Re: [secdir] [xmpp] SECDIR review of draft-ietf-xmpp-3921bis-15.txt

[Peter Saint-Andre <[e-mail]>]

On 10/25/10 10:10 PM, Peter Saint-Andre wrote:
> Thanks for the review. One comment inline.
> 
> On 10/25/10 8:08 PM, Richard L. Barnes wrote:
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the IESG.
>>  These comments were written primarily for the benefit of the security
>> area directors.  Document editors and WG chairs should treat these
>> comments just like any other last call comments.
>>
>> This document describes an instant-messaging and presence system based
>> on the core system of exchanging XML stanzas described in RFC 3920 and
>> draft-ietf-xmpp-3920bis.  As the document rightly notes, the underlying
>> transport protocol addresses most of the security considerations for
>> this document, and that document seems to have a thorough discussion of
>> security considerations (although I have not done a thorough review). In
>> general, I think that the security considerations in this document
>> adequately describe the additional risks posed by the instant-messaging-
>> and presence-specific parts of the protocol (beyond those of the base
>> protocol), and corresponding mitigations.
>>
>> One thing that might merit clarification: The overriding
>> application-layer security concern here is the proper routing of
>> presence and instant messaging stanzas through the XMPP system.
>> (Underlying communications security concerns are addressed by the core
>> spec.)  For the most part, these concerns with requirements on servers
>> to act in certain ways on behalf of the user.  It could be helpful to
>> the reader to re-state some of the communications patterns from Section
>> 13.1 of draft-ietf-xmpp-3920bis and comment on the particular roles that
>> the entities play in the context of instant messaging and presence
>> (e.g., routing unicast <message> stanzas, fan-out of broadcast presence
>> messages).
> 
> Although in general I'm not a fan of repeating material that is already
> covered by a referenced specification, I agree that it might be
> appropriate to provide a reminder about the underlying architecture of
> XMPP and its implications for the security of various IM-related and
> presence-related interactions. I'll reply again once I have investigated
> the best location for such a reminder and have formulated proposed text.

Does the following text (to be added to the Security Considerations
section of 3920bis) address your concern?

###

   Section 13.1 of [XMPP-CORE] outlines the architectural roles of
   clients and servers in typical deployments of XMPP, and discusses the
   security properties associated with those roles.  These roles have an
   impact on the security of instant messages, presence subscriptons,
   and presence notifications as described in this document.  In
   essence, an XMPP user registers (or has provisioned) an account on an
   XMPP server and therefore places some level of trust in the server to
   complete various tasks on the user's behalf, enforce security
   policies, etc.  Thus it is the server's responsibility to:

   1.  Preferably mandate the use of channel encryption for
       communication with local clients and remote servers.

   2.  Authenticate any client that wishes to access the user's account.

   3.  Process XML stanzas to and from clients that have authenticated
       as the user (specifically with regard to instant messaging and
       presence functionality, store the user's roster, process inbound
       and outbound subscription requests and responses, generate and
       handle presence probes, broadcast outbound presence
       notifications, route outbound messages, and deliver inbound
       messages and presence notifications).

   As discussed in Sections 13.1 and 13.4 of [XMPP-CORE], even if the
   server fulfills the foregoing responsibilities, the client does not
   have any assurance that stanzas it might exchange with other clients
   (whether on the same server or a remote server) are protected for all
   hops along the XMPP communication path, or within the server itself.
   It is the responsibility of the client to use an appropriate
   technology for encryption and signing of XML stanzas if it wishes to
   ensure end-to-end confidentiality and integrity of its
   communications.

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/