[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question re: RFC 2865 and State attribute in table 5.44
- To: radext mailing list <email@example.com>
- Subject: Question re: RFC 2865 and State attribute in table 5.44
- From: Alan DeKok <firstname.lastname@example.org>
- Date: Tue, 30 Jan 2007 17:09:56 +0100
- User-agent: Thunderbird 184.108.40.206 (Windows/20061207)
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.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.