AD review of draft-ietf-radext-crypto-agility-requirements-06.txt

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

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 


--
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/>