Re: #288: Considering messages in isolation

On 30/06/2011 1:02 p.m., Mark Nottingham wrote:
> On 30/06/2011, at 10:52 AM, Adrien de Croy wrote:
>
>> How does auth fit in with this, esp any challenge-response based authentication or connection-oriented auth.
> I think it's well-established that "connection-oriented" authentication is fundamentally incompatible with HTTP, and shouldn't be attempted. Yes, NTLM does it, and that causes *significant* problems in all of the implementations I'm aware of.

well the problem with "shouldn't be attempted" is that NTLM is one of 
the most popular auth mechanisms in use.

On this note, one reason it's so popular is because there's no other 
"secure" mechanism that can (in the default case) use the accounts from 
a Windows or Active Directory user database.  This is because by default 
the passwords are stored as MD4 hashes, and so any auth method that 
requires access to the plaintext password cannot be used unless the 
administrator changes settings to allow use of reversible encryption for 
password storage.

So, until MS makes the default password storage mechanism reversible, no 
mechanisms using plaintext passwords (such as CRAM-MD5, Digest et al) 
will get any traction in a windows environment.  Which leaves us stuck 
with NTLM.

Furthermore in a corporate environment, integrated authentication (which 
is supported by all popular windows-compatible browsers) is based on 
Negotiate, which usually boils down to NTLM or Kerberos.

Designers of new auth mechanisms (since there have been several recently 
discussed on this list) should therefore keep this in mind. I'm not 
saying we should all fall back to MD4 hashes, but it's an issue.

So IMO much as NTLM may be quite problematic, I believe it will be with 
us for a long time to come.

What action if any that leaves us with now is another matter.  Perhaps 
we should make some note somewhere, or explicitly deal with the case.  
For instance state somewhere that the assumption that requests are 
unrelated no longer holds if a particular header is present, indicating 
the use of session-based authentication for instance.

Adrien

>> NTLM clearly requires an assumption that authentication state across multiple requests is associated with the connection the requests are received on.
>>
>> Is Digest also a problem with this?
> No.
>
>> I realise there's not really anything an O-S can do, since a connection might have come from a proxy that aggregates clients into the same connection.
>>
>> Does the "Proxy-Support: session-based-authentication" header mess with this, IOW do we have a collision here with RFC4559
> That's Informational, although I'm a little surprised it was let through without a note to the effect that it breaks HTTP. Might be worth raising an errata to that effect.
>
>
>> Regards
>> Adrien
>>
>>
>> On 30/06/2011 12:01 a.m., Julian Reschke wrote:
>>> On 2011-06-28 07:15, Mark Nottingham wrote:
>>>> Milestone set for -15.
>>>> ...
>>> Applied with<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1317>.
>>>
>>> I added it to the new section, which now reads:
>>>
>>> 2.2.  Message Orientation and Buffering
>>>
>>>    Fundamentally, HTTP is a message-based protocol.  Although message
>>>    bodies can be chunked (Section 6.2.1) and implementations often make
>>>    parts of a message available progressively, this is not required, and
>>>    some widely-used implementations only make a message available when
>>>    it is complete.  Furthermore, while most proxies will progressively
>>>    stream messages, some amount of buffering will take place, and some
>>>    proxies might buffer messages to perform transformations, check
>>>    content or provide other services.
>>>
>>>    Therefore, extensions to and uses of HTTP cannot rely on the
>>>    availability of a partial message, or assume that messages will not
>>>    be buffered.  There are strategies that can be used to test for
>>>    buffering in a given connection, but it should be understood that
>>>    behaviors can differ across connections, and between requests and
>>>    responses.
>>>
>>>    Recipients MUST consider every message in a connection in isolation;
>>>    because HTTP is a stateless protocol, it cannot be assumed that two
>>>    requests on the same connection are from the same client or share any
>>>    other common attributes.
>>>
>>>
>>> Best regards, Julian
>>>
>> -- 
>> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
>> WinGate 7 beta out now - http://www.wingate.com/getlatest/
>>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Thursday, 30 June 2011 07:55:19 UTC