[ietf-enroll] Charter / mutual enrollment?

[Max Pritikin]

Of course in SSH the user is expected to check this initial key using
'out-of-band' mechanisms. This of course never happens, and the result
is, as you say, an imprint mechanism.

I'll bet a significant portion of the ssh users out there are so
accustomed to accepting these intial keys that when the attacker
eventually steps in and presents their own keys they would just accept
the new keys. (sure, sure, ssh provides some warning text. big deal.
most users don't know what that means anyway).

This sort of imprinting is of course fully acceptable to the model I
propose. But also as trust relatinships are evolved we can hopefully
move away from it for good.

	- max

On Thu, 2003-05-08 at 12:58, Russ Housley wrote:
> Max:
> 
> I understand your points, and it may not be possible to separate these 
> completely.  One also needs to consider the SSH model, where the public key 
> is provided on the first transaction.  Once you have the public key, you 
> know that you are talking to the same party, even if it is not the right 
> party.  This forces the attacker to be involved from the very beginning or 
> be locked out forever.
> 
> Russ
> 
> At 08:48 AM 5/7/2003 -0700, Max Pritikin wrote:
> 
> >Getting 'trust points' configured into clients is covered in the
> >introduction model (You all feel free to tell me when you give in
> ><grin>) and is why I started with discussions of bidirectional
> >introduction.
> >
> >Take the sequence of events between software A, device B, and
> >certificate authority, C:
> >
> >1) administrator uses software A to configure B to start an enrollment
> >with B.
> >
> >2) first step of enrollment is to get C's public key (the 'trust point'
> >in this context) onto B. The key can be pulled directly from C but then
> >the admin must use A to tell B it is the right key. Alternatively user
> >on A can push the entire key from A to B.
> >
> >This is an example of leveraging the trust relationship between A and B
> >to introduce C to B.
> >
> >(The other half of the exchange is where the administrator uses A to
> >introduce B to C. In today's world the administrator might use a
> >different A (e.g. A1), but in either case they use a tool for this. In
> >my original email on the thread I argue that A and A1 are all tools of
> >the admin and can be concidered one system for the model. Implementation
> >is free to design as complex a tool as needed.)
> >
> >         - max
> >
> >
> >On Tue, 2003-05-06 at 23:14, Russ Housley wrote:
> > > Bill:
> > >
> > > I am quite aware of this issue.  And, in fact I am doing some work in this
> > > area for a customer.
> > >
> > > I feel that enrollment is a much larger problem that is keeping people 
> > from
> > > using the security protocols that already exist.  Thus, solving the
> > > enrollment problem is of paramount importance.  I would really like to get
> > > this work going with the more limited scope.  If we find that the two are
> > > more intertwined than expected, then it is not too difficult to extend the
> > > charter.
> > >
> > > No one has requested a BOF slot for the meeting in Vienna yet ....
> > >
> > > Russ
> > >
> > > At 08:33 PM 5/6/2003 -0400, Bill Sommerfeld wrote:
> > > >So, one missing link somewhere (perhaps here, perhaps not) is the other
> > > >direction -- how to get 'trust points' configured into clients
> > > >with minimal fuss and muss...
> > > >
> > > >We all know that compiling them into apps has Issues..
> > > >
> > > >seems like it would be best to handle both directions in the same
> > > >place.
> > > >
> > > >                                                 - Bill
> > >
> > > _______________________________________________
> > > ietf-enroll mailing list
> > > ietf-enroll at mit.edu
> > > https://mailman.mit.edu/mailman/listinfo/ietf-enroll