Re: Request for Review: "Issues and Fixes" changes

[Alan DeKok <aland@deployingradius.com>]

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
   additional requirements.

   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-
   Challenge packets.

   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
   and port.

   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?

  Alan DeKok.

--
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/>