RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

[Avi Lior <avi@bridgewatersystems.com>]

I don't see any problem here...

In repsonse to an Access-Request for access to the network, Access-Reject
repsonse states to the NAS not to give the Session access to the network (or
however you want to word it).

What the NAS does to the connection between it an the user's device is out
of scope to RADIUS.  If the NAS wants to maintain the L2 connection to the
device it can.  



> -----Original Message-----
> From: Alan DeKok [mailto:aland@ox.org] 
> Sent: Monday, March 07, 2005 8:52 PM
> To: gwz@cisco.com; 'Frank Quick'; 'W. Mark Townsley'
> Cc: 'Jari Arkko'; 'Nelson, David'; 'Barney Wolff'; 'Avi 
> Lior'; 'Thomas Narten'; 'Carroll, Christopher P.'; 
> gerry.flynn@verizonwireless.com; radiusext@ops.ietf.org
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> "Glen Zorn (gwz)" <gwz@cisco.com> wrote:
> > I think that this is an error in 2869, and itself a 
> violation of 2865.
> ...
> > However, you are right that 2865 does not explicitly say that the 
> > connection must be dropped, it merely assumes that that is the only 
> > reasonable course of action.  I agree with that assumption, 
> obviously, 
> > since otherwise the semantics of the Access-Reject message 
> are up for 
> > grabs.
> 
>   I agree.  The use of Access-Reject as a *normal* part of a
> *continuing* authentication conversation violates RFC 2865.  
> The text in RFC 2869 should have used Access-Challenge, and 
> included the Password-Retry attribute there.  RFC 2869 
> Section 2.2 page 8, even
> says:
> 
>    If that authentication fails, the RADIUS server should return an
>    Access-Reject packet to the NAS, with optional Password-Retry and
>    Reply-Messages attributes.  The presence of Password-Retry 
> indicates
>    the ARAP NAS MAY choose to initiate another 
> challenge-response cycle,
> 
>   "challenge-response" should mean the use of the 
> Access-Challenge packet, and only the Access-Challenge attribute.
> 
>   RFC 2865, Section 4.4, page 19 addresses the semantics of 
> Access-Challenge being equivalent to Access-Reject in some cases:
> 
>       If the NAS does not support challenge/response, it MUST treat an
>       Access-Challenge as though it had received an Access-Reject
>       instead.
> 
>   Given the discussion surrounding Access-Reject, and the 
> comments about RFC 2869, I think we should open another issue 
> for the RFC 2869 violation of Access-Reject semantics, 
> independent of this draft.
> 
>   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/>