Subject: Re: [radext] #101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06‏

From: "radext issue tracker" <[email-masked]>
Date: Mon, 11 Jul 2011 07:17:12 -0000

#101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06‏

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Proposed resolution is as follows:

 In Section 2 change "MUST NOT introduce new capabilities negotiation
 features" to "MUST NOT introduce generic new capabilities negotiation
 features".

 Change Section 4.3 to the following:

 4.3.  Backwards Compatibility

    Solutions MUST demonstrate backward compatibility with existing
    RADIUS implementations.  That is, an implementation that supports
    both crypto-agility and legacy mechanisms MUST be able to talk with
    legacy RADIUS clients and servers (using the legacy mechanisms).

    While backward compatibility is needed to ease the transition between
    legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is
    only appropriate prior to the compromise of those mechanisms.  After
    legacy mechanisms have been compromised, secure algorithms MUST be
    used, so that backward compatibility is no longer possible.

    Since RADIUS is a request/response protocol, the ability to negotiate
    cryptographic algorithms within a single RADIUS exchange is
    inherently limited.  Prior to receipt of a response, a requester will
    not know what algorithms are supported by the responder.  Therefore,
    while a RADIUS request can provide a list of supported cryptographic
    algorithms which can be selected for use within a response, prior to
    the receipt of a response, the cryptographic algorithms utilized to
    provide security services within an initial request will need to be
    pre-determined.

    In order to enable a request to be handled both by legacy as well as
    crypto-agile implementations, a request can be secured with legacy
    algorithms was well as with attributes providing security services
    using more secure algorithms.  This approach allows a RADIUS packet
    to be processed by legacy implementations as well as by crypto-agile
    implementations, and does not result in additional response delays.
    If this technique is used, credentials used with legacy algorithms
    MUST be cryptographically independent of the credentials used with
    the more secure algorithms, so that compromise of the legacy
    credentials does not result in compromise of the credentials used
    with more secure algorithms.

    In this approach to backward compatibility, legacy mechanisms are
    initially used in requests sent between crypto-agile implementations.
    However, if the responder indicates support for crypto-agility,
    future requests can use more secure mechanisms.  Note that if a
    responder is upgraded and then subsequently needs to be downgraded
    (e.g. due to bugs), this could result in requesters being unable to
    communicate with the downgraded responder unless a mechanism is
    provided to configure the requester to re-enable use of legacy
    algorithms.

    Probing techniques can be used to avoid the use of legacy algorithms
    in requests sent between crypto-agile implementations.  For example,
    an initial request can omit use of legacy mechanisms.  If a response
    is received, then the recipient can be assumed to be crypto-agile and
    future requests to that recipient can utilize secure mechanisms.
    Similarly, the responder can assume that the requester supports
    crypto-agility and can prohibit use of legacy mechanisms in future
    requests.  Note that if a requester is upgraded and then subsequently
    needs to be downgraded (e.g. due to bugs), this could result in the
    requester being unable to interpret responses, unless a mechanism is
    provided to configure the responder to re-enable use of legacy
    algorithms.

    If a response is not received, in the absence of information
    indicating responder support for crypto-agility (such as pre-
    configuration or previous receipt of a crypto-agile response), a new
    request can be composed utilizing legacy mechanisms.

    Since legacy implementations not supporting crypto-agility will
    silently discard requests not protected by legacy algorithms rather
    than returning an error, repeated requests can be required to
    distinguish lack of support for crypto-agility from packet loss or
    other failure conditions.  Therefore probing techniques can delay
    initial communication between crypto-agile requesters and legacy
    responders.  This can be addressed by upgrading the responders (e.g.
    RADIUS servers) first.

-- 
------------------------------------+---------------------------------------
 Reporter:  charliek@…              |        Owner:            
     Type:  defect                  |       Status:  closed    
 Priority:  minor                   |    Milestone:  milestone1
Component:  Crypto-Agility          |      Version:  1.0       
 Severity:  Submitted WG Document   |   Resolution:  fixed     
 Keywords:                          |  
------------------------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/101#comment:1>
radext <http://tools.ietf.org/radext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>