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

[Pekka Nikander]

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

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.

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

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.

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?

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?

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.

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

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

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.

As a minor nit, it would be nice if the charter proposal would list
the names of the proposed chairs, too.

--Pekka Nikander