Subject: [anonsec] BTNS and fetching fingerprints/certs

From: Black_David at emc.com ([email-masked])
Date: Tue, 15 Mar 2005 20:14:08 -0500

Subject change to focus on the core of Ekr's argument: 

> Let's talk big picture for a second. There are (at least) two
> ways that BTNS can be used:
> 
> 1. Use BTNS or nothing.
> 2. Use BTNS or fall back to cleartext.
> 
> Now, in case (1), you definitely can't turn on BTNS unless you
> absolutely know that the peer does BTNS, because otherwise you
> can't communicate. This means that you need to have a prior
> arrangement with the peer, at which point they could easily
> have provided a public key fingerprint, at which point you
> could do more or less standard IKE (replacing the cert check
> with a comparison to the fingerprint, which is easy to add
> and not really a wire protocol issue) and call it a day.

I believe this was later clarified that "know the peer does
BTNS" specifically meant "know the peer supports IKE".  I'm
definitely interested in case (1) and have a counterexample
to Ekr's "could easily" assertion ...

... Suppose that the "prior arrangement with the peer" is
"sneaker-net", so any fingerprint, shared secret, etc. gets
transported by hand (don't laugh, it's not that unrealistic).
By the time one gets up to adding the 20th host with full n x
n connectivity, there are 38 items that have to be transported
- 19 to the new host, and one to each of the host's 19 peers -
and this has exceeded any reasonable scope of "easily" ...

The reason this matters is administrative/management overhead.
I'm interested in BTNS for channel binding use cases where
there are already good sets of identities and authentication
credentials in a higher layer protocol.  Any notion of identity
at the IPsec level that requires any management/administrative
attention just gets in the way in this case, even if something
better than "sneaker-net" is available.  The security policy
will be simple/compact - Joe's 10.*.*.* is far more likely than
an SPD entry per peer because the former requires no changes
to add or remove a host.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------