Subject: Some more background on the RFID experiment in Hiroshima

From: Ole Jacobsen <[email-masked]>
Date: Thu, 10 Sep 2009 12:23:31 -0700 (PDT)

An Overview of the RFID Experiment for IETF 76 in Hiroshima.
------------------------------------------------------------

Some of the details are still being worked out, but here is a summary:

Basics
------

* Each attendee will be issued an RFID card at the registration desk. 
  The information stored on the card is ONLY a number, no personal 
  data is stored on the card. (Note: the attendee can opt out at any
  time, including not collecting the card, see below).

* The "information" (number) on the card is not encrypted and could be 
  read by any RFID reader, but again, it's only a number.

* The number is "linked" to a back-end database through the readers 
  provided at the meeting.

* The database will contain only the following information from the
  registration data:

First Name, Last Name, Affiliation (if present), and ISO-3166 Code

* Each attendee will also be issued a username and password. This will
  give him/her access to the back-end database (via a web interface)
  where the user can:

-- Change password (user will be strongly encouraged to change pasword 
   on first login)

-- Change the User's Profile: Name, Affiliation, ISO-3166 Code, or add
   data, such as a photo, alias name, dietary preference etc, etc.)

-- Delete account to opt out of the experiment at any time.

Uses of the System
------------------

There are several planned uses of the RFID cards:

1. Speaker-at-microphone identification. A reader attached to the
   microphone(s) reads the card and causes his/her name any other info that
   the user has elected to include in the Profile to be displayed on the
   screen.

   [Note: Certain information may be displayed by default, but this will be
   user-configurable, for example I may choose NOT to have "Cisco Systems"
   displayed when I am at the microphone, but for statistical purposed it may
   still be OK to count the number of people from Cisco in summary form. The
   profile will have options to "display" or "don't display" certain fields.
   It will also be possible for me to have a DIFFERENT affiliation when I am
   standing at the microphone if I opt to have the "alias" affiliation (or
   none) displayed instead of my normal one].

2. Electronic bluesheet: Used in a manner similar to the paper blusheets to
   record attendance in a given working group/session. This is NOT intended to
   replace the paper bluesheets, even if one could envision such in the future.

3. Customized uses: Various information can be customized based on the
   user's profile. So, suppose my profile contains a "dietary" field which
   says "vegetarian," an information display could show me a list of
   vegetarian restaurants. There will be some examples of this at IETF 76 in
   Hiroshima.

Data rentention
---------------

The data collected in this experiment will only be used for basic 
statistical purposes. Since there is a blue-sheet component to this 
experiment it will be useful to compare the real bluesheet data with 
the electronic equivalent, but the official (legal) attendance record 
will still be based on the paper version. And the database will then 
be deleted.

The PASPY Card
--------------

Attendees who sign up for the IETF 76 Social will receive SECOND, 
different kind of RFID card, called PASPY. The PASPY card is an 
example of a "stored value" system which is increasingly being used in 
Japan and elsewhere, mostly for public transportation systems. In 
Hiroshima, PASPY is currently valid on the tram and bus system, with 
more systems underway. The PASPY cards are NOT linked to the IETF 76 
database or associated in any way with the RFID cards described above.

Please see: http://www.yikes.com/~ole/store/Hiroshima/Trains.htm

Wikipedia article: http://en.wikipedia.org/wiki/PASPY

The PASPY cards are contributed by the City of Hiroshima. They have a 
pre-loaded amount of 1,000 yen and can be used on the local 
transportation system and allow free access to the Hiroshima Peace 
Museum. No personal information is stored on these cards, but I will 
note that it is *possible* to register your card so that it can be 
disabled (or returned to its owner) if lost or stolen. Take a look at 
this picture: http://www.yikes.com/~ole/store/cards.jpg

If you read katakana you will notice that this PASPY card says, the 
equivalent of: "Jacobsen Ole". I think the only information I gave 
them was my cellphone number, but the registration form allows more 
information to be recorded. (Of course none of this is stored on the 
card itself).

Obviously, if you use your PASPY card extensively during the IETF, you 
may need to reload it with more money. More information on where you 
can use the PASPY card, how to reload it and so on will be provided by 
the local host onsite. There may also be some IETF76-customized uses 
of the PASPY card, but again, it's not linked to the back-end database 
described above.

I hope this answers some of the questions posted to the IETF list 
regarding the RFID experiment. As I said, the local host is still 
working hard to implement some of the details. We hope you will 
participate and provide feedback.

Ole J. Jacobsen, IAOC Meetings Committee

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: Eric Rescorla <[email-masked]>
Date: Fri, 11 Sep 2009 06:52:31 -0700

At Thu, 10 Sep 2009 12:23:31 -0700 (PDT),
> An Overview of the RFID Experiment for IETF 76 in Hiroshima.

Note that removing your name from the database doesn't remove the
ability of someone to track you via the tag.

>   read by any RFID reader, but again, it's only a number.

How are the numbers assigned?

>   give him/her access to the back-end database (via a web interface)

Does the Web UI make sure to hide the number->attendee mapping?

-Ekr

---

From: Ole Jacobsen <[email-masked]>
Date: Fri, 11 Sep 2009 07:57:02 -0700 (PDT)

Inline.

> ability of someone to track you via the tag.

If this is a great concern I would suggest either returning the card 
or not collecting it in the first place. Also, the type or readers 
used require close proximity to trigger, you literally have to touch 
the reader with your card to make it work. So nobody from the host 
organization at least will be tracking you. I am also not sure what 
value there is in knowing that 3478273983421 spent 10 minutes in trill 
and then moved on to behave (pun intended).

> How are the numbers assigned?

Don't know, but I have asked. I am guessing they are pre-assigned in 
the sense that each card has a unique ID that is later mapped to the
database.

> Does the Web UI make sure to hide the number->attendee mapping?

Don't know that either, but I agree that it should. It hasn't been
fully designed yet. Will ask that they do this.

> -Ekr

Ole J. Jacobsen

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 11 Sep 2009 08:16:29 -0700

Ole Jacobsen wrote:
> the reader with your card to make it work. 

Actually the strength of the field dictates the distance at which the
card can be energized. It is the reader not the passive rfid tag that is
operative in this regard. More than 12-18" is fairly hard for 125khz tags...

> So nobody from the host 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 12 Sep 2009 13:31:35 -0600

Ole Jacobsen <ole at cisco dot com> wrote:

> I am also not sure what value there is in knowing that 3478273983421 
> spent 10 minutes in trill and then moved on to behave (pun intended).

To amplify, I'm not sure why the security risks of being tracked while 
attending these meetings are considered so much greater than the risks 
of posting messages on mailing lists, signed with one's real name, and 
having those messages archived for years on publicly accessible Web 
sites.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Sep 2009 19:26:54 -0700

At Fri, 11 Sep 2009 07:57:02 -0700 (PDT),
> and then moved on to behave (pun intended).

Well, I think it's important to distinguish two different threat
scenarios: 

1. Tracking via the sensors that IETF has emplaced.
2. Tracking via sensors that others emplace [it's important to
   note that just because the readers you have are low power
   and can only work at close range, that doesn't mean it's not
   possible to have readers that work at longer ranges.]

In the first scenario, it's probably true that you can only
gather limited amounts of information, but in the second scenario,
the amount of information that can be gathered is limited primarily
by the number of sensors you're willing to emplace. I can 
imagine a number of scenarios where it would be attractive
to know where a given individual is at all times (for starters,
people often have private side meetings with customers at IETF
and if you had positional information you might be able to learn
about this). I certainly would not want to be tracked everywhere
I went.

This brings us to the question of the identifiers: it's certainly
true that systems which are anonymous but linkable offer a higher
level of privacy than those which do not. However, it's often
possible to determine which identifier a given person has 
(e.g., by observing a specific persons card being read), then
you can of course track them by name. In addition, if the
identifier->person mapping isn't generated securely and kept
confidential, then you may be able to quickly determine a
large fraction of the mapping.

> the sense that each card has a unique ID that is later mapped to the

OK, but the details matter here. For instance, if you have a stack
of cards with sequential serial numbers and you assign them in
sequence to the people in the attendee list (e.g., at the time
right before the meeting), you wouldn't need to know too many 
mappings to determine most of the database.

I'm not trying to make an argument for or against this experiment:
I don't even expect to be in Hiroshima, so it doesn't really 
matter to me one way or the other. However, given that the IETF has
extensive experience in this kind of secure systems design and
in fact has an entire WG (GEOPRIV) devoted to thinking about the
dissemination and privacy of positional information, it seems like
it would be nice to get a little more clarity about the security
of the proposed system.

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Sep 2009 21:33:56 -0500

On Sep 12, 2009, at 2:31 PM, Doug Ewell wrote:

>> I am also not sure what value there is in knowing that  
>> 3478273983421 spent 10 minutes in trill and then moved on to behave  
>> (pun intended).
>
> To amplify, I'm not sure why the security risks of being tracked  
> while attending these meetings are considered so much greater than  
> the risks of posting messages on mailing lists, signed with one's  
> real name, and having those messages archived for years on publicly  
> accessible Web sites.

Well, I for one don't want people to know that I'm actually showing up  
for the first ten minutes of each meeting I chair, replacing myself  
with an inflatable dummy, and then going off to the bar. It would be  
revealing that I'm too stupid to remove my RFID tag and attach it to  
the dummy, and that would be a blow to my professional credibility.

Seriously, it does have major implications for intellectual property  
lawsuits.

Let's say JoeBob attends a meeting of the FRILL working group, then  
goes home to patent a nifty new innovation in FRILL, which is then  
bought for $1 by a patent troll when JoeBob's company goes broke  
because his board of directors blew their investment capital on  
stocking their break room with headcheese. Said patent troll then sues  
some defendant, whose legal team later notices that said FRILL- 
enhancement had been discussed at IETF 211 while JoeBob, the inventor,  
was in the room, thereby invalidating the patent (and making JoeBob  
look like a doofus).

Okay, so that's not an example with too many negatives, unless JoeBob  
decides to sue us for making him look like a doofus.

Now let's presume that some people remember (and that some other  
people don't remember) JoeBob being in the room during the discussion,  
but IETF"s RFID tracker log shows that JoeBob was hanging out with me  
in the bar. Does IETF's failure to maintain the record that  
invalidates the patent make us liable to the defendant?

Or worse yet, IETF can't produce the RFID logs in response to a court  
order, because somebody goofed and deleted them. Was this a conspiracy  
to protect the patent troll? Who got bribed to make it happen? How  
many hundreds of thousands of euros we would like to spend on the  
paperwork related to the various discovery motions we might have to  
endure?

In other words, any retained information increases liability, both for  
the accuracy of the retained information and for the preservation of  
the retained information. That's why we must both have a policy about  
how that information is obtained and preserved, and we must live up to  
that policy, whatever it says.

Of course, the easiest policy is to retain no information. But even  
that has its consequences. For example, is deliberate ignorance   
consistent with industry best-practices? How does this interact with  
the Sarbanes-Oxley requirements of our sponsors? And why would a  
startup company stock its break room with headcheese anyhow?

--
Dean

---

From: joel jaeggli <[email-masked]>
Date: Sun, 13 Sep 2009 19:43:40 -0700

>    possible to have readers that work at longer ranges.]

spoofing via replay is an equally viable and entertaining possibility
for something you might in the future, potentially use for an attendance
tracking system.

---

From: "Michel Py" <[email-masked]>
Date: Sun, 13 Sep 2009 19:50:06 -0700

Hmm, it looks like the ghost of Jim Fleming is back to this list! Not
nearly as entertaining as the original, I'm afraid. I wonder if
someone's going to feed him.

Michel.

---

From: Richard Barnes <[email-masked]>
Date: Sun, 13 Sep 2009 23:19:08 -0400

> large fraction of the mapping.

Just to amplify this, it would be really trivial to gain targeted 
knowledge of the database just getting close to people that you're 
interested in tracking (e.g., talking to them, maybe even walking past 
them).  I'm guessing that if you're engaging in industrial espionage, 
you should at least have some knowledge of who you would like to target. 
  Once you've established the number-to-identity mapping, your sensors 
can do all the rest.

--Richard

---

From: Ole Jacobsen <[email-masked]>
Date: Sun, 13 Sep 2009 21:19:53 -0700 (PDT)

Eric,

The local hosts are reading the messages on this list and will take 
appropriate steps including:

* Not displaying the ID number <--> attendee mapping anywhere

* Not assigning numbers sequencially

Again, anyone may opt out, but this IS an experiment and it is 
certainly hoped that people will participate.

Ole

Ole J. Jacobsen

---

From: Ole Jacobsen <[email-masked]>
Date: Sun, 13 Sep 2009 21:22:49 -0700 (PDT)

Dean,

How is any of this relevant to an EXPERIMENT ???

Ole

Ole J. Jacobsen

On Sun, 13 Sep 2009, Dean Willis wrote:

> > >I am also not sure what value there is in knowing that 3478273983421 spent
> > >10 minutes in trill and then moved on to behave (pun intended).
> >
> >attending these meetings are considered so much greater than the risks of
> >posting messages on mailing lists, signed with one's real name, and having
> >those messages archived for years on publicly accessible Web sites.
> 
> Well, I for one don't want people to know that I'm actually showing up for the
> first ten minutes of each meeting I chair, replacing myself with an inflatable
> dummy, and then going off to the bar. It would be revealing that I'm too
> stupid to remove my RFID tag and attach it to the dummy, and that would be a
> blow to my professional credibility.
> 
> Seriously, it does have major implications for intellectual property lawsuits.
> 
> Let's say JoeBob attends a meeting of the FRILL working group, then goes home
> to patent a nifty new innovation in FRILL, which is then bought for $1 by a
> patent troll when JoeBob's company goes broke because his board of directors
> blew their investment capital on stocking their break room with headcheese.
> Said patent troll then sues some defendant, whose legal team later notices
> that said FRILL-enhancement had been discussed at IETF 211 while JoeBob, the
> inventor, was in the room, thereby invalidating the patent (and making JoeBob
> look like a doofus).
> 
> Okay, so that's not an example with too many negatives, unless JoeBob decides
> to sue us for making him look like a doofus.
> 
> Now let's presume that some people remember (and that some other people don't
> remember) JoeBob being in the room during the discussion, but IETF"s RFID
> tracker log shows that JoeBob was hanging out with me in the bar. Does IETF's
> failure to maintain the record that invalidates the patent make us liable to
> the defendant?
> 
> Or worse yet, IETF can't produce the RFID logs in response to a court order,
> because somebody goofed and deleted them. Was this a conspiracy to protect the
> patent troll? Who got bribed to make it happen? How many hundreds of thousands
> of euros we would like to spend on the paperwork related to the various
> discovery motions we might have to endure?
> 
> In other words, any retained information increases liability, both for the
> accuracy of the retained information and for the preservation of the retained
> information. That's why we must both have a policy about how that information
> is obtained and preserved, and we must live up to that policy, whatever it
> says.
> 
> Of course, the easiest policy is to retain no information. But even that has
> its consequences. For example, is deliberate ignorance  consistent with
> industry best-practices? How does this interact with the Sarbanes-Oxley
> requirements of our sponsors? And why would a startup company stock its break
> room with headcheese anyhow?
> 
> 
> --
> Dean
> 
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Sep 2009 00:31:07 -0400

Ole,

I'd like to encourage you and your IAOC/Trustee colleagues to
think about this in a slightly different light, consistent with
other concerns I've expressed recently.

Without taking any position about the idea itself, some
significant fraction of the community seems to believe that this
type of RFID experiment is a policy matter.  Another portion,
perhaps overlapping, believes that a version of the "eat our own
dogfood" principle says that we should set an example by
utilizing RFID only properly and with due consideration.  Some
of that group believes that "properly and with due
consideration" includes at least some technical security and
privacy issues, others (again possibly overlapping) believe that
the IETF should not be performing experiments with information
collection that can even potentially identify individuals unless
there are clear and public privacy policies in place.

I can find nothing in BCP 101 that encourages or authorizes the
IASA to go off and perform policy experiments on its own
initiative.  I haven't seen any signs of a proposal for a 3933
process experiment in this area.  Such a proposal, or an
IESG-initiated effort with a Last Call, presumably would have
involved an I-D and a reasonable possibility for the community
to determine whether the relevant ducks were lined up.

I also find nothing in the "guidelines [...]for regular
operational
decision making" (required by RFC 4071, Section 3.5, first
paragraph) that authorizes this sort of experiment.  Indeed,
despite that requirement, I'm not sure I can even find such
guidelines.  The only thing I can find is the "IAOC
Administrative Procedures" at
http://iaoc.ietf.org/documents/IAOC_Administrative_Procedures_7-17-08.pdf,
but they seem to be addressed to issues other than "regular
operational decision making" and, despite the date on the file,
the procedure document itself doesn't show an adoption date and
the Policy and Procedures page
(http://iaoc.ietf.org/policyandprocedures.html) seems to
indicate that they are just a draft.

In looking for that material, I did find the Communications
Policy, which appears to be a substitute for the Guidelines
called for by RFC 4071.   It makes interesting reading.  For
example:

	-- Section 5.3.4 calls for the IAOC to "adopt annual
	goals for the IASA and the IAD by December of each year
	for the succeeding year".  The Reports page of the web
	site (http://iaoc.ietf.org/reports.html) contains a line
	for such "Annual IASA Goals", but it isn't even a link,
	so apparently either there are no such goals or the IAOC
	doesn't believe that making them available to the
	community is a priority.
	
	-- Section 5.3.7 calls for an "Operations Report" to be
	submitted to the IAOC monthly and posted on the web
	site.  There is no evidence of integrated Operations
	Reports on the web site.  Not a single one.  There are,
	however, separate Financial Statements (three so far for
	2009 -- but those are covered separately in Section 5.2
	of the Communications Plan and are hence irrelevant to
	the Section 5.3.7 requirement) and Monthly Reports from
	the IANA (not the IAD).
	
	-- Section 5.3.8 says "The IAOC shall publish an IAOC,
	financial, and vendor performance report online one week
	before the IETF Meeting".  I don't recall seeing that
	report on a regular basis, only oral presentations at
	the IETF plenaries.   The "Plenary Reports" page
	(http://iaoc.ietf.org/plenary_reports.html) shows only
	IANA and RFC Editor reports associated with IETF
	meetings in the last several years.  Indeed, the last
	"IETF Ops Report" shown there is from IETF 68 (Prague in
	2007, before this Communications Policy was adopted)
	
	-- Section 5.3.10 calls for contracts or contract
	summaries to be posted on the web site within 14 days of
	execution.   I note, as an example, that AMS has been
	providing Secretariat Services for over 20 months now,
	but that the only Secretariat Services Contract posted
	is the December 2005 agreement with Neustar.  I don't
	suppose that I need to point out to the IAOC that 20
	months (and a contract date presumably somewhat earlier
	than that) is longer than 14 days.   I also note that
	not a single hotel contract, or summary thereof, has
	ever been posted.
	
	-- Section 6 calls for annual reviews of the
	Communications Policy, with community review and input
	"during the annual review cycle".  The Communications
	Policy was apparently adopted on July 12, 2007.  That
	suggests to me that there should have been two such
	reviews.  I'm not aware of either having occurred.  If
	the IAOC has concluded that the Communications Policy
	isn't practical, why hasn't the required review been
	initiated and the Policy been revised (with community
	review and input), rather than simply ignored in major
	respects?

I don't recall the community asking the IAOC or Secretariat to
initiate this RFID effort either.   I haven't gotten the
impression that the IAOC has so much spare time on its
collective hands that it should be making work for itself or the
community.  Certainly the list above strongly suggests that the
IAOC and IASA don't have sufficient time to even comply with the
policies that they adopted (or to effectively require that the
IAD comply with those tasks specifically assigned to him... many
of them by BCP 101 itself).

I do see a provision in BCP 101 (middle of Section 3.1) that
says:

	"The IAD shall ensure that personal data collected for
	legitimate purposes of the IASA are protected
	appropriately; at minimum, such data must be protected
	to a degree consistent with relevant legislation and
	applicable privacy policies."

Several people in the community with some experience on these
issues seem to believe that adequate protective procedures do
not appear to be in place, but we haven't heard from the IAD
about what measures are being taken.

So...

(1) To what extent does the IAOC believe it is reasonable to
adopt new and discretionary initiatives that require IAD and
IAOC supervision when the IAD and IAOC appear to be sufficient
overloaded so as to be unable to comply with a large number of
the IAOCs own procedures and requirements, both those explicitly
called for in BCP 101 and those which it adopted in December
2007.

(2) Is the IAOC supervising the IAD to be sure that adequate
protective procedures are in place for personally-identifiable
data as per the provisions above?

(3) Given that such procedures do not appear to be covered by
contractual provisions that justify secrecy, when does the
community get to review those procedures?

(4) For an experiment that was initiated by the IASA, without
the instruction, advice, or consent of the community, does the
IAOC have a procedure for determining how much "the ducks are
not lined up" or other negative feedback from the community is
sufficient to call the idea off?  Or is the IAOC's model such
that, having initiated this idea, no amount of feedback will
produce any change in behavior... i.e., that the experiment will
go forward and any evaluation will be performed after the fact?

The last question is particularly important because, if that is
the plan, everyone participating in the discussion on this
thread is wasting their time and yours.

I have not posted this inquiry as a Request for Review as
described in Section 3.5 of RFC 4071 for two reasons:

	(i) I do not consider the RFID experiment to be the main
	issue here, only the decision process that leads us into
	such experiments and the way of handling community
	review and comments.   If someone in the community who
	does consider the RFID experiment to be a main issue
	wants to use some of the text above to construct such a
	request for review, he or she should feel free but
	should note that RFC 4071 "normally" gives the IAOC 90
	days to respond.  By my rough count, 90 days would put
	us somewhere in December so that, if the IAOC decided to
	do so, it could simply ignore the Request for Review,
	carry out the experiment, and then indicate either that
	the Request for Review had become irrelevant or announce
	that it would adopt and follow new procedures sometime
	in the future.
	
	(ii) BCP 101 provides for Requests for Review of
	"decisions or action" of the IAD or the IAOC, not for
	massive non-feasance as outlined above.   One could
	potentially construct a Request for Review based on
	"...questions whether the IASA has created and
	maintained appropriate guidelines" but I don't have
	quite enough spare time on my hands right now to
	initiate that effort.  Again, if someone else is so
	inclined, feel free to borrow text as needed.

regards,
  john

---

From: Ole Jacobsen <[email-masked]>
Date: Sun, 13 Sep 2009 22:00:39 -0700 (PDT)

John,

With all due respect: The WIDE folks, host of IETF 76, have offered to 
showcase a technology that is being used increasingly for all kinds of 
things including public transportation system, door entry, and various 
other interesting applications. We've labelled this as an experiment 
and we've given everyone the option to NOT participate and we've 
encouraged a discussion of the many issues surrounding privacy and 
security that might arise by deploying such technology. We've also, 
with the help of the host, outlined some of the technical details and 
received feedback that I am sure will help improve many operational 
and privacy/security aspects of the experiment, details of which are 
being designed as we speak. As you know, Asia in general and Japan in 
particular is very high-tech and I am sure most IETF attendees will 
find the experiment interesting.

I think it's a real stretch to link this to any BCP, RFC or IASA 
founding document, but please don't read this as saying that your
questions aren't worth considering and/or answering. (But, as an 
individual IAOC member I won't be doing that here).

Just to be clear, the IAOC did not initiate the RFID experiment, and 
you are correct that the community did not ask for it. The WIDE folks
are working very hard to provide us with a great meeting, and as part
of this effort they are showcasing some cool technologies. The RFID
system is one such technology.

Ole

Ole J. Jacobsen

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Sep 2009 23:09:31 -0700

At Sun, 13 Sep 2009 21:19:53 -0700 (PDT),
> * Not assigning numbers sequencially

That seems like a good start. As Richard and I have both indicated,
however, this system seems to have substantial residual privacy
risk, even if the identifiers are assigned completely unpredictably
(and note that non-sequential and unpredictable are not at all the
same thing). 

> certainly hoped that people will participate.

I'm not trying to be difficult, but I'm not overly impressed with the
defense that people keep offering that this is an experiment and
people can opt out. If this were being done as an experiment at a
university, you would be expected to go in front of a human subjects
committee and demonstrate that your subjects had given informed
consent, probably wouldn't be harmed, etc. Now, obviously, this isn't
an academic setting, but I think it's fair to say that the people
running this experiment haven't done anything like full disclosure of
the relevant risks--and it's not even clear that they understand them
themselves. [It would also be consistent with common practice for
people to specifically opt in, not out.]

Now, I'm not saying that the IETF can never experiment with anything
(e.g., a new brand of pen at registration) without going through this
kind of review, but given that there has historically been quite a bit
of concern about the about the privacy implications of this sort of
RFID tagging (see, for instance, the issue of RFID tags in passports)
and that several people have raised concerns about this particular
use, ISTM that a somewhat higher bar is appropriate.  I'm not sure
exactly what I would consider meaningful for such an experiment in
order for participants to be fully informed, but it seems to me that
at minimum it would be the sort of security analysis that we would
expect to be provided in an I-D under RFC 3552.

-Ekr

---

From: joel jaeggli <[email-masked]>
Date: Sun, 13 Sep 2009 23:34:57 -0700

> other concerns I've expressed recently.

I would hope very much that any experiment that I try to carry out at
the ietf has no visibility at this level...

The only difference between supporting this experiment and say asking
the the network team to throw up the another vlan for some hot steaming
nat66 action is:

	the need for willing participants to carry tags around with
	them.

	the question of data retention

There have been experiments at every IETF that I've participated in,
some have required voluntary participation, many are just various parts
of the meeting teams trying news services or hardware platforms. insofar
as I'm concerned the barriers to experimentation should remain minimal.

In the past when the issue of data retention came up in the context of
an experiment as for example in the case of the intrusion detection
system at ietf 55 the stewardship answer was simply to destroy the data
once the meeting had concluded.

On the hosting side the one and only document in the ION series
experiment that I know of has the following to say about the network
hosting of experiments:

	The network provider MUST NOT view the IETF network as an
	experimental facility at the risk of impacting the IETF attendee
	experience. (Do not experiment with his/her favorite pet
	technology.)

I've been far to active on this thread already, and since this has now
deviated from layer 1 and 2 to layer 9 I will now shut up.

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 14 Sep 2009 00:05:25 -0700 (PDT)

> (and note that non-sequential and unpredictable are not at all the

I will leave it to the local organizers to disclose and explain the 
experiment further. I am no privacy and security expert, but it seems
to me rather unlikely that anyone needs to be concerned about being
"tracked" when the practical distance from reader to card is about
18 inches. In having these discussions we've probably highlighted a
number of *potential* risks much more than what the average credit 
card or cell phone customer is informed of. I suppose we could do what 
the Fastrak people did when they sent me the RFID gizmo for bridge
tolls: They included a foil-lined bag and explained that the system
was being used to monitor traffic (as well as collect tolls) and if
I didn't want to participate I could put the gizmo in the bag.

> consent, probably wouldn't be harmed, etc.

What about a "commercial" or "business" setting? The hotel in 
Stockholm where many (most?) of the IETFers stayed had RFID cards for 
key entry to the hotel rooms.

> Now, obviously, this isn't an academic setting, but I think it's 
> fair to say that the people running this experiment haven't done 
> anything like full disclosure of the relevant risks--and it's not 
> even clear that they understand them themselves. [It would also be 
> consistent with common practice for people to specifically opt in, 
> not out.]

Effectively that's what will happen. At registration, you will be 
offered the card, you can obviously refuse to accept it. As for
full disclosure of relevant risks, having this discussion is hopefully 
leading to a set of observations that can be supplied to each 
attendee. And yes, it isn't fully designed yet, but I am sure the
organizers never expected this amount of feedback either, particularly 
not since the technology has been in regular use in Japan for many 
years.

Ole

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 14 Sep 2009 12:08:39 +0200

On Mon, Sep 14, 2009 at 12:05:25AM -0700,
 Ole Jacobsen <[email-masked]> wrote 
 a message of 53 lines which said:

> I am sure the organizers never expected this amount of feedback
> either,

They don't know the IETF, then :-) They can expect a lot of feedback
on sushi and cookies, too.

> particularly not since the technology has been in regular use in
> Japan for many years.

The fact that some technology is already widely used certainly does
not mean that we should shut up about its security risks. I
appreciated Eric Rescorla's well-informed and well-explained analysis.

---

From: Scott Brim <[email-masked]>
Date: Mon, 14 Sep 2009 07:00:50 -0400

So far this has been an interesting experiment in trying to have an
experiment within the IETF culture.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 14 Sep 2009 07:54:41 -0400

I'm with Eric on this.  Part of our dog food is a decent regard for
security and privacy; we shouldn't neglect in the name of
experimentation.

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 14 Sep 2009 06:34:53 -0700 (PDT)

Neither privacy/security nor discussion of such is being neglected or
discouraged. That's part of the experiment too.

Ole

Ole J. Jacobsen

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 14 Sep 2009 10:06:37 -0400

John,

I can back most of your statement and the things you do but that below
is just absolutely absurd.

The RFID badge thing originated in the >HOST< not in IASA. It is
entirely within normal facilities arrangement and negotiation to use
pre-existing badge arrangements, particularly where there is an easy
opt out. An IETF meeting is not some computer cracker meeting trying
to provide anonymity. However interesting the general case of various
ID and information privacy arrangements may be, RFID or bar code or
photo ID or color coded deely-bopper or whatever badges are perfectly
reasonable as facilities provided by the HOST on a one time basis when
it is easy to opt out.

I request that you apologize to the long suffering volunteers that
make the IETF meeting facilities work for your unwarranted abuse.

Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: David Conrad <[email-masked]>
Date: Mon, 14 Sep 2009 09:15:58 -0700

Eric,

On Sep 13, 2009, at 11:09 PM, Eric Rescorla wrote:
> As Richard and I have both indicated,

I'm curious: do you carry a cell phone?

Regards,
-drc

---

From: Scott Brim <[email-masked]>
Date: Mon, 14 Sep 2009 12:26:47 -0400

Dean, all these excellent issues have to be dealt with if/when use of
RFIDs becomes a normal part of IETF logistics.  It's not.

Excerpts from Dean Willis on Sun, Sep 13, 2009 09:33:56PM -0500:
> stocking their break room with headcheese. Said patent troll then
> sues some defendant, whose legal team later notices that said FRILL-
> enhancement had been discussed at IETF 211 while JoeBob, the
> inventor, was in the room, thereby invalidating the patent (and
> making JoeBob look like a doofus).
> 
> Okay, so that's not an example with too many negatives, unless
> JoeBob decides to sue us for making him look like a doofus.
> 
> people don't remember) JoeBob being in the room during the
> discussion, but IETF"s RFID tracker log shows that JoeBob was
> hanging out with me in the bar. Does IETF's failure to maintain the
> record that invalidates the patent make us liable to the defendant?
> 
> Or worse yet, IETF can't produce the RFID logs in response to a
> court order, because somebody goofed and deleted them. Was this a
> conspiracy to protect the patent troll? Who got bribed to make it
> happen? How many hundreds of thousands of euros we would like to
> spend on the paperwork related to the various discovery motions we
> might have to endure?
> 
> In other words, any retained information increases liability, both
> for the accuracy of the retained information and for the
> preservation of the retained information. That's why we must both
> have a policy about how that information is obtained and preserved,
> and we must live up to that policy, whatever it says.
>

---

From: Scott Brim <[email-masked]>
Date: Mon, 14 Sep 2009 12:29:50 -0400

> (and note that non-sequential and unpredictable are not at all the

So don't carry it.  Or carry it in your faraday cage passport holder.

> I think it's fair to say that the people running this experiment
> haven't done anything like full disclosure of the relevant
> risks--and it's not even clear that they understand them themselves. 

Please help them

---

From: Scott Brim <[email-masked]>
Date: Mon, 14 Sep 2009 12:32:38 -0400

Excerpts from Ole Jacobsen on Mon, Sep 14, 2009 12:05:25AM -0700:
> I suppose we could do what 

Side story: when a car of mine was totalled in Brooklyn and towed to
New Jersey, I forgot to take the E-ZPass "tag" off and I later got a
trace of which bridges the tow truck had taken.

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 14 Sep 2009 12:38:58 -0400

> So don't carry it.  Or carry it in your faraday cage passport holder.

Maybe we could do a test of this as part of the meeting. I often tell  
people that a metal lunch box or
aluminum foil should be sufficient, but it might be good to see how  
good they (plus the holders you can buy)
really are.

Also, since the RFID readers can be bought easily (they're probably at  
Fry's), I would hope to hear of some good hack uses of this technology.

Regards
Marshall

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 Sep 2009 10:17:52 -0700

Marshall Eubanks wrote:
> aluminum foil should be sufficient, but it might be good to see how good
> they (plus the holders you can buy)
> really are.
> 

I worked on RFID readers last year as part of an aborted tentative[1] to improve
remote attendance for IETF meeting.  I expected the kind of problems that people
are (rightly so) worrying about currently, so I did a little bit of research on
the privacy part.  125Khz tags needs to be completely enclosed in a Faraday cage
with a double layer of conductive material. OTOH 13.56 Mhz tags can be isolated
with a single layer of conductive material, and it works fine even if the
material is only on one side or the card.  I chose 13.56 Mhz tags because, at
the difference of 125 Khz tag that can only carry a serial id, 13.56 Mhz tags
can store data (i.e. name, affiliation) and I do like the idea of having only to
destroy a card to improve my privacy (when it is in a database somewhere, it is
no longer yours).

Anyway, I designed a prototype of a card holder that permit to read the RFID
card and the printed information when open, and prevent to read both when closed:

http://ietf.implementers.org/rfid.jpg

[1] http://ietf.implementers.org/IETF20081118.pdf

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 14 Sep 2009 13:34:09 -0400

> Data rentention

Does this mean the database will be deleted after the comparison is  
done? Or does it mean the database will be deleted when the bluesheet  
data is deleted (i.e., never)?

Alissa

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 14 Sep 2009 10:41:02 -0700 (PDT)

It means that the data will be deleted at the end of the expiriment 
once the analysis is done. Educated guess: within 30 days of the end 
of the meeting, I know how busy the folkds running the meeting are. 
The bluesheets, on the other hand, are retained.

There is no need to retain this data once summaries and comparisons
are done.

Ole

On Mon, 14 Sep 2009, Alissa Cooper wrote:

> 
> Does this mean the database will be deleted after the comparison is done? Or
> does it mean the database will be deleted when the bluesheet data is deleted
> (i.e., never)?
> 
> Alissa
> 
> 
> 
> 
> 
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Sep 2009 14:39:18 -0400

--On Monday, September 14, 2009 10:06 -0400 Donald Eastlake
<[email-masked]> wrote:

> John,
> 
> I can back most of your statement and the things you do but
> that below is just absolutely absurd.
> 
> The RFID badge thing originated in the >HOST< not in IASA. It
> is entirely within normal facilities arrangement and
> negotiation to use pre-existing badge arrangements,
> particularly where there is an easy opt out. An IETF meeting
> is not some computer cracker meeting trying to provide
> anonymity. However interesting the general case of various ID
> and information privacy arrangements may be, RFID or bar code
> or photo ID or color coded deely-bopper or whatever badges are
> perfectly reasonable as facilities provided by the HOST on a
> one time basis when it is easy to opt out.
> 
> I request that you apologize to the long suffering volunteers
> that make the IETF meeting facilities work for your
> unwarranted abuse.

Donald,

There are, it seems to me, two rather separate issues here.  

One is the general theme of whether the IASA is performing
according to the responsibilities and obligations of BCP 101 and
its own rules. Those are responsibilities, obligations, and
rules for which the IAD and members of the IAOC presumably
signed up.   Now maybe much of the community doesn't care
whether they do those things or not.  I don't think that
absolves the IASA from those responsibilities, but YMMD.

The second is what a sponsor gets to do when they decide to
sponsor an IETF meeting.  Our policies on that subject have
evolved over the years.  My recollection is that several
requests/suggestions to run exhibition halls in conjunction with
IETF meetings have been turned down.  You and I can both
remember the time when sponsors had to ask secretariat
permission to set up a table near the registration area that
displayed a sponsor logo and were routinely told "no".  But the
point is that these are policies and that having a sponsor give
out T-shirts or RFID badges are policy decisions too... policy
decisions that are made somewhere in the IASA structure, not
decisions a sponsor can make unilaterally unless sponsorship
agreements have changed dramatically (and in ways that should be
visible to the community).

Equally, it is a policy decision to make attendance lists (with
any details attached to them at all) available for sponsor use
and another one for the Secretariat to engage in any sort of
"matching" or "comparison to blue sheets" activities.

To repeat the comment I made in my note, I'm not personally
opposed to any of these things.  I'm just concerned about how
the IASA is making the policy decisions and dealing with the
comments from the community to which they are supposed to be
responsive ... or abandoning those policy decisions to the
sponsor without any clear oversight.   Judging from Ole's
comments, I think the IASA _is_ taking some responsibility here
--contrary to your apparent belief that this is entirely a
sponsor initiative.  I am pleased that the IASA is doing so...
at the same time that I'm concerned about whether their
priorities are correct to spend time on this optional activity
given the required things that are not getting done.

However, let's assume that this really were a host decision
independent of the IASA and that our sponsorship agreements
permitted or encouraged such things.  Then I'd expect the model
to be opt-in, not opt-out, I'd expect the database of user names
(or other identifiers) and badge numbers to be kept isolated
from secretariat databases, and I'd expect the responses about
the handling of the content of those databases to be coming from
the sponsor, not members of the IAOC.  YMMD about that, but, as
soon as the secretariat is involved and/or things are going into
the envelopes, there is an IASA policy decision involved, not an
independent host action.

So, sorry, no apology here.

     john

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Sep 2009 14:57:43 -0400

--On Sunday, September 13, 2009 22:00 -0700 Ole Jacobsen
<[email-masked]> wrote:

> 
> John,
> 
> With all due respect: The WIDE folks, host of IETF 76, have
> offered to  showcase a technology that is being used
> increasingly for all kinds of  things including public
> transportation system, door entry, and various  other
> interesting applications. We've labelled this as an experiment 
> and we've given everyone the option to NOT participate and
> we've  encouraged a discussion of the many issues surrounding
> privacy and  security that might arise by deploying such
> technology. We've also,  with the help of the host, outlined
> some of the technical details and  received feedback that I am
> sure will help improve many operational  and privacy/security
> aspects of the experiment, details of which are  being
> designed as we speak. As you know, Asia in general and Japan
> in  particular is very high-tech and I am sure most IETF
> attendees will  find the experiment interesting.

Yes.  But, as to the substance, I think Eric's comments are very
relevant here.   As I pointed out in my note to Don, this ceases
to be a "host experiment" as soon as the IASA gets involved, and
the IASA certainly appears to be involved... and is making
policy decisions without adhering to what I believe to be the
requirements for IASA policy decisions.  

There are countries in which the use of security cameras is very
widespread too, but I wouldn't expect the IETF --the same IETF
that has occasionally taken very strong positions against bans
on encryption technologies to protect privacy -- to endorse them.

To be clear, I think it is entirely reasonable for a host to
propose something like this, either as a "technology
demonstration" or as an "experiment" (I think of the two as
different; YMMD).   I think it is entirely reasonable for the
IASA to say "tentatively ok" without turning that into a big
deal or public process, and make an announcement to the
community about the plan, and I see that as having been done.
But when, after the announcement, when the community expresses
considerable concerns, I expect the IASA (and, as appropriate
the sponsor) to engage directly on the questions and to treat
the decisions as a policy matter in which the community has to
be involved.  And that is different from saying "it is an
experiment", "...help improve many operational  and
privacy/security aspects of the experiment", without any signs
of being willing to entertain the null hypothesis of "maybe this
isn't a good idea without time and resources for more
consideration and openness".

>...
> Just to be clear, the IAOC did not initiate the RFID
> experiment, and  you are correct that the community did not
> ask for it. The WIDE folks are working very hard to provide us
> with a great meeting, and as part of this effort they are
> showcasing some cool technologies. The RFID system is one such
> technology.

But, as I said to Don, not a technology demonstration that the
IASA needs to facilitate on the one hand and then pretend does
not involve policy decisions about secretariat and other
involvements on the other.

   john

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Sep 2009 15:10:31 -0500

> How is any of this relevant to an EXPERIMENT ???

A maxim about experimentation: If the design of and data resulting  
from any experiment are made available, people may use these results  
to test hypotheses that were not necessarily envisioned by the  
experiment designers. In other words, people are likely to do things  
with the result of the experiment that we don't necessarily have in  
mind. This is a given, and is not necessarily a bad thing. Indeed, it  
is how a great many discoveries are made.

But the experimenters (and/or their sponsors) are not without  
liability in today's unfortunately litigious world.  By making the  
results available, we have made some level of express or implied  
warranty about those results. There may also be some liability toward  
the experimental subjects (those of us with RFID tags, or those of us  
interacting with tagged persons). For example, people might use the  
experimental results in prosecution of patent lawsuits. If there are  
errors in the data, or if it can be argued that there were flaws in  
the experiment that were not disclosed to the users of the data, we  
could potentially be liable for damages.

So any collection, retention, and/or release of data has to be  
protected by explicit disclosure of policy and known limitation. The  
"implicit warranty" has to be made explicit, and in our case it most  
likely had better explicitly say that we're not making any assertions  
about the validity of the data, the collection method, the names or  
locations of the participants, or anything else. We should probably  
also document the data retention policy, which in this case is  
probably "We may dispose of these data at any time and are not  
obligated to preserve or retain them or to make them available at any  
future date." Further, we may wish to release the data with some sort  
of explicit licensing terms that include this explicit non-warranty of  
the experiment's validity.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Sep 2009 15:29:18 -0500

> There is no need to retain this data once summaries and comparisons

That's a reasonably good statement of the retention policy.

For today's news about the unintended consequences of the release of  
experimental data, I refer you to:

http://www.foxnews.com/story/0,2933,549941,00.html?loomia_ow=t0:s0:a16:g2:r2:c0.083617:b27702080:z0

In short, 35 year old research maps relating to possible Hawaiian lava  
flows are being used to deny insurance coverage to homeowners, even  
though this isn't what the maps were intended for and despite the maps  
having been declared as hopelessly out-of-date by their producer.

You see, the maps are effectively in the public domain. Their use,  
retention policy, and level of validity  were not clearly described in  
the licensing terms given by the map makers. So the only thing anybody  
can do about it is make newer, better, maps, which both the homeowners  
and insurance companies are likely to fight because it would affect  
somebody's costs or profits. All politics are economical, and all  
science is political.

--
Dean

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 14 Sep 2009 13:50:16 -0700 (PDT)

John,

You said:

"But when, after the announcement, when the community expresses
considerable concerns, I expect the IASA (and, as appropriate
the sponsor) to engage directly on the questions and to treat
the decisions as a policy matter in which the community has to
be involved."

At the risk of being accused of spending far too much time and 
bandwidth on this particular topic, let me just say that the community 
IS involved as you can clearly see from the discussion on this
list. The WIDE people are paying close attention and I expect there 
to be yet more information forthcoming and the appropriate disclaimers 
and statements of any side effects (risks) involved.

I fundamentally disagree that "considerable concerns" have been 
expressed, instead I think good questions have been asked and issues
discussed that are all part of the experiment.

Risks are a fact of life. There is a risk that the T-shirts may 
contain chemicals you are allergic too, there is even a risk that
you could get mugged in Hiroshima (althought my personal estimate
is that you are about 100 times less likely to experience that as
compared to say, Chicago). The risk that (somehow) the RFID cards
will/can be read by a third party and used for some undesirable
purpose, I think is very low, but I agree that we should at least
outline the potential scenario and allow the attendee to make up
his/her mind regarding participation.

You are absolutely right that the IAOC has more pressing matters
to worry about.

Ole

Ole J. Jacobsen