Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

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.

	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