[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

 Hi,

 This is the AD review of
 draft-ietf-radext-crypto-agility-requirements-06.txt. The document is in
 good shape. Because of the relative broad applicability and security
 impact of the document, I will send it to IETF Last Call, although as a
 WG document targetting Informational status this would not have been
 mandatory. I have a number of comments and questions which I request to
 be taken into consideration together with the other IETF LC comments.

 The technical comments are marked T and the Editorial comments are
 marked E.

 T1. I am a little concerned by the fact that the second paragraph of
 section 1.2 speaks in terms of 'compliance', 'unconditional compliance'
 and 'conditional compliance' with 'this specification' which is actually
 an Informational document. Is this really needed? We tend to avoid such
 strict language in IETF documents.

 T2. In section 4.2 I see the following:

    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.

 I acknowledge that the NIST document is rather new, but such documents
 have a timely nature by definition and may change faster than we want
 this RFC to change. I would suggest to include at least a note saying
 that if [NIST-SP800-131A] its successors need to be taken as reference.
 Or, if we do not want to assume the risk of a blank check we should
 observe that this recommendation is valid at the time of the publication
 of this document.

 T3. Also in section 4.2 I see the following:

    In addition to the goals referred to above, [RFC4962] Section 2
    describes additional security requirements, which translate into the
    following requirements for RADIUS crypto-agility solutions:

 It may be my understanding but I could not find in section 2 of
 [RFC4962] the requirements that translate into 'strong, fresh, session
 key' and 'Limit key scope'. Can you explain me what I am missing?


 E1. Idnits complains:

   == You're using the IETF Trust Provisions' Section 6.b License Notice
 from
      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
      http://trustee.ietf.org/license-info/)

 E2. I am wondering what the scope of section 1.3 is. Maybe it's my
 English, but why is the section named 'The Charge'? Do you mean 'Scope'?
 It looks to me that dropping this section or making it (or a shorter
 version) part of Section 1.4 as background information would be better.

 E3. Page 5, second paragraph s/can selected/can be selected/

 Thanks and Regards,

 Dan

-- 
-----------------------------------+----------------------------------------
 Reporter:  dromasca@â             |       Owner:            
     Type:  defect                 |      Status:  new       
 Priority:  major                  |   Milestone:  milestone1
Component:  Crypto-Agility         |     Version:  1.0       
 Severity:  Submitted WG Document  |    Keywords:            
-----------------------------------+----------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/99>
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/>