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

[Pekka Nikander]

Max Pritikin wrote:
> Inlined and trimmings where appropriate,

Likewise.  But executive summary first:

   I seem to have two remaining problems, once the so far discussed
   modifications to the charter have been made.  The problems are
   the following:

   - The exact type or kind of the model, i.e., a security policy model,
     a process model, or what.  I would like to see some
     characterization.

   - The plurality and expressiveness of the model(s).  IMHO, sticking
     to TTI is probably too restrictive.  Instead of that, I would like
     to see a more generic model that grasps more of the semantics of the
     possible enrollment systems.

>>>> ...  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.
>>
> 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 is clear to me.  What is not clear is the expected semantics
of the permissions/credentials.  But perhaps that is so application
specific that it should be left completely out of scope.  But if we
do so, the charter should read so, explicitly stating that the semantics
of the permissions/credentials are out of scope, and that an enrollment
method MAY create credentials that are invalid (of course it SHOULD NOT
do so, but in some cases it MAY).

> 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 still think that the TTI models is not universal.  While it
is useful, sticking to it may leave out important scenarios.

IMHO, we should scope the charter so that TTI is one model to
be considered (perhaps the main one), but not the only one.

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

Maybe so, but it is different from the TTI model.  There is no
Introducer, unless you take the human who makes the physical contact
between the devices such an Introducer.  But even so, the security
of the model does not depend only on the competence of the human actor,
but also on the physical contact between the devices.

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

In this case I would argue even stronger that sticking to TTI goes
too far.  In LoF there is no third party, the security properties
depend on different communications over a span of time and links.
There is no introducer.

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

In this case there indeed are three parties, and you can take
the credit card company as the Introducer.  However, at least right
now it is unclear to me whether TTI is the right way of modelling this.

Hmm.  I think that my problem is that TTI seems to be missing
some important semantic aspects which should be described by
the kind of model I am looking for.  I have to think about this more.

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

Well, "a model for introduction" is not much better.  It doesn't
tell what kind of a model, i.e. security policy model or
process model or what.   There are zillions of *types* of models.

I think we pretty well understand the object of the model, i.e. the
system under investigation that we want to model.  But the *kind*
or *type* of the model that we want to produce is much less clear.

Remember that a 'model' is merely an abstraction of a system,
trying to describe some aspects of the system while leaving many
other aspects out.  What is important here is to somehow characterize
which aspects of the system we want to include into the model and
which ones we want to leave out.  To gain understanding on this
(prior to producing the model itself), we have to have a clear
understanding of *why*, exactly, we want to have the model.

This is still unclear to me.

>>>>What is the specific purpose and nature of the framework? ...

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

Much better.  One more question:  why just *a* mechanism instead
of a set of mechanisms?

> Having scenarios is a good idea. To start the list (some of these look
> redundant to me),
> 
> 1) "teleworker"
> 2) "grandma in the country" [grin]
> 3) "online billing"
> 4) "touchless deployment"
> 5) "establishing an account"

Excellent.  While I personally like all of them, "touchless deployment"
is really the one that is important for my employer, partly motivating
my participation to this work.  Hence, I think that we may need a few
variants of that, and maybe of others, too.

Anyway, your list is probably a sufficiently good list to be included,
as *examples*, into the charter.

--Pekka Nikander