[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AH padding after MD5/SHA1 hash value
Correct me if I'm wrong. I have a question about AH packet.
From what I understand from the wording in RFC240[234],
- for sender side, it is not illegal to attach more than 96 bits
into authentication data field. RFC2403 does not require us to
attach exactly 96bits. It just say "truncated value using the
first 96 bits MUST be supported". It is not clear to us whether
96bit truncation is the requirement, or not.
This seems odd while we call those AH algorithms as "HMAC-MD5-96".
If we do not require truncation to 96bits, why we call it "96"?
- Due to the way the document is written, receiver side will not
notice even if the peer attaches more meat than 96 bits.
Inbound check is done like this:
(1) compute 128bit(MD5) or 160bit(SHA1) hash
(2) compare first 96bit with authentication data field
the receiving side will notice it only if it is picky about the
length of AH portion length.
We (KAME) have never noticed this during past interop events, since
we only generate 96bit authentication data, and we do not care about
too-long authentication data (we do reject too-short authentication
data). We noticed that a MAJOR implementation attach the whole
160bits for HMAC-SHA1, and 128bit + 32bit padding for HMAC-MD5.
Now. Why the document is written this way? If my understanding is
correct, (1) we allow junk data to be attached at the end of
authentication data, and (2) we have no real requirement to check
if the junk data is rewritten or not. Even if man-in-the-middle
rewrites junk data portion, we will never notice, and data exchange
should go just fine. But, this worries me.
Is it specwise okay if we reject any packet with longer-than-96bit
authentication data? I know that we will not be able to interop
with the particular implementation mentioned above. I hope more
clarification to appear in the document.
itojun
RFC2402 chapter 2:
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Next Header | Payload Len | RESERVED |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Security Parameters Index (SPI) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sequence Number Field |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> + Authentication Data (variable) |
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFC2403 chapter 2:
> HMAC-MD5-96 produces a 128-bit authenticator value. This 128-bit
> value can be truncated as described in RFC 2104. For use with either
> ESP or AH, a truncated value using the first 96 bits MUST be <---
> supported. Upon sending, the truncated value is stored within the <---
> authenticator field. Upon receipt, the entire 128-bit value is
> computed and the first 96 bits are compared to the value stored in
> the authenticator field. No other authenticator value lengths are
> supported by HMAC-MD5-96.
Follow-Ups: