Subject: Re: [radext] #23: Comments

From: "radext issue tracker" <[email-masked]>
Date: Sun, 06 Mar 2011 04:55:27 -0000

#23: Comments

Comment(by bernard_aboba@…):

 It is proposed that we change the following text in Section 4.3:

    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:

 Negotiation of cryptographic algorithms MAY occur within the
 RADIUS protocol, or within a lower layer such as the transport
 layer.  Since RADIUS is a request/response protocol, the ability to
 negotiate cryptographic algorithms within RADIUS is inherently
 limited.  While a RADIUS request can provide a list of supported
 cryptographic algorithms which can selected for use within a response,
 prior to the receipt of a response, the cryptographic algorithms
 utilized to provide security services within the request will need to be
 pre-configured.
 Since legacy implementations not supporting crypto-agility will
 silently discard requests not protected by legacy algorithms,
 in the absence of knowledge about the capabilities of the
 recipient, requests will need to be protected by legacy algorithms.

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

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/23#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: Sun, 06 Mar 2011 06:58:05 -0000

#23: Comments

Changes (by bernard_aboba@…):

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

Comment:

 Updated proposal.  Add the following text to the end of Section 2:

    Negotiation of cryptographic algorithms MAY occur within the RADIUS
    protocol, or within a lower layer such as the transport layer.  Since
    RADIUS is a request/response protocol, the ability to negotiate
    cryptographic algorithms within RADIUS is inherently limited.  While
    a RADIUS request can provide a list of supported cryptographic
    algorithms which can selected for use within a response, prior to the
    receipt of a response, the cryptographic algorithms utilized to
    provide security services within the request will need to be pre-
    configured.  Since legacy implementations not supporting crypto-
    agility will silently discard requests not protected by legacy
    algorithms, in the absence of knowledge about the capabilities of the
    recipient, requests will need to be protected by legacy algorithms.

 Within Section 4.3 delete:

    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.

-- 
----------------------------------+-----------------------------------------
 Reporter:  glenzorn@…            |        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: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/23#comment:2>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Sat, 12 Mar 2011 22:54:17 -0000

#23: Comments

 This still isn't quite right.  While negotiation within a single RADIUS
 request/response is limited,  there are potential techniques that could be
 utilized over multiple exchanges.  Currently, the text doesn't describe
 the limitations or lay out some of the possibilities, nor does it discuss
 the implications for backwards compatibility for security or performance.

 Suggested resolution is as follows:

 Change Section 2 to the following:

 2.  A Working Definition of Crypto-Agility

    A generalized definition of crypto-agility was offered up at the
    RADEXT WG session during IETF-68.  Crypto-Agility is the ability of a
    protocol to adapt to evolving cryptography and security requirements.
    This may include the provision of a modular mechanism to allow
    cryptographic algorithms to be updated without substantial disruption
    to fielded implementations.  It may provide for the dynamic
    negotiation and installation of cryptographic algorithms within
    protocol implementations (think of Dynamic-Link Libraries (DLL)).

    In the specific context of the RADIUS protocol and RADIUS
    implementations, crypto-agility may be better defined as the ability
    of RADIUS implementations to automatically negotiate cryptographic
    algorithms for use in RADIUS exchanges, including the algorithms used
    to integrity protect and authenticate RADIUS packets and to hide
    RADIUS Attributes.  This capability covers all RADIUS message types:
    Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-
    Request/Response, and Status-Server.  Negotiation of cryptographic
    algorithms MAY occur within the RADIUS protocol, or within a lower
    layer such as the transport layer.

    Since RADIUS is a request/response protocol, the ability to negotiate
    cryptographic algorithms within a single RADIUS exchange is
    inherently limited.  While a RADIUS request can provide a list of
    supported cryptographic algorithms which can selected for use within
    a response, prior to the receipt of a response, the cryptographic
    algorithms utilized to provide security services within the request
    will need to be determined a-priori.  Techniques that can be used for
    negotiation over multiple request/response exchanges are described in
    Section 4.3.

 Change the third paragraph of Section 4.2 to the following:

    Crypto-agility solutions MUST avoid security compromise, even in
    situations where the existing cryptographic algorithms utilized by
    RADIUS implementations are shown to be weak enough to provide little
    or no security (e.g. in event of compromise of the legacy RADIUS
    shared secret).  Included in this would be protection against bidding
    down attacks.  In analyzing the resilience of a crypto-agility
    solution, it can be assumed that RADIUS requesters and responders can
    be configured to require the use of new secure algorithms in the
    event of a compromise of existing cryptographic algorithms or the
    legacy RADIUS shared secret.

 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/23#comment:3>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Sun, 13 Mar 2011 01:38:43 -0000

#23: Comments

 It is not clear to me what is meant by "MUST use the existing mechanisms".
 RADIUS does not include a version field, nor is any negotiation mechanism
 defined in any of the existing RADIUS RFCs.  Recommend that this phrase be
 deleted.

 Also, there is a simple workaround to the issue of probing delays:
 upgrade the responder (e.g. RADIUS server) first, so that a crypto-agile
 request will always receive a response.

 The proposed revision to Section 2 is as follows:

    will need to be determined a-priori.

    Proposals MUST NOT introduce new capabilities negotiation features
    into the RADIUS protocol and 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.

    Acceptable solutions for determining the mechanisms to be used within
    a request include manual configuration as well as backward compatible
    negotiation techniques such as those described in Section 4.3.
    Solutions for determining the mechanisms to be used in a response
    include manual configuration and "advertise and select" mechanisms
    (e.g. selection within the response from mechanisms advertised in a
    request).

 The proposed revision to Section 4.3 is as follows:

    legacy mechanisms).

    legacy mechanisms have been compromised, secure algorithms MUST be

    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, instead
    utilizing mechanisms indicated in the response.

    requests.

    Probing techniques can avoid the use of legacy algorithms between
    crypto-agile implementations.  An initial request can omit use of
    legacy mechanisms, 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 mechanisms.  Similarly, the responder
    can assume that the requester supports crypto-agility and can
    prohibit use of legacy mechanisms 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 mechanisms.

    responders.  This can be addressed by upgrading the responders (e.g.
    RADIUS servers) first.

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