Subject: Question on the Class attribute

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Dec 2007 11:04:28 -0800

Hello,

I had a question on the Class attribute [RFC 2865]. What should
the RADIUS server do if the Class in the Access Accept message
that it sent does not match with the Accounting Request message
that comes later?

RFC 2865 does say this attribute should never be modified by the
client. But I think the server behavior should still be specified
in case there is a mismatch. Is there any document that talks
about this?

Thanks in advance
Vijay

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 18 Dec 2007 09:44:37 -0500

> that it sent does not match with the Accounting Request message

Given that the RADIUS Accounting Server may be completely independent of 
the RADIUS Server, how would a RADIUS Accounting Server, in the most 
general case, be able to tell that the content of the Class attribute 
had been modified?  What session identifier information from other 
RADIUS attributes would it use to make that determination?

In the special case where the RADIUS Accounting Server is tightly 
coupled with the RADIUS Server and has a priori knowledge of sessions 
that the RADIUS Server has authorized, and therefore the intended value 
of the Class attribute, it might be possible to take some action.  In 
these special cases it is not entirely clear what value exists in the 
Class attribute.

Could you elaborate on a particular use case that exemplifies your concerns?

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Dec 2007 10:25:22 -0800

Hi David,

> RADIUS attributes would it use to make that determination?

It appears to me that RFC 2865 requires the class attribute, if
used, to be the same in the Access Accept and the Accounting
Request. I agree with you that if the Accounting Request goes to
a different server from the one that sent the Access Accept
message, this matching does not make sense. The use of this
attribute also may not make sense.

> these special cases it is not entirely clear what value exists in the 

I have no idea either.

> Could you elaborate on a particular use case that exemplifies your 

Our AAA server does not implement this attribute right now. We
were asked to. I am trying to figure out what this attribute is
about, where it is commonly used, etc... However, it looks like
the RADIUS AAA server behavior when the value in the Class
attribute in the Access Accept and Accounting Request does not
match is unspecified.

Vijay

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 18 Dec 2007 13:39:02 -0500

Vijay Devarapalli writes...

> Request.

It requires that the RADIUS client (NAS or proxy) not change the content of
Class, and that it be passed intact in the Accounting-Request messages.
Class is a "cookie" between the RADIUS Server and the RADIUS Accounting
server, much as State is a "cookie" between the RADIUS Server (e.g.
Access-Challenge message) and the RADIUS Server (e.g. Access-Request
message).

> about, where it is commonly used, etc...

It is used to "bind" sessions, as authorized by a RADIUS Server, to
accounting records, as logged on a RADIUS Accounting Server.

> However, it looks like the RADIUS AAA server behavior when the 
> value in the Class attribute in the Access Accept and Accounting
> Request does not match is unspecified.

That is correct, primarily because in the most general case there is no way
for the RADIUS Accounting Server to perform the "does it match" check.  It
takes the correct handling of the Class attribute by the NAS and by proxies
on faith, as that behavior is specified in RFC 2865.

There may be ways to detect broken behavior around the handling of Class
attributes by means of manual inspection of the server records.

There may be ways to automate the Class checking in the special case of a
tightly bound RADIUS Server and RADIUS Accounting Server, but that is beyond
the scope of RFC 2865 or RFC 2866.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Dec 2007 11:58:00 -0800

> It appears to me that RFC 2865 requires the class attribute, if> used, to be the same in the Access Accept and the Accounting> Request. I agree with you that if the Accounting Request goes to> a different server from the one that sent the Access Accept> message, this matching does not make sense. The use of this> attribute also may not make sense.
The Class attribute is designed to allow the RADIUS authentication server
to provide information to be placed within accounting records.  This is 
typically most useful in situations where the accounting server may not
have access to all the information which the authentication server has
access to -- because if it did, why would the Class attribute be needed at all? 
 
Accounting records need not even be handled by the same administrative domain 
(let alone the same RADIUS authentication server).  So the Class attribute does not
assume that the RADIUS authentication server and accounting server are the
same entity.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Dec 2007 15:14:16 -0800

Got it. Thanks for the responses.

Vijay