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

[Jim Schaad]

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.

 
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.  
 
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).
 
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.
 
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.
 
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.
 
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.
 
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.
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/ietf-enroll/attachments/20040505/e4ba39bc/attachment.htm