Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission

[Simo Sorce <[e-mail]>]

On Thu, 2015-02-26 at 15:40 -0500, Tom Yu wrote:
> Benjamin Kaduk <[e-mail]> writes:
> 
> > On Wed, 18 Feb 2015, Simo Sorce wrote:
> >
> >> On Wed, 2015-02-18 at 13:55 -0500, Benjamin Kaduk wrote:
> >>
> >> Would it make more sense to say something like:
> >>
> >>         The KDC MUST NOT make verbatim copies of CAMMAC contents into a
> >>         new CAMMAC unless the original CAMMAC is authenticated by an
> >>         originator that is fully trusted by the KDC.
> >>         The KDC MAY choose to filter, transform, or propagate elements
> >>         from the original CAMMAC according to local policy.
> >
> > It might.  Is this the first time we are using the word "trusted" in a
> > Kerberos RFC, though?  And being concrete does have something going for
> > it (we just have to get it right).
> 
> I prefer to avoid using the word "trusted" here.

Can we use "authorized" or something similar ?

> The KDC makes a policy decision about which CAMMACs have contents that
> are safe to copy verbatim into a new CAMMAC.  We can recommend that the
> KDC limit verbatim CAMMAC copying to cases where only the local realm
> KDCs know the key that authenticates the CAMMAC.
> 
> We could define a term "authenticated as originating from a local realm
> KDC" to mean:
> 
> 1. kdc-verifier is present and validates;
> 
> 2. svc-verifier is present, validates, and uses a key known only to
>    local realm KDCs; or
> 
> 3. no verifiers are present, the ticket-encrypting key is known only to
>    local realm KDCs, and all local realm KDCs properly filter out
>    client-submitted CAMMACs

This definition fails to include cross-realm tgts, because in (2) you
say the key must be known only by the local realm KDCS and it is not the
case fro cross-realm.

> (I think I didn't include case 2 in my earlier message, and think it's
> somewhat unlikely to get used in practice, but I think mentioning it
> makes the definition more complete.)

(2) is fundamental for the cross-realm case where the only thing you can
verify in the local KDC is the svc-verifier, given the kdc-verifier uses
a key you do not known (the other's realm tgt key).

We need to state that it is ok consider the CAMMAC if local policy says
you "trust" another REALM (you will probably not fully trust it, and
perform some filtering, but that is local policy and is captured in the
part that mentions filtering).

> We can say that the KDC SHOULD only make verbatim copies of CAMMAC
> contents to a new CAMMAC when it has authenticated the CAMMAC as
> originating from a local realm KDC.  We might also say that when the KDC
> has not authenticated a CAMMAC as originating from a local realm KDC, it
> SHOULD NOT apply a kdc-verifier to a new CAMMAC whose contents are a
> verbatim copy from that first CAMMAC.  (The cross-realm case is somewhat
> of an exception, though there generally should be some filtering.)
> 
> I guess "verbatim copying" is really shorthand for "verbatim copying
> without a complete policy check on the copied stuff".

I think we should say the KDC should apply policy but not dictate
whether there should necessarily be any filtering.
In a cross-realm case you may "fully-trust" the originating realm and
decide to verbating copy the CAMMAC, in other cases you may have a
different level of trust and apply filtering. The KDC should follow
whatever policy the amdin applies, with reasonable defaults in
implementations (but that is an implementation detail, we just need to
tell implementors what to pay attention to).

Simo.

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