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

"Richard L. Barnes" <> Tue, 26 October 2010 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D4613A68FD; Tue, 26 Oct 2010 15:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.409
X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rIXr+ODEijlR; Tue, 26 Oct 2010 15:11:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D5E13A68D2; Tue, 26 Oct 2010 15:11:13 -0700 (PDT)
Received: from [] (port=51620 by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1PArlN-000MIE-18; Tue, 26 Oct 2010 18:13:01 -0400
Message-Id: <>
From: "Richard L. Barnes" <>
To: Peter Saint-Andre <>
In-Reply-To: <>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 26 Oct 2010 18:12:59 -0400
References: <> <> <> <>
X-Mailer: Apple Mail (2.936)
Cc:,, XMPP <>,
Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Oct 2010 22:11:20 -0000

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


>>>> 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.
>> Any thoughts on this issue?
> 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.