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

From: "Adrangi, Farid" <[email-masked]>
Date: Wed, 5 Oct 2005 00:47:11 -0700

Hi David, all
Sorry for a late reply.  Please see my comments inline.
--Farid

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, September 29, 2005 4:21 PM
> To: Adrangi, Farid; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: GenART review of draft-ietf-radext-chargeable-user-id-05.txt
> 
> 
> 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).
> 

I agree.  We can address this concern by modifying the middle paragraph
in the Security section.

Current Text:
"
   The RADIUS entities (RADIUS proxies and clients) outside the home
   netowrk MUST NOT modify the CUI.  However, there is no way to detect
   or prevent this.
"

Proposed Text:
"
The RADIUS entities (RADIUS proxies and clients) outside the home
network MUST NOT modify the CUI.  However, there is no way to detect or
prevent this.  A man-in-the-middle may try to insert, modify or remove
the CUI, therefore the Message-Authenticator attribute(80) MUST be used
to protect all Access-Accept packets containing the CUI attribute.
"

> 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.
> 

Currently as written the draft allows a Server to insert a CUI even if
the NAS did not request one.  As you point out if the NAS receives an
unexpected CUI it will include it in the Accounting messages.  This is
not a security problem.

It is only a security problem if a Man in the middle inserts a bogus CUI
in the Access-Accept. RADIUS already provides integrity protection for
the Access Accept messages.  Note that it is possible for a Proxy to
insert a CUI but proxies are trust worth in AAA.

Taking the above paragraph and modifying it further should cover your
concern w.r.t inserting a CUI or removing the CUI.

"
The RADIUS entities (RADIUS proxies and clients) outside the home
network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
However, there is no way to detect or prevent this.  A man-in-the-middle
may try to insert, modify or remove the CUI, therefore the
Message-Authenticator attribute(80) MUST be used to protect all
Access-Accept packets containing the CUI attribute.
"

Will this work for you?

> 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: "Adrangi, Farid" <[email-masked]>
Date: Wed, 5 Oct 2005 00:54:31 -0700

Hi David, 
The last call is finished - you are right!  Please see my other e-mail
in response to your comments w/ proposed text.
Thanks a bunch!
Farid

> From: David Kessens [mailto:[email-masked]] 
> Sent: Tuesday, October 04, 2005 9:49 PM
> To: Loughney John (Nokia-NRC/Helsinki)
> Cc: [email-masked]; Adrangi, Farid; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: GenART review of 
> draft-ietf-radext-chargeable-user-id-05.txt
> 
> 
> 
> 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
> ---
>

---

From: "Adrangi, Farid" <[email-masked]>
Date: Wed, 5 Oct 2005 01:02:56 -0700

Sorry I just made a minor editorial change in the proposed text ...

Hi David, all

Current Text:
"

Proposed Text:
"
to protect all Access-Accept packets containing a CUI attribute.
"

"
Access-Accept packets containing a CUI attribute.
"

Will this work for you?

---

From: [email-masked]
Date: Thu, 6 Oct 2005 02:44:43 -0400

Farid,

> Access-Accept packets containing a CUI attribute.

Did you really want to say "MUST"?  That's ok, but "SHOULD be used to
protect all ... attribute when such threats are of concern" would be
sufficient and would provide an exception for RADIUS on suitably
isolated/controlled networks.  I'm particularly concerned about networks
where the RADIUS keying material needed to use Message-Authenticator has
not been set up due to the isolation/control being considered sufficient
to protect the RADIUS traffic.

It would also be a good idea to add a sentence explaining that theft-of-
service is a possible consequence of CUI insertion or modification.

> unexpected CUI it will include it in the Accounting messages.  This is

And more to the point, this appears to be an intended feature in that
it prohibits a NAS from second-guessing a Server's decision to return 
a CUI.  This is not as clear as it could be, so after the following text:

   If the CUI was included in an Access-Accept packet, RADIUS clients
   supporting the CUI attribute MUST ensure that the CUI attribute
   appears in the RADIUS Accounting-Request (Start, Interim, and Stop).

I would add the sentence:

   This requirement applies regardless of whether the RADIUS client
   requested the CUI attribute.

Thanks,
--David

> From: Adrangi, Farid [mailto:[email-masked]] 
> Sent: Wednesday, October 05, 2005 4:03 AM
> To: Black, David; [email-masked]; 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: GenART review of 
> > Subject: GenART review of

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 6 Oct 2005 11:39:18 -0400

David and Farid,

Message-Authenticator is not required in Access-Accept.  Access-Accept
already provides integrity protection and including
Message-Authenticator as a MUST will confuse people.  So I think that
the following is better (Note I don't mention Message-Authenticator is
the Access-Accept) If its there its better:

"The RADIUS entities (RADIUS proxies and clients) outside the home 
network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
However, there is no way to detect or prevent this.  

Attempting theft of service, A man-in-the-middle may try to insert,
modify or remove the CUI in the Access-Accept packets and Accounting
packets.  However, RADIUS Access-Accept and Accounting packets already
provide integrity protection."

> Sent: Thursday, October 06, 2005 2:45 AM
> To: [email-masked]; Avi Lior; 
> > However, there is no way to detect or prevent this.  A 
> > man-in-the-middle may try to insert, modify or remove the CUI, 
> > therefore the Message-Authenticator attribute(80) MUST be used to 
> > protect all Access-Accept packets containing a CUI attribute.
> > "
> > 
> > Will this work for you?
> 
> Did you really want to say "MUST"?  That's ok, but "SHOULD be 
> used to protect all ... attribute when such threats are of 
> concern" would be sufficient and would provide an exception 
> for RADIUS on suitably isolated/controlled networks.  I'm 
> particularly concerned about networks where the RADIUS keying 
> material needed to use Message-Authenticator has not been set 
> up due to the isolation/control being considered sufficient 
> It would also be a good idea to add a sentence explaining 
> that theft-of- service is a possible consequence of CUI 
> insertion or modification.
> 
> And more to the point, this appears to be an intended feature 
> in that it prohibits a NAS from second-guessing a Server's 
> decision to return a CUI.  This is not as clear as it could 
> be, so after the following text:
> 
> > > The open issues are security-related around insertion or 
> > > modification of a CUI.  They appear to be relatively easy 
> to address.
> > > 
> describes 
> > > a denial-of-service attack based on removal of CUI, but I 
> didn't see 
> > > any discussion of insertion or modification.
> > > access request for her traffic, or the attacker uses a 
> bogus CUI in 
> > > the Access-Accept preventing accounting reconciliation).  The 
> > I agree.  We can address this concern by modifying the middle 
> > paragraph in the Security section.
> > 
> > Current Text:
> > "
> > network MUST NOT modify the CUI.  However, there is no way 
> to detect 
> > or prevent this.  A man-in-the-middle may try to insert, modify or 
> > remove the CUI, therefore the Message-Authenticator 
> attribute(80) MUST 
> > be used to protect all Access-Accept packets containing a 
> CUI attribute.
> > "
> > 
> > > 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.
> > > 
> > 
> > It is only a security problem if a Man in the middle 
> inserts a bogus 
> > CUI in the Access-Accept. RADIUS already provides integrity 
> protection 
> > for the Access Accept messages.  Note that it is possible 
> for a Proxy 
> > to insert a CUI but proxies are trust worth in AAA.
> > 
> > However, there is no way to detect or prevent this.  A 
> > man-in-the-middle may try to insert, modify or remove the CUI, 
> > therefore the Message-Authenticator attribute(80) MUST be used to 
> > protect all Access-Accept packets containing a CUI attribute.
> > "
> > 
> > Will this work for you?
> > 
> > > Thanks,
> > > --David

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 6 Oct 2005 14:23:00 -0400

I agree with Bernard this is why I played down the
Message-Authenticator.  If its there it is a bonus if not its not so
what. 

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, October 06, 2005 12:11 PM
> To: Nelson, David
> Cc: Avi Lior; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > Adding Message-Authenticator to *any* RADIUS PDU is probably a Good 
> > Thing (tm).  Whether is should be made a MUST for packets 
> containing 
> > the CUI attribute is open to debate, I suppose.
> 
> I don't see why the CUI attribute should be treated 
> specially;  it is no different than User-Name or Class 
> attributes in this regard. 
> 
> In any case, my understanding is that CUI will typically only 
> be used in situations in which Message-Authenticator is 
> already required (e.g. EAP), so it's somewhat of a moot point.  
> 
> Rather than attempting to update RFC 2865 (which does not 
> require Message-Authenticator), I'd let sleeping dogs lie.
>

---

From: "Adrangi, Farid" <[email-masked]>
Date: Thu, 6 Oct 2005 12:14:37 -0700

Hi David, all
Thanks you all for your feedback & input.  Do we agree with the
following resolution to David's review comments?

1) Section 2.1

Current Text:
"

Propsed Text:
"

2) Section 6.0

Current Text:: (Section 6)
"
   The RADIUS entities (RADIUS proxies and clients) outside the home
   netowrk MUST NOT modify the CUI.  However, there is no way to detect
   or prevent this.
"

Proposed Text::

Thanks,
Farid

> From: Avi Lior [mailto:[email-masked]] 
> Sent: Thursday, October 06, 2005 11:23 AM
> To: Bernard Aboba; Nelson, David

---

From: [email-masked]
Date: Fri, 7 Oct 2005 11:17:40 -0400

This is ok.  Mentioning the use of Message-Authenticator
as a means of providing integrity protection in Section 6
would be better, but I'll defer to the RADIUS experts on
whether that's appropriate vs. opens a can of worms that's
best left closed.

Thanks,
--David

> Sent: Thursday, October 06, 2005 3:15 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Avi Lior; Bernard 
> Aboba; Nelson, David

---

From: "Adrangi, Farid" <[email-masked]>
Date: Fri, 7 Oct 2005 09:56:49 -0700

Thanks David.  If no objections form other folks, I will update the
draft and submit.
Thanks,
Farid

> Sent: Friday, October 07, 2005 8:18 AM
> To: Adrangi, Farid
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]

---

From: [email-masked]
Date: Mon, 10 Oct 2005 13:51:07 +0300

I'm OK with the proposed text.

John 

>From: ext Adrangi, Farid [mailto:[email-masked]] 
>Sent: 07 October, 2005 19:57
>To: [email-masked]
>Cc: [email-masked]; Loughney John 
>(Nokia-NRC/Helsinki); [email-masked]; Kessens David 
>(Nokia-NET/MtView); [email-masked]; 
>[email-masked]; [email-masked]
>Thanks David.  If no objections form other folks, I will 
>update the draft and submit.
>Thanks,
>Farid
>
>[email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]
>> This is ok.  Mentioning the use of Message-Authenticator as 
>a means of 
>> providing integrity protection in Section 6 would be better, 
>but I'll 
>> defer to the RADIUS experts on whether that's appropriate 
>vs. opens a 
>> can of worms that's best left closed.
>> 
>> Thanks,
>> --David
>> > [email-masked]; [email-masked]; Avi Lior; 
>Bernard Aboba; 
>> > Nelson, David