Re: [radext] #99: AD Review of RADIUS Crypto-Agility Requirements

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

#99: AD Review of RADIUS Crypto-Agility Requirements

Changes (by bernard_aboba@â):

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


Comment:

 Proposed resolution is as follows:

 T1.  This language appears to be boilerplate in AAA requirements RFCs and
 BCPs (see RFC 2989 Section 1.1, RFC 4962 Section 1.1, etc.).  No change
 suggested.

 T2. Recommended change in 4.2 is:
    Guidance on acceptable algorithms can be found in [NIST-SP800-131A].
    It is RECOMMENDED that mandatory-to-implement cryptographic
    algorithms be chosen from among those classified as "Acceptable" with
    no known deprecation date from within this or successor documents.

 T3.  This is a typo.  It should refer to Section 3.

 E1.  A newer notice should be used.

 E2. Recommend combining Section 1.3 and 1.1 as follows:

 1.1.  General

    At the IETF-66 meeting, the RADIUS Extensions (RADEXT) Working Group
    was asked by members of the Security Area Directorate to prepare a
    formal description of a crypto-agility work item, and corresponding
    charter milestones.  After consultation with one of the Security Area
    Directors, Russ Housley, text was initially proposed on the RADEXT WG
    mailing list on October 26, 2006:

       The RADEXT WG will review the security requirements for crypto-
       agility in IETF protocols, and identify the deficiencies of the
       existing RADIUS protocol specifications against these
       requirements.  Specific attention will be paid to RFC 4962
       [RFC4962].

       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 document describes the features, properties and limitations of
    RADIUS crypto-agility solutions, as well as defining the term
    "crypto-agility" as used in this context, and providing the
    motivations for this work.

    The requirements defined in this memo have been developed based on e-
    mail messages posted to the RADEXT WG mailing list, which may be
    found in the archives of that list.  The purpose of framing the
    requirements in this memo is to formalize and memorialize them for
    future reference, and to bring them explicitly to the attention of
    the IESG and the IETF Community, as we proceed with this work.


 E3. The typo should be corrected.

-- 
-----------------------------------+----------------------------------------
 Reporter:  dromasca@â             |        Owner:            
     Type:  defect                 |       Status:  closed    
 Priority:  major                  |    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/99#comment:1>
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/>