[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