[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: "Issues and Fixes" changes
David B. Nelson wrote:
>> ... Some need State, others do not.
> Here's the problem with that approach, it doesn't lead to interoperable
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
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
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
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
A SERVER implementation that needs state talks to a CLIENT
implementation that MUST echo State from an Access-Challenge in any
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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.