(introduction) Re: [ietf-enroll] Charter

Tue May 6 23:01:35 EDT 2003

Max,

> 
> 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.
> 

In this paragraph you have made some assumptions that I don't
necessaryly want to make.

1)  There is bidirectional identification.  I can see cases where the
identification may only be in one direction.  
2)  The entities are necessarily previously unrelated.  This is the
normal case, but not necessarilly the only case. 

> 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).

So petitioner == user and registrar == service provider.

> 
> > 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.

See my response to Paul on this.

> 
> 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.

Not all enrollment mechanisms require that out of band data be supplied.
This is esp. true if one is using the bound asymmetric key below or in
many cases where you are using shared secret information.  Examples
would be I don't really care who you are, you don't really care who I
am, you provide a service of some type.

>From the above, this does not follow.

> 
> 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.

This might be a good document to write, but let's wait until we know
there is an introducer in the framework.

> 
> 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
> 