-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 11:19:27AM -0800, Joe Touch wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Here's a summary of what I understand so far; please post corrections. >> >> 1. leap of faith = accepting an unauthenticated certificate >> this refers to the FIRST accept of that certificate > > My version: > > 1. leap of faith = accepting an unauthenticated peer when authentication > of it is otherwise desired > > Here "faith" refers to the belief, or rather, hope that the peer is > not being impersonated by an active attacker. > >> SSH servers do this automatically for client certificates, e.g. > ^^^^^^ ^^^^^^^^^^^^ > server public keys I meant client public keys. The auto-part is done at the server for the client info. The clients typically do NOT accept unauthenticated server public keys; they typically ask the user to authenticate them (as per below). >> SSH clients typically ask users to verify certificates that >> otherwise cannot be authenticated in-band; this *assumes* >> out-of-band authentication of the certificate. One can consider >> users who blindly 'accept' those certificates to be performing >> a similar 'leap of faith' at the user level, though. > > Not "consider" -- that *is* what leap of faith means in an SSH context: > that the user is asked to do something they often can't and so typically > accept a peer without further ado, on "faith" as it were. It's really useful to distinguish between what the user does (typically 'leaps') and what the protocol thinks it's doing (delegating authentication to a user process). SSH isn't taking the leap there. > >> 2. caching previously 'trusted' (authenticated or LOF assumed) keys for >> future use is NOT LOF >> there is no new leap taken >> >> this establishes continuity to _avoid_ a second LOF for the >> same certificate > > (2) is incidental to LoF, but fundamental to making LoF practical. The only practicality relates to interrupting the user to do out-of-band authentication. It's relevant only at the client side; the server side need not cache anything to be practical. >> I was reminded that such caching is irrelevant to IKE, i.e., that keys >> need not be cached to prevent hijacking, since SAs can be torn down only >> if the child of a parent SA (can anyone confirm?). > > This question is not important because you need connection latching to > protect you from the wildcard matching problems discussed and that, in > turn, provides a binding between individual packet flows and their > end-point IDs. Doesn't the need for (and utility of) connection latching presume channel binding? I.e., in the case where there is no channel binding, this doesn't seem relevant. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKFHVE5f5cImnZrsRAmY1AKDGKOwf1d6z7k+BxtJZw7ahot64KACfSyB4 DNXrcqi/Wdcmn1Q9ZPK4L3w= =7TV7 -----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.