[ietf-enroll]

[Jim Schaad]

Max,

One of the things you are going to find happening that you need to look out
for is that I will start you down what appears to be a simple path and then
start to hit you with all sorts of complications that you never imagined
were coming.  It has to do with how my mind works, it's very reactive rather
than proactive.

Also I am going to find out if the fact that I have not gotten the last two
messages has to do with my mail system having be in a weird state or having
gotten removed from the mailing list due to the fact that my mail system was
in a weird state.



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

[JLS] See long answer below


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

[JLS] yes - but so what.  With out an assocation between I & P you have not
gained any trust over I not existing.

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

[JLS] - The reason that I don't include I in this picture is based on the
entity discussion of what I is going to do.  I makes some statements about
identities my description of what it does.  The fact that the I-P (or I-R)
interface is unauthenticated means that I cannot infact make the statements
it is suppose to do.  Additionally, I believe that in the imprint case uses
the "normal" rather than "out-of-band" communication channel in the overall
picture.  (That is it uses the B rather than A and C data channels.)  This
means that I never gets talked to by P.  Finally I disagree that you can do
anything in the model about "making things closer".  Does this means that if
one meets somebody at a party and they introduce themselves to you that you
have a greater degree of confidence in what they are saying just be cause
you shake hands (actual physical contact) rather than just nodding.  (Does
the fact that one of you is wearing gloves make a difference in the security
level?)  I consider the case that an introduce get's two devices close to
each other to be covered in section 4.2.

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

[JLS] I quite agree.  These issues needs to be discussed in a global
security implications section with some guidance on how to identify the
problems and potentially a couple of different types of solutions.

> 4.2.2 Unidirectional Middle-to-End Information Flow 

>From a model perspective does this case add anything? How is it
materially different than (your) 4.2.1?

[JLS] Yes it does have some very different characteristics that need to be
looked at.  The major difference is that in section 4.2.1 the data is being
generated by one of the end entities while in 4.2.2 it is being generated by
the introducer.  One why to look at how it is different is to consider the
following.  Suppose R generates and decompeses the data for P into 10
different messages such that 7 are needed to re-create the original data.  R
now uses 10 different moderately reliable introducers to send the data to P.
We now have solved some of the problems  with both the relability and
nosiness of I.  Unless multiple of the I entities collaberate they cannot
pretent to be P.  Additionally R has an increased confidence that P is
really P since multiple introduction agents were involved in the data
transfer, thus meaning that more that one person things this is really P.

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

[JLS] No there may be more than one message (see above), just that all data
flow travels in one direction.  Consider the case of your VISA debit card.
There is one directional flow for the card and the password, but two
messages travel (ignoring for now the fact that you need to dial up and
activate the card as well).

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

[JLS] Yes and no.  The difference is that P and R now have different I
entities they are talking to.  The I entities may or may not talk to each
other as well.

The problem with the way you are looking at the entities is that it does not
match the real world use of credit cards.  In the world of credit cards
there is what is called the 4 corner model.  It looks like this:

     Ir <---> Ip
      ^       ^
      |       |
      v       v
      R <---> P

Where R is the vender, P the customer, Ir the vendor's bank and Ip the
customer's bank.  P gives a credit card to R (and identity credential), R
then ask Ir (it's bank) if it will allow a charge of X dollars on the card.
This may or may not be approved with or without talking to Ip.  Ir will then
later get the money from Ip well after the transaction has actually been
approved.  (This is where things get real fun because P can then contest the
transaction causing Ip not to send the money to Ir and as they say, "Money
makes the world go round.")

Now a days this is an over simplified description of what happens.  Ir and
Ip can communicate almost instantanously, R may require P to show a photo id
(i.e. driver's license) in order to accept the card to begin with (or
afterwards). So it does not match the clean model quite as easily.