Subject: [http-state] draft-salgueiro-secure-state-management-04.txt

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 21 Feb 2011 14:09:58 -0500

Folks,

We just published a significantly revised version of the secure state management draft that we had been working on.  The new draft can be found here:
http://tools.ietf.org/html/draft-salgueiro-secure-state-management-04
 
We had received mixed feedback before, but it seemed there were two recurring themes:
·         We wanted to move away from cookies for secure state management, though perhaps continuing to use cookies as a means of identifying the remote user agent
·         We need to have a solution that works over HTTP that does not require the use of Diffie-Hellman
 
We took a step back to look at the problem we were trying to solve.  What we want is to ensure that a request coming from a client could be trusted, even if transmitted over HTTP.  So, what we wanted really wasn’t a secure cookie, but a guarantee that the request is genuine.
 
With this draft, we’ve moved away from cookies and focus on only providing message authentication.  To provide message authentication, we still establish an association between the client and server.  We still allow for Diffie-Hellman to be used, but we have a mechanism in place to allow HTTPS to be used for the sole purpose of establishing associations, too.  The end result is that, with this draft, we can provide message integrity and we can avoid replay of messages.
 
We invite you to look at this revised draft and provide us with feedback.

Warm Regards,

Gonzalo

---

From: Adam Barth <[email-masked]>
Date: Mon, 21 Feb 2011 13:11:05 -0800

Overall feedback:

There are large performance problems with this proposal.  However, I
like the general idea of the user agent and the server establishing
key material that's used to authenticate various parts of the HTTP
request.

Some random detailed comments:

===
   In every request from the user agent to the server, the user agent
   MUST advertise its support for the Secure State Management
   procedures defined in this document.
===

User agent's aren't going to like this requirement because it bloats
UA => Server request for everyone.

===
      SSM-Functions = "SSM-Functions" ":" MAC-Function
                      *["," *SP MAC-Function]
===

Presumably LWS instead of SP.

===
   A client MUST NOT issue
   concurrent requests that utilize the same security association
   handle and session handle, as the server will not be able to
   differentiate between legitimate requests and requests that are, in
   fact, replay attacks.
===

This is terrible for performance.  It's extremely common to have
multiple requests in flight to a server and will only become more
common in the future.

===
   Once an association has been established, it MAY be used
   subsequently over either HTTP or HTTPS when the client issues
   requests to the server.
===

What about other protocols?  Can I use it with gopher?  What about
SPDY?  What about Future-Protocol-That's-Awesome?

===
   When using HTTPS and establishing a new security association, the
   server MUST reply to requests that contain the SSM-Functions header
   and that do not demonstrate having a valid security association with
   a 401 Unauthorized as shown below:
===

This is slow because it introduces an extra round-trip between the UA
and the server to establish the security association.  For servers
that care about latency, that's a huge hit in many common deployment
scenarios, especially mobile.

===
      GET / HTTP/1.1
      SSM-Functions: hmac-md5, hmac-sha-1
      SSM-Parameters: assoc=12345; session=1; nonce=1;
                components=Request-Line;
                mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
===

That's a lot of junk to send with each request.  People believe that
Cookie headers area already too long!

===
      HTTP/1.1 401 Unauthorized
      WWW-Authenticate: SSM transport=https, port=443
===

Why not just use a regular HTTP redirect?

I don't understand how the user agent chooses which components to use.
 Does the server request these?  Is the user agent just supposed to be
prescient?

Adam

On Mon, Feb 21, 2011 at 11:09 AM, Gonzalo Salgueiro <[email-masked]> wrote:
> Folks,
> We just published a significantly revised version of the secure state
> management draft that we had been working on.  The new draft can be found
> here:
> ·         We wanted to move away from cookies for secure state management,
> though perhaps continuing to use cookies as a means of identifying the
> remote user agent
> We took a step back to look at the problem we were trying to solve.  What we
> want is to ensure that a request coming from a client could be trusted, even
> if transmitted over HTTP.  So, what we wanted really wasn’t a secure cookie,
> but a guarantee that the request is genuine.
>
> With this draft, we’ve moved away from cookies and focus on only providing
> message authentication.  To provide message authentication, we still
> establish an association between the client and server.  We still allow for
> Diffie-Hellman to be used, but we have a mechanism in place to allow HTTPS
> to be used for the sole purpose of establishing associations, too.  The end
> result is that, with this draft, we can provide message integrity and we can
> avoid replay of messages.
>
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 21 Feb 2011 17:38:58 -0500

Adam,

Thanks for the feedback.  Comments below:

> There are large performance problems with this proposal.

Can you elaborate a little on your concerns?  Note that we tried to design
this so that the server itself would have to do only a little more work than
what it would have to do to handle a cookie and less than what it would have
to do for an HTTPS connection.

> However, I
> like the general idea of the user agent and the server establishing key
> material that's used to authenticate various parts of the HTTP request.

Great! Regardless of whether this draft goes forward, we'd like to tackle
this issue to provide some kind of message integrity and perhaps also to
prevent double-posting (versus the various other methods already employed
for the same purpose).

> User agent's aren't going to like this requirement because it bloats UA
> => Server request for everyone.

It does, but we can't see a way to avoid that. Perhaps we could avoid
sending it with specific methods (e.g., HEAD), but for consistency (and
perhaps there are other benefits), we suggested always advertising one's
capabilities.  Suggestions welcome!

>                       *["," *SP MAC-Function] ===
> 

Yes.  We'll change that.

> multiple requests in flight to a server and will only become more common
> in the future.

Having multiple requests in flight is permissible.  The requirement is that
each parallel request must have its own "session" value, which is an integer
value specified by the user agent.

> What about other protocols?  Can I use it with gopher?  What about SPDY?
> What about Future-Protocol-That's-Awesome?

:-)  I suppose it could be used for anything, but the scope of this document
is HTTP.

> and the server to establish the security association.  For servers that
> care about latency, that's a huge hit in many common deployment

Delay is introduced, but no worse than digest authentication.  Once a
security association is established, this process does not have to be
repeated.  We assume the association is valid until the server decides
otherwise.  We would expect that an association would be valid for at least
one day, so a UA would not have to create the association very often.  (The
lifetime of the association is certainly a subject for discussion.)

> Cookie headers area already too long!

Indeed, and a typical request might very well be longer since it might
include more "components".  This does add over 150 octets to the request,
but there is benefit in that message integrity is assured.  There is always
a cost with security.  We could reduce the size of the headers by
abbreviating things.  The above could be:

       SSMF: hmac-md5, hmac-sha-1
       SSMP: a=12345;s=1;n=1;c=Request-Line;\
             m=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed

It's shorter, but still just over 100 octets.
 
>       WWW-Authenticate: SSM transport=https, port=443 ===
> 

A redirection does not tell you what the issue is.  We've had this problem
with Javascript code that got redirected for authentication purposes (e.g.,
using a single sign-on service).  A request is issued for a JSON object, for
example, a 3xx is returned, and some HTML content is returned.  The
JavaScript code was completely oblivious to the 3xx.

We could have defined the procedure such that a redirection occurs, a 401 is
then returned, then on the next request another 3xx is returned to redirect
the client back to the HTTP port.  The issue there was that one would not
know why the redirection occurred and it introduces more exchanges on the
wire.  We're not entirely opposed to 3xx, but we proposed this as an
optimization.
 
>  Does the server request these?  Is the user agent just supposed to be

I assume you mean for generating the MAC?  We left that unspecified, as we
assume the user agent is the right entity to choose.  It is the one, after
all, that knows that it will send cookies that need protecting with a MAC or
other headers or a message body.  I'm personally not opposed to having the
server indicate a minimum set of components, where the UA would then provide
them if they are present.

Paul
 
> > ·         We wanted to move away from cookies for secure state
> > management, though perhaps continuing to use cookies as a means of
> > identifying the remote user agent ·         We need to have a solution
> > that works over HTTP that does not require the use of Diffie-Hellman
> >
> > We took a step back to look at the problem we were trying to solve.
> > What we want is to ensure that a request coming from a client could be
> > trusted, even if transmitted over HTTP.  So, what we wanted really
> > wasn’t a secure cookie, but a guarantee that the request is genuine.
> >
> > With this draft, we’ve moved away from cookies and focus on only
> > providing message authentication.  To provide message authentication,
> > we still establish an association between the client and server.  We
> > still allow for Diffie-Hellman to be used, but we have a mechanism in
> > place to allow HTTPS to be used for the sole purpose of establishing
> > associations, too.  The end result is that, with this draft, we can
> > provide message integrity and we can avoid replay of messages.
> >