The SASL capability is bi-directional, it can allow either side to mandate
secure connections.
SASL is more generic and is not that complicated and has broader problem
solving capabilities with regards to its allowable authentication
mechanisms.
Believe me, either mechanism is relatively simple to pull off. It's the TLS
component that's the work.
The argument for Upgrade: versus SASL should not boil down to code
complexity (IMHO), because I think the code burden difference is negligible.
And while a SASL mechanism is slightly more work, I think the bang for the
buck is worth it...(at least right now, I'm still studying both methods).
Randy
-----Original Message-----
From: Carl Kugler [mailto:kugler at us.ibm.com]
Sent: Friday, November 20, 1998 2:22 PM
To: ipp at pwg.org
Subject: IPP> IPP/NV: SASL vs. HTTP-TLS-UPGRADE
I've been looking over "Simple Authentication and Security Layer (SASL)",
RFC 2222 (http://info.internet.isi.edu/in-notes/rfc/files/rfc2222.txt); and
"Upgrading to TLS Within HTTP/1.1"
(ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-http-upgrade-00.txt).
>From an IPP point of view, these seem to be competing solutions to the same
problem. Here is the problem as I understand it:
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