Re: Straw-man charter for http-bis

[Henrik Nordstrom <[e-mail]>]

fre 2007-06-15 klockan 14:58 -0700 skrev Chris Newman:

> I would speculate it's because the following mandatory pieces of a complete 
> DIGEST-based solution were never written down:
> 
> * Client UI requirements

Sure, but how much of this is the role of IETF?

Since when do IETF specify client implementation besides what impacts
the wire protocols?

Also don't forget that HTTP has widespread use in many applications
where there is no UI at all.

> * How to store DIGEST H(A1) in a central authentication repository such as
>   LDAP or RADIUS in an interoperable fashion

Many server implementations uses LDAP as H(A1) store already, with
reasonable options for secure channels server<->backend.

And RADIUS has Digest support, now at PROPOSED STANDARD level (July
2006) and circulated as a draft for quite some years before that. In
RADIUS it's the RADIUS server being the Digest endpoint and the HTTP
server just relays the Digest exchanges and getting told the user
identity (and other RADIUS attributes) on successful authentication.

SASL has had Digest support for quite some time, but is not entirely
compatible with HTTP Digest.

> * How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST support

As first point above, but server implementation.

> * How to tie the DIGEST identity to whatever real identity system happens to
>   be deployed at the web site.  From an IETF standards perspective, that
>   means getting the LDAP directory entry and/or RADIUS/DIAMETER attributes for
>   the user to the subsystem that needs that information.  In practice this can
>   also involve a SQL database with unspecified keys and attributes.

HTTP is no different here than any other protocol in this regard. IPSec,
TLS, PPP, FTP, SMTP, SNMP, BGP, IMAP, etc etc.. all have similar needs
in identification of the involved parties, and all fight the same
integration problems more or less. But in several of those areas the
problems discussed regarding HTTP authentication is more accepted as
"how things work" and not considered such big problem..

But it's also true that the use of plaintext is very common due to much
the same reasons in integration and migration.

> * How a web page can securely associate branding with a DIGEST authentication
>   UI in the browser

Yes.

> * How to migrate an existing password repository using an arbitrary
>   one-way-function to store password verifiers to one that's DIGEST compatible,
>   and do so in a way that won't generate service calls from customers.

The simple fact that there is some migration is usually sufficient to
stop such project even at the planning stage. But it's unavoidable in
order to get away from plain-text exchanges.

It's not a very hard migration, especially not if the password backend
already periodically expires passwords. But it requires the backend to
support Digest (or whatever scheme is used), and for password storage
security reasons to be configured with the realm details..

> Since implementations already have all this infrastructure for plaintext 
> passwords (existing standards are sufficient due to plaintext simplicity), why 
> should they waste time doing a one-off version of all this work if there aren't 
> enough standards written for it to interoperate?

Even with standards chances are high the needed support would not be
enabled by default, or even implemented.

> Besides, DIGEST without TLS 
> is now so weak in a 10-cents-per-windows-zombie-CPU-week world that I question 
> the value of doing any of this work just for DIGEST.

I wouldn't say Digest is that weak. Sure, it's possible to perform a
offline brute-force password guessing attack based on the exchanges, and
due to all the legacy crap it's possible for a man in the middle to
downgrade Digest slightly if the client and server is willing to.

But yes, there is a need for a stronger replacement. Especially one
without all the compatibility fallbacks crap.

But more importantly there is a need for a robust framework where new
schemes can be plugged in more easily, and most importantly a way to
make HTTP authentication more visually and functionality attractive in
the browser world.

Even if IETF comes up with the technically most secure authentication
scheme it's unlikely to gain widespread foothold as "the" HTTP
authentication scheme and there will always be major vendors doing their
own thing I am afraid.

Regards
Henrik