Re: [Standards] Need help with problems regarding XEP-0114.
Hi Peter, > Trying this on the server I use (OpenFire), messages (and IQ stanzas) > sent to bare JIDs are not forwarded to the corresponding client. > Should it? iq stanzas are never forwarded. Message stanzas are only forwarded to "available resources", i.e. resources that that sent initial presence. Sending two messages from the component: C: Normal messagehej C: Normal messagehej However, on the client side, only one message is received, the one with the resource. Furthermore, no error message is returned: Have you checked offline storage? S: Normal messagehej Which XMPP server do you use, where this works? Is it possible for me to try to connect to a component to that server and see if it works differently then OpenFire? Searching RFC 6120, I cannot see if sending messages and IQ stanzas to bare JIDs is actually allowed or not. What I find in RFC 6120 is that "responding differently" to requests sent to bare JIDs and full JIDs allows for directory harvesting, which is considered bad. I interpret this as a recommendation to disallow (and not respond) to messages/requests sent to bare JIDs, since it's the only way to avoid responding differently ... Both is allowed and useful. Note that sending iq to the bare jid is typically only useful for things like requesting the vcard. Does anybody has some light to shed on this? Regarding presence subscriptions, is your component doing any roster handling? It has to send a subscription request to the user, and receive the user's subscription acceptance, optionally storing this information (as the component's roster), after which it can probe the user (assuming the user accepted). The XMPP server does not manage rosters or subscriptions for XEP-0114 components. It only does so for users. The server mainly handles XMPP Core (RFC 6120) for components, while everything in XMPP IM (RFC 6121) is up to the components themselves. I do send a presence stanza with a presence subscription request, in case the probe fails. Regarding roster: Since the roster is handled (or simulated) by the component, in what way other than sending a presence subscription stanza, should the component perform roster handling with the server? I thought roster handling was between client and its server, but not between servers or between component and server. Well, your component ought to manage it's subscriptions, but trying to send a probe and then dealing with an error might be a good-enough approach. Note that sending probes and getting errors back might not work like this on all implementations. You might get unsubscribed instead, regardless of whether the account exists (re directory harvesting) What I do is: A corresponding presence is not received by the client. What case of roster handling is supposed to happen before? Have you sent presence and requested the roster on the client? Roster pushes (i.e. what happens on the server after receiving a presence type=subscribe) are only sent to "interested resources".
[Standards] Fwd: [xmpp] WGLC of draft-ietf-xmpp-websocket-02
FYI. Please review and send feedback to the x...@ietf.org list. Thanks! Peter Original Message Subject: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 Date: Mon, 7 Apr 2014 16:29:56 -0500 From: Ben Campbell To: XMPP Working Group CC: draft-ietf-xmpp-websocket@tools.ietf.org This is a Working Group Last Call of draft-ietf-xmpp-websocket-02. The draft is available at the following URL: http://tools.ietf.org/html/draft-ietf-xmpp-websocket-02 The WGLC will conclude on 21 April, 2014. Please send your comments to the authors and the XMPP mailing list. Thanks! Ben. ___ xmpp mailing list x...@ietf.org https://www.ietf.org/mailman/listinfo/xmpp
Re: [Standards] Need help with problems regarding XEP-0114.
Hello Waqas & community. Thanks a lot for taking your time to help. See my comments to each one of your responses. It seems they do not work. Your component can send messages to the bare JID of the user, which would then be sent to the resources with highest priority (depending on server config, etc). That's the normal way to initiate a conversation with a bare JID when you don't have a full JID available. Trying this on the server I use (OpenFire), messages (and IQ stanzas) sent to bare JIDs are not forwarded to the corresponding client. Should it? Sending two messages from the component: C: Normal messagehej C: Normal messagehej However, on the client side, only one message is received, the one with the resource. Furthermore, no error message is returned: S: Normal messagehej Which XMPP server do you use, where this works? Is it possible for me to try to connect to a component to that server and see if it works differently then OpenFire? Searching RFC 6120, I cannot see if sending messages and IQ stanzas to bare JIDs is actually allowed or not. What I find in RFC 6120 is that "responding differently" to requests sent to bare JIDs and full JIDs allows for directory harvesting, which is considered bad. I interpret this as a recommendation to disallow (and not respond) to messages/requests sent to bare JIDs, since it's the only way to avoid responding differently ... Does anybody has some light to shed on this? Regarding presence subscriptions, is your component doing any roster handling? It has to send a subscription request to the user, and receive the user's subscription acceptance, optionally storing this information (as the component's roster), after which it can probe the user (assuming the user accepted). The XMPP server does not manage rosters or subscriptions for XEP-0114 components. It only does so for users. The server mainly handles XMPP Core (RFC 6120) for components, while everything in XMPP IM (RFC 6121) is up to the components themselves. I do send a presence stanza with a presence subscription request, in case the probe fails. Regarding roster: Since the roster is handled (or simulated) by the component, in what way other than sending a presence subscription stanza, should the component perform roster handling with the server? I thought roster handling was between client and its server, but not between servers or between component and server. What I do is: A corresponding presence is not received by the client. What case of roster handling is supposed to happen before? What happens between servers when I add a contact to an account on server 1? Does roster requests between client and server1 get propagated to server 2 also? Is this not handled by the presence stanza? Furthermore, I find in ยง3.1.1 in RFC 6121 the following statement: Implementation Note: Many XMPP clients prompt the user for information about the potential contact (e.g., "handle" and desired roster group) when generating an outbound presence subscription request and therefore send a roster set before sending the outbound presence subscription request. This behavior is OPTIONAL, because a client MAY instead wait until receiving the initial roster push from the server before uploading user-provided information about the contact. A server MUST process a roster set and outbound presence subscription request in either order (i.e., in whatever order generated by the client). Does that not mean that roster handling is optional before sending a presence subscription (and therefore must not affect if a presence subscription is delivered or not)? But I cannot see how this roster handling should be applied anyway, in the component case, since it seems to be a client-to-server protocol. Have I misunderstood? Best regards, Peter Waher
[Standards] UPDATED: XEP-0323 (Internet of Things - Sensor Data)
Version 0.3 of XEP-0323 (Internet of Things - Sensor Data) has been released. Abstract: This specification provides the common framework for sensor data interchange over XMPP networks. Changelog: [See revision history] (pw) Diff: http://xmpp.org/extensions/diff/api/xep/0323/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0323.html
[Standards] UPDATED: XEP-0325 (Internet of Things - Control)
Version 0.3 of XEP-0325 (Internet of Things - Control) has been released. Abstract: This specification describes how to control devices or actuators in an XMPP-based sensor network. Changelog: [See revision history] (pw) Diff: http://xmpp.org/extensions/diff/api/xep/0325/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0325.html
[Standards] Proposed XMPP Extension: Form Discovery and Publishing
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Form Discovery and Publishing Abstract: This specification describes a series of conventions that allow the management of form templates and publishing of completed forms. URL: http://xmpp.org/extensions/inbox/fdp.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] Need help with problems regarding XEP-0114.
On Mon, Apr 7, 2014 at 1:30 PM, Peter Waher wrote: > Hello > > > > I've now examined the possibility to use Jabber Components (XEP-0114) for > IoT Discovery and Provisioning, but have some problems. Since it's very > hard to find documentation on this XEP, and searching the internet for > solutions only returns pages with people having the same problems (but no > solutions), I'm turning to the XSF community to see if somebody has any > good input. > > > > First, I can mention that I can send and receive messages and iq stanzas > to and from normal JIDs and a component, as long as I have the resource of > the corresponding JID I want to communicate with. This is no problem, if > the client itself initiates communication. But what if the server component > needs to initiate communication? How does the server component obtain the > resource(s) of a corresponding bare JID? > > > > I've tried a presence probe. That only returns a not-authorized response. > The reason being that otherwise, it would be a security problem, if the > component was able to probe the presence of a JID, without being a friend. > (However, sending messages and iq stanzas to the JID, if you had the > resource, was OK, even without friendship.) > > > > The next thing I tried was to send a presence subscription to the JID from > the component. This request was not received by the client, regardless if I > tried with sending it from the component itself, or a virtual JID simulated > by the component. Searching the internet, this was the response I was > given: You needed to simulate accounts behind the component (using the same > component domain name). > > > > Is there a step that needs to be taken before sending the presence > subscription, for it to be routed correctly to the device? > > > > Or is presence subscriptions somehow disabled in server components? > > > > Or might this behave differently on different XMPP servers? (I'm using an > OpenFire XMPP server to test my implementation.) > > > > Example of communication that goes well. Here the component, given the > full JID of a client, is able to perform an IQ get & receive a response: > > > > C: type='get' id='1'>http://jabber.org/protocol/disco#info > "/> > > S: type="result" id="1"> xmlns="http://jabber.org/protocol/disco#info";> category="client" type="pc" name="Clayster"/>http://jabber.org/protocol/disco#info"/>http://jabber.org/protocol/disco#items"/> var="jabber:iq:roster"/> var="vcard-temp"/> > > > > While, on the client side, it looks as follows: > > > > S: type="get" id="1">http://jabber.org/protocol/disco#info > "/> > > C: type='result' id='1'> xmlns="http://jabber.org/protocol/disco#info";> category="client" type="pc" name="Clayster"/>http://jabber.org/protocol/disco#info"/>http://jabber.org/protocol/disco#items"/> var="jabber:iq:roster"/> var="vcard-temp"/> > > > > > > This is how the failed attempt looks like, where the component itself > makes a presence probe to retrieve the resource of a bare JID. When it > fails it tries to request a subscription on presence. > > > > C: to="unitt...@clayster.cl" type="probe"/> > > S: from="unitt...@clayster.cl"> code="401" type="auth"> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> > > C: to="unitt...@clayster.cl" type="subscribe"/> > > > > Nothing is received on the client side. I try the same thing, but with a > simulated account behind the component domain: > > > > C: > > S: xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> > > C: > > > > Nothing is received by the client. > > > > Hopefully, somebody with more insight can answer the above questions, or > give other insights on how to proceed. If I can initiate communication from > a server component, it would be a very good option to use in the IoT > Discovery XEP proposal and the Provisioning XEP. > > > > Best regards, > > Peter Waher > > > Your component can send messages to the bare JID of the user, which would then be sent to the resources with highest priority (depending on server config, etc). That's the normal way to initiate a conversation with a bare JID when you don't have a full JID available. Regarding presence subscriptions, is your component doing any roster handling? It has to send a subscription request to the user, and receive the user's subscription acceptance, optionally storing this information (as the component's roster), after which it can probe the user (assuming the user accepted). The XMPP server does not manage rosters or subscriptions for XEP-0114 components. It only does so for users. The server mainly handles XMPP Core (RFC 6120) for components, while everything in XMPP IM (RFC 6121) is up to the components themselves. Prosody plug: I've switched to writing components as Prosody plugins, so I can reuse a lot of Prosody's c2s machinery, and I wrote mod_component_client to then allow Prosody to act as a XEP-0114 component to other servers. -- Waqas Hussain
Re: [Standards] [editor] Updated protoXEP: IoT Discovery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 3/31/14, 4:16 PM, Peter Waher wrote: > > Hello > > > > I?ve attached the a revised version of the IoT Discovery proposal, where I?ve addressed any input I?ve received on the subject. > > > > Best regards, > > Peter Waher > > > > Apologies for the delay. I'll get this applied presently. - -- - - m&m Matthew A. Miller < http://goo.gl/LK55L > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTQv4eAAoJEOz0ck4QngW7SPQIALe9RNU1vxaj7d5+jrC6LRIo SfhgifHBgMRA029MkN1sXz8jDZF7hPst41mHneh/8VUISC7RIa4ih3jiipNnL+V0 UCKowIJ/g4eMuiFsMzEvqE0PRhdR+4M1HCQwz4Ns/pqGgHDpdSRBLWTdyOJTf9wf JT71IYuCcGHuaFbQOlHRML9vAOfMlePFLcvVeBAQ2ZvpnHbOuGVGFNisIT1eUXV4 C0izphjmi3DalITNIUwLQgUE6/V6sFYRLpCO0Yswq0JYeB+7S8q2mCLPJUfdk7Qr nQSEQDGqg1tjLkqWz4+ERfwd6QNrp5VWe76/G6rQ44oEm5tcgE8JxhFzhMvM3po= =y+iC -END PGP SIGNATURE-
[Standards] Need help with problems regarding XEP-0114.
Hello I've now examined the possibility to use Jabber Components (XEP-0114) for IoT Discovery and Provisioning, but have some problems. Since it's very hard to find documentation on this XEP, and searching the internet for solutions only returns pages with people having the same problems (but no solutions), I'm turning to the XSF community to see if somebody has any good input. First, I can mention that I can send and receive messages and iq stanzas to and from normal JIDs and a component, as long as I have the resource of the corresponding JID I want to communicate with. This is no problem, if the client itself initiates communication. But what if the server component needs to initiate communication? How does the server component obtain the resource(s) of a corresponding bare JID? I've tried a presence probe. That only returns a not-authorized response. The reason being that otherwise, it would be a security problem, if the component was able to probe the presence of a JID, without being a friend. (However, sending messages and iq stanzas to the JID, if you had the resource, was OK, even without friendship.) The next thing I tried was to send a presence subscription to the JID from the component. This request was not received by the client, regardless if I tried with sending it from the component itself, or a virtual JID simulated by the component. Searching the internet, this was the response I was given: You needed to simulate accounts behind the component (using the same component domain name). Is there a step that needs to be taken before sending the presence subscription, for it to be routed correctly to the device? Or is presence subscriptions somehow disabled in server components? Or might this behave differently on different XMPP servers? (I'm using an OpenFire XMPP server to test my implementation.) Example of communication that goes well. Here the component, given the full JID of a client, is able to perform an IQ get & receive a response: C: http://jabber.org/protocol/disco#info"/> S: http://jabber.org/protocol/disco#info";>http://jabber.org/protocol/disco#info"/>http://jabber.org/protocol/disco#items"/> While, on the client side, it looks as follows: S: http://jabber.org/protocol/disco#info"/> C: http://jabber.org/protocol/disco#info";>http://jabber.org/protocol/disco#info"/>http://jabber.org/protocol/disco#items"/> This is how the failed attempt looks like, where the component itself makes a presence probe to retrieve the resource of a bare JID. When it fails it tries to request a subscription on presence. C: S: C: Nothing is received on the client side. I try the same thing, but with a simulated account behind the component domain: C: S: C: Nothing is received by the client. Hopefully, somebody with more insight can answer the above questions, or give other insights on how to proceed. If I can initiate communication from a server component, it would be a very good option to use in the IoT Discovery XEP proposal and the Provisioning XEP. Best regards, Peter Waher
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
On 7 April 2014 10:04, Philipp Hancke wrote: > The alternative is we just say "Components are privately-authenticated S2S >> connections", and invoke BiDi and SASL auth and make it happen. This is >> functionally equivalent, but differs in that components are no longer >> special in any way (aside from near-mandatory support for XEP-0288), >> aren't >> backwards compatible with the older protocol, which becomes obsolete. That >> appeals to my sense of purity, and is likely significantly more secure in >> a >> number of ways. (At the very least, the security profile would be better >> understood). >> > > Well, I think the primary differences are that > a) components will appear in disco#items > I think that's orthogonal, actually - you could list ancilliary services hosted on "full" S2S via disco#items as well. For example, a site might choose to host their FT proxy or media relay on entirely different hosting to their IM services. So I suspect that while components are *often* listed, they're not always. Besides which, my proposal isn't that components wouldn't need provisioning of their own - it's just a protocol change, not a deployment one. > b) a server won't attempt to connect to a component > > That's not strictly true either, but again, I think you'd provision components nonetheless - this is purely unifying the protocol. They'd need to be provisioned, possibly given a password, and so on. There's an implication here that a component *could* be connected to, as well, but you'd obviously need to manually specify the endpoint in the server's configuration. However, by "moving on" from XEP-0114, we'd be able to reduce the attack surface - it'd be no different to C2S/S2S from a security standpoint (though possibly with additional considerations given "trusted" components and allowed spoofing, etc). Dave.
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
The alternative is we just say "Components are privately-authenticated S2S connections", and invoke BiDi and SASL auth and make it happen. This is functionally equivalent, but differs in that components are no longer special in any way (aside from near-mandatory support for XEP-0288), aren't backwards compatible with the older protocol, which becomes obsolete. That appeals to my sense of purity, and is likely significantly more secure in a number of ways. (At the very least, the security profile would be better understood). Well, I think the primary differences are that a) components will appear in disco#items b) a server won't attempt to connect to a component
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
On 7 April 2014 08:27, Steffen Larsen wrote: > I completely agree about making XEP-0114 (external components) more > suitable and secure like any other S2S scenario. Lifting it to a XMPP > version 1.0 stage would be great, but would also break a lot of > implementations. > I'm not entirely sure. I've seen *some* implementations break when they receive stream features they weren't expecting, but most existing implementations don't send the version attribute, so won't get them. So it'll break *some* implementations, and an implementation *might* want to offer component support on ports that suppress all features as a result. How widespread the problem would be is, I think, an unknown at this point. The alternative is we just say "Components are privately-authenticated S2S connections", and invoke BiDi and SASL auth and make it happen. This is functionally equivalent, but differs in that components are no longer special in any way (aside from near-mandatory support for XEP-0288), aren't backwards compatible with the older protocol, which becomes obsolete. That appeals to my sense of purity, and is likely significantly more secure in a number of ways. (At the very least, the security profile would be better understood). Dave.
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hi Peter, On 03 Apr 2014, at 14:03, Peter Waher wrote: > Hello Edwin & Co. > >> You seem to confuse Historical with Deprecated. Although the XEP is >> historical, the status is active. Furthermore, all servers I have used so >> far support XEP-0114: this is a core feature of most implementations. > > Actually, I do not. I am aware of the difference. What historical tells me, > apart from it being historical, i.e. part of the Jabber project before being > formalized, is that it: > > * Is not sufficiently important to have been lifted and issues discussed and > fixed, to become draft or final (or RFC). > * Any changes to it are not guaranteed to be backwards compatible. > * It's future is unclear, which is also stated in the XEP. > * It's use and implementation variants are unclear. > * Security aspects are unclear. > * It is not recommended by XSF or xmpp.org anywhere. > > After having investigated XEP-0114 now in some more detail, there are various > aspects which concerns me. Since Jabber components seems to be a third way to > connect to an XMPP server (the other two being c2s and s2s), and a very > useful one at that I must agree, I think the XSF should take some time and > effort in formalizing this XEP a bit, and fixing some of its flaws. I'm told > that it uses an old version of XMPP (0.9), and I wonder if it is not in > everybody's interest to lift it to v1.0, and allow things such as starttls, > etc. to make it more secure. Today, there is no way for the client > (component) to validate that the server is who it pretends to be, which makes > MITM attacks quite easy. And since you get such a direct access to the > server, it looks very much like a backdoor to me. I completely agree about making XEP-0114 (external components) more suitable and secure like any other S2S scenario. Lifting it to a XMPP version 1.0 stage would be great, but would also break a lot of implementations. > > Best regards, > Peter Waher -Cheers /Steffen smime.p7s Description: S/MIME cryptographic signature
