Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
Loa Andersson <loa@pi.nu> Wed, 28 May 2014 07:06 UTC
Return-Path: <loa@pi.nu>
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 DCFEC1A0816; Wed, 28 May 2014 00:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 s5AhvAbOHan8; Wed, 28 May 2014 00:06:01 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633BB1A0814; Wed, 28 May 2014 00:06:01 -0700 (PDT)
Received: from [192.168.1.8] (unknown [119.94.254.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D3A8418013DA; Wed, 28 May 2014 09:05:53 +0200 (CEST)
Message-ID: <53858ACE.8030909@pi.nu>
Date: Wed, 28 May 2014 09:05:50 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Vero Zheng <vero.zheng@huawei.com>, Manav Bhatia <manavbhatia@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>
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> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> <CAG1kdoj=VpE_EJc1zB=50eTsr=44Jr4yUc3BZVH2QpLJMR6mHQ@mail.gmail.com> <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com>
In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0Wx9LMM4A348oc1W1sOVCaPdf2M
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>
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, 28 May 2014 07:06:04 -0000
All, Do I understand correctly if we are now OK to go ahead and have this draft approved? /Loa On 2014-05-26 03:30, Vero Zheng wrote: > Thanks Yaron and Manav for working this out. > > I have just confirmed the post. > > Cheers, Vero > > *From:*Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Sunday, May 25, 2014 1:50 PM > *To:* Yaron Sheffer > *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF > Security Directorate; > draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; The IESG; Loa > Andersson > *Subject:* Re: [secdir] SecDir review of > draft-ietf-mpls-ldp-hello-crypto-auth-05 > > Hi, > > Yaron, I and few of us exchanged quite a few emails offline and we have > come up with a version that addresses Yaron's and Stephen's concerns > about repeating the HMAC stuff thats already present in RFC 2104. We've > cleaned it up pretty nicely with very minimal changes. > > I am unable to submit this latest and the greatest version since i have > updated my email ID in this version. The tracker requires one of the > co-authors to authenticate/approve the submission. > > I am attaching the latest version with this email in case folks want to > go through this till it becomes available formally. > > The draft is all set to fly now! :-) > > Cheers, Manav > > On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer <yaronf.ietf@gmail.com > <mailto:yaronf.ietf@gmail.com>> wrote: > > IMHO, this is purely a naming problem. Apad does NOT modify the base > HMAC, please see > http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05#section-5. > It is just one more thing that's signed by HMAC. > > My problem with this draft is that they have different ideas about the > key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy > that they spell out the HMAC construction instead of leaving it as a > black box. > > But I think Apad is just fine, if it weren't for the unfortunate name > that leads people to think it's modifying HMAC. > > Thanks, > Yaron > > > On 05/21/2014 04:28 PM, Uri Blumenthal wrote: > >> 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 <mailto: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 <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 > <mailto: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 <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 > <mailto:ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org> Cc: >>>>>>>>>>> Yaron Sheffer;manavbhatia@gmail.com <mailto: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 <mailto:loa@mail01.huawei.com> >>>>> Senior MPLS Expertloa@pi.nu <mailto:loa@pi.nu> Huawei >>>>> Technologies (consultant) phone:+46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064> >>> >>> _______________________________________________ >>> secdir mailing list >>>secdir@ietf.org <mailto:secdir@ietf.org> >>>https://www.ietf.org/mailman/listinfo/secdir >>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> >> _______________________________________________ >> secdir mailing list >>secdir@ietf.org <mailto:secdir@ietf.org> >>https://www.ietf.org/mailman/listinfo/secdir >> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
- [secdir] SecDir review of draft-ietf-mpls-ldp-hel… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Uri Blumenthal
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Ross Callon
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Loa Andersson
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Uri Blumenthal
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Barry Leiba
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Barry Leiba
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Bhatia, Manav (Manav)
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Manav Bhatia
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Loa Andersson
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Uri Blumenthal
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Loa Andersson
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Barry Leiba
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Manav Bhatia
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Vero Zheng
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Loa Andersson
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Manav Bhatia
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Loa Andersson
- Re: [secdir] SecDir review of draft-ietf-mpls-ldp… Manav Bhatia