Subject: [Ietf-krb-wg] Request WG adoption of draft-kanno-krbwg-camellia-ccm-01 ----- RE: FW: New Version Notification for draft-kanno-krbwg-camellia-ccm-01

From: "Thomas Hardjono" <[email-masked]>
Date: Tue, 3 Aug 2010 13:12:24 -0400

Larry, JHutz,

We would like to ask that the Kerberos WG adopt as a wg item
the Camellia CCM draft (draft-kanno-krbwg-camellia-ccm-01).
The desired destination/status is Standards Track.

Is there any other steps we need take in order
to get the draft adopted as WG item?

Thanks.

/thomas/

_________________

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of Thomas Hardjono
> Sent: Monday, July 05, 2010 10:49 AM
> To: [email-masked]
> Subject: [Ietf-krb-wg] FW: New Version Notification for draft-kanno-
> krbwg-camellia-ccm-01
> 
> 
> 
> Sorry folks, we found a couple of bugs in the doc and have corrected
> them.
> 
> New version (01) has just been uploaded.
> 
> /thomas/
> 
> 
> ________________________________________
> From: IETF I-D Submission Tool [[email-masked]]
> Sent: Monday, July 05, 2010 10:48 AM
> To: Thomas Hardjono
> Cc: [email-masked]; [email-masked]; Tom Yu
> Subject: New Version Notification for
draft-kanno-krbwg-camellia-ccm-01
> 
> A new version of I-D, draft-kanno-krbwg-camellia-ccm-01.txt has been
> successfully submitted by Thomas Hardjono and posted to the IETF
> repository.
> 
> Filename:        draft-kanno-krbwg-camellia-ccm
> Revision:        01
> Title:           Kerberos Support for Camellia Cipher in CCM Mode
> Creation_date:   2010-07-05
> WG ID:           Independent Submission
> Number_of_pages: 9
> 
> Abstract:
> This draft proposes the Kerberos (v5) support for the Camellia
Cipher
> in Counter with CBC-MAC (CCM) mode.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Aug 2010 16:09:34 -0400

> to get the draft adopted as WG item?

For that to happen, you'll need to convince the working group that it 
wishes to take on this work.  When last this was discussed, there seemed to 
be a strong sense in the room that it would be a good idea, but this was 
before the IPR disclosures and associated licensing terms were available 
for the WG to review.  Several WG members have indicated that the IPR 
issues would be an important factor.

Since there's been no further discussion, I think it's premature to issue a 
consensus call, but perhaps we can spark some discussion or comments from 
WG participants.

-- Jeff

---

From: Greg Hudson <[email-masked]>
Date: Tue, 03 Aug 2010 16:32:44 -0400

On Tue, 2010-08-03 at 16:09 -0400, Jeffrey Hutzelman wrote:
> Several WG members have indicated that the IPR 

There are standards-track RFCs for the use of Camellia in:

* CMS (RFC 3657)
* TLS (RFC 5932)
* IPSEC (RFC 4312, 5529)

Is that sufficient to allay people's concerns about IPR issues?  (If any
of the people present at the meeting who voiced concerns are reading
this conversation, that is.)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 3 Aug 2010 16:36:57 -0700

IIRC there was a concern (or maybe an actual pronouncement?) that the permissions granted for the use of Camellia did not extend to its use in Kerberos.  Anyone got a pointer to the actual state of affairs?

> this conversation, that is.)

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Aug 2010 22:46:06 -0400

--On Tuesday, August 03, 2010 04:36:57 PM -0700 "Henry B. Hotz" 
<[email-masked]> wrote:

> IIRC there was a concern (or maybe an actual pronouncement?) that the
> permissions granted for the use of Camellia did not extend to its use in
> Kerberos.  Anyone got a pointer to the actual state of affairs?

At the time of the WG meeting in Anaheim, the IPR disclosure relating to 
Kerberos had not yet been filed, and so the licensing terms with respect to 
Kerberos were not formally available.  I think they were expected to and 
did turn out to be analogous to those for other protocols, but don't take 
my word for it; look for yourself.  My search of the IETF IPR disclosure 
databsae found the following:  <https://datatracker.ietf.org/ipr/1304/>

-- Jeff

---

From: Greg Hudson <[email-masked]>
Date: Tue, 03 Aug 2010 21:16:30 -0400

On Tue, 2010-08-03 at 19:36 -0400, Henry B. Hotz wrote:
> permissions granted for the use of Camellia did not extend to its use
> in Kerberos.  Anyone got a pointer to the actual state of affairs?

https://datatracker.ietf.org/ipr/1304/

contains an IPR statement specifically relating to Kerberos.

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 4 Aug 2010 10:09:43 -0400

Here are some previous IETF IPR statements relating to Camellia:

OpenPGP (dated 4 July 2007):
http://www.ietf.org/ietf-ftp/IPR/ntt-and-mitsubishi-ipr-camellia.pdf

IPsec (dated 25 April 2005):
http://www.ietf.org/ietf-ftp/IPR/mitsubishi-ntt-joint-ipr-disclosure.pdf

/thomas/

__________________________________________

> [email-masked]] On Behalf Of Greg Hudson
> Sent: Tuesday, August 03, 2010 9:17 PM
> To: Henry B. Hotz
> Cc: [email-masked]
> Subject: Re: [Ietf-krb-wg] Request WG adoption of draft-kanno-krbwg-
> camellia-ccm-01 ----- RE: FW: New Version Notification for draft-kanno-
> krbwg-camellia-ccm-01
>

---

From: "Thomas Hardjono" <[email-masked]>
Date: Fri, 6 Aug 2010 09:52:20 -0400

Let ask the working group: folks, does anyone have any objections
to the Kerberos WG adopting as a work item the Camellia-CCM draft?
(aimed at Standards-Track).

http://tools.ietf.org/id/draft-kanno-krbwg-camellia-ccm-02.txt

(ps. I believe the IPR question has been clarified/answered).

Thanks.

/thomas/

> Sent: Wednesday, August 04, 2010 10:10 AM
> To: Greg Hudson; [email-masked]
> Cc: [email-masked]
> > > IIRC there was a concern (or maybe an actual pronouncement?)
that
> > > the permissions granted for the use of Camellia did not extend
to
> > > its use in Kerberos.  Anyone got a pointer to the actual state
of
> affairs?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 06 Aug 2010 13:26:10 -0400

> http://tools.ietf.org/id/draft-kanno-krbwg-camellia-ccm-02.txt

I'm not looking for lack of objection.  The standard is active support and 
rough consensus to adopt the work.  So by all means, folks, if you support 
the WG taking on this work, speak up.  The same goes if you have questions, 
comments, or objections.

> (ps. I believe the IPR question has been clarified/answered).

The only process requirement here is that the IPR disclosure be filed. 
However, it is explicitly within the working group's right to take the 
presence of IPR claims and the details of the terms offered into account 
when deciding what, if anything, to do with a technology.

-- Jeff

---

From: "Thomas Hardjono" <[email-masked]>
Date: Fri, 6 Aug 2010 14:19:26 -0400

> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: Friday, August 06, 2010 1:26 PM
> To: Thomas Hardjono; [email-masked]
> Cc: [email-masked]

Apologies JHutz, but what did you mean by "filed"?

http://www.ietf.org/ietf-ftp/IPR/ntt-and-mitsubishi-ipr-camellia-2.pdf

Thanks.

/thomas/

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 06 Aug 2010 14:54:55 -0400

> https://datatracker.ietf.org/ipr/1304/

Exactly this.

---

From: Tom Yu <[email-masked]>
Date: Fri, 06 Aug 2010 15:34:56 -0400

>> https://datatracker.ietf.org/ipr/1304/

As I recall, the only strong IPR-related objection had been that the
disclosure was not yet filed/published.  What opinions do people have
now about how the patent situation should affect WG adoption of the
work on Camellia enctypes?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 6 Aug 2010 13:11:12 -0700

On Aug 6, 2010, at 10:26 AM, Jeffrey Hutzelman wrote:

> I'm not looking for lack of objection.

OK.  ;-)

I support the idea of having a first-class encryption type like Camellia defined, implemented, and available as a "backup" to AES, in the event that some problem is discovered with AES.

I'll go further and say I think the IPR filing is good enough, so we can concentrate on the technical issues.  I still have no comment on the specific draft at this time.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 6 Aug 2010 23:12:16 +0200

Tom, Jeff,

> work on Camellia enctypes?

I believe there is nothing stopping adoption and assigning protocol numbers.

However, given that AES is w/o restriction and new new proposed enctype has restrictions of use (regardless what they are), I would object to make it RECOMMENDED and MUST support given that I feel that there are no technical reasons for doing this (only political).

Love

---

From: Luke Howard <[email-masked]>
Date: Sat, 7 Aug 2010 11:37:29 +0200

> However, given that AES is w/o restriction and new new proposed enctype has restrictions of use (regardless what they are), I would object to make it RECOMMENDED and MUST support given that I feel…

Is there any objection to specifying a CCM or GCM mode for AES?

-- Luke

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 6 Aug 2010 08:26:09 -0700

No objections.  (This is not a review of the draft contents, merely the subject.)

I'd be happier if the IPR declaration were in better english, but the intent appears to be what we need.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Aug 2010 16:32:35 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Tue, 2010-08-03 at 16:09 -0400, Jeffrey Hutzelman wrote:
    >> Several WG members have indicated that the IPR issues would be an
    >> important factor.

    Greg> There are standards-track RFCs for the use of Camellia in:

    Greg> * CMS (RFC 3657) * TLS (RFC 5932) * IPSEC (RFC 4312, 5529)

    Greg> Is that sufficient to allay people's concerns about IPR
    Greg> issues?  (If any of the people present at the meeting who
    Greg> voiced concerns are reading this conversation, that is.)

That's unrelated to any concerns about IPR issues in my mind.
I think the sorts of things that I'd like to know the answers to here
are:

* If Simon believes he could ship an implementation of this spec in his
  product * If redhat believes they could ship an implementation of
  this.

I expect I can get an answer from Simon; it would not surprise me if RH
declined to answer.

Also, people should be aware that there was a security area discussion
at SAAG Thursday of the IETF meeting in an attempt to find a general
security-area policy on what should be standards-track and what should
not.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Aug 2010 08:45:55 -0400

Tom>As I recall, the only strong IPR-related objection had been that the
Tom>disclosure was not yet filed/published.  What opinions do people have
Tom>now about how the patent situation should affect WG adoption of the
Tom>work on Camellia enctypes?

That may have been true at the mic.  Over Jabber, I think Love, Nico and
Simon were involved in a discussion about whether the terms would be a
problem for open-source.
I definitely recall Simon in that discussion; I'm fairly sure Love
chimed in.
I'm less sure of Nico.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Tue, 10 Aug 2010 12:52:35 -0400

On Mon, 2010-08-09 at 16:32 -0400, Sam Hartman wrote:
>   product

> * If redhat believes they could ship an implementation of
>   this.

Debian and Red Hat (in Fedora) both appear to be distributing an NSS
library with Camellia included.  Does that bear on the question?

Of course, I'm not saying that we have to do X, or even that X is
necessarily okay to do, just because other people in other domains did
X.  But it's possible that we are overthinking this issue.

> security-area policy on what should be standards-track and what should

Did anything relevant come out of that?  Tom says nobody has uploaded
SAAG minutes yet.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Aug 2010 13:32:27 -0400

Greg> On Mon, 2010-08-09 at 16:32 -0400, Sam Hartman wrote:
    >> * If Simon believes he could ship an implementation of this spec
    >> in his product

    >> * If redhat believes they could ship an implementation of this.

    Greg> Debian and Red Hat (in Fedora) both appear to be distributing
    Greg> an NSS library with Camellia included.  Does that bear on the
    Greg> question?

Yes, that's very interesting information.

    >> Also, people should be aware that there was a security area
    >> discussion at SAAG Thursday of the IETF meeting in an attempt to
    >> find a general security-area policy on what should be
    >> standards-track and what should not.

    Greg> Did anything relevant come out of that?  Tom says nobody has
    Greg> uploaded SAAG minutes yet.

I'm not sure what happened where.  Sean sent out some recommendations to
a few reviewers; there was a discussion at secdir; there was a
discussion at SAAG.  The secdir discussion was longer than the SAAG
discussion.  There seems to be a lot of support for being fairly
restrictive in what ciphers are  standards-track.

My analysis is that a couple of things are getting muddle together.
First is a desire to be restrictive in what ciphers we recommend people
implement. Somehow that's getting muddled together with standards-track
vs ninformational.  Another issue is that people are concerned that
we're being kind of arbitrary in what we make standards-track and what
is informational.  I think that is one of the forces pushing us towards
being restrictive.

I certainly don't see anything firm enough that we should feel bound by
it in this WG at this time.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 00:21:46 +0200

> http://tools.ietf.org/id/draft-kanno-krbwg-camellia-ccm-02.txt

I would support assigning code points and publishing it as
Informational.

I do not support making patented ciphers (even with what can be regarded
today as a permissive license) become required to implement and on the
standards track.  Doing that paves the way to the slippery slope where
we accept patented ciphers with different licenses just because we've
done that before.  We have a good unencumbered cipher available today in
AES.

I see reasons to specify how an alternative to AES works in Kerberos but
I don't see any reason to make it required to implement or a standard
track feature until AES actually have been broken.  When AES breaks, we
can discuss what the preferred alternative should be, and consider
moving Camellia-CCM from Informational to Standards Track.

Organization that wants to use Camellia for political reasons are free
to use it even if it is Informational.

I like AEAD modes in general, and it would be nice to have a AES-GCM
mode for Kerberos, although I'm not certain it is worth the
(significant) effort to migrate away from the current AES enctype.

/Simon

---

From: Greg Hudson <[email-masked]>
Date: Fri, 13 Aug 2010 20:27:42 -0400

> (significant) effort to migrate away from the current AES enctype.

Some notes about CCM vs. GCM:

* Luke did an experimental GCM enctype implementation, and noted that
without pre-computation, it was significantly slower than CCM.  Since
Kerberos constructs a lot of keys and throws them away after one use,
GCM is not necessarily a great performance fit.  An application wrapping
a large amount of data with GSS might benefit, but a KDC under heavy
load would suffer, as might a server which creates many GSS security
contexts and encrypts only a small amount of data in each.

* It's impossible for Kerberos to guarantee that nonce collision won't
happen with CCM or GCM--in fact, an attacker may be able to induce a
nonce collision by making a large number (around 2^48, with a 96-bit
nonce) of TGS requests for a service principal.  A nonce collision under
CCM only undermines the confidentiality of the two colliding messages; a
nonce collision under GCM undermines the authenticity of all messages
encrypted under that key.  This problem can be managed by increasing the
effective nonce size (by allowing the sender to influence the key
derivation constant), but the need to do so increases the message size
and the enctype's complexity.

The combination of these realizations led me to stop favoring GCM as an
AEAD mode for Kerberos.

On a related note, Sam (if I remember correctly) indicated that we had
bad experiences with using the same keys with multiple enctypes, back in
the bad days of DES.  That means if we specify any other modes of AES,
KDCs probably wouldn't be able to re-use keys--although such enctypes
could be up-negotiated from AES-CTS during an AP-REQ for use as subkeys.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 11:46:22 +0200

> The combination of these realizations led me to stop favoring GCM as an

This is very useful information.  May I suggest some of this discussion
is added to the Camellia-CCM document?  I bet I'm not the only one
wondering why CCM were chosen here.

> could be up-negotiated from AES-CTS during an AP-REQ for use as subkeys.

It was always confusing to have multiple enctypes for the same kind of
key.  It adds complexity to the policy interface and backend storage if
you want to be able to express that an AES-CTS key cannot be used for
AES-CCM (or vice versa).

As much as I like AEAD modes, I believe it will be painful to have both
AES-CTS and AES-CCM and for no practical gain today.  We could specify
how AES-CCM would work though, so that it is ready in case AES-CTS
breaks in a way that doesn't affect AES-CCM, and to get early
implementation experience with it.  Perhaps there is a way to specify
how AES-CTS and AES-CCM could co-exist.  But it should be labeled as
experimental and contain warnings.

/Simon

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 16 Aug 2010 11:01:59 -0400

> [email-masked]] On Behalf Of Simon Josefsson
> Sent: Friday, August 13, 2010 6:22 PM
> To: Thomas Hardjono
> Cc: [email-masked]
> > Lets ask the working group: folks, does anyone have any objections to
> > the Kerberos WG adopting as a work item the Camellia-CCM draft?
> I do not support making patented ciphers (even with what can be
> regarded today as a permissive license) become required to implement
> and on the standards track.  Doing that paves the way to the slippery
> slope where we accept patented ciphers with different licenses just
> because we've done that before.  We have a good unencumbered cipher
> available today in AES.

Thanks Simon.  We're asking for Camellia-CCM to be standards track 
primarily because Camellia is already standards track in the following:

- RFC4312: The Camellia Cipher Algorithm and Its Use With IPsec.
- RFC4132: Addition of Camellia Cipher Suites to TLS.

However, I do understand that the Kerb WG is free to decide 
differently from the TLS WG and the IPsec WG.

/thomas/

---

From: Greg Hudson <[email-masked]>
Date: Mon, 16 Aug 2010 11:29:37 -0400

> wondering why CCM were chosen here.

I can (probably on Wednesday) provide some text for Thomas to include in
a draft update.  My plan is to describe the design choices in the
introduction, unless people think it's better to include a rationale
section near the end.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Aug 2010 12:27:08 -0400

So, where do we stand with this request?

Thomas, Greg and I think Tom have expressed active support for adoption.

Simon has expressed a desire for this to go informational.

I've expressed a desire that krb-wg should only spend time on it if
we're going to do standards-track. (I think letting it be an independent
submission informational would be entirely fine if we decide the right
status is info).

Who else has expressed support or objections?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 16 Aug 2010 09:45:29 -0700

> Who else has expressed support or objections?

I don't think it should be requirement for Kerberos implementors to implement. So I guess I join Simon in the informational crowd.

Love

---

From: Tom Yu <[email-masked]>
Date: Mon, 16 Aug 2010 13:15:46 -0400

Love Hörnquist Åstrand <[email-masked]> writes:

> I don't think it should be requirement for Kerberos implementors to
> implement. So I guess I join Simon in the informational crowd.

What are your opinions on making Camellia-CCM standards-track but not
mandatory to implement?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 16 Aug 2010 10:46:33 -0700

I'm neutral on Camellia specifically.  

I support the idea of having a high-quality required-to-implement "hot backup" for AES in the event it is broken.  Such an alternative should IMO include a different checksum in the event it's not AES, but the checksum that's broken.

---

From: Luke Howard <[email-masked]>
Date: Mon, 16 Aug 2010 20:00:16 +0200

> I support the idea of having a high-quality required-to-implement "hot backup" for AES in the event it is broken.  Such an alternative should IMO include a different checksum in the event it's not…

Right, that's one attribute of CCM and possibly an argument for specifying aes-ccm.

-- Luke

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Aug 2010 20:43:10 +0200

Luke Howard <[email-masked]> writes:

>> I support the idea of having a high-quality required-to-implement
>> "hot backup" for AES in the event it is broken.  Such an alternative
>> should IMO include a different checksum in the event it's not AES,
>> but the checksum that's broken.
>

Given the work that has gone into the Camellia document, it appears
simple to write up a copy of it that uses AES instead.  Maybe there is
some value in having that...

/Simon

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 16 Aug 2010 23:10:49 -0700

> What are your opinions on making Camellia-CCM standards-track but not

No opinion. But unless given more reason to say yes, I would say no.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 16 Aug 2010 23:18:47 -0700

13 aug 2010 kl. 17:27 skrev Greg Hudson:

>  A nonce collision under CCM only undermines the confidentiality of the two colliding messages

I was under the impression the the nonce was used to generate the key stream too.

Love

---

From: Greg Hudson <[email-masked]>
Date: Tue, 17 Aug 2010 11:06:22 -0400

> I was under the impression the the nonce was used to generate the key stream too.

I'm with you up until the word "too".  The fact that the nonce is used
to generate the key stream is precisely why the confidentiality of the
messages is undermined.

In CCM, if two nonces collide, then you have two messages with the same
key stream.  The XOR of the plain texts of both messages can be
recovered without the key--thus, the confidentiality of the two
colliding messages is undermined.  An attacker may also be able to
recover S_0, the first key stream block which gets XOR'd with the
CBC-MAC checksums; but since an attacker cannot easily generate valid
CBC-MAC checksums of other messages, that doesn't allow forgeries.

In GCM, if two nonces collide, then the same confidentiality failure
occurs.  In addition, if the attacker can recover S_0, the attacker can
create forgeries, with the forgeries having the same nonce as the
colliding messages.  This is because the original key is not directly
involved in the construction of the GCM message tag, only the key
stream.

The above is only my best understanding based on the publications
describing CCM and GCM.  I am not a cryptographer.  See also RFC 5116
sections 5.1.1 and 5.3.1.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 17 Aug 2010 08:31:01 -0700

> sections 5.1.1 and 5.3.1.

I misunderstood your previous statement.

I don't think "only" describes the problem strongly enough, its a fatal flaw to have a collision and any proposal to use CCM with Kerberos needs to describe how to generate non repeating nonces, for example when CCM is used in the context of GSS/CFX.

Love

---

From: Greg Hudson <[email-masked]>
Date: Tue, 17 Aug 2010 11:46:44 -0400

On Tue, 2010-08-17 at 11:31 -0400, Love Hörnquist Åstrand wrote:
> I don't think "only" describes the problem strongly enough, its a
> fatal flaw to have a collision and any proposal to use CCM with
> Kerberos needs to describe how to generate non repeating nonces, for
> example when CCM is used in the context of GSS/CFX.

It might be possible to guarantee non-repetition of nonces within
GSS/CFX with enough effort, but that's not the hard problem.  The hard
problem is TGS requests.

That said, I disagree that this is a fatal flaw.  All cryptography
solutions are probabilistic (one-time pad confidentiality aside).  With
aes128-cts, an attacker could pick a single random key and decrypt your
message with 2^-128 probability.

With CCM or GCM, you typically have a 96-bit nonce (which allows a
reasonable maximum message length of 2^24 bytes).  The probability of
observing a collision becomes significant as you approach 2^48 observed
messages.  If you're not inducing the traffic, I think this is a
prohibitive number.  If you are inducing the traffic (e.g. if you are
spamming TGS requests to a KDC), then violating the confidentiality of
the observed messages is probably not useful.

---

From: Tom Yu <[email-masked]>
Date: Tue, 17 Aug 2010 12:52:17 -0400

> the observed messages is probably not useful.

I agree.  An attack that compromises the confidentiality of one pair
of ciphertexts with the same nonce is much weaker than an attack that
takes a pair of ciphertexts with the same nonce and can forge
an arbitrary number of authentic ciphertexts using the same key. (on
top of compromising confidentiality for the pair of ciphertexts)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Aug 2010 14:56:01 -0400

After reviewing Simon's response and the disclosure, I do not personally
have any IPR concerns about this draft.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Wed, 18 Aug 2010 15:43:25 -0400

> restrictive in what ciphers are  standards-track.

In Section 4.1.1 of RFC 2026 ("Internet Standards Process"):

   "A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable."

A I recall, part of the secdir and SAAG discussions revolved around
the concept of requiring "broad international support" for Standards
track cipher suites.  Given the selection of Camellia by the European
Community's NESSIE project:

    https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf

and ISO:

    http://webstore.iec.ch/preview/info_isoiec18033-3%7Bed1.0%7Den.pdf

I would say that there is evidence of broad international support.  It
is interesting to note that the NESSIE report identified IPR problems
with RC6 (and IDEA, but that's a 64-bit block cipher) but not with
Camellia.

(CRYPTREC also selected Camellia, but its relevance is arguably mostly
limited to Japan.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 19 Aug 2010 21:49:11 -0700

> GSS/CFX with enough effort, but that's not the hard problem.  The hard

You are saying that data tranfered in GSS/CFX is somehow is off lesser value for users of Kerberos ?

> That said, I disagree that this is a fatal flaw.

That what the CCM rfc say. "Using the same nonce for two different messages encrypted with the same key destroys the security properties of this mode."

>  All cryptography

Love

---

From: Greg Hudson <[email-masked]>
Date: Fri, 20 Aug 2010 10:52:39 -0400

> value for users of Kerberos ?

Of course not.  I'm saying that when you create a GSSAPI context, you
have some application state alongside the key, which (assuming you made
a subkey) is otherwise unused and which is discarded when the security
context is.

When you make a TGS request, it's to one of several stateless KDCs
possessing the same key, and the key is used for an unlimited period of
time.

> That what the CCM rfc say. "Using the same nonce for two different
> messages encrypted with the same key destroys the security properties
> of this mode."

An attacker guessing your key in one stupidly lucky attempt also
destroys the security properties of any cryptosystem.  The question is
what is required of an attacker to make the probability of a failure
significant.

Some examples of vaguely similar attacks on existing Kerberos enctypes:

* Checksum collisions: upon observing 2^48 messages checksummed with the
existing hmac-sha1-96-aes128, you are likely to have observed at least
one checksum collision, at which point you could substitute the old
message contents for the new one.

* Confounder collisions: if two messages using aes128-cts-hmac-sha1-96
happen to use the same confounder (likely after observing 2^64 messages;
2^32 with des3-hmac-sha1), an attacker can determine whether the
plaintexts of those messages are identical or different.

* Precomputation attack: let's say the same text is being checksummed
with many different aes128-cts-hmac-sha1-96 keys, using the
hmac-sha1-96-aes128 checksum.  An attacker can pre-compute checksums of
2^64 keys, observe 2^64 checksums, and have a high likelihood of
determining the key of at least one observed message.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 20 Aug 2010 08:04:02 -0700

> a subkey) is otherwise unused and which is discarded when the security

But that is not how CFX uses the the kerberos crypto system, it assumes that it can just blindly use it w/o any special hacks for each enctype.

> possessing the same key, and the key is used for an unlimited period of

Until you roll over your key, shouldn't that be a requirement then ?

> Some examples of vaguely similar attacks on existing Kerberos enctypes:

The difference here is that reuse of nonce reveal things about the content which your other examples doesn't.

Love

---

From: Greg Hudson <[email-masked]>
Date: Fri, 20 Aug 2010 11:08:49 -0400

On Fri, 2010-08-20 at 11:04 -0400, Love Hörnquist Åstrand wrote:
> The difference here is that reuse of nonce reveal things about the
> content which your other examples doesn't.

That's not true; the precomputation attack reveals the content of all
messages encrypted with the revealed key.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 20 Aug 2010 08:29:05 -0700

> messages encrypted with the revealed key.

I consider that to be an not relevant case, though worth to point out, since then the attacker knows the data we try to protect and tries to find out if we sent it.

CCM exposes information about the content that we want to have protected and attacker doesn't knows the content.

>>> determining the key of at least one observed message.

-03 draft have added language for ccm telling why its safe to use ccm, however it doesn't cover the specific cases of cfx and tgs, and how to deal with them, I think it must.

I also think that CCM should be defined for AES in the same draft.

Love

---

From: Greg Hudson <[email-masked]>
Date: Fri, 20 Aug 2010 11:38:02 -0400

On Fri, 2010-08-20 at 11:29 -0400, Love Hörnquist Åstrand wrote:
> I consider that to be an not relevant case, though worth to point out,
> since then the attacker knows the data we try to protect and tries to
> find out if we sent it.

No, that's not true.  The same protocol key may have been used to
encrypt data as well as checksum it, and the encrypted data is not known
by the attacker until the key is revealed through a checksum match.
(Key derivation does not help.  The pre-computed keys will be chosen
prior to key derivation, so once a checksum match is found, the attacker
knows the protocol key.)

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 20 Aug 2010 09:20:03 -0700

> prior to key derivation, so once a checksum match is found, the attacker

Doesn't this assume the checksum is over the cipher text ?

This since message M1 and key K1 can generate the same checksum as K2 and M2,
and finding a collision doesn't get you all the Mn that used Kn out there.

This this is far from the CCM discussion.

Love

---

From: Greg Hudson <[email-masked]>
Date: Fri, 20 Aug 2010 12:44:20 -0400

> and finding a collision doesn't get you all the Mn that used Kn out there.

That's not the attack.

The pre-computation attack assumes that there's a predictable plaintext
which is checksummed with many different keys.  The attacker
pre-computes checksums against this plaintext for 2^64 random keys
(choosing the key values prior to derivation) and stores the results.

Then the attacker observes checksums until one matches a pre-computed
value.  It is expected that it will take 2^64 observed checksums before
the attacker finds one which was generated using the same key as one of
the pre-computed keys.  At this point, the attacker knows the
pre-derivation key and can decrypt any ciphertexts which were created
using the same key, or can forge encrypted messages or checksums.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Aug 2010 05:31:01 -0400

FWIW I agree with Greg that probabilistic security with an appropriate
probability bound is what we're after with Kerberos enctypes and in fact
with any use of ciphers in the IETF with which I'm familiar.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg