Re: [Standards] XEP-0178 1.1rc3
BTW, I checked over 1.1rc5 and found a few typos and infelicities, so I've checked 1.1rc6 into git: http://xmpp.org/extensions/diff/api/xep/0178/diff/1.1rc5/vs/1.1rc6 That obviously does not document what is currently happening on the wire... Do we need a note stating that the authorization id in the current version contains a spurious newline? Y29uZmVyZW5jZS5leGFtcGxlLm9yZwo= is 'conference.example.org\n' I have not seen this in any implementation, so maybe developers are smart enough to do the right thing.
Re: [Standards] XEP-0178 1.1rc3
On 4/26/11 1:05 AM, Philipp Hancke wrote: BTW, I checked over 1.1rc5 and found a few typos and infelicities, so I've checked 1.1rc6 into git: http://xmpp.org/extensions/diff/api/xep/0178/diff/1.1rc5/vs/1.1rc6 That obviously does not document what is currently happening on the wire... I find that statement puzzling, since in the XMPP Council meeting last week you said: [15:35:07] fippo stpeter: +1 @ 0178 http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110420/#15:35:07 Did you mean +1 is looks fine or +1 we need to discuss that at the next meeting? Do we need a note stating that the authorization id in the current version contains a spurious newline? Y29uZmVyZW5jZS5leGFtcGxlLm9yZwo= is 'conference.example.org\n' I have not seen this in any implementation, so maybe developers are smart enough to do the right thing. I generated that using this command: echo -n 'conference.example.com' | openssl enc -base64 I wasn't aware the command would add an extraneous newline. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
On 4/20/11 9:00 AM, Peter Saint-Andre wrote: On 4/20/11 7:42 AM, Philipp Hancke wrote: I am not sure if backward compability really matters, the last time I checked I offered EXTERNAL to three servers... jabber.org, dave.cridland.net and some host running prosody. Right. Let's get some feedback Dave Cridland and Matthew Wild, at the least. I'm not sure that we have any implementations with which to be backward compatible. :) Please see the latest version, reflecting what I think is the consensus from list discussions: http://xmpp.org/extensions/tmp/xep-0178-1.1.html http://xmpp.org/extensions/diff/api/xep/0178/diff/1.0/vs/1.1rc4 Not related to the diff, but I just spotted this: S2S step 9: no match - close = MAY close or may allow dialback? Ah yes, TLS+Dialback? ;-) Changed in my working copy to: If no match is found, Server2 MAY either close Server1's TCP connection or continue with a Server Dialback [8] negotiation. S2S step 10: I think MUST NOT is too strong. After all, XMPP is deployed using the EXTERNAL mechanism (see the xmppwg charter :-), so we can not change the rules that way. MAY include (for interop reasons) with a note that a future version may remove this (actually I think that EXTERNAL will be deprecated in favor of d-w-d before that happens)? That way we have a clear migration path. OK. Changed in my working copy to: For server-to-server authentication, the auth/ element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of = as shown in RFC 6120). Note #7 is obsolete, that spec is 0238 - which is deprecated so it does not make sense to add a reference. True. And the dialback flows will be in d-w-d anyway, I'd think. Removed. BTW, I checked over 1.1rc5 and found a few typos and infelicities, so I've checked 1.1rc6 into git: http://xmpp.org/extensions/diff/api/xep/0178/diff/1.1rc5/vs/1.1rc6 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
I am not sure if backward compability really matters, the last time I checked I offered EXTERNAL to three servers... jabber.org, dave.cridland.net and some host running prosody. Right. Let's get some feedback Dave Cridland and Matthew Wild, at the least. I'm not sure that we have any implementations with which to be backward compatible. :) Please see the latest version, reflecting what I think is the consensus from list discussions: http://xmpp.org/extensions/tmp/xep-0178-1.1.html http://xmpp.org/extensions/diff/api/xep/0178/diff/1.0/vs/1.1rc4 Not related to the diff, but I just spotted this: S2S step 9: no match - close = MAY close or may allow dialback? S2S step 10: I think MUST NOT is too strong. After all, XMPP is deployed using the EXTERNAL mechanism (see the xmppwg charter :-), so we can not change the rules that way. MAY include (for interop reasons) with a note that a future version may remove this (actually I think that EXTERNAL will be deprecated in favor of d-w-d before that happens)? That way we have a clear migration path. Note #7 is obsolete, that spec is 0238 - which is deprecated so it does not make sense to add a reference.
Re: [Standards] XEP-0178 1.1rc3
On 4/20/11 7:42 AM, Philipp Hancke wrote: I am not sure if backward compability really matters, the last time I checked I offered EXTERNAL to three servers... jabber.org, dave.cridland.net and some host running prosody. Right. Let's get some feedback Dave Cridland and Matthew Wild, at the least. I'm not sure that we have any implementations with which to be backward compatible. :) Please see the latest version, reflecting what I think is the consensus from list discussions: http://xmpp.org/extensions/tmp/xep-0178-1.1.html http://xmpp.org/extensions/diff/api/xep/0178/diff/1.0/vs/1.1rc4 Not related to the diff, but I just spotted this: S2S step 9: no match - close = MAY close or may allow dialback? Ah yes, TLS+Dialback? ;-) Changed in my working copy to: If no match is found, Server2 MAY either close Server1's TCP connection or continue with a Server Dialback [8] negotiation. S2S step 10: I think MUST NOT is too strong. After all, XMPP is deployed using the EXTERNAL mechanism (see the xmppwg charter :-), so we can not change the rules that way. MAY include (for interop reasons) with a note that a future version may remove this (actually I think that EXTERNAL will be deprecated in favor of d-w-d before that happens)? That way we have a clear migration path. OK. Changed in my working copy to: For server-to-server authentication, the auth/ element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of = as shown in RFC 6120). Note #7 is obsolete, that spec is 0238 - which is deprecated so it does not make sense to add a reference. True. And the dialback flows will be in d-w-d anyway, I'd think. Removed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
Peter Saint-Andre wrote: s2s step 10 includes the authorization identity, whereas section 9.2.2. in the RFC includes an empty response. Unless we consider that a bug in the RFC we need some kind of handling for using the stream's from attribute in step 11 when the response is empty. I think it depends. As in XEP-0220, if the sending domain is authorizing as (e.g.) a subdomain such as chat.sender.tld then wouldn't the originating server specify that as an authorization identity? Or do we assume that the Multiple authentications? 'from' will always match the authorization identity, in which case it's That assumption is already there, because the receiving server offers EXTERNAL only if the 'from' is contained in the certificate. never necessary to include the authzid? I suppose the latter approach is simpler... Sure. But that was changed in version 0.0.3 and I don't think we can fix that now nor is there a compelling reason. I have no objections to adding a fallback to the stream's in s2s step 11 if the authorization id is empty. IIRC some servers already do that. philipp
Re: [Standards] XEP-0178 1.1rc3
On 4/14/11 6:11 AM, Philipp Hancke wrote: Peter Saint-Andre wrote: s2s step 10 includes the authorization identity, whereas section 9.2.2. in the RFC includes an empty response. Unless we consider that a bug in the RFC we need some kind of handling for using the stream's from attribute in step 11 when the response is empty. I think it depends. As in XEP-0220, if the sending domain is authorizing as (e.g.) a subdomain such as chat.sender.tld then wouldn't the originating server specify that as an authorization identity? Or do we assume that the Multiple authentications? 'from' will always match the authorization identity, in which case it's That assumption is already there, because the receiving server offers EXTERNAL only if the 'from' is contained in the certificate. You're right. never necessary to include the authzid? I suppose the latter approach is simpler... Sure. But that was changed in version 0.0.3 and I don't think we can fix that now nor is there a compelling reason. No, there is no compelling need -- such flexibility might be desirable someday, but we don't design for someday. I have no objections to adding a fallback to the stream's in s2s step 11 if the authorization id is empty. IIRC some servers already do that. What is the nature of the fallback? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
On 4/14/11 2:22 PM, Philipp Hancke wrote: Peter Saint-Andre wrote: never necessary to include the authzid? I suppose the latter approach is simpler... Sure. But that was changed in version 0.0.3 and I don't think we can fix that now nor is there a compelling reason. No, there is no compelling need -- such flexibility might be desirable someday, but we don't design for someday. We can still be liberal in what we accept and deal with empty authorization ids today. I have no objections to adding a fallback to the stream's in s2s step 11 if the authorization id is empty. IIRC some servers already do that. What is the nature of the fallback? I think it gets obvious if you add a 'from' after stream's :-/ The stream's 'from' attribute is used instead of the (empty) authorization id. Dave? I *think* that this discussion thread leads to the following text in Section 3, but please double-check it. ### [...] 10. Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication the auth/ element MUST NOT include an authorization identity (thus Server1 includes an empty response of = as shown in RFC 6120). auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'=/auth Interoperability Note: Previous versions of this specification relied on the authorization identity being present on the receiving server. Even though this is no longer required, the connecting server should include it for backward compability. 11. Server2 determines if hostname is valid. a. If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 returns success. success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/ Implementation Note: If Server2 needs to assign an authorization identity during SASL negotiation, it SHOULD use the value of the 'from' attribute of the stream header sent by Server1. [...] ### smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
On 4/14/11 3:30 PM, Philipp Hancke wrote: Peter Saint-Andre wrote: [...] I *think* that this discussion thread leads to the following text in Section 3, but please double-check it. ### [...] 10. Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication theauth/ element MUST NOT include an authorization identity (thus Server1 includes an empty response of = as shown in RFC 6120). auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'=/auth Interoperability Note: Previous versions of this specification relied on the authorization identity being present on the receiving server. Even though this is no longer required, the connecting server should include it for backward compability. MUST NOT include but should include for backward compability? Include it always and blame it on me (even though I don't have the old logs from 2006). I am not sure if backward compability really matters, the last time I checked I offered EXTERNAL to three servers... jabber.org, dave.cridland.net and some host running prosody. Right. Let's get some feedback Dave Cridland and Matthew Wild, at the least. I'm not sure that we have any implementations with which to be backward compatible. :) 11. Server2 determines if hostname is valid. a. If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 returns success. success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/ Implementation Note: If Server2 needs to assign an authorization identity during SASL negotiation, it SHOULD use the value of the 'from' attribute of the stream header sent by Server1. +1 Thanks for the review. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
On 4/12/11 1:16 PM, Philipp Hancke wrote: Peter Saint-Andre wrote: FYI, I've finally updated the provisional version of XEP-0178, based on list discussion from last October as well as the final versions of both RFC 6120 and RFC 6125. http://xmpp.org/extensions/tmp/xep-0178-1.1.html http://xmpp.org/extensions/diff/api/xep/0178/diff/1.1rc1/vs/1.1rc3 (Not sure whether I ever checked in rc2, but I thought it was safer to move from rc1 to rc3.) Feedback is welcome as always. s2s step 10 includes the authorization identity, whereas section 9.2.2. in the RFC includes an empty response. Unless we consider that a bug in the RFC we need some kind of handling for using the stream's from attribute in step 11 when the response is empty. I think it depends. As in XEP-0220, if the sending domain is authorizing as (e.g.) a subdomain such as chat.sender.tld then wouldn't the originating server specify that as an authorization identity? Or do we assume that the 'from' will always match the authorization identity, in which case it's never necessary to include the authzid? I suppose the latter approach is simpler... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
Peter Saint-Andre wrote: FYI, I've finally updated the provisional version of XEP-0178, based on list discussion from last October as well as the final versions of both RFC 6120 and RFC 6125. http://xmpp.org/extensions/tmp/xep-0178-1.1.html http://xmpp.org/extensions/diff/api/xep/0178/diff/1.1rc1/vs/1.1rc3 (Not sure whether I ever checked in rc2, but I thought it was safer to move from rc1 to rc3.) Feedback is welcome as always. s2s step 10 includes the authorization identity, whereas section 9.2.2. in the RFC includes an empty response. Unless we consider that a bug in the RFC we need some kind of handling for using the stream's from attribute in step 11 when the response is empty. philipp
