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

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



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

Quoting Stephen Kent <kent@bbn.com>:

> At 9:18 PM +0530 8/11/04, Navin Kumar wrote:
> >	<SNIP>
> >
> >My Doubt:
> >
> >As per RFC 2402 - AH Protocol, if the IP packet length does not 
> >match the blocksize of the auth algorithm, implicit padding is done with
> >zeros.
> >
> >1) Hence if AES-XCBCMAC is chosen in AH then , is it that always Case 1
> >occurs??
> >    Kindly clarify my understanding.
> 
> The authors described a generic padding mechanism for use of the 
> algorithm, not one tailored to use in the AH context.  So, I'd say 
> the right answer is to interpret this as CASE 1, i.e., the implicit 
> padding provided by AH makes the input to the algorithm always appear 
> as a full, final block.
> 
> Steve
> 
> 
> 
> 



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