<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered)">
<style>
<!--
/* 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;}
@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><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>While on vacation last week I had time to think about
ENROLL. Here is a possible model for ENROLL operation. This discussion is
trying to tease out some requirements for this function. The first part of the
discussion gives a storyboard for what I think we want to happen. The next part
attempts understand the implications of the storyboards. It finally closes with
a suggested functional decomposition and discussion of WG scope.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>1. Storyboards</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Storyboard from the enrollee's perspective. The user decides
to configure his device to operate in a new domain. He uses an Out-Of-Band
(OOB) channel to move some data between his device and one of the devices in
the new domain. A USB token or cross-over cable is an example OOB channel
common among computing devices, and IR is a common channel for consumer
electronics devices. The user would want the OOB transfer to be as easy as
possible, while implementers would like it to work with arbitrary OOB channels,
and together these preferences dictate that the OOB transfer is not a two-way
exchange, as doing so would require the user to move information back and forth
between devices, perhaps multiple times, on many OOB channels. The user should
be able to perform the OOB transfer in either direction, as a procedure that
requires the information be always transferred, e.g., from the enrollee device
to the enroller, is unlikely to be simple enough for arbitrary users to use.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>The transfer of the OOB information somehow triggers the
enrollment process. The enrollment process occurs over the normal in-band
channel, e.g., 802.11. It may be necessary in some cases for the user to
designate which is the enrollee device, but no other user intervention should
be required in the normal case. Examples where this extra step may be required
are enrollment of personal devices into personal networks, where both devices
might play either role of enrollee or enroller, or the initial configuration of
a new network at home, etc.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>When the enrollment process completes, the enrolling device
is configured with</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>a. an authentication algorithm to use with this domain</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>b. an identity for the new domain</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>c. a key that will subsequently authenticate the domain to
the device</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>d. an identity the enrollee will subsequently use to
identify itself to the</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> domain</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>e. a key that will subsequently authenticate the device to
the domain</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>f. a set of permissions for its operation in the domain,
which always includes</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> at least basic network access to the domain</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Storyboard from the enroller perspective. The operator
designates an enroller device. It plays roughly the role of a PKIX RA. When the
OOB exchange completes, the enroller device executes the in-band protocol to
verify that it is indeed communicating with the enrollee designated by the OOB
transfer. Once this is accomplished, the enroller device and the enrollee agree
on</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>g. the authentication method the domain and the enrolle will
use to authenticate</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> one another</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>h. a name for the domain</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>i. a key that will authenticate the domain to the enrollee</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>j. a name for the enrollee</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>k. a key that will authenticate the enrollee to the domain</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>l. a set of permissions for the enrollee, which includes at
least access to the</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> domain's network.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>The process may require the operator of the enroller device to
approve the enrollment prior to its completion, or approval may be automatic,
e.g., if the enrollee device presents a valid credit card number. Other
operator intervention should not be required.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2. Architectural implications</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>If these storyboards are correct, they have several
implications:</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2.1. First, enrollment requires two channels, an OOB channel
and an in-band channel. The goal of this separation is to establish basis for
believing each of the devices is communicating with intended peer. The model we
are using is the in-band channel gets bound to information transferred over the
OOB channel, to serve as the basis for this belief. This is different from the
e-commerce model, which posits that anyone with a certified name is the
intended peer. When a radio channel is used as the in-band channel, we need
some reason to believe the device in my hand is communicating with the device
in yours, and not with one controlled by someone else that just happens to have
a certified name.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2.2. Second, ease of use requires that the OOB channel is
one-way. This is because with a USB token or IR channel used for the OOB
transfer, the user cannot be expected to run back and forth between devices, at
least not if we expect real users to perform the operation themselves. This
implies that the initiator of the in-band protocol might be the enrollee in
some cases and the enroller in others, because it is equally unlikely that the
process will be successful if the user has to perform the OOB transfer in one
direction. This means that there will have to be a designation step at some
point, where the devices agree on roles for each.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2.3. There must have some way for enroller to advertise
authentication mechanism(s) used in the domain and for the enrollee to select
which among these it will use. This is a policy negotiation step.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2.4. Finally there is the enrollment step itself -- the
process whereby (a) the enrollee and enroller agree on identities for one
another (b) and bind keys to these identities.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2.5. We want the process initiated by the user, not happen
automatically. This is because the user provides the ultimate access control for
his own device, and will not take kindly to external “services”
unknowingly inviting themselves in without his permission.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2.6. Since we want the in-band protocol to work with
802.11i, it must present itself as an EAP authentication method. This is
because an 802.11i access point expects mobile stations to use an EAP method to
authenticate themselves prior to offering any further service.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>3. Discussion</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>From this description, there are a number of separate
components: two different devices operating in enrollee and enroller roles, and
a suite of five logical protocols that work together to effect enrollment. More
explicitly,</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>a. There is, of course, the enrolling device, as well as</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>b. what we will call the enroller device. A enroller device
is a special purpose server whose sole function within the architecture is to
coordinate enrollment. Obviously, the identification protocol runs between the
registration server and the enrolling device. Also the user moves the
out-of-band information between the enrolling device and the registration
server.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>c. The first protocol operates over a one-way, out-of-band
channel, used to exchange information between devices. This information is used
to provide a root of trust in the subsequent steps of the enrollment process.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>d. The second protocol is an “identification protocol,”
consuming the out-of-band, which is used to establish a secure channel between
the enrolling device and the domain's enroller. This protocol will demonstrate
that the domain is talking with the intended enrolling device, and that the
enrolling device is talking with the intended enroller. The second point of
this the identification protocol is to establish a security association which
is used to protect the remainder of the enrollment process. The second point is
to bind proof of possession of enroller’s and enrollee’s keys to
the OOB information, so that everyone knows they are communicating with the
intended peer.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>e. The third logical protocol is a designation protocol, to
indicate which device plays the role of enrolling device and which enroller.
Since we have specified that the out-of-band information is one-way, and that
the user can move the out-of-band information from either to the other, the
identification protocol is logically distinct from the designation protocol.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>f. Once the role of enrollee and enroller is established,
the parties must negotiate the capabilities of the enrollee against the
policies of the domain. Not all devices will be capable of using every
authentication technique, so there will have to be a question and answer
session to establish whether the two can indeed communicate. We will call this
the negotiation protocol.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>g. Once a security association is in place, roles have been
established, and capabilities have been agreed upon, the device can finally
enroll. The enrollment protocol establishes the identities, credentials, and
access rights that will be used subsequently. Example identities include device
names for use within the context of this domain and key fingerprints. Example
credentials could include device names bound to a randomly generated symmetric
key, or a certificate issued by the domain binding a domain assigned identity
to the device's public private key pair. Examples of permissions include the
right to access the network, the right to perform mesh routing, or the right to
admit new devices to the domain. Each application of the architecture will have
to enumerate the set of permissions afforded by that application.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>I think the purpose of the ENROLL WG is to establish an
architecture that is along these lines, define standardized pieces such as
these, and to define how the pieces work together to accomplish the entire
enrollment process.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Does this seem right? If not what is wrong and what is
missing? Or if this seems ok, what are our next steps to making this happen?</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>-- Jesse</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
</div>
</body>
</html>