<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV dir=ltr align=left><SPAN class=999122421-04052004><FONT face=Arial
color=#0000ff size=2>Jesse,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004><FONT face=Arial
color=#0000ff size=2><STRONG>One-time, One-way OOB
transfer:</STRONG></FONT></SPAN></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004> 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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004>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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004>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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004>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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004> 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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004> 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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004> 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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004>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></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN
class=999122421-04052004><STRONG>Storyboards:</STRONG></SPAN></FONT></FONT></FONT></DIV><FONT
face=Arial><FONT size=2><FONT color=#0000ff>
<DIV dir=ltr align=left><SPAN class=999122421-04052004></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004>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></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004>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></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004>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></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004> The
name of the domain may be NULL as may the name of the customer.</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004> The
keys may be identical as this may be using a symetric rather than asymetric
key.</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004>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></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004><STRONG>Architectual
Implications:</STRONG></SPAN></DIV>
<DIV dir=ltr align=left><SPAN
class=999122421-04052004><STRONG></STRONG></SPAN> </DIV></FONT></FONT></FONT><FONT
face=Arial><FONT size=2><FONT color=#0000ff>
<DIV dir=ltr align=left><SPAN class=999122421-04052004>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.</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=999122421-04052004></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN
class=999122421-04052004></SPAN> </DIV></BODY></HTML></FONT></FONT></FONT>