[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question re: RFC 2865 and State attribute in table 5.44
RFC 2865 Section 5.44 states:
[Note 1] An Access-Request MUST contain either a User-Password or a
CHAP-Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow other
kinds of authentication information to be conveyed, the attribute for
that can be used in an Access-Request instead of User-Password or
This seems to imply that if an authentication attribute isn't present in an
Access-Request, then a State attribute must be. Presumably if a state
attribute is present, the NAS must have gotten it from somewhere, and the
somewhere is either an Access-Accept (e.g. for a CoA-Request or
Disconnect-Request), or an Access-Challenge (for an Access-Request). Since
this is an either/or, it seems possible that a State attribute wouldn't be
present in an Access-Challenge if it was instead obtained from a previous
Also, Section 5.24 states the following:
This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the NAS performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
attribute unchanged in that Access-Request.
This seems to imply that an Access-Request could contain a State attribute
without having obtained it from an Access-Challenge. For example, an EAP
re-authentication attempt (e.g. Access-Request containing one or more
EAP-Message attributes) could contain a State attribute obtained from a
previous Access-Accept. In this case, it's not clear to me that the
Access-Challenge would necessarily have to contain a State attribute.
With respect to RFC 3579, leaving it out of Section 3.3 only implies that
the Table entry is the same as in RFC 2865. If the logic above applies,
then it is possible for a State attribute not to be present in an
Access-Challenge, though that is something of a corner case.
My overall recommendation is not to change the table, but to include some
text clarifying the situation. In practice there have been some
interoperability issues with Access-Request packets containing State
attributes that were not obtained from an Access-Challenge.
Alan DeKok said:
Table 5.44 lists 'State' as "0-1" for Access-Challenge. Are there any
client and/or server implementations that *don't* send a State in an
Access-Challenge? Section 4.4 says the Access-Challenge "MAY have a
single State Attribute, or none." But it doesn't explain why.
I note that RFC 3579, Section 3.3 doesn't list "State" as being
necessary for EAP conversations. I can't even find *any* reference to
the attribute in RFC 3579, which seems a little odd.
Is this something that needs to be addressed? I'm not aware of any
EAP implementations that *don't* use State, so it would appear to be
required for Access-Challenge, where the packet contains an EAP-Message
that isn't an EAP Success or Failure. Maybe the lack of use of the
State attribute is why section 2.6.1 (Identifier Space) describes such a
complicated mechanism for discriminating sessions.
Are there any other use cases where it is not necessary to send the
State attribute in an Access-Challenge? I can't recall seeing any, and
all of the clients & servers I've written require it.
Is there a problem with requiring State in Access-Challenge? I'm not
sure I should file an official ISSUE until I'm sure I understand what
the intent was.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.