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

[Manav Bhatia <[e-mail]>]

Yup, thats correct!


On Wed, May 28, 2014 at 12:35 PM, Loa Andersson <[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]]
>> *Sent:* Sunday, May 25, 2014 1:50 PM
>> *To:* Yaron Sheffer
>> *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF
>>
>> Security Directorate;
>> [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]>> 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]<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]>]
>>>>>>
>>>>>> 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]>;
>>
>>> 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] <mailto:stephen.farrell@cs.
>>>>>>>>>>>> tcd.ie>] Sent:
>>>>>>>>>>>>
>>>>>>>>>>> Wednesday, May
>>
>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF
>>>>>>>>>>>> Security Directorate; The IESG; draft-
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>
>>>>>>>>>>> <mailto:[e-mail]> Cc:
>>
>>> Yaron Sheffer;[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]>
>>>>>> Senior MPLS [e-mail] <mailto:[e-mail]> Huawei
>>>>>> Technologies (consultant)     phone:[phone]<tel:%2B46%20739%2081%2021%
>>>>>> 2064>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> secdir mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>>
>>>
>>> _______________________________________________
>>> secdir mailing list
>>> [e-mail] <mailto:[e-mail]>
>>>
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>
>>>
>>
> --
>
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
>