Proposed Resolution of Fixes Issue 141: State Attribute

["Bernard Aboba" <bernard_aboba@hotmail.com>]

The text of Issue 141 is enclosed below.  The proposed resolution is as 
follows:

Insert the following text at the end of Section  2.8:

"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."

---------------------------------------------------------------------------------------------------------------
Issue 141: State Attribute
Submitter name: David Mitton
Submitter email address: david@mitton.com
Date first submitted: November 11, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg01024.html
Document: Fixes-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

wrt State attribute; there was a case in the past where a vendor decided 
that their client would sent a State attribute with Null data to start a 
certain proprietary sequence. Non-Vendor's clients would fail on this server 
due to this expectation.

You should make it clear that a new Access-Request should not contain a 
State attribute. State should always come from a server, and prior context. 
Not manufactured by the client.



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