Subject: Re: [radext] #22: Review

From: "radext issue tracker" <[email-masked]>
Date: Sat, 05 Mar 2011 20:58:26 -0000

#22: Review

Changes (by bernard_aboba@…):

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

Comment:

 The proposed resolution is as follows:

 Within Section 4.3, change the following text:

    Proposals MUST NOT introduce new capabilities negotation features
    into the RADIUS protocol, but rather MUST use the existing
    mechanisms.  Included in such negotiation techniques are "hint and
    accept" and "hint and reject" mechanisms, where the NAS (RADIUS
    client) provides a list of supported algorithms and the RADIUS server
    selects one.

 to:

    Proposals MUST NOT introduce new capabilities negotiation features
    into the RADIUS protocol, but rather MUST use existing mechanisms.
    Negotiation techniques include "hint and accept" and "hint and
    reject" mechanisms, where the RADIUS request provides a list of
    supported algorithms and one is selected in the response.  Since it
    is necessary to integrity protect the list of algorithms, at least
    one ciphersuite needs to be used to protect the request and response.

-- 
--------------------------------+-------------------------------------------
 Reporter:  jsalowey@…          |        Owner:  bernard_aboba@…          
     Type:  defect              |       Status:  closed                   
 Priority:  major               |    Milestone:  milestone1               
Component:  Crypto-Agility      |      Version:  1.0                      
 Severity:  Active WG Document  |   Resolution:  fixed                    
 Keywords:                      |  
--------------------------------+-------------------------------------------

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

---

From: "radext issue tracker" <[email-masked]>
Date: Sat, 12 Mar 2011 23:08:34 -0000

#22: Review

Comment(by bernard_aboba@…):

 It isn't clear to me how "Hint and Reject" techniques apply, since legacy
 implementations will silently discard crypto-agile requests that don't
 utilize legacy mechanisms, without sending an error-message.  So the
 reality is more like "Choose and Silent Discard".  This can make it hard
 for a requester to distinguish lack of support for crypto-agility from
 packet loss or some other failure.

 Unless a request utilizing "Hint and Accept" is protected by legacy
 methods, a legacy implementation will silently discard it, this approach
 is only possible if the responder is crypto-agile, and even then, it only
 applies to the response, not the request, which needs to be protected by
 mechanisms that are chosen apriori.  Yet the document talks about the need
 to protect all RADIUS messages, not just responses.

 The reality is that in the absence of information about the capabilities
 of the responder, the requester will need to make a decision on what
 algorithms to use to protect the request.  If legacy mechanisms are
 included, then there will be potential consequences, regardless of what
 other algorithms are used.   So it is desirable to avoid use of legacy
 algorithms between crypto-agile implementations.   Also, information from
 previous responses could be used to determine what mechanisms to use to
 protect subsequent requests.

 Since Section 4.3 is about backward compatibility, it needs to talk about
 some of these issues, and put forward some potential approaches to solving
 the problem that can address security issues in both requests and
 responses.

 The suggested resolution is to change Section 4.3 to the following:

 4.3.  Backwards Compatibility

    Solutions to the problem MUST demonstrate backward compatibility with
    existing RADIUS implementations.  That is, an implementation that
    supports both the crypto-agility solution and legacy mechanisms MUST
    be able to talk with legacy RADIUS clients and servers (using the
    legacy mechanisms).  Proposals MUST NOT introduce new capabilities
    negotation features into the RADIUS protocol, but rather MUST use the
    existing 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 algorithms have been compromised, secure algorithms MUST be
    used, so that backward compatibility is no longer possible.

    Acceptable solutions to determining which set of mechanisms is used
    (with a particular peer) include some kind of negotiation, and manual
    configuration.  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 as well as more secure algorithms.
    While this approach permits the initial use of legacy algorithms
    between crypto-agile implementations, if the responder indicates
    support for crypto-agility, future requests can omit use of legacy
    algorithms.

    This approach minimizes the response delay from both legacy and
    crypto-agile implementations.  However, it is viable only where
    legacy hidden attributes (e.g. User-Password) are not included within
    requests, and where compromise of the legacy algorithm and RADIUS
    shared secret does not compromise secure algorithms.

    Probing techniques can be used to avoid the use of legacy algorithms
    between crypto-agile implementations.  An initial request can omit
    use of legacy algorithms, and if a response is received, then the
    recipient can be assumed to be crypto-agile and future requests to
    that recipient can utilize secure algorithms.  Similarly, the
    responder can assume that the requester supports crypto-agility and
    can prohibit use of legacy algorithms in future requests.

    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 algorithms.

    Since legacy implementations not supporting crypto-agility will
    silently discard requests not protected by legacy algorithms rather
    than returning an error, repeated requests may be required to
    distinguish lack of support for crypto-agility from packet loss or
    other failure conditions.  As a result, probing techniques can delay
    initial communication between crypto-agile requesters and legacy
    responders.

    Crypto-agility solutions SHOULD NOT require changes to the RADIUS
    operational model as defined in "RADIUS Design Guidelines" [RFC6158]
    Section 3.1 and Appendix A.4.  Similarly, a proposal SHOULD focus on
    the crypto-agility problem and nothing else.  For example, proposals
    SHOULD NOT require new attribute formats and SHOULD be compatible
    with the guidance provided in [RFC6158] Section 2.3.

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