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.


Atom API

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 

  - 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 
  []. 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.


Original proposal post to atom-syntax from PaulHoffman [WWW]New proposal: security services for Atom

See [WWW]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:

  1. that some people cannot access the Authorization-header from PHP or some other server-side language.

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

Note that mapping WSSE (or Digest) to a HTTP header will require either JavaScript or a 'custom binary' on the client side, since current webbrowsers do not implement this (and probably will not for the next (few )year(s)).

Because we have to use JavaScript or a 'custom binary' we should be able to also solve 2. within standard HTTP digest authentication

In conclusion the solution would be:


Related: PaceFeedSignature See Also: PaceDigitalSignatures