[radext] #89: Key Wrap and Password Hiding Requirements

["radext issue tracker" <trac+radext@zinfandel.tools.ietf.org>]

#89: Key Wrap and Password Hiding Requirements

 The properties of a key and a password are different.  Yet in several
 places, the document seems unclear about whether requirements for
 negotiation of Key-Wrap algorithms are distinct from requirements relating
 to hiding of passwords.

 For example, Section 1.3 states the following:

    The RADEXT WG will propose one or more specifications to remediate
    any identified deficiencies in the crypto-agility properties of the
    RADIUS protocol.  The known deficiencies include the issue of
    negotiation of substitute algorithms for the message digest
    functions, the key-wrap functions, and the password-hiding function.
    Additionally, at least one mandatory to implement cryptographic
    algorithm will be defined in each of these areas, as required.

 This would seem to imply that negotiation of algorithms for key-wrap is
 distinct from algorithms for "password hiding".

 Section 2 says this:

    Negotiation of cryptographic
    algorithms MAY occur within the RADIUS protocol, or within a lower
    layer such as the transport layer.

 While confidentiality can be provided in the transport layer, is it
 possible to provide keywrap functionality in this layer?

 Section 4.2 says:

    Proposals MUST support the negotiation of cryptographic algorithms
    for per-packet integrity/authentication protection.  It is
    RECOMMENDED that solutions provide support for confidentiality,
    either by supporting encryption of entire RADIUS packets or by
    encrypting individual RADIUS attributes.  This includes providing
    support for improving the confidentiality of existing encrypted
    (sometimes referred to as "hidden") attributes as well as encrypting
    attributes (such as location attributes) that are currently
    transmitted in cleartext.  Proposals supporting confidentiality MUST
    support the negotiation of cryptographic algorithms for encryption.

 This text appears to treat all encrypted attributes the same.

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

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/89>
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/>