[anonsec] PAS issue 14 - leap of faith

[Nicolas Williams]

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.

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.

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.

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

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

Nico
--