SASL in HTTP/1.1
draft-nystrom-http-sasl-12

Further work on this indicates that a new direction will be needed, and a small group has been formed to develop a new version.  This version is withdrawn.

From: Eric Rescorla

I've just reviewed draft-nystrom-http-sasl-11.txt and wanted to send you
some comments. The executive summary is that I don't think this document
is ready to go to Proposed without substantial changes.

-Ekr

GENERAL TECHNICAL COMMENTS

There are a number of technical features of this protocol
I find problematic.

Channel Security Assumption:
The protocol seems to assume that authentication state information is
bound to the TCP connection in some way. For instance, in the example
in S 4.7.1, the client and the server do a number of exchanges to
perform the SASL authentication but at the end of the day the actual
HTTP request that the server services is done entirely in the clear
with no security protection at all. The authors seem to assume that
once the SASL handshake is done the HTTP server will simply allow all
future requests to inherit its security properties without any
explicit cryptographic authentication.

I appreciate that this is standard practice in stateful protocols like
IMAP, SMTP, etc. but AFAIK it's not the way that things are typically
done in HTTP. In HTTP, each request contains its own authentication
information and can be handled without resorting to information about
which TCP connection it came in on.

This isn't purely a philosophical issue.  It means that SASL-HTTP will
perform poorly without persistent connections due to the number of RTTs
required for the exchange. The authors suggest that cookie-style state
management should be used but clearly expect persistent connections to
be the rule. This is an architectural issue for servers, which are used
to being able to terminate connections at will with the assumption that
clients can cheaply reauthenticate.

The interaction with multiple TCP connections, as are often used to
fetch inline images, also seems problematic.  Again, these work well
with basic or digest, but will be expensive to authenticate with SASL.


Failure To Protect Requests:
In addition to adding a lot of state to the connection, the design of
the protocol leads to a number of confusing security properties.
Consider again the exchange in S 4.7.1. Note that the final GET (the one
that actually performs the request) is completely cryptographically
unprotected. Not only is it not authenticated as part of the channel,
it's completely in the clear. What stops an attacker from letting the
handshake connection proceed and then hijacking the connection and
injecting any request he wants. It's not even clear that the FIRST
request needs to match whatever was used for the authentication (why is
the URI replayed in each phase of the SASL handshake again?)

Note that this isn't a problem with Digest, since each request gets some
cryptographic protection, even if there is nonce reuse allowing replay
attack. The attacker can't forge entirely new requests.

I understand that one can use a SASL security layer to protect against
this attack, but nowhere is it made clear that the protection is
inferior to Digest unless one does so. It's easy to do a better job. Why
don't we?

Note that it's especially easy to do a better job once you've bitten off
the notion that each connection has inherent state, which Digest doesn't
do. You can then use a simple MAC over each request using a sequence
number to prevent replay.  Wouldn't that be a worthy change for all the
C/R based mechanisms in SASL/HTTP?


GENERAL EDITORIAL COMMENTS

I found this document quite hard to follow. Like so many IETF documents,
it jumps right in with a bunch of PDUs and ABNF without any real attempt
to give an overview of the protocol that is being described. This is
particularly confusing becuase SASL is a framework and therefore already
has a bewildering number of options.

A more useful presentation would be to start by explaining roughly how
HTTP SASL works and then proceed to describe the PDUs.

For instance:
------------------------------------------------------
The SASL protocol itself is relatively straightforward.
It consists of a number of exchanges between the client
and the server. Typically, the initial exchange negotiates
the authentication mechanism and then remaining exchanges
actually authenticate the client to the server.

The following figure shows, in schematic fashion a typical SASL
authentication handshake which authenticates the client using the
CRAM-MD5 mechanism.

Client     Server
------                                              ------
                          <- Please authenticate, I speak
                                    CRAM-MD5, GSS-API, and
                                                    plain

I choose CRAM-MD5          ->
My ID is "ekr"

                          <- Go ahead ekr, your challenge
                                              is "abcdef"    


Response = "xyzabcd"      ->


Note that other mechanisms may require a larger number of round
trips.

This document describes how to use SASL as an authentication
mechanism for HTTP. We make use of the standard HTTP authentication
headers but with SASL contents. SASL messages sent by the
client are carried in the Authorization header. SASL messages
sent by the server are carried in the WWW-Authenticate header
---------------------------------------------------


An introduction of this type (actually a lot more than this) would make
a big difference in readability, rather than hitting the reader with BNF
on page 4.



DETAILED COMMENTS

S 4.2.2:
Wouldn't it be nice to explicitly state that this message is sent
by the server? I know it's determinable from the BNF, but...


Under sasl-mechanisms, this This section reads:

    A list of registered SASL mechanisms acceptable to the
    server. MUST be sent by the server unless a mechanism already has
    been agreed upon (see example 2 in Section 4.7.2). Servers MUST
    list supported SASL mechanisms in their preferred order.

Does that mean ascending or descending order of preference?


S 4.2.3:
Wouldn't it be nice to explicitly state that this message is sent
by the client?

S 4.3.2:
This reads:
  A client, which receives a "SASL"  authentication
  response token containing the  directive in a WWW-
  Authenticate (Proxy-Authenticate) header in a 401 - Unauthorized (407
  - Proxy Authentication Required) response, MUST choose one of the
  available mechanisms and construct a new request as described below.

MUST? What if no mechanism is acceptable?


I understand why CONNECT is necessary if you're connected to a
proxy, but the text in this section seems to me to imply that
you should use it even if you're not connected to a proxy.
That doesn't seem right. Do HTTP servers even respond correctly
if you try this?



S 4.3.7:
These examples would be a lot more useful earlier in the
document. You're already lost in a morass of BNF before you even see
this stuff. They would also be a lot more useful with some
explanation, instead of just being ladder diagrams.


S 4.3.11:
This reads in part:
  Since support for persistent connections is optional in HTTP/1.1, all
  servers MUST implement some method for state management of SASL
  authentication exchanges. This may include (but is not limited to)
  session caching, session expiration, dealing with duplicated
  authentication requests.

  This document does not specify methods for servers to manage session
  state once the client has been authenticated. For an example of such
  methods, see [RFC2965].

So, the idea here is that you have to use cookies to bind authentication
to requests once the SASL auth has happened? That doesn't seem like
the most secure scheme...


S 6.1:
This reads:

  Being descriptive rather than
  prescriptive, this memo does not mandate any particular SASL
  mechanism, and a complete threat analysis can therefore not be given.

What does this mean? This is going for Proposed, right? How can it
not be prescriptive?


S 6.2.1:
I understand that MITM downgrade attacks are inherent in this
kind of negotiation scheme, but there are ways to minimize
them. As long as your weakest scheme is some sort of C/R,
than you can do a MAC over the handshake messages and ensure that
you're algorithms aren't downgraded below some minimal security
level. In particular, you can ensure that if both parties are
willing to do a channel security layer you actually get that.

Now that I've mentioned this, why every offer SASL PLAIN?
If you're willing to offer a lousy mechanism, why not just
do Basic?


S 7.2:
In the section about security layers, I think some discussion of
the properties of the composition of security systems would
be useful here.

(From Lisa Dusseault)

This draft defines two success codes -- 235/236 -- which are unnecessary
and introduce a round-trip.  This makes SASL authentication work unlike Digest
(and Basic).  I don't see the justification for the change and the extra complexity.
Instead, when authentication succeeds, the response to the authorized request should
immediately be the regular success response, whether that's 200 OK with the body
of the requested resource, or some other success code.  The WWW-Authenticate
header indicating successful authentication can still appear, moved from the 235
code response to the real success response.

The special response code may still be necessary for the proxy authentication
case (236) , but I haven't seen that required for Digest.  If the authors argue that
it is necessary for the proxy authentication case, it would be good to see an example
of how that works and how the client follows up on that response.

Overall, I'd be more comfortable with this draft if it used the tried and proven
mechanism used by Basic and Digest, to give the "final answer" to the request that
contains the correct authorization, rather than to insert an extra success/re-request
round-trip.  The introduction of the extra round-trip may change the threat model.

Example 4.7.6 contains a 3rd GET request without authentication information, and
shows the server responding with a success response as if the client was still
authenticated, yet in this example there's no CONNECT or other mechanism to
ensure that this interaction is occurring over the same connection as the 2nd GET
request which does contain authentication information.  I'm following up separately
with the authors to see if they can clarify their intent here.

Lisa Dusseault

From Lisa Dusseault

I've reviewed draft -11 as well now, or at least those areas that related to the
comments I made on draft -05.

I said:


3. How clients choose to authenticate:

  "If the client requires authentication, it MUST issue OPTION request
  that includes Request-URI for the desired resource. This allows to
  query which SASL mechanisms are supported by the server for the
  requested resource."

This needs clarification.  Is the server REQUIRED to respond to a
OPTIONS request with a 401?  Or do you mean that the server responds to
OPTIONS with 200 plus it MUST include some kind of SASL-mechanisms
header?

If you mean the former, there's a problem with this approach in HTTP,
which we discovered in WebDAV Interop events.  Frequently anonymous have
read access but not write access on HTTP resources.  So the client is
allowed to do an OPTIONS request or GET request, but not a PUT request.
In a PROPFIND request, the server might respond with the publicly
readable properties but not with the properties to which permissions are
restricted.  So what if the client knows it needs to authenticate (to
see all the PROPFIND results, or to do a LOCK or PUT) and wants to do
so?  OPTIONS isn't good for this because the server allows all requests
for GET, OPTIONS or HEAD to succeed.  If the server challenges all
clients sending OPTIONS, then users without a login won't try to read
the publicly readable resource.

If you mean the latter, I don't see such a header defined.  And how does
this work with SASL schemes that require a server challenge in order for
the client to be able to authenticate?  Or does the server calculate
SASL challenges to put in the response to OPTIONS (even if client's
don't necessarily support this new scheme)?  And can the server also
respond 401 to OPTIONS?  (the deployed base already does).

Magnus responded:


It was the former. The text (and required server behaviour) has been
clarified since -05. I'd be interested to read your comments on the new
text.

The text in -11 (section 4.3.1.2) is better although it's not clear what status responses the
server would use.  Sometimes OPTIONS fails when the user isn't
authenticated and anonymous users aren't allowed to read or even see
the resource, in which case the server would respond with a 401.
Alternatively, the OPTIONS could succeed with 200 OK because
unauthenticated users *are* allowed to see the resource.  It sounds like
you want the server supporting SASL to respond with the SASL token
in both cases, but that's not explicit -- nor is the name of the header where
that should appear in the OPTIONS response.

This is made somewhat more clear by example 6 in section 4.7.6, which
it would be good to reference in section 4.3.1.2.

I said:


4. Whether SASL can appear together with basic/digest challenges:

  A client, which receives a "SASL"  authentication
  response in a WWW-Authenticate (Proxy-Authenticate) header in a 401 -
  Unauthorized (407 - Proxy Authentication Required) response, MUST
  choose one of the available mechanisms and respond with an
  Authorization (Proxy-Authorization) header containing a "SASL"  token with the chosen SASL mechanism in a
  directive in its next request.

This implies that if a DIGEST or BASIC challenge appears in the
WWW-Authenticate header along with a SASL challenge it's ignored by
clients supporting SASL.  Is that the intention?  If so, it should be
made clear.  If not, then how does the client choose between DIGEST and
SASL, or BASIC and SASL? Ordering?

Magnus responded:


This is a good observation. IMO it should be ordering, and we can clarify
this.

In draft -11, section 4.3.2, it seems you've chosen NOT to suggest ordering.
That may be preferable, but I'll just point out that some deployed clients
already seem to use ordering (Internet Explorer, for one).

I also have one new issue.  The text in 4.8 seems to directly contradict
the requirements in 4.3.1.2:

"  If the client requires authentication, but doesn't know which
  mechanisms are supported by the server, the client SHOULD issue an
  OPTION request that includes a Request-URI header for the desired
  resource and an Authorization (or Proxy-Authorization) header field
  containing a "SASL"  token that MAY contain , but
  MUST NOT contain any of the ,  or  directives.  This provides a way for the client to query
  the server about supported SASL mechanisms for the requested
  resource."

" 4.8 Interoperability with existing HTTP/1.1 clients and servers

  A client supporting a certain SASL-based authentication mechanism
  allowing for initial responses MUST NOT include a
  directive with a "SASL"  authorization request in an
  Authorization or Proxy-Authorization header unless it knows that the
  server supports the SASL mechanism in question. The client MAY use an
  OPTIONS request to find out about the server's SASL capabilities."

I'm also looking at Joe Orton's comments but I'll address that separately.

Lisa

From Roy Fielding (fielding@gbiv.com)

Regarding

- 'SASL in HTTP/1.1 '
    as a Proposed Standard
http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-11.txt

This specification is far too complex for adequate review, primarily
because it mixes HTTP authentication with session-layer processing
in a way that violates the layer independence of HTTP.  It assumes
that HTTP is being communicated over TCP or TLS/TCP, which is
certainly the most common case but is not the basis of the standard.

The claims regarding HTTP authentication's vulnerability to MITM
attacks are certainly true, but the SASL mechanism does nothing
to prevent such attacks for HTTP itself.  What it does provide is
yet another optional session layer that can be constructed to
remove MITM attacks if and only if it is applied in a non-optional
fashion. In other words, if all of the features of SASL are applied
in the same (or similar) way as a TLS session, then MITM attacks
can be prevented.  I see no reason to do such session negotiation
using the HTTP protocol -- that is one of the main reasons why
HTTP has the Upgrade header field to signal a willingness to
upgrade the connection protocol (session layer) using a protocol
exchange that is native (or at least separately defined) to
that connection protocol.

The specification can be vastly simplified by splitting the
definition of the SASL security layer, and any other stateful
form of connection that is managed by a non-HTTP protocol,
into a separate specification on par with TLS, while limiting
the HTTP protocol extensions to those necessary for HTTP clients
and servers to interoperate with SASL credentials.  Turning
HTTP into a security negotiation protocol is inappropriate given
that HTTP is designed to be layered on top of *any* transport
or session layer *after* such negotiation has taken place.


Cheers,

Roy T. Fielding                           
Chief Scientist, Day Software             

From Joe Orton (joe@manyfish.co.uk):

The last call is "aarrgggh".... well, how about removing "HTTP/1.1" from the title so this spec isn't confused with a real HTTP/1.1
authentication scheme?

What are these new 235/236 status codes for?  They seem to be entirelyredundant.  Trying to redefine OPTIONS is still not going to work, neither is the CONNECT-to-port-80 stuff, etc etc as per previous
reviews.

joe

Last call pointer sent to WEBDAV working group, with a specific request to look status codes (sasl mechanism may, of course, be of general interest to this community as well)

Last Call Reply to IANA, IANA's Response:

Thank you for pointing this out.  There is a total
of 5 assignments for this document (4 HTTP status
codes and 1 GSSAPI servive name).

I think we are all clear.

Thanks,

Michelle
IANA

==========

Sorry for jumping in, but there's also the GSSAPI service name "http", to
be found in Section 5.1.

Thanks,
-- Magnus

Last Call Comments by the IANA:

The IANA understands this document to have
only 4 assignments to be made:

235  "Authentication Completed"
236  "Proxy Authentication Completed"
432  "Transition Needed"
450  "Authentication mechanism not accepted"

These will be placed in the following registry:


Please let us know if there are any IANA actions
other than those mentioned above.