[Jabber-IETF] SASL issues
1 at 234.cx
Fri Oct 11 06:22:28 CDT 2002
Marshall Rose wrote:
> not true. the "sl" in "sasl" refers to "security layer" which is the
> term that sasl uses to refer to message integrity and privacy.
Ah, interesting, I didn't know that. So if I wanted to use Kerberos, I
would negotiate the GSS-API SASL mechanism, and the Kerberos-V GSS-API
mechanism, is that right?
If this is the case, we need to make sure that encryption is switched on
at exactly the right point. For example, suppose the sasl negotiation
was going on like this:
After this the server responds with <sasl:success>. Now, ordinarily the
client could send white space characters between the last sasl:response
and whatever tag is coming next. Unfortunately in this particular case,
white space becomes significant. The server and client must both start
encrypting the stream at the same point, or they will get out of step.
Does this make sense, or am I still misunderstanding SASL? If I'm not,
I suggest that the encryption should begin immediately after the ">" at
the end of the last sasl:response. The client is therefore permitted to
send white space between responses, but before doing so it must wait to
make sure that the server is not about to turn on encryption. If it is,
it must encrypt the white space, if it still wishes to send it.
On a slightly different note, the proposed starttls system would close
the stream and re-open it once encryption has started. Is there a
particular reason for doing this? If not, I wonder if it might be
sensible to make it work the same was as SASL. Otherwise you would have
the situation where you negotiate Kerberos and don't re-open the stream,
but you negotiate TLS and you do. It wouldn't matter hugely, but IMO it
is not too elegant. (This would get even stranger if someone ever
defined a TLS SASL mechanism.)
More information about the xmppwg