Problem Statement: IPP needs a mechanism for negotiating security in-band over a single HTTP session. A server might need to challenge a client for authorization in order to protect server resources. More importantly, a client may need to challenge a server for authorization because the server is about to become the recipient of some sensitive information. Furthermore, the client may need to negotiate an encrypted session with the server, because the client is about to transmit sensitive information over the net.
Either SASL plus some new "mechanism" for HTTP, or HTTP-TLS-UPGRADE could be used to solve the problem. To me, the HTTP-TLS-UPGRADE approach looks much simpler, more complete, more compatible with existing web infrastructure, and a lot easier to implement.
The existing SASL mechanisms that I've seen all are oriented to servers challenging clients for authorization to receive sensitive information. In IPP, the sensitive information is flowing the other way, from client to server. To use SASL in IPP, we'd have to invent a SASL HTTP "mechanism" (looks fairly complicated to me), build implementations, and register the mechanism with IANA. This looks like a long path to me.
On the other hand, HTTP-TLS-UPGRADE looks like it could be accomplished with relatively minor modifications to existing HTTP implementations. And it appears to meet all of our requirements.
I think the HTTP-TLS-UPGRADE is the best choice for IPP/NV, unless HTTP community in general settles on something different. If/when IPP is mapped to protocols other than HTTP (e.g., in SDP), a SASL mechanism might be the way to go.
-Carl "Simple is good!" Kugler
-----
See the original message at http://www.egroups.com/list/ipp/?start=4911