(introduction) Re: [ietf-enroll] Charter

[Trevor Freeman]

Hi Max,
What we don't have is a universal provisioning framework which covers a
variety of credential types. That said since the existing enrolment
protocols are transport independent, once a decision is made to for
example to enrol for a certificate, that we could use an existing
mechanism to do so. 

I am also not keen on the terms "petitioner" and "registrar". Some of
the documented cases where we have problems are where we are attempting
to establish a new trust relationship with an infrastructure such as a
wireless provider where these terms are appropriate. It would equally be
used to establish a secure session between two peers where I don't think
these terms fit. 

Some policy exchange is necessary in the process in that both parties
need to establish the intent of the new relationship to ensure both
parties are not labouring under a misapprehension.

Trevor



-----Original Message-----
From: Max Pritikin [mailto:pritikin at cisco.com] 
Sent: Thursday, May 01, 2003 9:37 PM
To: jimsch at exmsft.com
Cc: IETF-Enroll
Subject: (introduction) Re: [ietf-enroll] Charter


I'm concerned about the assumptions behind this initial proposal.

What we have here is the start of 'yet another enrollment protocol'. I'd
like to talk a bit about why these previous enrollment protocols have
failed and to present an alternative idea for how we could approach the
problem. I'll use the following inline comments to launch of the
discussion and followup with some more detailed proposals if people are
interested.

On Mon, 28 Apr 2003, Jim Schaad wrote:

> Here is a candidate charter for people to take shots at.
>
> Description of Working Group:
>
> There are many cases where a user needs to obtain credential
information
> from a service provider and provide for some type of information for
> validation of identity.  This working group will look at some of the
> cases dealing with the use of cryptographic algorithms for providing
> this information.

I agree with this statement but will re-phrase it in more generic terms
(a nitpick):

There are many cases where previously unrelated entities need to
establish
cryptographic credential information sufficient for identifying each
other
in latter exchanges. This working group will look at some of the cases
dealing with the use of crytographic algorithms for providing this
information.

For the purposes of discussion we can apply labels to these entities.
The
'petitioner' will be taken to mean the entity (user, new device, new
software etc) joining an existing security infrastructure. The
'registrar'
will be taken to mean the other entity (VPN gateway, CA, service
provider,
Wireless Access Point, software server etc).

> When doing enrollment of a user against a service provider, three
pieces
> of information need to be provided or created in order to support
> authentication of the user to the provider and to allow for additional
> security services to be provided any information exchanged.  These
> pieces of data are:
>
> 1.	The name of the entity being enrolled,
> 2.	A piece of keying information to be used
> 3.	A set of permissions for operations for the entity being
> enrolled.

We continue to be in general agreement here. There is very little
information that must be exchanged to establish a longer lasting trust.
Items 1 & 2 we agree on (Paul Hoffman's right that 'identity' works
better
than 'name').

But item 3 concerns me. If possible it would be nice to avoid going down
the policy and authorization path at this point. I think instead some
information about what the identity and keying information is to be used
for is more appropriate. This is configuration information rather than
authorization information.

Existing enrollment protocols describe various processes by which this
initial key and identity material an be exchanged "out of band". After
this data has been exchanged existing enrollment protocols work
reasonably
well. It is my impression that the problems that exist have less to do
with these enrollment protocols than the "out of band" mechanisms.

So the following can then be redirected:

> 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 base asymmetric key
> 3.	A bound asymmetric key (e.g. an X.509 certificate).
>
> Additionally, the group will consider the case of using a credit card
> profiling the framework.

This group will create a model to be used in describing the 'out of
band'
exchange mechanisms necessary for enrollment protocols. This model,
called
Introduction, will be not be dependant on the (non existent) security
relationships between the Petitioner and the Registrar but will instead
leverage the existing security relationships between these entities and
a third logical entity, refered to as the Introducer.

The group will then produce two documents:

1. The general description of the Introduction protocol and mechanisms.

2. Example profiles of how the Introduction protocol can be used for
advanced deployment scenarios:

	a. The Introducer is a single user at their web browser
leveraging
their trust relationship with a locally administered entity (petitioner)
and their trust relationship with a remote entity (registrar). For
example: a home user 'enrolling' local VPN software or hardware with a
corporate VPN network.

	b. The Introducer is a single organization leveraging their
existing trust relationship with a customer to drop ship pre-Introduced
equipment for later installation and enrollent. For example: an ISP
purchasing a dsl modem from a hardware vendor, having it drop shipped to
a
customer where it can automatically and securely join the ISP network.

	c. The Introducer is a complex system of business decisions and
IT
staff decisions that results in two devices able to engage in

Some more about this Introduction concept:

Given two entities that wish to exchange cryptographic material we see
'out of band' used, to set things up:

  P<---- no existing keys ----->R
  |                             |
  |admin using                  |admin using
  |local keys K1                |local keys K2
  |                             |
  A1  <-----out of band----->   A2
                 K3

Now using the keys exchanged "out of band" P and R establish a
connection
and 'enroll' (turning these simpler credentials into something longer
lasting).

Recognizing that 'out of band' really means 'using some other secure
mechanism' what we really have is a situation where A1 uses a K1 to
communicate with P and K3 to communicate with A2. This four corner
discussion is hard to wrap a simple protocol around; but if we simplify
it
we see:

  P<---- no existing keys ----->R
  |                             |
  |using                        |using
  |local keys K1                |local keys K2
  |(A1)                     (A2)|
  +---------Introducer----------+

Where on the left side we see K1 used to communicate between P and I,
and
on the right side K2 used to communicate between I and R. (Note that A1
and A2 are still in the diagram, they are systems though and if there is
anything we can do well it is provide interfaces to systems that allow
us
to treat them as one logical entity).

Now we can talk about leveraging the transitive trust relationship
across
I to establish a direct relationship between P and R.

(This was more than I meant in an initial email on this subject)

- Max Pritikin

> 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 module 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
>
>
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll
>
_______________________________________________
ietf-enroll mailing list
ietf-enroll at mit.edu
https://mailman.mit.edu/mailman/listinfo/ietf-enroll