Subject: [TLS] TLS_PSK_WITH_AES_128_CCM_8 security parameters

From: Klaus Hartke <[email-masked]>
Date: Mon, 5 Mar 2012 14:09:00 +0100

Dear all / authors of draft-mcgrew-tls-aes-ccm,

I'm trying to implement TLS_PSK_WITH_AES_128_CCM_8
[draft-mcgrew-tls-aes-ccm-03], which is the mandatory-to-implement
cipher suite for implementations of the Constrained Application
Protocol [draft-ietf-core-coap-08] in DTLS PSK mode.

It's surprisingly difficult to find some of the security parameters
for this cipher suite. It would be great if someone could confirm the
following values:

   prf_algorithm = tls_prf_sha256
   bulk_cipher_algorithm = aes
   cipher_type = aead
   enc_key_length = 16 octets
   block_length = 16 octets
   fixed_iv_length = 4 octets
   record_iv_length = 8 octets
   mac_algorithm = null
   mac_length = 0 octets
   mac_key_length = 0 octets
   verify_data_length = 12 octets

Another quite unobvious thing is the value of the
GenericAEADCipher.nonce_explicit field. Maybe something like the
following text could be added to the draft?

   GenericAEADCipher.nonce_explicit MUST be the
   64-bit sequence number (TLS) or the 16-bit epoch
   concatenated with the 48-bit sequence_number
   (DTLS).

Thanks,
Klaus

---

From: Robert Cragie <[email-masked]>
Date: Mon, 05 Mar 2012 16:19:30 +0000

Hi Klaus,

I agree it does take some effort to figure out the chain of documents 
which complete the picture. I wrote this applicability statement for PSK 
TLS in ZigBee IP:

"draft-mcgrew-tls-aes-ccm-03 contains AEAD TLS cipher suites whose AEAD 
part is detailed in rfc5116, which are very similar to rfc5487, which 
references both rfc5288 and the original PSK cipher suite document 
rfc4279, which references TLS 1.2 document rfc5246, which defines the 
TLS messages."

Other comments inline, bracketed by <RCC></RCC>

Robert

>     prf_algorithm = tls_prf_sha256
<RCC>Corrrect; there is only one PRF for TLS 1.2 (see [RFC5246] Section 
A.6)</RCC>
>     bulk_cipher_algorithm = aes
<RCC>Corrrect; implied by 'AES' in the name</RCC>
>     cipher_type = aead
<RCC>Corrrect; as stated in the draft</RCC>
>     enc_key_length = 16 octets
<RCC>Corrrect; implied by 'AES_128' in the name</RCC>
>     block_length = 16 octets
<RCC>Corrrect; implied by 'AES_128' in the name; not relevant for AEAD 
cipher.</RCC>
>     fixed_iv_length = 4 octets
<RCC>Correct; implied in section 3 of the draft (uint32)</RCC>
>     record_iv_length = 8 octets
<RCC>Correct; implied in section 3 of the draft (uint64)</RCC>
>     mac_key_length = 0 octets
<RCC>Correct; implied by use of AEAD cipher</RCC>
>     verify_data_length = 12 octets
<RCC>Correct; as not explicitly specified, 12 octets (from [RFC5246] 
section 7.4.9)</RCC>

>     concatenated with the 48-bit sequence_number
<RCC>
Section 4 refers to section 3 which states:

The "nonce" input to the AEAD algorithm is exactly that of [RFC5288]: 
the "nonce" SHALL be 12 bytes long and is constructed as follows:

struct {
    case client:
       uint32 client_write_IV;  // low order 32-bits
    case server:
       uint32 server_write_IV;  // low order 32-bits
    uint64 seq_num;
} CCMNonce.

It seems reasonably clear to me what 'seq_num' is from [RFC 5246] and 
that it is the GenericAEADcipher.nonce_explicit field. Section 3 
clarifies 'seq_num' for DTLS.
</RCC>
>
>
> Thanks,
> Klaus
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>