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

[Nico Williams <[e-mail]>]

On Sat, Nov 08, 2014 at 08:41:12PM -0500, Benjamin Kaduk wrote:
> On Fri, 7 Nov 2014, Nico Williams wrote:
> > 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.

Agreed, acceptor apps should be required to beprepared to handle them.

Q: Should mechanisms specify outputting such error tokens as well?
A: Optionally, yes. (my answer)

Q: Should initiator apps be expected to send them?
A: Optionally, yes. (my answer)

> > >    [[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.
> >
> > [...]
> 
> Right, that was clear to me from reading the draft; I just don't have
> an answer.

I'm not convinced that the problem doesn't arise.  (An acceptor that
supports both mechanisms but not u2u in the krb5 mech will not offer the
latter if it doesn't have long-term principal keys with which to accept
sec contexts, and the KDC shouldn't return KDC_ERR_MUST_USE_USER2USER if
the acceptor has long-term keys.  But if this should result for some
reason, then we'd have a problem.  In practice this doesn't happen,
won't happen, and anyways, user2user is exceedingly rare.)

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

It's trivial to go with the first.  I'll make it so.

Nico
--