Re: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC3566)

[Stephen Kent <kent@bbn.com>]

At 4:41 PM -0400 8/11/04, Sheila Frankel wrote:
>Actually, I came to the opposite conclusion:
>
>This question is addressed in the AES-XCBC-MAC RFC; unfortunately, it appears
>in a different section than the algorithm definition. The AH RFC, in section
>3.3.3.2.2, exempts MD5 and SHA-1 from the implicit packet padding 
>requirements,
>since they have their own padding conventions. AES-XCBC-MAC was not defined
>when the AH RFC was written, but it is treated in the same way. Thus, the
>padding will be performed according to the AES-XCBC-MAC specification, and
>Case2 will occur when the packetsize is not a multiple of 128 bits. In fact,
>the AES-XCBC-MAC RFC, in section 4.2, states "with regard to 'implicit packet
>padding' as defined in [AH], no implicit padding is required."
>
>Sheila Frankel
>sheila.frankel@nist.gov
>

Sheila,

Good point.

As you note, we make an explicit exception for MD5 and SHA-1 in AH, 
both the RFC and the new I-D that will replace it.  Maybe we should 
remove these references to specific algorithms in AH and ESP and, 
instead, refer folks to the documents that define how to use specific 
integrity algorithms with AH and ESP, re padding.

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec