Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis

Since discussion has veered towards "what's wrong with Digest?", a  
few more issues, FWIW;

- Forced timeout: it's important to be able to bound login state by  
time. While you can do this by keeping state on the server, this is  
impractical on massively distributed services (e.g., Yahoo!). While  
the opaque field of Digest can be used to transport a  
cryptographically signed timeout date, client implementation of  
Opaque is spotty AFAIK.

- Dictionary attacks: Because an analogue of the password is on the  
wire, it's possible to make dictionary attacks against poorly chosen  
passwords. Again, this can be mitigated by forcing users to choose  
good passwords, but that is difficult when dealing with large numbers  
of consumers.

- Downgrade attacks: Never mind intermediaries; imagine a pool of  
thousands of servers serving a site which use Digest auth. If one is  
compromised, and the browser has stored credentials, it can perform a  
downgrade attack by requesting Basic authentication.

There's a common thread through these that I don't think has surfaced  
in discussions much yet; the idea that, for some kinds of  
installations, it's very desirable to limit the number of servers  
that need to know the password to a small subset of the total set of  
deployed servers. Doing so makes the risk profile much more  
manageable and assures proper resource utilisation (servers doing  
password verification means that there's less resource for doing what  
they're supposed to), and is commonly seen on large Web sites by use  
of cookies as tokens + a dedicated 'login' hostname.

Again, digest has the potential for cross-domain authentication, but  
it isn't widely implemented, probably because people feel there are  
security issues in allowing it in an unmitigated fashion.

Cookies are also attractive because when they're used, the server  
doesn't need to trust that the implementation performs correctly;  
besides scoping issues (which have been mostly worked out), cookies  
generally either work or they don't. Additionally, it's not clear  
whether more than one credential is allowed at a time (IIRC they  
aren't), which limits its usefulness compared to Cookies.


Cheers,


On 2007/06/08, at 8:11 AM, Keith Moore wrote:

>
> Julian Reschke wrote:
>> Keith Moore wrote:
>>> no.  deprecate 2617.  deprecate the framework that is in 2616.  HTTP
>>> security needs a clean slate approach.
>>
>> I personally have no problem with this. In the wild, most
>> authentication isn't using RFC2617 anyway.
>>
>> However, my understanding is that the IESG doesn't allow RFC2616bis
>> not to discuss authentication in *some* manner.
> I'm certain that there will have to be a good answer to the
> authentication question before 2616bis will be allowed to get any kind
> of standardization status.  (it could probably be in a separate  
> document).
>> BTW: does the framework really require fixing?
> I am pretty sure that it does.  I think sites will continue to  
> insist on
> being in control of the look and feel of the username/password dialog.
> I also think that the phishing concerns have to be dealt with.  The  
> two
> of these together make for an interesting set of constraints.
>
> Keith
>
>

--
Mark Nottingham       mnot@yahoo-inc.com

Received on Thursday, 14 June 2007 07:01:21 UTC