Re: protocol: closing SASL upon Unbind
Hallvard B Furuseth <[email protected]>
| Newsgroups | gmane.ietf.ldapbis |
|---|---|
| Message-ID | <[email protected]> |
Sorry about the delay. Jim Sermersheim writes: > For my education, what about this is slightly wrong? > >>>> Hallvard B Furuseth <[email protected]> 1/24/05 12:22:03 PM > > Ouch. I lost those threads completely, while trying to unravel some > SASL stuff. IIRC; after Kurt's last (private) explanation I think > this text will be slightly wrong whatever we do, unless we leave the > details underspecified as in earlier drafts. Or unless the SASL spec > is modified. So I guess this text is as good as any. I still think - but still need to look at this - that the only ways [SASL] provide to remove a SASL layer is "closing the connection" and "replacing the layer". If a SASL implementation provides "removing the layer" as a separate operation, that's a SASL extension. If LDAP - or a SASL mechanism - requires support for first removing the layer, then doing something else on the connection, and then closing it, then it depends on an extension to [SASL]. LDAP does not refer to the definition of this extension. OTOH, Kurt listed privately quite a number of horrors with doing things the other way around: First removing the TLS layer, then the SASL layer. For example, note the problems we had with TLS layer removal - we had to invalidate the connection afterwards. SASL above TLS has the same problem. In particular if closing the SASL layer involves messages in both directions, which I believe Kurt said was possible. Which reminds me: Something - either [SASL] or [Protocol] or [Authmeth] - needs a warning about security problems with removing security layers in the wrong order. Since LDAP explicitly allows them to be added in any order, maybe a warning in an LDAP document is a good thing. Otherwise someone might feel the natural way to remove the layers is in the reverse order of how they were added. >Jim Sermersheim writes: >> Unless there are further issues with this, I will replace the current >> instructions for Unbind with Kurts suggested text here. >> >> >>> "Kurt D. Zeilenga" < [email protected] > 12/7/04 6:43:45 PM >>> >> My previous suggestion does not adequately cover the >> issue of graceful closure of the LDAP session. That is, >> the reason why a particular order was suggested was that >> it was thought to be graceful. So while I have no >> problem with removing the ordering aspect of the current >> text, I'd like to indicate that Unbind/Notice of Disconnect >> are intended to affect a graceful closure. >> >> Hence, I suggest: >> >> 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. >> >> I note that while the 4 actions the implementation might need >> to take are stated in the order which the implementation likely >> would need to affect graceful closure of the LDAP session, >> the text does not actually prescribe a particular order, nor >> does it imply that any exchange within the SASL and/or TLS >> layer would been necessary. -- Hallvard