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

[max pritikin]

Jim,

Jim,

Thank you for this though provoking exchange. I've been pondering it. I
particularly like the entity descriptions and the suggestion to re-order
some of the dataflow discussions. 

Some additional questions inline,

On Sun, 2004-10-10 at 21:48, Jim Schaad wrote: 
> 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.
I'll re-read with an eye toward consistent use of the term.

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

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

> 5.  Section 2 para 5:  'Trent says "Alice, meet Bob. ..."
Ok. Easy ones out of the way,

> 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)
I think one reason why we differ a bit on the imprint case is that I
draw and consider 'I' to be part of this exchange:
P<--->I--R
In the simple case I--R is a physical (internal to device P, if you
will) connection and I<--->R is un-authenticated. It is still an imprint
if I<-->R is a full secure across box link. The important aspect is that
I<--->P is un-authenticated.

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

But we shouldn't preclude an association between I & R.

>   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.
The way I draw this model we can also make an interesting observation
... the 'closer' we can get I to P physically the more secure the
imprint is. This matches common sense and is a plus for our model. 

> 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

I think I'd state that these are issues with reality. The model just
exposes them. Future protocols based on this model should attempt to
address these issues.

> 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.
>From a model perspective does this case add anything? How is it
materially different than (your) 4.2.1?

> 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:
Ah. I see why you differentiate this from the unidirectional flow. In
this scenario the introduction could have an arbitrary number of
messages (whereas in the unidirectional flow there is, essentially, only
one).

> 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.
I think this is just an interesting transport example but not a distinct
dataflow discussion. 

Because P is not yet introduced it is obviously not trusted by R yet.
Thus R must be able to accept this data from *anybody* (because it can
not yet prove P is who supplied it) and yet use it to determine P at a
future time (enrollment). Since the data can be accepted from anybody P
could be an untrusted transport:

I-(1)->P       R
                        I-(2)--P------>R
       P<-(3)->R

Still pondering this... 
> 4.3  Disjoint Introducers
> 
> In this section we will look at the cases where the introducers are
> effectively different entities for P and R.  

Hmm, an interesting case. Another way of thinking of it is that an
introduction can be 'half complete'; in that at the end of the
introduction only one of R & P can authenticate the other. This is
similiar to, for example, I delivering R's RSA certificate but not
sending any of P's information to 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. 

Isn't this 4.2.4 restated?

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

This is a storyboard, and I touch on this in section 7.5. I clearly
think that the current implementation(s) are broken wrt to this
scenario. I also clearly need to re-write sections of 7.5. Regardless my
approach is to define the entities a bit differently than you do.

P : The vendor
I : The user/laptop/creditcard.
R : The credit card provider/bank. More specifically the customer's
"account" at the institution.

I see this an an example of I introducting P to R. In this storyboard
the introduction should include an authorization for a financial
transaction (details out of scope).

Clearly the vendor will only trust the R to come through with $$ if
there is a pre-existing association of some kind between P & R. At some
point P must have been introduced to the bank as a whole (not the
specific user account). This 'disjoint introducer' concept may certainly
help to clarify this -- but still the vendor is a P and the bank 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.

Isn't this an example of an already established security relationship
between R & P? Not sure. 

Time to end this mail for now,

	- max

> Security Analysis: ...
> 
> 
> 
> Jim
>