Subject: Text on re-keying for rfc2222bis

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Aug 2004 19:09:13 -0500

Diffs for section 6.3:

--- /tmp/sasl-6.3-orig	Fri Aug  6 19:08:10 2004
+++ /tmp/sasl-6.3	Fri Aug  6 19:08:00 2004
@@ -1,5 +1,6 @@
+
 6.3.  Multiple authentications
 
    Unless otherwise stated by the protocol's profile, only one
    successful SASL negotiation may occur in a protocol session.  In this
    case, once an authentication protocol exchange has successfully
@@ -8,18 +9,22 @@
 
    If a profile explicitly permits multiple successful SASL negotiations
    to occur, then in no case may multiple security layers be
    simultaneously in effect.  If a security layer is in effect and a
    subsequent SASL negotiation selects a second security layer, then the
-   second security layer replaces the first. If a security layer is in
-   effect and a subsequent SASL negotiation selects no security layer,
-   the original security layer remains in effect.
+   second security layer replaces the first; this can be used as a form
+   of re-keying, where SASL mechanisms that provide security layers fail
+   to provide for re-keying, provided that the authenticated identities
+   remain the same.  If a security layer is in effect and a subsequent
+   SASL negotiation selects no security layer, the original security
+   layer remains in effect.
 
    Where a protocol profile permits multiple successful SASL
    negotiations, the profile MUST detail the effect of a failed SASL
    negotiation upon the previously established authentication state.
    In particular, it MUST state whether the previously established
    authenticated state remain in force or whether the connection is to
    revert to an non-authenticated state. Regardless of the specified
    effect upon authentication state, the previously negotiated security
    layer remains in effect.
+

New text for the security considerations section:

   The secure or administratively permitted lifetimes of SASL
   mechanisms' security layers are finite.  The use of cryptographic
   keys and the passage of time after the initial use of a cryptographic
   key weakens said keys by increasing the amount of ciphertext, other
   cryptographic material, and/or time that is available to
   cryptanalysts in any effort to attack the security layers.

   Administrative limits on security layers lifetime may take the form
   of time limits expressed in x.509 certificates, Kerberos V tickets,
   or in directories, and are often desired.

   In practice one likely effect of administrative security layers
   lifetime limits is that applications may find that security layers
   stop working in the middle of application protocol operation, such
   as, perhaps, during large data transfers.

   SASL does not provide for re-keying.  SASL mechanisms may; all future
   SASL mechanisms that provide security layers SHOULD provide for
   re-keying.

   Applications that wish to re-key SASL security layers where the
   mechanism does not provide for re-keying should re-authenticate the
   same IDs and replace the expired or soon-to-expire security layers.
   This approach requires support for re-keying in the application
   protocols.  See section 6.3.

Sorry for the delay.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Aug 2004 17:27:32 -0400

I'm a bit uncomfortable saying that SASL mechanisms should support
rekeying.  I'm not sure that the community understands what this would
mean well enough that mechanisms would converge on solutions with
similar properties.

Also, do we want to point out that for interop reasons SASL mechanisms
may want to provide advisory notice that rekeying is necessary rather
than invalidating security contexts.  I'm particularly concerned about
the transferring large file case.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2004 03:27:17 -0500

> mean well enough that mechanisms would converge on solutions with

Ok, how about this:

   SASL mechanisms that support re-keying SHOULD:
   
    - indicate that re-keying is or will be needed immediately;

    - provide re-keying messages or transparently include re-keying
      messages in the security layers; the latter can happen without
      application involvement, but only as long as the application is
      engaged in timely bidirectional exchanges with its peer.

> the transferring large file case.

I sympathize.  I don't mind seeing text in rfc2222bis about advisory vs.
mandatory security layer expiration.  But I think that text about this
that is specific to the GSS mechanisms seems well beyond the scope of
rfc2222bis.  Suggestions?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Aug 2004 17:27:32 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2004 03:27:17 -0500

Ok, how about this:

Nico
--