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

Wed May 5 13:06:57 EDT 2004

Inline,

On Wed, 2004-05-05 at 08:57, Jim Schaad wrote:
> 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

In this scenario there is no negotiation though. The Registrar/credit
card provider mandates a particular mechanism for enrollment and simply
informs the Petitiner/user. It seems at most this is going to be a list
of mechanisms provided by the Registrar rather than a full negotiation.

>  prorvider.  2) A negotiation of what is under stood as suffiently
> unique information to initiate the enrollment process (i.e. a mostly
> unique identifier).

Again I'm not sure this is up for negotiation. The Registrar/credit card
provider mandates something here as well. It is up to the
Petitioner/user to have such an identifier available. Such as a social
security number that can be used to lookup an appropriate credit record.

(Which highlights that this scenario description is incomplete without
including some discussion of credit record verification).

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

Agreed. The list of "here's how to enroll". One could imagine this
including the appropriate cryptographic information necessary to make
sure future communications are really with this credit card provider.

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

Because of course there isn't cryptographic information involved. If
this were computers exchanging information we wouldn't be sending out
"secret"/"personal" data; instead we'd send public data that we could
back up with some sort of cryptographic proof of identity. At any rate
by now we're well into the specific enrollment protocol itself which I
think is verging on out-of-scope.

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

Much like a nonce? 

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

You left out credit records the general 'trust' we put into well known
brand names. I wouldn't accept a credit card from "BigBadWolf Bank and
Trust" unless it was associated with Visa or Mastercard (who I
essentially trust to take BigBadWolf to court in the case of fraud
involving their good name). 

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

Agreed. I'd go further even and consider that humans almost always have
a "device"/"tool" to help them at each stage. Take you credit card
example and you'll see the humans using a telephone system to input
values. Additionally this telephone system is leveraged to help secure
the exchange (credit card provider may check the caller id information,
and the customer may not trust the 800 number on the original form but
may instead look in the phone book...). 

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

Very much agreed. Note though that if public key data is exchanged the
passive attack you outline for blue tooth is avoided (still have to
worry about active attacks though).

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

After enrollment anything goes. I'd like to mandate public keys used
during enrollment because the active vs passive issues touched on above.

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

I'm not sure what you ref here. 

	- Max

>  
> 
> ______________________________________________________________________
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll