<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.emailstyle17
{font-family:Arial;
color:windowtext;}
span.EmailStyle19
{font-family:Arial;
color:blue;
font-weight:bold;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold'>Jim,</span></font></b></p>
<p class=MsoNormal><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold'> </span></font></b></p>
<p class=MsoNormal><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold'>Thank
you for your comments, which are excellent, as always.</span></font></b></p>
<p class=MsoNormal><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold'> </span></font></b></p>
<p class=MsoNormal><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold'>Max Pritikin,
Alper Yegin, and I are preparing a draft framework document that reflects the
model to which your comments refer. We hope to have draft 0 available later
this month. I expect it will be more of a lightning rod than anything else, to
get the group kick-started, and I have no expectation that draft 0 will be the
final version.</span></font></b></p>
<p class=MsoNormal><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold'> </span></font></b></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Jim Schaad
[mailto:jimsch@nwlink.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Wednesday, May 05, 2004 8:57
AM<br>
<b><span style='font-weight:bold'>To:</span></b> Walker, Jesse;
ietf-enroll@mit.edu<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [ietf-enroll] Some
thoughts on ENROLL's direction</span></font></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Jesse,</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>I have finally gotten to the point of
backreading this mailing list after some prodding from various people. I
have a number of comments on this model that I would like to make.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><strong><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>One-time, One-way OOB
transfer:</span></font></b></strong></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> I cannot see how this would ever
actually work in the real world. I think that what you have done is to
elimate a large number of other OOB items from the end user's view, but not
considering them in the model is a poor choice. </span></font></p>
<p class=MsoNormal><b><i><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>[Walker, Jesse] Fair enough, but I had to start somewhere. My
mental model was a USB token as the OOB channel. A user will be willing to
insert it into one machine, remove it, and then insert it into another. She
will not in general be willing to then return it back the starting machine to
form a two-way channel. This sort of model seemed to me to be the minimal OOB
channel that we could assume. A minimalist philosophy may be the wrong assumption,
and my mental USB token may be the wrong medium.</span></font></i></b></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Let's start with the consideration of a
simple enrollment protocol for a human based agent (some machine agents
would have similar problems). As a customer, I create a user name and
password pair to send to a provider. I have just made assumption #1 --
The provider wants a user name and password pair. I have just made
assumption #2 -- The user name that I created as an customer is going to be
suffiently unique in the provider's name space for me to progress with the
enrollment process. </span></font></p>
<p class=MsoNormal><b><i><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>[Walker, Jesse] I believe that we don’t want to “standardize”
every possible OOB channel and every possible enrollment model. If we do that,
the situation will have progressed not a whit beyond where it is today—the
tower of Babel—and users will still refuse to enable security, because
they must learn too much. It seems like the right goal is for some small set of
models that allow for sufficient implementation and cost flexibility but do not
require the user to possess a large set of mental models to be able to employ
the techniques.</span></font></i></b></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>At a minimum what your OOB negotiation
needs to include is: 1) What enrollment protocol(s) are understood
by both the customer and the prorvider. 2) A negotiation of what is under
stood as suffiently unique information to initiate the enrollment process (i.e.
a mostly unique identifier).</span></font></p>
<p class=MsoNormal><b><i><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>[Walker, Jesse] This is a good observation. We will
incorporate this into the framework document.</span></font></i></b></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Consider the case of applying for a credit
card. There are three different OOB transfers that occur (assuming that
an in band transfer is the acutal use of a credit card). </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> 1. A credit card
application is provided to me by some means. Either mail, on-line or
directly handed to me. (This is the enrollment protocol publication
step.)</span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> 2. I fill out the
data and return it, on-line, by mail or directly. The data enclosed is of
a personal nature, but does not really identify me as credit card fraud via
identity theft proves.</span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> 3. After a piece
of plastic is received by me (usually by mail) I make a telephone call and
prove that I know the same data as was provided in step #2.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>There are several leap of faith steps
involved in this enrollment protocol, and yet this is of a suffiently
acceptable level of security that banks and individuals use this protocol
constantly. It is not "cryptographically" secure in any way
shape of form, but it is of sufficent level of security that both sides treat
it as acceptable risk.</span></font></p>
<p class=MsoNormal><b><i><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>[Walker, Jesse] To me it seems this example is misleading. Perhaps
we need to call in the anthropologists, but it seems like people have different
incentives to accept and then activate a credit care than those for enabling a
Wi-Fi hot spot account. This difference in incentives will set limits on what
is an acceptable OOB protocol in the different cases.</span></font></i></b></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><strong><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>Storyboards:</span></font></b></strong></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>1. I think that we need to say that
the decision to configure a device can be implicit in simply turning it
on. Consider the case of a cable modem -- I just plug it into the
network, turn it on and it gets "enrolled". Language should not
be written solely in terms of human agents.</span></font></p>
<p class=MsoNormal><b><i><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>[Walker, Jesse] Ok. There is a point to the human agent
language, however. The point is that a human being has to make a decision. This
is not the case in a closed system like a cordless phone, where all of the
choices can be made at the factory. In an open system, the manufacturer cannot
know whom you are or are not willing to trust, nor will the category that any
particular party inhabits be constant over time, so the introduction has to be
tied somehow to human choice.</span></font></i></b></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>2. The model needs to make some
interesting comments about the security of the OOB chanel. If you are
looking at IR channels to move both the data and the OOB data, then you have
moved into the problem of using the main data channel for both information and
the OOB data. This is what I would expect for consumer electronics, but
is a potential problem for Blue Tooth devices. If you are around at the
enrollment period, then you can eavesdrop to your hearts content.</span></font></p>
<p class=MsoNormal><b><i><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>[Walker, Jesse] Right</span></font></i></b></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>3. When dealing with the data that
is configured into the customer and the provider at the end of the enrollment
process, there is a great deal that needs to be made explicit. Examples
of this are:</span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> The name of the domain
may be NULL as may the name of the customer.</span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> The keys may be
identical as this may be using a symetric rather than asymetric key.</span></font></p>
<p class=MsoNormal><b><i><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>[Walker, Jesse] Right</span></font></i></b></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>4. It is not clear to me what is
meant by the authentication method used for authentication. By this do
you mean an authication algorithm such as EAP? or do you mean how to use the
provide keying information (i.e. RSA w/SHA1)? In any event this also
could be a NULL field at the end of authentication since this may be a one time
enrollment event and no long term information is stored, thus the enrollment
event is the autentication.</span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal><strong><b><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>Architectual
Implications:</span></font></b></strong></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Item 2.6 is a bogus item. We are
talking about a model here. EAP is one of the many different
autenticiation methods that are possible.<b><i><span style='font-weight:bold;
font-style:italic'>[Walker, Jesse] Correct. The particular problem I worry
about is 802.11. If you want to enroll in a 802.11 WLAN that uses 802.11i, then
the network will not speak anything but 802.1X and EAP until you have
authenticated to it. The implication is that for this class of networks, if
there is an in-band exchange to effect part of enrollment, then it had better
be expressed as an EAP method. If this was not clear, then hopefully it is now.</span></i></b></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'> </span></font></p>
</div>
</body>
</html>
</FONT></FONT></FONT>