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