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

[Loa Andersson <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> 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:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:* Sunday, May 25, 2014 1:50 PM
>         *To:* Yaron Sheffer
>         *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF
>
>         Security Directorate;
>         [e-mail]
>         <mailto:[e-mail]>__;
>         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
>         <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>__>
>         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
>             <[e-mail]
>             <mailto:[e-mail]>
>             <mailto:stephen.farrell@cs.__tcd.ie
>             <mailto:[e-mail]>>> 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:[e-mail] <mailto:[e-mail]>
>                         <mailto:[e-mail] <mailto:[e-mail]>>]
>
>                         Sent: Wednesday, May 21, 2014 4:29 PM To: Manav
>                         Bhatia; Stephen
>                         Farrell Cc: Bhatia, Manav (Manav); IETF Security
>                         Directorate; The
>                         IESG;
>                         [e-mail]
>                         <mailto:[e-mail]>
>
>         <mailto:[e-mail]
>         <mailto:[e-mail]>__>;
>
>                         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:[e-mail]>
>                                                 <mailto:stephen.farrell@cs.__tcd.ie
>                                                 <mailto:[e-mail]>>]
>                                                 Sent:
>
>         Wednesday, May
>
>                                                 21, 2014 2:53 AM To:
>                                                 Bhatia, Manav (Manav); IETF
>                                                 Security Directorate;
>                                                 The IESG; draft-
>                                                 [e-mail]
>                                                 <mailto:[e-mail]>
>
>         <mailto:[e-mail]
>         <mailto:[e-mail]>__> Cc:
>
>                                                 Yaron
>                                                 Sheffer;[e-mail]
>                                                 <mailto:[e-mail]>
>                                                 <mailto:[e-mail]
>                                                 <mailto:[e-mail]>>
>                                                 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:[e-mail]
>                         <mailto:[e-mail]>
>                         <mailto:[e-mail]
>                         <mailto:[e-mail]>>
>                         Senior MPLS [e-mail]
>                         <mailto:[e-mail]> <mailto:[e-mail]
>                         <mailto:[e-mail]>> Huawei
>                         Technologies (consultant)     phone:[phone]
>                         21 64 <tel:%2B46%20739%2081%2021%2064>
>                         <tel:%2B46%20739%2081%2021%__2064>
>
>
>                 _________________________________________________
>                 secdir mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>
>
>                 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
>             [e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>
>             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: [e-mail]
>     <mailto:[e-mail]>
>     Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>     Huawei Technologies (consultant)     phone: [phone]
>     <tel:%2B46%20739%2081%2021%2064>
>
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]