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

[Manav Bhatia <[e-mail]>]

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]>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 <[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]]
> >>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen
> >>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The
> >>>> IESG; draft- [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:[e-mail]] Sent: Wednesday, May
> >>>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF
> >>>>>>>>>> Security Directorate; The IESG; draft-
> >>>>>>>>>> [e-mail] Cc:
> >>>>>>>>>> Yaron Sheffer; [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]
> >>>> Senior MPLS Expert                          [e-mail] Huawei
> >>>> Technologies (consultant)     phone: [phone]
> >>
> >> _______________________________________________
> >> secdir mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/secdir
> >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> >
> > _______________________________________________
> > secdir mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/secdir
> > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> >
>