[ietf-enroll] Future of this WG

[Thierry Moreau]

Dear all, Randy and Paul:

Is there any next step for the ietf-enroll working group?

Perhaps the ietf-enroll activities has been too ambitious,
and became entangled in a mix of business processes
formalization, protocol and key management abstraction, and
the recurring difficulty in defining terms associated with
security services, e.g. "authentication". The reference to
credit card numbers in the wg charter didn't point towards
segregating business processes from protocol and security
formalism.

On another front, there are deployed methods, often with a
significant dose of leap-of-faith for the authenticated
enrollment of customers in secure services. For instance,
the enrollment of PKI users prior to the first certificate
issuance. Also, the use of subscriber identity modules (SIM)
as a basis for mobile telephony authentication (which I
overlooked in my survey document
http://www.connotech.com/sakem_white_paper_06.htm). The fact
that some of these deployed methods are little formalized
and yet commonly relied upon made it difficult to come up
with unifying definitions.

When secure services enrollment is discussed, very often we
encounter a confusion between credentials reuse and
bootstrapping a security association from virtually no prior
relationship. Another ietf working group, isms, is perhaps
facing the same issue, where the attractiveness of SNMPv3
security scheme is at stake: the business motivation
strongly points towards credentials reuse (e.g. RADIUS)
because organizations are deemed to ignore any network
management security solution that requires up front security
provisioning of managed devices. But SNMPv3 is an
application-level protocol for which few security
infrastructure solution, if any, can realistically provide
keying material to an application like SNMPv3 software
engine. If credentials reuse is hard when the next
generation of network management is at stake, it might be
very hard when only "formalism-on-paper" is at stake.

This isms and ietf-enroll working groups also share the two-
sided problem of a) authenticated enrollment and b)
authorization provisioning. In isms, the first goal was
realistically limited to a) by the charter, even if a) and
b) are identified.

Here is a possible course of action for ietf-enroll:

  A)  Leave aside authorization provisioning.

  B)  As much as possible, leave aside credentials reuse.

  C)  Provide a single framework for the three types of
      keying material (shared secret key, bare asymmetric
      key, bound asymmetric key).

  D)  An empiric approach, using evidence collected for a)
      deployed and prevailing enrollment schemes and b)
      "selected" secure scheme descriptive documents (e.g.
      omit far fetched schemes). This empiric approach
      implies that "authentication" might be a different
      notion in different enrollment schemes. Other security
      concepts should be easier to reconcile.

  E)  Stay away from attempts to formalize business
      processes, except to the extent they are closely
      related to an enrollment method.

  F)  Stay away from any protocol issue past the enrollment
      phase (e.g. stop when a certification authority has
      learned a PKI client public key under some
      "authentication" requirement).

  G)  It should be determined early whether a low entropy
      password is considered to fall in the definition of
      "shared secret key".

Within these narrow parameters, perhaps a framework document
would be of little use. If yes, then ietf-enroll may well
shut down.

Any ideas? Randy, can you relate your understanding of
"trusted device deployment problem" to the above?

Cheers

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau at connotech.com