Subject: Re: [Cfrg] draft-housley-ccm-mode-00.txt

From: [email-masked] (Peter Gutmann)
Date: Fri, 16 Aug 2002 16:11:28 +1200 (NZST)

"Housley, Russ" <[email-masked]> writes:

>IEEE 802.11 has chosen to make CCM the mandatory to implement AES mode for
>wireless LAN encryption. IEEE 802.15 has also chosen CCM for use with
>personal area networks.  In my opinion, this success is due to the lack of
>a patent (or pending patent from the authors) on CCM.  I suspect that most
>of the members of this list are aware that other candidate authenticated
>encryption modes are encumbered.

Is there a chance that it'd be covered by some other patent?  Having 
recently looked at DH+password mechanisms, I'm wary of algorithms in 
fields where multiple overlapping patents already exist.

>It is my intention to publish draft-housley-ccm-mode-00.txt as an
>Informational RFC.  This looks like the appropriate group to review the
>document.

If it's truly unencumbered, I'd like to see this as standards-track.  I've
been working on an single-pass encrypt+MAC process draft for CMS for use 
in areas like EDI, but a combined mode of operation would be much nicer.

Peter.

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

---

From: [email-masked] (David Wagner)
Date: 16 Aug 2002 11:53:10 GMT

Peter Gutmann wrote:
>If it's truly unencumbered, I'd like to see this as standards-track.

Can you elaborate?  What advantages do you see for CCM over
the standard encrypt-then-authenticate generic composition of
AES-CBC encryption and AES-CBC-MAC (suitably modified to be
secure for variable-length messages)?  The latter is unencumbered
and has the same performance characteristics as CCM.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 16 Aug 2002 09:39:13 -0400

>fields where multiple overlapping patents already exist.

The authors are unaware of any issued patents that cover CCM.  None of the 
authors have filed patents that cover CCM.  Non of the authors are aware of 
any filed, but not yet issued, patents that cover CCM.

>in areas like EDI, but a combined mode of operation would be much nicer.

Generally, the algorithm specification is published as in Informational 
RFC, then standards-track RFCs reference the Informational RFC.  In this 
way, the algorithm becomes mandatory to implement.

Russ

---

From: "David A. Mcgrew" <[email-masked]>
Date: Fri, 16 Aug 2002 07:07:37 -0700

Peter, Russ,

> >Informational RFC.  This looks like the appropriate group to review the

absolutely.

> in areas like EDI, but a combined mode of operation would be much nicer.

I'm not sure exactly what you mean by standards track.  One of the goals of
CFRG is to provide review of and discussion about informational RFCs on
crypto mechanisms.  Our hope is that these RFCs will prove useful to IETF
WGs, and may be adopted into standards-track work in the IETF.  Of course,
as an IRTF group we don't have a standards-track ourselves.

Perhaps you meant that you'd like to see the CCM ID become a CFRG ID, which
sounds fine to me.

David
[email-masked]

---

From: Gé Weijers <[email-masked]>
Date: Fri, 16 Aug 2002 09:51:06 -0700

>and has the same performance characteristics as CCM.
An advantage I can see is the use of the same key for both 
authentication and encryption. I'm not aware of any proof of security 
for an encrypt-then-authenticate design that holds up when you use the 
same key for both encryption and authentication. Using the same key 
halves the key storage requirements for an 802.11 base station.. CCM 
tries to ensure that the likelihood of collisions follows the usual 
birthday bound curve, and the article claims that encrypting the MAC 
value makes analysis of the MAC value impossible.

The proof of security will make for an interesting read.

Gé

---

From: David Wagner <[email-masked]>
Date: Fri, 16 Aug 2002 10:07:17 -0700 (PDT)

> authentication and encryption. [...] Using the same key 
> halves the key storage requirements for an 802.11 base station.

It is easy to achieve the same thing with the standard generic
composition.  You pick a 128-bit key, and derive the encryption and
authentication keys separately using a PRF: Ke = F_K(0), Ka = F_K(1).
This is all very standard, and is done in IPSec and TLS, for instance.
So I don't see this as an advantage or an disadvantage.

---

From: Gé Weijers <[email-masked]>
Date: Fri, 16 Aug 2002 11:48:50 -0700

>So I don't see this as an advantage or an disadvantage.
In an embedded environment where space and power are very constrained 
(802.11 card) halving the space requirement and reducing the amount of 
key scheduling that needs to be performed can certainly be helpful. Many 
current generation 802.11b cards lose about 40% throughput when WEP is 
enabled. The simpler the better.

Ge'

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 16 Aug 2002 16:33:16 -0400

David:

This requires the implementation to compute the key schedules for two 
keys.  In low end devices, storing these key schedules consumes significant 
memory, or recomputing them consumes significant cycles.  Neither is 
desirable in such devices.

Russ

---

From: Carl Ellison <[email-masked]>
Date: Sat, 17 Aug 2002 05:06:28 -0700

At 11:48 AM 8/16/2002 -0700, Gé Weijers wrote:
>In an embedded environment where space and power are very
>constrained  (802.11 card) halving the space requirement and
>reducing the amount of  key scheduling that needs to be performed
>can certainly be helpful. Many  current generation 802.11b cards
>lose about 40% throughput when WEP is  enabled. The simpler the
>better.

I can appreciate less-is-better arguments, in some absolute sense,
but I have trouble believing that even a simple card would have
trouble finding another 16 bytes for a second key.  WEP devices
stored 4 keys and had the logic to find the right one to use.

[You might argue that you need multiple keys, WEP-style, but I don't
buy the number 4.  If I need multiple keys for something, then I need
one key (set) per device I'm communicating with, not just a small
number of keys.]

 - Carl

+--------------------------------------------------------+
|Carl Ellison      Intel Labs        E: [email-masked] |
|2111 NE 25th Ave                    T: +1-503-264-2900  |
|Hillsboro OR 97124                  F: +1-503-264-6225  |
|PGP Key ID: 0xFE5AF240              C: +1-503-819-6618  |
|  1FDB 2770 08D7 8540 E157  AAB4 CC6A 0466 FE5A F240    |
+--------------------------------------------------------+