Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

Uri Blumenthal <uri@MIT.EDU> Wed, 21 May 2014 13:28 UTC

Return-Path: <uri@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E611A067C; Wed, 21 May 2014 06:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level:
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyoHHt-FY5PI; Wed, 21 May 2014 06:28:14 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id B2E1A1A0665; Wed, 21 May 2014 06:28:12 -0700 (PDT)
X-AuditID: 12074422-f79376d000000c58-33-537ca9eb8997
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 93.CF.03160.BE9AC735; Wed, 21 May 2014 09:28:11 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s4LDS8aj030133; Wed, 21 May 2014 09:28:08 -0400
Received: from [192.168.1.112] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4LDS1sQ032343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 May 2014 09:28:03 -0400
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Uri Blumenthal <uri@MIT.EDU>
In-Reply-To: <537CA2D2.4070103@cs.tcd.ie>
Date: Wed, 21 May 2014 09:28:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu>
References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <CAG1kdogiEJp=jy5D+tvXnAZ2XD0Xe1=kB-do_=h4PU1V9j7KKQ@mail.gmail.com> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1878.2)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixG6novt6ZU2wwYfdMhZ3z29ks5jxZyKz xb+5c5gt5ty7x2pxeVIbu8WHhQ9ZLKbvvcbuwO7R+mwvq8fa7qtsHjtn3WX3WLLkJ5PHrOlt bB5fLn9mC2CL4rJJSc3JLEst0rdL4MrY+u4Oa8Ec84rNu0sbGB/pdDFyckgImEic7FnDBmGL SVy4tx7I5uIQEpjNJDHv/TlmCGcjo8TatrVMEM4+Jom2CXfBWpgF9CR2XP/FCmLzChhIXOtf zwhiCwv4S6za28AMYrMJKEk0N28Bq+EU0JQ4e/wgUJyDg0VAVeLlq0CQmcwC15kknh35CTVT W2LZwtfMEDOtJDZtvssCsfgmi8TK5uVgC0QE9CX2bj7HDnG3vMSM9hPsExgFZyG5aRaSm2Yh mbuAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrqlebmaJXmpK6SZGcHS4KO1g/HlQ6RCjAAej Eg/vgqLqYCHWxLLiytxDjJIcTEqivBOX1gQL8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE1ngqU 401JrKxKLcqHSUlzsCiJ8761tgoWEkhPLEnNTk0tSC2CycpwcChJ8AqtAGoULEpNT61Iy8wp QUgzcXCCDOcBGq4MUsNbXJCYW5yZDpE/xajLcW7OqTYmIZa8/LxUKXHeN8uAigRAijJK8+Dm wJLaK0ZxoLeEeZ1ARvEAEyLcpFdAS5iAlvxdXAmypCQRISXVwJicw8B2SGdTYmqo5YfpVQc5 fM6sCznwqZeR7az4eh1DbVEfoaT1p9hvHZ3iY/SU49KUnkWrf1fqWlc82fL7lvoP2fW8U52U f9y2r3H5lLpfI2VC8t0ujm+hutm/hP+d5LDorXZP0T5g0rK49uvr3W61HCfPf9vVplLd+qfj w9wFioHfFxUmaCixFGckGmoxFxUnAgDWxjQARQMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fuFVaUbdv3EISbdmGUCx47Jf8xE
Cc: "Bhatia, Manav \(Manav\)" <manav.bhatia@alcatel-lucent.com>, IETF Security Directorate <secdir@ietf.org>, "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" <draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>, The IESG <iesg@ietf.org>, Manav Bhatia <manavbhatia@gmail.com>, Loa Andersson <loa@pi.nu>
Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 13:28:16 -0000

Once again, please.

1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for security reasons (and therefore is not secure as-is)?

2. What are those security reasons, and what are the attacks that are foiled by Apad?

3. What published papers/references/whatever is this documented? As HMAC came with security proofs, I’d like to see where and how they are invalidated (if they indeed are).



On May 21, 2014, at 8:57 , Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> 
> On 21/05/14 12:14, Bhatia, Manav (Manav) wrote:
>> I agree with Loa.
>> 
>> Our current draft is very simple and has gone through multiple
>> iterations of reviews in at least two WGs. It brings LDP to the same
>> level of security as other protocols running in the networks.
> 
> Fully agree with that goal.
> 
>> 
>> I think we should just push it forward and if there is an interest in
>> writing a new ID that updates HMAC specification, then we write one
>> that includes the Apad stuff. I think the latter should anyways be
>> done, regardless of what happens to this particular draft.
> 
> I need to read it. But I'd be happier if that HMAC draft existed
> and was going to be processed - then we wouldn't have to do this
> discussion again.
> 
> Cheers,
> S.
> 
>> 
>> The IETF submission site is down and hence couldn’t upload the
>> revised ID (addressing Yaron's comments). Will do it tomorrow once
>> its up.
>> 
>> After that its ready to be placed before the IESG.
>> 
>> Cheers, Manav
>> 
>>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] 
>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen
>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The
>>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org;
>>> Yaron Sheffer Subject: Re: SecDir review of
>>> draft-ietf-mpls-ldp-hello-crypto-auth-05
>>> 
>>> Folks,
>>> 
>>> I'm only the document shepherd. My feeling is that we are raising 
>>> the hurdle step by step for the KARP - initiated RFCs, the first 
>>> was comparatively smooth, now we are trying to put an 18 months 
>>> effort (individual draft to RFC) in front of approving something 
>>> that is comparatively simple and seen as raising LDP to the same 
>>> security as the other routing protocols.
>>> 
>>> So if we get to tired to push this, we are all better off not
>>> doing the security work for this particular protocol?
>>> 
>>> Someone said - "Never let the best be the enemy of the possible"!
>>> 
>>> /Loa
>>> 
>>> 
>>> 
>>> On 2014-05-21 12:39, Manav Bhatia wrote:
>>>> Stephen,
>>>> 
>>>>>> This however is a long drawn discussion because everyone
>>>>>> needs to
>>> be
>>>>>> convinced on the merits of updating the HMAC specification --
>>>>>> which
>>> I
>>>>>> am not sure will take how long.
>>>>> 
>>>>> So I need to look at this draft, HMAC and the other cases but 
>>>>> it seems to me that you're copying a page or two of crypto spec
>>>>> each time and changing one line. Doing that over and over is a
>>>>> recipe for long term pain, isn't it?
>>>> 
>>>> It sure is.
>>>> 
>>>> I had volunteered to write a 1-2 page long ID that updated the
>>>> HMAC
>>> to
>>>> include the Apad, but the idea was shot down. The only
>>>> alternative left was to include the crypto stuff in each standard
>>>> that we wrote later.
>>>> 
>>>>> 
>>>>> (And we've had this discussion for each such draft while I've 
>>>>> been on the IESG I think, which is also somewhat drawn out;-)
>>>> 
>>>> This draft is probably the last one thats coming from the Routing
>>>> WG which will have this level of crypto mathematics spelled out.
>>>> All other IGPs are already covered. In case we need to change
>>>> something
>>> in
>>>> the ones already covered we can refer to the base RFC where we
>>>> have detailed the crypto maths. For example, 
>>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst
>>>> other things also updates the definition of Apad. It points to
>>>> the exact mathematics in RFC 5709 and only updates the Apad
>>>> definition in that draft. This draft btw has cleared the WG LC
>>>> and would be appearing before you guys very soon.
>>>> 
>>>> Given this, i think we should just pass this draft with this
>>>> level of details. Subsequently, when LDP wants to update
>>>> something, it can normatively refer to this RFC and only give the
>>>> changes.
>>>> 
>>>> Cheers, Manav
>>>> 
>>>>> 
>>>>> S.
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Cheers, Manav
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> S
>>>>>>> 
>>>>>>>> 
>>>>>>>> Cheers, Manav
>>>>>>>> 
>>>>>>>>> -----Original Message----- From: Stephen Farrell 
>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May
>>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF
>>>>>>>>> Security Directorate; The IESG; draft- 
>>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc:
>>>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re:
>>>>>>>>> SecDir review of 
>>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely
>>>>>>>>>>>> bad idea. This reviewer does not have the
>>>>>>>>>>>> appropriate background to critique the proposed
>>>>>>>>>>>> solution, but there must be an overwhelming
>>>>>>>>>>>> reason to
>>>>>>>>> reopen> >>>>> cryptographic primitives.
>>>>>>>>>>> 
>>>>>>>>>>> This is a decision that was taken by Sec Ads when
>>>>>>>>>>> we were doing the crypto protection for the IGPs
>>>>>>>>>>> based on some feedback from NIST.
>>>>>>>>> This
>>>>>>>>>>> mathematics is not new and has been done for all
>>>>>>>>>>> IGPs and has been approved and rather encouraged by
>>>>>>>>>>> the Security ADs.
>>>>>>>>> 
>>>>>>>>> The above does not sound like something I recognise. I
>>>>>>>>> have repeatedly asked that documents not re-define
>>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and
>>>>>>>>> not budge. I probably should have done that before
>>>>>>>>> TBH.
>>>>>>>>> 
>>>>>>>>> If you are revising that doc, *please* get rid of the 
>>>>>>>>> re-definition and just properly refer to HMAC. Its
>>>>>>>>> about time to stop repeating that error.
>>>>>>>>> 
>>>>>>>>> S.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>>> --
>>> 
>>> 
>>> Loa Andersson                        email: loa@mail01.huawei.com 
>>> Senior MPLS Expert                          loa@pi.nu Huawei
>>> Technologies (consultant)     phone: +46 739 81 21 64
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview