[Standards-JIG] JEP-0170: dialback + TLS + SASL

Philipp Hancke fippo at goodadvice.pages.de
Wed Jan 18 12:20:00 UTC 2006


Peter Saint-Andre typeth:
> JEP-0170 is, so far, silent on the order of TLS, SASL, and dialback for 
> server-to-server communications. RFC 3920 basically says "dialback is a 
> legacy protocol, use TLS then SASL" but I wonder if the following order 
> makes sense:
> 
> 1. Dialback
> 2. TLS
*nitpick*
Section 5.1 rules 9&10 say you must discard any knowledge obtained
before TLS.
Hence there is no information gain from dialback.

> 3. SASL
Using what mechanism?

If you want to use dialback+EXTERNAL, the order would have to be
1. Dialback
2. SASL (EXTERNAL)
3. TLS
This can not be mistaken as SASL EXTERNAL using x509 certificates
and wont break current implementations thereof (unless they're buggy).
The problem is that there is no way to renegotiate features after
having done dialback and hence EXTERNAL must be offered before dialback,
when it's not clear if dialback will be successful and EXTERNAL
can be used.


Yet another approach might be to use dialback once to negotiate a
shared secret which can subsequently be used for SASL DIGEST-MD5...
Of course this would not result in a authentication any stronger than
dialback and only increases complexity.


If you really want to follow the order defined in the RFC,
you could in theory do something like
1. TLS
2. SASL EXTERNAL modified to carry dialback keys in <auth/>
                 (interpreting <auth/> as dialback step 4)
but that requires a ambiguous usage of EXTERNAL,
some tweaks to dialback (using <success/> in step 10)
and is quite weird.

 > For now I'm speaking practically -- I'm not talking about what will be
 > acceptable in rfc3920bis, just what works on the network. We'll deal
 > with the IETF implications later. :-)
starttls+dialback is widely on the network for months now...
You're probably to late to stop the juggernaut :-)

cheers

Philipp



More information about the Standards mailing list