Document: draft-hoffman-ikev1-algorithms-02.txt
Review: Mary Barnes
Date: 13 december 2004 

Summary: 
-------- 
Draft needs some work prior to approval. Also, I'm a bit confused
about this draft updating RFC 2409, rather than obsoleting, as it does
more than augment 2409 with new algorithms (although, per the detailed
comments, it's unclear as to exactly what is changed from RFC
2409). Wouldn't this document be more appropriately a BCP on
recommended algorithms since IKEv2 is already planned to obsolete
2409?

  

 Detailed comments: 
------------------ 

- Abstract: the current wording is quite unclear. I would suggested
  changing from:
" The required and suggested algorithms in the original IKEv1
 specification does not reflect the current reality of IPsec market.
 It requires allowing weak security and suggests algorithms that are
 thinly implemented. This document updates RFC 2409, the original
 specification, and is intended for all IKEv1 implementations deployed
 today."

to: 
 " The required and suggested algorithms in the original IKEv1
 specification do not reflect the current reality of the IPsec market
 requirements.  The original specification allows weak security and
 suggests algorithms that are thinly implemented. This document
 updates RFC 2409, the original specification, and is intended for all
 IKEv1 implementations deployed today." 

- Introduction, page 2: "This document updates RFC by changing..."
  should be "This document updates RFC 2409 by changing...." (or it
  should refer to "the RFC").

- Section 3: "Pre-shared secrets" and "SHA-1" as MUSTs aren't new
  requirements as indicated by that first sentence. So, perhaps it
  should be spelled out separately that the only

 requirement(s) that haven't changed from those listed in section 2
 are "pre-shared secrets" and "SHA-1".
 
- Section 3: The paragraph beyond the bulleted list isn't very clear
  at all (and may have some errors). It first lists the following
  MUSTs and SHOULDs as having changed to MAYs due to cryptographic
  weakness:

" The other algorithms that were listed at MUST-level and SHOULD-level 
 in RFC 2409 are now MAY-level. This includes DES for encryption, MD5 
 and Tiger for hashing, Diffie-Hellman MODP group 1, Diffie-Hellman 
 MODP groups with elliptic curves, DSA for authentication with 
 signatures, and RSA for authentication with encryption." 

But, then several of those are stated to have been "dropped due to
lack of any significant deployment" later in that paragraph.

 " Tiger for hashing, 
 Diffie-Hellman MODP groups with elliptic curves, DSA for 
 authentication with signatures, and RSA for authentication with 
 encryption are dropped due to lack of any significant deployment and 
 interoperability." 

Should this not read "...dropped to MAY due to..." or has their
support really been dropped altogether? If the latter is true, then
there is an error and these shouldn't be listed in that 2nd paragraph
in section 3 (and I think that also substantiates the perspective that
this draft obsoletes rather than updates RFC 2409). However, I think
the former was intended; in which case, I think that paragraph would
read much more clearly to just list separately those that have been
dropped to MAY for crytographic weaknesses and those that have been
dropped to MAY due to lack of significant deployment.

 One final suggestion I would make to improve this document would be
 to add a summary table to augment the text (I had to draw this out
 myself to understand what the changes were). Listing all the
 algorithms in the 1st column, with old and new in the 2nd and 3rd
 columns, something like the following:

Algorithm                  RFC 2409      Recommended 
-------------------------------------------------------------- 
DES for encryption         MUST          MAY (cryptographic weakness) 
MD5/SHA-1 for hashing      MUST          MAY (MD5) 
                           MUST (SHA-1) 
Pre-shared secrets         MUST          MUST 
..... 
Diffie-Hellman MODP groups MAY/          MAY 
w/elliptic curves          SHOULD 
AES-128 in CBC             RFC 3602      SHOULD 
Diffie-Hellman MODP        RFC 3526      SHOULD 
group 14