Subject: [kitten] AD review of draft-ietf-kitten-cammac

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 01:34:34 +0000

Hiya,

Sorry for being a bit slow with this. Some nitty points below, but
it's fine to consider 'em with any other LC comments and I'll now
start the IETF LC.

Thanks,
S.

- intro: I hate the term "trusted services" if you had a better one,
life would be a little nicer:-) But I guess that's baked in, though
you really only mean a host key I guess.

- I had to read section 3 twice, though it has been ages since I
delved into Kerberos detail. I think a diagram might help many
readers, but am fine if you think implementers wouldn't need that.

- the conditions in section 8 for when it's ok to create a new CAMMAC
without verifying the old are not very clear to this reader but do
look ok.  Would a bit of pseudo-code help maybe?

---

From: Simo Sorce <[email-masked]>
Date: Tue, 25 Nov 2014 14:20:41 -0500

On Tue, 25 Nov 2014 01:34:34 +0000

> you really only mean a host key I guess.

Not necessarily a host key, someone may just decide to use a different
service principal key, perhaps one dedicated just to the task. That's
why the plural and the "trusted".

> readers, but am fine if you think implementers wouldn't need that.

I am quite biased, as an author, as I've been working through the
details so much they are quite familiar to me. That said I think an
implementer should find the descriptions clear enough that there are
no ambiguities or difficulties in determining the meaning of the text.

> look ok.  Would a bit of pseudo-code help maybe?

I am not sure pseudo-code is really needed, if an implementer really
has doubts he can simply always attach all required signatures and
always verify them, there is never a case where a party would fail
because everything is in place :)

Simo.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Nov 2014 15:17:02 -0500 (EST)

> no ambiguities or difficulties in determining the meaning of the text.

To add a slightly less biased opinion (though as shepherd, I'm still quite
familiar with the document), I reread section 3 just now, and don't see
anything where a diagram would substantially help an implementor who is
already familiar with the AD-KDC-ISSUED container.

> because everything is in place :)

Well, the KDC should always verify any signatures which are present on the
old CAMMAC.  Simo is right that always putting in all the signatures will
always be fine.  The two exceptions boil down to (1) when the target
service of the ticket is the KDC itself, so the kdc-verifier and
svc-verifier are redundant, and (2) the CAMMAC is being used where
AD-KDC-ISSUED would have been sufficient, in which case omitting the
kdc-verifier brings the security properties in line with those of
AD-KDC-ISSUED.  I think it's easier to just state those two cases than try
to represent them in pseudocode, which would probably not actually be more
clear than text.

-Ben