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
