2.6.12 Credential and Provisioning (enroll) Bof

Current Meeting Report

listMinutes of the ENROLL BOF
November 11, 2003


Email list for this work is ietf-enroll@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 

Slides

None received.