[anonsec] PAS issue 14 - leap of faith

[touch at ISI.EDU (Joe Touch)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Nicolas Williams wrote:
> On Mon, Mar 27, 2006 at 10:35:44AM -0800, Joe Touch wrote:
>>> 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?
> 
> It's what we as human users to do: "validate" (as if they even usually
> could, via some oob way) a peer's public key so that the application can
> create a pseudonymous-ID-(public key)-to-peer-address/ID/name/... binding.

That seems like a very specific thing - out-of-band validation. There's
no leap there - the user can (and seems like they're expected to)
validate the key out-of-band.

I.e., I was distinguishing between out-of-band validation - which is
what SSL clients tend to do when the server's key isn't signed by a
known CA, vs what SSL servers to - which does not involve asking a user
anything.

> If unprotected traffic is OK then accepting peer public keys for "better
> than nothing security" requires no "faith" at all.  (The BTNS core I-D
> provides only for this, and so does not address LoF _at all_.)
> 
> OTOH, if protection against MITMs is required then on first meeting
> either "faith" or channel binding will be required to get past a peer's
> non-certified public key.

There are different places in the communication that MITM can occur;
BTNS SAB still protects against MITM after the IKE DH step; it just
doesn't protect you from doing the DH with the middle-man. I.e., if the
DH isn't to the middle-man, then the stream should be MITM-protected.

> Once one has take this leep then one can create a
> 
>     public key -> name/address/ID
> 
> binding to avoid having to take it again later.

That step seems to have nothing to do with LOF or even CB. It seems like
it's just a local CA, equivalent to signing the remote keys yourself
(i.e., you trusted them before, so you trust them in the future).

>> 	- 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.
> 
> Yes, but that's not quite LoF.  And the app, given connection latching
> and APIs to retrieve a latched connection's peer's public key, could
> still do LoF at the app layer, even though there's no LoF below.

I didn't think LOF was limited to cases with connection latching; if it
is, please let me know.

>> 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...
> 
> Not just 'blindly accepting a peer's cert', but doing so when and in
> spite of stronger authentication being desired, because one has "faith"
> that one is not currently being actively attacked...

"blindly" meant 'in the absence of stronger authentication'

if stronger authentication is desired, the the leap isn't taken ;-)

the faith is that the attack isn't in the identity phase of the
protocol; there can still be assumptions of attacks at other phases
(e.g., data attacks)

> ...And thence creating a stronger binding between the 'peer's cert' and
> the name/address by which it was named (at the transport layer and below
> that would always be an IP address; at the applications layers it would
> be a name or address).
> 
>>>    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 ;-)
> 
> Yes, of course, and IPsec policy must allow it, but that's not LoF in
> the SSH sense (see above); LoF in the SSH sense would consist of
> recording a {server's public key, user-provided servername/address}
> tuple on faith [that there peer really is the one the user wanted] and
> subsequently using the recorded entry to avoid having to take the leap
> again.

As per above, I don't see how using a cached leap is a new leap, and LOF
can't be defined in terms of just that cache (it'd be a circular
definition). There must be an initial leap; subsequent use of the cache
really seems like it isn't taking a new leap at all.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEKFAVE5f5cImnZrsRAuCLAJ47jaTqzzTTeJrQ10XbrAXY7nMCbgCfUZmo
pdbRcqqzzhTdTpYW99SgRgE=
=LD3N
-----END PGP SIGNATURE-----