Re: Comments on the GGF GSS-API extensions proposal

Sam Hartman wrote:
> 
> >>>>> "Nicolas" == Nicolas Williams <[email protected]> writes:
> 
>     Nicolas> 3.  Can you explain again why the
>     Nicolas> GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION option is
>     Nicolas> needed, why the per-msg token functions shouldn't always
>     Nicolas> fail when the context is expired, period?
> 
> I think this basically boils down to making application protocols
> simpler.  It's particularly true for SASL that having contexts expire
> is mostly unacceptable in practice.
> 
> AN argument could be made that the SASL GSSAPI mechanism (or all SASL
> applications) should support rekeying.  Honestly, for most
> applications I just don't think it is worth the complexity.  ANd the
> designers of these protocols tend to agree with me.  Things like FTP,
> many proprietary GSSAPI applications, etc do not support rekeying.
> There is of course the notable exception of SAP.

Thanks. :)

Reality shows that hardly anyone has implemented security context
expiration.  The larger fraction of Kerberos 5 gssapi mechanisms only
has it because rfc-1964 requires it.  Curiously Microsoft disabled
it in the Microsoft Kerberos SSP after devastating tests with
having it active in W2K3 beta -- little if any of their RPC and application
code was able to cope with it either.

I agree that dealing with gssapi security context expiration requires
an enormous  protocol complexity.  However the worst thing about it
(and about how Kerberos implements it) is would be extremely complex
("expensive) to implement it reliably:

  - the application needs to address the issue that a security context
    may expire at a time when there are still unprocessed protected
    messsages in transit or waiting in network buffers or message queues
    to be processed.  Possible approaches:
     - app-level unprotected retransmission queues
       (=most reliable, most expensive)
     - security context renegotiation with a safety margin prior to
       context expiration so that the likelyhood of protected messages
       expiring "in transit" is very low
       (=reasonable compromise, remaining risk of connection abort)
    I implemented the latter

  - In Kerberos, the security context lifetime is derived from the
    credentials, although independent security contexts have independent
    session keys, and the reasoning for security context expiration was
    that no keys should be valid forever.
    The problem with rfc-1964 is that if you don't think about the
    effect, you might write code that goes into a tight loop trying
    to establish a new security context (expecting longer lifetime
    that for the context one has been using).  If the TGT hasn't been
    refreshed, then the lifetime of the new security context will be
    exactly the same as the lifetime of the old one (if GSS_C_INDEFINITE
    is requested), namely the lifetime of the service ticket in the AP_REQ
    which was copied from the TGTs lifetime.

    Therefore my code currently uses a plausibility check whether the
    credentials lifetime is longer than the security context lifetime
    before it tries to renegotiate a successor security context,
    and there are delays imposed on how often a security context "refresh"
    will be attempted, and when security context refresh fails, the
    message protection will continue on the original security context.

  - it requires a bidirectional message exchange for the security
    context establishment at a time determined by the gssapi mechanism,
    which might be quite unusual for the (legacy) application (protocols),
    e.g. the FTP data channel.

  - it requires a synchronized handshake and switch-over to messages
    protected under the new security context between both peers,
    flushing of message queues on the communication channel

  - only the initiator can initiate a replacement security context,
    so if the acceptor thinks a renegotiation should be performed,
    it needs to request the initiator to actually try it.

-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]