Draft:  draft-ietf-radext-chargeable-user-id-05.txt
Reviewer: Black_David@emc.com
Review Date: Thursday 9/29/2005 6:21 PM
LC Date: Sept 29, 2005

Summary: This draft is on the right track but has open issues, 
described in the review.

Review:
--------
I'm not a RADIUS expert, so I trust that the RADIUS details are correct.

The open issues are security-related around insertion or modification
of a CUI.  They appear to be relatively easy to address.

The last paragraph of the Security Considerations section
describes a denial-of-service attack based on removal of CUI,
but I didn't see any discussion of insertion or modification.
The security considerations section should definitely discuss
modification of CUI, at that may enable theft-of-service attacks
(e.g., the attacker observes a successful CUI and reuses it for the
access request for her traffic, or the attacker uses a bogus CUI
in the Access-Accept preventing accounting reconciliation).  The
countermeasure is the same as for removal - use a
Message-Authenticator, which also covers insertion by an attacker
(and that should be mentioned also).

In the absence of Message-Authenticator, it looks like it may be
possible for an attacker to cause mischief by inserting a CUI in
an Access-Accept for which the corresponding Access-Request did
not contain a CUI.  Section 2.1 says that a RADIUS server SHOULD
NOT send CUI if it didn't receive it, but doesn't say what a
client should do with an unexpected received CUI, and (perhaps
worse), requires a RADIUS client that supports CUI to include a
received CUI in certain RADIUS accounting messages even if it
didn't ask for CUI.  I think Section 2.1 needs to discuss how a
RADIUS client should treat an unexpected CUI (client did not ask
for CUI, but server appears to have sent it, despite the SHOULD
NOT) - it should be fine to say that the RADIUS client SHOULD
ignore an unexpected CUI.