[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>