Algorithms for Internet Key Exchange version 1 (IKEv1)
draft-hoffman-ikev1-algorithms-03

[Ballot comment]
Reviewed by Mary Barnes, Gen-ART
I find that -03 addresses the concerns raised in the review.

Her review has been filed in the document log.

On Mary's comment about BCP - I think it's OK for this to be standards-track.

[Ballot comment]
I agree an editing pass would help this documen.t I would have
preferred the use of the adjectives defined in 2199 (REQUIRED,
RECOMMENDED, OPTIONAL) rather than new adjectives (MUST-level) etc,
but this preference is not strong enough for a discuss.

[Ballot comment]
Reviewed by Mary Barnes, Gen-ART

Her review has been filed in the document log.

On Mary's comment about BCP - I think it's OK for this to be standards-track.

Query: Should there be mention of a revised version of this at some date in the future changing AES to a MUST? (echoes of the SHOULD+ language from another document)

[Ballot discuss]
Mary Barnes' review (added as doc comment) identified several unclear points.
I think most of the problems can be fixed with an editing pass. I also think that the table of "old" and "new" requirements that Mary gave should be added to the document - it makes it MUCH clearer what has been changed.

[Ballot discuss]
Mary Barnes' review (added as doc comment) identified several unclear points.
I think most of the problems can be fixed with an editing pass. I also think that the table of "old" and "new" requirements that Mary gave should be added to the document - it makes it MUCH clearer what has been changed.

On Mary's comment about BCP - I think it's OK for this to be standards-track.
Should there be mention of a revised version of this at some date in the future changing AES to a MUST? (echoes of the SHOULD+ language from another document)

Review by Mary Barnes, Gen-ART (complete text)

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

[Ballot comment]
Comments received from the OPS directorate by Pekka Savola:

Good document.

Two minor editorial nits to improve the readability a bit.

  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.

==> I'd split to a second paragraph around here, because I first
misread this text.

    DES for
  encryption, MD5 for hashing, Diffie-Hellman MODP group 1 are dropped
  to MAY due to cryptographic weakness.  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.

==> this does not explain why MD5 is dropped for _HMAC functions_ ?