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

[Max Pritikin]

The term 'model' is so overloaded that we run the risk of discussing
semantics. From  this discussion I think we have both policy and process
models (if I understand the distinction between those correctly).

I'm thinking the TTI model is a _process_ model for secure enrollment
using an 'out-of-band' data exchange between any three entities. As a
process model it is well suited for use in developing a protocol for
general enrollment; which is a good goal. 

TTI covers those cases where three entities are involved in an
enrollment (e.g. device-user-service, service-user-service,
retailer-device-consumer, bank-retailer-service,
"petitioner-introducer-registrar" etc).

The three entity introduction model depends on a prior enrollment
between the two sets of entities within the three entity model (e.g
prior associations between the petitioner-introducer and the
introducer-registrar). 

Obviously these prior enrollments could be established by recursion -- a
prior TTI exchange. More interesting is when they are established via a
two entity 'weak' authentication mechanism. How weak this is depends on
how and when the mechanisms was applied -- which is determined by
policy. Thus we have a set of policy models that cover the different
types of two way enrollment ("leap of faith", "imprint" etc). I have a
difficult time seeing how a policy model can be used to write a
protocol.

>From these thoughts I offer these inlines,

On Thu, 2003-10-30 at 04:09, Pekka Nikander wrote:
> 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.

A process model covering enrollments involving three entities
(introduction) and a policy model discussing two entity ('weak'
authentication) enrollment.

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

If we limit TTI to only a description of the three entity process model
then I agree that we'll need to discuss more fully the two entity policy
model(s). Until now I've considered the two entity policy statements to
be an integral part of TTI.

> >>>> ...  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've defined them as out of scope (other than that they are
transported). They are the information necessary for a two entity
_strongly_ authenticated enrollment. I've been thinking that there are
multiple protocols out there that provide this today.

> > 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.
[snip]

Either that or TTI needs to be expanded to cover the two entity weak
authentication discussion in more detail (above I meant to type, "I
would propose..."). It strikes me that policy models are hard to turn
into protocols.

	- Max