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

[max pritikin]

Thank you for your comments. Some notes inline,

On Wed, 2004-09-29 at 13:53, Thierry Moreau wrote:
> 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:

I think we're in general agreement here. Although I think TTI is more
focused on what needs to happen 'prior to' enrollment and configuration
protocols. Modeling current enrollment & configuration protocols is, I
believe, less bounded which results in difficulty when determine
correctness of the model (e.g. the resulting models are not as useful as
intended).

This following list of observations is interesting for each leg (I-R,
I-P) of the introduction. But for introduction itself I'd though to
focus on a different list (as outlined in the section 5 sub-sections).

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


This list of observations is interesting wrt to the details of
individual protocols used at each leg (R-I, I-P) of the introduction.
But for introduction itself I'd though to focus on a different list (as
outlined in the section 5 sub-sections). 

Namely:
     5.1   Registrar - Introducer communication channel . . . . . . . 13
     5.2   Introducer - Petitioner communication channel  . . . . . . 13
     5.3   Introducer binding of (R-I) and (I-P)  . . . . . . . . . . 14

I like the suggestion that I clarify cryptography-based vs
procedural-based confidentiality.

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

Keeping in mind that I'm talking about the _introduction_, my thought is
that a threat analysis of the 5.1,5.2 and 5.3 issues provides a basis
for the threat analysis of any subsequent enrollment and configuration
protocols. 

For example if I-P or R-I (or 'I' itself) does not provide
confidentiality then the subsequent enrollment and configuration
protocols had better not depend on it. (e.g. they should use public key
technologies). 

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

I don't follow you here. I think the TTI model is 'useful in explaining
current (and predicting future) observations' in directly this space. It
is clear from the model that procedural based confidentiality/integrity
is needed between the Introducer and the Petitioner when no prior
security association exists. 

Whereas cryptographically based confidentiality/integrity can and must
be used from the Introducer to the Registrar in all cases.

By making this distinction (and providing a basis for discussions about
how the binding occurs) it is possible to evaluate the operational,
economic etc issues *and* helps predict solutions which minimize those
costs. 

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

The addition of these definitions makes sense. I'd mostly left them out
thinking that at this stage anybody that reads the document has a
general idea of them.

>   2) define some typical procedural actions (device
> manufacturing-time imprint, obtaining authentication assurance
> by observation of a transmission characteristics, ...),

I'd hoped to do something like this. The feedback seemed to be that what
you are describing is not a 'model'. Certainly procedural actions don't
match your definition given above.

(I do believe that the model helps to predict the ideal introduction
mechanisms/procedures; which should be standardized).

>   3) encompass alternate TTI exchanges (set of crypto-assisted
> digital protocol elements and out-of-band actions) with their
> respective trust assumptions,

>From the document abstract you'll note that TTI defines that 'out of
band' exchange. The goal being to clarify which trust assumptions are
being made and how to leverage them best.

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

Depending of course on the trust put into the 3 elements dicussed above
(R-I, I-P, I). Any security vulnerabilities involved at that point need
to be evaluated against the enrollment mechanism used. Again refering to
the example of symmetric vs asymmetric keys: if any one of R-I, I-P or I
fails to provide confidentiality then the enrollment protocol better not
depend on it.

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

It sounds like I'll regret ever writing that sentence. The take away is
that TTI gives us a way to model the complex out of band exchange which
itself depends on existing security associations in addition to
(possibly) physical security.

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

Thank you for your time here though,

	- Max

> Sincerely,