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

[Jim Schaad]

Max,

Comments preceed by JLS 

-----Original Message-----
From: ietf-enroll-bounces at mit.edu [mailto:ietf-enroll-bounces at mit.edu] On
Behalf Of Max Pritikin
Sent: Wednesday, May 05, 2004 10:07 AM
To: jimsch at exmsft.com
Cc: ietf-enroll at mit.edu
Subject: RE: [ietf-enroll] Some thoughts on ENROLL's direction

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.

[JLS] Actually there is a negotiation at this point, it is negotiation by
fiat.  I have the choice of accepting their protocol or not, but it is a
negotiaion.  In many circumstances this is actually negoiated by outside
bodies - generally standards bodies that say "You MUST do blah at this
point."  This does not make it any less a part of the model because some
times it is done by fiat and sometimes it actually needs to be done in the
process. (I.e. which of CMS, CMP or the other certificate enrollment
protocols are you using.)

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

[JLS] This is definitely up for negotiation.  Think of the situation where
you are trying to create an account with your ISP.  You say, "Is the
following name in use?" if it is then as the enrollee you need to think of a
new one, if it is not then it is suffiently unique.  Serial numbers (or
SSNs) are often suffiently unique, but again this is a negotiation by fiat
as they are laid down by an external body as the method of one gets
suffiently unique.

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

[JLS] Actually I think that this section is not needed for any part of the
model.  This is strictly limited to what happens inside of the service
provider and  is therefor not of interest to the actual enrollment process.

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

[JLS] Yes that is possible, one could pass the public key and a name in as
part of the OOB process.  This however is very difficult to do in any sort
of secure manner without having something like a hand carried USB token.
This is not really possible for traffic over the LAN as there is no private
secure physical hookup.

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

[JLS] What cryptographic data.  Cryptographic data is of the same value as
personal information.  The only potential advantage to it, is that for some
cryptographic algorithms I can compute proofs without giving up a core
secret.  There is absolutely no more concept of proof of identity here than
in saying "this is my personal secret that probably nobody else has
created".

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

[JLS]  Yes this could potentially be a nonce, but does not need to be unque
to this specific enrollment process.  SSN's are used in the credit card
scenario.

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

[JLS] Actually the trust you put in the "well known brand names" is exactly
what I was talking about for a leap of faith.  You get a credit card
application that claims to be for Bank One and an envolope addressed to Bank
One.  Why do you think it is really Bank One at the other end and not a
scammer looking for your data?  You have absolute no valid reason to make
any such assumption.

Information about thinks like credit histories are "not in scope" because
they are generally internal to the provider and not part of the customer.
If a denial of enrollment comes out then the customer has the ability to try
and change the general background of the enrollment process, but this is not
part of the enrollment process itself.

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

[JLS] This goes back to the e-mail message at the start of the thread.

	- Max


[JLS}  Max, I cannot allow for any framework to force the use of public keys
as the end result of enrollment (individual protocols of course are free to
do so).  There are too many situations where shared secrets are needed
instead because humans can't remember enough data to make public keys
usable.

Jim