I've updated the text to reflect some of the discussion. There are still areas that need obvious work. (For most of this, I just threw in some quick text knowing full well that it would need to be changed/fixed-up)
http://www.intertwingly.net/wiki/pie/PaceSecurityConsiderations Changes: * Using https with basic is not a MUST, but is recommended * The must/should handling of xml encrypted entries is changed ------------------- 14. Security Considerations 14.1 Authentication Implementors are advised to use client authentication mechanisms to prevent posting or editing by unknown or unauthorized sources. The type of authentication used is a local decision made by the server. Accordingly, clients are likely to face authentication schemes that vary across implementations. '''Ed.Note: Should this MUST stay? go? move to another section? Is it a MUST/SHOULD/MAY?''' Servers utilizing authentication MUST reject unauthorized or unauthenticated requests using the HTTP 401 "Unauthorized" response message. Per [RFC2616], 401 Unauthorized responses MUST include a WWW-Authenticate header identifying the authentication scheme that is to be used. Servers utilizing authentication mechanisms that involve the clear-text transmission of a password (e.g. HTTP Basic Authentication) are encouraged to secure the connection using, for example, a Transport Layer Security (TLS) connection. 14.2 Denial of Service Atom Publishing server implementations are susceptible to various forms of denial of service attacks. For instance, a malicious client could attack a server by posting extremely large files, by rapidly submitting multiple, illegitimate creation or modification requests to a collection or entry, or by making multiple pipelined requests on multiple connections. 14.3 Privacy Concerns Because collections might be editable by multiple clients, privacy concerns could arise when clients are granted full read and edit access to all of a collections member entries and metadata. To reduce the risk of inadvertent release or modification of private information via collection feeds, entry documents and linked media resources, servers are encouraged to utilize access control mechanisms that limit a clients ability to read and edit the metadata associated with a collection and it's member resources. 14.4 XML External Entities and Links within Atom document Atom Feed and Entry documents can contain XML External Entities as defined in section 4.2.2 of [REC-XML]. Atom implementations are not required to load external entities. However, implementations that choose to support external entities within Atom documents need to be aware of the risks inherent in doing so. Specifically, external entities are subject to all of the same security concerns as HTTP GET operations and run the risk of signficantly altering the semantics of the Atom document. Likewise, servers should consider resources linked to by atom:link and atom:content elements as being inherently untrustworthy and subject to all of the same security risks as HTTP GET operations. 14.5 Digital Signatures and Encryption '''Ed.Note: the text here stinks, but it gets away from the shoulds and musts. better text is requested :-)''' A server receiving an atom:entry that has been encrypted using XML Encryption is permitted to process that entry in whatever manner it chooses. For instance, the server could choose to treat the encrypted entry as it would any arbitrary non-Atom resource (e.g. by, possibly, creating a media-link entry that references the encrypted resource). Alternatively, the server could choose to decrypt the resource and add the non-encrypted entry to the collection. Clients sending XML Encrypted entries to a collection can make no assumptions as to how the request will be processed. A server receiving an atom:entry that contains an XML Digital Signature is not required to preserve the integrity of that signature. That is, the server may modify the entry in such a way that the original signature included with the POST is broken or it may choose to remove the signature from the entry. The server MAY choose to add its own XML Digital Signature to the entry. 14.6. Unsafe Media Posts Server implementations that allow clients to post non-Atom resources to a collection to create media-link entries need to be aware of the potential threat of allowing clients to send arbitrary and inherently unsafe media-types. For example, a collection that allows executable binary or script resources to be posted could be used by an attacker to distribute a virus to subscribers of that collection's Atom feed. To reduce the likelihood of such attacks, implementions should enforce limits on the types of media resources that may be posted to a collection. ------------------- - James
