Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation

[Marsh Ray <[e-mail]>]

On 12/12/2010 04:39 PM, Roy T. Fielding wrote:
>
> Define them all and let's have a bake-off.  It has been 16 years
> since HTTP auth was taken out of our hands so that the security
> experts could define something perfect.  Zero progress so far.

Perhaps it's a bad idea?

> We
> should just define everything and let the security experts do what
> they do best -- find the holes and tell us what not to implement.

I know some professional pen-testers who would love that!

Check out these videos. This is what happens when you take a 
general-purpose authentication protocol and repurpose it for use across 
the internet for an insecure application protocol:

http://extendedsubset.com/smb_relay_fully_patched.wmv
http://extendedsubset.com/smb_reflection_arp_poisoning.wmv
http://extendedsubset.com/?p=36

This case is NTLMv2, but the phenomenon is not limited to that.

The problem is that most general-purpose authentication protocols do not 
require enough specificity about the context of the authentication: who 
and what are you authenticating, to whom, and how does each side know 
it's operating under the same beliefs as the other?

This means that even if the client wants to be careful and authenticate 
only for the purpose of setting up a secure connection, the attacker can 
possibly forward that authentication to auth his own connection or 
transaction on some other service (on the same or even a different server).

Most auth protocols don't let the client strongly verify the server's 
identity before the client has to authenticate with his own. This is 
probably at least in part because it requires some common infrastructure 
to do this. So Kerberos and x509 PKI systems can authenticate the server 
(and sometimes even the target service), but most others do not.

Since HTTP lacks connection integrity, it's meaningless to speak of "an 
authenticated client". Perhaps the only thing that could be meaningfully 
authenticated is the request data itself. But auth protocols designed 
for setting up persistent connections typically don't have defined 
inputs for the message data/digest being signed, so it's often 
impractical to reuse them for that purpose.

These issues have been mostly addressed at the protocol level for TLS 
client cert authentication. If it really just comes down to deployment 
and client usability issues, it's hard to imagine coming up with 
something at another layer which would have less risk than building on 
top of that.

Deploying new uses of compatible, standard authentication protocols over 
insecure application protocols can be bad for the greater security 
ecosystem because it widens the field for cross-protocol attacks.

- Marsh