Subject: I-D ACTION:draft-nystrom-http-sasl-06.txt

From: [email-masked]
Date: Wed, 05 Mar 2003 06:30:19 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SASL in HTTP/1.1
	Author(s)	: M. Nystrom, R. Zuccherato, A. Melnikov
	Filename	: draft-nystrom-http-sasl-06.txt
	Pages		: 32
	Date		: 2003-3-4
	
This memo suggest the use of SASL [RFC2222] as a framework to enable
the use of strong authentication mechanisms in http/1.1 [RFC2616],
and defines one approach to accomplish this.
Please send comments on this document to the relevant mailing lists,
e.g. [email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nystrom-http-sasl-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-nystrom-http-sasl-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Scott Lawrence <[email-masked]>
Date: 07 Mar 2003 12:59:55 -0500

Thanks for posting this notice to ietf-http-wg; I hadn't heard of it
before then.

I'd like to support most of the comments made by Joe Orton, and
amplify on couple.

Joe Orton <[email-masked]> writes:

> The 1xx status-codes are reserved for "interim" HTTP responses, but the
> draft is now using 102 for a final response here, which won't work (or
> at least, isn't compatible with HTTP/1.1).

In particular, current clients (including proxies) will just treat a
102 as 100 and probably ignore it.

> Draft is confused about whether HTTP auth is per-request or
> per-connection.  Restrictions on not mixing auth sessions on a single
> connection etc should be dropped.

This gets to the heart of the issue, really.  HTTP is stateless by
definition, and the connection has no semantic importance; as such, it
can't (in HTTP alone) have any security significance.  Earlier efforts
to apply SASL to HTTP (drafts long expired) failed on just this point;
they tried to wedge SASL mechanisms into the stateless HTTP framework
(without success).  You've mostly recognized this and gotten a better
model, but I think you've not quite taken it far enough, and I think
that fixing it actually makes the suggested changes simpler.

As you point out in your Introduction, SASL is connection-oriented,
so in order to exploit it, the HTTP server must recognize that it is
using different rules - that the connection provides the security.
This is essentially the same as what we described (and you cited) in
RFC 2817.  I think therefor that rather than defining new
authentication responses you should just use the existing Upgrade
framework. 

I'll try to illustrate how this goes - fleshing it out will require a
bit more study (with which I'm happy to help).  This example assumes
no intermediaries (which would just add the required CONNECT
handshaking to make a tunnel over which to do this sequence)

    Client:                               Server:
1)    (original request)  --------------> [determines that SASL
                                           service is required]

2)     <-------------------------------- 426 Upgrade Required
                                         Upgrade: SASL/1.0, HTTP/1.1
                                         Connection: Upgrade
                                         WWW-Authenticate: sasl (mechanisms)

3)    (request) -----------------------> [changes semantics of 
      Upgrade: SASL/1.0                   connection to be SASL
                                          but not yet unauthenticated]
   
4a)    <-------------------------------- 101 Switching Protocols
                                         Upgrade: SASL/1.0, HTTP/1.1
                                         
4b)    <-------------------------------- 401 Unauthorized
                                         WWW-Authenticate: sasl (sasl challenge)
                 
5)     (original request) ------------->
       Authorization: sasl (sasl-response)                        

Step 1 is the client naively attempting the unauthenticated request.

Step 2 is the server insisting on SASL security for it, and including
the available mechanisms (if it is willing, it could also include
other WWW-Authenticate options such as digest, with the attendant
problems in downgrade attacks). 

The request in step 3 above (which is indicating that the client is
SASL-capable, and a desire to activate it) could be either the
original request, or a dummy request (OPTIONS would do) that exists
just to trigger the protocol upgrade.

4a is the server signalling that the new connection-oriented security
rules apply.  It's an intermediate response - the client can't send
anything in response to it.

4b is the server actually beginning the (mechanism-dependant) SASL
handshake by sending the challenge. 

I suspect that may be possible to fold some of these steps together, by
including the SASL challenge with the 426, enabling the client to
include Authorization in step 3.  

> The draft doesn't actually make any requirements on how the server
> responds to an OPTIONS request, so it's pointless as as well as
> misguided :)

Alas, we tried to make a formal definition of the response to OPTIONS
that would be programatically useful, but never got there.

> The CONNECT-to-port-80/SASL-security-layer-negotiation bits aren't
> compatible with HTTP, and Just Won't Work with deployed HTTP proxies,
> most of which don't even grok HTTP/1.1 properly.

This can be made to work - if SASL is genuinely better and offers
value, then perhaps vendors at all levels would find reasons to
support them.  I have some skepticism about this, but one can hope.
In any event, we have what we need in tbe protocol now to determine
_why_ (and where) things fail, which is the first step.

-- 
Scott Lawrence        
  Actively seeking work 
  http://skrb.org/scott/
  [ <[email-masked]> is deprecated ]

---

From: Scott Lawrence <[email-masked]>
Date: 07 Mar 2003 12:59:55 -0500

Client:                               Server: