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

[Max Pritikin <pritikin@cisco.com>]

[catching up ... for once i have a real excuse: i got married]

Some discussion inline,

On Sat, 2003-10-25 at 01:51, Pekka Nikander wrote:
> The IESG wrote:
> > A new IETF working group has been proposed in the Security Area.  
> > The IESG has not made any determination as yet. The following description 
> > was submitted, and is provided for informational purposes only.  Please send 
> > your comments to the IESG mailing list (iesg@ietf.org) by October 27th.
> 
> While I strongly agree that this is an important piece of work and
> needs to be chartered, I am not quite happy with the proposed charter.
> In general, I find it too vague.   In other words, I am afraid that
> the working group might initially spend far too much time in arguing
> what exactly to do, before the real work begins.
> 
> In my opinion, the charter should be discussed more at the
> mailing list before finalized.
> 
> Specific comments below:
> 
> >  There are many cases where a service consumer needs to contact a
> >  service provider to get credentials that the consumer can use when
> >  accessing the service; part of this initial contact may involve
> >  the consumer and the provider mutually validating the other's identity.
> 
> So far so good.
> 
> >  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."

> I am also confused about the relationship between credential
> provisioning and authentication here.  That is, I don't really
> understand what the last sentence refers to.  Does it refer to
> the validation of identity, i.e. is the "authentication" identity
> authentication?  If so, I think that the text should be clarified.
> If it refers somehow to the credentials provisioning process, I
> have to confess that I am really buffled about its meaning.

>From my perspective current enrollment mechanisms punt on this entire
issue. They assume that some (undefined) out-of-band system is used to
get the  authentication material exchanged. The documentation might
discuss the requirements for this  (e.g. "keep the secret" or "send the
peer the fingerprint of the public key via a secure mechanism") but
there is not a formal protocol that helps facilitate it.

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

> Furthermore, it is not quite clear to me from the description whether
> the set of permissions are automatically valid or not.  Maybe this
> vagueness is deliberate?  If so, I think it should be spelled out.
> If not, 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. In other
words what types of credentials should be obtained, what their lifetime
might be, etc. This is not general permissions/configurations for the
entire service provider/consumer relationship but rather just for the
enrollment aspect of that relationship.

> I would suggest rewording as follows:
> 
>           3. A set of service consumer permissions and other attibutes.
>              The permissions describe to the provider the services that
>              the consumer wants to access and is authorized to access.
>              They describe to the consumer what services offered by
>              the provider will be accessable.  The other attributes are
>              other pieces of data that are created during the credential
>              creation process and associated with the consumer, but that
>              do not fit into the description of a "permission".
> 
> >  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.  Right now, they do not say much to me.  Does
> to model attempt to provide patterns for real world operations and
> actions, i.e. something that happens outside of the digital domain?
> Or is it purely limited to actions within the digital domain?  Or
> something in between?

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 would be happy to have text or concepts from that document/model
worked into the charter if people are comfortable with the concepts
outlined.

> What is the specific purpose and nature of the framework?  Maybe I am
> dense, but it is not clear to me.  Does it give an outline for possible
> real world operations that could be augmented by some IETF protocol?
> Or what is the purpose?

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

> I think that the sentence above should be clarified.
> 
> >  The group will then produce three documents profiling the use of the
> >  framework for the following types of keying material:
> > 
> >        1. A shared secret key.
> >        2. A bare asymmetric key.
> >        3. A bound asymmetric key (such as an X.509 certificate).
> 
> This makes me think that the focus of the work is on keying information.
> However, based on my previous work with SPKI, Keynote, and other
> decentralized security systems, I am pretty convinced that there are
> likely to be differences in other dimensions as well.

Again drawing from the concepts in my TTI draft I suggest that this work
covers the 'out-of-band' and 'out-of-scope' things that have to happen
to deploy security systems. (All of them).

> At the previous BOF I presented the so called "weak" authentication
> model, based on our paper at the Cambridge Security Protocols Workshop
> a couple of years ago.  From that point of view, a very important
> aspect is the amount of assurance one has on the result of the
> enrollment process, i.e., who might have been able to eavesdrop the
> keying material during the enrollment process.  (Not all enrollment
> will be perfectly secure, since such strong security requirements
> seldom make sense in the commercial world.)

I wish I'd been able to attend that presentation. One of the stated
values of the Introduction model is that it can build on "weak"
authentication (see section 6 where I included a very short discussion
that overlaps some of the weak authentication concepts).  

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

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

Could you elaborate on this?

> Finally, I do not see any list of concrete goals.  I would like to
> see the potential deliverables of the working group to be explicitly
> listed, together with scheduled milestones.

This is excellent feedback.

	- Max

> As a minor nit, it would be nice if the charter proposal would list
> the names of the proposed chairs, too.
> 
> --Pekka Nikander
> 
> 
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll@mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll