Reuse of GSSAPI Tokens

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Reuse of GSSAPI Tokens

Jiva DeVoe
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?

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.

--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management Software for Mac OS X


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Nicolas Williams
On Thu, Jul 21, 2005 at 09:37:33AM -0400, 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?
>
> 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.

Replay caching.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Jiva DeVoe
I'm not sure what this means.

Is it possible to use the token twice?  Or not?

I mean, obviously, I could reuse the context itself... am just  
curious if kerberos defines that a token may not be used to establish  
more than one context.

What is Replay caching?

On Jul 21, 2005, at 11:57 AM, Nicolas Williams wrote:

> On Thu, Jul 21, 2005 at 09:37:33AM -0400, 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?
>>
>> 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.
>>
>
> Replay caching.
>
--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management Software for Mac OS X


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Nicolas Williams
On Thu, Jul 21, 2005 at 12:03:46PM -0400, Jiva DeVoe wrote:
> I'm not sure what this means.
>
> Is it possible to use the token twice?  Or not?
>
> I mean, obviously, I could reuse the context itself... am just  
> curious if kerberos defines that a token may not be used to establish  
> more than one context.

Kerberos does that, yes.

> What is Replay caching?

There's a cache of AP-REQs that have been seen in the time skew window
(+- 5 minutes), and none are accepted that have been seen or which fall
outside the replay window.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Jiva DeVoe
Thanks, that's what I needed to know. :)

On Jul 21, 2005, at 12:11 PM, Nicolas Williams wrote:

> On Thu, Jul 21, 2005 at 12:03:46PM -0400, Jiva DeVoe wrote:
>
>> I'm not sure what this means.
>>
>> Is it possible to use the token twice?  Or not?
>>
>> I mean, obviously, I could reuse the context itself... am just
>> curious if kerberos defines that a token may not be used to establish
>> more than one context.
>>
>
> Kerberos does that, yes.
>
>
>> What is Replay caching?
>>
>
> There's a cache of AP-REQs that have been seen in the time skew window
> (+- 5 minutes), and none are accepted that have been seen or which  
> fall
> outside the replay window.
>
--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management Software for Mac OS X


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Douglas E. Engert
In reply to this post by Jiva DeVoe


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             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Jiva DeVoe
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?

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.


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             [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>  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


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Matt Crawford

On Jul 21, 2005, at 14:24, Jiva DeVoe wrote:

> It's just if I wanted to do init/accept/accept/accept that I can't do
> it.

Think about it.

If you, the client, can use a given GSS token again, then I, the
eavesdropper, can do the same.

I think you don't want that.

> C creates a token using *_init_* and gives it to A to access a
> resource.

It may take several client/server exchanges to establish a context.  
What you seek is "credential delegation."

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Jiva DeVoe
Yes, I agree, and I realize this now... thanks for the clarification...

On Jul 21, 2005, at 3:32 PM, Matt Crawford wrote:

>
> On Jul 21, 2005, at 14:24, Jiva DeVoe wrote:
>
>
>> It's just if I wanted to do init/accept/accept/accept that I can't  
>> do it.
>>
>
> Think about it.
>
> If you, the client, can use a given GSS token again, then I, the  
> eavesdropper, can do the same.
>
> I think you don't want that.
>
>
>> C creates a token using *_init_* and gives it to A to access a  
>> resource.
>>
>
> It may take several client/server exchanges to establish a  
> context.  What you seek is "credential delegation."
>
>
--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management Software for Mac OS X


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Reuse of GSSAPI Tokens

Douglas E. Engert
In reply to this post by Jiva DeVoe


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             [hidden email]
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>
>> --
>>
>>  Douglas E. Engert  <[hidden email]>
>>  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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev