Re: Comments on the GGF GSS-API extensions proposal

>>>>> "Nicolas" == Nicolas Williams <[email protected]> writes:

    Nicolas> On Thu, Apr 08, 2004 at 01:48:40PM -0400, Sam Hartman
    Nicolas> 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.

    Nicolas> Additional exceptions: SSHv2, ONC RPC w/ RPCSEC_GSS.

    Nicolas> So what's exceptional here?  SASL and FTP?  Or SAP, SSHv2
    Nicolas> and RPCSEC_GSS?

I don't think sshv2 counts really but don't want to go into why.


The answer to your question is that the protocols that support
rekeying are exceptional both by number and by usage.

But that's not the interesting question.  The interesting question is
whether GSSAPI can justify the complexity of requiring rekeying from a
security standpoint.  I say that this complexity is not justified.

--Sam

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]