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

Mon Oct 4 16:56:51 EDT 2004

Folks, I think the comments/discussions below are very interesting. I'd
be interested in hearing your thoughts on the issues raised, my
responses and any other elements of the document you feel should be
improved.

If there are details you feel should be specified I'd be even more happy
to see sample text and/or discussion sent by the list. 

thanks,

	- max

On Wed, 2004-09-29 at 15:06, max pritikin wrote:
> 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,
> 
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll