Last Call Review of draft-ietf-xmpp-address-

Request Review of draft-ietf-xmpp-address
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-10-21
Requested 2010-10-07
Authors Peter Saint-Andre
Draft last updated 2010-10-29
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes 
State Completed
Review review-ietf-xmpp-address-secdir-lc-barnes-2010-10-29
Review completed: 2010-10-29


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.


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.


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.