[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PaceSecurityServices & Digest auth

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 and 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.


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