PROXY tickets and GSSAPI

[Nicolas Williams]

Wyllys,

You seem to be confusing ticket forwarding and proxying. Ticket proxying
is, indeed, useless, UNLESS you have an OOB channel over which the
remote side can keep requesting new proxied tickets or unless you know
exactly which service tickets to proxy over during the initial sec
context establishment. Whereas ticket forwarding is the same as ticket
proxying, but you proxy over a TGT, not a mere mortal service ticket
and, since TGTs are more useful that service tickets, ticket forwarding
is more useful that ticket proxying.

Now, the gss_accept_sec_context() API has a pointer argument by which
the acceptor can get the initiator's "delegated creds" (whether they be
forwarded TGTs or proxied service tickets, one or many) and your
acceptor can then turn around and use these delegated creds to initiate
other sec contexts on behalf of the initiator (what a mouthful).

Now, if your app is all GSS-based and never needs to do Kerberos stuff
directly, then you're set and you can be very happy (provided you can
actually live with that GSS-API...).

But if you need to actually get at the Kerberos tickets because, say,
your app needs to speak Kerberos to other services, or, perhaps, because
your app is more like a shell where the user can then initiate other
programs, including ones that may need to use those Kerberos tickets,
well, then you're stuck. You're stuck because you need to get at those
tickets and the GSS-API, being "generic" doesn't give you a way to peek
under the hood. It's not so bad if you can look under the hood anyways
because, say, you have source, but it sucks anyways.

What we need is a standard API for each GSS mechanism which lets you
convert GSS cred handles into mech-specific/API-specific creds. What I
mean by "standard API" is an IETF RFC, to go along with the likes of
RFC1964, and which specify a GSS-mech-specific API. Then Kerberos
implementors can provide this API and then you're closer to a livable
world. And it'd have to be an IETF RFC because the GSS-API is already
codified in IETF RFCs, even though the IETF shouldn't be in the business
of codifying APIs.

I recommend that you look at Simon Wilkinson's patches to OpenSSH which
implement the GSS key exchange / authentication drafts for SSHv2. Simon
had to find a way to create caches and set KRB5CCNAME for SSHD spawned
shells and other programs. His patches take advantage of his knowledge
of the Heimdal and MIT GSS krb5 implementations; there's enough #ifdefs
in there. And his patches also support the GSI mechanism too.

What's good enough for OpenSSH and Simon Wilkinson (and us, the users of
his patches) ought to be good enough for you, at least until the
necessary "generic" solutions are standardized - until then you can grin
and bear it, or you can kiss GSS goodbye (well, no, you can't do that,
RPCSEC_GSS and all :) ).

Simon's patches are at:

http://www.sxw.org.uk/computing/patches/openssh.html

Cheers,

Nico
--