Abstract
For Draft-09...
The spec's current Security Considerations are lacking in detail and scope.
** Revised ** Text for the "Security Considerations" portion has been pulled from PaceAuthenticationAndSecurityConsiderations, with some modifications. Some language from the "HTTP Access authentication" section of PaceAuthenticationAndSecurityConsiderations has been adopted.
Status
Open
Rationale
The spec's current Security Considerations are lacking in detail and scope
Proposal
12. Securing the Atom Publishing Protocol The Atom Publishing Protocol is based on HTTP. Authentication requirements for HTTP are covered in Section 11 of [RFC2616]. The use of authentication mechanisms to prevent posting or editing by unknown or unauthorized clients is RECOMMENDED but not required. When authentication is not used, clients and servers are vulnerable to trivial spoofing, denial of service and defacement attacks, however, in some contexts, this is an acceptable risk. The type of authentication deployed is a local decision made by the server operator. Clients are likely to face authentication schemes that vary across server deployments. At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection [RFC4346] as specified by [RFC2818]. The choice of authentication mechanism will impact interoperability. The minimum level of security referenced above (Basic Auth with TLS) is considered good practice for Internet applications at the time of publication of this specification and sufficient for establishing a baseline for interoperability. Implementers should, in general, investigate and use alternative mechanisms regarded as equivalently good or better at the time of deployment. It is RECOMMENDED that clients be implemented in such a way that allows new authentication schemes to be deployed. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using an appropriate 4xx HTTP response code (e.g. 401 "Unauthorized" or 403 "Forbidden") in accordance with RFC 2617. 13. Security Considerations As an HTTP-based protocol, APP is subject to the security considerations found in [RFC2616] Section 15. 13.1 Denial of Service Atom Publishing server implementations need to take adequate precautions to ensure malicious clients cannot consume excessive server resources (CPU, memory, disk, etc). 13.2 Replay Attacks Atom Publishing server implementations are susceptible to replay attacks. Specifically, this specification does not define a means of detecting duplicate requests. Accidentally sent duplicate requests are indistinguishable from intentional and malicious replay attacks. 13.3 Spoofing Attacks Atom Publishing implementations are susceptible to a variety of spoofing attacks. Malicious clients may send Atom entries containing inaccurate information anywhere in the document. 13.4 Linked Resources 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. External entities are subject to the same security concerns as any network operation and can alter the semantics of an Atom document. The same issues exist for resources linked to by Atom elements such as atom:link and atom:content. 13.5 Digital Signatures and Encryption Atom Entry Documents sent to a server might contain XML Digital Signatures [W3C.REC-xmldsig-core-20020212] and might be encrypted using XML Encryption [W3C.REC-xmlenc-core-20021210] as specified in section 5 of [RFC4287]. Servers are allowed to modify received resource representations in ways that can invalidate signatures covering those representations. 13.6. URIs and IRIs Atom Publishing Protocol implementations handle URIs and IRIs. See Section 7 of [RFC3986] and Section 8 of [RFC3987].
