Main Nav

I have read through the most recent docs, not quite grasping:

 

- If we use MS-CHAPv2 w PEAP on our campus, and that's all we want to use, does that exclude us from Eduroam?

 

- If not, what happens when I roam to another campus that uses TLS, or visa versa? The goal is autoconnection, with no reconfig, but is everyone on Eduroam really and truly using the same EAP with no need to reconfigure as you roam campus to campus?

 

Sorry to be thick, I realize a lot of time went in to the documents.

 

 

Lee H. Badman
Network Architect/Wireless TME
ITS, Syracuse University
315.443.3003
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

Lee,

eduroam is EAP agnostic.
All that the roaming does is pass the initial SSL/TLS tunnel to the home institution.
Then in the tunnel, exchanges occur between your device and your home institution
So, as long as your institution does a tunneled EAP, your are done. The visited institution
has nothing to do with oyur EAP -method.

EAP-TTLS, PEAP, EAP-TLS ... all tunneled will work

Philippe

Message from rgc@buffalo.edu

 

OK – one more question – We currently handling security reports regarding abuse on our wireless network by looking up the IP/User and then pushing the user account into a “deact” group and filtering for that on the radius server. This cuts off the users network access without affecting their ability to check email and it can be automated on the operational side.

 

Has anyone instituted a filter on their Eduroam realm that could disable user accounts if they are reported for abuse?  What is the policy on this – can we do that?

 

-----------------------------------

Robert G Colantuoni

Senior Programmer Analyst

CIT - Network and Classroom Services

SUNY Buffalo

rgc@buffalo.edu

716.645.3552

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hanset, Philippe C
Sent: Tuesday, November 13, 2012 10:02 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam technical questions

 

Lee,

 

eduroam is EAP agnostic.

All that the roaming does is pass the initial SSL/TLS tunnel to the home institution.

Then in the tunnel, exchanges occur between your device and your home institution

So, as long as your institution does a tunneled EAP, your are done. The visited institution

has nothing to do with oyur EAP -method.

 

EAP-TTLS, PEAP, EAP-TLS ... all tunneled will work

 

Philippe

 

Thanks, Phillipe-

 

I'm talking more from supplicant config side. So we use Xpressconnect to configure our supplicants to only use MS-CHAPv2 /PEAP while disabling the other EAP types, and in RADIUS only have this single EAP type enabled. So if our Eduraom SSID required this EAP type, and someone showed up and hit our EDUROAAM with their supplicant configured for EAP-TLS for EDUROAM, a reconfiguration would be required, no? Or am I really missing something important?

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Hanset, Philippe C [phanset@UTK.EDU]
Sent: Tuesday, November 13, 2012 10:01 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam technical questions

Lee,

eduroam is EAP agnostic.
All that the roaming does is pass the initial SSL/TLS tunnel to the home institution.
Then in the tunnel, exchanges occur between your device and your home institution
So, as long as your institution does a tunneled EAP, your are done. The visited institution
has nothing to do with oyur EAP -method.

EAP-TTLS, PEAP, EAP-TLS ... all tunneled will work

Philippe

Lee,

Your campus only terminates EAP sessions for YOUR users.
For visitors, you take the initial TLS negotiation (with the outer tunnel identity e.g. lhbadman@syr.edu, or anonymous@syr.edu, or @syr.edu ) and you pass it to the top level.
You never deal with the EAP-type for visitors.
In your RADIUS server you basically have a switch: pass to top level OR terminate locally.
Take a look at some config examples: http://www.eduroamus.org/radius_configuration

Philippe


Robert,

You are, of course, allowed to deactivate users that are reported for abuse.
This is your institution's network!

Philippe


Ah. You clever fella. 

Thanks for turning on the light.

Lee H. Badman
Network Architect/Wireless TME
ITS, Syracuse University
315.443.3003
From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Hanset, Philippe C [phanset@UTK.EDU]
Sent: Tuesday, November 13, 2012 10:48 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eduroam technical questions

Lee,

Your campus only terminates EAP sessions for YOUR users.
For visitors, you take the initial TLS negotiation (with the outer tunnel identity e.g. lhbadman@syr.edu, or anonymous@syr.edu, or @syr.edu ) and you pass it to the top level.
You never deal with the EAP-type for visitors.
In your RADIUS server you basically have a switch: pass to top level OR terminate locally.
Take a look at some config examples: http://www.eduroamus.org/radius_configuration

Philippe


Message from a.cudbardb@freeradius.org

The problem comes in implementing the ban. Some institutions allow an anonymous outer identity for the EAP tunnel, which, so long as it contains enough information for routing can contain an arbitrary user id. You ban one and the user can just change it and still get access. You never get to see the inner id unless the homeserver has been configured to send it back in the Access-Accept. The best solution is to contact the home institution directly and get their guys to ban the user. This will be easier once more institutions have adopted CUI as then there'll be a definitive linking value between a user and a session. Even without CUI it should still be possible to figure out the inner ID using timestamps and attributes included in the authentication request(s), it's just harder to automate the process. If you're using FreeRADIUS you might want to take a look at the example CUI configurations, and implement them at the same time as the your eduroam service. -Arran > Ah. You clever fella. > > Thanks for turning on the light. > > Lee H. Badman > Network Architect/Wireless TME > ITS, Syracuse University > 315.443.3003 > From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Hanset, Philippe C [phanset@UTK.EDU] > Sent: Tuesday, November 13, 2012 10:48 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Eduroam technical questions > > Lee, > > Your campus only terminates EAP sessions for YOUR users. > For visitors, you take the initial TLS negotiation (with the outer tunnel identity e.g. lhbadman@syr.edu, or anonymous@syr.edu, or @syr.edu ) and you pass it to the top level. > You never deal with the EAP-type for visitors. > In your RADIUS server you basically have a switch: pass to top level OR terminate locally. > Take a look at some config examples: http://www.eduroamus.org/radius_configuration > > Philippe > > >
Message from craigsimons@sfu.ca

Our approach is to block MAC addresses of banned machines directly on the switch port using vendor specific features on our switching gear. However, as the Radius requests are still created by your own equipment (which would presumably have MAC address Calling-Station-Id information), you could still reject outer EAP tunnel requests before they are proxied to the user's home institution. - Craig On 2012-11-14, at 12:45 AM, Arran Cudbard-Bell wrote: > The problem comes in implementing the ban. > > Some institutions allow an anonymous outer identity for the EAP tunnel, which, so long as it contains enough information for routing can contain an arbitrary user id. You ban one and the user can just change it and still get access. You never get to see the inner id unless the homeserver has been configured to send it back in the Access-Accept. > > The best solution is to contact the home institution directly and get their guys to ban the user. This will be easier once more institutions have adopted CUI as then there'll be a definitive linking value between a user and a session. Even without CUI it should still be possible to figure out the inner ID using timestamps and attributes included in the authentication request(s), it's just harder to automate the process. > > If you're using FreeRADIUS you might want to take a look at the example CUI configurations, and implement them at the same time as the your eduroam service. > > -Arran > > > >> Ah. You clever fella. >> >> Thanks for turning on the light. >> >> Lee H. Badman >> Network Architect/Wireless TME >> ITS, Syracuse University >> 315.443.3003 >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Hanset, Philippe C [phanset@UTK.EDU] >> Sent: Tuesday, November 13, 2012 10:48 AM >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >> Subject: Re: [WIRELESS-LAN] Eduroam technical questions >> >> Lee, >> >> Your campus only terminates EAP sessions for YOUR users. >> For visitors, you take the initial TLS negotiation (with the outer tunnel identity e.g. lhbadman@syr.edu, or anonymous@syr.edu, or @syr.edu ) and you pass it to the top level. >> You never deal with the EAP-type for visitors. >> In your RADIUS server you basically have a switch: pass to top level OR terminate locally. >> Take a look at some config examples: http://www.eduroamus.org/radius_configuration >> >> Philippe >> >> >>
Can always block MAC on WLAN too. Simple, nuclear, elegant.     -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Simons Sent: Wednesday, November 14, 2012 1:13 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Eduroam technical questions Our approach is to block MAC addresses of banned machines directly on the switch port using vendor specific features on our switching gear. However, as the Radius requests are still created by your own equipment (which would presumably have MAC address Calling-Station-Id information), you could still reject outer EAP tunnel requests before they are proxied to the user's home institution. - Craig On 2012-11-14, at 12:45 AM, Arran Cudbard-Bell wrote: > The problem comes in implementing the ban. > > Some institutions allow an anonymous outer identity for the EAP tunnel, which, so long as it contains enough information for routing can contain an arbitrary user id. You ban one and the user can just change it and still get access. You never get to see the inner id unless the homeserver has been configured to send it back in the Access-Accept. > > The best solution is to contact the home institution directly and get their guys to ban the user. This will be easier once more institutions have adopted CUI as then there'll be a definitive linking value between a user and a session. Even without CUI it should still be possible to figure out the inner ID using timestamps and attributes included in the authentication request(s), it's just harder to automate the process. > > If you're using FreeRADIUS you might want to take a look at the example CUI configurations, and implement them at the same time as the your eduroam service. > > -Arran > > > >> Ah. You clever fella. >> >> Thanks for turning on the light. >> >> Lee H. Badman >> Network Architect/Wireless TME >> ITS, Syracuse University >> 315.443.3003 >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Hanset, Philippe C [phanset@UTK.EDU] >> Sent: Tuesday, November 13, 2012 10:48 AM >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >> Subject: Re: [WIRELESS-LAN] Eduroam technical questions >> >> Lee, >> >> Your campus only terminates EAP sessions for YOUR users. >> For visitors, you take the initial TLS negotiation (with the outer tunnel identity e.g. lhbadman@syr.edu, or anonymous@syr.edu, or @syr.edu ) and you pass it to the top level. >> You never deal with the EAP-type for visitors. >> In your RADIUS server you basically have a switch: pass to top level OR terminate locally. >> Take a look at some config examples: http://www.eduroamus.org/radius_configuration >> >> Philippe >> >> >>
Message from a.cudbardb@freeradius.org

On 14 Nov 2012, at 18:24, Lee H Badman wrote: > Can always block MAC on WLAN too. Simple, nuclear, elegant. > And completely ineffective if the user has any technical skill whatsoever. shinyhead:freeradius-server-master arr2036$ ifconfig en0 en0: flags=8863 mtu 1500 options=2b ether 7c:6d:62:xx:xx:xx shinyhead:freeradius-server-master arr2036$ sudo ifconfig en0 ether 11:22:33:44:55:66 en0: flags=8863 mtu 1500 options=2b ether 11:22:33:44:55:66 media: autoselect (none) status: inactive -Arran > > > > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Simons > Sent: Wednesday, November 14, 2012 1:13 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Eduroam technical questions > > Our approach is to block MAC addresses of banned machines directly on the switch port using vendor specific features on our switching gear. However, as the Radius requests are still created by your own equipment (which would presumably have MAC address Calling-Station-Id information), you could still reject outer EAP tunnel requests before they are proxied to the user's home institution. > > - Craig > > > > On 2012-11-14, at 12:45 AM, Arran Cudbard-Bell wrote: > >> The problem comes in implementing the ban. >> >> Some institutions allow an anonymous outer identity for the EAP tunnel, which, so long as it contains enough information for routing can contain an arbitrary user id. You ban one and the user can just change it and still get access. You never get to see the inner id unless the homeserver has been configured to send it back in the Access-Accept. >> >> The best solution is to contact the home institution directly and get their guys to ban the user. This will be easier once more institutions have adopted CUI as then there'll be a definitive linking value between a user and a session. Even without CUI it should still be possible to figure out the inner ID using timestamps and attributes included in the authentication request(s), it's just harder to automate the process. >> >> If you're using FreeRADIUS you might want to take a look at the example CUI configurations, and implement them at the same time as the your eduroam service. >> >> -Arran >> >> >> >>> Ah. You clever fella. >>> >>> Thanks for turning on the light. >>> >>> Lee H. Badman >>> Network Architect/Wireless TME >>> ITS, Syracuse University >>> 315.443.3003 >>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Hanset, Philippe C [phanset@UTK.EDU] >>> Sent: Tuesday, November 13, 2012 10:48 AM >>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> Subject: Re: [WIRELESS-LAN] Eduroam technical questions >>> >>> Lee, >>> >>> Your campus only terminates EAP sessions for YOUR users. >>> For visitors, you take the initial TLS negotiation (with the outer tunnel identity e.g. lhbadman@syr.edu, or anonymous@syr.edu, or @syr.edu ) and you pass it to the top level. >>> You never deal with the EAP-type for visitors. >>> In your RADIUS server you basically have a switch: pass to top level OR terminate locally. >>> Take a look at some config examples: http://www.eduroamus.org/radius_configuration >>> >>> Philippe >>> >>> >>>
On 11/14/2012 5:55 PM, Arran Cudbard-Bell wrote: > On 14 Nov 2012, at 18:24, Lee H Badman wrote: > >> Can always block MAC on WLAN too. Simple, nuclear, elegant. >> > > And completely ineffective if the user has any technical skill whatsoever. To be fair, most users don't. The last time that I saw a user who actually forced the MAC address of device was from such a deep state of confusion that he had typed his assigned IP address into the MAC address field of his adapter properties. By sheer coincidence, he had been assigned an IP with the right number of digits. Needless to say, he had other issues that needed correcting... > shinyhead:freeradius-server-master arr2036$ ifconfig en0 > en0: flags=8863 mtu 1500 > options=2b > ether 7c:6d:62:xx:xx:xx > > shinyhead:freeradius-server-master arr2036$ sudo ifconfig en0 ether 11:22:33:44:55:66 > > en0: flags=8863 mtu 1500 > options=2b > ether 11:22:33:44:55:66 > media: autoselect (none) > status: inactive > > -Arran -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that Manager of Network Operations | is simple, elegant, and wrong. Worcester Polytechnic Institute | - HL Mencken ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.