Subject: [core] coap #55 (new): AES-CCM vs. AES-CBC

From: "core issue tracker" <[email-masked]>
Date: Sat, 06 Nov 2010 16:13:00 -0000

#55: AES-CCM vs. AES-CBC

 As AES-CCM is more suitabe to most low-power RF chips such as 802.15.4,
 Section 10 should consider cypher suites that make use of it intead of
 AES-CBC.

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  trivial             |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/55>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Sun, 07 Nov 2010 14:44:59 -0000

#55: AES-CCM vs. AES-CBC

Comment(by zach@…):

 DTLS [RFC4347] does not current support Authenticated Encryption with
 Additional Data (AEAD) cyphers like CCM. AEAD support was added to TLS 1.2
 but this is no currently defined with DTLS. (Thanks to Robert Cragie for
 pointing that out)

 Proposal is to encourage TLS working group to add TLS 1.2 support to DTLS.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/55#comment:1>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Sun, 21 Nov 2010 07:08:39 -0000

#55: AES-CCM vs. AES-CBC

> Section 10 should consider cypher suites that make use of it intead of

New description:

 As AES-CCM is more suitable to most low-power RF chips such as 802.15.4,
 Section 10 should consider cipher suites that make use of it instead of
 AES-CBC.

--

Comment(by cabo@…):

 We probably should be referencing (informative):

 Cipher suites:
  * I-D.mcgrew-tls-aes-ccm
  * I-D.mcgrew-tls-aes-ccm-ecc

 DTLS 1.2:
  * I-D.ietf-tls-rfc4347-bis

 The latter is now in "Publication requested state".  Still, it is not a
 normative reference as the use of DTLS is not a "MUST implement". (Also, I
 think many other references currently specified as normative aren't.)

 (and s/cypher/cipher/g)

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/55#comment:2>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Sun, 21 Nov 2010 08:42:32 -0000

#55: AES-CCM vs. AES-CBC

Comment(by cabo@…):

 Re IPsec, add a brief discussion (expanding the existing reference to
 section 9 of RFC 4309) about the requirements AES-CCM places on key
 establishment (i.e., the traditional manual keying approach does not work
 vert well here).

 More generally speaking, this text about key establishment should also
 point out that anti-replay requires a protocol to manage keys and sequence
 numbers.

 (the above are channeling comments by Eric Rescorla in http://www.ietf.org
 /mail-archive/web/core/current/msg01061.html which discusses this in more
 detail and also contains text from RFC 4303 that we might use.)

 If Tero Kivinen's lightweight IKE draft becomes available in time; add a
 reference to that (as relevant work in progress).

Ticket URL: <https://svn.tools.ietf.org/wg/core/trac/ticket/55#comment:3>
core <http://tools.ietf.org/core/>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2010 13:35:43 -0800

I'm not sure that non-normative text really does the job here. If you're
going to use
CCM, you pretty much need automatic key management. Is that something you
intend
t require or not...

-Ekr

On Sun, Nov 21, 2010 at 12:42 AM, core issue tracker <[email-masked]>wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Nov 2010 10:37:59 +0100

On Nov 28, 2010, at 22:35, Eric Rescorla wrote:

> I'm not sure that non-normative text really does the job here. If you're going to use
> CCM, you pretty much need automatic key management. Is that something you intend
> t require or not...

Interesting discussion.

I view CoAP as a protocol standard, not a system standard.
(And, yes, I'm fully aware that the security of a single protocol often cannot be evaluated without speculating about the surrounding system -- this has long been one of the unresolved dilemmas in IETF standardization.)

We are not defining new security mechanisms, we are pointing out ones that CoAP would work well with.
(Alexey's "must implement" discussion is relevant here, but somewhat orthogonal to my current point.)
To me, your comment reads a bit like "RFC 4309's security considerations are insufficient, so let's fix them in CoAP".
I'd rather reference them (possibly cite them, and maybe reinforce them where they are worded a bit too cautiously) as opposed to second-guess/"improve" them.
Getting normative about the system (as opposed to the protocol) should be avoided whenever possible.

(But I don't have a strong opinion on the specific issue of ruling out static keys for AES-CCM, which appears to remain a valid restriction even while the system around the protocol changes.)

Gruesse, Carsten

PS.: Interestingly, RFC 4309 doesn't even spend a SHOULD:

   Therefore, AES CCM should not be used with statically configured
   keys.

I'd like to know the history on that one.

---

From: Rene Struik <[email-masked]>
Date: Mon, 29 Nov 2010 11:49:52 -0500

Dear Carsten:

RFC 4309 specifies how to use CCM mode of operation with IPSec.

Some brief observations below. (These comments suggest that the use of 
the CCM mode, as specified with RFC 4309, is highly problematic, both 
from a security perspective, from per-packet data expansion perspective, 
with regard to offered security services, and as to imposed key 
management constraints.)

1) Data expansion.
Total per-packet data expansion is at least 12 bytes:
a) Data authentication.
According to Section 2 of RFC 4309, only authentication tags that are a 
multiple of 4 bytes are allowed; moreover,  authentication tags of 
length M=4 bytes are not allowed. Thus, per-packet data expansion due to 
authentication is minimally 8 bytes.
b) Initialization vector.
According to Section 3 of RFC 4309, the ESP payload includes a 8-byte 
IV. Thus, per-packet security admin overhead is minimally 8 bytes.

2) Nonce construction.
a) Small nonce space.
According to Section 2 of RFC 4309, the CCM mode uses L=4, thus reducing 
the nonce space to 11 octets only. As comparison, both IEEE 802.15.4, 
ISA SP100.11a, and, e.g., IETF RoLL rpl specification use a 13-octet nonce.
b) Problematic support for group key scenarios.
Nonce construction does not seem to easily cater to scenarios where one 
has a group key shared with more than two devices. With IEEE 802.15.4, 
ISA SP100.11a, and, e.g., IETF RoLL rpl, the nonce values generated by 
different originators of a packet do not clash by design. With RFC 4309, 
by constrast, it is not trivial to assure a partition of the nonce space 
according to the originator of a secured packet (from description in 
Section 4 of RFC 4309, this would somehow require inter-device 
coordination of the 8-byte IV value and avoidance of clashes between 
3-byte Salt values [which, due to the birthday paradox is bound to 
happen with probability 50% for 2^{12} generated random 24-bit values]).

3) Key management.
a) Salt value.
According to Section 7.1 of RFC 4309, Salt values are generated as a 
by-product of the establishment of keying material. This begs the 
question as to how these Salt values are distributed in group key 
settings. Example (hup-and-spoke trust model): a security manager 
function may distribute keys to all other nodes in a network. If two of 
those nodes now wish to communicate to each other, the recipient 
requires access to the originator's salt value (which is not included in 
the communicated packet).
b) Use of keying material.
According to Section 9 of RFC 4309, the CCM mode should not be used with 
statically configured keys. While this is indeed advisable from a key 
lifecycle management perspective, this requirement for secure operation 
of the CCM mode itself is more relaxed: One should simply not invoke the 
mechanism with the same nonce value during the lifetime of the key 
(thus, re-emphasizing the need to assure this in group key settings, 
e.g., via partitioning of the nonce space according to device id).
c) Different salt values for channel A-to-B and channel B-to-A.
According to Section 9 of RFC 4309, one must use different Salt values 
when communicating from A to B than when traversing this communication 
channel the other way around (from B to A). This begs the question as to 
how this should be realized.

4) Security services offered.
a) Replay protection not supported.
RFC 4309 does not seem to support replay protection. With IEEE 802.15.4, 
ISA SP100.11a, and, e.g., IETF RoLL rpl, replay protection is provided 
via maintenance of some local state information on a recipient device (a 
counter value of the originator) and use of monotonically increasing 
counters with the nonce, so as to be able to detect duplicates.

Best regards, Rene

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 Nov 2010 10:44:57 -0700

This all gets into a complicated area of how to split up protocols and system but generally the protocol needs to provide security (obviously security is also a system property but my point is it also often a protocol property). 

I would be very surprised to see the IESG approve CORE without specifying at least one MTI keying scheme.

Cullen <with my co-chair hat on>