[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: "Issues and Fixes" changes
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. If it doesn't
need state, it doesn't implement code looking for State.
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. Therefore if there is no authentication attribute present,
then the server needs some evidence that the request is linked to a previous
user authentication, so that the server is authorized to answer the request.
That evidence is provided by the State Attribute.
So I don't think it is accurate to say that the server can dispense with the
State Attribute without consequences.
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.
> Please refresh my memory regarding these discussions. Why would an EAP
> exchange in RADIUS not require the use of State?
RFC 3579 doesn't recommend using it. Instead, it has a very
complicated system which is more fragile, but sometimes functionally
Where an EAP-Message attribute is included in an Access-Request, the RFC
2865 requirement for an authentication attribute or State is fulfilled. So
I would agree that the use of State is not required.
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.
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. Given this situation, I don't believe that a
SHOULD would provide the required clarification. Instead, it would be better
to clarify the cases in which State is a MUST and the cases in which it is
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.