[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Question re: RFC 2865 and State attribute in table 5.44



  Table 5.44 lists 'State' as "0-1" for Access-Challenge.  Are there any
client and/or server implementations that *don't* send a State in an
Access-Challenge?  Section 4.4 says the Access-Challenge "MAY have a
single State Attribute, or none."  But it doesn't explain why.

  I note that RFC 3579, Section 3.3 doesn't list "State" as being
necessary for EAP conversations.  I can't even find *any* reference to
the attribute in RFC 3579, which seems a little odd.

  Is this something that needs to be addressed?  I'm not aware of any
EAP implementations that *don't* use State, so it would appear to be
required for Access-Challenge, where the packet contains an EAP-Message
that isn't an EAP Success or Failure.  Maybe the lack of use of the
State attribute is why section 2.6.1 (Identifier Space) describes such a
complicated mechanism for discriminating sessions.

  Are there any other use cases where it is not necessary to send the
State attribute in an Access-Challenge?  I can't recall seeing any, and
all of the clients & servers I've written require it.

  Is there a problem with requiring State in Access-Challenge?  I'm not
sure I should file an official ISSUE until I'm sure I understand what
the intent was.

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