Re: Request for Review: "Issues and Fixes" changes

[Alan DeKok <aland@deployingradius.com>]

David B. Nelson wrote:
>> ... Some need State, others do not.
> 
> Here's the problem with that approach, it doesn't lead to interoperable
> standards.

  To clarify: some SERVER implementations need State for particular
authentication methods.  Others do not.

  The only interoperability requirement is on the client.  If it sees a
State in an Access-Challenge, it echoes that back in the next
Access-Request.  There is no interoperability requirement on the server.
 If it needs State, it implements code looking for State.  If it doesn't
need state, it doesn't implement code looking for State.

>  The documents we produce are supposed to lead to independent,
> interoperable implementations based on the document alone.  I don't see how
> that happens if we decide that the on-the-wire message content is
> implementation-dependent. 

  The server requirements for local policy and authentication are
*always* implementation-dependent.  Sometimes the implementation is the
code, other times the local site policy.

> If any compliant system relies on receiving a given attribute for
> interoperability, then the standard needs to mandate that all
> implementations send that attribute.

  There's no reason for server to send State if they don't need it.

  What interoperability requirements are you thinking about?

>>   I'd like to make it a MUST, but based on the discussions around
>> EAP, I think it's only a SHOULD.
> 
> Please refresh my memory regarding these discussions.  Why would an EAP
> exchange in RADIUS not require the use of State?

  RFC 3579 doesn't recommend using it.  Instead, it has a very
complicated system which is more fragile, but sometimes functionally
equivalent.

  Even in EAP implementations that use State, the initial identity
request from the server doesn't need a State.  It probably *shouldn't*
have one, because allocating one would involve tracking sessions for
unknown, and un-named users.

>>    Some RADIUS client implementations do not properly use the State
>>    attribute in order to distinguish a restarted EAP authentication
>>    process from the continuation of an ongoing process (by the same user
>>    on the same NAS and port).  Where an EAP-Message attribute is
>>    included in an Access-Challenge or Access-Accept attribute, RADIUS
>>    servers SHOULD also include a State attribute.
> 
> Why is this not a MUST?

  See above.  Also, Section 2.1.2 in the document describes the new
method of using State, and makes it a SHOULD.

>>    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.
> 
> Why not MUST for the general case, with SHOULD or MAY for specific exception
> cases?

  The only MUST is that an implementation MUST use State if there's no
simpler way to track a "session".  If multiple packet exchanges don't
need "session" tracking (as above), then there's no need to use State.

  I have no real objection to making it a MUST, but doing so would
involve requiring many implementations to add State that they don't need.

> And how does an implementation that needs State tell that it is talking to
> an implementation that doesn't?  This seems like a real interoperability
> problem.

  A SERVER implementation that needs state talks to a CLIENT
implementation that MUST echo State from an Access-Challenge in any
subsequent Access-Request.

  Server implementations don't talk to each other. :)

>>   Any other Access-
>>    Request packet that does not contain an authentication attribute as
> 
> Uh... We just used the undefined term "authentication attribute".  :-)

  I'll go nuke it.

>>  A server may send an EAP-Message "identity request", and not include
>> State.  For the rest of the EAP session, State may be required.
> 
> May be required?  When?  Why?  Under what circumstances?  I don't think we
> can leave it that open ended.

  RFC 3576 does.  I believe that there are EAP server implementations
that don't use State.

>>> We should also advise authors of VSAs that they ought to take 
>>> note of this issue, and be explicit in their documents as to whether
>>> or not a State attribute is required to pair up with any new 
>>> authentication attributes being defined.
>>   Is the suggested text above clear enough to cover this possibility?
> 
> Not really.  I didn't see any mention of VSAs.

  It's not about VSA's.  It's about the authentication process.  I would
prefer to not discuss VSA's, or the particular authentication attributes
(whatever they are).

  The recommendation is that new authentication methods SHOULD use State
for multiple Access-Request / Access-Challenge sequences.  Since
existing methods *don't* use State all of the time for such sequences,
it's impolite to require that new methods MUST use it.

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