Reuse of GSSAPI Tokens
Douglas E. Engert
deengert at anl.gov
Thu Jul 21 16:26:56 EDT 2005
Jiva DeVoe wrote:
> I can establish multiple contexts through multiple init/accept iterations.
> It's just if I wanted to do init/accept/accept/accept that I can't do it.
> What I was hoping to accomplish was the ability to use a token by
> multiple servers to authenticate a given request. (All servers would
> be using the same service credential).
> Given the following scenario, A and B are servers, C is a client
> C creates a token using *_init_* and gives it to A to access a resource.
> A verifies it's ok by passing it to *_accept_*
> A now wants to pass the request from C on to B on behalf of C (because
> B has some resource A doesn't have) so A forwards the token on to B.
> B verifies C's token again, and returns with some data.
> Is there a "preferred" way to do this?
What you are talking about is delegation, where C authenticates
to A and also passes on a delegated credential to A that can be
used at A to authenticate to other servers like B.
With GSSAPI, the client sets the GSS_C_DELEGATE flag, and the
gss_accept_sec_context will have a delegated credential in
But there are not many options, so what Kerberos does is to
delegate a TGT to A that can be used by A to impersonate B.
This is a full TGT. This works well with something like
SSH where a user logs on and wants a full TGT. But if A is just
a service which C only partially trusts, C may not want
to delegate a full TGT. (When using AD as the KDC, they added
an ok_to_delegate flag to services that the AD KDC trust enough
to tel the client that it is OK to do a full delegation.)
> I imagine the preferred way might be something like:
> C and A authenticate each other with A/C tokens
> A and B authenticate each other with A/B Tokens
> Because B trusts A, he assumes C is OK because A tells him so.
But that was not what you said above. You said A could not
authenticate to B so needed to have C do it. If B is willing to
trust that A says he is working on befalf of C without C proving it,
then you don't need delegation.
The problem with the current delegation via GSS is it all or nothing.
But how much does C trust A? How much is C willing to delegate to A?
(I believe Windows AD with SSPI can do some limited delegation.)
> On Jul 21, 2005, at 2:38 PM, Douglas E. Engert wrote:
>> Jiva DeVoe wrote:
>>> Is it possible to use a token generated by the GSSAPI call
>>> gss_init_sec_context call to establish more than one security
>>> context via the gss_accept_sec_context call?
>> No. Generically speaking with GSS, you don't know what is in the token,
>> and the underlying mechanism may require the exchange a number of tokens
>> before returning success.
>>> Meaning, can I pass a token to gss_accept more than once? In my
>>> testing, it appears I can't. Subsequent calls result in an invalid
>>> context. If this is the case, I'm curious how this is done, since
>>> my token appears to be unchanged.
>> Why do you need to do this in the first place?
>> Generically speeking you should be able to establish more then one
>> but you must go through the gss_init_sec_context/ gss_accept_sec_context
>> loop for each context. If the Kerberos gssapi mechanism is not letting
>> you do this, then there is a problem.
>>> Jiva DeVoe
>>> PowerCard - Intuitive Project Management Software for Mac OS X
>>> krbdev mailing list krbdev at mit.edu
>> Douglas E. Engert <DEEngert at anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
> Jiva DeVoe
> PowerCard - Intuitive Project Management Software for Mac OS X
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the krbdev