Subject: [Gen-art] GenART review of draft-ietf-radext-chargeable-user-id-05.txt

From: [email-masked]
Date: Thu, 29 Sep 2005 19:20:34 -0400

Background for those who may be unaware of GenART:

GenART is the Area Review Team for the General Area of the IETF.
We advise the General Area Director (i.e. the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected
as the GenART member to review this document.  Below is my review,
which was written specifically with an eye to the GenART process, but
since I believe that it will be useful to have these comments more
widely distributed, others outside the GenART group are included.

This review was performed as part of IETF Last Call.

Review criteria for WG submissions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"

This draft is on the right track but has open issues, described in the
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.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art