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

From: [email-masked]
Date: Wed, 5 Oct 2005 07:25:07 +0300

Hi all,

I think that David Black's comments is reasonable.  We will add this as
a
last call issue and address it when we revise the document.  I will
propose
more exact text on the RADext mailing list & CC: David.

thanks for the review,
John 

>-----Original Message-----
>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 30 September, 2005 02:21
>To: [email-masked]; [email-masked]; 
>[email-masked]; Loughney John 
>(Nokia-NRC/Helsinki); [email-masked]
>Cc: [email-masked]; Kessens David (Nokia-NET/MtView); 
>[email-masked]; [email-masked]
>Subject: GenART review of draft-ietf-radext-chargeable-user-id-05.txt
>
>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

---

From: David Kessens <[email-masked]>
Date: Tue, 4 Oct 2005 21:49:29 -0700

John,

On Tue, Oct 04, 2005 at 09:25:07PM -0700, Loughney John (Nokia-NRC/Helsinki) wrote:
> 
> I think that David Black's comments is reasonable.  We will add this
> as a last call issue and address it when we revise the document. I
> will propose more exact text on the RADext mailing list & CC: David.

Can you be a bit more specific about what you mean with 'when we revise the
document' as the last call is finished now and I would like to bring
this document to the IESG as soon as possible ?

Thanks,

David Kessens
---