Subject: draft-montenegro-httpbis-multilegged-auth-01

From: Alexey Melnikov <[email-masked]>
Date: Sun, 8 Jul 2012 19:56:03 +0100

I think it is worth investing some WG time into this proposal, because several proposals (+ existing Kerberos) are already multilegged. Otherwise new schemes would need to reinvent this, for example using "sid" directive.

---

From: Nico Williams <[email-masked]>
Date: Sun, 8 Jul 2012 17:50:25 -0500

> I think it is worth investing some WG time into this proposal, because several proposals (+ existing Kerberos) are already multilegged. Otherwise new schemes would need to reinvent this, for exampl…

I sought to generalize this with REST-GSS (which really uses SASL/GS2,
not GSS directly).  Any comments?

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 9 Jul 2012 12:01:52 +0900

Dear Alexey,

> I think it is worth investing some WG time into this proposal, because several proposals (+ existing Kerberos) are already multilegged. Otherwise new schemes would need to reinvent this, for exampl…

I agree that it is good to have a unified vehicle for managing
sessions for multi-legged auth.

Actually, more than three-quarters of
my proposal is technically a common vehicle for multi-legged
authentication with optional re-use of key-based shared
secret for authorizing multiple requests without full key-exchange.
I think Alexey's SCRAM-SHA1 proposal completely fits
with this model, and I actually thought to propose, to Alexey,
to merge session-managing part of two proposals to one
unified scheme.  One possibility for me is to write (or propose)
an experimental draft for putting SCRAM-SHA1 onto my vehicle,
to see how it works or not.

Gabriel's draft is interesting in the way that connection-based
existing authentication schemes (NTLM and Negotiate)
into HTTP/2.0 world.  These things are declared "broken" in
current HTTP/1.1-bis discussions, and without considerations
it will not be useful for HTTP/2.0.
There should be a debate about how we treat existing connection-based
authentication for future, and if we decide it will survive, we will need
Gabriel's one or similar.

For key-based multi-legged authentications (things similar Digest, including
Mutual and SCRAM-SHA1), at the first glance, it seems not well
designed for key-based, but it is still interesting for me, because
it will show how these things are different, and how the common things
can be picked up.

My intuition at current moment is to have TWO common vehicles for
HTTP-layer multi-legged authentications, one for connection-based and
one for key-based (this is not a strong opinion, just an observation).
I want to continue research on how these two things are related,
to make common things common, and to keep different things different :-)

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Jul 2012 18:17:45 +0100

On 09/07/2012 04:01, Yutaka OIWA wrote:
> Dear Alexey,
>
> 2012/7/9 Alexey Melnikov<[email-masked]>:
Dear Yutaka,
I reviewed your draft and I thought that several features of it are 
indeed generic among HTTP authentication mechanisms and should be split 
out to a generic HTTP authentication related document (or at least into 
a separate section of one of your existing drafts).

So yes, I generally support doing what you suggest. But I think it might 
be worth delaying any specific work until the WG decides on which HTTP 
authentication-related documents it should work.
> to make common things common, and to keep different things different :-)

I haven't made my mind about this issue yet. So I am looking forward for 
more discussion.

Best Regards,
Alexey

---

From: Jonathan Silvera <[email-masked]>
Date: Mon, 9 Jul 2012 21:16:36 +0000

Dear Yutaka

Supporting legacy authentication schemes, should not be the question to ask ourselves. While these schemes are labeled as "broken" in HTTP 1.1, in reality they are deployed and working. If multiplexing  becomes a part of HTTP 2.0, as it is likely to be, these will be 'broken' not just in label, but in reality. 

The compatibility requirement of the HTTP 2.0 WG charter does not allow us to eliminate legacy schemes, as previous applications are supposed to keep on working, regardless of whether they are labeled as 'broken" for HTTP 1.1 or not. I believe that HTTP2.0 provides us with a great opportunity to ensure schemes currently labeled as "broken", are properly supported from the beginning. Without support for these legacy schemes, the adoption of HTTP2.0 will unavoidably suffer.

Another problem our proposal attempts to address, is that Kerberos' "dual mode" (authenticated connection or authenticated requests) introduces a lot of problems for clients today since there is no way to deterministically know which authentication type was negotiated. It would be great to hear from the WG on thoughts around how we can solve this problem in a generic way, in case more "dual mode" authentication schemes arise in the future.

Thanks

-Jonathan Silvera

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Monday, July 9, 2012 10:18 AM
To: Yutaka OIWA
Cc: HTTP Working Group
Subject: Re: draft-montenegro-httpbis-multilegged-auth-01

On 09/07/2012 04:01, Yutaka OIWA wrote:
> authentication with optional re-use of key-based shared secret for 
> authorizing multiple requests without full key-exchange.
> I think Alexey's SCRAM-SHA1 proposal completely fits with this model, 
> and I actually thought to propose, to Alexey, to merge 
> session-managing part of two proposals to one unified scheme.  One 
> possibility for me is to write (or propose) an experimental draft for 
> putting SCRAM-SHA1 onto my vehicle, to see how it works or not.
Dear Yutaka,
I reviewed your draft and I thought that several features of it are indeed generic among HTTP authentication mechanisms and should be split out to a generic HTTP authentication related document (or at least into a separate section of one of your existing drafts).

So yes, I generally support doing what you suggest. But I think it might be worth delaying any specific work until the WG decides on which HTTP authentication-related documents it should work.
> existing authentication schemes (NTLM and Negotiate) into HTTP/2.0 
> world.  These things are declared "broken" in current HTTP/1.1-bis 
> discussions, and without considerations it will not be useful for 
> HTTP/2.0.
> authentication for future, and if we decide it will survive, we will 
> need Gabriel's one or similar.
>
> For key-based multi-legged authentications (things similar Digest, 
> including Mutual and SCRAM-SHA1), at the first glance, it seems not 
> well designed for key-based, but it is still interesting for me, 
> because it will show how these things are different, and how the 
> common things can be picked up.
>
> I want to continue research on how these two things are related, to 
> make common things common, and to keep different things different :-)

I haven't made my mind about this issue yet. So I am looking forward for more discussion.

Best Regards,
Alexey

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Jul 2012 11:10:12 +1000

> Supporting legacy authentication schemes, should not be the question to ask ourselves. While these schemes are labeled as "broken" in HTTP 1.1, in reality they are deployed and working. If multiple…

The problem is that they may be deployed and working, but only at the cost of lots of pain and by other implementers (especially intermediaries). I.e., they're only "working" because people have worked around them.

> The compatibility requirement of the HTTP 2.0 WG charter does not allow us to eliminate legacy schemes, as previous applications are supposed to keep on working, regardless of whether they are labeled as 'broken" for HTTP 1.1 or not.

That's your interpretation. The charter doesn't require HTTP 2.0 to accommodate *every* use of HTTP, especially when it's being used -- or extended -- in a non-conformant way.

If we can satisfy these use cases by making some changes to them, that's great, but let's not call it "fixing HTTP."

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 10 Jul 2012 13:10:24 +1200

On 10.07.2012 09:16, Jonathan Silvera wrote:
> Dear Yutaka
>
> Supporting legacy authentication schemes, should not be the question
> to ask ourselves. While these schemes are labeled as "broken" in HTTP
> 1.1, in reality they are deployed and working. If multiplexing
> becomes a part of HTTP 2.0, as it is likely to be, these will be
> 'broken' not just in label, but in reality.

I take it you mean NTLM and Negotiate? since Basic and Digest are not 
declared broken, just somewhat unsafe.

NTLM/Negotiate are broken in both label and reality. To different 
degrees.

Try to use HTTP pipeline, HTTP persistent connection re-use, or try to 
operate them over any proxy which does not force stateful "pinning" onto 
*stateless* HTTP (Squid-3.0 for example) and you will see just how 
broken they are. Effects range from users not being able to login at 
all, logging in under other users credentials, to constant 
popup/challenge loops, some software even DoS the network attempting to 
retry automatically.
  This is broken by any definition.

The minor fact that some admin are willing to give up all those 
performance features of HTTP to gain the illusion of "working" is rather 
sad.

>
> The compatibility requirement of the HTTP 2.0 WG charter does not
> allow us to eliminate legacy schemes, as previous applications are
> supposed to keep on working, regardless of whether they are labeled 
> as
> 'broken" for HTTP 1.1 or not. I believe that HTTP2.0 provides us with
> a great opportunity to ensure schemes currently labeled as "broken",
> are properly supported from the beginning. Without support for these
> legacy schemes, the adoption of HTTP2.0 will unavoidably suffer.
>
> Another problem our proposal attempts to address, is that Kerberos'
> "dual mode" (authenticated connection or authenticated requests)
> introduces a lot of problems for clients today since there is no way
> to deterministically know which authentication type was negotiated. 
> It
> would be great to hear from the WG on thoughts around how we can 
> solve
> this problem in a generic way, in case more "dual mode" 
> authentication
> schemes arise in the future.

On this note, the "Negotiate" scheme specifies the ability to negotiate 
NTLM (connection-auth) over it. So IMHO, this scheme is 
connection-oriented due to that requirement.

I would like to see the "Kerberos" scheme formally specified as a 
separate scheme as the request-oriented form. In this way we can 
continue to support "Negotiate" as connection-oriented (HTTP 'broken') 
and "Kerberos" as request-oriented (HTTP 'working').

Anyone keen to do that leg-work?

AYJ

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Jul 2012 17:32:51 +0100

> not GSS directly).  Any comments?
You REST-GSS approach has some benefits over currently existing web 
authentication, so I am looking forward to discussing with the WG 
whether this should be the basis for all future web authentication 
mechanisms.

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Jul 2012 12:45:09 -0500

On Tue, Jul 10, 2012 at 11:32 AM, Alexey Melnikov
<[email-masked]> wrote:
> authentication, so I am looking forward to discussing with the WG whether
> this should be the basis for all future web authentication mechanisms.

Thanks.  I may be biased but I tend to agree :)

What benefits do you see?

Nico
--

---

From: Jonathan Silvera <[email-masked]>
Date: Wed, 11 Jul 2012 18:44:20 +0000

Hi Mark,

>The problem is that they may be deployed and working, but only at the cost of lots of pain and by other implementers (especially intermediaries). I.e., they're only "working" because people have wor…

It would be great if you (and the WG) can provide feedback with suggestions on how the proposal can be extended or modified to make sure implementers do not end up in a worst place once multiplexing is introduced.

>That's your interpretation. The charter doesn't require HTTP 2.0 to accommodate *every* use of HTTP, especially when it's being used -- or extended -- in a non-conformant way.

This would break millions of users in existing deployments. We are not advocating that every use of HTTP be accommodated for, rather ensuring mainstream scenarios continue to work.

>If we can satisfy these use cases by making some changes to them, that's great, but let's not call it "fixing HTTP."

Correct, the proposal is not fixing in HTTP in any way. The goal of our proposal is to ensure that clients in environments requiring multi-legged authentication schemes, continue to work in the presence of multiplexing, while addressing issues introduced by Kerberos' ability to authenticate a connection or individual requests.

Thanks

-Jonathan Silvera

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]]
Sent: Monday, July 9, 2012 6:10 PM
To: Jonathan Silvera
Cc: 'Alexey Melnikov'; 'Yutaka OIWA'; 'HTTP Working Group'
Subject: Re: draft-montenegro-httpbis-multilegged-auth-01

Regards,

--

---

From: Jonathan Silvera <[email-masked]>
Date: Wed, 11 Jul 2012 18:45:55 +0000

Hi Amos,

>I take it you mean NTLM and Negotiate? since Basic and Digest are not declared broken, just somewhat unsafe.
>NTLM/Negotiate are broken in both label and reality. To different degrees.
>Try to use HTTP pipeline, HTTP persistent connection re-use, or try to operate them over any proxy which does not force stateful "pinning" onto
*stateless* HTTP (Squid-3.0 for example) and you will see just how broken they are. Effects range from users not being able to login at all, logging in under other users credentials, to constant popup/challenge loops, some software even DoS the network attempting to retry automatically.
>The minor fact that some admin are willing to give up all those performance features of HTTP to gain the illusion of "working" is rather sad.

There are millions of users working in environments that require NTLM, who will find it very real if their deployments are broken by the new version of HTTP. It would be great to hear suggestions on how the proposal can be modified, to make sure multiplexing introduces minimal side effects for all implementers of multi-legged authentication schemes.

>On this note, the "Negotiate" scheme specifies the ability to negotiate NTLM (connection-auth) over it. So IMHO, this scheme is connection-oriented due to that requirement.
>I would like to see the "Kerberos" scheme formally specified as a separate scheme as the request-oriented form. In this way we can continue to support "Negotiate" as connection-oriented (HTTP 'broken') and "Kerberos" as request-oriented (HTTP 'working').

The dual mode I am referring to is independent of Negotiate, rather a characteristic of the Kerberos scheme itself. Kerberos (standalone or under Negotiate) can be request-oriented or connection-oriented. Problems arise due to the fact that there is no way to deterministically know which one will be used. 

Thanks

-Jonathan

-----Original Message-----
From: Amos Jeffries [mailto:[email-masked]] 
Sent: Monday, July 9, 2012 6:10 PM
To: [email-masked]
Subject: RE: draft-montenegro-httpbis-multilegged-auth-01

On 10.07.2012 09:16, Jonathan Silvera wrote:
> 1.1, in reality they are deployed and working. If multiplexing becomes 
> a part of HTTP 2.0, as it is likely to be, these will be 'broken' not 
> just in label, but in reality.

I take it you mean NTLM and Negotiate? since Basic and Digest are not declared broken, just somewhat unsafe.

NTLM/Negotiate are broken in both label and reality. To different degrees.

Try to use HTTP pipeline, HTTP persistent connection re-use, or try to operate them over any proxy which does not force stateful "pinning" onto
*stateless* HTTP (Squid-3.0 for example) and you will see just how broken they are. Effects range from users not being able to login at all, logging in under other users credentials, to constant popup/challenge loops, some software even DoS the network attempting to retry automatically.
  This is broken by any definition.

The minor fact that some admin are willing to give up all those performance features of HTTP to gain the illusion of "working" is rather sad.

> supposed to keep on working, regardless of whether they are labeled as 
> would be great to hear from the WG on thoughts around how we can solve 

On this note, the "Negotiate" scheme specifies the ability to negotiate NTLM (connection-auth) over it. So IMHO, this scheme is connection-oriented due to that requirement.

I would like to see the "Kerberos" scheme formally specified as a separate scheme as the request-oriented form. In this way we can continue to support "Negotiate" as connection-oriented (HTTP 'broken') and "Kerberos" as request-oriented (HTTP 'working').

AYJ

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 19:41:32 +0100

> What benefits do you see?

You use existing HTTP features, so hopefully that would be easier to 
implement than extensions to existing HTTP authentication framework.

There is also a benefit for not reusing WWW-Authenticate/Authorisation 
headers for multileg authentication, because it is not entirely clear 
how existing clients would handle unrecognized authentication 
mechanisms. So not needing to deal with backward compatibility might be 
a plus.

---

From: Yutaka OIWA <[email-masked]>
Date: Sun, 15 Jul 2012 03:19:56 +0900

Dear Jonathan,

for my understanding, your main purpose of proposing is to accept existing,
already deployed "connection-based" authentication schemes onto
possible HTTP/2.0.  Is it correct?

Then, my questions are twofold:
1. are there some specific reasons for implementations of
these authentication schemes to be strictly connection-based
(here the connection means TCP/IP)?  In other words,
are there some implementation restrictions which prevent
such authentication mechanisms from being used with
multiple underlying connections?
2. if the above answer is NO, is there strong intent to
keep them connection-based?  Or, if it can be deployed easily,
are you open to make it more friendly to HTTP/1.1 (and HTTP/2.0, likely)
message-based semantics?

Background of my questions is as follows:
Your proposal seems to be trying to keep them "connection-based" on HTTP/2.0
including proxy'ed requests.  Key-exchanges before successful authentication are
changed to be message-based by Auth-ID, but after successful authentication,
if original HTTP1 method is connection-based, it will be still connection-based.
This is typically expressed in Section 4.1 of your proposal as follows:
> [...] Proxies MUST bind
> the client-to-proxy and proxy-to-server connections.

However, at least Curl people already expressed concern with
connection-based authentication as follows:
 > The day we can clense connection-oriented authentications like NTLM
 > from the HTTP world will be a happy day, as it's state awareness is
 > a pain to deal with in a generic HTTP library and code.
And currently, your proposal seems not to solve their problem.

I will NOT say "we should cleanse out NTLM from Web", but
I want to explore possibilities for removing connection-dependency of
successfully-authenticated sessions of such schemes.
And I foresee that, if there are no implementation-dependent restrictions,
theoretically it is possible in a similar way as your proposal's style,
i.e. an amendment to existing HTTP/1.1 authentication schemes
when these are used with HTTP/2.0.  Even your framework of Auth-ID
can be reused for such changes.

Thanks,

Yutaka