[Standards-JIG] stream:error for dialback with no SASL support
jconley at winfessor.com
Mon Jul 26 18:43:44 UTC 2004
> -----Original Message-----
> From: Matthias Wimmer [mailto:m at tthias.net]
> Sent: Saturday, July 24, 2004 11:29 AM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] stream:error for dialback with no SASL
> Hi JD!
> JD Conley schrieb am 2004-07-24 10:53:31:
> > I assume you mean you're implementing STARTTLS for S2S with SASL
> > EXTERNAL, not implementing STARTTLS in dialback.
> SASL will be the next step. First I want to implement STARTTLS only
> therefore "dialback in STARTTLS" (starting TLS before exchanging
> dialback elements).
> The problem with it seems that XMPP is not very clear about using
> dialback and STARTTLS and in which order you should stack these two
> protocols. Maybe the authors even considered noone wants to combine
> these two protocols, but I think they can be useful. Correct me if I
> wrong, but I think SASL can only be used if the two connecting parties
> know each other and have exchanged some authentication tokens.
> on the open public Jabber network I have no clue yet how we could use
> SASL authentication (beside using the ANONYMOUS mechanism or requiring
> all Jabber servers having trusted X.509 certificates.) - but
> STARTTLS is interesting in any case.
We rely on the fact that the X.509 certificates are trusted. We use
EXTERNAL, not ANONYMOUS. The CN on the cert has to match the domain the
incoming connection is claiming it belongs to. The level of trust is
configurable by the server administrator. For example, they can allow
unknown CA's if the cert is explicitly trusted. This works well in the
corporate environment where a group of trading partners can all trust
each other's CA certificates. Obviously you can also configure the
system to trust the "normal" set of internet root CA's.
> > Right now the SoapBox Server sends an invalid-namespace stream
> > in the case where an incoming stream is not one of the configured
> > but I think I like not-authorized better.
> What do you mean by "configured types"?
I mean if the server is configured for DialBack or SASL. If the server
is configured to support only Dialback and an incoming connection does
not specify xmlns:db on the stream, the error will be generated.
> > The biggest pain with implementing SASL for S2S was the fallback
> > mechanism. If your local system supports SASL, for external
> > you have to try SASL first and then drop back to dialback if the
> > system doesn't support SASL. The problem is the different flavors
> > servers will reject you in various ways.
> As I said implementing SASL will be my next step after STARTTLS works.
> thought about the following bussiness logic for SASL/Dialback
I agree that TLS is useful in Dialback, even if it's only used to
protect the stream and not authenticate the endpoints.
> Outgoing connection:
> - send xmlns:db namespace declaration and the XMPP version attribute
> - if I get <stream:features/> containing <starttls/> start the TLS
> connection and start at the beginning again
> - if I get <stream:features/> containing <mechanisms/> check if I am
> configured to do SASL authentication with this server. If yes: Start
> SASL authentication
> - if I am configured to allow Non-SASL-but-Dialback-Connections, send
> <db:result/> and do Dialback processing
> - Send stream error and close connection
This is a little tricky. When you send your opening stream:stream you
will need to specify a version="1.0" so the receiver will send back a
stream:features if it supports any. If the receiver replies with a
version="1.0" then you can assume the stream:features will be following,
otherwise you can assume they will not.
> Incoming connection:
> - Check if xmlns:db is declared and if version attribute is present,
> if both are missing check if we are configured to allow legacy
> 1.0 connections (disabled by default)
> - If the incoming connections had the version attribute with a value
> starting with "1." send stream features. Containing <starttls/> if
> not yet established; and <mechanisms/> if stream not authenticated
> and we are configured to do SASL authentication with the incoming
> - If the other server requests STARTTLS, start the TLS layer and start
> at the beginning again.
> - If the other server starts SASL authentication, process SASL
> - If the other server sends <db:result/>, process the dialback.
> Do you think I will get into problems with this logic?
This logic sounds pretty close. The only issue is that if a server
supports SASL it probably won't use it over dialback (SoapBox doesn't).
So you may never receive an xmlns:db on the incoming stream. And,
technically, a SASL S2S connection can be mutually authenticated through
TLS and SASL EXTERNAL so the incoming and outgoing stream can be on the
same socket. The other major difference between Dialback and SASL is
SASL REQUIRES the use of to/from attributes on the stream. So you
cannot reuse a SASL S2S connection for multiple domains at the same
> > Let me know if you want a server to test with that already has
> > STARTTLS/SASL EXTERNAL implemented for S2S or if you want to chat
> > the implementation.
> Both might be very interesting after I finished the implementation. I
> will contact you the next days.
> Tot kijk
> Fon: +49-(0)70 0770 07770 http://web.amessage.info
> HAM: DB1MW xmpp:mawis at amessage.info
More information about the Standards