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

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

Bernard Aboba writes...

> If I read RFC 2865 correctly, it would seem that an Access-Request
> containing Service-Type="Call-Check" MUST contain a State attribute,
> since this won't contain User-Password, CHAP-Password or any other
> "authentication" attribute".  Now, I'm not sure I understand where
> the NAS is supposed to get the State Attribute from...

Indeed.  This brings to mind one of my favorite sayings regarding software:
"How did this ever work?".

My understanding of the use case for a Access-Request with a Service-Type of
Call-Check is that the Calling-Station-ID (and possibly the
Called-Station-ID) provides the identity of the remote user for the purpose
of a pre-screening authentication, originally used to decide whether the NAS
should accept the call set-up on an ISDN or DSL link, terminating in a modem
pool.  The idea was to avoid tying up a modem, if the user wasn't one of
your authorized customers.  In this use case there can be no valid source of
the State attribute in the NAS.

> ...but that does seem to be what RFC 2865 is saying.

Well, I wonder...
 
> > >    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"?
> 
> This quote came from RFC 2865, so I'm not sure what it means.  
> That's for us to figure out, I guess :)

I'll look at this again, in context, but taken out of context it does seem
confusing.

> That is already in RFC 2865, I believe.

Yes, and we think it's correct!  :-)

> BTW, I believe that there may be some other hints on this in
> RFC 2869. For example, in the ARAP section there is some discussion
> of how NASes that don't support ARAP are supposed to behave.

OK, we can look at that text for any possible guidance.



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