(introduction) Re: [ietf-enroll] Charter

Tue May 6 14:15:46 EDT 2003

Hi Trevor, thanks for the response (I was beginning to wonder if anybody
was out there). 

I am not married to 'petitioner' and 'registrar' but needed something to
call them and after many changes have settled on these. I'm still open
to variations. ('petitioner' and 'authority' were used reasonably
successfully in many of my drafts). Ideas? I'm not sure what you are
getting at when you point out these work well in the wireless space, are
you worried that the terms are already in similiar use?

Anyway, I agree that we don't have a universal provisioning framework.
It is unlikely that we'll be able to invent one in the context of this
group either. What I propose is a model for how to look at the very
beginning of enrollment, introduction if you will, and how to approach
that. 

The introduction process is portion of enrollment by which the peers
exchange the extremely initial key material and perform some 'policy
exchange'. This happens PRIOR to the having any key material between the
peers and is usually handled by an application specific "out of band"
mechanism.

The Trusted Transitive Introduction model provides a framework around
this introduction. It realistically addresses the problem of initial key
and 'policy' (I don't like this term, I use 'configuration'!) exchange
by defining the mechanisms for the 'out of band' data exchange. We
should be doing this in a transport independant manner, although certain
transports are well deployed and can be used. For some common transports
we can provide detailed discussion and sample implementations (e.g. a
user with their web browser).

Introduction is a gaping hole in exist 'enrollment' protocols (of which
there are many). I'd be happy to define a new enrollment protocol but,
as we've seen in pkix having multiple enrollment protocols to choose
from doesn't solve deployment problems. 

Each new approach seems to do one or both of 1) defining new message
formats and crypto processes and 2) define some vertical mechanism for
introduction. For example Robert Moskowitz's recent SSPP draft sent to
this list defines an interesting new mechanism for (1) but for (2) goes
on to state [Section 3.1 Managing Risk in SSPP]:

   The client needs some method of validating the serverÆs public key.
   This can be through a check of the fingerprint (hash) of the public
   key, where the fingerprint was obtained in some out-of-band process.
   Or the physical network between the client and server might be such
   that no man-in-the-middle is possible (for example with a crossover
   cable in a deployment staging area).

   Any instantiation of SSPP needs to examine how an attack might occur
   and mitigate those attacks.

Essentially leaving introduction up to the implementation. 

I strongly feel that having an general introduction protocol to handle
bi-directional introductions would solve a large class of enrollment
related problems; and would help provide a kick start for provisioning
frameworks (universal or otherwise). 

Comments?

	- Max

On Tue, 2003-05-06 at 09:10, Trevor Freeman wrote:
> 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