Subject: [secdir] SECDIR review of draft-ietf-xmpp-address-05.txt

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Oct 2010 22:08:16 -0400

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 a data structure for addressing XMPP resources. 
  As such, it has the potential to create authentication issues, in 
particular related to spoofing and mimicry of addresses.  The document 
does a good job of describing these risks and available mitigations, but 
could use a little bit of clarification on a few points.

Detailed comments follow.

--Richard

Major issues:

General: It's not clear to me from the text in this document JIDs differ 
from XMPP URIs.  My naïve assumption would be that an XMPP URI would 
simply be a JID with the scheme "xmpp:" prepended, but the last 
paragraph of Section 2.1 made me uncertain about this.  (I have not 
checked RFC 5122 to verify whether this is the case syntactically.) 
Since many client applications will have to convert from XMPP URIs to 
JIDs -- and because this is a security-sensitive operation -- it seems 
like it would be helpful for this document to specify conversions 
between XMPP URIs and JIDs, even if only by reference to RFC 5122.

S4.3:
It seems like there should be some discussion here about how entities 
that create JIDs can help mitigate issues of confusability.  For 
example, the existence of confusable characters in the domainpart is 
mitigated by proper registry policies (which I presume could be 
incorporated by reference to some IDNA documents).  Localparts and 
resourceparts are not constrained  to be domain names, but they are 
controlled or at least approved by a server, so the server can apply 
similar policies to these parts.

S4.4.1 P2:
The observation that only part of an identifier can be authenticated is 
a good one to make, but there's one subtlety: The remote server is 
actually authoritative for the localpart and resourcepart of the JID, so 
the fact that the remote domain has assigned a particular 'from' address 
effectively authenticates those fields when the domain is authenticated. 
  It might help to note that end-to-end authentication of XMPP stanzas 
could help mitigate this risk, since it would require the rogue server 
to generate false credentials in addition to modifying 'from' addresses.

Minor issues:

S2.2 P2: For clarity, I would change the "SHOULD be an FQDN, can be an 
IP address or unqualified host name" to "MUST be an FQDN, IPv4 address 
literal, IPv6 address literal, or unqualified host name".  If the 
intention here is that unqualified host names should have the same 
syntax as FQDNs, then that should be stated.

S2.2 P3: Not clear why this is a "Note:" paragraph, especially since it 
has "MUST" requirements in it.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Oct 2010 17:47:52 -0400

> Is this revised text clearer?
>
>   For the purpose of communication over an XMPP network (e.g., in the
>   'to' or 'from' address of an XMPP stanza), an entity's address MUST
>   be represented as a JID, not as a Uniform Resource Identifier [URI]
>   or Internationalized Resource Identifier [IRI].  An XMPP URI or IRI
>   [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the  
> native
>   addressing format used in XMPP is that of a mere JID without a URI
>   scheme.  ([XMPP-URI] is provided only for identification and
>   interaction outside the context of XMPP itself, for example when
>   linking to a JID from a web page.)

Yes, that is better, especially with the revision below.

> However, we might want to add the following sentence at the end of the
> revised paragraph quoted above:
>
>   See [XMPP-URI] for a description of the process for securely
>   extracting a JID from an XMPP URI or IRI.

After taking a better look at RFC 5122, I agree that that sentence is  
all that's needed.

> That said, I think draft-ietf-xmpp-address-06 (you reviewed -05)
> includes some text that might address your concern, to wit:
>
> ###
> ...
> ###
>
> Does that help?

That's exactly what I was looking for!  Presumably the same  
considerations apply to resourceparts, so perhaps just one more  
sentence establishing that equivalence would be in order.

>> to generate false credentials in addition to modifying 'from'  

Any thoughts on this issue?

> I take it you mean something like the following edited text:
>
> ###
>
>   The domainpart for every XMPP service MUST be a fully qualified
>   domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or
>   unqualifed hostname (i.e., a text label that is resolvable on
>   a local network).
>
>      Interoperability Note: Domainparts that are IP addresses might
>      not be accepted by other services for the sake of server-to- 
> server
>      communication, and domainparts that are unqualified
>      hostnames cannot be used on public networks because they are
>      resolvable only on a local network.
>
> ###
>
> Is that what you were looking for?

Yes.

> I've removed the "Implementation Note:" string at the beginning of  
> that
> paragraph.

Ok.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Oct 2010 18:12:59 -0400

On Oct 26, 2010, at 6:09 PM, Peter Saint-Andre wrote:

> On 10/26/10 3:47 PM, Richard L. Barnes wrote:
>
> <snip/>
>
>>>> S4.3: It seems like there should be some discussion here about
>>>> how entities that create JIDs can help mitigate issues of
>>>> confusability.  For example, the existence of confusable
>>>> characters in the domainpart is mitigated by proper registry
>>>> policies (which I presume could be incorporated by reference to
>>>> some IDNA documents).  Localparts and resourceparts are not
>>>> constrained  to be domain names, but they are controlled or at
>>>> least approved by a server, so the server can apply similar
>>>> policies to these parts.
>>>
>>> ### ... ###
> See the antepenultimate sentence of this adjusted paragraph:
>
> ###
>
>   1.  Because an XMPP service that allows registration of XMPP user
>       accounts (localparts) plays a role similar to that of a registry
>       for DNS domain names, such a service SHOULD establish a policy
>       about the scripts or blocks of characters it will allow in
>       localparts at the service.  Such a policy is likely to be
>       informed by the languages and scripts that are used to write
>       registered account names; in particular, to reduce confusion,  
> the
>       service MAY forbid registration of XMPP localparts that contain
>       characters from more than one script and to restrict
>       registrations to characters drawn from a very small number of
>       scripts (e.g., scripts that are well-understood by the
>       administrators of the service).  Such policies are also
>       appropriate for XMPP services that allow temporary or permanent
>       registration of XMPP resourceparts, e.g., during resource  
> binding
>       [XMPP] or upon joining an XMPP-based chat room [XEP-0045].  For
>       related considerations in the context of domain name
>       registration, refer to Section 4.3 of [IDNA-PROTO] and Section
>       3.2 of [IDNA-RATIONALE].  Note well that methods for enforcing
>       such restrictions are out of scope for this document.
>
> ###

Perfect.

>
>>>> S4.4.1 P2: The observation that only part of an identifier can be
>>>> authenticated is a good one to make, but there's one subtlety:
>>>> The remote server is actually authoritative for the localpart and
>>>> resourcepart of the JID, so the fact that the remote domain has
>>>> assigned a particular 'from' address effectively authenticates
>>>> those fields when the domain is authenticated. It might help to
>>>> note that end-to-end authentication of XMPP stanzas could help
>>>> mitigate this risk, since it would require the rogue server to
>>>> generate false credentials in addition to modifying 'from'
>>>> addresses.
>>
> Sorry, I was going to scroll up to that part of the email before  
> hitting
> send. :)
>
> I suggest the following modified text:
>
> ###
>
>   Address forging is difficult in XMPP systems, given the requirement
>   for sending servers to stamp 'from' addresses and for receiving
>   servers to verify sending domains via server-to-server  
> authentication
>   (see [XMPP]).  However, address forging is possible if:
>
>   o  A poorly implemented server ignores the requirement for stamping
>      the 'from' address.  This would enable any entity that
>      authenticated with the server to send stanzas from any
>      localpart@domainpart as long as the domainpart matches the  
> sending
>      domain of the server.
>
>   o  An actively malicious server generates stanzas on behalf of any
>      registered account.
>
>   Therefore, an entity outside the security perimeter of a particular
>   server cannot reliably distinguish between bare JIDs of the form
>   <localpart@domainpart> at that server and thus can authenticate only
>   the domainpart of such JIDs with any level of assurance.  This
>   specification does not define methods for discovering or
>   counteracting such poorly implemented or rogue servers.  However,  
> the
>   end-to-end authentication or signing of XMPP stanzas could help to
>   mitigate this risk, since it would require the rogue server to
>   generate false credentials in addition to modifying 'from'  
> addresses.
>
> ###
>
> Hopefully by the time we supersede the address spec, we will have
> developed a technology for end-to-end signing and encryption of XMPP
> stanzas, which we can reference from the foregoing paragraph.

Hope springs eternal :)

Revised text is fine.

Thanks for responding quickly.

--Richard

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 26 Oct 2010 15:11:10 -0600

[Copying [email-masked] to keep the WG in the loop...]

Thanks for the review.

Please be aware that you reviewed draft-ietf-xmpp-address-05, but based
on further discussion in the XMPP WG we published -06 right before the
October 25 cutoff, and I think -06 includes text that might address some
of your concerns (details below). A diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-xmpp-address-06.txt

On 10/25/10 8:08 PM, Richard L. Barnes wrote:
> simply be a JID with the scheme "xmpp:" prepended, 

Correct. There are complexities involved when the JID contains
characters outside the ASCII range, which is why RFC 5122 says to
convert the URI to an IRI before extracting the JID.

> but the last

   [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the native

> between XMPP URIs and JIDs, even if only by reference to RFC 5122.

I agree that we need to somewhere describe how a JID can be securely
extracted from an XMPP URI, and I think RFC 5122 handles that fairly
well at the moment. If the matter is not clear in RFC 5122, then it
needs to be clarified in 5122bis -- RFC 5122 will be revised anyway once
we supersede the address spec you've reviewed, once 3987bis is
published, etc. Because this (temporary) address spec mentions XMPP
URIs/IRIs only to say that they are explicitly out of scope for XMPP
itself and must not be used as the address format for communication over
an XMPP network, I think it's not proper to introduce dependencies on
RFC 5122 in the core specification.

> similar policies to these parts.

The XMPP community is just beginning to get a handle on these issues. I
agree that an XMPP server functions as a registry of sorts: a registry
of localparts associated with accounts. See for instance the last
paragraph here:

http://tools.ietf.org/html/draft-saintandre-xmpp-i18n-02#section-2

Similarly, an XMPP groupchat service functions as kind of registry for
temporary resourceparts, and in some cases even permanent resourceparts:

http://xmpp.org/extensions/xep-0045.html#register

With the understanding that usernames can be provisioned and not
registered directly by a user, I'll point out that the "in-band
registration" protocol (XEP-0077) traditionally used for registration of
an account at an XMPP server has included absolutely no support for
registration *policies* (e.g., disallowing symbol characters in the
localpart), because the XMPP community was blithely unaware of possible
problems with the lack of such policies. This is something that needs to
be remedied, but it has not been remedied yet. I'm hoping that work on
the successor to the address spec you've reviewed will lead to at least
some solutions to these problems, and the individual I-D that I
mentioned above is an attempt at starting that conversation.

###

   Despite the fact that some specific suggestions about identification
   and handling of confusable characters appear in the Unicode Security
   Considerations [UNICODE-SEC], it is also true (as noted in
   [IDNA-DEFS]) that "there are no comprehensive technical solutions to
   the problems of confusable characters".  Mimicked JIDs that involve
   characters from only one script, or from the script typically
   employed by a particular user or community of language users, are not
   easy to combat (e.g., the simple typejacking attack previously
   described, which relies on a surface similarity between the
   characters "1" and "l" in some presentations).  However, mimicked
   addresses that involve characters from more than one script, or from
   a script not typically employed by a particular user or community of
   language users, can be mitigated somewhat through the application of
   appropriate registration policies at XMPP services and presentation
   policies in XMPP client software.  Therefore the following policies
   are encouraged:

   1.  Because an XMPP service that allows registration of XMPP user
       accounts (localparts) plays a role similar to that of a registry
       for DNS domain names, such a service SHOULD establish a policy
       about the scripts or blocks of characters it will allow in
       localparts at the service.  Such a policy is likely to be
       informed by the languages and scripts that are used to write
       registered account names; in particular, to reduce confusion, the
       service MAY forbid registration of XMPP localparts that contain
       characters from more than one script and to restrict
       registrations to characters drawn from a very small number of
       scripts (e.g., scripts that are well-understood by the
       administrators of the service).  For related considerations in
       the context of domain name registration, refer to Section 4.3 of
       [IDNA-PROTO] and Section 3.2 of [IDNA-RATIONALE].  Note well that
       methods for enforcing such restrictions are out of scope for this
       document.

   2.  Because every human user of an XMPP client presumably has a
       preferred language (or, in some cases, a small set of preferred
       languages), an XMPP client SHOULD gather that information either
       explicitly from the user or implicitly via the operating system
       of the user's device.  Furthermore, because most languages are
       typically represented by a single script (or a small set of
       scripts) and most scripts are typically contained in one or more
       blocks of characters, an XMPP client SHOULD warn the user when
       presenting a JID that mixes characters from more than one script
       or block, or that uses characters outside the normal range of the
       user's preferred language(s).  This recommendation is not
       intended to discourage communication across different communities
       of language users; instead, it recognizes the existence of such
       communities and encourages due caution when presenting unfamiliar
       scripts or characters to human users.

###

Does that help?

###

      not be accepted by other services for the sake of server-to-server

###

> has "MUST" requirements in it.

I've removed the "Implementation Note:" string at the beginning of that
paragraph.

Thanks again for the review.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 26 Oct 2010 16:09:21 -0600

<snip/>

###

       registration of XMPP resourceparts, e.g., during resource binding

###

> Any thoughts on this issue?

Sorry, I was going to scroll up to that part of the email before hitting
send. :)

###

   Address forging is difficult in XMPP systems, given the requirement
   for sending servers to stamp 'from' addresses and for receiving
   servers to verify sending domains via server-to-server authentication
   (see [XMPP]).  However, address forging is possible if:

   o  A poorly implemented server ignores the requirement for stamping
      the 'from' address.  This would enable any entity that
      authenticated with the server to send stanzas from any
      localpart@domainpart as long as the domainpart matches the sending
      domain of the server.

   Therefore, an entity outside the security perimeter of a particular
   server cannot reliably distinguish between bare JIDs of the form
   <localpart@domainpart> at that server and thus can authenticate only
   the domainpart of such JIDs with any level of assurance.  This
   specification does not define methods for discovering or
   counteracting such poorly implemented or rogue servers.  However, the
   end-to-end authentication or signing of XMPP stanzas could help to
   mitigate this risk, since it would require the rogue server to
   generate false credentials in addition to modifying 'from' addresses.

###

Peter

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