[Standards-JIG] rfc3921bis, <message><service-unavailable/>

Ian Paterson ian.paterson at clientside.co.uk
Sun Oct 22 13:43:28 UTC 2006

The account discovery issue isn't new, but IMHO the new versions of the 
RFCs give us an opportunity to either fix it or accept it once and for all.

It is generally trivial for an attacker to assume/confirm that the 
server supports offline message storage. So, IMHO, the Security 
Considerations section of RFC3921bis is not very credible when it states:

"When a server generates an error stanza in response to receiving a 
stanza for a user who does not exist, the use of the 
<service-unavailable/> error condition helps protect against well-known 
dictionary attacks, since this is the same error condition that is 
returned if, for instance, the namespace of an IQ child element is not 
understood, or if offline message storage or message forwarding is not 
enabled for a domain."

RFC3921bis also states that after failing to deliver a <message/> 
stanza, the server MUST return a <service-unavailable/> stanza error if 
offline storage or message forwarding is not enabled, and SHOULD return 
an error if the account doesn't exist.

IMHO we need to either:
1. Explicitly state in the RFC that it is trivial for an attacker to 
discover the existance of an account, and explicitly and strongly 
discourage implementations without offline storage or message 
forwarding. (Since the "MUST" implies a serious presence leak.)
2. Change the RFC so that the server MUST NOT generate any response to a 
message stanza ever, unless the sender is subscribing to the recipient's 
presence. So when the recipient account does not exist, or when offline 
message storage or message forwarding is not enabled, the server MUST 
silently drop those message stanzas it can't deliver without sending an 
error to the sender. [AMP and XEP-0022 would be affected by this policy.]
3. Allow each implementation to choose either one of the two policies 
above. In which case the RFC could helpfully explain that no grey area 
between the two policies would make sense. i.e. Each implementation can 
either make it impossible to discover the existance of accounts or it 
can allow it. In this case the existing "MUST" and "SHOULD" above would 
need to be "MAY".

- Ian


More information about the Standards mailing list