Subject: [OSPF] Gen-ART review of draft-ietf-ospf-hmac-sha-05

From: Acee Lindem <[email-masked]>
Date: Mon, 20 Jul 2009 11:20:04 -0400

David Black's General Area Review Team (Gen-ART) comments on draft- 
ietf-ospf-hmac-sha-05.txt are attached:

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-ospf-hmac-sha-05
Reviewer: David L. Black
Review Date: July 20, 2009
IETF LC End Date: July 20, 2009

Summary:

This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:

This draft extends OSPFv2 cryptographic authentication to use
keyed HMACs based on the NIST secure hash standard family of
hashes (SHA-*).  The draft is solidly written, and is a
reasonably straightforward application of HMAC and the SHA-*
hashes to OSPFv2.  The draft is in good shape - all of my
comments are minor.

I wonder whether the "SHOULD" requirement for implementation
in Section 3 ought to include HMAC-SHA-224 and HMAC-SHA-384.
I would have stated requirements for these two hashes as "MAY"
in order to encourage use of either HMAC-SHA-256 or HMAC-SHA-512
when HMAC-SHA-1 is insufficient, but this is a judgment call.
To avoid confusion, this is a request that the authors think
about this topic; it is *not* a comment that the requirement
needs to be changed.  If the authors believe that the current
"SHOULD" requirements for these two hashes are the right
approach, that is acceptable to me.

In Section 3.2, it would be useful for the draft to say that an
OSPFv2 Security Association is not set up inband via OSPFv2, in
contrast to an IPsec Security Association created via IKE.  Among
the reasons that this should be done is that the term "OSPFv2
Security Association" is introduced in this draft - that term
does not occur in RFC 2328, even though Section D.3 of RFC 2328
defines an abstraction for which "OSPFv2 Security Association"
is an appropriate name.  I recommend stating that this term is
new to this draft.

The mention of IP Security in the next to last paragraph of
the Security Considerations (section 4) should cite an
informative reference, RFC 4301 would be appropriate.

idnits 2.11.12 did not find any issues.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 22 Jul 2009 21:01:32 +0530

Hi David,

Thanks for the review!
 
> approach, that is acceptable to me.

Given that SHA-224 (and perhaps SHA-384) is not even present in all crypto libraries we could, if others don't see a problem, move this from a SHOULD to a MAY.

> contrast to an IPsec Security Association created via IKE.  Among

Yup, sounds reasonable. We could add this too.

> informative reference, RFC 4301 would be appropriate.

Yup, this can also be done.

Cheers, Manav

---

From: Acee Lindem <[email-masked]>
Date: Wed, 22 Jul 2009 20:53:41 -0400

From: <[email-masked]>
Date: July 22, 2009 8:40:47 PM EDT
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Gen-ART review of draft-ietf-ospf-hmac-sha-05

Ran,

This is fine with me - about the level of requirement for

> approach, that is acceptable to me.

Thinking has clearly happened ;-), and I have no problem with
a result that that the requirement level will not be changed
because doing so would reduce consensus.

Thanks,
--David

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Wednesday, July 22, 2009 5:55 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-ospf-hmac-sha-05
>
> All,
>
> On  22 Jul 2009, at 11:31, Bhatia, Manav (Manav) wrote:
>> Given that SHA-224 (and perhaps SHA-384) is not even present in all
>> crypto libraries we could, if others don't see a problem, move this
>> from a SHOULD to a MAY.
>
> All of the key-lengths for SHA-1 and SHA-2 are available in
> at least some freely available crypto libraries, specifically
> including both SHA-224 and SHA-384.
>
> (ASIDE:  Commonly used search engines can be used to find such
libraries.
> Choice of which libraries, if any, to use is obviously implementer's
choice.)
>
> Making that change to "MAY" would reduce consensus, as compared
> with retaining the current "SHOULD" text, so it is best to keep
> the current language as-is.
>
> I made that edit about an hour after David's note was originally sent.
>
> Again, I made that edit about an hour after David's note was
> originally sent.
>
> Cheers,
>
> Ran Atkinson
> (who is the active document editor for this draft)
>
>