[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CUI Version 03 submitted
Bernard, all
Proposed text and comments included in Issue 66 (see below) were
incorporated into version -03. I just submitted version -03. Until
this version appears on the I-D repository, you can find it here:
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i
d-03.txt.
Thanks,
Farid
===============
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Monday, February 14, 2005 8:31 AM
> To: radiusext@ops.ietf.org
> Subject: [Issue 66]: Review of CUI-02
>
>
> Issue 66: Review of CUI-02
> Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com
> Date first submitted: February 14, 2005
> Reference:
> Document: CUI-02
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>
> Section 1
>
> " Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
> IRAP, have been studying mechanisms to provide roaming services,
> using RADIUS. One missing element is a mechanism for providing the
> current deployments with the capacity to deploy, bill and
> oversee WPA
> networks against fraud.
>
> The CUI attribute is intended to close operational loopholes in
> RADIUS specifications that have impacted roaming solutions
> negatively, especially when tunneled protocols with multiple
> identities, such as PEAP or TTLS, are used. Use of the
> CUI is geared
> to multi-identity EAP authentications which are, for the most part,
> recent deployments. A chargeable identity reflecting the user
> profile authenticated by the home network is needed in such roaming
> scenarios."
>
> Why is usage of CUI specific to WPA, as opposed to say, WPA2 or WEP?
> For example, couldn't CUI be useful on PPP dialup networks
> authenticating
> via EAP? Here is my suggested rewrite:
>
> " Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
> IRAP, have been studying mechanisms to provide roaming services,
> using RADIUS. Missing elements include mechanisms for billing and
> fraud prevention.
>
> The CUI attribute is intended to close operational loopholes in
> RADIUS specifications that have impacted roaming solutions
> negatively. Use of the CUI is geared toward EAP methods supporting
> privacy (such as PEAP and EAP-TTLS), which are, for the most part,
> recent deployments. A chargeable identity reflecting the user
> profile authenticated by the home network is needed in such roaming
> scenarios."
>
> Section 1.1
>
> " The CUI attribute provides a solution to the above problem
> and avoids
> overloading the use of current RADIUS attributes (e.g.,
> User-Name(1)
> re-write). The CUI is the correct standards-based
> approach to fixing
> the problems which have arisen with multiple-identity RADIUS
> authorization and accounting methods. It does not solve
> all related
> problems, but does provide networks the ability to bill and oversee
> WPA networks against fraud."
>
> Again, not sure why WPA is singled out. Proposed revision:
>
> " The CUI attribute provides a solution to the above
> problems and avoids
> overloading (User-Name) or changing the usage of existing
> RADIUS attributes (Class). The CUI therefore provides a standard
> approach to billing and fraud prevention when EAP methods
> supporting
> privacy are used. It does not solve all related
> problems, but does provide for billing and fraud prevention."
>
> Section 2.1
>
> "Therefore whether a
> RADIUS server/proxy or client accepts or rejects the presence or lack
> of presence of the CUI attribute is a matter of business policy."
>
> Not sure what this means. Since the NAS indicates whether it supports
> CUI, did you mean to say:
>
> "Therefore a RADIUS server supporting this specification may
> not choose
> to send the CUI in response to an Access-Request from a given
> NAS, even
> if the NAS has indicated that it supports CUI."
>
> Section 2.1
>
> " If an Access-Accept packet without the CUI attribute was
> received by
> a RADIUS client (NAS or Proxy) that requires the presence
> of the CUI
> attribute, then the Access-Accept packet MAY be treated as an
> Access-Reject packet based on local policies.
>
> If the CUI was included in the Access-Accept packet, RADIUS client
> (Proxy or NAS) that supports the CUI attribute MUST ensure that the
> CUI attribute appears in the RADIUS Accounting-Request (Start,
> Interim, and Stop)."
>
> The term "required" usually refers to a MUST, in which case MAY is too
> mild. Also, earlier you say that proxies may not modify the CUI; but I
> assume this does not apply to inserting it.
>
> Suggested rewrite:
>
> " If an Access-Accept packet without the CUI attribute was
> received by
> a RADIUS client that requested the CUI attribute, then the
> Access-Accept packet MAY be treated as an Access-Reject.
>
> If the CUI was included in an Access-Accept packet, RADIUS clients
> supporting the CUI attribute MUST ensure that the CUI attribute
> appears in the RADIUS Accounting-Request (Start, Interim,
> and Stop)."
>
> " Therefore, RADIUS client or server that does not support the CUI
> attribute MAY ignore this attribute.
>
> If RADIUS client (Proxy or NAS) requires the presence of the CUI
> attribute in the Access-Accept, it MUST indicate its requirement by
> including the CUI attribute in the Access-Request packet
> with a value
> set to the nul character (hereafter, it is also referred
> to as a nul
> CUI)."
>
> I'd suggest you drop the upper case MAY here:
>
> " Therefore, RADIUS clients or servers that do not support the CUI
> may ignore the attribute. A RADIUS client requesting the CUI
> attribute in an Access-Accept MUST include within the
> Access-Request
> a CUI attribute with a single NUL character (referred to as a nul
> CUI)."
>
> " A RADIUS server (a RADIUS proxy or the home RADIUS server) that
> requires the presence of the CUI in the Accounting-Request packets
> (Start, Stop, Interims) MAY respond with an Access-Reject packet if
> it receives an Access-Request messsage from a RADIUS client, that
> does not support the CUI attribute. The Access-Reject packet MUST
> include Error-Cause attribute [RFC3576] with value (to-be-defined)
> (decimal), "CUI-Support-Required".
>
> This usage does not appear consistent with the only approved usage
> scenario, which is driven by RADIUS client requirements. So far,
> the document has only made an argument that Class cannot be used by
> clients. However, this paragraph implies that CUI can be used instead
> of Class in order to provide accounting information to servers. That
> usage is out of scope. I recommend that this paragraph be deleted.
>
> " A summary of the RADIUS CUI Attribute is given below."
>
> Suggest a new section start prior to this section:
>
> "2.2 CUI Attribute
>
> A summary of the RADIUS CUI Attribute is given below."
>
> Section 5.2
>
> I don't see how this section relates to an approved scenario. Suggest
> deleting it.
>
> Section 6.
>
> " If the NAS includes CUI in an Access-Request. A man in the middle
> may remove the CUI attribute from the Access-Request. The
> result is
> that the Access-Accept will not have a CUI which will cause the NAS
> to reject the session resulting in a DOS attack. To prevent this
> attack, the NAS SHOULD include Message-Authenticator(80) in the
> Access-Request packets that contain a CUI."
>
> Suggest rewriting to:
>
> " If the NAS includes CUI in an Access-Request, a man-in-the-middle
> may remove it. This will cause the Access-Accept to not include
> a CUI attribute, which may cause the NAS to reject the session.
> To prevent such a DoS attack, the NAS SHOULD include a
> Message-Authenticator(80) attribute within Access-Request packets
> containing a CUI attribute."
>
> --
> 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/>
>
--
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/>