(introduction) Re: [ietf-enroll] Charter

[Trevor Freeman]

All of the example quote are user to infastructure. I believe there is little difference between user and infrastructure introductions and user to user introductions with the objective of ad-hoc relationships. Therefore the terminology "petitioner" & "register" seems a little weighed to that end.
 
I don't think we need to limit the exchange to the cryptographic capability of the user. /we can typically establish strong cryptographic link between two parties, what we then have to figure out is ways to establish mutual indention. ?That does not have to be restricted to a cryptographic based proof of identity.
 
I have had trouble registering with this list and am hoping I have now rectified this so you may see some more postings if the list moderator decides to forward them.
 
Trevor 

________________________________

From: Max Pritikin [mailto:pritikin at cisco.com]
Sent: Tue 5/6/2003 10:51 PM
To: jimsch at exmsft.com
Cc: 'IETF-Enroll'
Subject: RE: (introduction) Re: [ietf-enroll] Charter



Jim,

(And anybody else...)

On Tue, 2003-05-06 at 20:01, Jim Schaad wrote:
> 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. 

Certainly unidirection introduction is possible - I didn't mean to imply
that it is not. The model I'm proposing handles this very well. If the
Introducer passes key material about the Registrar to the Petitioner
without also passing any Petitioner key material to the Registrar then
you have unidirectional introduction. For example:

 P<---- no existing keys ----->R
 |                            
 |using                    
 |local keys K1            
 |(A1)                      (The Introducer doesn't have
 +---------Introducer        to tell R anything)

(Examples of this include the Introducer being a manufacturer and
shipping P with R's public keys. They also include situations where I is
the administrator who logs into P and types in a fingerprint.)

> 2)  The entities are necessarily previously unrelated.  This is the
> normal case, but not necessarilly the only case.

Previously unrelated entities are, seemingly, the hardest situation to
deal with. So I focused on that sitation first. But if some sort of
introduction/enrollment has already happened then the components can of
course engage in 'self introduction'. Which is to say that they can
leverage these existing security relationships to build future
relationship.

In other words there is nothing stopping the 'Introducer' component from
being co-located with either the Petitioner or the Registrar. This is a
valid example instantiation of the model.


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

Since users are limited in their cryptographic abilities to simple
passwords I tend not to concider them neither the Petitioner nor the
Registrar. I tend to think users are more likely to be a component of
the Introducer ("more likely" is of course not "always").

Some examples of the top of my head:

1) Customer brings home software/hardware and want to use it to securely
contact a service:
Petitioner = VPN client software/hardware
Introducer = A user at their web browser
Registrar  = Corporate VPN gateway

2) A slightly more fun example of same:
Petitioner = Home video conferencing system
Introducer = GrandMa in the country, using browser
Registrar = Family computer in the city

3) BigCorp wants to drop ship a device securely (note: no user)
Petition = The drop shipped device
Introducer = OEM factory ordering system
Registrar = BigCorp datacenter

4) SmartCo uses USB smartcards for customer badges
Petition = The new employee with their new badge
Introducer = The temp agency HR surfer dude taking her picture
Registrar = SmartCo building access database

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

('Entity label' works for me; but here I'm thinking more of the policy
vs configuration vs authorization etc debate. Or did I find the wrong
response to Paul?)

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

A bound asymmetric key like a certificate? In such a situation one has
to know the root key used for binding, and if you want your own key to
be bound you have to somehow get proof that it is really you to the
binder. All the public key enrollment protocols I know of do all of this
via out of band exchanges.

When using a shared secret mechanism you have to first exchange the
shared secret. This is itself an out of band exchange.

The only 'enrollment' (if it could be called that) that does not involve
an out of band exchange is imprinting. Where a device, entity or person
imprints (like a duck) on the first piece of key or identity material it
sees. (e.g. when you bring a new device home and it doesn't have a
password, or has a default password. SSH protocols are often an example
of this where the initial key presented by the peer is then cached and
used from then on; but only because the human "out of band" element
usually slacks off and doesn't check the fingerprint).

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

Can you offer an example of an enrollment mechanism that does not depend
on either an "out of band" exchange or imprinting, or in some way can
not be described using the three entity Introduction model? (Using
previous credentials is an example of what I've called 'self
introduction' and falls entirely within the model)

The primary advantage of this model is that it provides a mechanisms for
building direct trust between two entities by leveraging transitive
trust across third party. If implemented correctly the trust
relationships between the Introducer and the Petitioner and between the
Introducer and the Registrar need have no bearing on the ultimate trust
established between the Petitioner and the Registrar. (Again, this
accurately models what we see today where even the most secure of large
symmetric and asymetric key enrollments start with a simple password
known only the administrators).

Enough for tonight, I look forward to everybodies comments,

        - Max

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

_______________________________________________
ietf-enroll mailing list
ietf-enroll at mit.edu
https://mailman.mit.edu/mailman/listinfo/ietf-enroll