[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: "Issues and Fixes" changes
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
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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.