Last Call Review of draft-ietf-ospf-hmac-sha-
review-ietf-ospf-hmac-sha-secdir-lc-orman-2009-07-22-00

Review of draft-ietf-ospf-hmac-sha-05.txt

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written primarily for
the benefit of the security area directors.  Document editors and WG
chairs should treat these comments just like any other last call
comments.

OSPFv2 is a routing protocol, and its specification includes a
description of using a cryptographic key with a hash function for the
purpose of message authentication.  This draft specifies the use of
different hash algorithms and a different way of combining the key
with the data in order to form the authentication value sent with the
messages.

"Introduction
   The creation of this addition to OSPFv2 was driven by operator
   requests that they be able to use the NIST SHS family of
   algorithms in the NIST HMAC mode, instead of being forced
   to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic
   Authentication."
A reference (minutes of a NANOG meeting?) would be helpful.

Section 3 gives SHA-1 a "should".  Why?  I can see a "should" on MD5 for
backward compatibility, but SHA-1 should have died aborning.

Section 3.1 says that the combining method is described in section
3.2, but 3.3 is the actual location.

Section 3.2, in the paragraph about authentication keys, refers
to "K in section 3.2 above".  This makes no sense; the reference
should probably be deleted.

In section 3.3: "K    is the selected OSPFv2 key".  The statement
should use the terminology of section 3.2 and say "K is the
authentication key for the OSPFv2 security association".

Section 3.3: "B is the block size of H, measured in octets, rather than bits".
Two problems:  1. the indentation format is irregular, 2. nothing has
suggested measuring in bits, so the "rather than" is gratuitous.
The same holds for the comment regarding the length of L.

Section 4, Security Considerations.

The second paragraph, while correct in the sense that it says nothing
wrong, does not do a good job of explaining the numerous "concerns".
There should be a plausible argument about the value of switching to
the SHA family, and a little more about the value of HMAC over
prepended key.  

Is there a reference for the US govmt's preference for the SHA family?

I don't think the section does justice to the problem of replay.  It's
my (perhaps flawed) understanding that RFC2838 strongly recommends
using a random initial sequence number, so the comments about always
starting from zero seem wrong (unless there is some reason to believe
that implementations do not adhere to the RFC2838 guidance).  Further,
a passive observer of two sessions can insert replay packets, with
appropriate sequence numbers, at any time, because the authentication
key is static.  RFC2838 seems to mandate a tear-down on any sequence
number mismatch.  Altogether, this seems more serious to me than the
MD5 collisions.

I think that a stronger statement about IPsec (I think that is what is
meant by the penultimate paragraph in section 4; there is no
reference) could be made.

I'm not sure that "full digital signatures" would be a stronger
authentication method.

The number of authors exceeds the RFC editor's guidelines.  I approve.