Re: GSS-API routine for renewing credentials
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. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS-API routine for renewing credentials
- Original Message - From: "Nicolas Williams" <[EMAIL PROTECTED]> To: "Robert" <[EMAIL PROTECTED]> Cc: Sent: Thursday, April 19, 2007 0:01 Subject: Re: GSS-API routine for renewing credentials > 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 > -- I do have control over the protocol (That is, in one instance. Another instance will probably make use of SASL). Thanks for your elaborate answer. It's much appreciated. I 'll go and play around with it a bit. Thanks, Robert Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS-API routine for renewing credentials
On Thu, Apr 19, 2007 at 12:10:12AM +0200, Robert wrote: > I do have control over the protocol (That is, in one instance. Another > instance will > probably make use of SASL). Thanks for your elaborate answer. It's much > appreciated. > I 'll go and play around with it a bit. Even if you're using SASL, if you have control over the application protocol you may still be able to signal the peer to tear down the SASL security layers and start over with new SASL authentication and security layers. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS-API routine for renewing credentials
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
Re: GSS-API routine for renewing credentials
- Original Message - From: "Nicolas Williams" <[EMAIL PROTECTED]> To: "Robert" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, April 18, 2007 22:23 Subject: Re: GSS-API routine for renewing credentials > 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. > > Nico > -- 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)). Robert Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS-API routine for renewing credentials
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. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
GSS-API routine for renewing credentials
Hi, 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. Thanks, Robert Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
