[ietf-enroll] re: email + though processes

[max pritikin]

On Thu, 2004-10-14 at 22:17, Jim Schaad wrote:
> 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.

No worries. Part of the point of discussing the model is so we can
explore these simple/complex paths before writing specs, writing code,
releaseing product, etc. Also an advantage of talking early/often is
that as the conversation progresses there is no major disadvantage to
adjusting our perspectives as needed. 

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

Welcome to the club. I was informed that we were bouncing mail recently
and then earlier this week my laptop's mainboard fried. And computers
are supposed to _improve_ productivity!?

	- max

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