[ietf78-tech] Note to Russ and Ray about admission control

[Jim Martin]

Gentlepeople,
	Here's the note I sent to Russ & Ray just now outlining our plan. Hopefully I got it all right!

	- Jim

----

Gentlemen,
	I think we finally have the black box definition of how the admission control scheme in Maastricht will work. I say black box only because there are a few implementation details we're still working on, but we believe the user experience and data path behavior is now set. Many thanks to the IETF78 NOC team on this, and Randy in particular for pushing this to resolution.

	- Jim


Admission Control Credentials
------------------------------------------
	To gain access to the IETF network, all users will need to provide access credentials. The primary source of these credentials will be the registration ID, found in their registration web page, in the response email, on their  receipt, and on the back of their badge. The Registration ID will act as the username, with a fixed string password (eg, "IETF"). This fixed string password will be the same for all attendees.

	If an attendee is uncomfortable using their Registration ID, for whatever reason, there will be a supply of completely anonymous RegID/Password pairs on paper slips available at the help desk and registration desks. The attendee will simply be asked to show a badge, to ensure they're legitimately an attendee, and will be provided a slip.

	Each set of credentials will allow up to 3 separate MACs on the network, to allow attendees to use the same credential for their laptop, phone, or other devices. It's limited to 3 to prevent the leak of any one set of credentials from undermining the entire system. 


Gaining Access to the Network
------------------------------------------
	The primary mechanism to gain access to the network will be by using the "ietf.1x" and "ietf-a.1x" SSIDs. These will be configured with WPA1 and WPA2 Enterprise. The user will provide their credentials to their local supplicant which will authenticate them to the network. 

	For the users that cannot do WPA Enterprise, there is an alternative access mechanism via a captive portal. To use this portal, a user will associate with "ietf-portal" or "ietf-a-portal".  Upon initial connection, Internet connectivity will be blocked. Once the user browses to any site, they will be redirected to a portal page where they can enter their credentials. Once the credentials are validated, their MAC will have unrestricted access to the network for some period of time (likely to be one day, or perhaps the whole week).  The portal page will also have links to the internal wiki with help information and an ability to lodge trouble tickets, even before authenticated.

Fallback Plan
------------------
	Implementing this plan in Maastricht is important, but obviously not without risk. The 802.1X based access mechanisms are well tested at previous meetings and are unlikely to be a major risk. The captive portal, however, is more of an unknown. The first step to mitigate this risk will be to push as many people as possible to use the WPA SSIDs, thus reducing the load on the portal machines. If the portals do experience problems, the NOC team will be prepared to re-enable the traditional "ietf and "ietf-a" open SSIDs. This should only be done as a last resort, because in Beijing, this option simply will not exist. If pain is to be had, better to have it when we have a fallback position, rather then when our options are limited. 

Notes
--------

- Note that we're using WPA1 in addition to WPA2, even though it's outdated. The reasons for this are twofold. First, because the goal is to have as large a percentage of the attendees access the network via the WPA mechanism, and allowing the older WPA1 allows more people to do this. Second, since our goal is admission control, not per-session data security, the crypto weakness of WPA1 is immaterial. Anyone who's concerned about data security should simply only use WPA2.

-  For Beijing, we should add redundancy into the Registration ID so one can not just type in an N digit numeric string. Think of something similar to a credit card number with an internal checksum.  This  would mean that the secretariat would need to make this change to the RegID, which would have a clear implementation cost, The details of this should be discussed during this meeting. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3675 bytes
Desc: not available
Url : http://www.daedelus.com/pipermail/ietf78-tech/attachments/20100629/253edda6/attachment.bin