Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

Hi Mitchell,

Erblichs wrote:
> Group,
>
> 	Sometimes a minor opinion..
>
> 	First. Up to this point, IMO, 99%+ nbr misconfigs
> 	could be debuged at 1 local router with review of
> 	incoming pkts. With this "work-in-progress", 
> 	this will NO longer be the case if we overload
> 	type 2.
>   
I believe Dave Katz already made this point. However, let me apply it to
your statement. Previously, you could have a key mismatch. With the
new draft you can have a key/algorithm mismatch - I don't see that
this is that big a change.

Thanks,
Acee

> 	What is a 'Must' clause going to achieve?
>
> 	  By default ALL implementations support MD5, simple/clear,
> 	  and NULL auth. The only high probability of a nbr
> 	  formation is to use one of these three. Yes, MD5 was
> 	  the defacto standand auth 2 algor.
>
> 	  Thus, any algor that super-ceeds one of these auths,
> 	  at this time, will not guarantee interoperability.
>
> 	  However, as pointed out in the draft, the highest
> 	  common auth is not highly secure, but could be used
> 	  as a fall back. Yes, the admin would see either before
> 	  or after a nbr formation attempt that a mismatch
> 	  exists, and reconfigs the routers to use the fallback.
>
> 	  Thus, to support backward compatibility and to secure
> 	  against SOME attacks, IMO all configs SHOULD/MUST support
> 	  MD5. 
>
> 	  If this is the case, would the clause only improve the
> 	  chance that "MD5" is not removed as newer algors are
> 	  supported?
>
> 	  Or is their a thought for a algor other than MD5 to
> 	  specified as the MUST algor?
>
>
> 	Mitchell Erblich
> 	----------------
> 	
>
> 	  
> 	  
>
> Vishwas Manral wrote:
>   
>> Sujay,
>>
>> I agree we can include that in the draft. The reason as well as the
>> links to the draft.
>>
>> Thanks,
>> Vishwas
>>
>> On 8/24/06, sujay <sujayg@huawei.com> wrote:
>>     
>>> Agree,
>>> While a failed authentication could be basically due to configuration issues
>>> or
>>> Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported
>>> algo'
>>> may need  an  Image upgrade. It's my guess image upgrade may not be
>>> thoroughly welcome.
>>> We do need a 'Must' support algo. clause.
>>>
>>> Vishwas ; would it be a nice idea to add a section in the current draft,
>>> talking about this issue
>>> and with cross reference to the below mentioned drafts??
>>>
>>>
>>> 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: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
>>> Sent: Thursday, August 24, 2006 10:24 AM
>>> To: paul@jakma.org
>>> Cc: ospf@ietf.org; Mailing List
>>> Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft
>>>
>>> Paul,
>>>
>>>       
>>>> There is though value in defining "MUST support" algos, otherwise poor
>>>> users could be faced with having routers which all implement OSPF but
>>>> can be made to interoperate unless authentication is left
>>>> unconfigured.
>>>>         
>>> We have drafts to meet the following exact requirements:
>>> http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t
>>> xt
>>>  and
>>> http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t
>>> xt
>>>
>>> for OSPF and IS-IS respectively.
>>>
>>> Thanks,
>>> Vishwas
>>>
>>> On 8/24/06, Paul Jakma <paul@clubi.ie> wrote:
>>>       
>>>> On Wed, 23 Aug 2006, Dave Katz wrote:
>>>>
>>>>         
>>>>> Sigh.  C'mon, folks, there is no problem.
>>>>>           
>>>>> 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.
>>>>>           
>>>> Strongly concur.
>>>>
>>>> There is though value in defining "MUST support" algos, otherwise poor
>>>> users could be faced with having routers which all implement OSPF but
>>>> can be made to interoperate unless authentication is left
>>>> unconfigured.
>>>>
>>>> MD5 at least should be defined as a MUST support.
>>>>
>>>> (Despite the pre-image weaknesses, it's still not yet completely
>>>>   insecure in MAC mode)
>>>>
>>>> regards,
>>>> --
>>>> Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A
>>>>         
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>
>>>
>>>       
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ospf
>>     
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf
>
>   

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf