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

[Pekka Nikander]

[Leaving the IESG out from the CC: list since it looks like
  we need to produce a new charter version anyway.  Adding
  security ADs instead, since they may still be interested.]

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

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

>>> 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 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
   - resurrecting duckling by Stajano and Andersson
   - leap-of-faith from our Cambridge paper
   - something that uses a credit card transaction / other
     monetary transaction as the "identification" function
     for enrollment.

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.

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

A "mechanism" is a good word.  It says that we have to spell out
how things work and interact.  Hence, maybe we should speak about
"frameworks for mechanisms"?

>> At the previous BOF I presented the so called "weak" authentication
>> model, based on our paper at the Cambridge Security Protocols Workshop
>> ...
> 
> I think there is significant value in determining how one would leverage
> the weak authentication mechanisms to perform enrollment into stronger,
> long term, authentication infrastructures. 

Agreed!

>                                              Consider person using 
> leap-of-faith (as described in your document) to deploy a new device,
> audio/video equipment, into their home. After some period of time they
> wish to enroll this device with a video conferencing provider. This new
> association should be able to build on the existing, time tested, weak
> authentication to provide strong authentication moving forward.

A good example!

>>Hence, I would suggest broadening the scope of the profiling work.

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