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

[Avi Lior <avi@bridgewatersystems.com>]

So I am okay about this -- but only for now.

Going forward we have an issue and we need to think about this.

Access-Reject may not always result in the termination of a session etc...

For example, when I am doing authorize only, (Access-Accept with
Service-Type = Authorize-Only) the Access-Reject is a rejection of that
authorization and not necessarily the rejection of the entire session or
service.  Or is it? 

Avi

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Friday, March 04, 2005 11:44 AM
> To: Nelson, David
> Cc: Jari Arkko; gwz@cisco.com; Avi Lior; Thomas Narten; W. 
> Mark Townsley; Frank Quick; christopher.carroll@hbsr.com; 
> radiusext@ops.ietf.org
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> On Fri, Mar 04, 2005 at 10:13:47AM -0500, Nelson, David wrote:
> > 
> >        This protocol defines how RADIUS (RFC 2865) is used in a
> >        specific application using vendor-specific protocol 
> extensions.
> >        It has been reviewed by the RADIUS community within 
> the IETF and
> >        the following issues have been noted: (1) This 
> document specifies
> >        returning an attribute in an Access-Reject message. 
> According to
> >        RFC 2865 an Access-Reject packet MAY only include 
> Reply-Message
> >        and Proxy-State attributes.  Subsequent RFCs allow for other
> >        attributes to be included in an Access-Reject 
> packet, but these
> >        are included to indicate the reason the 
> > authentication/authorization
> >        has failed.  It is a normative requirement of RFC 2865 that 
> > receipt
> >        of an Access-Reject at the NAS terminate the session of the 
> > attached
> >        network host.  This document violates that normative 
> requirement.
> >        Instead, the use of an Access-Challenge packet would 
> have been
> >        appropriate according to RFC 2865. (2) The security 
> > considerations
> >        of this specification rely, in part, on the specific cellular
> >        telephony infrastructure used in this application, and the 
> > protocol
> >        extensions as described herein potentially exhibit 
> inadequate 
> >        security properties when used outside of the 
> specific deployment
> >        environment.  As a result, the use of this 
> specification in other
> >        circumstances than those described in this document or as a 
> > basis
> > 
> >        for new work is strongly discouraged.
> 
> I endorse this.  To me, the prime problem is the 
> non-termination on -reject. Inclusion on attributes in the 
> -reject, while a clear violation of 2865, is the lesser issue.
> 
> Barney
> 
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I never met a computer I didn't like.
> 

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