[jdev] Re: s2s doubts
Stephen Marquard
scm at marquard.net
Wed May 18 14:16:34 CDT 2005
Peter Saint-Andre wrote:
> On Wed, May 18, 2005 at 11:18:58AM -0700, Justin Karneges wrote:
>
>>On Wednesday 18 May 2005 09:42 am, Stephen Marquard wrote:
>>
>>>Justin Karneges wrote:
>>>
>>>>If this was meant to be possible, it certainly isn't clear in RFC 3920.
>>>>Is this an extension documented somewhere?
>>>
>>>You do TLS as documented for streams (if advertised as a stream
>>>feature), and then dialback as documented. TLS doesn't add much
>>>additional complexity - the only subtlety is to wait for TLS to complete
>>>once it's started before sending any dialback packets.
>>
>>The spec does not discuss dialback with TLS, or even <stream:features> for
>>that matter. My problem with what you describe is that it would probably
>>cause breakage between jabberd and my own server implementation which was
>>created according to the spec. Please don't make stuff up. If we really
>>want dialback + TLS, this _needs_ to be documented in the RFC.
>
> I fail to see what anyone is making up here. TLS is documented in
> Section 5 of RFC 3920. Server dialback is documented in Section 8
> of RFC 3920. Stream features are documented in Section 4.6 of RFC
> 3920. Nowhere in RFC 3920 is it set forth that two servers MUST
> NOT or SHOULD NOT complete dialback if they have completed TLS
> (although RFC 3920 does say that two servers SHOULD NOT complete
> dialback if they have completed SASL). If you are suggesting that
> rfc3920bis be changed to so specify the relationship between TLS
> and dialback, that is one thing. But the spec as written does not
> forbid this behavior in any way.
TLS + Dialback (as implemented in j1 and j2) would seem to violate these
rules in XMPP 5.1:
7. The initiating entity MUST validate the certificate presented by the
receiving entity; see Certificate ValidationCertificate Validation
regarding certificate validation procedures.
12. If the TLS negotiation is successful, the initiating entity MUST
continue with SASL negotiation.
So in this regard, j1 & j2 are not XMPP-compliant. But then as they're
already not XMPP compliant by not implementing SASL, this is nothing new.
Regards
Stephen
More information about the JDev
mailing list