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