On Thu, Mar 23, 2006 at 02:36:32PM -0800, Joe Touch wrote: > Maybe it'd be useful to pose the questions separately, i.e., what should > each of the following steps be called> > > 1. accepting the first unauthenticated certificate (U-C) > > 2. deciding to cache accepted U-Cs for future use > > 3. referring to the blind acceptance of cached U-Cs when matching > > Where's the leap? Is it in: > - accepting the first UC > - assuming that matching UCs mean matching endpoints > - somewhere else? The better question is: where is the leap taken? If it's taken by the app, then we avoid the problems we discussed at Vancouver, whereas if it's taken in the KE (by creating LoF PAD entries binding the peer address and public key) then we run into those problems. Also, looking at the SSH example, LoF is usefully done on a client, not a server -- the server doesn't care about the client's public key since the client will be authenticating at the app layer and connection latching and channel bindings will protect against MITMs, but the client cares because once it knows a server's public key it might be willing to send passwords/session ID cookies (for "fast re-authentication") and what not over the latched connection. Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.