GSS-API routine for renewing credentials

Simon Wilkinson simon at sxw.org.uk
Wed Apr 18 18:40:57 EDT 2007


On 18 Apr 2007, at 22:41, Robert wrote:

>
> The client should actually not be bothered by the need to initiate  
> a new
> security context with the gateway. That's what you indicate, right?
> (The gateway may need the delegated credentials to initiate a new  
> security
> context to a second backend server (silentl failover)).

I've implemented something similar to this for OpenSSH (patches  
available from http://www.sxw.org.uk/computing/patches/openssh.html )  
- it works as follows:

The client regularly checks it's credentials to see if they've  
changed. If they have,  and they're still suitable [1] it initiates a  
rekey with the server - this causes a new GSSAPI context to be  
established, and a new set of credentials to be delegated

The server accepts delegated credentials upon rekeys. If the client  
has delegated credentials, and they're suitable [2], it stores them  
into the same credentials cache as it stored the credentials  
delegated with the initial connection.

There's a few gotcha's that you need to be careful of, if you're  
doing this for interactive services. These are mainly to do with the  
fact that the user may change the contents of the credential cache on  
both the client and server, in ways that mean that it's no longer  
appropriate to delegate credentials from (or to) that cache.

[1] The user may kinit as a different user on the client. At this  
point, it may no longer be appropriate to delegate these credentials  
to the server. With SSH, you also have to be careful because once  
started, rekey must successfully complete or the connection must be  
torn down. It's important to make sure that the client's credentials  
can be used for a rekey, before that rekey is commenced.

[2] The user may have kinit'd as a different user on the server. In  
this case, they might be very surprised if their credentials cache on  
the server suddenly switched back to being the same as the one they  
originally connected with.

Simon.




More information about the Kerberos mailing list