From: "Jim Schaad" <jimsch@nwlink.com>
To: <agenda@ietf.org>, "Russ Housley" <housley@vigilsec.com>,
"Steve Bellovin" <smb@research.att.com>
Date: Thu, 29 May 2003 15:03:20 -0700
cc: "'IETF-Enroll'" <ietf-enroll@mit.edu>
Subject: [ietf-enroll] Enrollment BOF Request
BOF NAME & ACRONYM: Credential and Provisioning BOF (ENROLL)
AREA: Security
RESPONSIBLE AD: Russ Housley, Steve Bellovin
BOF CHAIR: Jim Schaad
Mailing Lists:
General Discussion: ietf-enroll@mit.edu
To Subscribe: send email to mailman@mit.edu
In Body: subscribe ietf-enroll
AGENDA:
- Intro and Agenda Bashing (5 min)
- Overview of Expected Scope (15 min)
- Charter Discussions (15 min)
- Model Presentations
- Weak Authentication (10 min)
- Shared Secret (10 min)
- Introduction Model (10 min)
- Call for Participation (5 min)
- Open Discussion (30 min)
Description of Working Group:
There are many cases where a client needs to obtain credential
information from a service provider and provide some type of information
for validation of identities (client and/or service provider). This
working group will look at some of the cases dealing with the use of
cryptographic algorithms for providing this information.
When doing enrollment of a client 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 vice
versa) and to allow for additional security services to be provided any
information exchanged. These pieces of data are:
1. The "entity label" for the service consumer,
2. A piece of keying information to be used
3. A set of permissions for operations for the service consumer.
Each of these data items could be created by either the client 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 cases:
1. A shared secret key
2. A bare asymmetric key
3. A bound asymmetric key (e.g. 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. (An example
of this would be credit card usage.)
The Group currently has no drafts.
Goals and Milestones:
Sept 2003 First draft of model
Dec 2003 Last call on model document
Nov 2003 First draft of Framework document
April 2004 Last call on Framework document
March 2004 First draft of secret key profile
March 2004 First draft of bare asymmetric key profile
March 2004 First draft of bound asymmetric key profile
Aug 2004 Last call on secret key profile
Aug 2004 Last call on bare asymmetric key profile
Aug 2004 Last call on bound asymmetric key profile
CONFLICTS to avoid: S/MIME, PKIX, SAAG
Special Requsts: Not Monday Morning.
Number of Slots: 1
Length of Slot: 2 or 2.5 hours