PROXY tickets and GSSAPI

[Wyllys Ingersoll]

Nico -
    You are correct, I'm a bit confused about the diffs between proxy tix
and forwarded tix.    I understand that the proxy tickets are service 
tickets
and the forwarded tix are TGTs.  Im trying to get my hands around the
problem of actually sending a useable service ticket (with the proxy flag
set) to a GSSAPI service.     I know that the TGT will be forwarded in the
gss_init_sec_context call when the delegation flag is set, but how would one
send the service ticket with the proxy flag - is this where the OOB exchange
between the client and proxy server comes into play?

-Wyllys

Nicolas Williams wrote:
> 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