Re: [kitten] Kerberos extra round trips I-D revised

[Nico Williams <[e-mail]>]

On Fri, Nov 07, 2014 at 04:13:06PM -0500, Benjamin Kaduk wrote:
> On Mon, 27 Oct 2014, Nico Williams wrote:
> My summary is: [...]

That's a fine summary.  (Except that I think we seem to agree that
there's no need for an initiator->acceptor error context token.)

> The initiator includes (3) in the follow-up AP-REQ, proving freshness and
> allowing the replay cache to be safely omitted.

Yes.

> The core extension seems like a fine thing to have so I would be okay with
> adopting this as a WG document if we think we have the energy to advance
> it properly.

Thanks.  I hope we do.  I think this is sorely needed.

> There are a few open questions tagged in the document:
> 
>    [[anchor1: Perhaps we should use a checksum 0x8003 [RFC4121]
>    extension instead of authorization data in the authenticator.]]

(FYI, this [[anchorN:...]] business is an artifact of lyx2rfc's
rendering of "revision remarks" -- comments intended for rendering,
effectively.  I should fix this to drop the anchorN business.)

> This is for incorporating the challenge-nonce back into the reply, if I
> understand correctly.  I'm not sure how well that would work if we want to
> allow for stateless acceptors that use nonces similar to the pkinit
> freshness tokens we've been discussing.

It works fine: the acceptor decrypts the Ticket from the AP-REQ, then
the Authenticator from the AP-REQ, recovers the challenge, and validates
it.

The challenge should probably have a timestamp and a counter at the very
least, and should be at least integrity protected.  I.e., it should be
very similar to the PKINIT freshness token.

>    [[anchor2: Question: how should we address this?  We could say "give
>    priority to the user-to-user mechanism", but in some cases that might
>    require changes to the acceptor side.]]
> 
> This refers to the potential for conflict with
> draft-swift-win2k-krb-user2user, which I haven't read, so I can't say much
> about.

Consider an initiator app with a mech with these extensions *and* an
implementation of draft-swift-win2k-krb-user2user.  Now imagine this app
talks to an acceptor app that also has both mechanisms but not these
extensions.  Can we accidentally end up failing to setup a security
context?

That was my question.

However, I'm now convinced that the answer is "no", therefore this
section and remark can be removed.

The reason the answer is "no" is that if the acceptor app has acceptor
credentials for RFC4121 and draft-swift-win2k-krb-user2user then it
should be able to use both, otherwise it should only have acceptor
credentials for one (if that) and only offer to negotiate those
mechanisms for which it has acceptor credentials.  It follows then that
the situation I feared cannot happen.

>    [[anchor3: We could use the GSS_EXTS_FINISHED extension from
>    draft-ietf-kitten-iakerb to implement a strong binding of all context
>    tokens.]]
> 
> I haven't thought about things hard enough to decide whether the gain in
> strength of binding is worth the extra work.

I think it's not worth the extra work, but it's important that the
acceptor either insist that the cname/crealm of the two AP-REQs be the
same, or else ignore the cname/crealm from the first AP-REQ and then
rely only on the second AP-REQ's cname/crealm.  I feel uneasy about the
latter.  For PROT_READY purposes it would be convenient if the two
Authenticators asserted the same sub-session keys too.  I don't think
there's any need to bind any more of the exchange, but then, I like the
binding everything as a generic defensive design security principle.

Nico
--