[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: "Issues and Fixes" changes
David B. Nelson wrote:
> Ah, so you are using MAY to indicate conditional MUST, rather than to
> indicate an option (i.e. personal choice). That doesn't comport with RFC
> 2119. I understand why the Table of Attributes has 0-1, but I'm concerned
> about the use of MAY in the text, especially if we really mean a conditional
> MUST. I think we need to break out the conditions in the text, applying
> MUST and MAY as appropriate.
The problem is that the MUST for State is really
implementation-dependent. i.e. challenge-response systems leverage
Access-Challenge and User-Password. Some need State, others do not.
The MAY here means "if your system needs it, it is permitted to use
it. If your system doesn't need it, there's no harm in adding it."
I'd like to make it a MUST, but based on the discussions around EAP, I
think it's only a SHOULD.
The other thing is that the whole use of State for authorization
checks is a horrible hack. Instead, there should be a session
identifier returned by the RADIUS server to the NAS in an Access-Accept,
and that session identifier should be used in all subsequent
authorization checks, and Accounting-Requests.
I've re-written the text, and as a bonus, it looks like we can drop
the references to specific authentication attributes:
Some RADIUS client implementations do not properly use the State
attribute in order to distinguish a restarted EAP authentication
process from the continuation of an ongoing process (by the same user
on the same NAS and port). Where an EAP-Message attribute is
included in an Access-Challenge or Access-Accept attribute, RADIUS
servers SHOULD also include a State attribute. See Section 2.1.3 on
Request ID supplementation for additional benefits to using the State
attribute in this fashion.
As defined in [RFC2865] Table 5.44, Access-Request packets may
contain a State attribute. The table does not qualify this
statement, while the text in Section 5.24 quoted above adds
We extend the requirements of [RFC2865] to say that Access-Requests
which are part of an ongoing Access-Request / Access-Challenge
authentication process SHOULD contain a State attribute. While most
implementations require the presence of a State attribute in an
Access-Challenge packet, some challenge-response systems can
distinguish the initial request from the response to the challenge
without using a State attribute to track an authentication session.
The Access-Challenge and subsequent Access-Request packets for those
systems do not need to contain a State attribute.
Other authentication systems require additional information outside
of the authentication mechanism in order to tie a sequence of Access-
Request / Access-Challenge packets to an ongoing authenticaiton
session. Those systems SHOULD include a State attribute in Access-
In general, if the authentication process involves one or more
Access-Request / Access-Challenge sequences, the State attribute
SHOULD be sent in the Access-Challenge packets.
The only permissible values for a State attribute are values provided
in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
Request packet. A RADIUS client MUST use only those values for the
State attribute that it has previously received from a server. An
Access-Request sent as a result of a new or restarted authentication
run MUST NOT include the State attribute, even if a State attribute
has previously been received in an Access-Challenge for the same user
In contrast, Access-Requests which are intended to perform
authorization checks MUST contain a State attribute in order to tie
the authorization check to a previous authentication session. This
last requirement often means that an Access-Accept needs to contain a
State attribute, which is then used in a later Access-Request that
performs authorization checks.
Access-Request packets that contain a Service-Type attribute with
value Authorize Only (17) MUST contain a State attribute. Access-
Request packets that contain a Service-Type attribute with value Call
Check (10) SHOULD NOT contain a State attribute. Any other Access-
Request packet that does not contain an authentication attribute as
defined above MUST contain a State attribute. This list is not
exhaustive, and may be extended in future specifications.
> I would recommend adding text to that effect, as an implementation note, to
> clarify when the State attribute is and is not required in an
> Access-Challenge and subsequent Access-Request.
See text above.
> Yes, adding wording as to what attributes require the inclusion of the State
> attribute would be preferable.
I would prefer to focus on the process, rather than the attributes. A
server may send an EAP-Message "identity request", and not include
State. For the rest of the EAP session, State may be required.
> I think we need to mention them, and describe the type of attribute that
> would qualify as authentication attribute in general terms. We should also
> advise authors of VSAs that they ought to take note of this issue, and be
> explicit in their documents as to whether or not a State attribute is
> required to pair up with any new authentication attributes being defined.
Is the suggested text above clear enough to cover this possibility?
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.