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

["Richard L. Barnes" <[e-mail]>]

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

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

--Richard