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

[Uri Blumenthal <[e-mail]>]

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