Add sections to the Protocol about "Securing the Atom Protocol" and Security Considerations.
Active. Please direct discussion to the atom-syntax list:
One of the side-effects of being in the IETF is that we are not allowed to hand-wave or under-specify security for our documents. We don't need to decide all of the security properties in our -00 drafts, but it would be useful for us to start thinking about them now.
Section: Securing the Atom Protocol
K,kk. Securing the Atom Protocol All instances of publishing Atom entries SHOULD be protected by authentication to prevent posting or editing by unknown sources. Atom servers and clients MUST support either of the following authentication mechanisms, and SHOULD support both. - HTTP Digest Authentication [ref] - WSSE-style authentication (described below) Atom servers and clients MAY support encryption of the Atom session using TLS [ref]. K,kk.1 WSSE-style Authentication This authentication method is included as part of the protocol to allow Atom servers and clients that cannot use HTTP Digest Authentication but where the user can both insert its own HTTP headers and create a CGI program to authenticate entries to the server. This scenario is common in environments where the user cannot control what services the server employs, but the user can write their own HTTP services. The authentication method described here has weaker cryptographic properties as HTTP Digest Authentication because this method does not allow the server to choose the nonce for protecting the shared secret. This method is more susceptible to replay attacks than HTTP Digest Authentication because it forces the server to expire tokens based on a combination of remembering successful nonces and the time given in the responses; HTTP Digest Authentication allows using an server-based nonce expiration mechanism. This is particularly bad in the all-too-common scenario where the clocks on the client and the server are significantly skewed from each other. [[ Description here of a new authentication mechanism similar to [http://www.xml.com/pub/a/2003/12/17/dive.html]. More explanation of the crypto properties will be added. ]]
Section: Security Considerations
KK.kk. Security Considerations Because Atom is a publishing protocol, it is important that only authorized users can create and edit entries. The security of Atom is based on HTTP Digest Authentication and/or the WSSE-style authentication described in this document. Any weaknesses in either of these two protocols will obviously affect the security of the Atom publishing protocol. Both HTTP Digest Authentication and the WSSE-style authentication described in this document are susceptible to dictionary-based attacks on the shared secret. If the shared secret is a password (instead of a random string with sufficient entropy), an attacker can determine the secret by exhaustively comparing the authenticating string with hashed results of the public string and dictionary entries. See RFC 2617 for more detailed description of the security properties of HTTP Digest Authentication.
Atom Protocol specification text.
See RFC2617 for more detailed description of the security properties of HTTP Digest Authentication.
Note that I'm not all that happy with the WSSE-style authentication in the second part, but have included it because others have said that the scenario for it is plausible. My preference would be to go only with HTTP Digest Authentication, but am OK with us rolling a second option. PaulHoffman
Why use WSSE?
The reasons proclaimed here are:
that some people cannot access the Authorization-header from PHP or some other server-side language.
the clock synchronization problem.
To solve 1. one could map the authorization header to say 'X-Authorization' or 'X-Digest' and simply use the same digest authentication for those clients where the Authorization-header is not passed on to the http-service.
In conclusion the solution would be:
- Use digest authentication
- Send an extra "X-Authorization"-header containing the same as the "Authorization"-header possibly appended by a client-timestamp