Reuse of GSSAPI Tokens

[Douglas E. Engert]

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  
> application:
> 
> 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
the deleg_cred_handle.

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  
>> context,
>> 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
>>> http://www.devoesquared.com
>>> PowerCard - Intuitive Project Management Software for Mac OS X
>>> --------------------------------------------------------------------- 
>>> ---
>>> _______________________________________________
>>> krbdev mailing list             krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>
>> -- 
>>
>>  Douglas E. Engert  <DEEngert at anl.gov>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444
>>
> 
> -- 
> Jiva DeVoe
> http://www.devoesquared.com
> 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
  (630) 252-5444