Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft
"Tom Sanders" <toms.sanders@gmail.com> Tue, 29 August 2006 15:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5zJ-0004yX-VQ; Tue, 29 Aug 2006 11:58:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5zI-0004wJ-4G for ospf@ietf.org; Tue, 29 Aug 2006 11:58:52 -0400
Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI5zH-0000Ox-P3 for ospf@ietf.org; Tue, 29 Aug 2006 11:58:52 -0400
Received: by py-out-1112.google.com with SMTP id e30so1347166pya for <ospf@ietf.org>; Tue, 29 Aug 2006 08:58:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JXI5ojcuXqrk2HGdIlskby9MeH0l462Y4rRsRaovKqgACNR4Saamf3cKNJ8pqLjsAEtKNxP849gGEO17kREeJfJROM49VATFUtGU9wdechxComMJ+pEe5BcOxeeM42UVZfxEcl9w/EhWyGQ0IPZ5W2dC3vuM05Ed6gyZa4aY9VY=
Received: by 10.35.127.7 with SMTP id e7mr15176078pyn; Tue, 29 Aug 2006 08:58:51 -0700 (PDT)
Received: by 10.35.128.10 with HTTP; Tue, 29 Aug 2006 08:58:51 -0700 (PDT)
Message-ID: <6ed23a860608290858g201e84f4pc0a5b757053a5f44@mail.gmail.com>
Date: Tue, 29 Aug 2006 21:28:51 +0530
From: Tom Sanders <toms.sanders@gmail.com>
To: Erblichs <erblichs@earthlink.net>
Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft
In-Reply-To: <44F34E34.5CFD81A4@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> <77ead0ec0608280318p1b73e218v8bca87253ae30933@mail.gmail.com> <44F34E34.5CFD81A4@earthlink.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Cc: ospf@ietf.org, paul@jakma.org, Mailing List <OSPF@peach.ease.lsoft.com>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org
Erblichs, I am not sure if Vishwas addressed your concern. If he did, then i am at fault in understanding your concern. However, let me give it a shot. > 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 > -- Toms. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf
- [OSPF] Revised OSPF HMAC SHA Authentication Draft Vishwas Manral
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Erblichs
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Manav Bhatia
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Erblichs
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Manav Bhatia
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Phil Cowburn
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Acee Lindem
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Phil Cowburn
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… tom.petch
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Tom Sanders
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Manav Bhatia
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Tom Sanders
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Michael J Barnes
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Acee Lindem
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Russ White
- RE: [OSPF] Revised OSPF HMAC SHA Authentication D… sujay
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Manav Bhatia
- RE: [OSPF] Revised OSPF HMAC SHA Authentication D… Manav Bhatia
- RE: [OSPF] Revised OSPF HMAC SHA Authentication D… sujay
- RE: [OSPF] Revised OSPF HMAC SHA Authentication D… sujay
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Dave Katz
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Paul Jakma
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Vishwas Manral
- RE: [OSPF] Revised OSPF HMAC SHA Authentication D… sujay
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Vishwas Manral
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Erblichs
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Vishwas Manral
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Tom Sanders
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Tom Sanders
- Re: [OSPF] Revised OSPF HMAC SHA Authentication D… Acee Lindem