Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [email-masked])

From: eugen at leitl.org (Eugen Leitl)
Date: Fri Sep 10 08:22:23 2004

----- Forwarded message from "\"Hal Finney\"" <[email-masked]> -----

From: [email-masked] ("Hal Finney")
Date: Thu,  9 Sep 2004 12:57:29 -0700 (PDT)
To: [email-masked], [email-masked],
	[email-masked]
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.

This new effort is Joe Touch's proposal to weaken IPsec so that it uses
less resources and is easier to deploy.  He calls the weaker version
AnonSec.  But it is not anonymous, all the parties know the addresses
of their counterparts.  Rather, it allows for a degree of security on
connections between communicators who don't share any secrets or CAs.
I don't think "anonymous" is the right word for this, and I hope the
IETF comes up with a better one as they go forward.

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email-masked]

----- End forwarded message -----
-- 
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/20040910/0a5fe851/attachment.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Sep 10 09:06:25 2004

Clarifications below...

Eugen Leitl wrote:

> 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.

> Rather it
> connections.

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.

> Presently IPsec relies on either pre-shared secrets or a
> exchange without authentication.

This is one option, but not the only one.

> It also proposes less authentication

There are two aspects:
	- smaller portion of the packet is hashed
	- none of the packet is hashed, but a cookie is used

> The point has nothing to do with anonymity;

The last one, agreed. But the primary assumption is that we can avoid a 
lot of infrastructure and impediment to deployment by treating an 
ongoing conversation as a reason to trust an endpoint, rather than a 
third-party identification. Although anonymous access is not the primary 
goal, it is a feature of the solution.

> rather it is an attempt

Please review the draft; there are a number of reasons this is being 
considered, not the least of which is to reduce the cumbersome 
requirement of key infrastructure as well as to avoid performance penalties.

> better solution is desirable.

Please be more specific; how would it be better?

> of their counterparts.

Address != identity. Agreed, if what you want to do is hide traffic, 
this does not provide traffic confidentiality. But it does not tell you 
whether the packets come from 128.9.x.x (ISI, e.g.) or from someone 
spoofing 128.9.x.x; all you know is that whoever is using that address 
is capable of having an ongoing conversation (TCP connection, e.g.) with 
you.

I.e., there are two ways to be anonymous, as noted earlier:
	1) don't give out your name (A. Smith, e.g.)
	2) give out a name, but it doesn't necessarily mean anything
	(e.g., Mickey Mouse)

Even if you use "real" names in (2), there's no difference with (1), 
since you don't know whether the real Mickey Mouse is using it.

> Rather, it allows for a degree of security on
> ------------------------------------------------------------------------
> 
> _______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040910/07e8c66a/signature.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Sep 10 10:26:27 2004

Joe,

	<SNIP>

>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

---

From: rabbi at abditum.com (Len Sassaman)
Date: Fri Sep 10 10:28:25 2004

> of IP message packets, covering smaller subsets, as an option.

Indeed. I have been following these discussions, somewhat confused by the
claim that this had anything to do with anonymity, which it does not
appear to.

However, I do believe that there may be ways of modifying IPsec to do
provide basic anonymity features, such as the encryption of packet
headers, on-router mixing, etc. David Chaum and I have been discussing
this somewhat recently -- might this be a good forum to float these ideas?

--Len.

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Sep 10 10:56:35 2004

Stephen Kent wrote:

>> other security mechanisms at various layers. It is not focused only on 
>> IPsec.
> 
> 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

That update may be part of what needs to be addressed; the focus of 
ANONSEC is to provide configuration-free security for any protocol. 
TCP-MD5 was used only as an example.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040910/b40a4ba1/signature.bin