2.6.2 Credential and Provisioning (enroll)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-25


Paul Hoffman <paul.hoffman@vpnc.org>
Eric Rescorla <ekr@rtfm.com>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

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
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
order to support authentication of the service consumer to the service
provider (and visa versa) and to allow for additional security
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

Goals and Milestones:

Sep 04  First WG draft of model document
Mar 05  First draft of profile document(s)
May 05  Last call on model document
Dec 05  Last call on profile document(s)

No Current Internet-Drafts

No Request For Comments

Current Meeting Report


Tuesday, March 8
Minutes taken by Paul Hoffman and Don Eastlake
--combined by Paul Hoffman
Paul Hoffman and Eric Rescorla, chairs

Paul talked about the status of the WG and the very little
    work that had happened on the mailing list.
Max Pritikin's draft has expired.
There have been difficulties with definitions.
Agenda: spend about a half hour on drafts, then talk about futures.

Jim Schaad discussed Max's draft
    Expired: draft-pritikin-ttimodel-01.txt
    It is really about introduction, not enrollment
    The draft talks about the parties to be introduced and a
        trusted-third-party who knows them both
    "Imprint" kind of means leap of faith to trust who you see first.
    Manufacturer insertion of crypto variables or the like into a
        device at start is a type of third party introduction
        (between device and manufacturer registration service).
    Deciding whether you have single or bi-directional flow through
        TTP is important
    Bi-directional allows zero-knowledge stuff where maybe TTP doesn't
        know if Alice and Bob agreed
    Writing the model document and having a common lexicon would be
        very valuable.
    Hoffman: Which terms are most important to define?
        One-way courier and two-way courier
        Third party post-verification

Hannes Tschofenig discussed his "Next Steps for ENROLL" draft
    Enroll touches on both imprinting and bootstrapping
    These are sufficiently different that they should be treated
    Imprinting == procedure to equip a component with a secret value
        of a cryptographic parameter.
        Only fuzzy definitions available but frequently discussed in
        IETF docs
            EAP type protocols
            3GPP Generic Authentication
            Various MIP6
    Rescrola: KDC's (Key Distribution Centers) start with strong
        keying material while bootstrapping is to get to strong
        material from weak material
    The problem affects many WGs but general solution may be hard
    Lack of a specific problem domain often confuses people
    Shore: why is imprinting an IETF work?
        What's the interoperability issue?
    Tschofenig: Say you want to configure a laptop with some EAP
        methods using a USB stick ...
    Sommerfeld: the format of imprinting message is important
        Shovelling around is less important
        Should include octet string
        There really isn't any better forum for "imprinting" work
    Tschofenig: You need to know what protocol you are using
    Someone: USB stick can be considered equivalent to a wire.
    Rescorla: different way to think about imprinting
        Have a high bandwidth channel and low-bandwidth channel
            (your hands)
        Low bandwidth is not IETFy
        Can we do imprinting only?
        You need to define a bootstrap protocol to use the
            insecure channel to secure the insecure channel
        Crypto is IETFy
        USB stick is conduit for the low bandwidth channel
        Can we get a good enough handle on low bandwidth channel
            interaction methods? (We understand protocols)

Hoffman to group: Is enough work being done on imprinting and
    bootstrapping elsewhere that we just need to do a definitions
    document? (No hands raised.)
Joe Salloway: a fair amount of work in other WGs is happening
    Some stuff is being reinvented
    Maybe do a survey of imprinting to see if there is a common problem
    There is probably an enrollment phase
    Worries that there is a lot of duplication in bootstrapping that
        would benefit for some standardization
    Boostrapping will be easier than Imprinting since there is more
        work going on
Hoffman: Has anyone looked at imprinting work being done elsewhere?
    Eronen did a short survey of imprinting, has a bunch
    Rescorla also has a pile of papers

Hoffman proposed that a terminology document would be useful if we
    don't produce anything else
    Could help other WGs
    Could elicit some independent model document
    No volunteers came forward; maybe after the meeting
Hoffman: what about a survey of what the IETF has done so far on
    bootstrapping and imprinting
    Shore somewhat accepted that task
    Can use Tschofenig's slides as a start



None received.