Re: IESG review comments on the RADIUS Issues and Fixes draft

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> What does "an authentication attribute" mean?

  Hmm... good point.

> I think it might be better to focus on the initiation (or re-initiation) of
> an authentication sequence, rather than focusing on which attributes are
> included.
> 
> For example, if one were to implement a textual challenge method, the
> initial Access-Request may just contain a User-Name.

  Which breaks the current requirements to include User-Password, or
CHAP-Password, State, or EAP-Message.

> In this case the initial Access-Request doesn't have any "authentication
> attributes", which are traditionally User-Password, CHAP-Password, EAP
> Message, and whatever RFC 4590 defines for this purpose.  Given that future
> work may add other authentication methods, attempting to define when the
> State attribute MUST be included in an Access-Request based on the other
> attributes in the message seems problematic.  I think it better to define it
> based on start (or restart) vs. continuation of an authentication sequence.

  Makes sense to me.  We already have some requirements on the use of
the State attribute:

   An Access-Request sent as a result of a new or restarted
   authentication run MUST NOT include the State attribute, even if the
   State attribute has previously been received in an Access-Challenge
   for the same user and port.

   Since a State attribute is always initially provided by the server in
   an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
   Request, a RADIUS client MUST NOT insert a State attribute that it
   has not previously received from the server.

  The goal of the suggested text would seem to be to extend [RFC 2865]
Section 4.1:

      An Access-Request MUST contain either a User-Password or a CHAP-
      Password or a State.

  What I want to say is:

  1) Access-Requests that can be authenticated when the server examines
their contents do not need a State.  e.g. User-Password, CHAP-Password,
or sometimes the final packet in a multi-packet challenge/response scheme.

  2) Access-Requests that are part of an ongoing authentication session
otherwise MUST have State.  The server is responsible for sending State
in an Access-Challenge when it believes it will need State in the next
Access-Request.  The client is responsible for including State in all
Access-Requests that are sent in response to an Access-Challenge.

  I think that covers the scenarios we need, while avoiding the
definition of an "authentication attribute".

  Suggested word-smithing of the above goals?  Do the goals meet
expectations?

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