[ietf-enroll] Enroll TTI Model document (unofficial-draft)

Wed Oct 29 03:39:31 EST 2003

Max,

I donot mind sending it to the mail-list. So, I just send it now for more discussions.

- Peng

> -----Original Message-----
> From: ext Max Pritikin [mailto:pritikin at cisco.com]
> Sent: 28 October, 2003 09:25
> To: Zhang Peng.P (NES/Helsinki)
> Subject: RE: [ietf-enroll] Enroll TTI Model document 
> (unofficial-draft)
> 
> 
> Peng,
> 
> I've looked for your response on the list and haven't been 
> able to find
> it. I hope this isn't an indication that there are problems 
> on the list.
> I believe the exchange below would be a good thing to send to 
> the list,
> and if you don't mind (let me know) I will forward it.
> 
> Inlines,
> 
> On Tue, 2003-10-21 at 00:48, Peng.P.Zhang at nokia.com wrote:
> > Hi Max,
> > 
> > I followed up some communications in the list and read your draft. I
> > am interested in the work and may involve more as a 
> volunteer later if
> > possible.
> > 
> > I have some general comments/questions about the group and 
> your draft.
> > 1. Can I get more information about the group except emails through
> > the maillist? I think the maillist is a bit quite these days.
> 
> I do not believe there is another resource at this time. 
> 
> > 2. I am a bit confused about the goal of the group. I did see some
> > concrete work like your draft. But are the goals (e.g., call for
> > drafts) still under discussion? I'd like to hear your views on this.
> 
> I've been moving ahead with the TTI work (product etc). There 
> is ongoing
> discussion about the charter and lack of discussion on the list itself
> -- so I agree that there is still discussion that needs to take place.
> 
> > 3. Your description of the problem seems quite understandable to me
> > (if I understand correctly :). So, the problem lies in how to get
> > long-term credentials. Currently, it is solved by 
> out-of-band methods.
> >  One example from my experience is like this: a user's mobile device
> > needs a certificate to access the user's VPN network, in order for
> > that, the user first gets a pair of username/password through
> > out-of-band way, and uses the pair to get a certificate. After this,
> > the user may not use the username/password any more, but 
> only uses the
> > certificate. (However, this solution may have some security problem,
> > e.g., man-in-middle attack)
> 
> If the out of band exchange was of a username/password there is a
> potential man-in-the-middle attack and of a passive attack (see the
> username/password and use them before the correct user gets a chance).
> An exchange of public keys reduces this risk some (makes it harder as
> there are two 'bands' to man-in-the-middle' and removes the passive
> attack).
> 
> > 4. But do we see out-of-band solutions a problem or some other
> > problems? Because on one hand, out-of-band likely works in current
> > world. On the other hand, we may have to rely on some sort of
> > out-of-band solution for this Introduction. Or, can we throw it
> > totally?
> 
> These risks will always be around. We can minimize them by increasing
> the complexity (e.g. keys and key length) and security of the
> information exchanged out-of-band. Take your example above. 
> What if the
> user had an existing certificate and used that? What if they had a
> username/password or smartcard with an existing security 
> infrastructure?
> If they could leverage that existing security then the 
> introduction that
> depends on it would be that much more secure.
> 
> I think that some introductions will always start with a simple
> out-of-band, or even in-band 'imprinting', introduction (like when
> people setup SSH today). The goal of TTI is to clarify this  
> process and
> discuss how to build on it.
> 
> Without TTI we always have to go back to those first 
> principles to build
> up a new security domain. Or we'd have to build the new 
> security domain
> on top of the previous domain (e.g. a subCA, web-of-trust, etc). The
> transitive nature of TTI allows us to leverage an existing security
> domain and then not depend on it again.
> 
> > 5. TTI model seems very interesting. I think it basically depicts
> > involved elements and procedures. But I have some questions,
> > - does the Introducer do similar functions as a Registry Authority
> > (RA) in PKI deployment? Basically, a user first registers in RA by
> > some way, then when a user requests a certificate from a CA, the CA
> > will checks the user through RA in the sense that RA is like an
> > introducer to the user.
> 
> I hesitate to start mapping things onto the x509 PKI directly (it
> doesn't work; these concepts are not covered in PKI except as they
> relate to the 'out-of-band' portions of enrollment, e.g. vaugely). But
> if it helps to understand the model then consider the 
> Registrar as being
> the RA, the Petitioner as being the new device obtaining a certificate
> and the Introducer as being the adminstrator(s) that pass the
> out-of-band public key and configuration material around.
> 
> > - In TTI over http, the Petitioner runs a web server and an 
> introducer
> > runs a web browser. Does this fit to many applications if we think a
> > Petitioner is a user who wants to apply for a certificate, then user
> > (on a PC, or a mobile phone) normally does not have a web server
> > running. 
> 
> A user doesn't ever really apply for a certificate directly. 
> They apply
> for certificates for particular devices (a PC, or mobile phone) that
> they possess.
> 
> The device can of course run a simple web server. It would even be
> perfectly acceptable for the device to also run the web 
> browser that the
> user uses to perform the introduction (if it was a user and not some
> other system doing the introduction)! 
> 
> (Note that one could use TTI in the above scenario to exactly 
> duplicate
> the existing out-of-band enrollment mechanisms of sending the 
> user a one
> time password and having them use it to do the introduction. It could
> look & feel (and have the same security problems) as an existing
> enrollment using a one-time-password. BUT - one could also 
> chooes to use
> a more secure mechanism.   
> 
> > 
> > What do you think the other way that Introducer runs web 
> server and a
> > Petitioner runs a web browser to log into the server and fill the
> > information.
> 
> I have considered many scenarios where the Petitioner initiates an
> introduction by contacting the Introducer and requesting one. Or even
> contacting the Registrar and offering a list of potential Introducers
> (in that context maybe they should be called References?). 
> 
> I cover this a little bit in section 5 of the draft. There was a more
> detailed discussion of it in previous drafts but I felt they 
> caused too
> much confusion. I'd be happy to bring them back; I certainly 
> agree that
> they are interesting scenarios.
> 
> 	- Max
> 
> > Br,
> > Peng
> > 
> > > -----Original Message-----
> > > From: ext Max Pritikin [mailto:pritikin at cisco.com]
> > > Sent: 17 October, 2003 01:29
> > > To: Jim Schaad; jimsch at exmsft.com; ietf-enroll at mit.edu
> > > Subject: [ietf-enroll] Enroll TTI Model document 
> (unofficial-draft)
> > > 
> > > 
> > > Folks,
> > > 
> > > With IETF coming up some discussion on this list is _overdue_. 
> > > 
> > > With that in mind here is a pointer to a document 
> (unofficial-draft)
> > > discussing the Trusted Transitive Introduction Model:
> > > 
> > > http://www.employees.org/~czmax/tti/draft-pritikin-ttimodel-00.txt
> > > 
> > > This is a short document, please take a glance at it. I've removed
> > > specifics of TTI implementation protocol and tried to 
> focus on just
> > > discussing the model.
> > > 
> > > We have implemented a working version of this protocol 
> over HTTP. In
> > > Minneapolis I'd be happy to show a demo of what we've 
> done and talk
> > > about what we've learned in the process. Based on your 
> feedback I'll
> > > either write up what we have currently as another draft (tti 
> > > over http)
> > > or we can work together to produce one that is more generic (my
> > > preference).
> > > 
> > > Questions,
> > > 
> > > 1. Do we have a time we can meet in Minneapolis?
> > > 2. Has anybody been thinking about this problem?
> > > 3. Should this unofficial-draft be sent to the RFC editor? (Cutoff
> > for
> > > submissions is MONDAY).
> > > 4. Should this document be associated with an Enroll (I prefer
> > > 'Introduction' WG, or as a personal document? (Can this be changed
> > > later?)
> > > 
> > > Thanks,
> > > 
> > > 	- Max Pritikin
> > > 
> > > _______________________________________________
> > > ietf-enroll mailing list
> > > ietf-enroll at mit.edu
> > > https://mailman.mit.edu/mailman/listinfo/ietf-enroll
> > > 
> 
> 