[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CUI version -02
Hi all,
We just submitted version -02 of the document. It does not yet appear
in the I-D repository, but you can access it here.
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i
d-02.txt
This version includes resolutions for:
- Issue 52 ; please see the mail snapshot below for exact changes.
- Issue 46 ; please see the mail snapshot below for exact changes.
- Issue 49
- Issue 13 - should be closed.
- Issue 56, 57, 58 are related to capability advertisement. Note: Since
the CUI advertisement is not REQUIRED, the CUI does not need to wait for
Capabilities attribute - your thoughts?.
- And some editorial clean-ups ...
Thanks,
Farid
///---------------------------------------
/// Issue 52
///---------------------------------------
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Saturday, January 08, 2005 3:42 PM
> To: radiusext@ops.ietf.org
> Subject: Issue 52: Review of CUI-01
>
>
> Issue 52: Review of CUI-01
> Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com
> Date first submitted: January 8, 2004
> Reference:
> Document: CUI-01
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> Section 1
>
> " For example, local or intermediate networks may limit the number of
> simultaneous sessions for specific users; they may require a
> chargeable-user-identity in order to demonstrate willingness to pay
> or otherwise limit the potential for fraud.
>
> This implies that an authenticated and unique identity provided by
> the home network should be able to be conveyed to all parties
> involved in the roaming transaction for correlating the
> authentication and accounting packets.
>
> Providing a unique identity, called the Chargeable-User-Identity
> (CUI) to intermediaries, is necessary to fulfill certain business
> needs. This should not undermine the anonymity of the user. The
> mechanism provided by this draft allows the home operator to meet
> these business requirements by providing a temporary identity
> representing the subscriber and at the same time protecting the
> anonymity of the subscriber."
>
> There is a tradeoff between providing an authenticated and
> unique identity to all parties suitable for correlation, while also
> not compromising some aspects of privacy.
>
> Later on in Section 1.1, it is stated:
>
> " When the home network assigns a value to
> the CUI, it asserts that this value represents a user in the home
> network. The assertion should be temporary. Long enough to be
> useful for the external applications and not too long such that it
> can be used to identify the user."
>
> I think this paragraph helps clarify the tradeoff, so that it
> should follow the paragraph above.
>
[FA] Done.
> Section 1.1
>
> The first two paragraphs appear like they belong better in Section 1.
>
[FA] There were moved to section 1 with some editing:
"
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.
"
> "A mechanism for providing the current deployments wit
> the capacity to deploy, bill and oversee WPA networks against fraud."
>
> This is not a sentence. Should this be
> "One missing element is a mechanism for...."
>
[FA] Done - please see the above edited paragraphs that moved up.
> "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."
>
> This statement appears to come out of the blue. We are just
> getting into a discussion of usage scenarios, and suddenly
> we jump to a discussion which appears to be about backward
> compatibility. I'd suggest you move this sentence later
> in the document where it may be better put in context.
>
[FA] This paragraph was moved to section 2.1. It was combined with the
second paragraph in section 2.1, as below:
"
The RADIUS server (a RADIUS proxy, home RADIUS server) may include the
CUI attribute in the Access-Accept message destined to a roaming
partner. The CUI support by RADIUS infrastructure is driven by the
business requirements
between roaming entities. 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.
"
> "Additionally,
> there could be multiple class attributes in a RADIUS packet with
> unspecified ordering, which makes it hard to the entities outside
> home network to determine which one contains the CUI."
>
> RFC 2865 does specify that attributes of the same type are not
> reordered by proxies, so I don't think ordering is an issue.
> The problem is opacity, which would occur whether a single
> Class attribute was used, or multiple attributes. My
> recommendation is to delete this sentence.
[FA]
You are right that 2865 does specify the ordering of class. But it is
still an issue.
An intermediary receives an list of class attributes:
If the home network inserted once class attributes then the intermediary
can assume that the first class attributes represents the CUI however if
it did not and someone else inserted the class attribute then the next
intermediary
will act on the first class attribute which would not be the CUI. So
the problem really stems from the fact that even though class is
ordered, an intermediary cannot with certainty detect which one if any
contains the CUI-like-information. So, perhaps we can fix the above
sentence (as below) instead of removing it:
"Additionally, there could be multiple class attributes in a RADIUS
packet, and since the contents of Class attribute is not to be
interpreted by clients, this makes it hard to the entities outside home
network to determine which one contains the CUI."
>
> " The home network could use User-Name(1) in the Access-Accept
> message to convey the CUI to intermediaries and the
> NAS. However,
> as the Access-Accept packet is routed to the NAS, the
> User-Name(1)
> attribute could be (completely) rewritten by an intermediary and
> therefore the NAS or other intermediaries along the way will not
> have access to the CUI. Furthermore, the NAS may use
> the original
> value of the User-Name(1) attribute (the one sent in the
> Access-Request packet) in the Accounting-Request
> packets to ensure
> the billing follows the same path as authentication packets."
>
> To my knowledge, existing implementations do not rewrite a User-Name
> attribute sent in an Access-Accept, since a proxy-state attribute
> can be used to enable routing of the Access-Accept back to the NAS
> without examining the User-Name attribute. So the issue is not
> rewriting so much as the potential impact on routing of accounting
> packets. For example, the original "privacy" NAI in the
> EAP-Response/Identity might have been:
> example.com!@isp.com.
>
> This is rewritten by isp.com to "@example.com". As a result,
> the example.com RADIUS server may not even be aware of isp.com
> as an intermediary, and might send a User-Name attribute in the
> Access-Accept of "2388484848@example.com". However, without
> decoration, the resulting Accounting-Request would be routed
> differently than the Access-Request, which might cause problems.
> Section 2.1
>
[FA] Based on our email exchanges on this thread, I agree your proposed
text (with some minor modification/editing):
"
The User-Name(1) attribute included in the Access-Request may be used
for the purpose of request routing, and in the process may be rewritten
by intermediaries. As a result, a RADIUS server receiving an
Access-Request packet relayed by a proxy cannot assume that the
User-Name(1) attribute remained unmodified.
On the other hand, rewriting of a User-Name(1) attribute sent within an
Access-Accept packet occurs more rarely, since a Proxy-State(33)
attribute can be used to route the Access-Accept packet without parsing
the User-Name(1) attribute. As a result, a RADIUS server cannot assume
that a proxy stripping routing information from a User-Name(1) attribute
within an Access-Request will add this information to a User-Name(1)
attribute included within an Access-Accept. The result is that when a
User-Name(1) attribute is sent in an Access-Accept it is possible that
the Access-Request and Accounting-Request packets will follow different
paths. Where this outcome is undesirable, the RADIUS client should use
the original User-Name(1) in accounting packets. Therfore, another
mechanism is required to convey a CUI within an Access-Accept message to
the RADIUS client, so that the CUI can be included in the accounting
packets.
"
> "RADIUS clients (proxy or NAS) outside
> the home network MUST NOT modify the CUI attribute."
>
> I think you want to say that RADIUS proxies MUST NOT modify the CUI
> attribute, and that NAS devices that support CUI MUST include
> it in the
> Accounting-Request unmodified, no?
[FA] We mean both proxies and NAS. And you are right about the
inclusion of the CUI in the accounting packets, and we mention that
couple of paragraphs below in section 2.1. In summary, we are not
requesting some behavior *other* than having proxies leave the CUI alone
and having NAS devices include it in the Accounting-Request.
>
> " RADIUS client (Proxy or NAS) that does not support the CUI
> attribute
> MAY ignore this attribute or MAY treat the Access-Accept as
> Access-Reject."
>
> Rather than including this paragraph, I would cite RFC 2865
> with respect
> to behavior on receipt of an unimplemented attribute in an
> Access-Accept.
> That way you are guaranteed not to be updating RFC 2865.
> For example, RFC 2865 only indicates that an Access-Accept
> is treated as an Access-Reject if the service cannot be provided.
> This would require a different value of the Service-Type attribute,
> which is not used here. So the statement above represents a major
> change to RFC 2865, which is already a Draft Standard.
>
[FA] Right. The paragraph was reworked as below:
"
RFC 2865 includes the following statements about behaviors of RADIUS
client and server with respect to unsupported attributes: "A RADIUS
client MAY ignore Attributes with an unknown Type." and "A RADIUS server
MAY ignore Attributes with an unknown Type.". 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 this attribute with a nul character for its data field
> (hereafter, it is also referred to as a nul CUI) in the
> Access-Request message."
>
> A cleaner approach might be to include a Capabilities
> attribute including the Type codes of (standard) attributes
> that the NAS is advertising support for. That way a single
> attribute could be used to advertise support for up to 253
> attributes.
>
[FA] I think we all agree on the benefit of having a capabilities
attribute. There has been several solution proposals, that I hope we
can work together to come up with a reasonable solution. In the mean
time, I will not make any changes to the document on this -- and I think
we should capture and track this as a separate issue.
> " If the NAS supports CUI attribute then the CUI attribute
> MAY also be
> used as one of the identity attribute in Disconnect Message and
> Change of Authorization messages defined by [RFC3576].
> Determination
> of NAS support for the CUI is outside the scope of this document."
>
> I don't think this is a good idea. There is already an issue in
> translation of RFC 3576 messages into equivalent
> Diameter messages and this is going to make it harder.
> In retrospect, we probably should have been more
> strict with respect to identification in RFC 3576,
> such as requiring the Session-Id as a unique identifier.
[FA] As per our e-mail discussions, we agreed to remove this. So, it
was removed.
>
> Section 3
>
> 0 0 0-1 0 0 101 Error-Cause
>
> This would seem to be updating RFC 3579 and RFC 3576. Please
> delete this
> line.
>
[FA] Removed.
> Section 4
>
> " In deployments with both RADIUS and Diameter interworking, a
> translation agent will be deployed and operate in accordance to the
> NASREQ specification."
>
> Why is translation required? Shouldn't Diameter just define
> an identical
> attribute with the same Type value? And isn't CUI used in applications
> other than NASREQ, such as EAP?
>
[FA] See your point. Maybe we should just say:
"Diameter needs to define an identical attribute with the same Type
value." but which Diameter application??
> Section 5.2
>
> " This document instructs IANA to assign a new Error-Cause attribute
> [RFC3576],"
>
> Since the attribute already exists, I think you want a new Error-Cause
> value.
>
[FA]
"This document instructs IANA to assign a new value for Error-Cause
attribute [RFC3576], ..."
> Section 6
>
> " The CUI attribute must be protected against Man-in-the-Middle
> attacks. The CUI appears in Access-Accept and Accounting-Requests
> packets and is protected by the mechanisms that are defined for
> RADIUS [RFC2865] and [RFC2866]. Therefore there are no additional
> security considerations beyond those already identified in
> [RFC2865]
> and [RFC2866].
>
> Message-Authenticator(80) and Event-Timestamp(55) can be used to
> further protect against Man-in-the-middle attacks.
>
> It is strongly recommended that the CUI form used is such that the
> real user identity is not revealed. Furthermore, where a reference
> is used to a real user identity, the binding lifetime of that
> reference to the real user be kept as short as possible."
>
> I think you really mean that you would like to protect
> RADIUS packets including CUI against modification. Even
> though the draft prohibits modification of the CUI attribute
> by proxies, there is no way to prevent this, really.
>
> Message-Authenticator and Event-Timestamp attributes don't
> protect against man-in-the-middle (e.g. rogue proxies), they
> protect against modification and replay, respectively.
>
[FA] Okay, how about the revised text for the security section, as
below?
"
It is strongly recommended that the CUI form used is such that the real
user identity is not revealed. Furthermore, where a reference is used
to a real user identity, the binding lifetime of that reference to the
real user be kept as short as possible.
The RADIUS entities (RADIUS proxies and clients) outside the home
network MUST NOT modify the CUI. However, there is no way to detect or
prevent this.
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.
"
Please note that the last paragraph will change once we decide on using
capabilities 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/>
>
///---------------------------------------------
/// Issue 46
///---------------------------------------------
Based on our discussion so far, we have agreed to make the following
clarification on the use-case currently included in the document.
"
The CUI attribute serves as an alias to the user's real identity,
representing a chargeable identity as defined and provided by the home
network as a supplemental or alternative information to User-Name(1).
Typically the CUI represents the identity of the actual user but it may
also indicate other chargeable identities such as a group of users.
"
To best of my knowledge, there hasn't been any other use-cases proposed
to the list. We are planning to submit an update this week -- please
let us know if you have any new use-cases in mind.
BR,
Farid
On Sun, 16 Jan 2005, Adrangi, Farid wrote:
> Background:
> ===========
> The CUI document define a new RADIUS attribute called a CUI. The CUI
> functions as an handle or an alias to a user identity especially when
> the more traditional user identity attributes (username) do not convey
> the user identity. The draft cites one example when this happens
mainly
> EAP methods that hide that hide the identity.
>
> As per the document, the CUI is assigned a value by the home network
so
> that entities outside the home network, can have a handle to the user
to
> fulfill certain business scenarios. The document cites two cases: 1)
> when an intermediary requires to ensure that a user is only logged in
> once; and 2) For the purpose of billing mediation.
>
> To function as a handle to the user identity, it is suffice that the
CUI
> which is of type string contain an opaque value that is generated by
the
> home network. This value is an assertion by the home network that
> represents a unique user in their network. The only operation that is
> reasonably allowed to be performed by none home network entities on
this
> attribute therefore is a binary comparison.
>
> Are there other use-cases?
> =========================-
>
> As instructed by David Nelson we are seeking any other use-case
> scenarios that would demonstrate the need to change the content of the
> CUI, that is would require non-opaqueness; Or ones that would require
> semantic changes to the current document. We are not looking for use
> cases that will further support the current CUI document.
>
> If there are such use cases, can you please respond with: "[CUI
USECASE]
> some title" on the list. We will look for consensus to support this
> scenario.
>
> BR,
> Farid
>
--
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/>