Subject: [Ipsec] CCM: AAD construction

From: "Bansal, Yogesh" <[email-masked]>
Date: Wed, 6 Apr 2005 13:30:24 -0700

Group - 

I have few questions on CCM & it's use in IPSec ESP mode. The questions
are related to construction of AAD blocks required for authentication
purposes.

1) Construction of AAD blocks in CCM in general

RFC 3610 specifies construction of B_0, B_1 blocks 
The construction of B_0 has been clearly defined. This block is followed
by length encoding of "a" followed by "a" itself, as per the following
paragraph in the spec:
 
Blocks encoding a are formed by concatenating this string that encodes
l(a) with a itself, and splitting the result into 16-octet blocks, and
then padding the last block with zeros if necessary. These blocks are
appended to the first block B_0.

Does this mean the following:

B_1 = encoding(l(a)) || a || pad (to the next 16 octet block )

Hence, the AAD block stream then consists of 
B_0 || B_1 || m_0 || m_1 ... || m_n (padding, if required) 

[Q] Please confirm whether the interpretation of B_1 construction is
correct. 

2) Construction of AAD blocks in IPSec ESP mode 

Does B_1 definition mean the following in IPSec ESP mode 
AAD_IPSec = SPI || SEQ_Num

B_1 = encoding (l (AAD_IPSec)) ||  AAD_IPsec || pad (to the next 16
octet block) 

[Q] Please confirm construction of B_1 block in IPSec mode is correct.

3) Computing CBC-MAC in CCM Mode With IPsec ESP
CCM spec (RFC 3610) implies that authentication is done on the plain
text (and not the cipher text). 

However, IPSec ESP mode states that encryption is done prior to
authentication. Does this order change in the
draft-ietf-ipsec-ciph-aes-ccm-05.txt, meaning that authentication is
done after CTR-encryption? If so, is the CBC-MAC encrypted again. 

My interpretation is that the order still remains the same as specified
in RFC 3610, i.e. authentication is on  plain text and not cipher text. 

[Q] Please indicate what is the correct order of processing on the
outbound side.

Thanks for your time. 

Regards,
Yogesh 

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Apr 2005 04:07:33 -0400

At 1:30 PM -0700 4/6/05, Bansal, Yogesh wrote:
>	<SNIP>

look at ESP v3. drafts of this document have been around for quite a 
while. it has just been approved by the IESG and is now in the RFC 
Editor's hands. It has an explicit discussion of how to process 
packets when a combined mode algorithm (confidentiality and 
integrity) is employed.

Steve

---

From: Russ Housley <[email-masked]>
Date: Thu, 07 Apr 2005 14:39:59 -0400

>[Q] Please confirm whether the interpretation of B_1 construction is

Sometimes.  When 0 < l(a) < (2^16 - 2^8), then B0 includes l(a).  In this 
case, B1 begins with a.

>[Q] Please confirm construction of B_1 block in IPSec mode is correct.

The answer to this is found in draft-ietf-ipsec-ciph-aes-ccm-05.txt, which 
is in the RFC Editor queue.  Section 5 shows the two cases for AAD 
construction.  In both cases, l(a) is less than (2^16 - 2^8), so l(a) is 
encoded as part of B0.  Thus, B1 contains only the SPI and the sequence 
number.  The two cases are the traditional sequence number, which is 32 
bits, and the extended sequence number, which is 64 bits.  In either case, 
the total length of the AAD is less than one block, and padding is needed.

>[Q] Please indicate what is the correct order of processing on the

Authentication is done first.

Please make sure that you are following draft-ietf-ipsec-esp-v3-10.txt, 
which is also in the RFC Editor queue.  This document includes support for 
authenticated encryption modes like CCM.  This support is not available in 
ESP v2 (RFC 2406).

Russ