Subject: Removing the SASL layer before the TLS layer

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 07 Dec 2004 23:43:47 +0100

The LDAPbis group is discussing to specify that terminating the session
would do something like:
    cease exchanges at the LDAP message layer,
    tear down the SASL layer (if any),
    tear down the TLS layer (if any), and
    close the transport connection.
LDAP specifies that TLS is layered between the transport connection and
any SASL layer, so it certainly looks reasonable to do it in this order.

Kurt tells me that
  a mechanism can define as part of its data security layer a graceful
  closure facility.  This can even be associated with another "kind of
  security services", which the SASL I-D explicitly states mechanisms
  may offer.
He also states that if SASL a mechanism provides a layer closure
facility, it should be used (by LDAP when terminating the session).

However, as far as I can tell rfc2222bis prohibits this:

   3.3 Security layers

   If use of a security layer is negotiated by the authentication
   protocol exchange, the security layer is applied to all subsequent
   data sent over the connection (until another security layer is
   negotiated ( see also section 6.3) or underlying connection is
   closed).

I had taken this to mean that the two interfaces which SASL provides to
remove the layer is to close the connection and to replace the layer.  I
can see no "call the mechanism's graceful closure facility if it exists"
interface, so for a protocol to require this seems to me to require the
use of a private extension to SASL.  That does not seem proper.
Though a protocol implementation may choose to do so, of course.

(A C implementation of SASL as currently specified will provide a
finalization function whether or not the spec says so, since there must
be some call to reclaim memory.  OTOH, this is not so for a garbage
collecting language, unless it includes the misfeature of doing
finalization during garbage collection.)

Also, to my reading, even if a mechanism provides a "graceful closure"
facility which leaves the connection intact, doing anything on the
connection (such as graceful TLS closure) between removing the layer
and closing the connection violates the text from 3.3 above.

Three solutions I see (in addition to possible clarifications of 3.3)
are:

* Provide a "close the SASL layer if the mechanism supports it"
  interface - possibly with the caveats that
  - it MUST NOT be used other than when closing the connection - though
    possibly before doing graceful TLS closure,
  - protocol peers MUST NOT accept other activity on the connection
    afterward.

* Allow the protocol profile to specify that if TLS is active, then when
  the connection is closed in an orderly manner the SASL layer is
  removed before - or after - the TLS layer if possible.
  "If possible" because the mechanism may not support it, or because
  only one protocol peer can invoke SASL layer removal and the
  connection closure is initiated by the wrong protocol peer.

* No change; a protocol should not specify that the SASL layer is
  removed before the TLS layer.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 07 Dec 2004 18:19:10 -0800

>    close the transport connection.

My latest suggested text for the LDAP TS is:
   The client, upon transmission of the UnbindRequest, and
   the server, upon receipt of the UnbindRequest are to
   gracefully close the LDAP session by ceasing exchange
   at the LDAP message layer, tearing down any SASL layer,
   tearing down any TLS layer, and closing the transport
   connection.

>any SASL layer,

[[Also, the LDAP TS defines the terms "SASL layer" as follows:
   The term "SASL layer" refers to SASL services used in providing 
   security services, as well as associations established by these 
   services. 

(and likewise for other layers).   Note that in the LDAP TS,
"layer" is being used both in the sense of a "protocol layer"
and a "data security layer".  So, "tear down any SASL layer"
not only means to terminate, if installed, a SASL data security
layer, but it also means to end any associations established
through the SASL services.  Please see archives of the LDAPBIS
list for discussions regarding this terminology.]]

>so it certainly looks reasonable to do it in this order.

Nothing in either of suggested texts above indicates that
order of statements implies any particular tear down order.
The comma separating the statements means "and", not "and then".

Also, the statements are quite vague.  The primary intent
is to make it quite clear that when the LDAP session ends,
so do the any installed data security layers, so does
the underlying transport connection, and so does any
logical associations in the session.

The current text (see draft-ietf-ldapbis-protocol) also
stated a particular order in which the layers were to be
closed.  This was intended to encourage graceful closure
of the LDAP session (as a whole).  I agree with you that
the current I-D text is too prescriptive, hence recent
suggestions drops the explicit ordering language.

I'm not sure why you are bent over my statements that a
mechanism could conceivable provide a graceful closure
facility.  But I note that the suggested text actually says
nothing about mechanism-specific graceful closure, and I
never intended it to.  I noted it to illustrate that
graceful closure of the LDAP session should imply graceful
and orderly closure of its component layers.

>facility, it should be used (by LDAP when terminating the session).

Yes.  The intent of the LDAP Unbind operation is to gracefully
close the LDAP session. This implies a requirement that each
layer be torn down in a graceful manner, and in an appropriate
order.  If a particular layer, whether it be provided via TLS
or SASL, includes a graceful closure facility, that facility
should be used in the closure of the LDAP session.

>remove the layer is to close the connection and to replace the layer.

What I am saying is that a mechanism specification can state
that upon replacement/closure of the layer provided by the
mechanism that some specified exchange of cipher buffers is
to take place to gracefully close the layer.

>I can see no "call the mechanism's graceful closure facility if it exists"
>interface,

You also won't see "call the mechanism's rekeying facility if it
exists" interface as well, but that does not mean that mechanisms
are not free to provide rekeying facilities.  Nor does it prevent
application protocol specifications from saying that where rekeying
facilities are offered by the mechanism, they should be used.

>so for a protocol to require this seems to me to require the
>use of a private extension to SASL.

No extension of the framework is needed to allow mechanism to
offer these kinds of facilities.

>That does not seem proper.

Assuming use of an existing SASL library (which may not be true
for some implementations), graceful closure can easily be provided
as part of the libraries facilities for layer replacement and
connection closure.  But regardless, these are API details.

The framework document simply does not discuss API details.
  "While the [abstraction] layer [provided by the framework]
  does generally hide the particulars of protocols from mechanisms,
  the layer does not generally hide the particulars of mechanisms
  from protocols.

That is, mechanism specifications can and do place
mechanism-specific requirements upon application
protocols implementations.

>facility which leaves the connection intact, doing anything on the connection (such as graceful TLS closure) between removing the layer and closing the connection violates the text from 3.3 above.

Yes.  I never intended to imply that graceful closure would be
used anywhere other than at layer-replacement/connection-closure.
I was noting that in replacing-the-layer/closing-the-connection,
the mechanism specification may require exchange of cipher
buffers to effect that replacement/closure in a graceful manner.

>Three solutions I see (in addition to possible clarifications of 3.3)

Personally, I don't think any clarification is needed to 2222bis here.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Dec 2004 09:53:29 -0500

>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:

    Hallvard> Kurt tells me that a mechanism can define as part of its
    Hallvard> data security layer a graceful closure facility.  This
    Hallvard> can even be associated with another "kind of security
    Hallvard> services", which the SASL I-D explicitly states
    Hallvard> mechanisms may offer.  He also states that if SASL a
    Hallvard> mechanism provides a layer closure facility, it should
    Hallvard> be used (by LDAP when terminating the session).

    Hallvard> However, as far as I can tell rfc2222bis prohibits this:

    Hallvard>    3.3 Security layers

    Hallvard>    If use of a security layer is negotiated by the
    Hallvard> authentication protocol exchange, the security layer is
    Hallvard> applied to all subsequent data sent over the connection
    Hallvard> (until another security layer is negotiated ( see also
    Hallvard> section 6.3) or underlying connection is closed).

    Hallvard> I had taken this to mean that the two interfaces which
    Hallvard> SASL provides to remove the layer is to close the
    Hallvard> connection and to replace the layer.  I can see no "call
    Hallvard> the mechanism's graceful closure facility if it exists"
    Hallvard> interface, so for a protocol to require this seems to me
    Hallvard> to require the use of a private extension to SASL.  That
    Hallvard> does not seem proper.  Though a protocol implementation
    Hallvard> may choose to do so, of course.

I believe your understanding of section 3.3 is correct.  I believe it
would be a violation of RFC2222bis for a mechanism to provide a
facility to remove a security layer.

I'm not sure that this conflicts with Kurt's proposed text though.

--Sam

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 8 Dec 2004 17:17:25 +0100

Kurt D. Zeilenga writes:
> (...)

Well, we argued for several rounds about that ordering, and your text
looks ordered to me, so I though you meant to retain that ordering.
Since you do not, we can take that back to the LDAP list.

> never intended it to.

If that was not intended, fine.  I'm not bent over saying that a
mechansim may provide it, I'm bent over saying that this facility
should then be used.

Except - why do you then turn around and say that it should be used:

> I noted it to illustrate that

Either graceful closure of a SASL layer is the protocol's business, or
it is not.  If there is a good reason why implementations ought to use
such a facility if it exists, being vague about it isn't helpful.

Whether I'm getting your words above right or not, it seems to me that
you giving several examples of how SASL mechanisms are free to break
SASL's stated purpose: "...providing authentication and data security
services in connection- oriented protocols via replaceable mechanisms".
If so, that statement should be weakened, and rfc2222bis should make
clear that when one adds a new SASL mechanism to a SASL library, this
mechanism may require the SASL API to be changed, and all programs which
might use that mechanism to be changed accordingly.

> to take place to gracefully close the layer.

If one has a SASL implementation which does not require the user to call
a "remove layer" function before closing the connection, then a
mechanism which requires the user to do that is not replacable in the
sense I thought rfc2222bis meant.  Both that SASL implementation's API
and every program which uses it will have to be updated in order to use
the new mechanism properly.

> are not free to provide rekeying facilities.

True...

> Nor does it prevent

If SASL mechanisms are _not_ supposed to be replacable in the sense I
thought it meant, that is true.

> offer these kinds of facilities.

No, and I'm not talking about that.  I'm talking about claims that such
facilities should or must be used if present.

> connection closure.  But regardless, these are API details.

Not if an interface to removing the layer is to simply close the
connection.  Yes, one can create a new API library call, but old
programs using that library will not be using that call, so old
programs must all be updated.  That is not an API detail.

> protocols implementations.

Well, that's not what I thought it meant.  That something is not hidden
does not imply that the API must be modified to accomodate it.

>> Also, to my reading, even if a mechanism provides a "graceful
>> closure" facility which leaves the connection intact, doing anything
>> on the connection (such as graceful TLS closure) between removing the
>> layer and closing the connection violates the text from 3.3 above.
>

Well, I guess I just didn't understand what you said about TLS vs SASL
closure ordering.

> buffers to effect that replacement/closure in a graceful manner.

See above.

-- 
Hallvard

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Dec 2004 10:45:18 -0600

> I'm not sure that this conflicts with Kurt's proposed text though.

Right, since Kurt's text is about negotiating the end of the entire
session at the application layer.

I'm mildly concerned that forbidding the removal of the SASL security
layer may prevent the development of SASL applications that perform
channel binding at the application layer.  Since SASL mechanisms ought
to provide for channel binding themselves, rather than the applications,
I think this concern can be ignored, but I point it out just in case
someone finds it a bigger concern than I do.

Nico
--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Dec 2004 09:26:22 -0800

>> nothing about mechanism-specific graceful closure, and I

Just to be sure everyone is clear as to what I mean by "graceful closure",
I note use this term to mean "non-abrupt closure", and not "downgrade
to clear text".

>mechansim may provide it, I'm bent over saying that this facility

Note that I am saying on this and other lists, however the
suggest text is appropriately vague here.  It just says the
LDAP session is to be gracefully closed.  What that means
precisely, in regards to any installed SASL data security
layer, depends upon the mechanism.

>Except - why do you then turn around and say that it should be used:

Yes, since the purpose of the LDAP Unbind is to gracefully close
the LDAP session, every layer in the protocol stack should be
gracefully torn down.  If the SASL or TLS or whatever is providing
a data security layer and the specification has defined a facility
for graceful closure of the layer, then that facility should be used
by the LDAP implementation in closing the LDAP session.  

Regarding "replacement" of mechanisms, note that this generally
means that a protocol specifications can be written to support
not only current mechanisms, but future mechanisms.  It however
says nothing about details involved in upgrading implementations
to support new mechanisms, and certainly for an implementation
to support a dissimilar mechanism (to those it currently supports)
may require significant reworking of the implementation.  For
instance, adding support for Kerberos-based or certificate-based
mechanism(s) to an implementation which previously only supported
password-based mechanisms will require significant reworking of
the implementation.  Adding support for a mechanism which supports
rekeying, adaptive data compression, or various other "new"
services may require reworking of the implementation.  If
implementations use abstraction layers, these abstraction layers
will likely need to reworked.

However, the protocol specification likely needs little to no
change to support "new" services.  Certainly it may be appropriate
to provide guidelines for the use of these new services, but that's
about all that should be needed.  In some cases, how to use new
services may be obvious from the existing protocol specifications.

I think that if some new mechanism did provide a graceful closure
facility, that its use in LDAP would be obvious given the suggested
text.  Simply by stating that the Unbind operation purpose is to
gracefully close the LDAP session is enough guidance for them to
gracefully close the component layers in a session in an orderly
fashion.   If we later find the suggested text is too vague, well,
that something we can remedy later (e.g., if and when there is a
mechanism which provides for graceful closure).

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 07 Dec 2004 18:19:10 -0800

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Dec 2004 09:53:29 -0500

--Sam

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 8 Dec 2004 17:17:25 +0100

True...

See above.

-- 
Hallvard

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Dec 2004 10:45:18 -0600

Nico
--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Dec 2004 09:26:22 -0800

Kurt