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

Manav Bhatia <manavbhatia@gmail.com> Wed, 28 May 2014 07:21 UTC

Return-Path: <manavbhatia@gmail.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 196411A0814; Wed, 28 May 2014 00:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9YrBON42mnCF; Wed, 28 May 2014 00:21:06 -0700 (PDT)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D77C1A03B7; Wed, 28 May 2014 00:21:06 -0700 (PDT)
Received: by mail-ob0-f178.google.com with SMTP id va2so10433279obc.23 for <multiple recipients>; Wed, 28 May 2014 00:21:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FAiLCH+fZ3owGNb97iGGiYgd/L4XO+tZqxajfHjuzvM=; b=jcZV98tCxU1CP5oviBv65kfurGFFo4cdoSKzS/xkWW5lpyFGaguh5b7EpEMsGN4B4Q eD0ejtNp0c2ZWHtC7rmjLFr1BHHSKzbHuNbjE9VwK9uUL6iProhmLiqRblclCjlvrmkj CVTJvHO3r8W0vQCnjUEuyoWBqsQJmZ5TcFY4JZEFGyzQio0KNqfKnM8s01Fy3oL+O2Yh INVbZu4BySXhHe3ARnDU0dxc5xeLrAYRafc5VGAijSnytY6YRVkloMwL42MotLKGi/yR pHu2JJZ/2OKDS0xDjZ5F/jf0luNORNaOLToTlt9xZpbENsonb5UBlLAFNkfUfzDTqKCx wEOA==
MIME-Version: 1.0
X-Received: by 10.60.143.37 with SMTP id sb5mr29891692oeb.38.1401261662930; Wed, 28 May 2014 00:21:02 -0700 (PDT)
Received: by 10.76.77.97 with HTTP; Wed, 28 May 2014 00:21:02 -0700 (PDT)
In-Reply-To: <e4d37c4da6354631b8c6b113d46a23f0@SG70XWXCHHUB02.zap.alcatel-lucent.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> <53858ACE.8030909@pi.nu> <CAG1kdoidVWx2i_TEsBtvDCVPq99_ZpnNkY59GPi-=RHfzrO0wQ@mail.gmail.com> <e4d37c4da6354631b8c6b113d46a23f0@SG70XWXCHHUB02.zap.alcatel-lucent.com>
Date: Wed, 28 May 2014 12:51:02 +0530
Message-ID: <CAG1kdogcFnTd6U9CW0N-smx-97uD+1JAeW6ZGBGFRpsLUEZfQg@mail.gmail.com>
From: Manav Bhatia <manavbhatia@gmail.com>
To: Loa Andersson <loa@pi.nu>
Content-Type: multipart/alternative; boundary=047d7b3a81a0a82d5b04fa70a761
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QrejPhqDSVQZCD64yfOgsQhgAFU
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>, Vero Zheng <vero.zheng@huawei.com>
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:21:11 -0000

Hi Loa,

We dont need to. The changes are only editorial in nature.

Cheers, Manav


On Wed, May 28, 2014 at 12:43 PM, Loa Andersson <loa@pi.nu> wrote:

> Folks,
>
> This is not entirely scientific, but based on the diff's bwetween
> version -04 and -06, does to me not indicate that the changes are
> such that we need to take the draft back to the wg for a new wglc.
>
> Unless the responsible AD or my co-chairs speaks up and have a
> different opinion, it is my opinion that we now should move this
> draft ahead.
>
> /Loa
>
> On 2014-05-28 09:06, Manav Bhatia wrote:
> > Yup, thats correct!
> >
> >
> > On Wed, May 28, 2014 at 12:35 PM, Loa Andersson <loa@pi.nu
> > <mailto:loa@pi.nu>> wrote:
> >
> >     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
> >         <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
> >         <mailto: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>
> >         <mailto: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
> >         <
> 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>
> >             <mailto: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>
> >                         <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:
> draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>
> >
> >         <mailto: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>
> >                                                 <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>
> >
> >         <mailto: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:
> Sheffer%3Bmanavbhatia@gmail.com>
> >                                                 <mailto:
> 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:email%3Aloa@mail01.huawei.com>
> >                         <mailto:loa@mail01.huawei.com
> >                         <mailto:loa@mail01.huawei.com>>
> >                         Senior MPLS Expertloa@pi.nu
> >                         <mailto:Expertloa@pi.nu> <mailto:loa@pi.nu
> >                         <mailto:loa@pi.nu>> Huawei
> >                         Technologies (consultant)     phone:+46 739 81
> >                         21 64 <tel:%2B46%20739%2081%2021%2064>
> >                         <tel:%2B46%20739%2081%2021%__2064>
> >
> >
> >                 _________________________________________________
> >                 secdir mailing list
> >                 secdir@ietf.org <mailto:secdir@ietf.org>
> >                 <mailto:secdir@ietf.org <mailto:secdir@ietf.org>>
> >
> >                 https://www.ietf.org/mailman/__listinfo/secdir
> >                 <https://www.ietf.org/mailman/listinfo/secdir>
> >                 wiki:
> http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview
> >                 <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>
> >
> >
> >             _________________________________________________
> >             secdir mailing list
> >             secdir@ietf.org <mailto:secdir@ietf.org>
> >             <mailto:secdir@ietf.org <mailto:secdir@ietf.org>>
> >
> >             https://www.ietf.org/mailman/__listinfo/secdir
> >             <https://www.ietf.org/mailman/listinfo/secdir>
> >             wiki:
> http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview
> >             <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>
> >
> >
> >
> >     --
> >
> >
> >     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>
> >
> >
>
> --
>
>
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>