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

From: SM <[email-masked]>
Date: Thu, 01 Jul 2010 08:08:09 -0700

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 1 Jul 2010 08:26:35 -0700

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:

> 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:
> 
> 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

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

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Thu, 01 Jul 2010 17:39:38 +0200

> 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 apart…

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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 01 Jul 2010 08:41:45 -0700

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Jul 2010 11:44:21 -0400

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
[email-masked]
Shinkuro, Inc.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 1 Jul 2010 11:52:29 -0400

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:
<http://www.starbucks.com/blog/22761/free-one-click-wi-fi-is-coming>

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

>> networks to
> 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.
>
> 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.
>

---

From: Ole Jacobsen <[email-masked]>
Date: Thu, 1 Jul 2010 08:50:50 -0700 (PDT)

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
 <insert resource> 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: [email-masked]  URL: http://www.cisco.com/ipj

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 1 Jul 2010 09:42:16 -0700

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

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 1 Jul 2010 13:01:34 -0400

> participants means people who have registered for the IETF meeting."

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

Regards
Marshall

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Jul 2010 13:07:45 -0400

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
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 Jul 2010 19:18:12 +0200

> 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.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Jul 2010 10:49:37 -0700

On Thu, Jul 1, 2010 at 8:52 AM, Richard L. Barnes <[email-masked]> 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 01 Jul 2010 14:52:54 -0400

> 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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 1 Jul 2010 14:59:33 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 01 Jul 2010 15:00:08 -0400

Richard:

> 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 01 Jul 2010 15:05:31 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 01 Jul 2010 15:20:34 -0400

Iljitsch:

> 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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 1 Jul 2010 15:28:10 -0400

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 Jul 2010 21:32:16 +0200

> anyone that wants one.  If you are concerned about the logs, then you

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.

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2010 21:38:13 +0200 (MEST)

Ole Jacobsen wrote:
> > is registered for the meeting.
> 
>  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

---

From: Russ Housley <[email-masked]>
Date: Thu, 01 Jul 2010 15:43:26 -0400

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:
> identity? -- Will users be allowed to request multiple anonymous IDs? --
> Will these policies be identical for both IETF 78 and IETF 79?
> 
> Thanks,
> --Richard
> 
>

---

From: David Conrad <[email-masked]>
Date: Thu, 1 Jul 2010 12:59:03 -0700

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

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 1 Jul 2010 12:58:51 -0700

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Jul 2010 04:59:33 +0900

> hosts I communicate with.

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

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Jul 2010 05:02:23 +0900

> ... 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

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Jul 2010 05:09:01 +0900

> 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. :)

> 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.

> 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

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2010 22:09:01 +0200 (MEST)

> 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

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Jul 2010 05:21:38 +0900

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Jul 2010 16:42:36 -0400

--On Friday, July 02, 2010 05:09 +0900 Randy Bush
<[email-masked]> 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

---

From: Ole Jacobsen <[email-masked]>
Date: Thu, 1 Jul 2010 13:44:57 -0700 (PDT)

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

Much hair loss and greying since then. Yikes.

Ole

Ole J. Jacobsen

---

From: Russ Housley <[email-masked]>
Date: Thu, 01 Jul 2010 17:35:40 -0400

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

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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 01 Jul 2010 19:19:19 -0400

>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.

>  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

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Jul 2010 10:17:24 +0900

> 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 01 Jul 2010 21:19:40 -0400

> 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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 02 Jul 2010 10:17:19 -0400

On 07/01/2010 11:50 AM, Ole Jacobsen wrote:
>   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.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Jul 2010 10:31:45 -0700

> 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 apart…
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

---

From: SM <[email-masked]>
Date: Fri, 02 Jul 2010 07:36:05 -0700

At 08:26 01-07-10, Fred Baker wrote:
>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.

>  looking security guards who very much did check badges. As stewards

No comment.

>  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.

>let's not go there ;-) > ).

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

>where access to the area is monitored but access to the network

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 
>various constituencies - just consider this an inquiry into how the 
>IETF should decide on how to decide whether a venue is acceptable.

Agreed.

At 20:27 01-07-10, Health wrote:
>ietf internet access is only for ietfers for free.

What is your definition of "ietfers"?

My initial message was more about social distance.  I don't know 
whether the admission control requirement is a sign that the gap 
cannot be bridged.

Regards,
-sm

---

From: Ole Jacobsen <[email-masked]>
Date: Fri, 2 Jul 2010 11:33:35 -0700 (PDT)

SM,

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

Ole

Ole J. Jacobsen

---

From: Bob Hinden <[email-masked]>
Date: Fri, 2 Jul 2010 11:52:34 -0700

Mike,

> 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 th…

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Jul 2010 20:30:02 -0400

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.

-- 
Website: http://hallambaker.com/

---

From: SM <[email-masked]>
Date: Fri, 02 Jul 2010 15:25:17 -0700

Hi Ole,
>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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 3 Jul 2010 18:02:31 +0200

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

> 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

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.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 3 Jul 2010 12:03:51 -0400

> 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

---

From: Marocco Enrico <[email-masked]>
Date: Sat, 3 Jul 2010 20:27:55 +0200

+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.

---

From: Ole Jacobsen <[email-masked]>
Date: Sat, 3 Jul 2010 12:17:30 -0700 (PDT)

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

---

From: Marocco Enrico <[email-masked]>
Date: Sun, 4 Jul 2010 13:26:41 +0200

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

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 4 Jul 2010 08:22:28 -0700

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 3 Jul 2010 15:13:28 -0400

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.

---

From: Chris Elliott <[email-masked]>
Date: Tue, 6 Jul 2010 11:59:50 -0400

> of the computer or the fingerprint of the cert.

MAC secure? Surely you jest.

> > 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
> > 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.
> >
> >
>
>
>
> --

-- 
Chris Elliott
[email-masked]

---

From: [email-masked]
Date: Tue, 6 Jul 2010 13:06:31 -0400

> 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

---

From: Mark Atwood <[email-masked]>
Date: Tue, 6 Jul 2010 11:37:20 -0700

> 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

---

From: Chris Elliott <[email-masked]>
Date: Tue, 6 Jul 2010 15:12:25 -0400

> 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.

-- 
Chris Elliott
[email-masked]
CCIE # 2013

---

From: joel jaeggli <[email-masked]>
Date: Tue, 06 Jul 2010 20:23:40 -0700

> 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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Jul 2010 15:32:55 -0400

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

MAC address XXXXX is not very interesting
MAC address that party purporting to be CISCO says is XXXXX is quite a
bit more interesting
MAC address that party validated as CISCO as XXXXX 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.

---

From: Chris Elliott <[email-masked]>
Date: Mon, 12 Jul 2010 11:56:34 -0400

Phillip,

In your earlier email, you state:

> of the computer or the fingerprint of the cert.

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

> the certificate.

Maybe you should check your waist.

Chris.

-- 
Chris Elliott
[email-masked]

---

From: Chris Elliott <[email-masked]>
Date: Mon, 12 Jul 2010 13:53:40 -0400

On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker <[email-masked]>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 <[email-masked]>
> wrote:
> > Phillip,

-- 
Chris Elliott
[email-masked]
CCIE # 2013

---

From: Martin Rex <[email-masked]>
Date: Mon, 12 Jul 2010 20:39:28 +0200 (MEST)

> 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

---

From: Chris Elliott <[email-masked]>
Date: Mon, 12 Jul 2010 15:12:13 -0400

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 <[email-masked]> 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 <[email-masked]> wrote:

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Jul 2010 20:05:40 -0700

> 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.
> it is absolutely unnecessary.
Securing wireless must detect MitM attack. Using a cert at the server 
when making changes seems a small price.

-Doug

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Jul 2010 23:12:43 -0400

See belos ...

>> ...

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 )

>> ...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Jul 2010 12:07:05 -0400

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Jul 2010 14:35:34 -0400

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Jul 2010 15:54:15 -0400

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jul 2010 12:05:21 -0400

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.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Jul 2010 18:45:18 +0200

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

> 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.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Jul 2010 13:38:28 +0200

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

---

From: IETF Chair <[email-masked]>
Date: Sat, 24 Jul 2010 09:19:22 -0400

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:
> ADMISSION CONTROL CREDENTIALS
> 
> 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
>

---

From: Josh Howlett <[email-masked]>
Date: Mon, 26 Jul 2010 12:28:22 +0000

> Since we expect a reasonable attendance at IETF from
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 24 Jul 2010 14:37:31 -0400

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

Might be something that maybe deserves to see wider use.