Skip to main content

OSPFv2 HMAC-SHA Cryptographic Authentication
RFC 5709

Yes

(Jari Arkko)
(Ross Callon)

No Objection

Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(Lisa Dusseault)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)

Note: This ballot was opened for revision 07 and is now closed.

Lars Eggert No Objection

(Jari Arkko; former steering group member) Yes

Yes ()

                            

(Ross Callon; former steering group member) Yes

Yes ()

                            

(Tim Polk; former steering group member) Yes

Yes (2009-08-26)
I believe the SHOULD list in section 3 is too long to have real value.  I would suggest
retaining HMAC-SHA-256 as MUST, with Keyed-MD5 and HMAC-SHA-1 as SHOULD,
and relegate the others to MAY.

I also wonder if SHA-224 is worth including at all, given that we would only save 32
bits on the wire.  Would operators find this a compelling feature?

(Adrian Farrel; former steering group member) No Objection

No Objection (2009-08-25)
Some nits you should address to improve the polish if you have the document open for edit.

---
RFC Editor will ask you to reduce the number of names on the front
cover in line with the guidelines.
---
Section 2
   All OSPF protocol exchanges are authenticated.
Notwithstanding the exact same statement being present in RFC 2328 it 
is hard to claim that the Authentication Type "Null Authentication"
represents authentication in action.
Perhaps s/are/can be/
---
Section 3.2
   RFC 2328 defined an OSPFv2 Security Association (OSPFv2 SA) in
   Section D.3, pages 228 and 229.  However, the term is new to
   this document.
Not clear what the second sentence means. 
---
Section 3.2

There is a fair amount of "should". Does this need to be 2119 language?
---
Section 3.2   Authentication Algorithm

             THis information should never
             be sent over the wire in cleartext form.
s/THis/This/

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2009-08-27)
3. Cryptographic authentication with NIST SHS in HMAC mode

   The algorithms used to generate and verify the message digest
   are specified implicitly by the secret key.

And the secret key is identified by the KeyID. Maybe you should say that here.

3.2   OSPFv2 Security Association

   Authentication Algorithm
             This indicates the authentication algorithm
             to be used.  THis information should never
             be sent over the wire in cleartext form.

While this is true, I think this is a bit misleading: this information is never sent over the wire (in OSPF itself). I suggest changing the last quoted sentence to make this clear, for example:

 This information is never sent over the wire.

(Cullen Jennings; former steering group member) (was Discuss, No Objection) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection (2009-08-27)
I agree with Tim that SHA-224 is of questionable value here
(and so is SHA-384, IMHO -- it's just a truncated version 
of SHA-512).

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()