2.6.1 Credential and Provisioning (enroll)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-15

Chair(s):
Paul Hoffman <paul.hoffman@vpnc.org>
Eric Rescorla <ekr@rtfm.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
Technical Advisor(s):
Donald Eastlake 3rd <Donald.Eastlake@motorola.com>
Mailing Lists:
General Discussion: ietf-enroll@mit.edu
To Subscribe: ietf-enroll-request@mit.edu
In Body: subscribe
Archive: http://mailman.mit.edu/pipermail/ietf-enroll/
Description of Working Group:
There are many cases where a service consumer needs to contact a service provider to get credentials that the consumer can use when accessing the service; part of this initial contact may involve the consumer and the provider mutually validating the other's identity. This working group will look at some of the cases where cryptography is used to provide authentication.

When doing enrollment of a service consumer against a service provider, three pieces of information need to be provided or created in order to support authentication of the service consumer to the service provider (and visa versa) and to allow for additional security services to be provided any information exchanged. These pieces of data are:

1. An identifier, within a namespace controlled by the service provider, for the service consumer. 2. Keying information to be used for identity confirmation. 3. A set of service consumer permissions. These permissions describe to the provider the services that the consumer wants to access, and they describe to the consumer what services offered by the provider will be accessable.

Each of these data items could be created by either the consumer or provider at any point during the enrollment process.

This group will create a model to be used in describing enrollment procedures and create a document for a framework how this is to be done. The group will then produce three documents profiling the use of the framework for the following types of keying material:

1. A shared secret key. 2. A bare asymmetric key. 3. A bound asymmetric key (such as an X.509 certificate).

As part of the validation of the framework, the group will examine how other real world enrollment procedures could be profiled. For example, credit card information might be part of the input to the enrollment process.

Goals and Milestones:
Nov 03  First draft of model
Feb 04  Last call on model document
Feb 04  First draft of Framework document
May 04  First draft of secret key profile
May 04  First draft of bare asymmetric key profile
May 04  First draft of bound asymmetric key profile
Jun 04  Last call on module document
Oct 04  Last call on secret key profile
Oct 04  Last call on bare asymmetric key profile
Oct 04  Last call on bound asymmetric key profile
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Minutes for the ENROLL Meeting
IETF 60
August 2, 2004


1. Agenda: Hoffman presented the Agenda: Agenda bashing (Hoffman), draft-pritikin-ttimodel, (Pritikin), Comments on the ttimodel draft (Schaad), Where do we go?, and Revisions of Milestones.


2. Trusted Transitive Introduction Model: Pritikin presented an overview of the ttimodel draft. Model is essentially that of a secure introductions system, which is a third party that facilitates the "out of band" exchanges between systems trying to establish authentication. Process is recursive, so the more stages you go through the more systems you can communicate securely with. Basic low-security exchange must occur as the first step, but this may take place during manufacturing or staging over a physically secure link (i.e., a short wire). This initial introduction would allow the device to "imprint" on its first connection, establishing basic policies, initial credentials, etc.


Somebody asked for clarification that you don't have to establish initial credentials or policy during the initial imprint, but it's a good idea to do so. Pritikin agreed that this was the case. He suggested that competitive pressure would drive vendors to do more during the initial imprint, because it gives you a competitive advantage over other products that do less.


Kumar (from Panasonic) asked how, if you're making lots of small devices, how you can stop the production line to initialize each. Pritikin noted that this complex configuration may not be common. That simpler examples may be the norm for small devices. Bonatti asked for clarification that this initial step was analogous to a manufacturing initialization, like loading a unique serial number onto an Ethernet adapter. Pritikin agreed and Hoffman amplified, noting yes but an operation unique to ENROLL.


Randy Turner remarked that mass marketing was a unique environment, and that he would like to see the existence proof for this concept. Pritikin noted that the communication paths exist in the "out of band" case. It's merely a question of whether your model takes advantage of that in a way that you can build on in a structured way. Pritikin proposed that we evaluate whether this approach is a good way forward for ENROLL, finalize the draft as a WG document.


3. Comments on Trusted Transitive Introduction Model: Schaad presented some prepared comments on the ttimodel draft. He stated that he does not think that the existing document does a good job at what a model document should be. However, he thinks that the model implied makes sense. He presented an alternate view of the model using the roles of Petitioner, Registrar, and Introducer. He noted that in some scenarios the introducers might not be the same entity for authenticating the Petitioner to the Registrar and vice versa. He equated his "mediated" model as being equivalent to what is presented in the ttimodel draft.
Randy Turner summarized Schaad's comments by referring to the "Goal of ENROLL" slide. To wit, produce a document that: Describes a model of doing introduction, Describes security aspects of model, Allows for designers of protocols to evaluate their protocol against the model. Randy suggested that Schaad was saying that the TTI model does the first, but not the second. Schaad responded that he was looking for something higher level that compared different approaches. Pritikin was happy to add more models to the document to address Jim's concerns.


4. Milestones: Hoffman was unsure whether the work could be completed in a year and asked who is interest. Many raised their hands and it was agreed to press forward with the work under the assumption that it should be completed within the year.


--Paul Hoffman, Director
--VPN Consortium

Slides

Enrollment
Comments for ENROLL