[anonsec] PAS issue 14 - leap of faith

[Joe Touch]

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