Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

[Manav Bhatia <[e-mail]>]

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 <[e-mail]>
>> To: Vishwas Manral <[e-mail]>
>> Cc: [e-mail]; Manav Bhatia <[e-mail]>
>> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf