Re: [Ipsec] CCM: AAD construction

Yogesh:

>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.

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

>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.

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.

>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.

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

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