-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 10:01:44AM -0800, Joe Touch wrote: >> Nicolas Williams wrote: >>> 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? >> By whatever enables BTNS, which would be a user or an app. >> >> [...] >> >> Those PAD entries are instances of a broader "BTNS OK" entry, which >> means the 'leap' has already been taken. > > LoF isn't merely about accepting unauthenticated peers -- in the context > of SSH, for example, it's about interactively asking if a peer's public > key is "valid" and then recording it so that subsequently no such > interaction is necessary. This is the part I don't quite understand. Where's the LOF? - accepting the key now - keeping it for later reuse There's no reason the application can't set "accept unauthenticated peers for the following addresses/protocols/ports", so that the protocol doesn't need to ask the app even for new peers. I.e., the 'leap' seems to be in 'blindly accepting a peer's cert'. That need not wait for an initial exchange, and is often exactly what users end up doing when asked anyway... > Applying the SSH model to BTNS we want: > > - "servers" to accept unauthenticated [BTNS] clients blindly, leaving > it to the application to do any client/user authentication that might > be desired at the application layer, > > - "clients" to require either that servers be authenticated (not BTNS) > or that interaction with a user to accept a server's public key (BTNS > PUBLICKEY ID) and record it somewhere (potentially the PAD could be > used as an ssh_known_hosts type record, though I would not recommend > it, and I would recommend against it on multi-user [time sharing] > systems). The key might be useful to record during the SA (to prevent hijacking), but need not be recorded beyond that; the latter seems more like an option than a necessity. > Clients may, instead of interacting with a user to "validate" a > server's public key, bind authentication at the application layer to > the server's public key, as is done in SSHv2 with the GSS-API key > exchange extension to SSHv2. The client must first auto-accept the server's public key (instead of interacting with the user first), otherwise there won't be a channel to bind later ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKDCAE5f5cImnZrsRAgy5AKDyL3rw1q3ohJZgtq9Tnaqau9u34gCg1aRV 5sjWBU8ZicAMGqO2Ej4KvLw= =yNZi -----END PGP SIGNATURE-----
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.