opportunistic IPsec interoperability

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

_______________________________________________

RE: opportunistic IPsec interoperability

I think identity based encryption sounds fine. Using the public
part (here identity) to encrypt is not an entirely new concept.

The question is who is going to vouch for those identities? How
do you prevent spurious identites being advertised? Do we need 
to come back to certificates, one of the main reasons to use 
identity instead of public keys?

Besides, IMHO, the goals of ANONSEC may be different from the 
goals of IBE.

Atul

> -----Original Message-----
> From: anonsec-bounces <at> postel.org [mailto:anonsec-bounces <at> postel.org]On
> Behalf Of ext Eugen Leitl
> Sent: Thursday, September 09, 2004 4:52 AM
> To: ANONSEC <at> postel.org
> Subject: [anonsec] opportunistic IPsec interoperability
> 
> 
> 
> 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

Re: opportunistic IPsec interoperability

On Thu, Sep 09, 2004 at 10:52:02AM +0200, Eugen Leitl wrote:
> 
> 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.

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.

Opportunistic ANONSEC

I propose that ANONSEC be a simple profile of IKE[v2] that uses
self-signed non-pre-shared certs for the CERT/AUTH exchanges.

This clearly is workable where two peers' SPDs are statically configured
to allow ANONSEC.

To be workable for opportunistic ANONSEC (meaning: "use ANONSEC if where
peers support it") this approach would require that there be a way for
peers to request/agree to use ANONSEC.

I see two non-mutually exclusive ways to do that:

a) provide APIs that apps can use to indicate desire/willingness to use
ANONSEC,

and/or

b) provide a way to propose, in the IKE protocol, ANONSEC.

For (a) see Bill Sommerfeld's draft-ietf-ipsp-ipsec-apireq-00.

For (b) I'd propose a new CERT type whose payload is a self-signed cert
and whose use indicates a proposal to do ANONSEC, as well as a new
CERTREQ type whose payload is empty or, optionally, a self-signed cert,
and whose use indicates a proposal to do ANONSEC.

Comments?

Nico
--

-- 

Re: opportunistic IPsec interoperability

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

Re: potential new IETF WG on anonymous IPSec (fwd from hal <at> finney.org)

----- Forwarded message from "\"Hal Finney\"" <hal <at> finney.org> -----

From: hal <at> finney.org ("Hal Finney")
Date: Thu,  9 Sep 2004 12:57:29 -0700 (PDT)
To: cryptography <at> metzdowd.com, cypherpunks <at> al-qaeda.net,
	rah <at> shipwright.com
Subject: Re: potential new IETF WG on anonymous IPSec

> The IETF has been discussing setting up a working group
> for anonymous IPSec.  They will have a BOF at the next IETF
> in DC in November.  They're also setting up a mailing list you
> might be interested in if you haven't heard about it already.
> ...
> 	http://www.postel.org/anonsec

To clarify, this is not really "anonymous" in the usual sense.  Rather it
is a proposal to an extension to IPsec to allow for unauthenticated
connections.  Presently IPsec relies on either pre-shared secrets or a
trusted third party CA to authenticate the connection.  The new proposal
would let connections go forward using a straight Diffie-Hellman type
exchange without authentication.  It also proposes less authentication
of IP message packets, covering smaller subsets, as an option.

The point has nothing to do with anonymity; rather it is an attempt
to secure against weaknesses in TCP which have begun to be exploited.
Sequence number guessing attacks are more successful today because of
increasing bandwidth, and there have been several instances where they
have caused disruption on the net.  While workarounds are in place, a
better solution is desirable.

Re: Re: potential new IETF WG on anonymous IPSec (fwd from hal <at> finney.org)

Clarifications below...

Eugen Leitl wrote:

> ----- Forwarded message from "\"Hal Finney\"" <hal <at> finney.org> -----
> 
> From: hal <at> finney.org ("Hal Finney")
> Date: Thu,  9 Sep 2004 12:57:29 -0700 (PDT)
> To: cryptography <at> metzdowd.com, cypherpunks <at> al-qaeda.net,
> 	rah <at> shipwright.com
> Subject: Re: potential new IETF WG on anonymous IPSec
> 
> 
>>The IETF has been discussing setting up a working group
>>for anonymous IPSec.  They will have a BOF at the next IETF
>>in DC in November.  They're also setting up a mailing list you
>>might be interested in if you haven't heard about it already.
>>...
>>	http://www.postel.org/anonsec
> 
> 
> To clarify, this is not really "anonymous" in the usual sense. 

It does not authenticate the endpoint's identification, other than "same 
place I had been talking to."

There's no difference between having no "name" and having a name you 
cannot trust. I.e., I could travel under the name "anonymous" or "", or 
under the name "A. Smith". If you don't know whether I am actually A. 
Smith, the latter is identical to the former.

Re: Opportunistic ANONSEC

Nicolas Williams wrote:

> I propose that ANONSEC be a simple profile of IKE[v2] that uses
> self-signed non-pre-shared certs for the CERT/AUTH exchanges.

FWIW, ANONSEC (the BOF that we hope to have, and the topic of this 
mailing list) is intended to include IKE mods, as well as mods to other 
Internet security protocols, e.g., TCP-MD5.

Can you explain why certs of any type are needed in this case? It would 
be easier to deploy to avoid the cert issue altogether.

> This clearly is workable where two peers' SPDs are statically configured
> to allow ANONSEC.
> 
> To be workable for opportunistic ANONSEC (meaning: "use ANONSEC if where
> peers support it") this approach would require that there be a way for
> peers to request/agree to use ANONSEC.

Agreed. That's already been discussed.

> I see two non-mutually exclusive ways to do that:
> 
> a) provide APIs that apps can use to indicate desire/willingness to use
> ANONSEC,
> 
> and/or
> 
> b) provide a way to propose, in the IKE protocol, ANONSEC.

Re: Opportunistic ANONSEC

On Fri, Sep 10, 2004 at 09:12:16AM -0700, Joe Touch wrote:
> 
> 
> Nicolas Williams wrote:
> 
> >I propose that ANONSEC be a simple profile of IKE[v2] that uses
> >self-signed non-pre-shared certs for the CERT/AUTH exchanges.
> 
> FWIW, ANONSEC (the BOF that we hope to have, and the topic of this 
> mailing list) is intended to include IKE mods, as well as mods to other 
> Internet security protocols, e.g., TCP-MD5.
> 
> Can you explain why certs of any type are needed in this case? It would 
> be easier to deploy to avoid the cert issue altogether.

0) Simplicity.  This approach is very, very simple.

1) We need something that can be reused later for re-keying (including
re-establishing SAs after SA expiration).  Not covering this is really
not acceptable, and making changes to IKE to allow for renewal of
expired SAs goes against (0).

A public key would do, but this leads me to:

2) No need to talk about AUTH with bare keys vs. certs.  We need only
talk about CERT/CERTREQ (see my previous post).

3) Leap-of-faith.  Once you've shared a self-signed cert through ANONSEC
(and better: authenticated it using channel bindings and whatever
authentication you had available) the cert becomes available for

Re: Re: potential new IETF WG on anonymous IPSec (fwd from hal <at> finney.org)

Joe,

	<SNIP>

>Correction: it is a proposal to extend Internet security - including 
>Ipsec, but also including TCP-MD5 (sometimes called "BGP MD5") and 
>other security mechanisms at various layers. It is not focused only 
>on IPsec.

TCP-MD5 and other MACs based on MD5 not using the HMAC construct are 
generally  deprecated at this point.  TCP-MD5 had to get special text 
written by Steve Bellovin to allow for its use in BGP, as that 
protocol went to full standard, and that occurred only because of its 
widespread implementation. So, going forward, it seems questionable 
to provide support for protocols that use this form of MAC.

Steve
_______________________________________________