[ietf-enroll] next steps for enroll

[Tschofenig Hannes]

hi jim,

thanks for your response. 
sorry for the late reply. please find some comments inline: 

> -----Original Message-----
> From: Jim Schaad [mailto:jimsch at nwlink.com] 
> Sent: Montag, 08. November 2004 16:25
> To: Tschofenig Hannes; ietf-enroll at mit.edu
> Subject: RE: [ietf-enroll] next steps for enroll
> 
> Gentlemen,
> 
> I read this document, abet slowly trying to work around other 
> commitments, and I feel that this document or one or two 
> similar documents need to be adopted by the group in order to 
> give good guidence on how the models should be viewed and used.
> 
> Lets start with a discussion of section 3.1, a supposedly 
> simple case and see what happens.
> 
> This skips over many of the details that we need to look at 
> in order for a complete analysis to be done.  First there are 
> three different data flow models that can be considered to 
> have occurred depending on how one squints at what is happening.
> 
> 1.  There is an imprint data flow operation occuring.  This 
> is between the manufacturer and the device being 
> manufactured.  Here I am mapping the manufacturer to R and 
> the device to P.  This comes up with some questions that need 
> to be looked at (and thus should be in the model document?).
> 
>   A) Is the secret material being generated on P or R.  
> Depending on the type of material being generated this means 
> there must be statements about how R keeps and maintains the 
> secret.  Also there needs to be some statements about how R 
> makes sure that the same info is not placed on two devices.  
> (Conversely there is an issue of timeliness and randomization 
> if the device generates the secret.)
> 
>   B) Can P be imprinted more than one time, by more than one R?
> 

let me call this case the two party case. a two party protocol is, i think,
in many ways simpler than a three party protocol. it is true that there
still some issues that need to be described (which are not in the document
right now). however, i have the impression that we can address many of the
protocol features by means of state establishment.

hence, we certainly have to address typical properties such as
- when is state created
- who creates the state (party p, r or even both parties)
- how long is the state valid
- how do you name the state
- are you allowed to have multiple state entries between two nodes
- which one do you use if there are multiple state entries available
- how do you delete state
- who is allowed to modify state


> 
> 2.  There is a courier data flow operation occuring.  This is 
> between the manufacturer and the end registration agent.  
> This may actually be a series of courier agents rather than a 
> single agent.  Now you can look at the implications of being 
> in a courier data flow.
> 
> 3.  One could map the data flow as central authority (one 
> directional flow
> outwards) if one assumes that the introducer is the 
> manufacturer.  If one looks at  using this as the overview of 
> the data flow, then one needs to talk about how one needs to 
> look at combining the data flow models.  There really is are 
> multiple couriers between the manufacturer and the 
> registration agent and this needs to be discussed even if one 
> uses this data model.
> 

i am not sure whether i complete understood these two paragraphs. if i say
that they are outside the scope of the enroll (and even the ietf) then i
might be wrong.

there are certainly many ways (and many parties involved) in the process of
imprinting if you consider entities like couriers. however, i think that we
then move into a domain where we (at the ietf) might not have the proper
experience. 

(am i on the wrong track?)

> Finally there needs to be discussion on 1) type of 
> information being used,
> 2) how discovery of R is done by P.
> 
> 
> Next section 3.2 - This maps to either the courier or 
> mediated data flow depending on wheither you are looking a 
> unidirectional or bi-directional data flow.  The issues that 
> you have brought up need to be covered as issues in the 
> enroll document wrt the courier model.  Basically there needs 
> to be good restrictions on the data that flows in order to 
> make the system work.
> 
> Next section 3.3 - This is not establishing a secret over an 
> insecure network.  This is exactly the same as the section 
> 3.2 data flow.  I.e. you are either doing mediated or courier 
> data flow with the fingerprint being the data that is being 
> transported OOB.

i agree that the separation between 3.1 and 3.2 is weak. however, there are
real-world examples that belong to category 3.1 and others that belong to
3.2. section 3.3. certainly establishes a secret over an insecure network
either using the mechanisms depicted in figure 3 or in figure 4. from a
protocol point of view there is a big difference between the message flow
shown in figure 3 and 4 (not talking about the difference between section
3.2 and section 3.3). 

i personally do not quite understand what we try to accomplish. do we want
to describe what issues need to be considered to accomplish 3.2? should we
focus on specific applications (e.g, imprinting end hosts and wlan access
points)? 

should we focus more on 3.3? 

we can find examples in all these categories today. narrowing the focus can
be quite useful in order to make some progress. 

ciao
hannes

> 
> 
> Jim
> 
>