Subject: RE: [Ipsec] Question about Integrity Checksum Data

From: [email-masked]
Date: Fri, 27 May 2005 16:11:25 +0300

Hi,

If you negotiate e.g. "AUTH_HMAC_SHA1_96" for your integrity
algorithm, then yes, the integrity checksum data is always 96 bits.

(Presumably, someone could define AUTH_HMAC_SHA1_128 or
AUTH_HMAC_SHA1_160 or something else in the future, but those
would be totally different integrity algorithms from IKEv2 
point of view, even though not much additional code would
be needed.)

Best regards,
Pasi

> -----Original Message-----
> From: Yoav Nir
> Sent: Friday, May 27, 2005 11:59 AM
> To: IPsec WG
> Subject: [Ipsec] Question about Integrity Checksum Data
> 
> 
> Hi.
> 
> This has probably been discussed before, but I couldn't find it
> in either the draft or the mailing list archive.
> 
> The Integrity Checksum Data field in the Encrypted payload is
> described as having a length as specified by the integrity
> algorithm. All the integrity algorithms are those that are also
> specified for ESP.  In ESP, the hash value is truncated to 96
> bits (hence the _96 suffix in all their names)
> 
> In IKEv1 we did not truncate the hash value for IKE, only for
> ESP.  Has this changed for IKEv2?  Are we supposed to use only
> the first 96 bits for MD5 and SHA1, or should we keep using the
> full untruncated value?
> 
> Thanks
> 
> Yoav

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Sun, 29 May 2005 07:25:15 +0300

Thanks.

It is strange.  If you read RFC 4109 (algorithms for IKEv1) or the IANA 
registry, it says just MD5 or SHA1, and in fact implementations of 
IKEv1 did use the full checksum (128 or 160 bits).

However, the UI-suites document and the algorithms document show only 
the _96 version of these algorithms. Is this difference intentional? 
Does this mean that for an IKEv1 implementation to support the VPN-A 
suite it would need to have a new algorithms for integrity?

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 May 2005 15:43:57 -0700

At 7:25 AM +0300 5/29/05, Yoav Nir wrote:
>It is strange.  If you read RFC 4109 (algorithms for IKEv1) or the 
>IANA registry, it says just MD5 or SHA1, and in fact implementations 
>of IKEv1 did use the full checksum (128 or 160 bits).

Nothing strange so far.

>However, the UI-suites document and the algorithms document show 
>only the _96 version of these algorithms. Is this difference 
>intentional? Does this mean that for an IKEv1 implementation to 
>support the VPN-A suite it would need to have a new algorithms for 
>integrity?

Because we changed from not negotiating the actual PRF in IKEv1 to 
negotiating it in IKEv2, the UI-suites document had to pick between 
one of the two wordings; I chose the IKEv2 wording.

In IKEv1, it says:

    All of these attributes are mandatory and MUST be negotiated. In
    addition, it is possible to optionally negotiate a psuedo-random
    function ("prf").  (There are currently no negotiable pseudo-random
    functions defined in this document. Private use attribute values can
    be used for prf negotiation between consenting parties). If a "prf"
    is not negotiation, the HMAC (see [KBC96]) version of the negotiated
    hash algorithm is used as a pseudo-random function. Other non-
    mandatory attributes are described in Appendix A. The selected hash
    algorithm MUST support both native and HMAC modes.

Thus, when you negotiate a hash algorithm of "SHA1", you are really 
negotiating the PRF of "HMAC-SHA1" and the use of SHA1 in other 
places in the protocol. Maybe instead of:
    Pseudo-random function   HMAC-SHA1 [RFC2104]
I could have said:
    Hash (IKEv1) or pseudo-random function (IKEv2)   SHA1 [SHA1] or 
HMAC-SHA1 [RFC2104]
but that would be harder to understand.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 May 2005 09:52:10 +0300

So if I'm using the UI suite VPN-A, whenever I'm using IKEv1 I will use 
the integrity algorithm SHA1 (with a 160-bit checksum field), but 
whenever I'm using IKEv2 I will use the SHA1_96 integrity algorithm 
(with a 96-bit checksum field).

Is this correct?

On May 30, 2005, at 1:43 AM, Paul Hoffman wrote:

> negotiating the PRF of "HMAC-SHA1" and the use of SHA1 in other places 
> in the protocol. Maybe instead of:

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 May 2005 08:08:25 -0700

At 9:52 AM +0300 5/30/05, Yoav Nir wrote:
>So if I'm using the UI suite VPN-A, whenever I'm using IKEv1 I will 
>use the integrity algorithm SHA1 (with a 160-bit checksum field), 
>but whenever I'm using IKEv2 I will use the SHA1_96 integrity 
>algorithm (with a 96-bit checksum field).
>
>Is this correct?

No. In IKEv1, you will use the hash algorithm SHA1, and the integrity 
algorithm HMAC-SHA1, just as you do now. The UI suite doesn't change 
that at all.

--Paul Hoffman, Director
--VPN Consortium