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

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> Alan DeKok writes...
> 
>>   The Call-Check MAY need to be tied to a previous authentication
>> request.  This can be done via the State attribute being sent in an
>> Access-Accept, and used in a later Access-Request with Call Check.
> 
> Can you suggest a specific use case where this may happen?   My
> understanding of the use of Call-Check is that it always precedes a formal
> authentication.

  Hmm... yes.  RFC 2865 has no requirements on Access-Requests with Call
Check containing State, so I think that requirement can be removed from
the document.


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

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

>>    Access-Request packets that contain a Service-Type attribute with
>>    value Call Check (10) or Authorize Only (17) MUST contain a State
>>    attribute.
> 
> I would suggest MUST for Authorize-Only and MAY for Call-Check.

  OK.

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

> As I indicated in a separate message, I think we need to include a formal
> definition (e.g. by list) of those attributes we consider to be
> authentication attributes.

  What about vendor or SDO extensions?

> We are debating whether unknown values of other attributes, or unknown
> attribute types, ought to be treated similarly.  The suggestion is that a
> NAS MAY choose to treat them similarly, i.e. treat unknown attribute types,
> or unknown values of known attribute types as an Access-Reject based on
> locally configured policy, with the default being to silently ignore them,
> for backwards compatibility.  NASes MAY implement this local policy feature,
> and it is RECOMMENDED for any new implementations or significant revisions.
> We ought not to deprecate any existing implementations that don't have this
> local policy feature, however.

  Yes.

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