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

From: "Nelson, David" <[email-masked]>
Date: Thu, 6 Oct 2005 12:01:27 -0400

Avi Lior writes...

> Message-Authenticator is not required in Access-Accept.

Except, of course, for any RADIUS PDU containing the EAP-Message
attribute (RFC3579].

> Access-Accept already provides integrity protection and including
> Message-Authenticator as a MUST will confuse people.

The Authenticator header field was considered a relatively weak
construct, hence the introduction of the Message-Authenticator
attribute.  I will note, however, that each of these forms of message
integrity has hop-by-hop scope, i.e. is keyed by the hop-by-hop RADIUS
shared secret.  This precludes the Message-Authenticator from protecting
against illicit or inappropriate behavior on the part of RADIUS proxies.

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

It is true that unauthorized message alteration by RADIUS proxies cannot
be detected.

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

The existing packet integrity protection mentioned in the second
sentence is effective only for MITM attacks *not* conducted within a
RADIUS proxy.

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.

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 6 Oct 2005 09:10:35 -0700 (PDT)

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