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

[Jim Schaad]

Max,

This message is going to end up very long and probably some what garbled.  I
am writing this in the breaks between work that needs to be done at the
winery and this affects the flow of thought that can be produced.

1.  I really want to change the order of presentations of the data flows
from the simplest to the most complex.  While I think there is a great deal
of possible discussion on this order, it seems to me that the simplest is
the imprint data flow method.  In your current presentation you have added
complexity to this model because of it's second place order and thus your
desire to relate it to the mediated model presented first.

2.  There is a difference in how imprint is used in my world vs. in your
world.  Imprint for me is the really basic things and would not include the
possibility of a secure channel.  This secure channel is present in a lot of
the applications where you use the word imprint.

3.  Section 2 Para 2:  This is not mandatory for public key exchange.
Consider the following scenario -- As register I send a DH public key &
parameters along with a secret to the petitioner.  The petitioner then
creates a private DH key in the group, sets up a public key encrypted
channel and sends the secret across to prove identity.  

4.  Section 2 para 3:  We are still talking about OOB communication.  I
think the first sentence should be "manual 'out-of-band' communication"

5.  Section 2 para 5:  'Trent says "Alice, meet Bob. ..."

6.  Here is some updated thoughts about what I think needs to be in the
primary area of section 3.  If we are doing a model then we need to talk
about all of the important pieces of the model and define what they are and
what they are expected to do.  Following this some examples would not be out
of order.

X.X  Model Components

In the model there are six different components that need to be looked at.
Not all components are used in all of the data flows laid out in section
4.0, but all are considered to be part of the model.

                           ---A---->  P
                           |          ^
                           v          |
                           I          B
                           ^          |
                           |          v
                           ----C--->  R

Petitioner - This is the entity that is trying to join the security domain
in question.  The petitioner can be either a human agent or an automated
agent.  In general both human and automated agents make bad judgments about
who can be trusted, thus having methods of establishing trust which do not
call for judgments by the Petitioner is desirable.  The petitioner is
designated by the letter P when discussing the model.

Registration Agent - This is the entity that controls access to the security
domain in question.  The registration agent can be either a human agent or
an automated agent.  As the registration agent is considered to be of
reasonable intelligence, it can often make good judgments about trusting
petitioning entities if it has the correct information.  The Registration
agent is designated by the letter R when discussing the model.

Introducer - This is the entity that has the responsibility for correctly
identifying the petitioner and the registration agent to the other.  The
primary role of the introducer is to make one of two statements either "The
entity that gave me this item is ..." or "I will only give this to the
entity ...".  These statements may be modified slightly to say "The entity
at the other end can be trusted to correctly give it's own name".  (This
would be the case if one hooks a dedicated cable between two boxes.)

B is the "normal" communication channel between the Petitioner and the
Registration Agent.  This channel can be considered secure only after a
sufficient amount of information has been passed between P and R in a
reliable manner.

A is the "out-of-band" communication channel between the Petitioner and the
Introduction Agent.  This channel can be considered security as there is a
prior relationship of some type between P and I.

B is the "out-of-band" communication channel between the Registration and
Introduction Agents.  This channel can be considered secure as there is a
prior relationship between R and I.


7.  I have produced an updated data flow section.  In part it represents the
ways that my thought process have changed at the need to really formalize
what I was taking about at the last meeting.  Thus it does not directly
correspond to what I said there.  I hope that it is still clear.


4.0   Data Flow 

During the process of Introduction, information is exchanged between the TTI
entities.  The order of passing data and the set of entities involved allows
us to classify the introduction processes into various types.  This section
describes the different data flow types and discusses the security aspects
involved with each data flow.

Unless otherwise noted in the discussion for the data flow below, the order
of data being passed is not considered to be relevant tot he security
implications.  (Thus in a bi-directional channel the order and interweaving
of the data is normally not relevant to the security properties.)

The data flow diagrams described here deal only with the process of setting
up the data for an initial secure channel between P and R.  The process of
setting up the secure channel between P and I or R and I is ignored.  The
data flow diagrams also only deal with the process of transmitting the
introduction data, once this is done setting up and using the subsequent
secure connections and it's properties is out of scope to this document.

The amount and type of information exchanged or transferred during the
introduction process is heavily dependent on the enrollment dialog to follow
the introduction.  This is considered to be out of scope to this document as
is the process of identify the correct enrollment protocol to be used.

4.1. No Introducer (Imprint)

The imprint data flow in the model occurs without the use of the Introducer.
This is one of the most common methods of introduction both in the real
world and in the security world today.  It has very poor security properties
in terms of getting a true introduction of two parties, but is an acceptable
method under some circumstances.
In this real world this corresponds to the situation where one is at a party
and somebody walks up and says "Hi, my name is Bob."  (To which you reply
"Hi Bob, my name is Alice").  At this point you don't really know if Bob has
lied to you about his name or not, however you can now recognize this as
being Bob in the future.  (Assuming of course that you have a memory for
names and faces.)

Put a pretty picture at this point    I  P<--->R
                                           (1)

Under most circumstances the communication (1) has a bi-directional flow of
data, however this is not necessary. The flow of data could be
unidirectional, i.e. carrying a token used to established a shared key
during enrollment.

Security Analysis:  When looking at this model, one cannot assume any
pre-existing knowledge between any of the participants.  Nor, since there is
no prior relationship can one assume any security level on the communication
channel between the parties.  Although a very common method of introduction
in the real world, it is not used in those situations where a level of
security can be considered to be important.  As stated above however, this
method can be used when the only thing that is desired is to be able to
recognize somebody the second time that that appear.

4.2  Common Introducer

The data flows in this section of the document are all based on a single
common introducer being used by both P and R.

4.2.1  Unidirectional End-to-End Information Flow (Courier)

In the courier data flow model, an intermediary is used to transfer the data
between the two parties in some type of secure manner.  The level of
security is dependent on the type of courier that is being used.  This data
flow is used in many cases in the real world.  The simplest example would be
you manager handing you a sealed envelope containing your identity and
password for your computer account when you start a new job.

Put pretty pictures at this point      P--->I--->R
                                        (1)  (2)
   or                                 P<---I<---R


The data flow is unidirectional, but the data can flow either from R to P or
from P to R.  The security properties are the same.  There is no requirement
that both channels (1) and (2) need to exist at the same time.  (There could
be a unidirectional store and forward model working here.)

Security Analysis:  In looking that this model there are three points of
failure that need to be examined.  The entity I and the two channels (1) and
(2).  The two data channels have the same issues and will be treated
together.

The assumptions one makes for the Entity I are follows:  1) The packets will
be relayed between the two data channels without alteration or prying.  2)
The two data channels will be created with the correctly identified
entities.  

Entity I can 1) snoop, 2) alter contents (man in the middle attack), 3) lie
about identities.  This are issues with all versions of the model
For insecure data channels, they can be snooped, altered.
For secure data channels, with integrity checking nothing can be done.

4.2.2 Unidirectional Middle-to-End Information Flow 

In the central authority data flow model, the Introducer generates the
identification material and hands it to the entities P and R.

Put a pretty picture at this point    P<----I---->R
                                        (1)   (2)

The data flows (1) and (2) are unidirectional with all data flowing from the
Introducer to the other parties.  A data channel between P and R would then
be created at enrollment time.

Security Analysis:

The Entity is expected to 1) Create the data used by P and R to mutual
authenticate each other, 2) transmit the data to the correct entities.
Channels (1) and (2) could either be secure or insecure and have appropriate
security problems.


4.2.3 Bidirectional Information Flow (Mediated)

In the mediated data flow model, the introducer acts as a bidirectional
channel to send information through.  The level of security is dependent on
the type of mediator that is being used.  One example of this type of data
flow would be hooking a cable directly between two devices.  The fact that
the cable exists means that the can securely talk to each other.  

Put a pretty picture here

                        P<->I<->R

Security Analysis:

4.2.4  Round the horn information flow

In this data flow model, the introducer supplies information to one party,
and later verifies that it is the correct information for the second party
at a later time.

Pretty Pictures (and mirror image)

                        I--->P
                        ^    |
                        |    v
                        |--->R

Example:  Data is provided by I to P, P uses this data to talk to R and R
verifies the data with I.  

Messy but possible.  I cannot think of a good real world scenario that
really matches this, but I am sure one exists.

Note: this could be a bi-directional flow as well with both entities
mirroring the other.


4.3  Disjoint Introducers

In this section we will look at the cases where the introducers are
effectively different entities for P and R.  

4.3.1   End-to-End Unidirectional w/ authority

In this data model, information flows from one P to R (or visa versa) and R
then validates the information received with an authority figure.  This is a
common model used for financial transactions.  A customer gives a VISA card
to a vender (data from P to R), the vender then runs the data passed the
vender bank which approves or denies the transaction.  (R validates the
information with I(R)).  Is would also be the case of a signed packet coming
across which then goes to an OCSP server to validate.

Pretty pictioner
                        I(r)<-->R<---P   or

                        I(p)<-->P<---R

This model can be made bi-directional by running both at the same time.

Security Analysis: ...



Jim