PaceSecurityServices & Digest auth

[Ezra Cooper <ezra@xxxxxxxxxxxx>]

I'd like to express support for specifying some authentication 
method(s) for use with Atom, for interoperability--and also for the 
Digest auth method. For our environment (Six Apart), it's preferable to 
WSSE-style because in generic hosting environments, we don't want to 
store the password in cleartext. For that reason, I don't think 
WSSE-style auth should be required for Atom servers (I say +1 to the 
current wording, "MUST support either... SHOULD support both").

I see three issues to be addressed with Digest:

  (1) Some web-servers remove the WWW-Authenticate header before 
passing it to a CGI program.
  (2) We need an equivalent method for use within a SOAP message.
  (3) The default HTTP Digest auth algorithm is based on MD5, and 
requires the server to be able to form an MD5 hash based on the triple 
(username, realm, password). If you don't store either the cleartext 
password or that specific hash, you're out of luck.

To address (1), I propose this addition to the end of section K,kk. in 
PaceSecurityServices:

========
An Atom client MAY authenticate itself to an Atom server by sending an 
X-Atom-Authenticate HTTP header, in the same form as for the 
WWW-Authenticate header [RFC2617]. If an Atom client sends a 
WWW-Authenticate header, it SHOULD have the same value as the 
X-Atom-Authenticate header.
========

This is in line with some of the mechanisms that have been suggested, 
for example in Joe Gregorio's post [1].

As to (2), I suggest that we simply tunnel the header fields of HTTP 
Digest Auth within XML elements (the same way we've done with WSSE). 
Using WSSE UsernameToken is attractive, except for requiring the server 
to store the password in the clear. I'll be interested what others 
think about this.

To address the third issue, I'd like to propose some alternative 
"algorithms" (in the sense of RFC 2617) for Digest auth. In particular 
I'd like to offer new functions to take the role of the H and KD 
functions used in RFC 2617, sections 3.2.2.1 and 3.2.2.2. I'm happy to 
propose these in a separate RFC, or help work them into the Atom spec. 
I do believe that they would have usefulness outside of Atom, and yet 
my immediate goal is to achieve interoperable Atom implementations.

Thanks,
Ezra

References
[1] http://bitworking.org/news/New_AtomAPI_Implementation_Release2