Subject: [OSPF] OSPF WG Last Call for OSPFv2 HMAC-SHA Cryptographic Authentication - <draft-ietf-ospf-hmac-sha-04.txt>

From: Acee Lindem <[email-masked]>
Date: Thu, 7 May 2009 13:42:42 -0400

The WG last call for the subject document will begin today and end  
Friday, May 22nd at 12:00 AM PDT. Please review the document and send  
your comments to this list. This version includes the Apad in the  
HMAC calculation consistent with the discussions we had in  
Philadelphia and SF.

Thanks,
Acee and Abhay

---

From: John Smith <[email-masked]>
Date: Sun, 17 May 2009 23:55:19 +0000 (GMT)

Hi,

Good to see this work finally moving forward. I strongly support this once the following two issues are taken care of:

(a) Draft cites HMAC-SHA-256, and not HMAC-SHA-1, as a MUST. Any specific reasons? 

(b) Although the document adds support for HMAC-SHA-224, i dont see a value of B (section 3.3) defined for this.

John

----- Original Message ----
From: Acee Lindem <[email-masked]>
To: OSPF List <[email-masked]>
Sent: Thursday, 7 May, 2009 23:12:42
Subject: [OSPF] OSPF WG Last Call for OSPFv2 HMAC-SHA Cryptographic Authentication - <draft-ietf-ospf-hmac-sha-04.txt>

The WG last call for the subject document will begin today and end Friday, May 22nd at 12:00 AM PDT. Please review the document and send your comments to this list. This version includes the Apad in the HMAC calculation consistent with the discussions we had in Philadelphia and SF.

Thanks,
Acee and Abhay_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Mon, 18 May 2009 09:06:52 -0400

Hi John,

Thanks for reviewing.

On May 17, 2009, at 7:55 PM, John Smith wrote:

>
> Hi,
>
> Good to see this work finally moving forward. I strongly support  
> this once the following two issues are taken care of:
>

HMAC-SHA-1 is "So 1997"... The authors reached agreement on a  
stronger common algorithm. Ran or one of the other authors may want  
to comment on HMAC-SHA-1 vulnerabilities as there was a lengthy  
discussion on which algorithm(s) to make a "MUST".

>
> (b) Although the document adds support for HMAC-SHA-224, i dont see  
> a value of B (section 3.3) defined for this.

This should be updated as follows:

                For SHA-1, SNA-224, and SHA-256: B == 64
                For SHA-384 and SHA-512:         B == 128

Thanks,
Acee

> Subject: [OSPF] OSPF WG Last Call for OSPFv2 HMAC-SHA Cryptographic  
> Authentication - <draft-ietf-ospf-hmac-sha-04.txt>
>
> Friday, May 22nd at 12:00 AM PDT. Please review the document and  
> send your comments to this list. This version includes the Apad in  
> the HMAC calculation consistent with the discussions we had in  
> Philadelphia and SF.
>
> Thanks,

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 18 May 2009 22:09:54 +0530

Hi John,

Thanks for the review! 

> discussion on which algorithm(s) to make a "MUST".

The search space for SHA1 collisions is getting quite smaller. One can read more about it on http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

Though this does not directly affect HMAC-SHA1, there have been other papers about attacks on SHA1 when used with the HMAC construct (http://eprint.iacr.org/2006/319.pdf). Please note that these attacks don't necessarily result in direct vulnerabilities in HMAC-SHA1 as used in the routing protocols for authentication purposes (RFC 4822, RFC 5310), because the colliding message may not necessarily be a syntactically correct protocol packet. However, we reasoned that if the WG wanted to mandate one particular authentication algorithm then it must be something stronger and more secure than HMAC-SHA1, and so HMAC-SHA-256 was chosen. 

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: Acee Lindem <[email-masked]>
Date: Fri, 22 May 2009 11:36:37 -0400

The WG last call has ended. We'll incorporate the John Smith's  
comment on the missing HMAC-SHA-224 block length and send the draft  
to the ADs for evaluation.
Thanks,
Acee