[ietf-enroll] Re: [New-work] WG Review: Credential and Provisioning (enroll)

[Max Pritikin]

Inlines and trimmings where appropriate,

On Wed, 2003-10-29 at 00:07, Pekka Nikander wrote:
[snip]
> Max Pritikin wrote:
> >>> This working group will look at some of the cases where cryptography
> >>> is used to provide authentication.
> >>
> >> I'd like the charter to be more specific on what these "some of the
> >> cases" are.  It is not clear to me, and I was at the BOF.
> > 
> > What about,
> > 
> > "This working group will look at how cryptographic authentication of
> > these initial contacts can be achieved and what the appropriate behavior
> > is when cryptographic authentication can not be achieved."
> 
> Better, but how about the following?
> 
>    "This working group will look at how cryptographic identity
>     authentication can be achieved for these initial contacts and
>     what the appropriate behaviours are when such cryptographic
>     identity authentication cannot be achieved."

I'm ok with this.

> That would also clear my previous confusion.
> 
> >>>    3. A set of service consumer permissions. These permissions
> >>>       describe to the provider the services that the consumer
> >>>       wants to access, and they describe to the consumer what
> >>>       services offered by the provider will be accessable.
> >>
> >> I think this may be too restrictive.  While I agree that creating
> >> a set of permissions is the most common and most needed case, there
> >> may be settings where additional, non-permission attributes might
> >> be useful.  (I think Erik made this point, too.)
> > 
> > What if we refer to this as 'configurations'? The point is that in
> > addition to exchanging cryptographic material there is some data that is
> > exchanged or instantiated that is applied to this material (or entities
> > being identified with the material) during subsiquent exchanges.
> 
> It looks like that we agree on what is desired.  The question
> seems to really be about wording.  "Permissions" appears to be
> too restrictive.  "Configuration" doesn't really match what we
> mean, IMHO.  "Attribute" may have too strong ties to attribute
> certificates (or does it)?  Erik suggested "parameters".  Maybe
> "permissions and other parameters" would be OK?

I'd be ok with 'permissions and other parameters'.

> >> ...  I would explicitly mention that the permissions describe the
> >> set of services that the client is authorized to access. ...
> > 
> > ... Where the set of services can be limited to actual enrollment.
> 
> Ok, just spell it out, please.

Again I fall back to the TTI model for my conceptual framework. These
'permissions and other parameters' are the result of the introduction
process (out-of-band or otherwise) and describe the credential that is
about to be generated. There are two aspects of this description, the
client (petitioner) needs to know how to recieve and handle the
credential (enrollment protocol, storage requirements, etc) and the
server (registrar) needs to know the parameters of the credential being
generated (lifetime, keysize, name, etc).

> >>> 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.
> >>
> >> I think the charter should be more explicit in the nature of the
> >> model and framework.  ...
> > 
> > Here I start pushing the TTI draft already presented to the list. TTI
> > provides the 'something in between'. It is in the digital domain and
> > taylored to model the 'introduction' mechanisms used in the real world.
> 
> I had a quick glance at the TTI draft, but didn't have time
> to really concentrate.  However, independently on that, I think
> that the charter should be much more clear in this point.

I agree, the charter should be clearer on this point. I propose the TTI
model to be adopted but recognize that it needs more review on the list
before we take that step.

> > I would be happy to have text or concepts from that document/model
> > worked into the charter if people are comfortable with the concepts
> > outlined.
> 
> Well, my current feeling is that the TTI model is only one,
> even though an important one.  There are other important models,
> not based on a third party but e.g. a business transaction or
> people meeting each other physically.  (If you want a concrete
> example, think about the resurrecting duckling model by Stajano
> and Anderson).
> 
> Hence, saying that the group will create a model is somewhat
> dangerous.  I would rather see that the group would explore a
> number of existing enrollment models, and attempt to produce
> a synthesis or summary of them.  If that approach is taken, then
> it is also important to list a number of starting points.  I
> would suggest the following ones; there are sure to be others
> that I am missing right now:
>
>    - TTI

Actually I was attempting to describe the TTI model as an appropriate
framework for using these various enrollment mechanisms.

For example,

>    - resurrecting duckling by Stajano and Andersson

If I understand this correctly it is an example of a weak authentication
'enrollment' between the Introducer and the Petitioner, or Introducer
and Registrar. The TTI model then builds on this.

>    - leap-of-faith from our Cambridge paper

Similiarly. These are examples where a weak authentication mechanism is
used between any two of the TTI entities.

>    - something that uses a credit card transaction / other
>      monetary transaction as the "identification" function
>      for enrollment.

A credit card transaction is an example of an existing authentication
mechanism between two of the three TTI entities. 

> If we take these as starting points, then we can perhaps
> speak about "security policy models for enrollment".  To me,
> a "security policy model" is a clear enough concept, covering
> models such like Biba, BLP, Chinese Wall, etc.
> 
> Or should we talk about "process models"?  Would that be more
> appropriate.  A "model for enrollment" is really far too vague.

Agreed. I prefer "a model for introduction", which is really much more
specific. After introduction enrollment is a protocol between two end
entities.

> >> What is the specific purpose and nature of the framework? ...
> > 
> > How about,
> > 
> > "To provide a standards based mechanism for leveraging various existing
> > authorization and authentication infrastructures to secure the
> > enrollment of new entities into an independant authorization and
> > authentication infrastructure." ?
> 
> Far too hard to parse, and a little bit too vague.  I must be
> appearing dense by now (and perhaps I am), but I still don't
> get it.  Perhaps we should discuss in much more concrete terms.

"The framework provides a cryptograhic introduction mechanism that
allows existing security relationships to be leveraged in producing new,
independent, relationships." ?

[snip]
> Well, I think that maybe the working group should produce a
> scenario document first, outlining a number of enrollment
> scenarios that the working group would consider.  That would
> help to make the work much more concrete.
> 
> --Pekka Nikander

Having scenarios is a good idea. To start the list (some of these look
redundant to me),

1) "teleworker"
User purchases a VPN device at a local retailer and wishes to connect it
to their corporate VPN network.

2) "grandma in the country" [grin]
Naive user purchases a digital camera and wishes to use it to exchange
video and pictures with family members through an online service
provider.

3) "online billing"
Web user wishes to setup automatic payments between their online bank
and their online Music provider.

4) "touchless deployment"
Administrator wishes to order a device from a retailer and have it drop
shipped to a remote part of the world. A non-tech person might provide
it power and plug it in but all administrative tasks must be local.

5) "establishing an account"
A user wishes to setup a new account with a service provider. 

	- max