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

On Monday 11 June 2007 09:38, Jamie Lokier wrote:
> A few notes on what I think forms + cookies offers that RFC2617 doesn't.
>
>     1. The login cookie (or its validity) can be expired under control
>        of the server.  That is, the site can offer a "logout now"
>        button, options for "logout at end of session" and "keep me
>        logged in between sessions" - and also control the idle expiry
>        time.
Again, this is an implementation issue.
Regarding basic auth, this is true -- there is no way to "expire the session".
But using digest you can implement full-fledged session control, because
the server has got the "nonce" values under control and can store
a sessionid in it.
There is a proof of concept for this available at http://auth.ingostruck.de
you can register, login, logout and the session expires, all using plain 
rfc2617 digest auth.

As for "keep me logged in between sessions" I would tend to say that this
is one of the major security risks and would neither incorporate it into a 
potential rfc2617 successor nor recommend to implement it (and it could still 
be done using cookies for non-sensitive parts of a site).

>     2. Related to above, different types of access can be maintained
>        simultaneously for the same pages.  For example, the server may
>        remember who you are between sessions for personalisation - but
>        for critical operations require re-authentication between. I
>        think Ebay does this - you can remain logged in between
>        sessions for convenient browsing, but placing a bid requires a
>        password confirmation each session.
>
>     3. Password transfer for authentication can be done over SSL/TLS,
>        even if the accessed pages after that are plaintext with the
>        cookie as authenticator, for performance or caching reasons.
There is no need for that with digest *and* you do not even need
SSL/TLS for auth purposes.
The only part that needs SSL/TLS is registration (exchange new credentials
between server and client), but this is expressly outside of rfc2617's scope.

Current UA impls do not send auth across schemes (http/https), which makes 
perfectly sense for basic, but for digest this could be done without major
changes to rfc2617, because the scheme is not involved in the hash calculus.

>     4. Related to 3, a clever site could run client-side ECMAscript to
>        apply a crypto operation to the authentication cookie on every
>        page fetch, so the shared secret is not revealed on the wire
>        and is immune to replay attacks, combining the advantages of
>        both methods.  (I'm not aware of any site doing this, but it
>        seems plausible, for browser-accessed sites only of course).
Replay attacks could already be avoided using digest auth,
if nc would be implemented correctly by UAs. Even with broken ua
impls who mess up nc, a server can implement one-shot nonces at the
cost of another round-trip using the "stale" mechanism
(within my impl a nonce becomes stale after 10 requests and after
every single POST request).

>     5. Forms + cookies can be implemented by any server-side page
>        rendering scheme, e.g. PHP, Perl, CGI, etc. which handles forms
>        + cookies for other purposes.  In other words, it's accessible
>        to actual site authors, who often can't reconfigure their web
>        server but can write those scripts.  Yes, this is an
>        implementation detail, but there's practical reasons why it's
>        such as _very_ common implementation detail.
This one seems to be the crux of the matter, but the 
Authorization, Authenticate and Proxy-Authenticate headers are available
to all those server-side-rendering schemes too (at least through CGI,
via HTTP_AUTHORIZATION etc.).

>     3. Retaining the server control of behaviour that forms + cookies
>        offers.  Ability to force "logout now" - not merely request, by
>        declaring an authentication token no longer valid.
>
>        Time-based expiration. 
Could already be done, just like with cookies.
Maybe an explanation *how* this could be done should be added.

>        Ability to 
>        retain different levels of authentication simultaneously for
>        different aspects of a site.
If different "realms" are properly implemented, this could be done, too.

>        Ability to request that a client 
>        forgets the user's password.  
This is part of "exchange new credentials between server and client"
which has been left out of rfc2617 by purpose.
Maybe this is one of the major deficiencies there (the i18n problem
for passwords is a result of this too).

>     4. Describing hooks whereby the UI elements can appear embedded in
>        a related HTML page, but aren't required to be.
>     5. Ensure that it's possible that site authors who write in
>        e.g. PHP, Perl, CGI etc. can easily make use of the scheme.
>        Simply because this is an important requirement for practical
>        deployment.
These two seem to be the crucial points to me: 
- hook up to the "application layer" in a well-defined way
  within the spec (like I already wrote in a mail to the wg list)
- create working reference a/o example impls for major web servers

Kind regards

Ingo Struck

Received on Monday, 11 June 2007 13:30:59 UTC