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
------------------
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 PROTECTED]>
> To: Vishwas Manral <[EMAIL PROTECTED]>
> Cc: [email protected]; Manav Bhatia <[EMAIL PROTECTED]>
> 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
> 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
> ----------------
>
> Vishwas Manral wrote:
> >
> > 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 PROTECTED]>
> > To: <[email protected]>
> > 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 PROTECTED] 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 protected]
> > https://www1.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
