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

[Alan DeKok <aland@deployingradius.com>]

  Replying to myself with suggested  text that may be clearer:

...
   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 other
   requirements not specified in that table.

   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.  It is the
   responsibility of the server to send a State attribute in an Access-
   Challenge packet, if that server needs a State attribute in a
   subsequent Access-Request to tie multiple Access-Requests together
   into one authentication session.  As defined in [RFC2865] Section
   5.24, the State MUST be sent unmodified from the client to the server
   in the new Access-Request reply to that challenge, if any.

   While most server 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 mechanisms need to tie a sequence of Access-
   Request / Access-Challenge packets together into one ongoing
   authentication session.  Servers implementing those authentication
   mechanisms 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 by the server in the Access-Challenge packets.  Using
   the State attribute to create a multi-packet session is the simplest
   method available in RADIUS today.  While other methods of creating
   multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1),
   those methods are NOT RECOMMENDED.

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