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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 16 May 2014 17:05:24 +0300

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document proposes to add cryptographic authentication to LDP "all
routers" Hello messages, which are transported as unicast UDP.

Summary

The document may be ready to publish, but this reviewer has major
issues with the selected solution.

Details

• The main issue is that only a symmetric crypto option is defined.
IMHO, adding a public-key based scheme would be invaluable. Public keys
do not necessarily imply certificates, and can be used with little added
complexity compared to the current proposal. As far as I can see, the 
current use is not so performance constrained to preclude public key 
operations. And public keys would enable much easier and more secure 
deployment in many cases:
	∘ Different organizations can accept messages from one another, without 
needing to share the same keys. So even if groups keys are used (which 
is certainly not the best practice), public keys have an advantage.
	∘ Revocation is much simpler: to be able to revoke each individual 
sender (e.g. when a router is decomissioned), you need N**2 SAs in the 
symmetric case, vs. N keys when public keys are used.
• Managing the 32-bit SAID manually in a large network is extremely 
onerous. So in practice keys would be rarely on never changed.

• 2.2: the authentication algorithm and the authentication key are not
"independent", because the algorithm normally determines the key length.

• 2.2: the various time values included in the SA essentially require
(rough) time synchronization between the nodes. If this is the case, 
time values could have been used for replay protection, which would have 
been much simpler to implement than the 64-bit sequence number which 
needs to persist across reboots.

• 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.

• 7: 128-bit keys are OK (or overkill) for some algorithms, but too
short for others. In general, the recommended key length is not
constant. It depends on the algorithm.

• "The mechanism described herein is not perfect and does not need to be
perfect." This is kind of vague, and would be better replaced by your
security goals.

Thanks,
	Yaron

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 16 May 2014 10:43:03 -0400

Quoting Yaron Sheffer <[email-masked]>:
> .......

They do seem to be using HMAC, even though without explicitly naming it 
so (5.1
and 5.2). Also, HMAC is referred to in the Normative References.

> perfect." This is kind of vague, and would be better replaced by your

Concur. :-)

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 16 May 2014 19:35:39 +0300

> and 5.2). Also, HMAC is referred to in the Normative References.

Yes, of course. But then they argue with the standard definition, "While 
[RFC2104] supports a key that is up to B octets long, this application 
uses L as the Ks length consistent with [...]". And then instead of 
using it like a black box, they spell it out in 5.2, so developers are 
encouraged to re-implement HMAC instead of using one of dozens of 
existing implementations.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 19 May 2014 00:17:04 +0000

Hi Yaron,

Thanks for the comments. My comments inline.

> symmetric case, vs. N keys when public keys are used.

The idea behind this draft is to bring LDP HELLO's security to at least the same level as the routing protocols running in the same networks today. All IGPs are currently using a symmetric crypto option and we think it is ok at this point in time to continue with the same for LDP.

With SDN principles its possible that the key distribution becomes quite simple with a central controller distributing the keys to all the nodes in the network along with the other information. This also seems to be one of the thoughts behind not pursuing an automated key management protocol for IGPs (something that we were supposed to take up as part of the Phase 2 in the KARP WG -- you can look at RFC 6518 for more details).

Given this I would like to continue with what we have and look at other mechanisms once we have more clarity on the direction which we seem to be heading towards.

Also finally note that this security is always within a providers network -- there isnt a need to involve different organizations.

> onerous. So in practice keys would be rarely on never changed.

Ok, so whats the point?

> "independent", because the algorithm normally determines the key

This is nit-picking and sure we can remove the word "independent". When defining the Authentication Key we do mention that it depends on the algo.

Authentication Key

      This value denotes the cryptographic authentication key associated
      with the LDP SA.  The length of this key is variable and depends
      upon the authentication algorithm specified by the LDP SA.

> needs to persist across reboots.

The various timers are only associated if somebody wants to rollover the keys. The granularity of these timers can be coarse (implementation specific) and will not be secure enough to use for anti replay protection.

Moreover, without the 64 bit sequence numbers, its very difficult to protect against inter-session replay attacks (RFC 6862)

> 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.

> constant. It depends on the algorithm.

This needs to be punched on each router console. For an internal network, do you think 128 bit isnt good enough?
> perfect." This is kind of vague, and would be better replaced by your

I think we can just delete this! :-)

Cheers, Manav

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 19 May 2014 23:27:56 +0300

Hi Manav, thanks for your response. Please see clarifications below.

	Yaron

> Also finally note that this security is always within a providers network -- there isnt a need to involve different organizations.

I understand the statement "we do not know where we're going, so let's 
not over-design now". But note that even with SDN and even with a key 
management protocol, public keys have an advantage over symmetric keys 
for this scenario. And if you have automated key 
management/distribution, the simplicity of symmetric keys actually 
becomes less important.

>> onerous. So in practice keys would be rarely on never changed.

That you need automated key management, otherwise this mechanism is an 
overkill.

> This is nit-picking and sure we can remove the word "independent". When defining the Authentication Key we do mention that it depends on the algo.

Sure, this is a nit.

>        upon the authentication algorithm specified by the LDP SA.

Good.

> The various timers are only associated if somebody wants to rollover the keys. The granularity of these timers can be coarse (implementation specific) and will not be secure enough to use for anti…

Note that the timer values are optional (the draft says they can be left 
"unspecified"), but the draft doesn't say what value should be in the 
field if the values are to be omitted. I *guess* it should be "0", 
please clarify it.

> Moreover, without the 64 bit sequence numbers, its very difficult to protect against inter-session replay attacks (RFC 6862)

That really depends on what data is signed by the key. But I see your point.

> 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 h…

Then I guess I disagree, but I am not familiar with the background for 
this decision.

> This needs to be punched on each router console. For an internal network, do you think 128 bit isnt good enough?

Personally, I think 128 bits are great :-) Seriously, if people are 
using HMAC-SHA-512 then 128 is not appropriate. You can argue that you 
don't need more than 128 bits of entropy, but then I would suggest to 
remove SHA-512 from the draft. The general point is that different 
algorithms require different key lengths.

> I think we can just delete this! :-)

Please do.

---

From: Ross Callon <[email-masked]>
Date: Mon, 19 May 2014 20:59:57 +0000

I have what may be a slightly ignorant question, but...

When I looked at automated key management protocols many years ago, they worked between two systems (system A talks to system B). In particular, at some point multiple years ago the automated key management protocols did not work between many routers all talking to each other across a broadcast LAN, which for example might need to multicast routing traffic among themselves. 

Is this still true? 

Thanks, Ross

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Monday, May 19, 2014 4:28 PM
To: Bhatia, Manav (Manav); IETF Security Directorate; The IESG; [email-masked]
Cc: [email-masked]
Subject: Re: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

	Yaron

Sure, this is a nit.

Good.

Please do.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 20 May 2014 00:16:41 +0300

It hasn't been a great success (as far as I know), but msec 
(http://tools.ietf.org/wg/msec/) spent a lot of energy and published a 
lot of documents in this area. For example, RFC 4535.

Thanks,
	Yaron

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 20 May 2014 10:35:38 +0000

Hi Yaron,
 
> management/distribution, the simplicity of symmetric keys actually

As per the KARP design guide (RFC 6518) we were taking this up in the subsequent phases of KARP work life cycle. The Phase I initially updates all protocols with the latest algorithms and key agility (rollover). Anything beyond that is the next step.

What we're doing here is updating LDP with stronger algos and ensuring that keys can be easily rolled over without disrupting the protocol.

> That you need automated key management, otherwise this mechanism is an

Again, as per KARP design Phase I, we need to get all routing protocols to a certain minimum level. Redesigning the protocol for an automated key management protocol is Phase II.

> > The various timers are only associated if somebody wants to rollover
> the keys. The granularity of these timers can be coarse (implementation
> specific) and will not be secure enough to use for anti replay
> protection.
> 

We have the following text in the draft:

   In order to achieve smooth key transition, KeyStartAccept SHOULD be
   less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
   KeyStopAccept.  If KeyStartGenerate or KeyStartAccept are left
   unspecified, the time will default to 0 and the key will be used
   immediately.  If KeyStopGenerate or KeyStopAccept are left
   unspecified, the time will default to infinity and the key's lifetime
   will be infinite.

Can you suggest what else needs to be added to make it clearer?

> 
> >
> > Moreover, without the 64 bit sequence numbers, its very difficult to
> protect against inter-session replay attacks (RFC 6862)
> 

Goody.

> >
> > 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.
> >
> 

I am sure the Security and the Routing ADs can help you with the history. 

> > This needs to be punched on each router console. For an internal
> network, do you think 128 bit isnt good enough?
> 

I think you missed the text in Sec 5.1 which says:

   The LDP Cryptographic Protocol ID is appended to the Authentication
   Key (K) yielding a Protocol Specific Authentication Key (Ks).  In
   this application, Ko is always L octets long.  While [RFC2104]
   supports a key that is up to B octets long, this application uses L
   as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and
   [RFC7166].

In case of HMAC-SHA-512 the key size would be 512 bits.

We never restrict the key size to 128.

> 
> >>
> >> • "The mechanism described herein is not perfect and does not need
> to
> >> be

Consider it done.

Cheers, Manav

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 20 May 2014 23:36:57 +0300

Hi Manav,

> Hi Yaron,
[...]

> Can you suggest what else needs to be added to make it clearer?

I suggest to add: "Any unspecified values are encoded as zero."
[...]
> We never restrict the key size to 128.

I was referring to the following text, which I still think is misguided: 
"Deployments SHOULD use sufficiently long and random values for the 
Authentication Key so that guessing and other cryptographic attacks on 
the key are not feasible in their environments.  Furthermore, it is 
RECOMMENDED that Authentication Keys incorporate at least 128 
pseudo-random bits to minimize the risk of such attacks."

Crypto keys should have random bits amounting to their full length, 
rather than just a 128-bit subset of the key.

[...]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 May 2014 22:23:02 +0100

>> 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.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 May 2014 07:20:26 +0000

Hi Yaron,

> I suggest to add: "Any unspecified values are encoded as zero."

Sure, will do.

> >
> >>
> [...]
> >>
> >>>> * 7: 128-bit keys are OK (or overkill) for some algorithms, but
> too

Thanks for the catch. I agree, it doesn't make sense to use a subset of the key. Will remove this.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 May 2014 07:39:06 +0000

Hi Stephen,

The crypto mathematics in our draft (and RFC 5310, 5709, 6506, .. and quite a few other RFCs/drafts) is slightly different from the basic HMAC. In all these RFCs we've introduced an additional pad (unimaginatively called the "Apad") that's used in the hash computation. We were asked to include the Apad when we were originally writing the IS-IS and OSPFv2 security (RFC 5310 and 5709) RFCs. Ran Atkinson along with Mathhew Fanto (from NIST) had earlier written the RIPv2 RFC which had first employed the Apad. I was unequivocally told (by the Security ADs as well) that the Apad had to be included since that's what NIST wanted. I am sure Ran Atkinson can explain you more clearly about what the actual deal was. However, ever since then, we've been including the Apad in all our standards (at least the ones coming out of the Routing Area WG).

This has now been extensively implemented and there are libraries available that account for the Apad when computing the hash for the routing protocols.

The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason why LDP should be an exception. The same has been proposed for BFD btw.

Cheers, Manav

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2014 2:53 AM
> To: Bhatia, Manav (Manav); IETF Security Directorate; The IESG; draft-
> [email-masked]
> Cc: Yaron Sheffer; [email-masked]
> >>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 May 2014 08:54:54 +0100

Manav,

On 21/05/14 08:39, Bhatia, Manav (Manav) wrote:
> Hi Stephen,
> 
> The crypto mathematics in our draft (and RFC 5310, 5709, 6506, .. and
> quite a few other RFCs/drafts) is slightly different from the basic
> HMAC. In all these RFCs we've introduced an additional pad
> (unimaginatively called the "Apad") that's used in the hash
> computation. We were asked to include the Apad when we were
> originally writing the IS-IS and OSPFv2 security (RFC 5310 and 5709)
> RFCs. Ran Atkinson along with Mathhew Fanto (from NIST) had earlier
> written the RIPv2 RFC which had first employed the Apad. I was
> unequivocally told (by the Security ADs as well) that the Apad had to
> be included since that's what NIST wanted. I am sure Ran Atkinson can
> explain you more clearly about what the actual deal was. However,
> ever since then, we've been including the Apad in all our standards
> (at least the ones coming out of the Routing Area WG).
> 
> This has now been extensively implemented and there are libraries
> available that account for the Apad when computing the hash for the
> routing protocols.
> 
> The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason why
> LDP should be an exception. The same has been proposed for BFD btw.

Even given the above, I fail to see why you repeat this text over
and over and over. Is there a real logic for that?

S

> 
> Cheers, Manav
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Wednesday, May 21, 2014
>> 2:53 AM To: Bhatia, Manav (Manav); IETF Security Directorate; The
>> IESG; draft- [email-masked] Cc:
>> Yaron Sheffer; [email-masked] Subject: Re: SecDir review of
>> draft-ietf-mpls-ldp-hello-crypto-auth-05
>> 
>> 
>> 
>>>>> * 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
>>>> 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.
> 
> 
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 May 2014 08:07:46 +0000

Stephen,

> and over and over. Is there a real logic for that?

Yes. The logic is that Apad keeps changing based on the protocol. There are some specific attacks that can be prevented by defining Apad to mean something specific. In case of OSPFv2 it means the source address of the sender. In case of OSPFv3, it is a value where the first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. L in this case is the length of the hash. 

In case of RIpv2 and IS-IS it's a fixed constant.

In this draft Apad is defined as:

In case of IPv4, the first 4 octets contain the IPv4 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times.  
In case of IPv6, the first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times.

One way to avoid this duplication is by writing a new RFC that redefines HMAC and includes the Apad. Other documents can only mention the Apad value, while including a normative reference to that RFC.

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.

Cheers, Manav

> >> reopen> >>>>> cryptographic primitives.
> >>>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 May 2014 11:24:27 +0100

On 21/05/14 09:07, Bhatia, Manav (Manav) wrote:
> Stephen,
> 
>>> The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason
>>> why LDP should be an exception. The same has been proposed for
>>> BFD btw.
>> 
> Yes. The logic is that Apad keeps changing based on the protocol.
> There are some specific attacks that can be prevented by defining
> Apad to mean something specific. In case of OSPFv2 it means the
> source address of the sender. In case of OSPFv3, it is a value where
> the first 16 octets contain the IPv6 source address followed by the
> hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. L in this case
> is the length of the hash.
> 
> In case of IPv4, the first 4 octets contain the IPv4 source address
> followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times.
>  In case of IPv6, the first 16 octets contain the IPv6 source address
> followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4
> times.
> 
> One way to avoid this duplication is by writing a new RFC that
> redefines HMAC and includes the Apad. Other documents can only
> mention the Apad value, while including a normative reference to that
> RFC.
> 
> 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?

(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;-)

S.

>>>> [mailto:[email-masked]] Sent: Wednesday, May 21,
>>>> 2014 2:53 AM To: Bhatia, Manav (Manav); IETF Security
>>>> Directorate; The IESG; draft-
>>>> [email-masked] Cc: Yaron
>>>> Sheffer; [email-masked] Subject: Re: SecDir review of 
>>>>>>> * 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
>>>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> re-definition and just properly refer to HMAC. Its about time
>>>> to stop repeating that error.
>>>> 
>>>> S.
>>> 
>>> 
>>> 
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 May 2014 11:41:56 +0100

On 21/05/14 11:39, Manav Bhatia wrote:
> 
> 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. 

How about we make that idea fly again?

I realise that might cause some short term pain with this I-D, but
it could be the right thing to do.

S.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 May 2014 12:58:30 +0200

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:
> It sure is.
> 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.
>
>>
> 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
>>>>>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 May 2014 11:14:40 +0000

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. 

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.

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

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2014 4:29 PM
> To: Manav Bhatia; Stephen Farrell
> Cc: Bhatia, Manav (Manav); IETF Security Directorate; The IESG; draft-
> [email-masked]; Yaron Sheffer

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 May 2014 13:57:54 +0100

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.
> 
>> -----Original Message----- From: Loa Andersson [mailto:[email-masked]] 
>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen
>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The
>> IESG; draft- [email-masked];
>> Yaron Sheffer Subject: Re: SecDir review of
>> So if we get to tired to push this, we are all better off not
>> doing the security work for this particular protocol?
>> 
>>>>> This however is a long drawn discussion because everyone
>>>>> needs to
>> be
>>>>> convinced on the merits of updating the HMAC specification --
>>>>> which
>> I
>>>> 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.
>>> 
>>>> 
>>> 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
>>>>>>> 
>>>>>>>> [mailto:[email-masked]] Sent: Wednesday, May
>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF
>>>>>>>> Security Directorate; The IESG; draft- 
>>>>>>>> [email-masked] Cc:
>>>>>>>>>>> * 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
>>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> re-definition and just properly refer to HMAC. Its
>>>>>>>> about time to stop repeating that error.
>>>>>>>> 
>>>>>>>> S.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>> 
>> --
>> 
>> 
>> Senior MPLS Expert                          [email-masked] Huawei
>> Technologies (consultant)     phone: +46 739 81 21 64

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 21 May 2014 09:28:00 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 May 2014 09:42:33 -0400

> security as the other routing protocols.

Well, 18 months is an extremely pessimistic time frame, so let's step back:
This isn't the first time we've come here, so it's well known what
needs to be documented.  Stephen and Manav: how long do you really
think it would take to write this document up and have it ready for
last call?  How much real iteration on the document is likely to be
needed?

It seems to me that if Manav should write something up and pass it by
Stephen, you could have something that's pretty much ready by the time
Manav posts it as -00.  Post to a few appropriate lists for comments,
post a -01, maybe a -02, then last call it.  That can't be more than a
few weeks.  Then we have a four-week last call, another week in IESG
Evaluation.  We ought to be able to get this from inception to the RFC
Editor queue in 2 months, maybe 3 tops.

Is that really a serious problem?  And that will close this issue for
good, so we don't have to keep having the discussion.

I understand the response that we often have, that we don't want to
hold *this* document hostage for something broader that needs to be
done.  And that's valid as far as it goes... but when we see ourselves
saying it continually about the same topic, something needs to be done
or we'll never get to fixing the broader issue.

Barry

Barry

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 May 2014 13:47:50 +0000

When we were doing the OSPFv2 crypto authentication we had used the base HMAC (http://tools.ietf.org/html/draft-ietf-ospf-hmac-sha-03). Ran Atkinson and a few others had written another draft that did exactly what we did and had additionally introduced the Apad (that we're discussing here) in their crypto maths.

The following presentation was made at the 73rd IETF.
http://www.ietf.org/proceedings/73/slides/ospf-5.pdf

We were instructed by the Security ADs back then that this was the construct (one with Apad) that folks wanted to use and based on that a decision was taken to merge the two drafts (http://tools.ietf.org/html/draft-ietf-ospf-hmac-sha-04) which finally resulted in RFC 5709.

You can look at http://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-hmac-sha-04.txt to see the exact version where we introduced this crypto maths. 

I wasn't a big fan of Apad to start with. However I am ok now, as it seems to help us in some clever ways (protects us against attacks on the IP header). I think we should live with it irrespective of whether it helps in improving the HMAC or not. (BTW, it doesn't - I spoke to Hugo Krawczyk and others who clearly understand this more than me)

Cheers, Manav

> From: Uri Blumenthal [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2014 6:58 PM
> To: Stephen Farrell
> Cc: Bhatia, Manav (Manav); Loa Andersson; Manav Bhatia; draft-ietf-
> [email-masked]; The IESG; IETF Security
> Directorate
> Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-
> crypto-auth-05
> 
> 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)?
> 
> 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).
> 
> 
> 
> >> The IETF submission site is down and hence couldn't upload the

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 May 2014 13:51:53 +0000

Hi Barry,

> few weeks.  Then we have a four-week last call, another week in IESG

This isnt correct. One we don't know the correct home for such a draft. Even if we do find a home (which am sure is possible) its going to be a very contentious debate on whether HMAC needs Apad or not. Till date, I have not heard of a very convincing reason. People would like to know the reason of why we want this. If we don't have a very convincing reason then it's a long drawn battle which aint finishin' in a few weeks time! :-)

Cheers, Manav

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 May 2014 10:04:35 -0400

> This isnt correct. One we don't know the correct home for such a
> draft. Even if we do find a home (which am sure is possible) its going
> to be a very contentious debate on whether HMAC needs Apad or not.
> Till date, I have not heard of a very convincing reason. People would
> like to know the reason of why we want this. If we don't have a very
> convincing reason then it's a long drawn battle which aint finishin'
> in a few weeks time! :-)

Ack.
But, then, why is it better to stick Apad in piecemeal, document by
document, and have the argument all over again every time?

Barry

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 May 2014 14:19:34 +0000

> document, and have the argument all over again every time?

Because this is perhaps the last document that will use the Apad.

All others are already out! ;-)

Cheers, Manav

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 21 May 2014 17:24:59 +0300

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

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 21 May 2014 16:09:46 +0530

Stephen,

It sure is.

Cheers, Manav

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 May 2014 17:50:02 +0200

Bary,

> document, and have the argument all over again every time?

Are you requesting that we are revising the document that already have
been approved using the "piecemeal" approach? If you are not why can't
we wrp up the last one and move ahead?

/Loa

--

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 21 May 2014 11:58:09 -0400

1. Leave the HMAC construct alone. Do not redefine it in the draft, do not spell it out in the draft, just use it/refer to it. Could you please make the text reflect this? Stephen suggested “for someone here to re-factor their text to just do their Apad thing but to not repeat text from 2104”, which makes perfect sense to me.

2. You can use HMAC to sign (hmm, authenticate :) anything you wish, including Apad. It should not be a concern from security point of view.

Thanks!

On May 21, 2014, at 10:24 , Yaron Sheffer <[email-masked]> 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
> 
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 May 2014 18:11:57 +0200

Barry,

> last call?  How much real iteration on the document is likely to be

Wish you were right, but even looking at non-contetious and simple
drafts 18 months is optimistic.

For example
draft-ietf-mpls-special-purpose-labels dates back to 2012-03 (27 months)

And the draft we are talking about here woudl be much more contentious,
I actually put in 18 months as a quite optimistic estimate.

/Loa

--

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 May 2014 13:24:48 -0400

> All others are already out! ;-)

OK... I didn't realize we were at the end of the trip.

Barry

---

From: Manav Bhatia <[email-masked]>
Date: Sun, 25 May 2014 11:20:02 +0530

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 <[email-masked]>wrote:

> > 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

---

From: Vero Zheng <[email-masked]>
Date: Mon, 26 May 2014 01:30:05 +0000

Thanks Yaron and Manav for working this out.
I have just confirmed the post.

Cheers, Vero

From: Manav Bhatia [mailto:[email-masked]]
Sent: Sunday, May 25, 2014 1:50 PM
To: Yaron Sheffer
Cc: Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF Security Directorate; [email-masked]; 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.

Cheers, Manav

On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> 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.

Thanks,
        Yaron

On 05/21/2014 04:28 PM, Uri Blumenthal wrote:
> On May 21, 2014, at 8:57 , Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>
>>
>>
>>>> -----Original Message----- From: Loa Andersson [mailto:[email-masked]<mailto:[email-masked]>]
>>>> IESG; draft- [email-masked]<mailto:[email-masked]>;
>>>>>>>>>> [mailto:[email-masked]<mailto:[email-masked]>] Sent: Wednesday, May
>>>>>>>>>> [email-masked]<mailto:[email-masked]> Cc:
>>>>>>>>>> Yaron Sheffer; [email-masked]<mailto:[email-masked]> Subject: Re:
>>>>>>>>>> SecDir review of
>>>> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
>>>> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]> Huawei
>>>> Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 28 May 2014 09:05:50 +0200

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:
> *From:*Manav Bhatia [mailto:[email-masked]]
> *Sent:* Sunday, May 25, 2014 1:50 PM
> *To:* Yaron Sheffer
> *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF
> Security Directorate;
> [email-masked]; The IESG; Loa
> Andersson
> *Subject:* Re: [secdir] SecDir review of
> 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 attaching the latest version with this email in case folks want to
> go through this till it becomes available formally.
>
>> On May 21, 2014, at 8:57 , Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>
>>>
>>>>> -----Original Message----- From: Loa Andersson [mailto:[email-masked] <mailto:[email-masked]>]
>>>>> IESG; [email-masked]
> <mailto:[email-masked]>;
>>>>>>>>>>> [mailto:[email-masked] <mailto:[email-masked]>] Sent:
> Wednesday, May
> <mailto:[email-masked]> Cc:
>>>>>>>>>>> Yaron Sheffer;[email-masked] <mailto:[email-masked]> Subject: Re:
>>>>>>>>>>> SecDir review of
>>>>> Loa Andersson                        email:[email-masked] <mailto:[email-masked]>
>>>>> Senior MPLS [email-masked] <mailto:[email-masked]> Huawei
>>>>> Technologies (consultant)     phone:+46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064>
>>>
>>>[email-masked] <mailto:[email-masked]>
>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>>[email-masked] <mailto:[email-masked]>
>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>

--

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 28 May 2014 12:36:50 +0530

Yup, thats correct!

On Wed, May 28, 2014 at 12:35 PM, Loa Andersson <[email-masked]> wrote:

>>>>>> Loa Andersson                        email:[email-masked]<mailto:
>>>>>> [email-masked]>
>>>>>> Technologies (consultant)     phone:+46 739 81 21 64<tel:%2B46%20739%2081%2021%
>>>>>> 2064>
>>>>>>
>>>>>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 28 May 2014 09:13:59 +0200

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     All,
>
>         *From:*Manav Bhatia [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         [email-masked]
>         <mailto:[email-masked]>__;
>         The IESG; Loa
>         Andersson
>         draft-ietf-mpls-ldp-hello-__crypto-auth-05
>
>         Hi,
>
>         On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>         wrote:
>
>         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>.
>             1. Who specifically, at NIST and at IESG, says that HMAC
>             needs Apad for security reasons (and therefore is not secure
>             as-is)?
>
>             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
>             <[email-masked]
>             <mailto:[email-masked]>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>
>
>
>                         -----Original Message----- From: Loa Andersson
>                         [mailto:[email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked] <mailto:[email-masked]>>]
>
>                         IESG;
>                         [email-masked]
>                         <mailto:[email-masked]>
>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>__>;
>
>                         draft-ietf-mpls-ldp-hello-__crypto-auth-05
>
>                         Folks,
>
>                             draft-ietf-ospf-security-__extension-manual-keying-08
>                             amongst
>                                                 -----Original
>                                                 Message----- From:
>                                                 Stephen Farrell
>                                                 [mailto:[email-masked]
>                                                 <mailto:[email-masked]>
>                                                 <mailto:[email-masked]
>                                                 <mailto:[email-masked]>>]
>                                                 Sent:
>
>         Wednesday, May
>
>                                                 21, 2014 2:53 AM To:
>                                                 The IESG; draft-
>                                                 [email-masked]
>                                                 <mailto:[email-masked]>
>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>__> Cc:
>
>                                                 Yaron
>                                                 Sheffer;[email-masked]
>                                                 <mailto:[email-masked]>
>                                                 <mailto:[email-masked]
>                                                 <mailto:[email-masked]>>
>                                                 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> >>>>>
>                                                         This is a
>                                                         decision that
>                                                         was taken by Sec
>                                                         Ads when
>                                                         we were doing
>                                                         the crypto
>                                                         protection for
>                                                         the IGPs
>                                                         mathematics is
>                                                         not new and has
>                                                         been done for all
>                                                         IGPs and has
>                                                         been approved
>                                                         and rather
>                                                         encouraged by
>                                                 The above does not sound
>                                                 like something I
>                                                 recognise. I
>                         Loa Andersson email:[email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]
>                         <mailto:[email-masked]>>
>                         Senior MPLS [email-masked]
>                         <mailto:[email-masked]> <mailto:[email-masked]
>                         <mailto:[email-masked]>> Huawei
>                         <tel:%2B46%20739%2081%2021%__2064>
>
>
>                 _________________________________________________
>                 secdir mailing list
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>
>                 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
>             <mailto:[email-masked] <mailto:[email-masked]>>
>
>             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>
>
>
>
>     --
>
>
>     <mailto:[email-masked]>
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     <tel:%2B46%20739%2081%2021%2064>
>
>

--

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 28 May 2014 12:51:02 +0530

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 <[email-masked]> wrote:

> >         <mailto:[email-masked]
> >__;
> >         The IESG; Loa
> >         Andersson
> >         <
> >                         <mailto:
> [email-masked]>
> >
> >                                                 21, 2014 2:53 AM To:
> >                                                 Bhatia, Manav (Manav);
> IETF
> >                                                 <mailto:
> [email-masked]>
> >
> >                                                         based on some
> >                                                         feedback from
> >                                                 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
> >                                                 If you are revising that
> >                                                 doc, *please* get rid of
> the
> >                                                 re-definition and just
> >                                                 properly refer to HMAC.
> Its
> >                 wiki:
> http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview
> >             wiki:
> http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview