Subject: Does it impose a security issue with the HMAC TLV in draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC value?

From: Linda Dunbar <[email-masked]>
Date: Mon, 20 Aug 2018 19:57:31 +0000

Clarence, et al:

The HMAC TLV, which is to part of SRH, has both HMAC Key and HMAC Value.
If intercepted, HMAC key can be altered to produce the desired value of the intruder. How can the receiver use the altered key to validate the integrity of the payload?
Isn't it a security hole?

I thought the HMAC key has to be sent to nodes separately from payload, so that receiver can calculate the Hash value of the received payload to validate the integrality of the payload, Correct?   That means the HMAC Key should be included in the TLV of the SRH.

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 20 Aug 2018 20:08:01 +0000

Typo, I meant "HMAC Key should NOT be included in the TLV of the SRH"

Linda

From: ipv6 [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, August 20, 2018 2:58 PM
To: [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>
Subject: Does it impose a security issue with the HMAC TLV in draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC value?

Clarence, et al:

Linda Dunbar

---

From: David Lebrun <[email-masked]>
Date: Tue, 21 Aug 2018 09:19:56 +0100

Hi Linda,

The "HMAC Key ID" field does not contain the pre-shared secret key, which
would indeed make no sense. Rather, it contains an opaque value that serves
as an index for a pre-shared key and a hashing algorithm. Please read
Section 6.2 of the draft[1] for more details.

[1]
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-14#section-6.2

Cheers,
David

On Mon, Aug 20, 2018 at 9:08 PM Linda Dunbar <[email-masked]>
wrote:

> Typo, I meant “HMAC Key should NOT be included in the TLV of the SRH”
>
>
>
> Linda
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, August 20, 2018 2:58 PM
> *To:* [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>
> *Subject:* Does it impose a security issue with the HMAC TLV in
> draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC
> value?
>
>
>
> Clarence, et al:
>
>
>
> If intercepted, HMAC key can be altered to produce the desired value of
> the intruder. How can the receiver use the altered key to validate the
> integrity of the payload?
>
> Isn’t it a security hole?
>
>
>
> I thought the HMAC key has to be sent to nodes separately from payload, so
> that receiver can calculate the Hash value of the received payload to
> validate the integrality of the payload, Correct?   That means the HMAC Key
> should be included in the TLV of the SRH.
>
>
>
>
>
> Linda Dunbar
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 21 Aug 2018 16:38:57 +0000

David,

Why not call the field “HMAC Key-Index”? It is kind of misleading to call the field as “Key ID”.

In addition, why need 4 octets for Index to the pre-shared key? How many keys would each node has?
Why does the HMAC hash value need 32 octets? That is a lot of bytes to carry the hash value. The HMAC is not really to secure anything, it only serves the purpose of Checksum (hashed with pre shared key). Why not 4 bytes? What are the reasons of not having smaller number of hash value?

Linda

From: David Lebrun [mailto:[email-masked]]
Sent: Tuesday, August 21, 2018 3:20 AM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Does it impose a security issue with the HMAC TLV in draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC value?

Hi Linda,

The "HMAC Key ID" field does not contain the pre-shared secret key, which would indeed make no sense. Rather, it contains an opaque value that serves as an index for a pre-shared key and a hashing algorithm. Please read Section 6.2 of the draft[1] for more details.

[1] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-14#section-6.2

Cheers,
David

On Mon, Aug 20, 2018 at 9:08 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Typo, I meant “HMAC Key should NOT be included in the TLV of the SRH”

Linda

From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Linda Dunbar
Sent: Monday, August 20, 2018 2:58 PM
To: [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>
Subject: Does it impose a security issue with the HMAC TLV in draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC value?

Clarence, et al:

Linda Dunbar

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: David Lebrun <[email-masked]>
Date: Thu, 23 Aug 2018 11:38:04 +0100

Linda,

The purpose of the HMAC is not to provide a mere checksum, it provides
authenticity and integrity of the SRH. A value of 32 bytes allows to store
the output of modern hash functions such as SHA-256. Truncating the output
to 4 bytes would make it fairly trivial to generate collisions, rendering
the security feature useless. Again, I strongly suggest that you read the
Section 6.2 of the draft[1] as it explains the purpose of the HMAC fields
and contains the answer to your questions. You might also want to consider
reading the definition of an HMAC[2][3] to better understand its purpose in
general.

[1]
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-14#section-6.2
[2] https://tools.ietf.org/html/rfc2104
[3] https://en.wikipedia.org/wiki/HMAC

On Tue, Aug 21, 2018 at 5:39 PM Linda Dunbar <[email-masked]>
wrote:

> Why does the HMAC hash value need 32 octets? That is a lot of bytes to
> carry the hash value. The HMAC is not really to secure anything, it only
> serves the purpose of Checksum (hashed with pre shared key). Why not 4
> bytes? What are the reasons of not having smaller number of hash value?
>
>
>
> Linda
>
>
>
>
>
> *From:* David Lebrun [mailto:[email-masked]]
> *Sent:* Tuesday, August 21, 2018 3:20 AM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: Does it impose a security issue with the HMAC TLV in

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Aug 2018 15:29:25 +0000

David,

I have read the Section 6.2. I understand how HMAC works.

The entire payload is NOT encrypted. HMAC is only the Hash of Payload with the pre-shared Security Key. What kind of problem will happen of there are collision of the Hash value? The goal is to prevent intruder from changing the SRH in a way to result in the same Hash Value. With multiple keys, what is chance of having SRH changed to another meaningful value and resulting in the same Hash value?  < 0.001%?

I just think it is overkill to have 32 bytes for the Hash value & 4 bytes to carry the Key-Index. At least, make the size flexible, give implementer some room to choose a tolerable size.

Linda

Sent: Thursday, August 23, 2018 5:38 AM

Linda,

The purpose of the HMAC is not to provide a mere checksum, it provides authenticity and integrity of the SRH. A value of 32 bytes allows to store the output of modern hash functions such as SHA-256. Truncating the output to 4 bytes would make it fairly trivial to generate collisions, rendering the security feature useless. Again, I strongly suggest that you read the Section 6.2 of the draft[1] as it explains the purpose of the HMAC fields and contains the answer to your questions. You might also want to consider reading the definition of an HMAC[2][3] to better understand its purpose in general.

On Tue, Aug 21, 2018 at 5:39 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
David,

Linda

From: David Lebrun [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 21, 2018 3:20 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Does it impose a security issue with the HMAC TLV in draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC value?

Hi Linda,

Cheers,
David

Linda

Clarence, et al:

Linda Dunbar

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 23 Aug 2018 17:40:06 +0000

Linda,

The ‘HMAC Key’ field is actually the equivalent of the Security Parameter Index (SPI) of IPsec. It is negotiated outside of SRH (as it is negotiated outside of IPsec via IKE – or static configuration). So, the attacker can do nothing even during the key roll-over when only 2 keys would be accepted.

Now, your suggestion of using the name of ‘HMAC Key Index’ rather than ‘HMAC Key ID’ makes sense

-éric

From: ipv6 <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Monday, 20 August 2018 at 21:58
To: "[email-masked]" <[email-masked]>, Clarence Filsfils <[email-masked]>
Subject: Does it impose a security issue with the HMAC TLV in draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC value?

Clarence, et al:

Linda Dunbar

---

From: "Liu,Shu@CATR" <[email-masked]>
Date: Fri, 24 Aug 2018 10:32:20 +0800

so what is the point to define a HMAC tLv, when the payload is fixed length?

If the length is more flexible, such note will not be necessary, in sec 6.2.1 “
If the output of the hash function is

   larger than 256 bits, then the output value is truncated to 256 by

   taking the least-significant 256 bits and inserting them in the HMAC

   field.

”

Of course, fixed length has one merit, the attackers have to guess the hash algorithm. But it will be  compromised, when “the 160-bit hash value must then be right-hand padded with 96 bits set to 0”

Thanks.

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, August 23, 2018 11:29 PM
To: David Lebrun
Cc: [email-masked]; [email-masked]
Subject: RE: Does it impose a security issue with the HMAC TLV in draft-ietf-6man-segment-routing-header-14 containing both HMAC Key and HMAC value?

David, 

Linda 

Linda,

On Tue, Aug 21, 2018 at 5:39 PM Linda Dunbar <[email-masked]> wrote:

David, 

Linda

Hi Linda,

Cheers,

David

On Mon, Aug 20, 2018 at 9:08 PM Linda Dunbar <[email-masked]> wrote:

Linda

Clarence, et al: 

 

Linda Dunbar