[ietf-nntp] I-D ACTION:draft-ietf-nntpext-authinfo-00.txt

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

> Is this the "always return 381 to USER" hack? That would be fine, I
> think.

Yeah, that's the one, although innd currently has a few other problems
(like replying with 480 to any other form of the AUTHINFO command).

> Try this wording, based on forbidding PASS-only:

This seems fine to me.

>> 400 in any circumstances other than as an initial greeting has very
>> little implementation out in the real world that I've seen.  I'll bet
>> that pretty much everyone uses 502 here.

> Nevertheless, this is one of the things we cleaned up in the base
> document.  Let's not break it now (particularly since to do so will
> require going back and changing the base document).

Hm.  Okay, that's fine with me, although I think it's worth a specific
mention at the beginning of whatever document we publish about this,
specifying that it's a change from existing practice that people will need
to take into account.

> The AUTHINFO extension could require this maximum to be extended for
> clients calling the AUTHINFO SASL command, yes. That would need to be
> made explicit.

*nod*.

>> Because you can detect a MIM attack that resulted in degraded security
>> if you look at the supported SASL mechanisms after the security layer
>> was negotiated and it differs from what was available before.

> So why shouldn't you advertise SASL?

I think the only reason not to advertise SASL after authentication is that
you are not allowed, IIRC, to redo a SASL negotiation after you've already
done one once (because of the privacy layer portion of it).

But that's just a vague memory, and I don't see that mentioned explicitly
in RFC 2222, so perhaps I'm wrong?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>