Yes, I know it's not quite there yet; I've been hoping that some of the
other WG members would start getting in there and tearing it apart but,
as yet, haven't had much success. It would be excellent it Sam could
take a look.
- James
Lisa Dusseault wrote:
> I don't believe this proposed text quite meets the requirements in
> RFC3552. BTW, I've asked Sam to comment on the Security Considerations
> or have somebody comment at tomorrow's WG meeting, but he's probably
> looking at the latest draft, not at Paces.
>
> Lisa
>
> On Jul 5, 2006, at 4:51 PM, James M Snell wrote:
>
>>
>> Ok, a few more tweaks on PaceSecurityConsiderations, Most importantly,
>> expanding the discussion of Replay and Spoofing attacks.
>>
>> #pragma section-numbers off
>>
>> == Abstract ==
>>
>> For Draft-09...
>>
>> The spec's current Security Considerations are lacking in detail and
>> scope.
>>
>> == Status ==
>>
>> In Progress. '''Updated'''
>>
>> == Rationale ==
>>
>> The spec's current Security Considerations are lacking in detail and
>> scope
>>
>> == Proposal ==
>>
>> {{{
>> 12. Security Considerations
>>
>> 12.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.
>>
>> It is suggested but not required that servers utilizing authentication
>> mechanisms involving the clear-text transmission of a password (e.g.
>> HTTP Basic Authentication) secure the connection using, for example, a
>> Transport Layer Security (TLS) connection.
>>
>> 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").
>>
>> 12.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 resources, by rapidly
>> submitting multiple, illegitimate creation or modification requests to a
>> collection or entry, or by making multiple pipelined requests on
>> multiple connections.
>>
>> 12.3 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.
>>
>> 12.4 Spoofing Attacks
>>
>> Atom Publishing implementations are susceptible to a variety of spoofing
>> attacks.
>>
>> For instance, a malicious client could POST an entry to a collection
>> fraudulently using some other individuals name, email address and URI in
>> the atom:author element. To prevent such an attack, servers could
>> consider verifying, augmenting and possibly overriding the content of a
>> POSTed entries atom:author element. For instance, the atom:author could
>> be extended to specify the IP address from which the request originated,
>> or the authenticated identity of the individual that sent the request.
>>
>> Additionally, collections that choose to accept the value of a newly
>> POSTed entries atom:id element without modification, and which allow
>> multiple members within the collection to share identical atom:id
>> values, are at risk of falling victim to the type of spoofing attack
>> described in section 8.4 of [RFC4287]. Specifically, Atom processors
>> could suppress display of duplicate entries by displaying only one entry
>> from a set of entries with identical atom:id values.
>>
>> 12.5 Privacy Concerns and Access Control
>>
>> 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. This specification does not define a means of
>> controlling the access to a collection or it's member resources.
>>
>> 12.6 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.
>>
>> 12.7 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].
>>
>> A server receiving an entry containing 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 signature is broken
>> or it may choose to remove the signature from the entry. The server can
>> choose to add its own XML Digital Signature to the entry.
>>
>> 12.8. 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 resource representations. 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 are
>> encouraged to enforce limits on the types of media resources that can be
>> posted to a collection.
>>
>> 12.9. URIs and IRIs
>>
>> Atom Publishing Protocol implementations handle URIs and IRIs. See
>> Section 7 of [RFC3986] and Section 8 of [RFC3987].
>>
>> }}}
>>
>> == Impacts ==
>>
>> == Notes ==
>>
>> Some portions inspired/copied from http://www.ietf.org/rfc/rfc2518.txt
>> (WebDAV)
>>
>> ----
>>
>> CategoryProposals
>>
>
>
