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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Alan DeKok writes...

>   The problem is that the MUST for State is really
> implementation-dependent.  i.e. challenge-response systems
> leverage Access-Challenge and User-Password.  Some need State,
> others do not.

Here's the problem with that approach, it doesn't lead to interoperable
standards.  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. 

Sure, implementers are free to innovate and go above and beyond the
standard, or even to deviate from the standard if they don't want to claim
strict compliance.  What we cannot do, I think, is decide that the standard
should leave the on-the-wire message format and content up to individual
implementations.  It needs to be fully specified -- standardized.

>   The MAY here means "if your system needs it, it is permitted to use
> it.  If your system doesn't need it, there's no harm in adding it."

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

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

>   The other thing is that the whole use of State for authorization
> checks is a horrible hack.

Well, yeah, maybe.  But it's a standardized hack, upon which many
implementations rely.  :-)  It is what it is.
 
>   I've re-written the text, and as a bonus, it looks like we can drop
> the references to specific authentication attributes:
> 
> ...
>    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 Section 2.1.3 on
>    Request ID supplementation for additional benefits to using the State
>    attribute in this fashion.
> 
>    As defined in [RFC2865] Table 5.44, Access-Request packets may
>    contain a State attribute.  The table does not qualify this
>    statement, while the text in Section 5.24 quoted above adds
>    additional requirements.
> 
>    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?

>    While most
>    implementations require the presence of a State attribute in an
>    Access-Challenge packet, some challenge-response systems can
>    distinguish the initial request from the response to the challenge
>    without using a State attribute to track an authentication session.
>    The Access-Challenge and subsequent Access-Request packets for those
>    systems do not need to contain a State attribute.

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.
 
>    Other authentication systems require additional information outside
>    of the authentication mechanism in order to tie a sequence of Access-
>    Request / Access-Challenge packets to an ongoing authentication
>    session.  Those systems SHOULD include a State attribute in Access-
>    Challenge packets.
> 
>    In general, if the authentication process involves one or more
>    Access-Request / Access-Challenge sequences, the State attribute
>    SHOULD be sent in the Access-Challenge packets.

Again, why not MUST?  Or at least MUST for the general case, with SHOULD or
MAY for specific exception cases (that we fully describe).

>    The only permissible values for a State attribute are values provided
>    in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
>    Request packet.  A RADIUS client MUST use only those values for the
>    State attribute that it has previously received from a server.  An
>    Access-Request sent as a result of a new or restarted authentication
>    run MUST NOT include the State attribute, even if a State attribute
>    has previously been received in an Access-Challenge for the same user
>    and port.
> 
>    In contrast, Access-Requests which are intended to perform
>    authorization checks MUST contain a State attribute in order to tie
>    the authorization check to a previous authentication session.  This
>    last requirement often means that an Access-Accept needs to contain a
>    State attribute, which is then used in a later Access-Request that
>    performs authorization checks.
> 
>    Access-Request packets that contain a Service-Type attribute with
>    value Authorize Only (17) MUST contain a State attribute.  Access-
>    Request packets that contain a Service-Type attribute with value Call
>    Check (10) SHOULD NOT contain a State attribute.  Any other Access-
>    Request packet that does not contain an authentication attribute as

Uh... We just used the undefined term "authentication attribute".  :-)

>    defined above MUST contain a State attribute.  This list is not
>    exhaustive, and may be extended in future specifications.

>   I would prefer to focus on the process, rather than the attributes.

Agreed.

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

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



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