[27679] in Kerberos
Re: GSS-API routine for renewing credentials
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Wed Apr 18 18:03:59 2007
Date: Wed, 18 Apr 2007 17:01:19 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Robert <rob_krb@xs4all.nl>
Message-ID: <20070418220119.GW4375@Sun.COM>
Mail-Followup-To: Robert <rob_krb@xs4all.nl>, kerberos@mit.edu
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <000401c78202$43a37600$8ff5fea9@rapido>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
