Subject: [Ipsec] Implementation of AES-XCBC MAC

From: Navin Kumar <[email-masked]>
Date: Thu, 5 Aug 2004 14:28:00 +0530 (IST)

hi,

   Is there any implementation of AES-XCBC MAC algorithm or any IPSec/IKE 
implementation which includes AES-XCBC MAC ?

have a nice day,
navin

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Navin Kumar <[email-masked]>
Date: Wed, 11 Aug 2004 21:18:07 +0530 (IST)

Hi,
  RFC 3566 (AES-XCBC-MAC-96 Algorithm and Its Use with IPSec) states 
that :

Case 1:

if the size of last block of message is 128 bits :
do  

E[n] =  Encryption (M[n] XOR E[n-1] XOR K2) with  K1 

Case2:
if the size of last block of message is less than 128 bits:
do

i)Pad M[n] with a '1'bit  followed by '0'bits to make M[n] to be a 
block size of 128 bits.
ii) E[n] = Encryption (M[n] XOR E[n-1] XOR K3 ) with  K1

where 
M[n] -  the last block of message 
E[n] - the AESXCBC-MAC value
E[n-1] = encrypted output of the previous block
K1 - AES Encryption Key K1
K2 - derived key from K1.
Encryption - AES Encryption

The above is explained in RFC 3566 in section 4 .

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.   

2) When will Case 2 occur?

thanks in advance.

navin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Aug 2004 15:30:18 -0400

At 9:18 PM +0530 8/11/04, Navin Kumar wrote:
>	<SNIP>

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

---

From: Sheila Frankel <[email-masked]>
Date: Wed, 11 Aug 2004 16:41:40 -0400

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
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Aug 2004 09:21:50 -0400

>padding' as defined in [AH], no implicit padding is required."

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