[anonsec] PAS issue 14 - leap of faith
Nicolas.Williams at sun.com
Tue Apr 4 07:53:29 PDT 2006
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.
More information about the ANONSEC