Re: Please review: http gss authentication mech

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Sun, Nov 12, 2006 at 11:07:03AM -0800, Lisa Dusseault wrote:
> Major architectural concern: I am not enough of a GSS expert to know  
> if this mechanism offers enough information in each roundtrip for a  
> server to be able to reconstruct who the request is from and where  
> they are in the authentication process.

It has enough information in each roundtrip that:

a) it context tokens for one security context will not get mixed up with
another (and failure will result if they do get mixed up as a result of
implementation bugs),

b) when the context is fully established the server will know who the
client is.

This is done at the GSS-API level by tracking _state_ in a security
context, which is an opaque type, both, client and server side.

To avoid server side state the server will "export" (serialize) and
encrypt the security context after processing each context token and
will send back any output context tokens and the encrypted exported
context to the client.  The client will send subsequent context tokens
and the server's encrypted context back to the server.

Rinse, repeat until the security context is fully established, at which
point, since the set of TLS channels with this client [or its proxy] and
this server [or its concentrator] is now bound to that context the
client and server can now rely on TLS to secure their session without
further GSS sec context establishments.  A cookie, or the encrypted
exported fully established security context can then be used as a
cookie-like object to identify all of a client's requests without
actually having to re-authenticate the client.

>                                          The spec only mentions  
> passing GSS tokens resulting from various API calls, and not how  
> these tokens can be used to recover state, or what other state the  
> server must store to put all this together, and how long the server  
> must store that.  For HTTP server farms and non-persistent connection  
> scenarios, it's important to explain this stuff somewhere.

See above.  The key is being able to export (serialize) server-side
GSS-API state.  The GSS-API appears to allow this only for fully
established security contexts, but we think it's trivial to allow it for
partially established security contexts as well.

> Other work todo on this spec, besides the todos already mentioned in  
> the spec:
>       [...]
> 	- Explain the limits on the number of roundtrips (current spec text  
> says "This process continues until either an error occurs or the GSS- 
> API layer has successfully completed...").

The limits on round-trips are given by the underlying mechanism.  The
client can't force an infinite number of round-trips for a single
security context unless the underlying GSS mechanism gives it a way to
do that (I don't know of any that do, nor do I expect any future mechs
to do that).

Do the HTTP implementations need to know a priori the min/max # of
round-trips?

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten