[Council] disco mods

Peter Saint-Andre stpeter at jabber.org
Fri Dec 2 17:04:22 CST 2005


Ian Paterson wrote:
> Hi Peter,
> 
> This is looking good. However, I'm not quite comfortable with list items
> 2.1 and 2.2 in the Security Considerations section yet:

Yeah, I was getting sleepy when I wrote that text. ;-)

> 1. The JEP doesn't seem to specify anywhere what the server should
> return in the following case:
> - the request did not specify a node
> - there are other items as well as available resources
> - the requesting entity is not authorized to receive presence

The text in the proposed Security Considerations currently stands as 
follows:

******

A server MUST carefully control access to any functionality that would 
enable directory harvesting attacks or (in instant messaging servers) 
that would leak presence information; this functionality consists of the 
server's replies to disco#info and disco#items requests sent to bare 
JIDs (addresses of the form account at domain.tld) hosted on the server, 
since the server responds to such requests on behalf of the account. The 
following rules apply to the handling of service discovery requests sent 
to bare JIDs:

    1. In response to a disco#info request, the server MUST return a 
<service-unavailable/> error if one of the following is true:
       1. The target entity does not exist (no matter if the request 
specifies a node or not).
       2. The requesting entity is not authorized to receive presence 
from the target entity (i.e., via a presence subscription of type "both" 
or "from") or is not otherwise trusted (e.g., another server in a 
trusted network).

    2. In response to a disco#items request, the server MUST return an 
empty result set if:
       1. The target entity does not exist (no matter if the request 
specifies a node or not).
       2. The request did not specify a node, the only items are 
available resources (as defined in RFC 3921), and the requesting entity 
is not authorized to receive presence from the target entity (i.e., via 
a presence subscription of type "both" or "from") or is not otherwise 
trusted (e.g., another server in a trusted network). [15]

[15] However, the server MAY return items other than available resources 
(if any).

******

So to answer your questions:

 > - the request did not specify a node

That's addressed by 1.1, 2.1, and 2.2, no?

 > - there are other items as well as available resources

That's addressed by note 15, no? (Probably belongs in the main text.)

 > - the requesting entity is not authorized to receive presence

That's addressed by 1.2 and 2.2, no?

> 2. That example illustrates a second, more general, issue. If the normal
> response to an 'unauthorized' user would contain items (no matter if the
> request specified a node or not), then the following rule enables
> directory harvesting: "the server MUST return an empty result set if the
> target entity does not exist (no matter if the request specified a node
> or not)".

I don't think it's true that the normal response to an 'unauthorized' 
user would contain items. Why would that be the case? I'd assume that 
the normal IM user has not published items to its bare JID with no node, 
and that the only items returned would be available resources. So if I 
as an unauthorized requestor send a disco#items query to your 
bare-JID-no-node and I receive an empty result-set, how can I 
differentiate between "no available resources" and "entity does not exist"?

I agree that the text could be more clearly written. Perhaps a table of 
some sort would help.

Peter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/council/attachments/20051202/96b54fd8/smime.bin


More information about the Council mailing list