[anonsec] PAS issue 14 - leap of faith

[Nicolas Williams]

On Mon, Apr 03, 2006 at 05:52:41PM -0400, Stephen Kent wrote:
> >>  I think I'm ready to assert:
> >>
> >>  a) LoF is meaningful only where actual authentication of the peer is
> >>     desired; not caring at all requires no "leap";
> >
> >That makes no sense to me, nor does it match anything I could find in
> >the literature. LOF seems precisely about blind acceptance of the first
> >certificate presented without authentication.
> 
> I agree with Nico. The essence of LoF is that a user accepts a 
> credential (a cert that will be viewed as a trust anchor for SSL, a 
> public key for a server in SSH) under the assumption that there is no 
> MITM attack taking place at the time of exchange with the server, and 
> that the ID and key asserted in the exchange is accurate. After that 
> initial exchange where the LoF takes place, subsequent communication 
> is authenticated based on the credential that was accepted, and is 
> resistant to MITM attacks.

Right, so the BTNS core I-D only provides for "not caring at all" about
authentication and leaves LoF to some other document.

> In the IPsec context, this translates into creating a PAD entry based 
> on a unauthenticated IKE exchange.

This is the first one of two methods we've considered so far.

The second method involves connection latching and pushes the
responsibility for LoF to the application.

I *much* prefer the second method.

>                                    The difference here is that IPsec, 
> unlike SSH and SSL, implements access control and thus the ID bound 
> to the key directly affects the protocol operation in this regard. So 
> we have to be very careful what form  of IDs are installed in a PAD 
> entry under an LoF model of operation. For example, addresses might 
> be inappropriate (due to DHCP and mobility) but names might be OK.

The problem is that w/o IPsec-specific APIs the only "IDs" seen by the
application through traditional APIs are, in fact, IP addresses.

You've just re-identified the problem: IPsec LoF requires IPsec-specific
APIs to avoid dynamic address consumption (read: DoS attacks), and it
requires application involvement.

We just agreed that we don't want strong bindings between PUBLICKEY IDs
and addresses; we also don't want to allow theft of packet flows at SA
expiration/renewal time, and we don't want very long SA lifetimes to
create stronger publickey/address bindings than we're willing to
tolerate.  Which, IMO, argues for connection latching.

If you'll accept IPsec APIs at all then I think you'll find the second
LoF method (see above) more appealing than the first.

Nico
--