[ietf-enroll] Draft notes from Enroll BOF

[Cullen Jennings]

The following is a draft of the notes I took in the meeting. If folks could
let me know how to make them clearer, add stuff I missed, or correct
mistakes I made, I would be very grateful if people sent text.

Thanks, Cullen

----- Summary ------------------------------------------

Email list for this work is ietf-enroll at mit.edu

Proposed charter is at http://www.ietf.org/ietf/03nov/enroll.txt

The group will keep working the charter on the list and keep moving towards
forming a WG but is not a WG yet.

There are lots off security protocols and security implementation such as
S/MIME and  802.11 with various stuff, yet many of these things are not
being used. This is because enrollment is too difficult for people other
than geeks. How can we get these security services so easy to use that
people actually use them?

This work is proposing developing models, not protocols, for secure
enrollment. One of the uses cases for this work is you go to a store and buy
a wireless printer then take it home. How do you securely enroll it into
your home wireless network? This work is about what happens in the very
early stages when a device first comes into a system. It is not about the
type of things that EAP does with mobile devices.

A few recurring things came out of the comments in the BOF.
* The anticipated use cases would help people
* Having the first draft of the model document would help people see if this
is something we need to go forward with
* Clean up the use of the word  "identity" in the current draft charter and
use words like authorization or authentication instead. Will work this on
the list. 

Hannes Tschofenig will send some pointers to work on "imprinting" to the
mailing list 

Stephen Hanna will send link to an old draft about some of these issues.



---- Raw Notes ------------------------------------------

 The stuff that follows are the raw notes I typed in during the meeting....

The problem is you go to store, buy a device, now you need to get it
connected. For example your new wireless notebook needs to be introduced to
the network at your house or you take your wireless device to the airport
and want to pay your money and use it. Would like to develop a model for
enrollment in these types of situations

Would like to concentrate on some of the easier problems.

Comment that it seems to be like work done in EAP.  Answer: This is trying
to do much less and just do the initial stage the work. This work will just
say who are you and what capabilities are but not go on the the next steps.

Comment that some people thought the work in this group seemed like very
little. That is the idea to try something very simple.

Comment requesting for some real world user cases that might help
differentiate it from device provisioning and EAP. Is this mobile, cell
phone, 802.11. Answer ... Canonical cases is ... Laptop, 802.11 at airport.
When you try to do first web address, you get redirected to web page. You
pay money and the system remembers your MAC and allows it. This is not great
from a confidentiality and security point of view. Would be nice if you did
some handshake and got a shared key. This shared key can be used for first
step. The end of this first step is where this work would stop.

Comment that we are not producing protocol but producing a model for
comparing protocols against and perhaps as a kick off point for protocols.

The bottom example in the draft uses credit card as shared secret but this
work is more about using maiden name to get a credit card. Should fix the
example.

This work  can use a weak thing we have to get something better. This is all
prior to doing an EAP exchange. It might be something in the device or
something we have such as a maiden name.

Would like to remove the huge amount of hand-waving at the very early stages
of enrollment in current systems.

This work is about what happens when you buy a phone how it gets enrolled
into the system. Not what happens with a phone and EAP for roaming.

Perhaps change the "identity confirmation" in bullet 2 to "authorization
confirmation". 

Another use case was brought up that is very different. Distributed software
install of several software components on several different devices. This
was determined way way out off scope in the beginning.

Enrollment is a real problem in 802.11 wireless, both home and public.

Example use case, buy a wireless printer and add it to your home network.

Question about how much human interaction on both consumer and provider
sides. There will need to be some but as little as possible hopefully as
little as possible. Perhaps close to none on provider side.

In a shared secret case, it seem very likely it will be human typing the
credential in. 

Question about if models for things like cable modem enrollment are broken.
No this work does not imply that cable modem enrollment is broken - it does
not say it needs to be changed. The existing models don't work well in some
cases. 

Question about what the problems are in existing systems.

This discussion of Model is important but also need more complex case - for
example model that can be moved to protocol. As we move to better
credential, like 128 bits or asymmetric, the model where a user goes and
types it in, will fall down.

Once we have the model specified, some people will turn out to already be
doing it and can write a profile. Others might want to make changes to make
it fit the model. 

Comment that Perhaps we need an internet draft before we really form the
working group.

Comment it would be useful to provide the anticipated use cases for this.

Moderators of BOF summarized that they were hearing a couple things:
* The anticipated use cases would help people even after the BOF meeting
* Having the first draft of the model document would help people see if this
is something we need to go forward with
* Clean up the use of the word  identity and use authorization or
authentication more

Asked what can we do to help crystallize if a WG is even wanted?

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

Question about what our cases are:
Person to person ? 
Person to Person plus information from a physical device?
Person to Machine?
Machine to Machine?
I think the answer was No to person to Person but yes to others. <Note taker
comment - was this what other people got? I may have misunderstood the
response on this>

The case with cell phone, call up person to type in something. We would
consider this Person to Machine. The person you call is just filling in for
a poor machine user interface.

Comment that this whole space is so complicated - what are we doing here.
Access identity, federation, federated identity. Answer: Not aware that one
of these have done some model. Comment that all of these rely on some
initial key exchange. On all of these are not explaining the first . EAP is
a good exchange but requires some credential but requires you to get a
credential. All of these system depend on getting that initial credential.
This work is about how to bootstrap to the point you have that initial
creation.

Comment that work identity needs to disappear. Need round on mailing list to
decided what to change these too.

Comment that this general class of things is called imprinting.

Hannes Tschofenig will send some pointers to work on "imprinting" to the
mailing list 

Comment on an old draft from zero conf that might be used for this. Zeroconf
did not end up address the security issues of this.

Stephen Hanna will send link to an old draft about some of these issues.  it
may be difficult to span space from enrolling toaster with no buttons or
display and enrolling a notebook computer with 802.1x with a screen and
keyboard. 

This work is more used from bootstrapping onto a system not necessarily
something you use ever time you come on.


Russ Housley's Comments on why he thinks it is important.

<The note taker missed a bunch of what Russ said, so, apologies for somewhat
butchering Russ's message

There are lots off security protocols and security implementation, S/MIME,
802.11 with stuff, yet many of these things are not being used. This is
because enrollment is too difficult for people other than geeks. How can we
get these security services so easy to use that people actually use them?
The reason TLS has such deployment is that only the server needed to do
something.