Subject: [anonsec] opportunistic IPsec interoperability

From: eugen at leitl.org (Eugen Leitl)
Date: Thu Sep 9 01:52:16 2004

There have been several opportunistic IPsec schemes (FreeS/WAN, etc.) but
none of them was widely deployed nor achieved true opportunism (publishing
DNS records is a high threshold), and suffered high setup latency.

What's your opinion on http://rooster.stanford.edu/~ben/pubs/ipibe.pdf
?

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20040909/9132549f/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Sep 9 14:54:22 2004

> DNS records is a high threshold), and suffered high setup latency.

Define "opportunistic."

> What's your opinion on http://rooster.stanford.edu/~ben/pubs/ipibe.pdf

In practice an IBE requires that the sender find the public parameters
for the receiver's IBE PKG, which typically will be the same for other
receivers in the same domain -- how much overhead is saved by having to
do this once for many peers depends on usage patterns.

Finding the PKG (so as to get its public parameters) for some IP address
may well be non-trivial; more so if you want to authenticate the PKG
(which I'm sure you'd want to do :)

I.e., IBE is not infrastructure-less, though it may sometimes be
promoted as if it were (something like "you only need to know the peer's
name," which is true, if you can find the peer's PKG's public parameters
given the peer's name, but even so, that you must do so is not obvious
from such a statement).

ANONSEC is literally about anonymous key exchanges and as such requires
no authentication infrastructure, no CAs, no PKGs, no KDCs, no DNSSEC,
nada, nothing.

Of course, anonymous key exchanges are trivially vulnerable to MITM
attacks, and therefore so is ANONSEC, but that's ok for certain
applications.

Joe's goal, I think, is to make it hard for attackers who could not
mount MITM attacks on ANONSEC key exchanges to then attack sessions that
use those keys.  The application: protecting BGP against TCP RST spoof
attacks without having to setup passwords, PKIs, or any sort of
authentication infrastructure.

My goal is to additionally provide for a way to name ANONSEC channels
such that authentication of such names at higher network layers proves
that there's not MITMs in the ANONSEC channels.

Other applications are possible.

Michael Richardson points out "leap of faith" authentication schemes and
"opportunistic encryption" by which, I think, he means "if your peer
supports ANONSEC, just use it" which differs, if at all, from Joe's
ANONSEC proposal only in the nature of the policies one uses (static vs.
dynamic, if you wish).

Cheers,

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Sep 10 08:04:25 2004

Here are some additional observations on IBE:

IBE requires that the public parameters for a group of users be made 
available in an integrity secure and authentic fashion. This is 
equivalent to having to distribute a public key cert for the CA for 
these users. There is also the problem that the enity who acts as a 
CA in an IBE context must be trusted to create the private keys for 
the users it represents, not an ideal security model in general.

IF one managed to align CAs with DNS domains, THEN this might be a 
more manageable problem. But, note the failure to perform such 
alignment for traditional (cert-based) PKIs. Thus one needs to 
explain why we expect to create an IBE infrastructure that aligns 
with DNS and does not become a trusted third party (e.g., 
VeriSign-style) infrastructure, given the lack of success in doing 
this for traditional PKIs.

Also, IBE was initial proposed as a way to address the problem of 
e-mail encryption, where the sender has to retrieve the cert of each 
recipient before being able to send encrypted mail. In IPsec, the 
real time connection between two parties provides a ready means to 
exchange certs, so the underlying problems are not the same. In fact, 
certs are used for authentication in the Ipsec context, not 
encryption, so IBE is literally not the ideal term for what one would 
like here.  It would be IBS (identity based signature), since IKEv2 
uses only signatures for authentication (a simplification relative to 
IKEv1, where either signatures or encryption was used for 
authentication).

Steve

P.S.  the cited paper 
(http://rooster.stanford.edu/~ben/pubs/ipibe.pdf) misspells IPsec as 
IPSec and erroneously characterizes several aspects of IPsec.