Subject: [Ipsec] Query for IPv6 ICV

From: "Khan, Irfan" <[email-masked]>
Date: Thu, 4 Nov 2004 14:43:35 +0500

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.

Thanks in advance.

Kind regards,

Muhammad Irfan Khan

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Nov 2004 21:07:51 -0500

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

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