HTTP2 Expression of Interest

The purpose of this EOI is to endorse the "Multilegged Authentication for HTTP Multiplexing<http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth>" proposal:
http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth-01
"Briefly describe your implementation or deployment before giving your feedback on all of the proposals":

We have client and server stacks for HTTP 1.1 and associated APIs, with massive deployment in consumer scenarios, corporate and large organizations, cloud, etc. We use HTTP in many different ways and scenarios, including browsers and client apps, web servers and web services, media delivery, cloud applications, VPN, and many others.
 "Have you already implemented / deployed this proposal? Do you intend to? "
Microsoft has partially implemented the Multilegged Authentication for HTTP Multiplexing<http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth> proposal, specifically adding the Persistent-auth header to disambiguate when Kerberos results in connection-based authentication or request-based authentication:
http://msdn.microsoft.com/en-us/library/dd341152(v=PROT.10).aspx

We have no plans at the moment to implement other proposed authentication proposals. It would be beneficial to create a high level summary of the specific problem or inefficiency that each authentication scheme addresses. We can use this summary to compare each authentication scheme with the other proposed ones, as well as the existing authentication schemes.





"Do you believe it is a good basis for standardization? Why / why not?"



HTTP multiplexing is more than likely going to be included in HTTP2.0, which will break deployments relying on connection-based authentication schemes. This proposal provides a mechanism to ensure compatibility between HTTP multiplexing and connection-based authentication schemes. Furthermore, this proposal is backwards compatible with HTTP 1.1.
"If it is adopted as the basis for further work, what concerns need to be addressed?"
Without a doubt, we will have to do something to ensure connection-based authentication schemes continue to work with HTTP 2.0.
There are concerns that connection-based authentication schemes are not compliant with HTTP 1.1 and some advocate eliminating them completely from the protocol. Unfortunately, this cannot be done without negatively affecting millions of users, and eliminating reply attacks at the HTTP layer becomes difficult without connection orientation. We would like to hear specific feedback from the WG on how to improve the proposal in a way that best aligns with the core HTTP 2.0 spec, so that we can modify it prior to formal standards submission.
As we discussed our feedback for this Expression of Interest, a couple of additional ideas came to mind. These do not appear in any formal HTTP 2.0 authentication proposal, but we feel that they are small enough and compelling enough to warrant discussion for potential inclusion as part of the HTTP 2.0 authentication work to be chartered within HTTPbis:

1.       Lightweight "probe" for POSTs and PUTs.  Initial PUTs and POSTs with long entity bodies will cause problems because of the extra round trip required by authentication. ("Initial" means when first request on a connection is PUT or POST). If the body is indefinite length, it may not be able to be recreated. This is a problem with any multi-legged authentication scheme in HTTP. It could be avoided if there were a guaranteed benign request type that could be used to force authentication if needed before doing the PUT or POST.

2.       Update Digest. One major issue with Digest is the fact that it relies on the broken and old MD5, so an update could start by adding crypto agility and a much stronger default MUST implement hash. Other potential items for an updated digest include making it work properly with chunks and/or requiring channel binding with its use. The use of channel binding should be considered for other authentication schemes as well.



The following are some open questions that we believe should be brought up for discussion in the WG:



1.       How to properly perform authentication with large POST requests and indefinite length PUT requests? See above.

2.       Update digest? See above.

3.       How can we modify HTTP authentication to work better with connection-based authentication schemes.

4.       Real security is hard to do at the HTTP layer. Would we get more value by moving away from attempting to solve security at the HTTP Layer and instead focusing on Channel Binding + TLS/SSL?

5.       Would it be useful to create a Best Current Practices (BCP) document for authentication to include:

a.       Step by step instructions for securing resources using HTTP authentication using request-based schemes.

b.      Step by step instructions for securing resources using HTTP authentication using connection-based schemes.

c.       Step by step instructions for how to use cookies for authentication.
Thanks

-Jonathan Silvera