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

["Paul E. Jones" <[e-mail]>]

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).

 
> 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.

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!

> ===
>       SSM-Functions = "SSM-Functions" ":" MAC-Function
>                       *["," *SP MAC-Function] ===
> 
> Presumably LWS instead of SP.

Yes.  We'll change that.

> 
> ===
>    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.

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.

> 
> ===
>    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?

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

> ===
>    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.

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.)

> ===
>       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!

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.
 
> ===
>       HTTP/1.1 401 Unauthorized
>       WWW-Authenticate: SSM transport=https, port=443 ===
> 
> Why not just use a regular HTTP redirect?

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.
 
> 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?

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
 
> Adam
> 
> 
> On Mon, Feb 21, 2011 at 11:09 AM, Gonzalo Salgueiro <[e-mail]>
> 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:
> > 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
> > _______________________________________________
> > http-state mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/http-state
> >
> >
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state