[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE:Issue 52: Review of CUI-01
Title: Message
Hi
Bernard,
Thanks for your
comments/feedbacks/corrections. I agree with most of your comments
-- we will incorporate them into the next version. Please see
my comments inline.
BR,
Farid
> -----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.
>
Good suggestion. Will do.
> Section 1.1
>
> The first two
paragraphs appear like they belong better in Section 1.
>
Makes sense - Will
move it up.
> "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...."
yes.
>
> "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.
>
Ok.
> "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.
Ok.
>
> " 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
>
I think the second half of the paragraph
addresses the above problem w.r.t decoration and
routing. Maybe we should add an example for
clarification. How about we revise
the paragraph to something like this?
"
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. For example, the EAP peer
may construct the NAI with additional information (e.g., example.com@intermediary.com) to
influence routing of the AAA packet through a preferred intermediary
network. This is rewritten by the intermediary network (i.e.,
"intermediary.com" ) to example.com. As a result, the home
RADIUS server in "example.com" may not even be aware of "intermediary.com" and
therefore sends a User-Name(1) containing CUI (i.e., CUI@example.com) in the Access-Accept to the
NAS. If the NAS uses the User-Name(1) of the received Access-Accept
in Accounting-Request (as recommended by a strong SHOULD in RFC 2865), then the
resulting Accounting-Request would be routed differently than the
Access-Request, which might cause problems. If the NAS uses the
original NAI sent in the Access-Request, then the CUI will not be
included in the Accounting-Request. Furthermore, in some
deployments, 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.
"
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?
Your statement is
correct. And we say that in sectoin 2.1 -- couple of paragraphs
below. but here we are simply stating that the entities outside the home
network MUST NOT modify CUI.
>
> " 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.
>
You are right, so how
about this?
"
RFC 2865 states that A
RADIUS server or client ignore Attributes
with an unknown Type. Therefore, RADIUS client (Proxy or NAS)
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.
I agree. But, there
is no capabilities attribute for RADUS now, and as you know we have a proposal
for capabilities attribute but no progerss yet - we may want to accelerate
this.
>
> " 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.
>
Are you implying that RADIUS has a
session-id -- I wasn't aware of that. I thought Glen Zorn is proposing
this in one of his drafts. Anyhow, I guess you are suggesting to remove
this paragraph - yes?
> 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.
>
Ok.
> 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?
NASREQ does not have this
attribute. Does NASREQ automatically cover new RADIUS attributes?
CUI will not be used in EAP - unless you correct me by describing a use-case for
it.
>
> 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.
Yes, right!
>
> 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.
>
You are right there
is no way to prevent this by design of RADIUS. RADIUS
assumes that the
clients are trusted. Therefore we would n't even attempt to
prevent it.
> 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.
>
RADIUS is not an end to end protocol. It a hop
by hop protocol.
So there is a client and a server and the "man in the
middle" threat is NOT
the client or the server but rather someone that is
observing the traffic.
RADIUS already provides protection for man in the
middle against changing
the Access-Accept. However, not in the
Access-Request but this may not be
important here. Except when the NAS
wants CUI but the man in the middle
deletes that attribute.
Message-Authenticator can be used here.