[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
equivalent.
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 optional. 



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>