>To clarify: some SERVER implementations need State for particular
>authentication methods. Others do not.
>
>The only interoperability requirement is on the client. If it sees a
>State in an Access-Challenge, it echoes that back in the next
>Access-Request. There is no interoperability requirement on the server.
>If it needs State, it implements code looking for State.
gwz> And sending a State attribute in the first place.
>If it doesn't
>need state, it doesn't implement code looking for State.
gwz> Nor send a State attribute in the first place.
I think the issue goes beyond interoperability (although that is certainly
something worth
clarifying).
For example, if an Access-Request contains neither an authentication
attribute or State attribute, there are security implications.
Some RADIUS attributes (such as Tunnel-Password) reveal confidential
information about a user, and so they require some evidence of user
authentication.
gwz> Well, maybe; but when used w/L2TP (the only real-world usage of the Tunnel-
gwz> Password attribute of which I'm aware) it normally contains a password for
gwz> the NAS/LAC to use to authenticate itself to the LNS & so has nothing to do
gwz> with any human user. The RFC 2868 attributes are often used in replies to
gwz> Access-Requests with Service-Type = Call Check, BTW.
> There's no reason for server to send State if they don't need it.
For the reasons above, I don't believe that is what RFC 2865
intended.
gwz> I don't quite get your logic here. 2865 seems pretty clear and unambiguous
gwz> (for once ;-) on this topic: usage of the State attribute is always optional on
gwz> the server side & server driven and it is always mandatory on the client side --
gwz> if it receives one it must return it unchanged in the next Access-Request (if
gwz> any).
...
> The recommendation is that new authentication methods SHOULD use State
>for multiple Access-Request / Access-Challenge sequences. Since
>existing methods *don't* use State all of the time for such sequences,
>it's impolite to require that new methods MUST use it.
gwz> I agree.
RFC 2865 has a MUST relating to inclusion of authentication attributes or
State within an Access-Request. It would seem that this ignored some cases
(such as Call-Check) in which State either is optional or realistically
can't be included at all.
gwz> I believe that common practice is to include a User-Password attribute in call
gwz> checks, possibly containing a canned "password". This practice has the
gwz> nice side-effect of providing (weak) authentication of the NAS as well --
gwz> something that was otherwise impossible pre-2869.
...