<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (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;}
span.EmailStyle20
{font-family:Arial;
color:navy;}
@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 style='margin-left:.5in'><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'>[</span></font></i></b><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</span></font></i></b><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'>] 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=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>[Vic Lortz] Interestingly enough, Microsoft
just this week announced a new technology for securely configuring WLAN networks
using USB tokens. They call it “Windows Smart Network Key”,
and it will be included in Windows XP SP2. Their initial version of this
technology does not include an in-band exchange, but it does include returning
the USB token back to the starting machine. I’m not saying we
should necessarily follow that example, but it is one real-world data point to consider.
I think the current reason for returning the token to the originator has mostly
to do with updating a user interface on that machine with information about the
devices that were enrolled. Once the SSID and WEP keys (or WPA-PSK keys)
have been delivered to the other devices using the USB token, the enrollment
operation is effectively complete. </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I think a “mental USB token”
is useful, because many potential OOB channels correspond to this model.
We don’t have to enumerate solutions for all of them, but we need to make
sure the framework we create can be readily mapped onto them.</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> ietf-enroll-bounces@mit.edu
[mailto:ietf-enroll-bounces@mit.edu] <b><span style='font-weight:bold'>On
Behalf Of </span></b></span></font><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>Walker, Jesse</span></font><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Sent:</span></b> </span></font><font size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>Wednesday, May
05, 2004</span></font><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>3:12 PM</span></font><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> jimsch@exmsft.com;
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>
<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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='margin-left:.5in;text-align:center'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center>
</span></font></div>
<p class=MsoNormal style='margin-left:.5in'><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> </span></font><font size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>Wednesday, May
05, 2004</span></font><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>8:57 AM</span></font><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 </span></font></i></b><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'>tower</span></font></i></b><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'> of </span></font></i></b><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'>Babel</span></font></i></b><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'>—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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><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 style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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 style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><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>