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

From: Greg Hudson <[email-masked]>
Date: Wed, 11 Feb 2015 16:19:26 -0500

draft-ietf-kitten-cammac is in the RFC editor queue, so I assume it's
too late to make any non-trivial corrections, but we noticed an issue
with the security considerations section when going over cross-realm
scenarios.

When we decided to make kdc-verifier optional, we provided guidance to
KDC implementors to avoid attacks where services can forge CAMMAC data
and get KDCs to put kdc-verifiers on them.  So we wrote:

    The KDC MUST NOT create a new CAMMAC from an existing one unless the
    existing CAMMAC has a valid kdc-verifier, with two exceptions:

    1. [Local TGTs under certain assumptions about realm KDCs]

    2. [Ticket modification requests, but the KDC] MUST NOT place a
       kdc-verifier in the new CAMMAC.

We missed a third case.  If the header ticket is an incoming cross-realm
TGT, any CAMMACs in that ticket can only be verified with the
svc-verifier; the kdc-verifier, if present, will be signed with the
foreign realm's local TGS key.  (Section 4 makes it clear that the
kdc-verifier always uses the local TGS key and the svc-veriifer uses the
cross TGS key for cross-realm TGTs.)  Nevertheless, the KDC may choose
to filter and propagate CAMMAC-signed authdata originating from the
foreign realm.  For example, a KDC might choose to propagate
authentication indicators, perhaps translating them into local realm
indicator conventions, since only the foreign realm can know how the
client originally authenticated.  If the local KDC is propagating
authdata originating from the foreign realm, it must place a local realm
kdc-verifier on the CAMMAC it produces if the issued ticket might be
used in an S4U2Proxy request.

I suspect we will have to submit an errata for this, amending "two
exceptions" to "three exceptions" and adding a third exception to cover
the case of incoming cross-realm requests.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Feb 2015 13:47:12 -0500 (EST)

> with the security considerations section when going over cross-realm

It appears to not be too late.

% The document draft-ietf-kitten-cammac-01 has changed from RFC-EDITOR
% state to IESG state. We thought you'd like to know. You can also follow
% your document's state at
% <http://www.rfc-editor.org/queue2.html#draft-ietf-kitten-cammac>. For
% definitions of state names, please see:
% <http://www.rfc-editor.org/state_def.html>.

But, we should decide what new text we wish to insert.

> the case of incoming cross-realm requests.

Do you want to come up with a concrete proposal for new text?

I agree that the change is needed.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Thu, 12 Feb 2015 16:21:17 -0500

> Do you want to come up with a concrete proposal for new text?

Sure.  In section 8 (Security Considerations), replace "two exceptions"
with "three exceptions," and add a third item to the list:

---
3. If the ticket server principal is a cross-realm TGS from a different
realm, the CAMMAC's kdc-verifier cannot be validated because the
checksum was made using the other realm's local TGS key.  If the
CAMMAC's svc-verifier is valid, the CAMMAC contents can be safely
assumed to have originated from the other realm.  The KDC SHOULD NOT
blindly copy CAMMAC elements originating from another realm, but MAY
choose to filter, transform, and propagate elements according to policy
rules, and MAY place a kdc-verifier in the new CAMMAC containing the
resulting authorization data elements.
---

I use MUST NOT instead of SHOULD NOT because a KDC might be in a
subsidiary relationship to a higher-security realm.  By "cross-realm TGS
from a different realm," I mean an incoming cross-realm krbtgt principal
like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell
that out.

---

From: Tom Yu <[email-masked]>
Date: Thu, 12 Feb 2015 18:13:25 -0500

> like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell

This seems backwards to me; you wrote "KDC SHOULD NOT blindly copy"
in your suggested text.  Which did you intend?

I would like to try to reason about this from a data origin
authentication standpoint.  This might help us come up with more clear
and generally applicable wording.  On the other hand, if we want to
minimize textual changes, reasoning about this might help us avoid
missing edge cases when we make the more minimal changes.

The kdc-verifier provides data origin authentication that the CAMMAC
contents originated from the KDC itself (or another KDC serving the same
local realm).  If the KDC successfully validates the kdc-verifier, it
can copy the CAMMAC contents knowing that either it or another KDC in
the realm originated the contents.  There is also the local TGT special
case.  In the other cases, where it can only validate the svc-verifier,
it must apply some policy about the provenance of the contents of the
CAMMAC to decide whether to copy the contents verbatim, filter, or
transform them.  This includes both the non-S4U2Proxy service tickets
and the cross-realm TGTs.

Exception (1) in the document is for the case where the
ticket-encrypting key is a key that only other KDCs in the local realm
know, and therefore provides the same properties of data origin
authentication that the kdc-verifier would.  Exception (2) is different,
because the KDC has no assurance that the CAMMAC contents originated
from it or another KDC serving the same local realm.  In this case, the
KDC makes a policy decision that the only consumers of the possibly
forged CAMMAC contents that it copies into a new CAMMAC are consumers
that would not suffer adverse effects from such a forgery.

In the cross-realm case, the local realm KDC can only validate the
svc-verifier (because the only remote realm KDC can validate the
kdc-verifier).  The local realm KDC makes a policy decision about how to
filter, transform, etc. the original CAMMAC contents to a new CAMMAC.

I guess this is a roundabout way of suggesting text that includes:

   The KDC SHOULD NOT make verbatim copies of CAMMAC contents into a new
   CAMMAC when it cannot validate the original CAMMAC as authentically
   originating from itself or another KDC in its local realm.  In such a
   situation, the KDC MAY choose to filter, transform, or propagate
   elements from the original CAMMAC to a new CAMMAC according to policy
   rules, and MAY place a kdc-verifier in the new CAMMAC containing the
   resulting authorization data elements.

   The two individually sufficient conditions for a KDC validating a
   CAMMAC as authentically originating from itself or another KDC in its
   local realm are:

      1. The KDC successfully validates the kdc-verifier of the CAMMAC; or

      2. The CAMMAC lacks a kdc-verifier, but the encryption key for its
         surrounding ticket is one known exclusively by the local realm
         KDCs (e.g., when the ticket is a local TGT), and all KDCs
         serving the realm are configured to filter out CAMMAC
         authorization data submitted by clients.

Then we would somehow modify existing explanatory text about the
specific use cases, e.g.:

1. omission of kdc-verifier to make TGTs, etc., smaller -- safe to make
   verbatim copies if the local realm KDCs are configured properly

2. omission of kdc-verifier when the only consumers of the CAMMAC are
   the original service principal of the ticket (no S4U2Proxy
   privileges) -- apply policy rules

3. incoming cross-realm TGTs -- apply policy rules

---

From: Greg Hudson <[email-masked]>
Date: Thu, 12 Feb 2015 23:38:26 -0500

On 02/12/2015 06:13 PM, Tom Yu wrote:
>> I use MUST NOT instead of SHOULD NOT because[...]
>

Sorry, editing error.  I meant to say "I use SHOULD NOT instead of MUST
NOT because...".

> authentication standpoint.

Your reasoning about data origin authentication matches my reasoning
about the ways a KDC can safely process an incoming CAMMAC.

> I guess this is a roundabout way of suggesting text that includes:

I have no objection to this presentation and can review the full
alternative section 8 text if you want to write it.  I don't know if
rewriting this much text would necessitate another working group or IETF
last call; that might be a consideration.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Feb 2015 13:55:22 -0500 (EST)

>    originating from itself or another KDC in its local realm.  In such a

The SHOULD NOT here makes me slightly uncomfortable.  (I understand Greg's
reasons for suggesting it, though.)  Can we say something about MUST NOT
... as originating from itself or another KDC in its local realm or [some
other trusted KDC; wording TBD]?  This could potentially even include the
cross-realm case.

>    situation, the KDC MAY choose to filter, transform, or propagate

I think that what "such a situation" is potentially unclear and should be
specified more concretely.

>    CAMMAC as authentically originating from itself or another KDC in its

That's a rather complicated sentence; I expect it would confuse some
readers.

>    privileges) -- apply policy rules

Would these involve changes outside section 8?

-Ben

---

From: Simo Sorce <[email-masked]>
Date: Wed, 18 Feb 2015 14:18:36 -0500

> other trusted KDC; wording TBD]?  This could potentially even include the

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.

This is less verbose and should be easier to read. It sill make clear
(IMO) that CAMMAC can be trusted only if the KDC trusts fully one of the
originators, which can be the local Realm's key or a Trusted Realm key,
up to local policy.

> specified more concretely.

See my proposal above to make this part also less unclear. There is no
need for "such situation", the KDC may *always* choose top do as it
wishes with the CAMMAC.

HTH,
Simo.

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 20 Feb 2015 16:04:44 -0500 (EST)

>         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).

> need for "such situation", the KDC may *always* choose top do as it

And that is true; the KDC can always choose to do whatever it wants, in
some sense.

-Ben

---

From: Tom Yu <[email-masked]>
Date: Thu, 26 Feb 2015 15:40:01 -0500

> it (we just have to get it right).

I prefer to avoid using the word "trusted" here.

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

(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.)

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".

---

From: Simo Sorce <[email-masked]>
Date: Thu, 26 Feb 2015 15:47:56 -0500

> I prefer to avoid using the word "trusted" here.

Can we use "authorized" or something similar ?

>    local realm KDCs, and all local realm KDCs properly filter out

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.

> 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).

> 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.

---

From: Tom Yu <[email-masked]>
Date: Thu, 26 Feb 2015 16:40:20 -0500

> Can we use "authorized" or something similar ?

We could, or we could describe the concepts in terms of KDC policies.

> say the key must be known only by the local realm KDCS and it is not the

I think it's not necessary to include cross-realm in (2).  Almost by
definition, a cross-realm TGT doesn't originate from the local realm.
(I guess a local realm KDC could forge one, because it has the key, but
I think there's not much point in analyzing that use case.)

> a key you do not known (the other's realm tgt key).

The cross-realm key is also known to the KDCs of the remote realm, so I
think it doesn't call into this set of definitions.  We can consider the
cross-realm case when we describe policies for CAMMACs not authenticated
by local realm KDC-only principals.

> part that mentions filtering).

[...]

> tell implementors what to pay attention to).

You make a good point that there might be cases where a policy allows
the KDC to make verbatim copies of CAMMAC contents in cross-realm TGTs
from specific "trusted" remote realms.

We could provide examples of local policies that would allow verbatim
copying of CAMMAC not originating from a local realm KDC.  Some would
be:

1. svc-verifier is for a cross-realm TGS principal, and policy allows
   the KDC to copy that realm's CAMMAC contents verbatim.

2. kdc-verifier is absent, svc-verifier is present and valid, but is for
   a non-KDC service.  Typically only allow verbatim copying if the only
   possible consumer is the same service principal as the original
   ticket, but don't apply a kdc-verifier.  This is the use case where
   there's a policy that prohibits the service from using S4U2Proxy, and
   the KDC omits kdc-verifier to save space in the ticket.