[ietf-enroll] Please help with TTI model document v2

[Thierry Moreau]

Paul Hoffman / VPNC wrote:

> At 8:51 PM -0700 9/24/04, max pritikin wrote:
>
>> Comments highly appreciated!
>>  . . .
>> Thanks for any feedback,
>
> Indeed. This is a weird WG; there seems to be lots of interest but 
> very few people sending input to the mailing list. If y'all are 
> interested, please review and comment!

General observations about the TTI modeling

The science of physics showed that a model is usually neither
right or wrong. A model is more or less useful in explaining
current (and predicting future) observations.

In the TTI model, the object matter of observations would be
*enrollment and configuration protocols* and the observations
are issues such as:

     the use of symmetric or asymmetric cryptography in a
     protocol to achieve some introduction material agreement
     elements

     integrity, authentication, and trust, where these notions
     needs to be defined

     authentication:     with regard to introduction, a sense
          of assurance for an entity A that a given
          cryptographic key is under the control of a given
          entity B,
                    with regard to a cryptographic protocol, a
          cryptographic assurance that a protocol element can
          be successfully performed only by an entity that
          controls a given cryptographic key

     integrity:     some assurance about a data element for an
          entity, based on assumptions that are either well-
          known in the trade (e.g. given a symmetric secret
          key, a MAC mechanism provides data integrity) or
          that should be explicit in the documentation of a
          security scheme

     trust:    an a-priori assurance for an entity that a set
          of procedural elements is performed as stated in the
          documentation of a security scheme

     the recourse to cryptographic mechanisms *or procedural
     mechanisms* to ensure integrity, authentication, and
     confidentiality protection (the TTI model implies some
     non-crypto procedural mechanisms such as a sealed
     envelope for confidentiality or direct contact with a
     person or an entity representative for authentication).

     Note:     I didn't attempt to define confidentiality
               since the use of this term in section 5.1 and
               5.2 of the draft is very ambiguous
               (cryptography-based or procedural-based,
               whether confidentiality implies a pre-
               established association between the introducer
               and either petitioner or registrar, whether
               these matters are addressed by the model or
               not)

Another measure of a model usefulness in the field of
information security would be a threat analysis where any
entity role in the model is (analytically) subverted to
identify potential vulnerabilities. The model would be useful
if the threat analysis applied to the model predicts the
threat analysis applied to the enrollment and configuration
protocol.

These general observations being said, the current TTI
document (draft-pritikin-ttimodel-02.txt) fails to address the
general problem (no prior relationship between the petitioner
and the registrar) in clearly specifying how non-cryptographic
measures (that are deemed to be severely constrained by
operational, economic and cultural issues, e.g. respectively
non-practicability of manual hash verification, high cost of
manual symmetric key distribution, level of compliance to
credit card number privacy guidelines) can be leveraged upon
with the help of an introducer to come up with some level of
authentication assurance for the registrar.

A description of a TTI model (perhaps the TTI losing its
original significance) is certainly possible that would
  1)  start with definitions of confidentiality,
authentication, trust, and integrity, both in cryptography-
assisted sense and procedural sense (e.g. some confidentiality
provided by courier service, some integrity provided by the
look-and-feel of a user interface),
  2) define some typical procedural actions (device
manufacturing-time imprint, obtaining authentication assurance
by observation of a transmission characteristics, ...),
  3) encompass alternate TTI exchanges (set of crypto-assisted
digital protocol elements and out-of-band actions) with their
respective trust assumptions,
  3) claim some security properties for  TTI exchanges so
described (e.g. at the end of the exchange, the registrar is
satisfied that the key XYZ is indeed controlled by the
petitioner).

For sure, the alternate TTI exchanges would be influenced by
the most wanted solutions (e.g. wireless introduction and
enrolment), but the level of description abstraction should be
such that closely related TTI exchanges could be merged and
diverging ones could find a common terminology for their
relative understanding.

I was under the impression that some contributions to the
mailing list were moving forward in that direction, departing
from the narrow view that "recursive use of prior associations
is the strength of TTI."

Unfortunately, I am not in a position to commit resources to
the advancement of this project.

Sincerely,

-- 

- 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