Subject: RE: [Ipsec] Query for IPv6 ICV

From: Grubmair Peter <[email-masked]>
Date: Thu, 11 Nov 2004 10:44:05 +0100

Hi, I am not sure if its really wrong what Windows produces -
as 20 bytes (ICV + padding) + 12 bytes AH gives 32 bytes,
which is a multiple of 8.
So maybe 20 bytes of Windows are 12 bytes ICV + 8 bytes padding.
RFC2402 does not prohibit unneccessary padding.
best regards
   Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stephen Kent
Sent: Donnerstag, 11. November 2004 03:08
To: Khan, Irfan
Cc: [email-masked]
Subject: Re: [Ipsec] Query for IPv6 ICV

At 2:43 PM +0500 11/4/04, Khan, Irfan wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
  boundary="----_=_NextPart_001_01C4C252.C14D11BF"

Hi,

I'm trying to establish an IPSEC session over IPv6 with Windows XP and
FreeBSD (Kame's implementation) AH Transport mode with HMAC-MD5
authentication. Windows sends an ICV of 20 bytes (with 4 padded 0 bytes) and
FreeBSD simply discards the packet.

RFC 2403 states that HMAC-MD5-96 produces a 128 bit authenticator value and
a truncated value using the first 96 bits MUST be supported.

I want to know that IPSEC standards say about ICV size in case of IPv6.

2402 says that the ICV is padded to cause the whole AH length to be an
integral multiple of 4 bytes for IPv4, 8 bytes for IPv6.

The HMAC-MD5-96 ICV is 12 bytes (96 bits) long, as stated in 2403. That is
not only te MUST support length specified by the RFC, it is the only length
specified as the output of this algorithm, for use with AH or ESP. I admit
that RFC 2403 could be better worded in this regard,  but the operative
sentence in the RFC states: "No other authenticator value lengths are
supported by HMAC-MD5-96." Also, of course, the title of the RFC does
provide a hint :-)

The rest of the AH header is 12 bytes long, so, the total AH header length,
when this integrity algorithm is employed, is 24 bytes. This meets the IPv4
and IPv6 requirements for alignment, since 24 is an integral multiple of
both 4 and 8.

So, it is not appropriate for the ICV to be padded for IPv4 or IPv6.

What you seem to describe is transmission of a 16-byte HMAC output, which is
then padded with 4 bytes to cause the result to be an integral multiple of 8
bytes, for IPv6. This is wrong, because the integrity algorithm specified
here does not define a 128-bit output.

The Windows implementation is broken and the Free BSD implementation is
appropriately rejecting the packet.

Steve

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Nov 2004 08:53:21 -0500

>RFC2402 does not prohibit unneccessary padding.

I am sure :-)

I explained the rationale in my message, i.e., the HMAC-MD5-96 RFC 
specifies that ONLY a 96-bit value is defined by that standard. So, 
if one negotiates this integrity algorithm in IKE, the ONLY 
acceptable HMAC value to send is one that is exactly 96-bits in 
length. Sending the full 128-bit output  of HMAC-MD5 violates the RFC 
specification.

You are right that the AH RFC does not prohibit unnecessary padding, 
but it seems  clear that what Windows is doing is outputting the 
wrong length HMAC value, then padding that.

Steve