[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
Section 1.1
The first two paragraphs appear like they belong better in Section 1.
"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...."
"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.
"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.
" 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
"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?
" 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.
" 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.
" 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.
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.
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?
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.
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.
--
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/>