Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

["Vishwas Manral" <[e-mail]>]

Erblichs,

If you read RFC4305, the implementation requirements have and must be changed.

   The implementation requirements are compared below:

   Old   Old         New
   Req.  RFC(s)      Requirement  Algorithm (notes)
   ---   ------      -----------  ---------
   MUST  2406        SHOULD NOT   DES-CBC [RFC2405] (1)
   MUST  2402 2406   MAY          HMAC-MD5-96 [RFC2403]
   MUST  2402 2406   MUST         HMAC-SHA1-96 [RFC2404]

We expect the same for all protocols utilizing the crypto algorithms.

Thanks,
Vishwas

On 8/29/06, Erblichs <[e-mail]> 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.
>
>         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 <[e-mail]> 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:[e-mail]]
> > > Sent: Thursday, August 24, 2006 10:24 AM
> > > To: [e-mail]
> > > Cc: [e-mail]; 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 <[e-mail]> 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      [e-mail]   [e-mail]  Key ID: 64A2FF6A
> > >
> > > _______________________________________________
> > > OSPF mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/ospf
> > >
> > >
> >
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ospf
>

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf