[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[radext] #85: Confidentiality Requirements

#85: Confidentiality Requirements

 Section 4.3 states:

    Proposals MUST support the negotiation of cryptographic algorithms
    for per-packet integrity/authentication protection.  Support for
    confidentiality of entire RADIUS packets is OPTIONAL.  However,
    proposals MUST support the negotiation of algorithms for encryption
    (sometimes referred to as "hiding") of RADIUS attributes.  It is
    RECOMMENDED for proposals to provide for the encryption
    of existing attributes.  This includes existing "hidden" attributes
    as well as attributes (such as location attributes) that require
    confidentiality.

 This paragraph is confusing along multiple dimensions.

 Since RADIUS is a transactional protocol, it is not possible to
 "negotiate" algorithms for use in a RADIUS request; algorithm(s) must be
 chosen.  Also, it is not clear whether negotiation as referred to here
 would refer to encryption of entire RADIUS packets or just individual
 attributes.  Also does "encryption of existing attributes" imply that
 attributes can be doubly encrypted?

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/85>
radext <http://tools.ietf.org/radext/>


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>