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

[Benjamin Kaduk <[e-mail]>]

On Fri, 7 Nov 2014, Nico Williams wrote:

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

Well, I think the acceptor application should be prepared to handle one if
it gets one, but maybe the initiator doesn't always need to make/send one.

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

Right, that was clear to me from reading the draft; I just don't have an
answer.

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

I also feel uneasy about the latter.

-Ben

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