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

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

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.

Peter

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