Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

Sigh.  C'mon, folks, there is no problem.

View the algorithm as simply part of the shared secret.  All  
authentication is done between consenting adults and there has to be  
out-of-band and a priori agreement on the parameters or the  
authentication fails.  Nobody is going to be guessing the algorithm  
in use on a particular session any more than they would be guessing  
the secret.  And if you want to switch algorithms (which is  
essentially just switching secrets) the key ID mechanism is present.

At the end of the day it doesn't matter if the value of 2 or 3 or 42  
is used;  if there's a mismatch on the the algorithm ID, the  
algorithm, or the key, the authentication will fail, and if it all  
matches, it will work.  For that matter, I don't think that even the  
existing algorithm ID is necessary, since the entire thing has to be  
agreed upon a priori anyhow.

For what it's worth, type 2 fits the bill just fine, defined the way  
that it is.  If one box does only MD5 and the other box only does  
SHA, they cannot talk.  If they share an algorithm, it is up to the  
user to configure the two boxes compatibly, like a thousand other  
parameters.  While having a separate code point for SHA would have  
marginal debugging utility ("wrong algorithm, dummy!") it's no harder  
to make sure that this matches on both sides than it is to make sure  
the shared secret matches.

--Dave

On Aug 23, 2006, at 3:06 AM, sujay wrote:

> Yes,
>
> If an authentication fails it could mean the algo's used are  
> different.
>
> And if one implementation supports MD5 alone( "which I believe is  
> commonly used !" ), the others
>
> support otherwise, It could be a problem, there is no explicit way  
> we are converying which algo is being used.
>
> The Au Type = 2 is overloaded.
>
> Now a "MUST" clause is for the WG to decide.
>
> 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!
>
>
> From: Manav Bhatia [mailto:manav@riverstonenet.com]
> Sent: 2006年8月23日 13:04
> To: 'sujay'
> Cc: 'Mailing List'
> Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft
>
> 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
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf