(RADIATOR) 802.1X Authenticators - Common Accounting Problems

[Terry Simons]

Hi Jon,

On Jun 10, 2004, at 9:16 AM, Jonathan Moore wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Terry,
>
> We are in the process of trying to roll out 802.1x in a wired setting 
> here at the University of Pennsylvania. I think your accounting 
> requirements document is a good start.

Excellent.  :-)

>
> I would add the "NAS-Port" attribute to your list; believe it or not, 
> our current switch network does not include this attribute in its 
> RADIUS accounting records, which means that we can only see that a 
> user logged in through a switch, but not which port.

Yeah, I have seen this as well, but our most pressing issues have been 
the Acct-Session-Id and Calling/Called-Station-Id attributes.  Thanks 
for the reminder!

>
> If you would like, I could write up a paragraph describing the 
> NAS-Port requirements so you can fold it in.

How's this?

NAS-Port and NAS-Port-Type

Some vendors do not follow RFC 2866 regarding the NAS-Port and 
NAS-Port-Type attributes.  The RFC clearly states: "It SHOULD contain a 
NAS-Port or NAS-Port-Type attribute or both unless the service does not 
involve a port or the NAS does not distinguish among its ports."  These 
two attributes are important for network diagnostics for the following 
reasons:

1) For organizations that deploy both wired and wireless networks, the 
NAS-Port-Type attribute is needed to determine if a given user is 
authenticated via Ethernet , or 802.11 wireless.

2) For both wired and wireless authentication, but especially wired, it 
is sometimes either necessary (definitely in the case of wired), or 
useful to know what port a user is authenticated to.  In a wired 
environment, this is a necessary attribute for security reasons 
(determining which port a known malicious user is currently connected 
to, for instance).  The attribute can also be used for statistical 
purposes to determine which ports are most utilized.  In a wireless 
environment, for instance, it is helpful to determine which wireless 
protocol a given user is connected with.  For instance, a wireless 
access point could account a different NAS-Port for each of its 
802.11b, 802.11g, or 802.11a users, which is helpful statistically.

>
> Also, I should also mention the Internet2 SALSA-NetAuth working group 
> which is going on:
> http://security.internet2.edu/netauth/
> They have bi-weekly conference calls, and at the last call someone 
> mentioned "hey, we should get one of the University of Utah folks to 
> sit in on this." So consider yourself invited, or pass the invitation 
> along to the appropriate person. I'm sure we'd love to have the 
> benefit of your 802.1x experience.

Very cool!

I'm probably a good candidate for this, since I do most of the Client 
testing for the U of U (Meetinghouse Win/Mac/PocketPC, SecureW2, 
Apple's Panther Client, Xsupplicant, etc... :)  I'm also probably the 
most versed with our Radiator setup and understand the little tweaky 
things that we have going.

What do I need to do to get involved with this?

>
> For example, I think your requirements document could easily be 
> fleshed out to a full set of attribute requirements via the working 
> group, so we could then use to apply pressure to our respective 
> vendors. :)

The more the merrier!

I'm considered the University of Utah bulldog when it comes to 802.1X 
testing, so bring it on.  :-)

Thanks for the feedback... it's nice to actually get some!

- Terry

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.