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

[Benjamin Kaduk <[e-mail]>]

On Wed, 11 Feb 2015, Greg Hudson wrote:

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

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.

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

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

I agree that the change is needed.

-Ben