user2user GSSAPI [was Re: threading best practices?]

[Nico Williams]

I'd like the mech to work for u2u.  I've a proposal:

 - If the initiator knows it wants user-2user then let it send a bogus
AP-REQ (a constant one, actually) with a new APOptions flag that
denotes "I want to do user2user, so gimme a TGT".  If the acceptor
doesn't support this then it will respond with a KRB-ERROR, else with
a Ticket, in which case there's one more round-trip: the AP-REQ with
the user2user Ticket that the initiator is then able to get.
(Aliasing should be handled in the TGS exchange, with the KDC
validating that the 2nd ticket corresponds to the name that the
initiator wanted for the target principal.  Note that this would allow
us to have targets where the initiator doesn't know their name a
priori, something Martin's been wanting for a long time :)

 - If the initiator had a valid service ticket but the acceptor wanted
to do user2user (this is not likely, but hey), then we need a flag in
the AP-REQ (probably an APOption flag, maybe the same as above, and
possibly an authz-data element for the Authenticator) by which the
initiator can indicate its willingness to go on for an additional
round-trip, in which case the acceptor's KRB-ERROR will indicate that
it wants user2user auth and the e-data will bear the acceptor's TGT.

In the first case there's the issue of what happens if the acceptor
doesn't support the new thing: failure.  So you'd have to upgrade the
acceptor, but you were going to have to install new software if you
went with the raw krb5 API anyways...

In the second case there's the issue of what happens if the initiator
doesn't support the new thing: failure, but we don't care because the
second scenario shouldn't happen anyways (unless I'm missing
something).

Nico
--