[Standards-JIG] stream:error for dialback with no SASL support

Matthias Wimmer m at tthias.net
Sat Jul 24 18:29:13 UTC 2004

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 and
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 am
wrong, but I think SASL can only be used if the two connecting parties
know each other and have exchanged some authentication tokens. Therefore
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.

> Right now the SoapBox Server sends an invalid-namespace stream exception
> in the case where an incoming stream is not one of the configured types,
> but I think I like not-authorized better.

What do you mean by "configured types"?

> The biggest pain with implementing SASL for S2S was the fallback
> mechanism.  If your local system supports SASL, for external connections
> you have to try SASL first and then drop back to dialback if the remote
> system doesn't support SASL.  The problem is the different flavors of
> servers will reject you in various ways.

As I said implementing SASL will be my next step after STARTTLS works. I
thought about the following bussiness logic for SASL/Dialback selection:

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

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 jabberd
  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 TLS
  not yet established; and <mechanisms/> if stream not authenticated yet
  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?

> 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 about
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20040724/8cb02fc7/attachment.sig>

More information about the Standards mailing list