[ietf-enroll] Future of this WG

[Randy Turner]

Hi Thierry and group,

I think the solution space for my trusted device issues I spoke of  
earlier can fit within your constrained charter
and requirements. I think you did a pretty good job of trimming the  
fat regarding where the real problem is.

I think it's going to be difficult to rationalize some of what would  
be a resulting "enroll" solution without calling attention
to particular business models that we are trying to address. If this  
is just simply reaffirming the problem, then I think we
still need a problem-space review. At a plenary meeting last year, I  
know I couldn't really describe the problem to folks without
talking about one or more business models that an enroll solution  
would have to support.

FYI, when I have plotted initial solutions to this problem space, the  
enrollment credentials are transient, and expire rapidly. If the
enrollment process is not initiated within a short period of time,  
the communication of the bootstrap credentials from provider to
consumer has to be repeated, with another new temporary credential  
token.

Randy


On Jun 17, 2005, at 1:07 PM, Thierry Moreau wrote:

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