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

[Max Pritikin]

Inlines,

On Thu, 2004-05-06 at 11:40, Jim Schaad wrote:
> Max,
> 
> Comments preceed by JLS 

As a general lament -- why is is format of "proceeded by <token>" being
used more and more frequently? Isn't it completely broken? What is wrong
with the good old ">" symbol?

Regardless this makes it difficult to respond to and follow email
threads and you'll have to forgive me if your comments get lost and/or
ignored when indicated this way.

Inline attempts to respond to them anyway,

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

Ok, I'll buy that these "accept this method or go away" examples are a
negotiation of sorts. What I mean is that 'by fiat' does not involved a
4 way exchange.

I think that the whole discussion of selecting a unique account name is
part of the enrollment process; much like establishing any shared
credential. The particular requirements of a specific enrollment
protocol wrt the resulting locally significant credential (8character
username, must look like an email addr, first name last name, has to
have the letter 'a' as every 5th character, based on a public key,
secret key etc) is independent of the model itself.  

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

This is an important aspect of the model though -- there is almost
always a 3rd party involved in the initial authorizations during
enrollment. The case where a 3rd party is not involved (a pure imprint)
is actually very very small. Imprinting is not the norm. 

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

We can leverage other secure mechanisms than a physical link. Such as an
HTTPS connection to the local browser (possibly extended by a secure
physical link from the browser to whatever is being enrolled). I think
it is important to develop the model such that we can leverage such
existing security infrastructures otherwise we'll *always* be forcing
either a leap-of-faith or fallback to the most basic level of
out-of-band (e.g. physical) key transport. 

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

By ignoring any sense of a 3rd party involved in this exchange you are
correct. I argue that as a model for enrollment we need to accept this
third party's existence even if we don't require it.

The truth is though that these third parties do exist and are leveraged
during existing enrollments. The existing mechanisms doesn't leverage
that enough to provide additional privacy (e.g. you end up passing your
private personal information to the credit card provider) but that
doesn't mean we shouldn't make sure the model supports more. 

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

I'm hearing: "Because it has been done this way in the past we need not
consider a model that supports something better"? Especially in this
extremely sensitive example (my credit history/financial data is
probably some of my most important identity information!) I think we
should be looking forward to an infrastructure that supports more.

Obviously supporting more doesn't mean we can avoid support for the
general existing, less secure, less ideal, case.

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

As indicated above "After enrollment anything goes" I don't give a hoot
what is used as the locally significant credentials. I do feel that
there are security gaps during introduction and enrollment and that
public/private keys protect against passive attacks this early in the
process. 

	- Max

> Jim
> 
> 
>