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 -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
