[NNTP] Re: MODE READER

[Jeffrey M. Vinocur]

On Nov 5, 2004, at 1:23 AM, Mark Crispin wrote:

> Note, however, that TLS protects more than public posting.  It also 
> protects the exchange of authentication credentials.  For better or 
> worse, the overwhelming majority of authentications involve userid and 
> password, transmitted to the server in the clear.  Every NNTP server 
> that has password-based authentication but not mandatory TLS exposes 
> that user's password to every bad guy in the universe.

The overwhelming majority of authentications involve cleartext 
passwords because up until now that's essentially all there was.  I 
expect that SASL will play a substantial role in the future.  And over 
time, I believe NNTP (and hopefully many other protocols) are going to 
subsume their authentication and encryption into SASL, and be able to 
fold all of that into use of a SASL library.  I don't think this is 
naive, but I guess I could be wrong.

Regardless, the mere fact that authentication at present is cleartext 
unless protected by TLS is insufficient justification to distinguish 
STARTTLS as coming strangely before MODE READER.


> Now, you could have AUTHINFO SASL CRAM-MD5 or AUTHINFO SASL GSSAPI or 
> any other SASL authenticator that does not allow an eavesdropping 
> attacker to authenticate as the user, and get away without using TLS.  
> But that still doesn't address session hijacking problems.

Although, a SASL mechanism that establishes a security layer would 
suffice for this.


> Not using AUTHINFO at all, and instead relying upon client IP address 
> validation, doesn't address IP address spoofing.

Although I don't have any data, my impression is that most sites using 
IP addresses for authorization are in control of the entire block of 
IPs in question, the network paths between those IPs and the server, 
and the network paths to the server from the outside world.  Thus I 
expect the level of concern these administrators have for IP spoofing 
is quite low.  Even if such attacks became more common, I'd expect the 
easiest solution to be proper configuration of the involved network 
hardware...


-- 
Jeffrey M. Vinocur
jeff at litech.org