GSS-API routine for renewing credentials - Kerberos

This is a discussion on GSS-API routine for renewing credentials - Kerberos ; 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...

+ Reply to Thread
Results 1 to 7 of 7

Thread: GSS-API routine for renewing credentials

  1. 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


  2. 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


  3. Re: GSS-API routine for renewing credentials


    ----- Original Message -----
    From: "Nicolas Williams"
    To: "Robert"
    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


  4. 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


  5. 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


  6. Re: GSS-API routine for renewing credentials


    ----- Original Message -----
    From: "Nicolas Williams"
    To: "Robert"
    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


  7. 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


+ Reply to Thread