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

Vero Zheng <vero.zheng@huawei.com> Mon, 26 May 2014 01:30 UTC

Return-Path: <vero.zheng@huawei.com>
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 517951A0418; Sun, 25 May 2014 18:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.151
X-Spam-Level:
X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 WMezzsRTad5z; Sun, 25 May 2014 18:30:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C141A0416; Sun, 25 May 2014 18:30:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEN23558; Mon, 26 May 2014 01:30:11 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 02:29:49 +0100
Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 02:30:08 +0100
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.103]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 26 May 2014 09:30:05 +0800
From: Vero Zheng <vero.zheng@huawei.com>
To: Manav Bhatia <manavbhatia@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
Thread-Index: AQHPd90r0DS+N+7Z9EeeVC8ahSnwZptSFBaQ
Date: Mon, 26 May 2014 01:30:05 +0000
Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.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>
In-Reply-To: <CAG1kdoj=VpE_EJc1zB=50eTsr=44Jr4yUc3BZVH2QpLJMR6mHQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.115]
Content-Type: multipart/alternative; boundary="_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OmEtp2gOVboW6spRKrJsUesuQZ4
X-Mailman-Approved-At: Mon, 26 May 2014 00:40:48 -0700
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>, 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: Mon, 26 May 2014 01:30:22 -0000

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 Expert                          loa@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
>