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.




The spec's current Security Considerations are lacking in detail and scope


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