Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

"Tom Sanders" <toms.sanders@gmail.com> Tue, 29 August 2006 16:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI688-0003aj-2l; Tue, 29 Aug 2006 12:08:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI686-0003ad-Pg for ospf@ietf.org; Tue, 29 Aug 2006 12:07:58 -0400
Received: from nz-out-0102.google.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI684-0002RI-Hs for ospf@ietf.org; Tue, 29 Aug 2006 12:07:58 -0400
Received: by nz-out-0102.google.com with SMTP id q3so1347643nzb for <ospf@ietf.org>; Tue, 29 Aug 2006 09:07:56 -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=AUCV31b/z4rQvhKDKkQocJqetbcUZB48jZjrjdnEu0jfbTLbQxCd4HzCwCarwNJ61h6n3bGs2HYezy4Jw2USgGi6uNEQgOJDEEC4Pi347+R+aX1Dd+n2qGrvSS2DOG/C/J/TkINzn69aGfinQnIGNyxgiApd9QS7q4moF16Hdsc=
Received: by 10.35.87.8 with SMTP id p8mr15213166pyl; Tue, 29 Aug 2006 09:07:56 -0700 (PDT)
Received: by 10.35.128.10 with HTTP; Tue, 29 Aug 2006 09:07:55 -0700 (PDT)
Message-ID: <6ed23a860608290907w7c8a118at95341eda10f0debe@mail.gmail.com>
Date: Tue, 29 Aug 2006 21:37:55 +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: <6ed23a860608290858g201e84f4pc0a5b757053a5f44@mail.gmail.com>
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> <6ed23a860608290858g201e84f4pc0a5b757053a5f44@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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

Sorry .. I sent an incomplete mail .. ;)

On 29/08/06, Tom Sanders <toms.sanders@gmail.com> wrote:
> 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.

I assume you are at this point referring to
draft-bhatia-manral-white-ospf-hmac-sha-02.txt. Lets not rehash the
same discussion regarding overloading Auth 2 here.

> >
> >        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.

Which is where the draft-bhatia-manral-crypto-req-ospf-00.txt helps.
The authors can correct me if i am wrong in my understanding here.

> >
> >          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?

MD5 is MUST- while HMAC-SHA-1 is SHOULD+.

I think the definitions in the beginning of the draft would help.
Reading those again tells me that we may at some later point deprecate
MD5 and mandate support for hmac-sha-1 for all the implementations.

hmac-sha-1 would then be a MUST and the other higher variants of
hmac-sha SHOULD+.

Toms.

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