[anonsec] PAS issue 14 - leap of faith

[Nicolas Williams]

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

> 	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.

> 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.

> 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.

Nico
--