RE: how eduroam works (was: Re: Admission Control to the IETF 78 and IETF 79 Networks)

[Josh Howlett]

As someone who is involved in eduroam, I'm curious how many people found the 
availability of eduroam at IETF 78 useful.

If you believe that you are eligible to use eduroam - irrespective of whether 
you tried it at IETF 78 - please consider completing the form at the following 
URL (it's only three questions):

https://foodle.feide.no/foodle.php?id=zjn224x1

(Ignore the message about anonymous access).

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

how eduroam works (was: Re: Admission Control to the IETF 78 and IETF 79 Networks)

[Klaas Wierenga]

Hi Phillip,

You can find all you want to know at the website: http://www.eduroam.org,

especially the Service Definition at:

http://www.eduroam.org/downloads/docs/GN2-07-327v2-DS5_1_1-_eduroam_Service_Definition.pdf

you may also want to watch the cartoon at:

http://www.youtube.com/watch?v=TVCmcMZS3uA


In short:

There is a hierarchy of RADIUS proxy-servers (institution, country, 
European/APAC/Americas) that form a web of (transitive) trust.


This RADIUS infrastructure is used to forward EAP requests from the 
visited institution to the home institution of the user, the home 
institution of the user verifies the credentials and sends back an ACK 
or NAK.


When the visited institution receives an ACK from the home institution 
the user gets access.


Users connect using 802.1X with WPA2/AES

Hope this helps,

Klaas Wierenga



> Any chance of a link to specs showing how it is done?

> Might be something that maybe deserves to see wider use.

On Sat, Jul 24, 2010 at 9:19 AM, IETF Chair  wrote:
> > eduroam (education roaming) is the secure, world-wide roaming access
> > service developed for the international research and education
> > community. eduroam allows students, researchers and staff from
> > participating institutions to obtain Internet connectivity across 
campus

> > and when visiting other participating institutions by simply opening
> > their laptop. Since we expect a reasonable attendance at IETF from
> > eduroam-connected sites, IETF participants with an eduroam account
> > configured, should get connected to the wireless network right away 
with

> > their usual credentials.
> >
> > Enjoy,
> > Russ
> >
> > On 6/30/2010 5:55 PM, IETF Chair wrote:
>> >> I am writing to let you know about a change in the IETF meeting 
network.

>> >> At IETF 79 in Beijing, the IETF network will be connected to the open
>> >> Internet with absolutely no filtering.  However, we have agreed 
with our

>> >> hosts that only IETF meeting participants will have access to the
>> >> network.  Following sound engineering practices, we will deploy
>> >> admission control mechanisms as part of the IETF 78 meeting 
network in

>> >> Maastricht to ensure that they are working properly before they are
>> >> mission critical.
>> >>
>> >> I am writing to let you know what to expect in both Maastricht 
and Beijing.

>> >>
>> >>
>> >> ADMISSION CONTROL CREDENTIALS
>> >>
>> >> To gain access to the IETF network, you will need to provide a
>> >> credential. Your primary credential will be your registration ID. 
 You

>> >> can find your registration ID on the registration web page, in the
>> >> response email confirmation you received from the Secretariat, on 
your

>> >> payment receipt, and on the back of your IETF meeting badge.  Your
>> >> Registration ID will be your user name, and it will be used with a
>> >> password that will be provided at a later date.  This same 
password will

>> >> be used by all attendees.
>> >>
>> >> We recognize that IETF 78 registration IDs are very easy to 
guess.  We

>> >> expect to use less easily guessed registration IDs for IETF 79.
>> >>
>> >> If for any reason you are uncomfortable using your Registration ID,
>> >> there will be a supply of completely anonymous Registration 
ID/Password

>> >> pairs on slips of paper available at the help desk and registration
>> >> desk.  You will be asked to show an IETF meeting badge to ensure that
>> >> slips are only provided to registered meeting attendees.
>> >>
>> >> Each set of credentials will allow up to three separate MAC 
addresses on

>> >> the network, allowing attendees to use the same credential for their
>> >> laptop, phone, or other devices.  The limit is to prevent the 
leak of a

>> >> single credential from undermining the entire system.
>> >>
>> >>
>> >> GAINING ACCESS TO THE NETWORK
>> >>
>> >> The primary mechanism to gain access to the wireless network will be
>> >> either the "ietf.1x" or "ietf-a.1x" SSID.  These will be 
configured with
>> >> WPA1 and WPA2 Enterprise.  You simply provide your credentials to 
your

>> >> supplicant software for authentication to the network.  I personally
>> >> encourage you to use WPA2 over WPA1 if your software and hardware
>> >> support both.
>> >>
>> >> If your software does not support WPA Enterprise, you can use the
>> >> captive portal.  To use this portal, associate with either the
>> >> "ietf-portal" or "ietf-a-portal" SSID.  Upon initial connection,
>> >> Internet connectivity will be blocked.  Simply open a browser and 
go to
>> >> any web site, just like many hotel networks, and you will be 
redirected

>> >> to a portal page where you can enter your credentials.  Once the
>> >> credentials are validated, your MAC address will have unrestricted
>> >> access to the network for some period of time.  The portal page will
>> >> also have links to the internal wiki page with helpful information as
>> >> well as a way to create trouble tickets prior to authentication.
>> >>
>> >> If 

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

Any chance of a link to specs showing how it is done?

Might be something that maybe deserves to see wider use.

On Sat, Jul 24, 2010 at 9:19 AM, IETF Chair  wrote:
> eduroam (education roaming) is the secure, world-wide roaming access
> service developed for the international research and education
> community. eduroam allows students, researchers and staff from
> participating institutions to obtain Internet connectivity across campus
> and when visiting other participating institutions by simply opening
> their laptop. Since we expect a reasonable attendance at IETF from
> eduroam-connected sites, IETF participants with an eduroam account
> configured, should get connected to the wireless network right away with
> their usual credentials.
>
> Enjoy,
> Russ
>
> On 6/30/2010 5:55 PM, IETF Chair wrote:
>> I am writing to let you know about a change in the IETF meeting network.
>> At IETF 79 in Beijing, the IETF network will be connected to the open
>> Internet with absolutely no filtering.  However, we have agreed with our
>> hosts that only IETF meeting participants will have access to the
>> network.  Following sound engineering practices, we will deploy
>> admission control mechanisms as part of the IETF 78 meeting network in
>> Maastricht to ensure that they are working properly before they are
>> mission critical.
>>
>> I am writing to let you know what to expect in both Maastricht and Beijing.
>>
>>
>> ADMISSION CONTROL CREDENTIALS
>>
>> To gain access to the IETF network, you will need to provide a
>> credential. Your primary credential will be your registration ID.  You
>> can find your registration ID on the registration web page, in the
>> response email confirmation you received from the Secretariat, on your
>> payment receipt, and on the back of your IETF meeting badge.  Your
>> Registration ID will be your user name, and it will be used with a
>> password that will be provided at a later date.  This same password will
>> be used by all attendees.
>>
>> We recognize that IETF 78 registration IDs are very easy to guess.  We
>> expect to use less easily guessed registration IDs for IETF 79.
>>
>> If for any reason you are uncomfortable using your Registration ID,
>> there will be a supply of completely anonymous Registration ID/Password
>> pairs on slips of paper available at the help desk and registration
>> desk.  You will be asked to show an IETF meeting badge to ensure that
>> slips are only provided to registered meeting attendees.
>>
>> Each set of credentials will allow up to three separate MAC addresses on
>> the network, allowing attendees to use the same credential for their
>> laptop, phone, or other devices.  The limit is to prevent the leak of a
>> single credential from undermining the entire system.
>>
>>
>> GAINING ACCESS TO THE NETWORK
>>
>> The primary mechanism to gain access to the wireless network will be
>> either the "ietf.1x" or "ietf-a.1x" SSID.  These will be configured with
>> WPA1 and WPA2 Enterprise.  You simply provide your credentials to your
>> supplicant software for authentication to the network.  I personally
>> encourage you to use WPA2 over WPA1 if your software and hardware
>> support both.
>>
>> If your software does not support WPA Enterprise, you can use the
>> captive portal.  To use this portal, associate with either the
>> "ietf-portal" or "ietf-a-portal" SSID.  Upon initial connection,
>> Internet connectivity will be blocked.  Simply open a browser and go to
>> any web site, just like many hotel networks, and you will be redirected
>> to a portal page where you can enter your credentials.  Once the
>> credentials are validated, your MAC address will have unrestricted
>> access to the network for some period of time.  The portal page will
>> also have links to the internal wiki page with helpful information as
>> well as a way to create trouble tickets prior to authentication.
>>
>> If your small devices does not support WPA Enterprise and does not have
>> a browser, then you will be able to visit the help desk and register the
>> device MAC address for access to the network.  If you need to register
>> your device, please know the MAC address of your device before you show
>> up at the help desk.
>>
>>
>> FALLBACK PLAN
>>
>> Implementing this plan at IETF 78 in Maastricht is important, but
>> obviously not without risk.  The IEEE 802.1X-based access mechanisms
>> have been well tested at previous meetings, and this mechanism is not
>> likely to be a source of trouble.  The captive portal, however, is a
>> greater unknown.  Please use the WPA SSIDs if at all possible to reduce
>> the load on the portal machines.  If the portals do experience problems,
>> the NOC team will implement a backup plan.  The backup plan will only be
>> used as a last resort as the backup plan will not be an option at IETF
>> 79 in Beijing.
>>
>>
>> Safe Travel and Best Wishes,
>>   Russ Housley
>>   IETF Chair
>>
>> ___
>> Ietf mail

RE: Admission Control to the IETF 78 and IETF 79 Networks

[Josh Howlett]

> Since we expect a reasonable attendance at IETF from
> eduroam-connected sites, IETF participants with an eduroam account
> configured, should get connected to the wireless network right away
> with their usual credentials.

And it's working flawlessly on my laptop and phone. Thank you to everyone who 
made this possible.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[IETF Chair]

eduroam (education roaming) is the secure, world-wide roaming access
service developed for the international research and education
community. eduroam allows students, researchers and staff from
participating institutions to obtain Internet connectivity across campus
and when visiting other participating institutions by simply opening
their laptop. Since we expect a reasonable attendance at IETF from
eduroam-connected sites, IETF participants with an eduroam account
configured, should get connected to the wireless network right away with
their usual credentials.

Enjoy,
Russ

On 6/30/2010 5:55 PM, IETF Chair wrote:
> I am writing to let you know about a change in the IETF meeting network.
> At IETF 79 in Beijing, the IETF network will be connected to the open
> Internet with absolutely no filtering.  However, we have agreed with our
> hosts that only IETF meeting participants will have access to the
> network.  Following sound engineering practices, we will deploy
> admission control mechanisms as part of the IETF 78 meeting network in
> Maastricht to ensure that they are working properly before they are
> mission critical.
> 
> I am writing to let you know what to expect in both Maastricht and Beijing.
> 
> 
> ADMISSION CONTROL CREDENTIALS
> 
> To gain access to the IETF network, you will need to provide a
> credential. Your primary credential will be your registration ID.  You
> can find your registration ID on the registration web page, in the
> response email confirmation you received from the Secretariat, on your
> payment receipt, and on the back of your IETF meeting badge.  Your
> Registration ID will be your user name, and it will be used with a
> password that will be provided at a later date.  This same password will
> be used by all attendees.
> 
> We recognize that IETF 78 registration IDs are very easy to guess.  We
> expect to use less easily guessed registration IDs for IETF 79.
> 
> If for any reason you are uncomfortable using your Registration ID,
> there will be a supply of completely anonymous Registration ID/Password
> pairs on slips of paper available at the help desk and registration
> desk.  You will be asked to show an IETF meeting badge to ensure that
> slips are only provided to registered meeting attendees.
> 
> Each set of credentials will allow up to three separate MAC addresses on
> the network, allowing attendees to use the same credential for their
> laptop, phone, or other devices.  The limit is to prevent the leak of a
> single credential from undermining the entire system.
> 
> 
> GAINING ACCESS TO THE NETWORK
> 
> The primary mechanism to gain access to the wireless network will be
> either the "ietf.1x" or "ietf-a.1x" SSID.  These will be configured with
> WPA1 and WPA2 Enterprise.  You simply provide your credentials to your
> supplicant software for authentication to the network.  I personally
> encourage you to use WPA2 over WPA1 if your software and hardware
> support both.
> 
> If your software does not support WPA Enterprise, you can use the
> captive portal.  To use this portal, associate with either the
> "ietf-portal" or "ietf-a-portal" SSID.  Upon initial connection,
> Internet connectivity will be blocked.  Simply open a browser and go to
> any web site, just like many hotel networks, and you will be redirected
> to a portal page where you can enter your credentials.  Once the
> credentials are validated, your MAC address will have unrestricted
> access to the network for some period of time.  The portal page will
> also have links to the internal wiki page with helpful information as
> well as a way to create trouble tickets prior to authentication.
> 
> If your small devices does not support WPA Enterprise and does not have
> a browser, then you will be able to visit the help desk and register the
> device MAC address for access to the network.  If you need to register
> your device, please know the MAC address of your device before you show
> up at the help desk.
> 
> 
> FALLBACK PLAN
> 
> Implementing this plan at IETF 78 in Maastricht is important, but
> obviously not without risk.  The IEEE 802.1X-based access mechanisms
> have been well tested at previous meetings, and this mechanism is not
> likely to be a source of trouble.  The captive portal, however, is a
> greater unknown.  Please use the WPA SSIDs if at all possible to reduce
> the load on the portal machines.  If the portals do experience problems,
> the NOC team will implement a backup plan.  The backup plan will only be
> used as a last resort as the backup plan will not be an option at IETF
> 79 in Beijing.
> 
> 
> Safe Travel and Best Wishes,
>   Russ Housley
>   IETF Chair
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Iljitsch van Beijnum]

On 30 jun 2010, at 23:55, IETF Chair wrote:

> To gain access to the IETF network, you will need to provide a
> credential. Your primary credential will be your registration ID.  You
> can find your registration ID on the registration web page, in the
> response email confirmation you received from the Secretariat, on your
> payment receipt, and on the back of your IETF meeting badge.  Your
> Registration ID will be your user name, and it will be used with a
> password that will be provided at a later date.  This same password will
> be used by all attendees.

When and how will this password be distributed? I'll be arriving on saturday 
(to attend a workshop at the venue), it would be helpful if those who arrive 
early don't have to wait to get on the network until registration opens sunday 
at 11.

(It occurs to me that a good way to give out this information pre-meeting is 
through inclusion on the payment receipt.)

Also see Mark Andrews' message, on some systems it's useful or necessary to 
know the exact authtentication type that will be used.

Thanks,

Iljitsch
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Iljitsch van Beijnum]

I should know better than dive back into this discussion...

On 13 jul 2010, at 18:05, Phillip Hallam-Baker wrote:

> Con: There is no cost to generating the cert, the cert can be
> generated after the device ships. Thus there is no degree of
> accountability established in the presentation of a cert. If a user
> abuses the network (e.g. to send spam) there is no bar to prevent them
> ditching the banned cert and re-applying for another.

The cost of generating the cert can be more than just generating the cert. For 
instance, it could be made necessary to have the cert signed by someone who is 
presumably trustworthy. Or they need to build up some reputation.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

While the fingerprint of the cert can be used as a globally unique
identifier, this approach has advantages and disadvantages.

Pro: There is no cost to generating the cert, the cert can be
generated after the device ships

Con: There is no cost to generating the cert, the cert can be
generated after the device ships. Thus there is no degree of
accountability established in the presentation of a cert. If a user
abuses the network (e.g. to send spam) there is no bar to prevent them
ditching the banned cert and re-applying for another.

Con: Existing management infrastructure is designed around the
communication of MAC addresses. Most computer system retailers
servicing the enterprise space already communicate the MAC address of
equipment to customers as part of the shipping process. Infrastructure
to support additional identifiers would have to be built out
separately and to avoid birthday paradox collisions, randomly unique
identifiers need to be twice as long as assigned ones making use of
simple barcodes impossible.


The IETF requirements can be met with cert fingerprints, the general
case requirement for accountability cannot without some party
providing rate limiting somewhere in the system.

On Mon, Jul 12, 2010 at 11:12 PM, Donald Eastlake  wrote:
> See belos ...
>
>> On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker 
>> wrote:
>>>
>>> No, if you read my book you would see the scheme I am proposing.
>>>
>>> The problem with current MAC addresses is that they are not
>>> trustworthy. That is accepted. If MAC addresses were not trivially
>>> forged then the existing WiFi scheme would work fine.
>>>
>>> ...
>>>
>>> Instead every device would have been issued with a device cert to bind
>>> the MAC address to a public key during manufacture. This is already a
>>> requirement for cable modems. The cost is of the order of cents per
>>> device if the certs are installed during manufacture. Maintenance
>>> costs get much higher as soon as the device has left the factory.
>
> I don't see any need for the MAC address to be bound. If the device
> has a build in cert, you can use that, regardless of what the MAC
> address is, to authenticate and secure communications.
>
> Isn't this provided by 802.1AR-2009? ( Available from
> http://standards.ieee.org/getieee802/802.1.html )
>
>>> The function of the certificate is to stop the MAC address being
>>> trivially forged. OK yes, if you design the protocols wrong then you
>>> can end up with Cisco being able to intercept on the wire traffic. But
>>> if you do the job right you can prevent interception even if the
>>> manufacturer defects.
>>>
>>> ...
>>>
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

Intel got a bloody nose on that one because they were incompetent and lied.

A few weeks before the launch an Intel person told me about the serial
number scheme as a means of tracking down CPUs stolen during
distribution. Then at the launch we were told how the serial number
was going to enable a new generation of DRM systems (which it did
not). When asked the PR flacks denied the purpose was preventing
theft. Afterward I was told that the history was that some VP was
going to give a keynote and decided they needed something to announce
and so marketing repackaged the anti-theft scheme.

It was a pointless argument as every PC has at least ten unique
machine readable identifiers. From the point of view of enabling DRM
schemes, any identifier is acceptable, even if it is fairly soft and
easily changed. So the objections do not prevent the outcome they wish
to prevent while preventing outcomes that might be beneficial.

Any security scheme that is worth having is going to change the
accessibility of information. That is intrinsic to the function.



On Mon, Jul 12, 2010 at 2:39 PM, Martin Rex  wrote:
> Phillip Hallam-Baker wrote:
>>
>> The simplest, cleanest solution to this problem is to either have a
>> device cert installed during manufacture or to employ my alternative
>> scheme designed for low performance devices that does not require them
>> to perform public key cryptography on the end point device (patent
>> pending, all rights reserved).
>
> Personally, I'm heavily opposed to an approach along these lines.
> It is a big plus that MAC addresses can be trivially changed,
> and I regularly connect with random MACs in public places.
>
> Several years ago, Intel came out with a unique identifier in their
> Pentium CPU.  The market did not take it very well, at least here
> in Europe.  I remember BIOS options to enable/disable the unique
> CPU ID, and it was disabled on all the machines I have been using
> (and AFAIK, it was disabled on all PCs distributed by my companies
> IT department).  Talking about it, I do not remember having seen such
> a bios option for many year -- may I assume that the unique identifier
> was removed from Intel CPUs entirely?
>
>
> Personally, I'm somewhat less concerned about a unique or fixed ID in
> my DSL-router.  I have only one DSL subscription with one single ISP,
> and I need to authenticate to my ISP with userid&pass -- which makes
> we wonder why should there be a unique/fixed ID in that device,
> it is absolutely unnecessary.
>
>
> -Martin
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

Well maybe if you read the full thread rather than just cherry picking
parts of it you would have understood the point better.

My original argument was that I think the IETF should eat the WiFi
authentication dog-food here because the current product tastes like
poo and the only way things are going to get any better is if a bunch
of network engineers start to see that there is a real problem.


I have also proposed a scheme that would be applicable for use at the
IETF. Basically the shortest distance from where we are to where we
want to be is to use self signed certs and use the fingerprint of the
cert as a unique device ID. But that is only addressing the specifics
of how to make the scheme work at IETF, which is really not very
interesting in the grand scheme of things. What is more interesting
would be a scheme that can be relied on to work anywhere without half
an hour of fiddling and jiggering the configuration - as will be the
Maastricht/Beijing experience.

The first year they started doing this at RSA the help desk had a
pretty long queue and much time was spend debugging crappy code. The
basic experience being that Macs work fine, Windows works fine with
native drivers. But corporate configuration laptops with device
drivers written by the WiFi card provider and/or VPN products were
massively flaky..


On Mon, Jul 12, 2010 at 1:53 PM, Chris Elliott  wrote:
> On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker 
> wrote:
>>
>> No, if you read my book you would see the scheme I am proposing.
>
>
> I hope your book is rather less opaque than your attempts to explain your
> technique here.
>>
>> The problem with current MAC addresses is that they are not
>> trustworthy. That is accepted. If MAC addresses were not trivially
>> forged then the existing WiFi scheme would work fine.
>>
>> What I am saying is that if people got really serious about usability
>> and in particular the WiFi design had been controlled by a Steve Jobs
>> style person who demanded an absolute commitment to a first class
>> usability approach, then we could have a scheme that did not require
>> end-user configuration.
>>
>> Instead every device would have been issued with a device cert to bind
>> the MAC address to a public key during manufacture. This is already a
>> requirement for cable modems. The cost is of the order of cents per
>> device if the certs are installed during manufacture. Maintenance
>> costs get much higher as soon as the device has left the factory.
>>
>> The function of the certificate is to stop the MAC address being
>> trivially forged. OK yes, if you design the protocols wrong then you
>> can end up with Cisco being able to intercept on the wire traffic. But
>> if you do the job right you can prevent interception even if the
>> manufacturer defects.
>
> I thought we were talking about how to do this for the meeting in Maastricht
> and then in Beijing. I agree that manufacturers could make this easier for
> all of us. But some of us live in the real world and must make things work
> today.
> I'd be glad to listen to an explanation of how to make this work with the
> current devices that IETF attendees will be bringing to Maastricht and
> Beijing.
> Chris.
>
>>
>> And as for my waist - yes there does seem to be rather more of it than
>> there should be, but I don't think that is Dogbert's fault. I blame
>> the cookies at IETF break time.
>>
>>
>> On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott 
>> wrote:
>> > Phillip,
>> > In your earlier email, you state:
>> >>
>> >> If the designers had actual brains instead of bits of liver strapped
>> >> round their waist by dogbert then all that would be necessary to
>> >> securely authenticate to the network is to give either the MAC address
>> >> of the computer or the fingerprint of the cert.
>> >
>> > Note that you say "either". Now you state:
>> >>
>> >> Of course the MAC address is trivially forged. That is the function of
>> >> the certificate.
>> >
>> > Maybe you should check your waist.
>> > Chris.
>> >
>> > --
>> > Chris Elliott
>> > chell...@pobox.com
>>
>> --
>> Website: http://hallambaker.com/
>
>
>
> --
> Chris Elliott
> chell...@pobox.com
> CCIE # 2013



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

No, if you read my book you would see the scheme I am proposing.

The problem with current MAC addresses is that they are not
trustworthy. That is accepted. If MAC addresses were not trivially
forged then the existing WiFi scheme would work fine.

What I am saying is that if people got really serious about usability
and in particular the WiFi design had been controlled by a Steve Jobs
style person who demanded an absolute commitment to a first class
usability approach, then we could have a scheme that did not require
end-user configuration.

Instead every device would have been issued with a device cert to bind
the MAC address to a public key during manufacture. This is already a
requirement for cable modems. The cost is of the order of cents per
device if the certs are installed during manufacture. Maintenance
costs get much higher as soon as the device has left the factory.

The function of the certificate is to stop the MAC address being
trivially forged. OK yes, if you design the protocols wrong then you
can end up with Cisco being able to intercept on the wire traffic. But
if you do the job right you can prevent interception even if the
manufacturer defects.


And as for my waist - yes there does seem to be rather more of it than
there should be, but I don't think that is Dogbert's fault. I blame
the cookies at IETF break time.


On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott  wrote:
> Phillip,
> In your earlier email, you state:
>>
>> If the designers had actual brains instead of bits of liver strapped
>> round their waist by dogbert then all that would be necessary to
>> securely authenticate to the network is to give either the MAC address
>> of the computer or the fingerprint of the cert.
>
> Note that you say "either". Now you state:
>>
>> Of course the MAC address is trivially forged. That is the function of
>> the certificate.
>
> Maybe you should check your waist.
> Chris.
>
> --
> Chris Elliott
> chell...@pobox.com
>
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Donald Eastlake]

See belos ...

> On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker 
> wrote:
>>
>> No, if you read my book you would see the scheme I am proposing.
>>
>> The problem with current MAC addresses is that they are not
>> trustworthy. That is accepted. If MAC addresses were not trivially
>> forged then the existing WiFi scheme would work fine.
>>
>> ...
>>
>> Instead every device would have been issued with a device cert to bind
>> the MAC address to a public key during manufacture. This is already a
>> requirement for cable modems. The cost is of the order of cents per
>> device if the certs are installed during manufacture. Maintenance
>> costs get much higher as soon as the device has left the factory.

I don't see any need for the MAC address to be bound. If the device
has a build in cert, you can use that, regardless of what the MAC
address is, to authenticate and secure communications.

Isn't this provided by 802.1AR-2009? ( Available from
http://standards.ieee.org/getieee802/802.1.html )

>> The function of the certificate is to stop the MAC address being
>> trivially forged. OK yes, if you design the protocols wrong then you
>> can end up with Cisco being able to intercept on the wire traffic. But
>> if you do the job right you can prevent interception even if the
>> manufacturer defects.
>>
>> ...
>>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Douglas Otis]

On 7/12/10 11:39 AM, Martin Rex wrote:

Personally, I'm heavily opposed to an approach along these lines.
It is a big plus that MAC addresses can be trivially changed,
and I regularly connect with random MACs in public places.
   
Russ and Ted discussed use of MAC addresses for access.   I may have 
missed or misunderstood their point, although such a scheme is often 
used (and easily defeated) in typical coffee-shop settings.  I may be 
wrong, and this is a good list for learning such things.


When security is desired, something like WPA2 Enterprise EAP-TTLS seems 
more realistic.  Perhaps other options need to be included to overcoming 
third-party software for versions of Windows.  This approach would keep 
information and privacy better secured, and systems less exposed to 
various exploits, since some attendees may actually need protection in 
the big city. :^)


Better security can be found with 802.1X-2010 that resolves some 
vulnerabilities by using MACSec 802.1AE to encrypt data between logical 
ports.  This suffers a drawback of deploying client certs, of poor 
coverage, along with the anxiety that EAP-TPM might cause.

Personally, I'm somewhat less concerned about a unique or fixed ID in
my DSL-router.  I have only one DSL subscription with one single ISP,
and I need to authenticate to my ISP with userid&pass -- which makes
we wonder why should there be a unique/fixed ID in that device,
it is absolutely unnecessary.
   
Securing wireless must detect MitM attack. Using a cert at the server 
when making changes seems a small price.


-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Chris Elliott]

Phillip,

I read all of all your emails on this thread before I replied the first time, 
just not your book.

We will be and we have been "eat[ing] the WiFi authentication dog-food" at IETF 
meetings. And it's gotten easier each time.

You do realize, don't you, that we are offering WPA/WPA2 with enterprise 
authentication and encryption as our recommended way of getting onto the 
network, right? We are only offering a web portal so that folks that can't do 
WPA* can authenticate. And we've been offering WPA* enterprise on most IETF 
networks for many years. The difference this time is we are going to unique 
user credentials.

I anticipate the time it will take for most attendees to authenticate will be 
the time it takes to type in a username and password--far under a half an hour, 
unless the attendee is Stephen Hawking, in which case I will personally help 
the attendee authenticate! There will be those with problems. That's why 
there's a help desk.

Chris.

P.S. bring a copy of your book to Maastricht and I'll bring a copy of mine and 
we'll do a prisoner exchange. :-)


--
Chris Elliott
CCIE # 2013


On Jul 12, 2010, at 2:35 PM, Phillip Hallam-Baker  wrote:

> Well maybe if you read the full thread rather than just cherry picking
> parts of it you would have understood the point better.
> 
> My original argument was that I think the IETF should eat the WiFi
> authentication dog-food here because the current product tastes like
> poo and the only way things are going to get any better is if a bunch
> of network engineers start to see that there is a real problem.
> 
> 
> I have also proposed a scheme that would be applicable for use at the
> IETF. Basically the shortest distance from where we are to where we
> want to be is to use self signed certs and use the fingerprint of the
> cert as a unique device ID. But that is only addressing the specifics
> of how to make the scheme work at IETF, which is really not very
> interesting in the grand scheme of things. What is more interesting
> would be a scheme that can be relied on to work anywhere without half
> an hour of fiddling and jiggering the configuration - as will be the
> Maastricht/Beijing experience.
> 
> The first year they started doing this at RSA the help desk had a
> pretty long queue and much time was spend debugging crappy code. The
> basic experience being that Macs work fine, Windows works fine with
> native drivers. But corporate configuration laptops with device
> drivers written by the WiFi card provider and/or VPN products were
> massively flaky..
> 
> 
> On Mon, Jul 12, 2010 at 1:53 PM, Chris Elliott  wrote:
>> On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker 
>> wrote:
>>> 
>>> No, if you read my book you would see the scheme I am proposing.
>> 
>> 
>> I hope your book is rather less opaque than your attempts to explain your
>> technique here.
>>> 
>>> The problem with current MAC addresses is that they are not
>>> trustworthy. That is accepted. If MAC addresses were not trivially
>>> forged then the existing WiFi scheme would work fine.
>>> 
>>> What I am saying is that if people got really serious about usability
>>> and in particular the WiFi design had been controlled by a Steve Jobs
>>> style person who demanded an absolute commitment to a first class
>>> usability approach, then we could have a scheme that did not require
>>> end-user configuration.
>>> 
>>> Instead every device would have been issued with a device cert to bind
>>> the MAC address to a public key during manufacture. This is already a
>>> requirement for cable modems. The cost is of the order of cents per
>>> device if the certs are installed during manufacture. Maintenance
>>> costs get much higher as soon as the device has left the factory.
>>> 
>>> The function of the certificate is to stop the MAC address being
>>> trivially forged. OK yes, if you design the protocols wrong then you
>>> can end up with Cisco being able to intercept on the wire traffic. But
>>> if you do the job right you can prevent interception even if the
>>> manufacturer defects.
>> 
>> I thought we were talking about how to do this for the meeting in Maastricht
>> and then in Beijing. I agree that manufacturers could make this easier for
>> all of us. But some of us live in the real world and must make things work
>> today.
>> I'd be glad to listen to an explanation of how to make this work with the
>> current devices that IETF attendees will be bringing to Maastricht and
>> Beijing.
>> Chris.
>> 
>>> 
>>> And as for my waist - yes there does seem to be rather more of it than
>>> there should be, but I don't think that is Dogbert's fault. I blame
>>> the cookies at IETF break time.
>>> 
>>> 
>>> On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott 
>>> wrote:
 Phillip,
 In your earlier email, you state:
> 
> If the designers had actual brains instead of bits of liver strapped
> round their waist by dogbert then all that would be necessary to
> securely authen

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Martin Rex]

Phillip Hallam-Baker wrote:
> 
> The simplest, cleanest solution to this problem is to either have a
> device cert installed during manufacture or to employ my alternative
> scheme designed for low performance devices that does not require them
> to perform public key cryptography on the end point device (patent
> pending, all rights reserved).

Personally, I'm heavily opposed to an approach along these lines.
It is a big plus that MAC addresses can be trivially changed,
and I regularly connect with random MACs in public places.

Several years ago, Intel came out with a unique identifier in their
Pentium CPU.  The market did not take it very well, at least here
in Europe.  I remember BIOS options to enable/disable the unique
CPU ID, and it was disabled on all the machines I have been using
(and AFAIK, it was disabled on all PCs distributed by my companies
IT department).  Talking about it, I do not remember having seen such
a bios option for many year -- may I assume that the unique identifier
was removed from Intel CPUs entirely?


Personally, I'm somewhat less concerned about a unique or fixed ID in
my DSL-router.  I have only one DSL subscription with one single ISP,
and I need to authenticate to my ISP with userid&pass -- which makes
we wonder why should there be a unique/fixed ID in that device,
it is absolutely unnecessary.


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Chris Elliott]

On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker wrote:

> No, if you read my book you would see the scheme I am proposing.
>

I hope your book is rather less opaque than your attempts to explain your
technique here.

The problem with current MAC addresses is that they are not
> trustworthy. That is accepted. If MAC addresses were not trivially
> forged then the existing WiFi scheme would work fine.
>
> What I am saying is that if people got really serious about usability
> and in particular the WiFi design had been controlled by a Steve Jobs
> style person who demanded an absolute commitment to a first class
> usability approach, then we could have a scheme that did not require
> end-user configuration.
>
> Instead every device would have been issued with a device cert to bind
> the MAC address to a public key during manufacture. This is already a
> requirement for cable modems. The cost is of the order of cents per
> device if the certs are installed during manufacture. Maintenance
> costs get much higher as soon as the device has left the factory.
>
> The function of the certificate is to stop the MAC address being
> trivially forged. OK yes, if you design the protocols wrong then you
> can end up with Cisco being able to intercept on the wire traffic. But
> if you do the job right you can prevent interception even if the
> manufacturer defects.
>

I thought we were talking about how to do this for the meeting in Maastricht
and then in Beijing. I agree that manufacturers could make this easier for
all of us. But some of us live in the real world and must make things work
today.

I'd be glad to listen to an explanation of how to make this work with the
current devices that IETF attendees will be bringing to Maastricht and
Beijing.

Chris.


> And as for my waist - yes there does seem to be rather more of it than
> there should be, but I don't think that is Dogbert's fault. I blame
> the cookies at IETF break time.
>
>
> On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott 
> wrote:
> > Phillip,
> > In your earlier email, you state:
> >>
> >> If the designers had actual brains instead of bits of liver strapped
> >> round their waist by dogbert then all that would be necessary to
> >> securely authenticate to the network is to give either the MAC address
> >> of the computer or the fingerprint of the cert.
> >
> > Note that you say "either". Now you state:
> >>
> >> Of course the MAC address is trivially forged. That is the function of
> >> the certificate.
> >
> > Maybe you should check your waist.
> > Chris.
> >
> > --
> > Chris Elliott
> > chell...@pobox.com
>
> --
> Website: http://hallambaker.com/
>



-- 
Chris Elliott
chell...@pobox.com
CCIE # 2013
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Chris Elliott]

Phillip,

In your earlier email, you state:

If the designers had actual brains instead of bits of liver strapped
> round their waist by dogbert then all that would be necessary to
> securely authenticate to the network is to give either the MAC address
> of the computer or the fingerprint of the cert.


Note that you say "either". Now you state:

Of course the MAC address is trivially forged. That is the function of
> the certificate.
>

Maybe you should check your waist.

Chris.


-- 
Chris Elliott
chell...@pobox.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

Of course the MAC address is trivially forged. That is the function of
the certificate.

MAC address X is not very interesting
MAC address that party purporting to be CISCO says is X is quite a
bit more interesting
MAC address that party validated as CISCO as X is more interesting still.

Now this is not getting us to a point where nobody can possibly break
the system. But we have got to a point where the expected losses are a
couple orders of magnitude lower than we can expect through current
approaches.


On the issues involved using client certificates for wireless access,
I agree that the current practice falls far short of what is
acceptable. That is the reason why I think it would be helpful for the
IETF to spend some time eating the dog food (even if a different
brand, we can do better).

Now in theory, this is a problem that PKI should make easier to solve.
But instead it seems that it gives people too much scope to create
incompatible variations.


The simplest, cleanest solution to this problem is to either have a
device cert installed during manufacture or to employ my alternative
scheme designed for low performance devices that does not require them
to perform public key cryptography on the end point device (patent
pending, all rights reserved).


I do not see the value of client certificates for this type of network
access. They work in the enterprise context as the selection of the
certificate is unambiguous. But here we have a situation where we are
not really looking to become part of the IETF network specifically, we
just want a uniform identifier.

I would prefer to use client certs for VPN layer security and a device
cert for WiFi authentication. The user is not a device, conflating the
two is bad.

By a device cert, I mean an authentication credential that permits
authentication of the device without disclosure of the authentication
secret, is linked to a globally unique identifier and never expires.

The simplest solution for this in my view would be for everyone to
independently generate a self-signed cert and use the fingerprint to
mediate access. They can then in theory use the same cert in any
similar environment.


One (yucky) way we could do this is to each enter the fingerprint of
the cert(s) for each device when we register.

A much better way to achieve the same effect would be to configure the
network so that any computer that presents any certificate can access
the network registration page (just like in a hotel network) but
leaving that area is only possible after the user has authenticated
and the fingerprint of the cert is entered into the auth database.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[joel jaeggli]

On 2010-07-06 11:37, Mark Atwood wrote:

That is sadly true.  However, it would still be a good idea to do at
the IETF gathering, *because* it is currently a usability nightmare.
There is not enough both real world experience, and exposure of IETF
participant attendees to actual "tip of the spear" usability of
interesting use cases like this.


we typically do eap-peap for the ietf802.1x ssid/vlan, the difference 
this time is the radius server will have a lot more credientials to 
chooose from.



If lots of smart and networking aware people all get the chance to do
this kind of "interop and usability" "testing" all at once, then a lot
of useful knowledge, tips, howtos, bug discovery, and application
feedback will happen, which I believe can only be a good thing towards
fixing the usability bottleneck that client certs are today.

..m
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Chris Elliott]

On Tue, Jul 6, 2010 at 2:37 PM, Mark Atwood  wrote:

> > As far as using certificates --- sure, it's possible to set up EAP-TLS
> > using client certificates.  It can be done on Mac, Windows, and Linux.
> > But the setup of that across multiple operating systems and getting
> > users to correctly set up their certificates, sending a CA signing
> > request securely to a central system, configuring their client WiFi
> > system to deal with EAP-TLS, etc., is a usability nightmare.
>
> That is sadly true.  However, it would still be a good idea to do at
> the IETF gathering, *because* it is currently a usability nightmare.
> There is not enough both real world experience, and exposure of IETF
> participant attendees to actual "tip of the spear" usability of
> interesting use cases like this.
>
> If lots of smart and networking aware people all get the chance to do
> this kind of "interop and usability" "testing" all at once, then a lot
> of useful knowledge, tips, howtos, bug discovery, and application
> feedback will happen, which I believe can only be a good thing towards
> fixing the usability bottleneck that client certs are today.
>

This can be done in the context of what we are setting up to do
authentication for the next two meetings, but will take a fair amount of
work, and will add to the complexity of getting on the network for
attendees.

We will be using 802.1X and portal software (users can choose which they
wish to use--either or both) to communicate authentication information with
users. Both will be using Radius on the back end. Supporting an additional
EAP method (TLS) for 802.1X is trivial. Supporting TLS for the portal is
likely to be fairly easy as well.

However, this would require the IETF have a certificate infrastructure.
Which does not exist. And a mechanism for users to request certs securely.
So, right there, we have the chicken and egg issue--what do users use to
authenticate themselves before they have a cert? I'd suggest that the same
method we are planning on using to authenticate users (reg ID or anonymous
ID obtained by IETF badge holders from the reg desk) can be used. This means
that we've just required a whole series of additional steps to be done by
attendees. So I don't see the NOC team taking this on.

I would support an experiment, if someone or some group is willing to run
with it, that would do the above. I believe that the changes needed to
support such an experiment (supporting TLS for authentication) could be done
by the NOC team without too much additional effort. However, this person or
group would have to take on setting up the CA infrastructure, integrating it
with the FreeRADIUS server we will be using, and instructing attendees on
how to participate in the experiment.

Note that this is not a typical environment for certs. We are trying to
authenticate that users are a member of a group (IETF attendees) while
(optionally) preserving anonymity for users. I would suggest that a
certificate experiment try to replicate these same criteria, which may or
may not make it a useful experiment for the usage of user certs in general.

So, if you, or anyone, is interested in running an experiment please put in
your request. We support various experiments on the IETF networks most
meetings, and this could be a useful, or at least educational, one.

Chris.


> ..m
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>


-- 
Chris Elliott
chell...@pobox.com
CCIE # 2013
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Mark Atwood]

> As far as using certificates --- sure, it's possible to set up EAP-TLS
> using client certificates.  It can be done on Mac, Windows, and Linux.
> But the setup of that across multiple operating systems and getting
> users to correctly set up their certificates, sending a CA signing
> request securely to a central system, configuring their client WiFi
> system to deal with EAP-TLS, etc., is a usability nightmare.

That is sadly true.  However, it would still be a good idea to do at
the IETF gathering, *because* it is currently a usability nightmare.
There is not enough both real world experience, and exposure of IETF
participant attendees to actual "tip of the spear" usability of
interesting use cases like this.

If lots of smart and networking aware people all get the chance to do
this kind of "interop and usability" "testing" all at once, then a lot
of useful knowledge, tips, howtos, bug discovery, and application
feedback will happen, which I believe can only be a good thing towards
fixing the usability bottleneck that client certs are today.

..m
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[tytso]

On Sat, Jul 03, 2010 at 03:13:28PM -0400, Phillip Hallam-Baker wrote:
> 
> Any time a user has to think when the computer can think for them is a
> failure. Every WiFi access control system I have ever used has
> required me to configure the computer.
> 
> If the designers had actual brains instead of bits of liver strapped
> round their waist by dogbert then all that would be necessary to
> securely authenticate to the network is to give either the MAC address
> of the computer or the fingerprint of the cert.

The MAC address of the computer is trivially forged.  Can be done with
a single ifconfig command.

As far as using certificates --- sure, it's possible to set up EAP-TLS
using client certificates.  It can be done on Mac, Windows, and Linux.
But the setup of that across multiple operating systems and getting
users to correctly set up their certificates, sending a CA signing
request securely to a central system, configuring their client WiFi
system to deal with EAP-TLS, etc., is a usability nightmare.

> This configuration is going to cost several minutes per participant.

?Half a minute per participant, maybe; the biggest risk is that they
lose the piece of paper with the wifi login information.  But it's a
one-time setup cost.

> Think of it on Enterprise scale and you have significant costs.

On the enterprise scale if you are willing to force everyone to use a
standardized OS configuratoins, then you can do EAP-TLS relatively
cheaply.  I've certainly in use at my current employer, and it's
really not hard, even if you are supporting Mac, Windows, _and_ Linux.
But that doesn't mean it would be easy to do at IETF; in fact, because
IETF doesn't have the power to mandate that all its attendees only use
a specific version of Windows, MacOS, and Linux, with a specific
locked-down stock system load and configuration, using the traditional
username/password via a captive portable is probably the only thing
that does make sense.

- Ted
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Chris Elliott]

On Sat, Jul 3, 2010 at 3:13 PM, Phillip Hallam-Baker wrote:

> The usability of these systems suck.
>
> Any time a user has to think when the computer can think for them is a
> failure. Every WiFi access control system I have ever used has
> required me to configure the computer.
>
> If the designers had actual brains instead of bits of liver strapped
> round their waist by dogbert then all that would be necessary to
> securely authenticate to the network is to give either the MAC address
> of the computer or the fingerprint of the cert.
>

MAC secure? Surely you jest.


> This configuration is going to cost several minutes per participant.
> Think of it on Enterprise scale and you have significant costs.
>
>
> And the coffee shop scenario is not about authentication, its really
> about getting acceptance of the terms of service.
>
>
> On Sat, Jul 3, 2010 at 12:02 PM, Iljitsch van Beijnum
>  wrote:
> > On 2 jul 2010, at 2:30, Phillip Hallam-Baker wrote:
> >
> >> It has taken ten years for WiFi to get to a state where an adequate
> >> credential mechanism is supported, and it is still clunky.
> >
> > What are you talking about?? Enterprise type WPA where you authenticate
> against a back end server has been around for years, and with WPA2 it
> supports good encryption, too.
> >
> >> And they
> >> still don't have a decent mechanism to support the typical coffee shop
> >> type access mode.
> >
> > Well, you could use WPA(2) there too. People who don't have a working
> account yet for the hotspot in question would then log in as guest, create
> an account and then log in with that account.
> >
> > But I would argue that the IETF in general has ignored access control to
> IP networks and how this interacts with provisioning of addresses and other
> information once PPP was out the door. Look at the backflips that are
> required to provide ethernet-based broadband access. Although we can
> partially blame this on the lack of uptake of 802.1x which handles the
> authentication, but that still makes (IP-over-)ethernet-based broadband
> problematic because of its point-to-multipoint model that isn't appropriate
> for providing services.
> >
> >
>
>
>
> --
> Website: http://hallambaker.com/
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Chris Elliott
chell...@pobox.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

The usability of these systems suck.

Any time a user has to think when the computer can think for them is a
failure. Every WiFi access control system I have ever used has
required me to configure the computer.

If the designers had actual brains instead of bits of liver strapped
round their waist by dogbert then all that would be necessary to
securely authenticate to the network is to give either the MAC address
of the computer or the fingerprint of the cert.


This configuration is going to cost several minutes per participant.
Think of it on Enterprise scale and you have significant costs.


And the coffee shop scenario is not about authentication, its really
about getting acceptance of the terms of service.


On Sat, Jul 3, 2010 at 12:02 PM, Iljitsch van Beijnum
 wrote:
> On 2 jul 2010, at 2:30, Phillip Hallam-Baker wrote:
>
>> It has taken ten years for WiFi to get to a state where an adequate
>> credential mechanism is supported, and it is still clunky.
>
> What are you talking about?? Enterprise type WPA where you authenticate 
> against a back end server has been around for years, and with WPA2 it 
> supports good encryption, too.
>
>> And they
>> still don't have a decent mechanism to support the typical coffee shop
>> type access mode.
>
> Well, you could use WPA(2) there too. People who don't have a working account 
> yet for the hotspot in question would then log in as guest, create an account 
> and then log in with that account.
>
> But I would argue that the IETF in general has ignored access control to IP 
> networks and how this interacts with provisioning of addresses and other 
> information once PPP was out the door. Look at the backflips that are 
> required to provide ethernet-based broadband access. Although we can 
> partially blame this on the lack of uptake of 802.1x which handles the 
> authentication, but that still makes (IP-over-)ethernet-based broadband 
> problematic because of its point-to-multipoint model that isn't appropriate 
> for providing services.
>
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Joel Jaeggli]

We've had deployments where we've taken over the hotel's wireless 
Infrastructure and as result been expected to serve their customers as well... 
Doing so is more or less incompatible with authenticated network access. It 
imagine us doing that again sometime...

Joel

Joel's iPad

On Jul 4, 2010, at 4:26 AM, Marocco Enrico  
wrote:

> That is understood, Andrew's comment I seconded was about the
> possibility of the change becoming permanent after Beijing.
> 
> --
> Ciao,
> Enrico
> 
> Sent from my iPhone
> 
> On Jul 3, 2010, at 21:19, "Ole Jacobsen"  wrote:
> 
>> 
>> Enrico,
>> 
>> Nobody has suggested there was anything wrong with the old (NUL)
>> access method nor that any damage has ever been caused, but that
>> is entirely orthogonal to the matter at hand. We are (in November)
>> going to a location where such access is "required" (at least it
>> seems a good idea from host's point of view), so we are testing
>> it in another location, Maastricht, first to iron out bugs etc.
>> 
>> Ole
>> 
>> 
>> On Sat, 3 Jul 2010, Marocco Enrico wrote:
>>> +1
>>> 
>>> Also, if we really need to switch to a new access method, I would
>>> deeply appreciate if someone explained what was wrong with the old
>>> one, i.e. what damage was ever caused by an open IETF network. If
>>> any.
>>> 
>>> --
>>> Ciao,
>>> Enrico
>>> 
>>> 
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
> abbiate ricevuto questo documento per errore siete cortesemente pregati di 
> darne immediata comunicazione al mittente e di provvedere alla sua 
> distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged 
> information intended for the addressee(s) only. Dissemination, copying, 
> printing or use by anybody else is unauthorised. If you are not the intended 
> recipient, please delete this message and any attachments and advise the 
> sender by return e-mail, Thanks.
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Marocco Enrico]

That is understood, Andrew's comment I seconded was about the
possibility of the change becoming permanent after Beijing.

--
Ciao,
Enrico

Sent from my iPhone

On Jul 3, 2010, at 21:19, "Ole Jacobsen"  wrote:

>
> Enrico,
>
> Nobody has suggested there was anything wrong with the old (NUL)
> access method nor that any damage has ever been caused, but that
> is entirely orthogonal to the matter at hand. We are (in November)
> going to a location where such access is "required" (at least it
> seems a good idea from host's point of view), so we are testing
> it in another location, Maastricht, first to iron out bugs etc.
>
> Ole
>
>
> On Sat, 3 Jul 2010, Marocco Enrico wrote:
>> +1
>>
>> Also, if we really need to switch to a new access method, I would
>> deeply appreciate if someone explained what was wrong with the old
>> one, i.e. what damage was ever caused by an open IETF network. If
>> any.
>>
>> --
>> Ciao,
>> Enrico
>>
>>

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Ole Jacobsen]

Enrico,

Nobody has suggested there was anything wrong with the old (NUL)
access method nor that any damage has ever been caused, but that
is entirely orthogonal to the matter at hand. We are (in November)
going to a location where such access is "required" (at least it
seems a good idea from host's point of view), so we are testing
it in another location, Maastricht, first to iron out bugs etc.

Ole


On Sat, 3 Jul 2010, Marocco Enrico wrote:
> +1
> 
> Also, if we really need to switch to a new access method, I would
> deeply appreciate if someone explained what was wrong with the old
> one, i.e. what damage was ever caused by an open IETF network. If any.
> 
> --
> Ciao,
> Enrico
> 
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Marocco Enrico]

Andrew G. Malis wrote:
> IMHO, the best IETF network experiences have been when the IETF took
> over the entire hotel network for the week, including the guest room
> access whether wired or wireless, and allowed free access to all hotel
> guests. I hope that we can return to that model in the future.

+1

Also, if we really need to switch to a new access method, I would
deeply appreciate if someone explained what was wrong with the old
one, i.e. what damage was ever caused by an open IETF network. If any.

--
Ciao,
Enrico


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Andrew G. Malis]

On Thu, Jul 1, 2010 at 7:19 PM, Michael StJohns  wrote:
> I would expect this (per user login) to fade away after Beijing - unless and 
> until the IAOC and IETF agrees that its necessary for the longer term.  And I 
> don't believe that discussion has been had.

I would like to second this.

IMHO, the best IETF network experiences have been when the IETF took
over the entire hotel network for the week, including the guest room
access whether wired or wireless, and allowed free access to all hotel
guests. I hope that we can return to that model in the future.

Cheers,
Andy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Iljitsch van Beijnum]

On 2 jul 2010, at 2:30, Phillip Hallam-Baker wrote:

> It has taken ten years for WiFi to get to a state where an adequate
> credential mechanism is supported, and it is still clunky.

What are you talking about?? Enterprise type WPA where you authenticate against 
a back end server has been around for years, and with WPA2 it supports good 
encryption, too.

> And they
> still don't have a decent mechanism to support the typical coffee shop
> type access mode.

Well, you could use WPA(2) there too. People who don't have a working account 
yet for the hotspot in question would then log in as guest, create an account 
and then log in with that account.

But I would argue that the IETF in general has ignored access control to IP 
networks and how this interacts with provisioning of addresses and other 
information once PPP was out the door. Look at the backflips that are required 
to provide ethernet-based broadband access. Although we can partially blame 
this on the lack of uptake of 802.1x which handles the authentication, but that 
still makes (IP-over-)ethernet-based broadband problematic because of its 
point-to-multipoint model that isn't appropriate for providing services.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[SM]

Hi Ole,
At 11:33 AM 7/2/2010, Ole Jacobsen wrote:

Could you please summarize in one paragraph exactly what problem
you have with this setup?


I do not have any problem with the setup.  I support what Ted Hardie 
said in the last paragraph of his message.


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Phillip Hallam-Baker]

Actually, I wish we had done something in this area sooner in the hope
of creating a forcing function to make the authentication mechanisms
in WiFi more appropriate.

It has taken ten years for WiFi to get to a state where an adequate
credential mechanism is supported, and it is still clunky. And they
still don't have a decent mechanism to support the typical coffee shop
type access mode.


On Thu, Jul 1, 2010 at 11:26 AM, Fred Baker  wrote:
> While it is new in IETF meetings, it is far from unusual in WiFi networks to 
> find some form of authentication. This happens at coffee shops, college 
> campuses, corporate campuses, and people's apartments. I think I would need 
> some more data before I concluded this was unreasonable.
>
> On Jul 1, 2010, at 8:08 AM, SM wrote:
>
>> Hello,
>> At 14:55 30-06-10, IETF Chair wrote:
>>> I am writing to let you know about a change in the IETF meeting network.
>>> At IETF 79 in Beijing, the IETF network will be connected to the open
>>> Internet with absolutely no filtering.  However, we have agreed with our
>>> hosts that only IETF meeting participants will have access to the
>>> network.  Following sound engineering practices, we will deploy
>>> admission control mechanisms as part of the IETF 78 meeting network in
>>> Maastricht to ensure that they are working properly before they are
>>> mission critical.
>>
>> Most IETF participants probably know that the consensus of the IETF is 
>> documented through BCPs and other Standards Track RFCs.  If the text in the 
>> RFC isn't clear, there is room for disagreement.  If it is ill-defined, 
>> someone will go and find the loophole.  If the above text was in a BCP, we 
>> could nit on the definition of IETF meeting participants.  It is clear to 
>> people unfamiliar with the IETF that IETF meeting participants means people 
>> who have registered for the IETF meeting.
>>
>> I have been told that an IETF meeting does not have security guards at the 
>> door to verify who has a badge to determine whether the person is registered 
>> for the meeting.  If someone walks into an IETF meeting, the person can 
>> enjoy the cookie for free and even provide a contribution at the mic.  The 
>> person enjoys the same privileges as people who have paid for meeting 
>> attendance fee.
>>
>> I'll take the opportunity to thank Karen O'Donoghue for keeping the IAOC 
>> minutes up to date.  The IAB could do with some help in that area.
>>
>> Some of you may recall that the Beijing venue contract was discussed on this 
>> mailing list last year.  It resulted in some resolutions as follows:
>>
>> "Whereas the Host has assured the IAOC that 'a normal IETF
>>  meeting can be legally held in China and that no pre-screening
>>  of material or monitoring of session content is required or will
>>  be done,'
>>
>>  Whereas the IAOC, based on the assurances of the Host and a
>>  history of the venue successfully hosting major international
>>  conferences that relate to our industry, believes a normal IETF
>>  meeting can be held at the venue,
>>
>>  Whereas the IAOC heard all arguments made on the list, and
>>  made its determination on the ability to hold a successful
>>  meeting i.e. run it in a fashion as we always have, using the
>>  tools that we always have, with a critical mass of the
>>  traditional participants, discussing the usual topics."
>>
>> The fashion in the IETF is to have an open network.  There isn't any 
>> admission control and credentials are not required to enjoy the benefit of 
>> free and full Internet access.  The IETF may run out of cookies; it never 
>> runs out of bandwidth.
>>
>>> I am writing to let you know what to expect in both Maastricht and Beijing.
>>
>> And it is expected that the comments on this thread will follow sound IETF 
>> practices when it comes to mailing list discussions. :-)
>>
>> Regards,
>> -sm
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
> http://www.ipinc.net/IPv4.GIF
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Bob Hinden]

Mike,

> Going back to the IAOC, I would ask whether this requirement was known at the 
> time of the previous Beijing discussion?  If so, why wasn't it brought up at 
> that point in time and as part of the discussion on venue acceptability.  If 
> it was added later, when was it added, and why wasn't the requirement made 
> known to the broader IETF prior to announcing the solution? Finally, I know 
> this is a hypothetical, but would this requirement have tipped the IAOC 
> decision the other way had it been known at the same time of the previous 
> discussion?
> 
> I don't mean to pick on either you or the IAOC - you both are doing a 
> reasonable job steering among the shoals of the needs of the various 
> constituencies - just consider this an inquiry into how the IETF should 
> decide on how to decide whether a venue is acceptable. 

I don't remember exactly when this came up, probably after the previous Beijing 
discussion.  It came up as part of the discussion with the host that in order 
to provide a non-filtered Internet connection as required in the MOU, they 
would need a mechanism to limit network access to only IETF meeting attendees.  
Since we were not there to provide a network to non-IETF attendees and doing 
simple admission control was common in venues like NANOG., I didn't think this 
was an unreasonable request, nor would it keep us from having a normal IETF 
meeting.  I would also note the that there is a lot of variance in different 
IETF venues, such as voltage, food, local languages, etc., etc.  I saw this as 
something in that class of differences, not as as something that would keep us 
from having a productive IETF meeting.

The IEFF NOC volunteer team has been working closely with the local host team 
to develop something that is as light weight as possible and still meet their 
requirements.

Hope this is helpful.

Bob






___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Ole Jacobsen]

SM,

Could you please summarize in one paragraph exactly what problem
you have with this setup?

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[SM]

At 08:26 01-07-10, Fred Baker wrote:
While it is new in IETF meetings, it is far from unusual in WiFi 
networks to find some form of authentication. This happens at coffee 
shops, college campuses, corporate campuses, and people's 
apartments. I think I would need some more data before I concluded 
this was unreasonable.


I didn't conclude that it was unreasonable for reasons that are not 
mentioned above.


At 08:41 01-07-10, Dave CROCKER wrote:
attendance includes many local folk.  Once upon a time, IETF 
meetings constituted an extremely collegial environment among folks 
who knew each other.  Today, attendance is much more diverse.


Yes.

At 08:50 01-07-10, Ole Jacobsen wrote:

 I would have to disagree. You were probably not even born when we
 had real terminal rooms with real terminals and computers and mean
 looking security guards who very much did check badges. As stewards


No comment.


 of the IETF meeting resources, I would say that it is perfectly
 reasonable for the IAOC (or the local host) to control access to
  to only meeting participants. There is no principal
 difference between cookies and network here as far as I am concerned.
 And as others have pointed out, access control to WiFi networks is
 the norm rather than the exception, even when they are "free".


Two points:

 1. Resources are finite
 2. There can be abuse

Having an open IETF network should not be read as an encouragement 
for abuse or to make abusive use of the resources.  Some people may 
read it as an encouragement to do that.  As long as that number is 
insignificant, it's not a problem.  These people should not read this 
as meaning that they will get away with abuse.


In my initial message I mentioned that "the person enjoyed the same 
privileges as those who have paid".  Strictly speaking, that's a side 
effect of not enforcing access control.  My message should also not 
be read as an encouragement not to pay to attend the meeting.  The 
IETF might not be sustainable without the revenue from attendance fees.


At 12:05 01-07-10, Russ Housley wrote:

Not totally right.  The person with a badge can get one or more slips
with anonymous registration ID/passwords.  The badge-holder can then
share the slip with accompanying persons (such as spouse or kids or <
let's not go there ;-) > ).


The paragraph about that in the announcement did not go unnoticed.

At 12:38 01-07-10, Martin Rex wrote:

Is there no more Terminal room on IETF these days with LAN access,
where access to the area is monitored but access to the network
is not de-anonymized?


There were such access at some point.  The IAOC may be able to 
confirm whether it will still be available.


At 16:19 01-07-10, Michael StJohns wrote:
I agree with the above statement, but its really beside the 
point.  The issue is not that the IETF and IETF attendees are 
required to obey the laws of the venue, but rather whether or not 
the IETF chooses to hold a meeting in a venue where the law is 
sufficiently ... restrictive, draconian, capricious, ?? ... 
to  require the IETF to change its model of operation.


There was a long discussion about that because the venue was 
selected.  My previous message was not to focus on that.


This was specific to the "hotel gets to cancel the meeting on a 
whim" issue, but seems somewhat applicable to this topic.  We're 
instituting a new set of mechanisms , specific to this venue, not 
driven by changes requested or suggested by the IETF. So we're not 
doing this as  "run it in a fashon as we always have".


Yes.

I would expect this (per user login) to fade away after Beijing - 
unless and until the IAOC and IETF agrees that its necessary for the 
longer term.  And I don't believe that discussion has been had.


Yes.

With respect to this - it's too late to change the venue - and we're 
at the whim of the venue governments and regulations so we're pretty 
much stuck.  I'm hoping that further restrictions or changes will 
not be imposed, but don't know that I'm confident that will be the case.


That's the reason why I didn't consider it as reasonable to argue 
about this change.  This does not mean that I would consider it as 
unreasonable if you or someone else was to raise such an argument.


Going back to the IAOC, I would ask whether this requirement was 
known at the time of the previous Beijing discussion?  If so, why 
wasn't it brought up at that point in time and as part of the 
discussion on venue acceptability.  If it was added later, when was 
it added, and why wasn't the requirement made known to the broader 
IETF prior to announcing the solution? Finally, I know this is a 
hypothetical, but would this requirement have tipped the IAOC 
decision the other way had it been known at the same time of the 
previous discussion?


These questions came to mind.  I preferred not to ask them.

I don't mean to pick on either you or the IAOC - you both are doing 
a reasonable job steering among the shoals of the needs of the 
va

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Douglas Otis]

On 7/1/10 8:26 AM, Fred Baker wrote:

While it is new in IETF meetings, it is far from unusual in WiFi networks to 
find some form of authentication. This happens at coffee shops, college 
campuses, corporate campuses, and people's apartments. I think I would need 
some more data before I concluded this was unreasonable.
   
Beijing is truly a big city.  Some reports show China has more Internet 
users than North America, with other regions being a distant third. 
Isn't restricting access using a MAC address passé?  Within these 
hundreds of millions of users, are popular intrusion tools, such those 
distributed on Ubuntu CDs being marketed as "Free Internet", that are 
able to quickly crack WEP, and even WPA.  Brute force techniques for 
WPA2 might even utilize low cost online services of clustered video 
cores run against captured initial four-way handshakes which should 
discourage use of simple pass phrases.


A reasonable chance of keeping access away from this savvy population, 
will likely require enterprise WPA2.  Otherwise, it might become popular 
during the event to use high-gain antennas to obtain uncensored access.  
Distribution of such content could prove embarrassing, especially when 
logs reveal it came over IETF networks.


-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Robert Moskowitz]

On 07/01/2010 11:50 AM, Ole Jacobsen wrote:

You wrote:

"It is clear to people unfamiliar with the IETF that IETF meeting
participants means people who have registered for the IETF meeting."

  Correct.

"I have been told that an IETF meeting does not have security guards
at the door to verify who has a badge to determine whether the person
is registered for the meeting. If someone walks into an IETF meeting,
the person can enjoy the cookie for free and even provide a
contribution at the mic. The person enjoys the same privileges as
people who have paid for meeting attendance fee."

  This is also true, but it is clearly not DESIGNED to let anyone
  participate for free in our meetings. I'd call this a "side-effect"
  that, if abused, would be remedied with exactly the kind of guards
  and badge checkers you envision. Participation in our PROCESS is open
  and can be achieved through mailing lists. Participation in our
  meetings has a real cost associated with it regardless of how it is
  funded. You are well aware of the fellowship program for example.

"The fashion in the IETF is to have an open network. There isn't any
admission control and credentials are not required to enjoy the
benefit of free and full Internet access. The IETF may run out of
cookies; it never runs out of bandwidth."

  I would have to disagree. You were probably not even born when we
  had real terminal rooms with real terminals and computers and mean
  looking security guards who very much did check badges. As stewards
  of the IETF meeting resources, I would say that it is perfectly
  reasonable for the IAOC (or the local host) to control access to
to only meeting participants. There is no principal
  difference between cookies


Remeber the Dallas IETF in DEc '95 when the hotel staff had to form a 
barrier to keep the MLM group also at the hotel away from our cookies 
and breakfast Cokes?  :)



and network here as far as I am concerned.
  And as others have pointed out, access control to WiFi networks is
  the norm rather than the exception, even when they are "free".

Cheers,

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

   

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Mike:

> Going back to the IAOC, I would ask whether this requirement
> was known at the time of the previous Beijing discussion?  If so,
> why wasn't it brought up at that point in time and as part of the
> discussion on venue acceptability.  If it was added later, when
> was it added, and why wasn't the requirement made known to the
> broader IETF prior to announcing the solution? Finally, I know
> this is a hypothetical, but would this requirement have tipped
> the IAOC decision the other way had it been known at the same
> time of the previous discussion?
>
> I don't mean to pick on either you or the IAOC - you both are doing
> a reasonable job steering among the shoals of the needs of the
> various constituencies - just consider this an inquiry into how the
> IETF should decide on how to decide whether a venue is acceptable.

In short, no, this was not known at the time the previous discussion
took place.  I could have raised this sooner, but I chose to wait until
a proposed solution was in hand so that everyone could understand the
impact.  Raising it earlier would have prompted questions that could not
be answered without a strawman for the solution.

In my view, the host is working diligently to ensure that the IETF
meeting participants have unfiltered access to the open Internet.

Russ





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Ted:

>> There's a difference, however, between ticking a box and having individual
>> user-attributable credentials.  The two techniques are focused on different
>> goals, generically binding users to an AUP, without caring who they are,
>> versus being able to identify individual users on the network (with more
>> detail than a MAC address).
>>
>> The proposal here is the latter, which would seem to raise the question of
>> why individual user attribution is necessary, i.e., why anonymity in the
>> IETF network unacceptable -- even within the pool of IETF participants.
> 
> I agree with Richard's view here, and I suggest the following
> modifications to the  proposed admission control:
> 
> 1) Use only paper-provided slips to provide authentication credentials.
> There is no stated reason for associating specific registration data
> with the network authentication method and it is trivial to provide
> the slips of paper to anyone with a proper badge.  Let the individual
> getting a slip shuffle the pile, get multiple slips every day, or do
> whatever else they would like to increase randomness.  But start from
> the presumption that the admission control is to limit access to
> "registered attendees only" not to provide an association to
> registration data.
> 
> 2) Favor anonymous MAC registration over portal methods.  Set up a
> terminal or group of terminals which allow individuals to register
> their MAC addresses for access.   Allow anyone with a badge access to
> those terminals, and do not collect information on which individual
> entered which MAC address.  (The portal mechanism relies on a specific
> ordering of application protocol activity at best; at worst it
> provides a full-on monkey-in-the-middle.  That should be a last
> resort)
> 
> 3) For the portal, there is no reason to have the MAC-based
> permissions created to be time limited.  If proper credentials from a
> slip of paper are entered, there is no reason not to treat this as
> equivalent to registration of the MAC address for the duration of the
> meeting.
> 
>  My personal preference is that this requirement from the host be
> politely declined as contrary to the usual operation of the IETF
> network.   But if it is not going to be declined, then the admission
> control should not further the ability to associate specific
> credentials to individuals.

A few points in response:

1) Anonymous slips are available to anyone with an IETF meeting badge
that wants them, as often as they want them, from two sources: the IETF
registration desk and the network help desk.

2) The MAC address registration is available at the network help desk.

3) I have not discussed the portal time limit with the NOC Team, but
I'll recommend that the registration work for the whole week.

Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Randy Bush]

> The issue is not that the IETF and IETF attendees are required to obey
> the laws of the venue, but rather whether or not the IETF chooses to
> hold a meeting in a venue where the law is sufficiently ...
> restrictive, draconian, capricious, ?? ... to require the IETF to
> change its model of operation.

i presume you are referring to the problems people from most countries
of the world have even entering the united states, being jailed while
trying to do so legitimately, etc.  very good point.

randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Michael StJohns]

At 02:52 PM 7/1/2010, Russ Housley wrote:
>No matter where a meeting is held, we are subject to the laws of that
>location.  Nothing new there.

Hi Russ -

I agree with the above statement, but its really beside the point.  The issue 
is not that the IETF and IETF attendees are required to obey the laws of the 
venue, but rather whether or not the IETF chooses to hold a meeting in a venue 
where the law is sufficiently ... restrictive, draconian, capricious, ?? ... to 
 require the IETF to change its model of operation.

As SM pointed out, the IAOC made the following determination when considering 
the Beijing venue:

>Whereas the IAOC heard all arguments made on the list, and
>  made its determination on the ability to hold a successful
>  meeting i.e. run it in a fashion as we always have, using the
>  tools that we always have, with a critical mass of the
>  traditional participants, discussing the usual topics."

This was specific to the "hotel gets to cancel the meeting on a whim" issue, 
but seems somewhat applicable to this topic.  We're instituting a new set of 
mechanisms , specific to this venue, not driven by changes requested or 
suggested by the IETF. So we're not doing this as  "run it in a fashon as we 
always have".

I would expect this (per user login) to fade away after Beijing - unless and 
until the IAOC and IETF agrees that its necessary for the longer term.  And I 
don't believe that discussion has been had.

With respect to this - it's too late to change the venue - and we're at the 
whim of the venue governments and regulations so we're pretty much stuck.  I'm 
hoping that further restrictions or changes will not be imposed, but don't know 
that I'm confident that will be the case.  

Going back to the IAOC, I would ask whether this requirement was known at the 
time of the previous Beijing discussion?  If so, why wasn't it brought up at 
that point in time and as part of the discussion on venue acceptability.  If it 
was added later, when was it added, and why wasn't the requirement made known 
to the broader IETF prior to announcing the solution? Finally, I know this is a 
hypothetical, but would this requirement have tipped the IAOC decision the 
other way had it been known at the same time of the previous discussion?

I don't mean to pick on either you or the IAOC - you both are doing a 
reasonable job steering among the shoals of the needs of the various 
constituencies - just consider this an inquiry into how the IETF should decide 
on how to decide whether a venue is acceptable. 

Thanks  - Mike




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Richard:

> Is there a reason that the anonymous IDs are opt-in?  Why not have all
> the IDs be anonymous?

Asked and answered.  I previously said:

: One reason for using the registration ID was to allow people to
: use the network before they check-in at the IETF registration desk.
: Another reason was fewer tasks for the people manning the IETF
: registration desk.

Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Ole Jacobsen]

We even had AppleTalk at IETF's for a while...

Much hair loss and greying since then. Yikes.

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[John C Klensin]

--On Friday, July 02, 2010 05:09 +0900 Randy Bush
 wrote:

>> The use of WLAN started out with a small group of early
>> adopters somewhere around 1996/1997.
> 
> earler, i believe.  i think i had wlan in s'hoim in 95, and
> ran the dhcp server experimaent on my laptop in the corner.
> but don't trust my memory, i don't.

I don't trust my memory either, but my recollection is that we
had 900 MHz WaveLAN/ Roamabout technology (with those big
paste-on-the-back transceivers) floating around a few years
before that.  Some relatively early meeting in Stockholm or Oslo
introduced us to an early 802.11a FHSS device and protocol.
Some of us bought the transceivers on the theory that it was the
coming thing, but I don't remember which meeting or the sequence
of events.

john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Randy Bush]

the only hard issue i have heard is log access and retention.  it is
clear radius logs, the only logs being used (aside from landings and
take-offs of black helicopters), should be destroyed at the end of the
meeting.  but should they be wiped more frequently?  

their intended use is solely for debugging for users who have problems
authenticating.  will folk be happy with not being able to check
"yesterday it worked, today not?"  if so, ops can destroy them nightly
or more frequently.

note that the ops group has no direct need for logs.  it's the users who
we presume want any authentication problems which they might have to be
debuggable.

randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Martin Rex]

Russ Housley wrote:
> 
> Yes, the slips obtained from the IETF registration desk and the network
> help desk are anonymous.  You show your badge, and then you can pick one
> or more slips from the container.  The people at the desk will not know
> which registration ID you got.

Thank your for the clarification.

To me this sounds like a kind of "virtual terminal room"
for use with WLAN.  The network access credentials are not personalized
and only indiciate that you're "in the terminal room" attaching
to the network.

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Randy Bush]

> I do remember the guarded terminal rooms in 1995-1998.

the terminals themselves were being guarded, not their use.  they were
expensive.  now there are no terminals in the terninal room.  so the
name was apt. :)

> The use of WLAN started out with a small group of early adopters
> somewhere around 1996/1997.

earler, i believe.  i think i had wlan in s'hoim in 95, and ran the dhcp
server experimaent on my laptop in the corner.  but don't trust my
memory, i don't.

> I'm not sure that the liability issues for open WLANs have been
> correctly described here.

i would assume not.  we're not lawyers, even though many seem to play
one on the net.

> IANAL and I'm german, and the IETF meeting is in the Netherlands.

and we're practicing for beijing.

randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Randy Bush]

>> "It is clear to people unfamiliar with the IETF that IETF meeting
>> participants means people who have registered for the IETF meeting."
> ... and their accompanying persons (who can also get a slip).

i see no reason to limit it to persons.  what if an attendee has a dog
with wifi, a wifi fifi?

randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Randy Bush]

> I'm concerned about the correlation between my MAC address and the
> hosts I communicate with.

and how and why would you suggest that be logged?  i am not aware radius
does that.

randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Joel Jaeggli]

It not necessary to log but it is necessary to create either a firewall ACL or 
an L2 fib entry at the time of authentication...

Joel's iPad

On Jul 1, 2010, at 12:32 PM, Iljitsch van Beijnum  wrote:

> On 1 jul 2010, at 21:20, Russ Housley wrote:
> 
>> Again, the use of anonymous registration IDs is available to you and
>> anyone that wants one.  If you are concerned about the logs, then you
>> should use one.
> 
> I'm concerned about the correlation between my MAC address and the hosts I 
> communicate with. Anonymous IDs don't help against that, but not logging 
> does, because then the only way for a government to obtain this correlation 
> is on an individual basis rather than casting a wide net that catches large 
> amounts of previously logged information.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[David Conrad]

On Jul 1, 2010, at 12:32 PM, Iljitsch van Beijnum wrote:
> I'm concerned about the correlation between my MAC address and the hosts I 
> communicate with.

Change your MAC address.

Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Richard:

Yes, the slips obtained from the IETF registration desk and the network
help desk are anonymous.  You show your badge, and then you can pick one
or more slips from the container.  The people at the desk will not know
which registration ID you got.

We will use this same approach for IETF 78 and IETF 79.  However, I
reserve the right to make process improvements based on the lessons
learned at IETF 78.

Russ

On 7/1/2010 2:59 PM, Richard L. Barnes wrote:
> Russ,
> 
> Couple of quick questions:
> -- Are the anonymous IDs truly anonymous (show existence of badge [not
> necessarily name on badge] and get one) or are they tied to a user
> identity? -- Will users be allowed to request multiple anonymous IDs? --
> Will these policies be identical for both IETF 78 and IETF 79?
> 
> Thanks,
> --Richard
> 
> 
> On Jul 1, 2010, at 2:52 PM, Russ Housley wrote:
> 
>> Andrew:
>>
 While it is new in IETF meetings, it is far from unusual in WiFi
 networks to find some form of authentication. This happens at coffee
 shops, college campuses, corporate campuses, and people's
 apartments.
>>>
>>> I'd hate to think that the IETF is modelling its networks on dodgy
>>> semi-opaque NAT boxes with bad DNS habits and poor performance.
>>>
>>> That aside, I have some questions.  What are the plans for logging of
>>> the authentication requests, failures, and successes, and who could
>>> legally have access to those logs?  In particular, are the governments
>>> of the countries where the (respective) events are to be held able to
>>> require that the logs be turned over?  How long will the logs be kept,
>>> and by whom?  (Obviously, these are not new issues, but given the
>>> increased ability under this approach to associate a particular human
>>> with one or more MAC addresses, it would seem that the status of such
>>> logging might be more important.)
>>
>> No matter where a meeting is held, we are subject to the laws of that
>> location.  Nothing new there.
>>
>> The use of anonymous registration IDs is available to anyone that wants
>> to go that route.  Anyone concerned about the logs should use one.
>>
>> The NOC Team sees no value in the logs after the meeting is over.  The
>> logs will be discarded by the NOC Team at the end of the meeting.  Of
>> course, during the meting they might be very hepful in debugging and
>> such.
>>
>> Russ
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Martin Rex]

Ole Jacobsen wrote:
> 
> > "I have been told that an IETF meeting does not have security guards 
> > at the door to verify who has a badge to determine whether the person 
> > is registered for the meeting.
> 
> > "The fashion in the IETF is to have an open network. There isn't any 
> > admission control and credentials are not required to enjoy the 
> > benefit of free and full Internet access. The IETF may run out of 
> > cookies; it never runs out of bandwidth."
> 
>  I would have to disagree. You were probably not even born when we 
>  had real terminal rooms with real terminals and computers and mean
>  looking security guards who very much did check badges.

I do remember the guarded terminal rooms in 1995-1998.  But
while the access to the room was guarded and badges were checked,
there was no monitoring or logging what you were doing at the
"terminals" (=PCs) or on your laptop that you attached to on
of the RJ-45 plugs.

Is there no more Terminal room on IETF these days with LAN access,
where access to the area is monitored but access to the network
is not de-anonymized?

The use of WLAN started out with a small group of early adopters
somewhere around 1996/1997.  IIRC someone working for Digital brought
along a small number of WLAN Adapters (pretty large, I believe PCMCIA-based)
and some folks taped it on the back of the lid of their laptops.


I'm not sure that the liability issues for open WLANs have been
correctly described here.  IANAL and I'm german, and the IETF
meeting is in the Netherlands.

If the meeting was in German and the IAOC wanted to obtain signed
voluntary(!) consent agreements from IETF particpants for collecting
personalized network traffic characteristics (e.g. DHCP leases),
before giving them network access credentials, then they would need
to ensure that these network access credentials can be individually
revoked at any time, because the consent agreement will be individually
revokable at any time, after which not more logging of that persons
traffic is permitted...

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Iljitsch van Beijnum]

On 1 jul 2010, at 21:20, Russ Housley wrote:

> Again, the use of anonymous registration IDs is available to you and
> anyone that wants one.  If you are concerned about the logs, then you
> should use one.

I'm concerned about the correlation between my MAC address and the hosts I 
communicate with. Anonymous IDs don't help against that, but not logging does, 
because then the only way for a government to obtain this correlation is on an 
individual basis rather than casting a wide net that catches large amounts of 
previously logged information.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Richard L. Barnes]

Is there a reason that the anonymous IDs are opt-in?  Why not have all  
the IDs be anonymous?





On Jul 1, 2010, at 3:20 PM, Russ Housley wrote:


Iljitsch:


This is useful, but not quite what I was asking.  Clearly, the above
means that the logs exist during the meeting, while we are at the  
host

venue.  I think it is safe to say that under some legal regimes, a
government could require the delivery of such existing logs to them.


I would very much appreciate assurances that such logging will not  
occur,

and that there will be no "live" feed of such information to third

parties,

such as government or law enforcement.

A week's worth of correlation between my MAC address and the IP  
addresses
that I exchange encrypted information with is not something I think  
any

government needs to have.

Of course if a government has cause to believe that a given user is
misbehaving they still have the option to talk to the NOC staff and
have them obtain information about this user.


As I said in my reply to Andrew, no matter where a meeting is held, we
are subject to the laws of that location.  Nothing new there.

We have received no requests for the kind of "live" feeds that you
suggest.  I'm quite sure that the NOC Team and the IAOC would push  
back

is such a request were made.

Again, the use of anonymous registration IDs is available to you and
anyone that wants one.  If you are concerned about the logs, then you
should use one.

Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Iljitsch:

>> This is useful, but not quite what I was asking.  Clearly, the above
>> means that the logs exist during the meeting, while we are at the host
>> venue.  I think it is safe to say that under some legal regimes, a
>> government could require the delivery of such existing logs to them.
>
> I would very much appreciate assurances that such logging will not occur,
> and that there will be no "live" feed of such information to third
parties,
> such as government or law enforcement.
>
> A week's worth of correlation between my MAC address and the IP addresses
> that I exchange encrypted information with is not something I think any
> government needs to have.
>
> Of course if a government has cause to believe that a given user is
> misbehaving they still have the option to talk to the NOC staff and
> have them obtain information about this user.

As I said in my reply to Andrew, no matter where a meeting is held, we
are subject to the laws of that location.  Nothing new there.

We have received no requests for the kind of "live" feeds that you
suggest.  I'm quite sure that the NOC Team and the IAOC would push back
is such a request were made.

Again, the use of anonymous registration IDs is available to you and
anyone that wants one.  If you are concerned about the logs, then you
should use one.

Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Not totally right.  The person with a badge can get one or more slips
with anonymous registration ID/passwords.  The badge-holder can then
share the slip with accompanying persons (such as spouse or kids or <
let's not go there ;-) > ).

Russ

On 7/1/2010 1:01 PM, Marshall Eubanks wrote:
> 
> On Jul 1, 2010, at 11:50 AM, Ole Jacobsen wrote:
>>
>> You wrote:
>>
>> "It is clear to people unfamiliar with the IETF that IETF meeting
>> participants means people who have registered for the IETF meeting."
>>
>> Correct.
> 
> ... and their accompanying persons (who can also get a slip).
> 
> Regards
> Marshall
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Richard:

> There's a difference, however, between ticking a box and having
> individual user-attributable credentials.  The two techniques are
> focused on different goals, generically binding users to an AUP, without
> caring who they are, versus being able to identify individual users on
> the network (with more detail than a MAC address).
> 
> The proposal here is the latter, which would seem to raise the question
> of why individual user attribution is necessary, i.e., why anonymity in
> the IETF network unacceptable -- even within the pool of IETF participants.

Anonymous access is available to anyone that cares to get a random
registration ID from the IETF registration desk or the network help
desk.  So, clearly that was not a motive.

One reason for using the registration ID was to allow people to use the
network before the checkin at the IETF registration desk.  Another
reason was fewer tasks for the people manning the IETF registration desk.

Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Richard L. Barnes]

Russ,

Couple of quick questions:
-- Are the anonymous IDs truly anonymous (show existence of badge [not  
necessarily name on badge] and get one) or are they tied to a user  
identity?  
-- Will users be allowed to request multiple anonymous IDs?  
-- Will these policies be identical for both IETF 78 and IETF 79?


Thanks,
--Richard


On Jul 1, 2010, at 2:52 PM, Russ Housley wrote:


Andrew:


While it is new in IETF meetings, it is far from unusual in WiFi
networks to find some form of authentication. This happens at coffee
shops, college campuses, corporate campuses, and people's
apartments.


I'd hate to think that the IETF is modelling its networks on dodgy
semi-opaque NAT boxes with bad DNS habits and poor performance.

That aside, I have some questions.  What are the plans for logging of
the authentication requests, failures, and successes, and who could
legally have access to those logs?  In particular, are the  
governments

of the countries where the (respective) events are to be held able to
require that the logs be turned over?  How long will the logs be  
kept,

and by whom?  (Obviously, these are not new issues, but given the
increased ability under this approach to associate a particular human
with one or more MAC addresses, it would seem that the status of such
logging might be more important.)


No matter where a meeting is held, we are subject to the laws of that
location.  Nothing new there.

The use of anonymous registration IDs is available to anyone that  
wants

to go that route.  Anyone concerned about the logs should use one.

The NOC Team sees no value in the logs after the meeting is over.  The
logs will be discarded by the NOC Team at the end of the meeting.  Of
course, during the meting they might be very hepful in debugging and  
such.


Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Russ Housley]

Andrew:

>> While it is new in IETF meetings, it is far from unusual in WiFi
>> networks to find some form of authentication. This happens at coffee
>> shops, college campuses, corporate campuses, and people's
>> apartments. 
> 
> I'd hate to think that the IETF is modelling its networks on dodgy
> semi-opaque NAT boxes with bad DNS habits and poor performance.  
> 
> That aside, I have some questions.  What are the plans for logging of
> the authentication requests, failures, and successes, and who could
> legally have access to those logs?  In particular, are the governments
> of the countries where the (respective) events are to be held able to
> require that the logs be turned over?  How long will the logs be kept,
> and by whom?  (Obviously, these are not new issues, but given the
> increased ability under this approach to associate a particular human
> with one or more MAC addresses, it would seem that the status of such
> logging might be more important.)

No matter where a meeting is held, we are subject to the laws of that
location.  Nothing new there.

The use of anonymous registration IDs is available to anyone that wants
to go that route.  Anyone concerned about the logs should use one.

The NOC Team sees no value in the logs after the meeting is over.  The
logs will be discarded by the NOC Team at the end of the meeting.  Of
course, during the meting they might be very hepful in debugging and such.

Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Ted Hardie]

On Thu, Jul 1, 2010 at 8:52 AM, Richard L. Barnes  wrote:
> There's a difference, however, between ticking a box and having individual
> user-attributable credentials.  The two techniques are focused on different
> goals, generically binding users to an AUP, without caring who they are,
> versus being able to identify individual users on the network (with more
> detail than a MAC address).
>
> The proposal here is the latter, which would seem to raise the question of
> why individual user attribution is necessary, i.e., why anonymity in the
> IETF network unacceptable -- even within the pool of IETF participants.
>

I agree with Richard's view here, and I suggest the following
modifications to the  proposed admission control:

1) Use only paper-provided slips to provide authentication credentials.
There is no stated reason for associating specific registration data
with the network authentication method and it is trivial to provide
the slips of paper to anyone with a proper badge.  Let the individual
getting a slip shuffle the pile, get multiple slips every day, or do
whatever else they would like to increase randomness.  But start from
the presumption that the admission control is to limit access to
"registered attendees only" not to provide an association to
registration data.

2) Favor anonymous MAC registration over portal methods.  Set up a
terminal or group of terminals which allow individuals to register
their MAC addresses for access.   Allow anyone with a badge access to
those terminals, and do not collect information on which individual
entered which MAC address.  (The portal mechanism relies on a specific
ordering of application protocol activity at best; at worst it
provides a full-on monkey-in-the-middle.  That should be a last
resort)

3) For the portal, there is no reason to have the MAC-based
permissions created to be time limited.  If proper credentials from a
slip of paper are entered, there is no reason not to treat this as
equivalent to registration of the MAC address for the duration of the
meeting.

 My personal preference is that this requirement from the host be
politely declined as contrary to the usual operation of the IETF
network.   But if it is not going to be declined, then the admission
control should not further the ability to associate specific
credentials to individuals.

Just two cents,

Ted Hardie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Iljitsch van Beijnum]

On 1 jul 2010, at 19:07, Andrew Sullivan wrote:

> This is useful, but not quite what I was asking.  Clearly, the above
> means that the logs exist during the meeting, while we are at the host
> venue.  I think it is safe to say that under some legal regimes, a
> government could require the delivery of such existing logs to them.

I would very much appreciate assurances that such logging will not occur, and 
that there will be no "live" feed of such information to third parties, such as 
government or law enforcement.

A week's worth of correlation between my MAC address and the IP addresses that 
I exchange encrypted information with is not something I think any government 
needs to have.

Of course if a government has cause to believe that a given user is misbehaving 
they still have the option to talk to the NOC staff and have them obtain 
information about this user.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Andrew Sullivan]

On Thu, Jul 01, 2010 at 09:42:16AM -0700, Joel Jaeggli wrote:
> It has been the documented practice of the ietf meeting network
> operations to limit the amount of pii data collected in operation or
> experimentation and to destroy logs containing pii data if they
> exist (example data collected by the IDS or formerly http proxy back
> when we ran one) after the meeting.

This is useful, but not quite what I was asking.  Clearly, the above
means that the logs exist during the meeting, while we are at the host
venue.  I think it is safe to say that under some legal regimes, a
government could require the delivery of such existing logs to them.
Once such logs have been delivered, then even if the meeting netops
people destroy the logs, the logs can persist.  Right?

What I'm trying to find out is what assurances, if any, we have about
the ability of the IETF to remain in sole control of the data.  I'm
not really a paranoid type, but perhaps the recent experience of
Toronto police simply lying (with government collusion) about what
powers they had to detain people during the recent G20 meeting has
made me a little sensitive to this kind of (surprise, new)
requirement.  I would also likely care less, except the whole point of
this effort is plainly to support one government's policy -- a policy
that I find odious, and one that appears at least once to have had
technical side effects on the global DNS.  I'll leave aside the optics
of announcing the new policy less than a month before it is to be
implemented, and after people have already made travel plans, paid
meeting fees, and so on.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Marshall Eubanks]

On Jul 1, 2010, at 11:50 AM, Ole Jacobsen wrote:



You wrote:

"It is clear to people unfamiliar with the IETF that IETF meeting
participants means people who have registered for the IETF meeting."

Correct.


... and their accompanying persons (who can also get a slip).

Regards
Marshall



"I have been told that an IETF meeting does not have security guards
at the door to verify who has a badge to determine whether the person
is registered for the meeting. If someone walks into an IETF meeting,
the person can enjoy the cookie for free and even provide a
contribution at the mic. The person enjoys the same privileges as
people who have paid for meeting attendance fee."

This is also true, but it is clearly not DESIGNED to let anyone
participate for free in our meetings. I'd call this a "side-effect"
that, if abused, would be remedied with exactly the kind of guards
and badge checkers you envision. Participation in our PROCESS is open
and can be achieved through mailing lists. Participation in our
meetings has a real cost associated with it regardless of how it is
funded. You are well aware of the fellowship program for example.

"The fashion in the IETF is to have an open network. There isn't any
admission control and credentials are not required to enjoy the
benefit of free and full Internet access. The IETF may run out of
cookies; it never runs out of bandwidth."

I would have to disagree. You were probably not even born when we
had real terminal rooms with real terminals and computers and mean
looking security guards who very much did check badges. As stewards
of the IETF meeting resources, I would say that it is perfectly
reasonable for the IAOC (or the local host) to control access to
 to only meeting participants. There is no principal
difference between cookies and network here as far as I am concerned.
And as others have pointed out, access control to WiFi networks is
the norm rather than the exception, even when they are "free".

Cheers,

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Joel Jaeggli]

It has been the documented practice of the ietf meeting network operations to 
limit the amount of pii data collected in operation or experimentation and to 
destroy logs containing  pii data if they exist (example data collected by the 
IDS or formerly http proxy back when we ran one) after the meeting.

One can refer to the RFID experiment and discussion for another example of pii 
data handling in ietf experiments.

Joel's iPad

On Jul 1, 2010, at 8:44 AM, Andrew Sullivan  wrote:

> On Thu, Jul 01, 2010 at 08:26:35AM -0700, Fred Baker wrote:
> 
>> While it is new in IETF meetings, it is far from unusual in WiFi
>> networks to find some form of authentication. This happens at coffee
>> shops, college campuses, corporate campuses, and people's
>> apartments. 
> 
> I'd hate to think that the IETF is modelling its networks on dodgy
> semi-opaque NAT boxes with bad DNS habits and poor performance.  
> 
> That aside, I have some questions.  What are the plans for logging of
> the authentication requests, failures, and successes, and who could
> legally have access to those logs?  In particular, are the governments
> of the countries where the (respective) events are to be held able to
> require that the logs be turned over?  How long will the logs be kept,
> and by whom?  (Obviously, these are not new issues, but given the
> increased ability under this approach to associate a particular human
> with one or more MAC addresses, it would seem that the status of such
> logging might be more important.)
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@shinkuro.com
> Shinkuro, Inc.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Ole Jacobsen]

You wrote:

"It is clear to people unfamiliar with the IETF that IETF meeting 
participants means people who have registered for the IETF meeting."

 Correct.

"I have been told that an IETF meeting does not have security guards 
at the door to verify who has a badge to determine whether the person 
is registered for the meeting. If someone walks into an IETF meeting, 
the person can enjoy the cookie for free and even provide a 
contribution at the mic. The person enjoys the same privileges as 
people who have paid for meeting attendance fee."

 This is also true, but it is clearly not DESIGNED to let anyone 
 participate for free in our meetings. I'd call this a "side-effect"
 that, if abused, would be remedied with exactly the kind of guards
 and badge checkers you envision. Participation in our PROCESS is open 
 and can be achieved through mailing lists. Participation in our 
 meetings has a real cost associated with it regardless of how it is
 funded. You are well aware of the fellowship program for example.

"The fashion in the IETF is to have an open network. There isn't any 
admission control and credentials are not required to enjoy the 
benefit of free and full Internet access. The IETF may run out of 
cookies; it never runs out of bandwidth."

 I would have to disagree. You were probably not even born when we 
 had real terminal rooms with real terminals and computers and mean
 looking security guards who very much did check badges. As stewards
 of the IETF meeting resources, I would say that it is perfectly 
 reasonable for the IAOC (or the local host) to control access to
  to only meeting participants. There is no principal
 difference between cookies and network here as far as I am concerned.
 And as others have pointed out, access control to WiFi networks is
 the norm rather than the exception, even when they are "free".

Cheers,

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Richard L. Barnes]

There's a difference, however, between ticking a box and having  
individual user-attributable credentials.  The two techniques are  
focused on different goals, generically binding users to an AUP,  
without caring who they are, versus being able to identify individual  
users on the network (with more detail than a MAC address).


The proposal here is the latter, which would seem to raise the  
question of why individual user attribution is necessary, i.e., why  
anonymity in the IETF network unacceptable -- even within the pool of  
IETF participants.


BTW, the trend cited here of more networks requiring more  
authentication also goes the other way:






On Jul 1, 2010, at 11:41 AM, Dave CROCKER wrote:




On 7/1/2010 8:26 AM, Fred Baker wrote:
While it is new in IETF meetings, it is far from unusual in WiFi  
networks to
find some form of authentication. This happens at coffee shops,  
college
campuses, corporate campuses, and people's apartments. I think I  
would need

some more data before I concluded this was unreasonable.



+1

Small towns often have an environment that makes it reasonable to  
leave one's doors unlocked.  Large cities rarely do.  The IETF is  
now part of a very big city.  Restricting wifi access to authorized  
personnel has become not only the norm, but the expected and often  
the required.


Small added note about physical security:

As SM noted, we don't have monitors at the meeting room doors.  Even  
with them, meeting attendance includes many local folk.  Once upon a  
time, IETF meetings constituted an extremely collegial environment  
among folks who knew each other.  Today, attendance is much more  
diverse.


One aspect of the diversity is that we need to treat meetings rooms  
as fully public places, with the attendant risks.  The risk is not  
terrible, but it /is/ real.


There have been thefts in these rooms, in multiple meeting cities,  
where property was stolen rather boldly, such as from underneath the  
seat of an attendee.


We need to watch our personal property as if the person sitting next  
to us, or behind us, might steal it.


Because some of them have.

d/
--

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Andrew Sullivan]

On Thu, Jul 01, 2010 at 08:26:35AM -0700, Fred Baker wrote:

> While it is new in IETF meetings, it is far from unusual in WiFi
> networks to find some form of authentication. This happens at coffee
> shops, college campuses, corporate campuses, and people's
> apartments. 

I'd hate to think that the IETF is modelling its networks on dodgy
semi-opaque NAT boxes with bad DNS habits and poor performance.  

That aside, I have some questions.  What are the plans for logging of
the authentication requests, failures, and successes, and who could
legally have access to those logs?  In particular, are the governments
of the countries where the (respective) events are to be held able to
require that the logs be turned over?  How long will the logs be kept,
and by whom?  (Obviously, these are not new issues, but given the
increased ability under this approach to associate a particular human
with one or more MAC addresses, it would seem that the status of such
logging might be more important.)

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Dave CROCKER]

On 7/1/2010 8:26 AM, Fred Baker wrote:

While it is new in IETF meetings, it is far from unusual in WiFi networks to
find some form of authentication. This happens at coffee shops, college
campuses, corporate campuses, and people's apartments. I think I would need
some more data before I concluded this was unreasonable.



+1

Small towns often have an environment that makes it reasonable to leave one's 
doors unlocked.  Large cities rarely do.  The IETF is now part of a very big 
city.  Restricting wifi access to authorized personnel has become not only the 
norm, but the expected and often the required.


Small added note about physical security:

As SM noted, we don't have monitors at the meeting room doors.  Even with them, 
meeting attendance includes many local folk.  Once upon a time, IETF meetings 
constituted an extremely collegial environment among folks who knew each other. 
 Today, attendance is much more diverse.


One aspect of the diversity is that we need to treat meetings rooms as fully 
public places, with the attendant risks.  The risk is not terrible, but it /is/ 
real.


There have been thefts in these rooms, in multiple meeting cities, where 
property was stolen rather boldly, such as from underneath the seat of an attendee.


We need to watch our personal property as if the person sitting next to us, or 
behind us, might steal it.


Because some of them have.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Olivier MJ Crepin-Leblond]

Le 01/07/2010 17:26, Fred Baker a écrit :
> While it is new in IETF meetings, it is far from unusual in WiFi networks to 
> find some form of authentication. This happens at coffee shops, college 
> campuses, corporate campuses, and people's apartments. I think I would need 
> some more data before I concluded this was unreasonable.
>   

This is about to become law in several European countries (or maybe it
already *is* law in some), and the signing-up process protects the WIFI
provider from liability by having the user agree to an acceptable use
policy (AUP), a process consisting of ticking a box.

Kind regards,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[Fred Baker]

While it is new in IETF meetings, it is far from unusual in WiFi networks to 
find some form of authentication. This happens at coffee shops, college 
campuses, corporate campuses, and people's apartments. I think I would need 
some more data before I concluded this was unreasonable.

On Jul 1, 2010, at 8:08 AM, SM wrote:

> Hello,
> At 14:55 30-06-10, IETF Chair wrote:
>> I am writing to let you know about a change in the IETF meeting network.
>> At IETF 79 in Beijing, the IETF network will be connected to the open
>> Internet with absolutely no filtering.  However, we have agreed with our
>> hosts that only IETF meeting participants will have access to the
>> network.  Following sound engineering practices, we will deploy
>> admission control mechanisms as part of the IETF 78 meeting network in
>> Maastricht to ensure that they are working properly before they are
>> mission critical.
> 
> Most IETF participants probably know that the consensus of the IETF is 
> documented through BCPs and other Standards Track RFCs.  If the text in the 
> RFC isn't clear, there is room for disagreement.  If it is ill-defined, 
> someone will go and find the loophole.  If the above text was in a BCP, we 
> could nit on the definition of IETF meeting participants.  It is clear to 
> people unfamiliar with the IETF that IETF meeting participants means people 
> who have registered for the IETF meeting.
> 
> I have been told that an IETF meeting does not have security guards at the 
> door to verify who has a badge to determine whether the person is registered 
> for the meeting.  If someone walks into an IETF meeting, the person can enjoy 
> the cookie for free and even provide a contribution at the mic.  The person 
> enjoys the same privileges as people who have paid for meeting attendance fee.
> 
> I'll take the opportunity to thank Karen O'Donoghue for keeping the IAOC 
> minutes up to date.  The IAB could do with some help in that area.
> 
> Some of you may recall that the Beijing venue contract was discussed on this 
> mailing list last year.  It resulted in some resolutions as follows:
> 
> "Whereas the Host has assured the IAOC that 'a normal IETF
>  meeting can be legally held in China and that no pre-screening
>  of material or monitoring of session content is required or will
>  be done,'
> 
>  Whereas the IAOC, based on the assurances of the Host and a
>  history of the venue successfully hosting major international
>  conferences that relate to our industry, believes a normal IETF
>  meeting can be held at the venue,
> 
>  Whereas the IAOC heard all arguments made on the list, and
>  made its determination on the ability to hold a successful
>  meeting i.e. run it in a fashion as we always have, using the
>  tools that we always have, with a critical mass of the
>  traditional participants, discussing the usual topics."
> 
> The fashion in the IETF is to have an open network.  There isn't any 
> admission control and credentials are not required to enjoy the benefit of 
> free and full Internet access.  The IETF may run out of cookies; it never 
> runs out of bandwidth.
> 
>> I am writing to let you know what to expect in both Maastricht and Beijing.
> 
> And it is expected that the comments on this thread will follow sound IETF 
> practices when it comes to mailing list discussions. :-)
> 
> Regards,
> -sm 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

http://www.ipinc.net/IPv4.GIF

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Admission Control to the IETF 78 and IETF 79 Networks

[SM]

Hello,
At 14:55 30-06-10, IETF Chair wrote:

I am writing to let you know about a change in the IETF meeting network.
At IETF 79 in Beijing, the IETF network will be connected to the open
Internet with absolutely no filtering.  However, we have agreed with our
hosts that only IETF meeting participants will have access to the
network.  Following sound engineering practices, we will deploy
admission control mechanisms as part of the IETF 78 meeting network in
Maastricht to ensure that they are working properly before they are
mission critical.


Most IETF participants probably know that the consensus of the IETF 
is documented through BCPs and other Standards Track RFCs.  If the 
text in the RFC isn't clear, there is room for disagreement.  If it 
is ill-defined, someone will go and find the loophole.  If the above 
text was in a BCP, we could nit on the definition of IETF meeting 
participants.  It is clear to people unfamiliar with the IETF that 
IETF meeting participants means people who have registered for the 
IETF meeting.


I have been told that an IETF meeting does not have security guards 
at the door to verify who has a badge to determine whether the person 
is registered for the meeting.  If someone walks into an IETF 
meeting, the person can enjoy the cookie for free and even provide a 
contribution at the mic.  The person enjoys the same privileges as 
people who have paid for meeting attendance fee.


I'll take the opportunity to thank Karen O'Donoghue for keeping the 
IAOC minutes up to date.  The IAB could do with some help in that area.


Some of you may recall that the Beijing venue contract was discussed 
on this mailing list last year.  It resulted in some resolutions as follows:


 "Whereas the Host has assured the IAOC that 'a normal IETF
  meeting can be legally held in China and that no pre-screening
  of material or monitoring of session content is required or will
  be done,'

  Whereas the IAOC, based on the assurances of the Host and a
  history of the venue successfully hosting major international
  conferences that relate to our industry, believes a normal IETF
  meeting can be held at the venue,

  Whereas the IAOC heard all arguments made on the list, and
  made its determination on the ability to hold a successful
  meeting i.e. run it in a fashion as we always have, using the
  tools that we always have, with a critical mass of the
  traditional participants, discussing the usual topics."

The fashion in the IETF is to have an open network.  There isn't any 
admission control and credentials are not required to enjoy the 
benefit of free and full Internet access.  The IETF may run out of 
cookies; it never runs out of bandwidth.



I am writing to let you know what to expect in both Maastricht and Beijing.


And it is expected that the comments on this thread will follow sound 
IETF practices when it comes to mailing list discussions. :-)


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Admission Control to the IETF 78 and IETF 79 Networks

[IETF Chair]

I am writing to let you know about a change in the IETF meeting network.
At IETF 79 in Beijing, the IETF network will be connected to the open
Internet with absolutely no filtering.  However, we have agreed with our
hosts that only IETF meeting participants will have access to the
network.  Following sound engineering practices, we will deploy
admission control mechanisms as part of the IETF 78 meeting network in
Maastricht to ensure that they are working properly before they are
mission critical.

I am writing to let you know what to expect in both Maastricht and Beijing.


ADMISSION CONTROL CREDENTIALS

To gain access to the IETF network, you will need to provide a
credential. Your primary credential will be your registration ID.  You
can find your registration ID on the registration web page, in the
response email confirmation you received from the Secretariat, on your
payment receipt, and on the back of your IETF meeting badge.  Your
Registration ID will be your user name, and it will be used with a
password that will be provided at a later date.  This same password will
be used by all attendees.

We recognize that IETF 78 registration IDs are very easy to guess.  We
expect to use less easily guessed registration IDs for IETF 79.

If for any reason you are uncomfortable using your Registration ID,
there will be a supply of completely anonymous Registration ID/Password
pairs on slips of paper available at the help desk and registration
desk.  You will be asked to show an IETF meeting badge to ensure that
slips are only provided to registered meeting attendees.

Each set of credentials will allow up to three separate MAC addresses on
the network, allowing attendees to use the same credential for their
laptop, phone, or other devices.  The limit is to prevent the leak of a
single credential from undermining the entire system.


GAINING ACCESS TO THE NETWORK

The primary mechanism to gain access to the wireless network will be
either the "ietf.1x" or "ietf-a.1x" SSID.  These will be configured with
WPA1 and WPA2 Enterprise.  You simply provide your credentials to your
supplicant software for authentication to the network.  I personally
encourage you to use WPA2 over WPA1 if your software and hardware
support both.

If your software does not support WPA Enterprise, you can use the
captive portal.  To use this portal, associate with either the
"ietf-portal" or "ietf-a-portal" SSID.  Upon initial connection,
Internet connectivity will be blocked.  Simply open a browser and go to
any web site, just like many hotel networks, and you will be redirected
to a portal page where you can enter your credentials.  Once the
credentials are validated, your MAC address will have unrestricted
access to the network for some period of time.  The portal page will
also have links to the internal wiki page with helpful information as
well as a way to create trouble tickets prior to authentication.

If your small devices does not support WPA Enterprise and does not have
a browser, then you will be able to visit the help desk and register the
device MAC address for access to the network.  If you need to register
your device, please know the MAC address of your device before you show
up at the help desk.


FALLBACK PLAN

Implementing this plan at IETF 78 in Maastricht is important, but
obviously not without risk.  The IEEE 802.1X-based access mechanisms
have been well tested at previous meetings, and this mechanism is not
likely to be a source of trouble.  The captive portal, however, is a
greater unknown.  Please use the WPA SSIDs if at all possible to reduce
the load on the portal machines.  If the portals do experience problems,
the NOC team will implement a backup plan.  The backup plan will only be
used as a last resort as the backup plan will not be an option at IETF
79 in Beijing.


Safe Travel and Best Wishes,
  Russ Housley
  IETF Chair

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf