[ietf-enroll] Some thoughts on ENROLL's direction

Wed May 5 18:39:22 EDT 2004

[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.

[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.  

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.

-----Original Message-----
From: ietf-enroll-bounces at mit.edu [mailto:ietf-enroll-bounces at mit.edu]
On Behalf Of Walker, Jesse
Sent: Wednesday, May 05, 2004 3:12 PM
To: jimsch at exmsft.com; ietf-enroll at mit.edu
Subject: RE: [ietf-enroll] Some thoughts on ENROLL's direction

Jim,

Thank you for your comments, which are excellent, as always.

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.

  _____  

From: Jim Schaad [mailto:jimsch at nwlink.com] 
Sent: Wednesday, May 05, 2004 8:57 AM
To: Walker, Jesse; ietf-enroll at mit.edu
Subject: RE: [ietf-enroll] Some thoughts on ENROLL's direction

Jesse,

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.

One-time, One-way OOB transfer:

 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. 

[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.

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.  

[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.

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).

[Walker, Jesse] This is a good observation. We will incorporate this
into the framework document.

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).  

    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.)

    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.

    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.

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.

[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.

Storyboards:

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.

[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.

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.

[Walker, Jesse]  Right

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:

    The name of the domain may be NULL as may the name of the customer.

    The keys may be identical as this may be using a symetric rather
than asymetric key.

[Walker, Jesse]  Right

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.

Architectual Implications:

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.[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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/ietf-enroll/attachments/20040505/06375fc6/attachment.htm