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

["Nelson, David" <dnelson@enterasys.com>]

Jari Arkko writes...

> Ok otherwise but lets be careful with the word "extends".
> There are different types of extensions, lets be more
> specific. How about
> 
>      This protocol defines how RADIUS (RFC 2865) is used in a
>      specific situation and vendor-specific protocol extensions.
>      It has been reviewed by the Radius community and the
>      following issues have been noted: (1) The document suggests
>      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. Instead, the use of an Access-Challenge packet 
>      would have been appropriate according to RFC 2865. (2) ... 
>      maybe more issues ...  As a result, the use of this specification
>      in other circumstances than those described in the document or 
>      as a basis for new work is not recommended.

This looks pretty good to me.  I'd suggest a few changes, as shown
below:

       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.



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