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