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
_______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
