Subject: Re: [radext] #100: Gen-ART Review

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

#100: Gen-ART Review

Changes (by bernard_aboba@…):

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

Comment:

 Proposed resolution is as follows:

 -  Change:
 OLD: This memo,
      when approved, reflects the consensus of the RADIUS Extensions
     (RADEXT) Working Group of the IETF as to the features, properties and
     limitations of the crypto-agility work item for RADIUS.

 NEW: This memo describes the features, properties and
     limitations of the crypto-agility solution for RADIUS.

 - Introduction,second paragraph. In this situation, there has apparently
 been some confusion about the history, so articulating the background is
 important.

 - Section 1.3 has been deleted.

 - Section 2. First sentence has been deleted.

 - Section 2, 4th paragraph. SHOULD NOT upgraded to MUST NOT.

 - Section 4.2, 5th paragraph, 1st sentence. Change to: "   Support for
 encryption of individual RADIUS attributes is OPTIONAL
    for solutions that provide encryption of entire RADIUS packets."

 - Section 4.2, "Limit key scope" paragraph.  Change to:  Support
      for end-to-end confidentiality of RADIUS attributes is OPTIONAL.

 Change Section 4.3 to:

 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.

    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.

    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.

    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.

 - Section 4.6. Change
 OLD:

     At the
     IETF-70 meeting, and leading up to that meeting, the RADEXT WG
     debated whether or not RFC 4107 would require a RADIUS Crypto-Agility
     solution to feature Automated Key Management (AKM). The working
     group determined that AKM was not inherently required for RADIUS
     based on the following points:

 NEW:

     Consideration was given as to
     whether or not RFC 4107 would require a RADIUS Crypto-Agility
     solution to feature Automated Key Management (AKM). It was
     determined that AKM was not inherently required for RADIUS based
     on the following points:

 Nits:

 - Section 4.6, 1st paragraph after the bulleted list: Change .., the same
 time, … -> …, at the same time,...

-- 
----------------------------------------+-----------------------------------
 Reporter:  mary.ietf.barnes@…          |        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/100#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/>