[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AH padding after MD5/SHA1 hash value

To: itojun@iijlab.net
Subject: Re: AH padding after MD5/SHA1 hash value
From: "Shoichi 'Ne' Sakane" <sakane@ydc.co.jp>
Date: Tue, 13 Jun 2000 22:56:23 +0900
Cc: ipsec@lists.tislabs.com
In-Reply-To: Your message of "Tue, 13 Jun 2000 22:42:33 +0900"<29940.960903753@lychee.itojun.org>
References: <29940.960903753@lychee.itojun.org>
Sender: owner-ipsec@lists.tislabs.com

> 	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"?

There is the reason at the section 5 in RFC2104, but it doesn't mentioned
strongly.

Follow-Ups:

Re: AH padding after MD5/SHA1 hash value

From: itojun@iijlab.net

References:

AH padding after MD5/SHA1 hash value

From: Jun-ichiro itojun Hagino <itojun@iijlab.net>

Prev by Date: AH padding after MD5/SHA1 hash value
Next by Date: RE: Replay problem
Prev by thread: AH padding after MD5/SHA1 hash value
Next by thread: Re: AH padding after MD5/SHA1 hash value
Index(es):
- Main
- Thread