Subject: [OSPF] Revised OSPF HMAC SHA Authentication Draft

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 18 Aug 2006 09:58:40 +0530

Hi,

We have updated the OSPF HMAC-SHA authentication draft with the comments
that we received on the list and offline.

The updated version has a short section which discusses backwards
compatibility, similarities and differences from using MD5 (which is
explained in Section 5 of 2328), etc.

http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-
02.txt

Please let us know if there are further modifications desired.

Cheers,
Manav, Vishwas, et al.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 18, 2006 1:20 AM
Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-02.txt

> >A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > Title : OSPF HMAC Cryptographic Authentication
> > Author(s) : M. Bhatia, et al.
> > Filename : draft-bhatia-manral-white-ospf-hmac-sha-02.txt
> > Pages : 11
> > Date : 2006-8-17
> >
> > This document describes a mechanism for authenticating OSPF packets
> >   by making use of the HMAC algorithm in conjunction with the SHA
> >   family of cryptographic hash functions. Because of the way the hash
> >   functions are used in HMAC construction, the collision attacks
> >   currently known against SHA-1 do not apply.
> >
> >   This will be done in addition to the already documented
> >   authentication schemes described in the base specification.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-
02.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in the body of
> > the message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then
> > "get draft-bhatia-manral-white-ospf-hmac-sha-02.txt".

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Erblichs <[email-masked]>
Date: Fri, 18 Aug 2006 11:20:46 -0700

Vishwas Manral, et al,

	RFC 2328 specificly specifies "message digest" in section D3.

	I am not expert in this field, but wouldn't a section
	why Type 2 shouldn't then be reserved for MD5?

	It should ALSO be a simple argument that any type 2 before now
	 was using MD5. Thus it is a defacto standard for the type.

	And then and a aditional type by allocated for HMAC-SHA auth.

	Mitchell Erblich
	----------------

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 18 Aug 2006 20:48:24 +0000 (GMT)

Mitchell,
 
Type 2 in RFC 2328 is not reserved for MD5, but is instead used to denote some sort of Cryptographic Authentication as opposed to NULL authentication and simple password scheme. 
 
Refer to Figure 2 in our draft. It shows the way the authentication data must be filled in the OSPF header if the Authentication Type is set to 2. Cryptographic Authentication (Type 2) as defined in RFC 2328 allows for any auth algorithm to be used without altering the protocol packets. This is done by including the Key ID in the authentication data. Key ID carried in the packet uniquely identifies an OSPF SA and gives the authentication algorithm and the secret key that is used to create the message digest appended to the OSPF packet.
 
If the Key ID maps to a HMAC-SHA algorithm then the HMAC is appended to the OSPF packet instead of the MD5 digest.
 
Cheers,
Manav

----- Original Message ----
From: Erblichs <[email-masked]>
To: Vishwas Manral <[email-masked]>
Cc: [email-masked]; Manav Bhatia <[email-masked]>
Sent: Friday, 18 August, 2006 11:50:46 PM
Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

Vishwas Manral, et al,

    Mitchell Erblich
    ----------------

---

From: Erblichs <[email-masked]>
Date: Fri, 18 Aug 2006 15:03:33 -0700

Manav Bhatia,

	Did you read my email and my arguments.
	
	I am only concerned/dealing with interoperability...
	The Secondly section deals with Key-ID..

	Section D3 specifies MD5 as the only auth method. It specificly
	stated "message digest".
	1) Do you agree?

	In every implementation that I know of type 2 is MD5. That
	makes it a MD5 "defacto standard" with respect to type 2.
	2) Do you agree? Do you know what is meant as a "defacto
	  standard"? 

	Please inform me of at least 1 implmentation does not assume
	type 2 is MD5 that is not based on this draft.
	3) Do you know of even 1 customer released implementation?

	Until that is the case, I think type 2 should be "reserved" for
	MD5 to DECREASE the chance of any interoperability concerns.

	Their is no reason that I know of, that a additional type, say type
	3 could not then be used for this RFC's auth method..
	4) Why can't shouldn't a new type be specified? 

	Thus, the point is that if ALL implementations before this draft
	suggestion used type 2 as MD5, why shouldn't a new type be used
	for HMAC-SHA?

	Secondly:
	I understand that the "Key-ID" from 2328 is supposely to identify the
	alg and secret key,  per "interface".
	However, I have no knowledge that certain bits within the key-id would
	IETF uniquely identify MD5 vs HMAC-SHA. Until someone informs me that
	all key-ids have this global uniqueness. With virtual interfaces
	and non-interface flooding scope OSPF pkts, I consider this a possible
	issue that doesn't need to be addressed when their is a simple ANSWER.

	THEN, since we have additional types available and 100% of
implementations
	use MD5 as type 2, I would hope that some else with more clought would 
	have suggested, the simple approach and officially allocate type 2 as
MD5 and 
	allocate a new type for additional auth methods..
	I am actually surprised that I saw no-one else suggested this!!!!

	Mitchell Erblich
	------------------