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

["David B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...

> >>    We extend this definition to say that Access-Requests which
> >>    are part of an ongoing authentication process MAY contain a
> >>    State attribute.
> >
> > So, this sentence really confuses me.  Maybe I'm taking it out
> > of context, but my understanding is that an Access-Request that
> > is part of an ongoing authentication process MUST contain a State
> > Attribute.  This has been the case since the State attribute was
> > defined.  Why are we changing it to MAY?
> 
>   We're not.  RFC 2865, Table 5.44 says State is "0-1" in
> Access-Request.  Note 1 says that Access-Requests contain User-
> Password, CHAP-Password, or State.  Section 2 says that Access-
> Challenges MAY contain State.

Ah, so you are using MAY to indicate conditional MUST, rather than to
indicate an option (i.e. personal choice).  That doesn't comport with RFC
2119.  I understand why the Table of Attributes has 0-1, but I'm concerned
about the use of MAY in the text, especially if we really mean a conditional
MUST.  I think we need to break out the conditions in the text, applying
MUST and MAY as appropriate.  One of the nits that has always bothered me
about RFC 2865 (and others that imitate its style) is relegating important,
normative elements of the protocol definition to footnotes to the Table of
Attributes. I think we can do better to aid readability by pulling those
elements out into text descriptions, in the relevant sections where the
concepts are discussed.

>   While most implementations require State in Access-Challenge, I have
> seen some challenge-response systems that do not require it.  Those
> systems can distinguish the initial request from the response to the
> challenge without using State to track a "session".

I would recommend adding text to that effect, as an implementation note, to
clarify when the State attribute is and is not required in an
Access-Challenge and subsequent Access-Request.

> >>    Any Access-Request that does not contain an authentication
> >>    attribute MUST contain a State attribute.  This list of
> >>    authorization parameters is not exhaustive, and may be extended
> >>    in future specifications.
> >
> > In the second sentence, did you mean "authentication" rather than
> > "authorization"?
> 
>   Maybe.  I think it's safer just to clean up the terminology.

Yes, adding wording as to what attributes require the inclusion of the State
attribute would be preferable.
 
>   What about vendor or SDO extensions?

I think we need to mention them, and describe the type of attribute that
would qualify as authentication attribute in general terms.  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.
That advice might also go in the Design Guidelines draft, BTW. 




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