[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: "Issues and Fixes" changes
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
Hmm... yes. RFC 2865 has no requirements on Access-Requests with Call
Check containing State, so I think that requirement can be removed from
>> 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
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
> I would suggest MUST for Authorize-Only and MAY for Call-Check.
>> 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
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.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.