Re: from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]

[Michael Jakl <ja...@gmail.com>]

Hi!

On Sun, Jul 5, 2009 at 00:34, Bernd Fondermann<bf...@brainlounge.de> wrote:
> Bernd Fondermann wrote:
> After a quick(!) review, I found that the /client/ is required to send a
> 'from' address /only/ if it has bound more than one resource at the same
> time (rare).
> In all other cases, the from is available in the handler via
> SessionContext.getInitiatingEntity(). So it is not necessary to enrich
> the stanza while it is still in the handler.
>
> Now, where do you expect the server to add the from, when it currently
> doesn't?

I was thinking that a "from" attribute should be present because all
examples in the XEP0060 include one. Additionally this error condition
explicitely notes it:

XEP0060 6.1.3.1:
http://xmpp.org/extensions/tmp/xep-0060-1.13.html#subscriber-subscribe-error-nomatch
If the specified JID is a bare JID or full JID, the service MUST at a
minimum check the bare JID portion against the bare JID portion of the
'from' attribute on the received IQ request to make sure that the
requesting entity has the same identity as the JID which is being
requested to be added to the subscriber list.

Second, the RFC3929 9.1.2 says this:
When a server receives an XML stanza within the context of an
authenticated stream qualified by the 'jabber:client' namespace, it
MUST do one of the following:

   1. validate that the value of the 'from' attribute provided by the
client is that of a connected resource for the associated entity
   2. add a 'from' address to the stanza whose value is the bare JID
(<no...@domain>) or the full JID (<node@domain/resource>) determined by
the server for the connected resource that generated the stanza (see
Determination of Addresses (Determination of Addresses))

I think it would be easier to just add the "from" attribute to the
stanza than have each component that requires it check wether one is
included, if not, take the one from the SessionContext.

I'd add the from attribute in XMPPCoreStanzaHandler#execute. There we
already deal with 9.1.1 of the RFC (veryfying proper "to" attribute).

Another way to get this in, in a general way, is to extend
Stanza#getFrom, but this isn't the right place to do this IMHO.

What do you think about it?

Michael

Re: from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]

[Michael Jakl <ja...@gmail.com>]

Hi!

On Sun, Jul 5, 2009 at 14:50, Bernd
Fondermann<be...@googlemail.com> wrote:
> On Sun, Jul 5, 2009 at 12:21, Michael Jakl<ja...@gmail.com> wrote:
>> Second, the RFC3929 9.1.2 says this:
>> When a server receives an XML stanza within the context of an
>> authenticated stream qualified by the 'jabber:client' namespace, it
>> MUST do one of the following:
>>
>>   1. validate that the value of the 'from' attribute provided by the
>> client is that of a connected resource for the associated entity
>>   2. add a 'from' address to the stanza whose value is the bare JID
>> (<no...@domain>) or the full JID (<node@domain/resource>) determined by
>> the server for the connected resource that generated the stanza (see
>> Determination of Addresses (Determination of Addresses))
>
> We do (1.), so we are fine. Some stanzas come without from addresses,
> the most prominent probably being availability presence.

I've read it like this: IF there is an "from", THEN (1.), ELSE (2.). But the
Do EITHER (1.) OR (2.) is also a valid interpretation I haven't seen.

>> I think it would be easier to just add the "from" attribute to the
>> stanza than have each component that requires it check wether one is
>> included, if not, take the one from the SessionContext.
>
> I think we should write a utility method which provides this info.

I've done that for my PubSub module now.

Thanks for the clarifications,
Michael

Re: from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]

[Bernd Fondermann <be...@googlemail.com>]

On Sun, Jul 5, 2009 at 12:21, Michael Jakl<ja...@gmail.com> wrote:
> Hi!
>
> On Sun, Jul 5, 2009 at 00:34, Bernd Fondermann<bf...@brainlounge.de> wrote:
>> Bernd Fondermann wrote:
>> After a quick(!) review, I found that the /client/ is required to send a
>> 'from' address /only/ if it has bound more than one resource at the same
>> time (rare).
>> In all other cases, the from is available in the handler via
>> SessionContext.getInitiatingEntity(). So it is not necessary to enrich
>> the stanza while it is still in the handler.
>>
>> Now, where do you expect the server to add the from, when it currently
>> doesn't?
>
> I was thinking that a "from" attribute should be present because all
> examples in the XEP0060 include one.

Examples are not normative. Don't be fooled by illustrations ;-)
It's good that all examples have 'from's, this makes the spec easier
to comprehend.

> Additionally this error condition
> explicitely notes it:
>
> XEP0060 6.1.3.1:
> http://xmpp.org/extensions/tmp/xep-0060-1.13.html#subscriber-subscribe-error-nomatch
> If the specified JID is a bare JID or full JID, the service MUST at a
> minimum check the bare JID portion against the bare JID portion of the
> 'from' attribute on the received IQ request to make sure that the
> requesting entity has the same identity as the JID which is being
> requested to be added to the subscriber list.

I think this is to prevent subscribing evil@vysper.org to a node which
should only accessible for angel@vysper.org by means of a fake 'from'
address (spoofing attack). If the from is not there, the server knows
who's it.

> Second, the RFC3929 9.1.2 says this:
> When a server receives an XML stanza within the context of an
> authenticated stream qualified by the 'jabber:client' namespace, it
> MUST do one of the following:
>
>   1. validate that the value of the 'from' attribute provided by the
> client is that of a connected resource for the associated entity
>   2. add a 'from' address to the stanza whose value is the bare JID
> (<no...@domain>) or the full JID (<node@domain/resource>) determined by
> the server for the connected resource that generated the stanza (see
> Determination of Addresses (Determination of Addresses))

We do (1.), so we are fine. Some stanzas come without from addresses,
the most prominent probably being availability presence.

> I think it would be easier to just add the "from" attribute to the
> stanza than have each component that requires it check wether one is
> included, if not, take the one from the SessionContext.

I think we should write a utility method which provides this info.

> I'd add the from attribute in XMPPCoreStanzaHandler#execute. There we
> already deal with 9.1.1 of the RFC (veryfying proper "to" attribute).
>
> Another way to get this in, in a general way, is to extend
> Stanza#getFrom, but this isn't the right place to do this IMHO.

The 'from' attribute is meaningless in an authenticated stream (see
exception below!), because the server knows who he is dealing with
already.
At this stage, the from should be ignored in most cases, because it
only leads to double-checks, spoofing attacks and errors.

There is one exception: If more than one resource is bound in the same
session (rare!), then you need to differentiate at times.

Now, if you really need the 'from', because you need to decide between
subscribing a bare or full jid, well, use it.

(It took me a few months to comprehend this, BTW.)

  Bernd