ietf-nntp Re: WG Review: Simple Authentication and Security Layer (sasl)

[Andrew Gierth]

>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:

 Ken> Unless I don't fully understand your problem, I don't see what
 Ken> this has to do with SASL.

not to do with SASL as a framework, but with all the SASL schemes which
I have reviewed (with the obvious exception of PLAIN), including those
which have been suggested for "servers and clients MUST support ...".

But it's clear you don't understand the problem, so I will give a
detailed example.

suppose user at example.com, whose password is 'foo123', connects to the
server. At present, what happens is:

client sends AUTHINFO USER user at example.com
server remembers username, responds with 381
client sends AUTHINFO PASS foo123

at this point, the server consults its configuration to find the
authentication method for 'example.com'; for example, this may specify
a RADIUS server address and secret. The server then makes a RADIUS
query, which it can easily do because it has both the username and
password in hand. Note that the server does _not_ itself store _any_
info about valid users in 'example.com', especially not their
passwords.

This obviously isn't possible using mechanisms like DIGEST-MD5,
CRAM-MD5 or SRP, because all of those are based around the client
_proving knowledge of the password_ rather than actually _sending_ the
password. If the server does not have access to stored passwords, but
only has access to a separate authentication mechanism that uses a
_different_ protocol, then there is no way for the server to provide
any of these methods.

-- 
Andrew.