Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

From: Manav Bhatia <[email-masked]>
Date: Sat, 19 Aug 2006 17:17:29 +0000 (GMT)

Mitchell,
 
>    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.
 
A message digest function is *just* another hash function and the two terms can be almost used interchangeably. Please note that MD5 is not the only "message digest" function; SHA-1 is also a NIST promoted "message digest" function. 
 
Essentially a message digest or hash function takes an arbitary sized data, mangles it, and outputs a fixed length hash value. IMO RFC 2328 is referring to any such function here and not MD5 really per se.
 
So for authentication purposes we can concatenate a shared secret K with the message M and use some message digest function x to compute MD (K | M) as the MAC. This scheme can be broken and the HMAC construct was introduced, which at a very top level, works this way: 
 
(i) Concatenate the secret to the front of the message, digest the combination. 
(ii) Concatenate the secret to the front of the digest, and digest the combination again.
 
Thus HMAC also creates a "message digest" - which is what we propose to use in our draft.
 
>    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.
 
There is nothing in RFC 2328 which says that type 2 is "MD5" authentication. 
 
If you look at D.3 from 2328 then it says very clearly that "The algorithms used to generate and verify the message digest are specified implicitly by the secret key". It goes on to say that this particular specification, i.e. RFC 2328, defines the use of type 2 authentication *when* MD5 authentication is used.
 
2328 clearly leaves enough room for other "message digest/hash" functions to be used for OSPF.
 
>    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.
 
There will be no interop issues. It will be a simple case of authentication failure and a configuration mismatch. Its no worse than configuring two routers with different keys.
 
> 
>    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
 
If an implementation believes that type 2 only means MD5, then its a gross misinterpretation of the RFC.
 
>    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
 
No it doesnt work this way.
 
>    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.
 
Key ID is simply an identifier (or an index) mutually agreed on by the two communicating parties that uniquely identifies the secret key that is used to generate the message digest/hash along with some other details. Its not as simple as this, and i am not getting into the details of key-chains, key distribution, key life time, etc. 
 
>    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 repeat. An implementation that only works by assuming type 2 to mean MD5 only is clearly violating the spirit of RFC 2328. Its after all not a huge effort to change some data structures to map the key ID to different authentication algorithms.
 
Cheers,
Manav
 
>    I am actually surprised that I saw no-one else suggested this!!!!
> 
>    Mitchell Erblich
>    ------------------
>    
> 
> Manav Bhatia wrote:
>> 
>> 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,
>> 
>>     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

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

---

From: "Phil Cowburn" <[email-masked]>
Date: Sun, 20 Aug 2006 06:29:15 +0530

I strongly agree with Manav here and an implementation must be able to
demultiplex using the Key ID in the incoming packet. It is afterall
for this very reason that we put the Key ID in the packet.

Erblichs point, as i read it is, that most implementations (if not
all) currently take type 2 to mean MD5. This may break once this draft
becomes a standard, which it would, in some time.

My take on this is that even if the WG agrees to Erblichs solution and
introduces a new type, say 3 for HMAC-SHA-1 authentication, then
somebody else could repeat the same argument and clamour for a new
type when we're introducing newer authentication algorithms in the
future.

Lets move on from this issue.

Phil

---

From: Acee Lindem <[email-masked]>
Date: Sun, 20 Aug 2006 17:45:22 -0400

> type when we're introducing newer authentication algorithms in the
Hi Phil,
I think RFC 2328 is clear that authentication type 2 applies to all
cryptographic authentication types.

Thanks,
Acee

---

From: "Phil Cowburn" <[email-masked]>
Date: Mon, 21 Aug 2006 06:11:36 +0530

Hello Acee,

> cryptographic authentication types.

Which is exactly what i'm saying.

In fact i just gave an argument saying that we must not create a new
authentication type for the stuff introduced in this new draft as 2328
is capable of handling different authentication algorithms.

Phil

---

From: "tom.petch" <[email-masked]>
Date: Mon, 21 Aug 2006 11:48:50 +0200

---- Original Message -----
From: "Phil Cowburn" <[email-masked]>
To: "Acee Lindem" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 21, 2006 2:41 AM
Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

> is capable of handling different authentication algorithms.
Technically correct as almost everyone agrees, and yet and yet ...

If you had asked me, before this issue came up, I would have sworn that  RFC2328
mandated type 2 as MD5.  It has been the only one is use for so long, the only
one I ever see, and I thought I knew what RFC2328 said:-(

So, I think this will introduce confusion and we should clearly flag the fact
that people (like me) with extensive practical experience of OSPF may be
surprised to now learn what the existing standard actually is.

Tom Petch

---

From: "Tom Sanders" <[email-masked]>
Date: Mon, 21 Aug 2006 16:50:38 +0530

Folks,

Obviously the point that Erblichs is trying to make is that OSPF may
be "technically" capable of supporting HMAC-SHA authentication in its
current form, but OAM may be an issue and it may become harder to
debug an auth mismatch.

In the end the operator can always look at the router configurations
in case OSPF doesnt come up and would know that the auth algos dont
match. This can then be fixed.

Yeah ..Yeah .. I understand this!

What i miserably fail to understand is the reluctance in the WG to use
a new authentication type. We have 16 bits reserved for this field and
i dont see this being used up any time in the coming future.

Explictly indicating the auth algo details in the header makes, in my
view, debugging extremely easy. I understand that we would be eating
up type codes that we would have to fill in the OSPF header each time
we come up with a new authentication algorithm but given the size of
this field i dont think its a point of concern.

Is it possible to poll the WG on what they think is the right
approach? Chairs, Authors?

The poll should be on whether we should proceed as-is in the draft or
should we use a new type field for each new authentication scheme that
we come out with?

-- 
Toms.

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 21 Aug 2006 14:22:20 +0000 (GMT)

Hi Tom,
 
[..] 
 
> should we use a new type field for each new authentication scheme that
 
We dont need to use a new auth type value for each new authentication scheme that comes up in the future.
 
One can define a new generic auth type 3, which would carry the authentication algorithm details in addition to the Key ID, auth data length and the crypto sequence number. The authentication data for type auth type 3 would be the same as type 2, except that the reserved bytes would get replaced with the authentication algorithm ID.
 
However, i dont think this is required.
 
Cheers,
Manav

---

From: "Tom Sanders" <[email-masked]>
Date: Mon, 21 Aug 2006 22:21:29 +0530

Manav,

> We dont need to use a new auth type value for each new authentication scheme > that comes up in the future.
>
> One can define a new generic auth type 3, which would carry the authentication > algorithm details in addition to the Key ID, auth data length and the crypto
> sequence number. The authentication data for type auth type 3 would be the
> same as type 2, except that the reserved bytes would get replaced with the
> authentication algorithm ID.

Excellent, this is much better than our initial guess.

Actually one octet is enough for carrying the Algo ID. You are still
left with one reserved octet. Go Play!

> However, i dont think this is required.

Well, thats something that the WG, and not you and me, have to decide! :)

-- 
Toms.

---

From: Michael J Barnes <[email-masked]>
Date: Tue, 22 Aug 2006 12:32:33 -0700

Hello Manav,

> One can define a new generic auth type 3, which would carry the
> authentication algorithm details in addition to the Key ID, auth data
> length and the crypto sequence number. The authentication data for type
> auth type 3 would be the same as type 2, except that the reserved bytes
> would get replaced with the authentication algorithm ID.

A concern I have with this is that when a new authentication algorithm is 
devised we would have to have to wait for a new OSPF RFC to specify the 
Authentication Algorithm ID before we could implement the algorithm. 
Generally, I don't think a new OSPF RFC should be required just to make 
use of a new algorithm.

Looking at IPsec, it also does not include a field which indicates which 
algorithm is used. The IPsec SPI is equivalent to the Key ID we use in 
OSPF. We are defining an SA similarly to IPsec, which . As in IPsec, the 
SA indicates which algorithm and key are used. So this draft is in keeping 
with how IPsec operates. I think it makes sense for OSPF to follow the 
lead of IPsec in this regard.

My $.02

Thanks,
Michael

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Aug 2006 15:44:35 -0400

Tom Sanders wrote:
>> authentication > algorithm details in addition to the Key ID, auth 
>> data length and the crypto
Hi Tom,

I'd also vote against this since the standardized definition of 
cryptographic
authentication (AuType = 2) was designed to accommodate different hash
algorithms. Based on the discussion heretofore, it seems that its definition
satisfies this requirement. Additionally, I don't see any compatibility 
problems
with implementations unequivocally map AuType 2 to MD5 authentication.
As one would expect, authentication will fail (at least with a very high
probability :^) if there is a mismatch between configured hash algorithms.

Thanks,
Acee

---

From: Russ White <[email-masked]>
Date: Tue, 22 Aug 2006 17:07:34 -0400

> cryptographic authentication (AuType = 2) was designed to accommodate
> different hash algorithms. Based on the discussion heretofore, it
> seems that its definition satisfies this requirement. Additionally, I
> don't see any compatibility problems with implementations
> unequivocally map AuType 2 to MD5 authentication. As one would
> expect, authentication will fail (at least with a very high 

Agreed--I would agree this is the best way to handle this.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: sujay <[email-masked]>
Date: Wed, 23 Aug 2006 12:27:05 +0530

I would prefer maintain using Au Type = 2  for the new algo's as well.
With a thought ; as there is a possibility of more algo's to be added in
te same scheme with Au Type = 2, and there is some talk about MD5 being
the most used in implementations.

Can we have a default algo. concept??

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h
&hl=en

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it! 
-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: 2006年8月23日 2:38
To: Acee Lindem
Cc: [email-masked]
Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

> unequivocally map AuType 2 to MD5 authentication. As one would expect, 
> authentication will fail (at least with a very high probability :^) if 
> there is a mismatch between configured hash algorithms.

:-)

Russ

- --

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 23 Aug 2006 07:37:40 +0000 (GMT)

Sujay,
 
>Can we have a default algo. concept??
 
What do you mean by the default algo? Is it one authentication algorithm that all implementations MUST support?
 
Manav