[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] TLS_PSK_WITH_AES_128_CCM_8 security parameters
From:       Robert Cragie <robert.cragie () gridmerge ! com>
Date:       2012-03-05 16:19:30
Message-ID: 4F54E792.1030402 () gridmerge ! com
[Download RAW message or body]


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

On 05/03/2012 1:09 PM, Klaus Hartke wrote:
> 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
<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_algorithm = null
>     mac_length = 0 octets
>     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>

> 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).
<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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


["smime.p7s" (application/pkcs7-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]