GSS-API routine for renewing credentials

[Nicolas Williams]

On Wed, Apr 18, 2007 at 11:41:03PM +0200, Robert wrote:
> >On Wed, Apr 18, 2007 at 08:25:39PM +0200, Robert wrote:
> >>Does anyone know whether there is a routine in GSS-API to renew 
> >>(forwarded)
> >>client credentials? I'm unable to locate such a routine in GSS-API, but
> >>maybe
> >>I'm overlooking it.
> >
> >There's no such thing.
> >
> >In SSHv2 we deal with this by re-keying the SSHv2 session and, in the
> >process, establishing a new GSS-API security context, which is an
> >opportunity to delegate a new credential.
> >
> >I.e., you have to establish a new security context.
> 
> Thanks Nico.
> 
> I'm just thinking how that would work (if that would work for my situation).
> I looking at this from a client -> gateway -> backend server  perspective.
> 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)).

Do you have control over the protocol that your application is using, or
is it a standard protocol (or de facto standard from you point of view)?

If the former, then just add an option to re-authenticate (establish a
new security context).

If the latter and the protocol is SSHv2, just do what I described
earlier.

If the latter and the protocol is something like IKE/KINK, then just
establish a new SA or equivalent.

If the latter and the protocol is something like ONC RPC w/ RPCSEC_GSS
then just establish a new context (but you need to make sure that you
map the new context to the correct "session" at the application
protocol, if there is such a concept).

If the latter and the protocol is something like FTP, or if it uses
SASL (like IMAP), then you lose: you have to tear down the connection
and start over if you really want to delegate a new credential.

Nico
--