Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc

From: Sam Hartman <[email-masked]>
Date: Thu, 01 Aug 2013 08:40:05 -0400

*blink*
why do we ever want to make enctype optional even it can be inferred?
We've never done that before that I am aware of.
Enctype is always explicit in Kerberos.

---

From: Simo Sorce <[email-masked]>
Date: Thu, 01 Aug 2013 08:53:03 -0400

> Enctype is always explicit in Kerberos.

The reasoning was that the KDC krbtgt has only ever one enctype so we do
not need to provide it. I was not totally convinced at first, but it
saves a few bytes so I am ok if others agree.
If you feel strongly that it would be an error I am also ok making it
mandatory. Basically I do not have a problem either way.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Greg Hudson <[email-masked]>
Date: Thu, 01 Aug 2013 10:18:37 -0400

> Enctype is always explicit in Kerberos.

Enctype has always been explicit for ciphertexts, not for checksums.
Most of the time when we include a checksum in Kerberos, we include the
cksumtype and specify what key should be used somehow.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Aug 2013 14:44:16 -0400

> mandatory. Basically I do not have a problem either way.

I think agree with Sam here.  The enctype should always be explicit.
There is no requirement in the spec or protocol that krbtgt or any other
principal only have keys of one enctype.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Thu, 01 Aug 2013 20:18:33 -0400

> principal only have keys of one enctype.

On the other hand, AD-KDCIssued does not have an enctype, because the
key for the checksum is implicitly the same as the one the KDC used to
encrypt the ticket.  This is a precedent for omitting the enctype when
it should be obvious from context.

---

From: Greg Hudson <[email-masked]>
Date: Thu, 01 Aug 2013 20:27:40 -0400

> principal only have keys of one enctype.

I don't see how that's relevant.  A KDC implementation would omit the
enctype in the KDC verifier because it thinks it can deduce the enctype
(by always using the first key, for instance), not because it assumes
there is only one enctype in the krbtgt principal.

To expand on what I said before, it's disingenuous to call this a
departure from current practice because "the enctype is always explicit
in Kerberos."  The enctype is always explicit in ciphertext because it
specifies the kind of encryption operation which was used to generate
the ciphertext.  In this case, the enctype would be there for a
different purpose (key identification), and it is not normal practice in
Kerberos to include an enctype with a checksum if the key can be
identified without one.

---

From: Simo Sorce <[email-masked]>
Date: Tue, 06 Aug 2013 21:52:12 -0400

> Kerberos to include an enctype with a checksum if the key can be

Although I agree that it would be perfectly safe if the enctype were
optional, given the strong feeling by Sam and Jeffrey I am fine leaving
it as required.

Sam, Jeffrey,
do you have any other objection on the structure ?

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Aug 2013 23:01:19 -0500

I have no strong feeling. I forgot this was a checksum. Disregard my comment.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Aug 2013 13:55:05 -0400 (EDT)

> Kerberos to include an enctype with a checksum if the key can be

I don't personally care very much whether the enctype is mandatory here, 
but I don't think any of the objections to making it optional that have 
appeared so far are of particular technical merit. [Ed. I guess this is 
partially overtaken by events while I was drafting this mail.]

Anyways, I've gotten to do a more careful review of the entire document, 
comments below.

Section 3, first sentence, s/insure/ensure/.  There is no monetary 
compensation involved, here :)

The description of the Trusted Service MAC a bit confusing, I might 
reword it as "The Trusted Service MAC is not required, but can be useful 
when the authorization data is received by a less-trusted service and a 
more-trusted service is available on the same host.  In this case the 
authorization data can be verified without an additional round trip to the 
KDC."

In section 4.1, the description of the Verifier-MAC is very 
abstract/high-level.  I would prefer something more concrete in a document 
of this nature.

Now that AD-CAMMAC-BINDING is left to the implementation, we could say 
that about the encoding as well as the contents, and not necessarily 
require the OCTET STRING form.

Looking at the kdc-verifier, the string "TGS key" appears only once in RFC 
4120, and not in a definition.  Do we want this slight informality, or 
would "the service key of the ticket-granting service" be better? 
Additionally, mandatory checksum types are bound to encryption types, not 
keys, so it might be more pedantically correct to say the "mandatory 
checksum type for the TGS key's enctype".  (I am not explicitly asking for 
that.)

I noticed while going through that RFC 3961 never uses the term "mandatory 
checksum", it is the "required checksum". :)

In the other-verifiers description, we still have a parenthetical "(which 
one?)", resolution of which is the point of the thread I'm hijacking.

The discussion of AD-CAMMAC-BINDING in the security considerations which 
we talked about previously will also be helpful.

That's all the new stuff from this round of review.

-Ben