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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Alan DeKok writes...
 
> As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
> contain a State attribute.  We extend that definition here, to say
> that Access-Request packets that contain an authentication attribute
> or a Service-Type attribute with the value Call Check (10) MAY contain
> a State attribute.  Access-Request packets not matching the above
> description MUST contain a State attribute.

What does "an authentication attribute" mean?

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.  The Access-Challenge
may come back with a Reply-Message containing a nonce, e.g. 33409126 and a
State attribute.  You type the nonce into your hardware authentication
token, and it comes back with a response, e.g. 992398757.  The next
Access-Request message contains the User-Name, User-Password containing the
response, and the State attribute from the last Access-Challenge.

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.



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