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

[Greg Hudson <[e-mail]>]

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.