(introduction) Re: [ietf-enroll] Charter
Max Pritikin
pritikin at cisco.com
Wed May 7 11:34:55 EDT 2003
Hi Travor, welcome to the discussion.
Actually one of the examples (3) has no user involved. I can provide
more:
5) Assume DRM has taken over the world and my media technology is now a
cryptographically enabled smartcard prepared to stream data to local
devices (gosh, I hope not!)
Petitioner = the local DRM capable speakers
Introducer = the media technology that detects the speakers
Registrar = the DRM folks at RIAA
6) Say I head over to a friends house and want to join (for the day) his
secure wireless network.
Petitioner = my portable and wireless card
Introducer = his portable
Registrar = his wireless access point
(My portable and his communicate using the IR wireless).
In almost all these situations a user of some sort may be involved. For
example in (6) my friend might be on the Introducer to click a button
and authorize my portable to be introduced to the network (unless he has
it set that any device that can physically talk to his ir port can be
introduced to use the wifi). An important point though is that the user
never sees or manually excanges any "out of band" data.
In other words he doesn't give me a password, doesn't show me a
fingerprint, doesn't email a certificate. In that important sense he is
NOT involved in the actual enrollment. Just authorization; which I
content is out of scope anyway.
With an introduction/enrollment model like this we can talk about
building up secure networks that don't have to keep reverting to the
lowest common denominator (password) whenever a user is involved.
- Max
On Wed, 2003-05-07 at 05:58, Trevor Freeman wrote:
> 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
>
More information about the ietf-enroll
mailing list