Question re: RFC 2865 and State attribute in table 5.44

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

RFC 2865 Section 5.44 states:

  [Note 1] An Access-Request MUST contain either a User-Password or a
  CHAP-Password or State.  An Access-Request MUST NOT contain both a
  User-Password and a CHAP-Password.  If future extensions allow other
  kinds of authentication information to be conveyed, the attribute for
  that can be used in an Access-Request instead of User-Password or
  CHAP-Password.

This seems to imply that if an authentication attribute isn't present in an 
Access-Request, then a State attribute must be.  Presumably if a state 
attribute is present, the NAS must have gotten it from somewhere, and the 
somewhere is either an Access-Accept (e.g. for a CoA-Request or 
Disconnect-Request), or an Access-Challenge (for an Access-Request).   Since 
this is an either/or, it seems possible that a State attribute wouldn't be 
present in an Access-Challenge if it was instead obtained from a previous 
Access-Accept.

Also, Section 5.24 states the following:

     This Attribute is available to be sent by the server to the client
     in an Access-Accept that also includes a Termination-Action
     Attribute with the value of RADIUS-Request.  If the NAS performs
     the Termination-Action by sending a new Access-Request upon
     termination of the current session, it MUST include the State
     attribute unchanged in that Access-Request.

This seems to imply that an Access-Request could contain a State attribute 
without having obtained it from an Access-Challenge.  For example, an EAP 
re-authentication attempt (e.g. Access-Request containing one or more 
EAP-Message attributes) could contain a State attribute obtained from a 
previous Access-Accept.  In this case, it's not clear to me that the 
Access-Challenge would necessarily have to contain a State attribute.

With respect to RFC 3579, leaving it out of Section 3.3 only implies that 
the Table entry is the same as in RFC 2865.  If the logic above applies, 
then it is possible for a State attribute not to be present in an 
Access-Challenge, though that is something of a corner case.

My overall recommendation is not to change the table, but to include some 
text clarifying the situation.  In practice there have been some 
interoperability issues with Access-Request packets containing State 
attributes that were not obtained from an Access-Challenge.


Alan DeKok said:

 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>