Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
On Fri, 10 Sep 2004, Eugen Leitl wrote: >From: Joe Touch <[EMAIL PROTECTED]> >>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." > That's pseudonymity, not anonymity. >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. This is just plain not true. When operating under a pseudonym, you are making linkable acts - linkable to each other even if not necessarily linkable to your own official identity. Anonymous actions or communications are those which cannot be linked to any other no matter how hard someone tries. We can expect the public to fail to grasp the distinction, but on this list "anonymous" is a very strong claim. Anonymity is *HARD* to do, not something that results from failing to check a credential. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]))
On Sat, Sep 11, 2004 at 11:38:00AM -0700, Joe Touch wrote: > >>Although anonymous access is not the primary goal, it is a feature > >>of the solution. > > > >The access is _not_ anonymous. The originator's IP, ISP call traces, > >phone access records will be all over it and associated audit logs. > > And you cannot determine whether that IP address came from the authentic > owner of that address or is spoofed. I'll try to be more careful - > you're right, in that it's not anonymous access. It IS anonymous > security, though. I think you are confusing a weak potential for a technical ambiguity of identity under attack conditions with anonymity. (The technical ambiguity would likely disappear in most practical settings). Anonymity implies positives steps to avoid linking with PII. With anonymity you want not just technical ambiguity, but genuinely pluasible deniability from an anonymity set -- preferably a large set of users who could equally plausibly have established a given connection, participated in an authentication protocol etc. We don't after all call TCP anonymous, and your system is cleary _less_ "anonymous" than TCP as there are security mechanisms involved with various keys and authentication protocols which will only reduce ambiguity. > >The distinguishing feature of anonymous is that not only is your name > >not associated with the connection but there is no PII (personally > >identifiable information) associated with it or obtainable from logs > >kept. > > If I know the IP address you used, I still know NOTHING, FWIW. This is > no more distinguishable than the port number is in identifying something > behind a NAT. Practically, knowing the IP address conveys a lot. Many ISPs have logs, some associated with DSL subscriber and phone records, for billing, bandwidth caps, abuse complaints, spam cleanup etc etc. The IP may be used for many different logged activities and some of those activites may involve directly identified authentication. People go to lengths to hide their IP precisely because it does typically convey all too much. > >And to be clear also anonymous means unlinkable anonymous across > >multiple connections (which SSH type of authentication would not be) > > That might be more specifically "per-connection anonymous", but the term > 'anonymous' is too general for that usage. However, there's still > nothing associated across connections in ANONSEC, IMO. > You cannot know whether two connections from 10.0.0.1 on two different > ports with two different cookies are from the same endpoint. The point > of ANONSEC is that you don't care. If one wants this to be true in practice it has to propogate up the stack. (Not the problem of ANONSEC, a problem for the higher level app). But even at the authentication protocol level one has to be quite careful. There are many gotchas if you really do want it to be unlinkable. (eg. pseudo random sequences occur in many settings at different protocol levels which are in fact quite linkable). I'll give you one high level example. At ZKS we had software to remail MIME mail to provide a pseudonymous email. But one gotcha is that mail clients include MIME boundary lines which are pseudo-random (purely to avoid string collision). If these random lines are generated with a non-cryptographic RNG it is quite likely that so called unlinkable mail would in fact be linkable because of this higher level protocol. (We cared about unlinkability even tho' I said pseudonymous because the user had multiple pseudonyms which were supposed to be unlinkable across). I would say if your interest in fixing such pseudo random sequeneces is not present you should not be calling this anonymous. But if it is part of your threat model, then you may in fact be using anonymous authentication and that would be interesting to me at least to participate. Adam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
Zooko O'Whielcronx wrote: On 2004, Sep 09, , at 16:57, Hal Finney wrote: ... 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. No. It can also use RSA public keys without embedding them in certificates or requiring a CA, let alone a 3rd party one. The new proposal would let connections go forward using a straight Diffie-Hellman type exchange without authentication. 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. Sounds right to me, though "unauthenticeted" might be more precise. I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN this is called "opportunistic encryption". That is certainly not what FreeS/WAN meant by "opportunistic encryption". http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/glossary.html#carpediem OE does authenticate all connections. The trick is that the public keys are stored in DNS so you do not have to exchange keys with the admin of a site before you can do secure communications to it. For this to be secure, you need DNSsec widely deployed. In effect you are using DNS as a PKI. Without DNSsec, this reduces to something fairly anonymous -- anyone who can lie in DNS can pretend to be anyone they choose. However, that was never the design intent of OE. If you want anonymous connections, there are easier ways. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]))
Joe Touch <[EMAIL PROTECTED]> wrote: > >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. Joe: I respectfully request that you call this something other than "anonymous". It is quite confusing and misleading. Some people have spent quite a bit of time and effort in fact working on anonymous IP and anonymous/pseudonymous transports. For example at ZKS we worked on an anonymous/pseudonymous IP product (which means cryptographically hiding the souce IP address from the end-site). There are some new open source anonymous IP projects. Your proposal, which may indeed have some merit in simplifying key management, has _nothing_ to do with anonymous IP. Your overloading of the established term will dilute the correct meaning. Zooko provided the correct term and provided references: "opportunistic encryption". It sounds to have similar objectives to what John had called opportunistic encryption and tried to do with freeSWAN. Lowever level terms may be unauthenticated as Hal suggested. Or non-certified key management (as the SSH cacheing of previously before seen IP <-> key bindings and warnings when they change). > Although anonymous access is not the primary goal, it is a feature > of the solution. The access is _not_ anonymous. The originator's IP, ISP call traces, phone access records will be all over it and associated audit logs. The distinguishing feature of anonymous is that not only is your name not associated with the connection but there is no PII (personally identifiable information) associated with it or obtainable from logs kept. And to be clear also anonymous means unlinkable anonymous across multiple connections (which SSH type of authentication would not be) and linkable anonymous means some observable linkage exists between sessions which come from the same source (though no PII), and pseudonymous means same as linkable anonymous plus association to a persistent pseudonym. Again there are actually cryptographic protcols for_ having anonymous authentication: ZKPs, multi-show unlinkable credentials, and refreshable (and so unlinkable) single-show credentials. Adam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
Eugen Leitl <[EMAIL PROTECTED]> writes: >It does not authenticate the endpoint's identification, other than "same place >I had been talking to." So in other words it's the same baby-duck security model that's been quite successfully used by SSH for about a decade, is also used in some SSL implementations that don't just blindly trust anything with a certificate (particularly popular with STARTTLS-enabled MTAs/MUAs where you don't want to bother with CA-issued certs), and is even used in various X.509 applications (via "certificate fingerprints"), although the X.509 folks don't like to admit that because it implies that a known-good cert fingerprint is more reliable than a CA :-). Maybe it's worth doing some sort of generic RFC for this security model to avoid scattering the same thing over a pile of IETF WGs, things like the general operational principles (store a hash of the server key, compare it on subsequent connects), how to present the value to the user (a format that's consistent across protocols would be nice), maybe a simple /etc/passwd-type file format listing servers and their matching hashes, etc etc etc. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
At 12:57 PM 9/9/2004, Hal Finney wrote: > 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. I read the draft, and I don't see how it offers any improvement over draft-ietf-ipsec-internet-key-00.txt or Gilmore's proposal touse "open secret" as a not-very-secret pre-shared secret that anybody who wants to can accept. It does introduce some lower-horsepower alternatives for authenticating less than the entire packet, and suggests using AH which I thought was getting rather deprecated these days, but another way to reduce horsepower needs is to use AES instead of 3DES. Also, the author's document discusses protecting BGP to prevent some of the recent denial-of-service attacks, and asks for confirmation about the assertion in a message on the IPSEC mailing list suggesting "E.g., it is not feasible for BGP routers to be configured with the appropriate certificate authorities of hundreds of thousands of peers". Routers typically use BGP to peer with a small number of partners, though some big ISP gateway routers might peer with a few hundred. (A typical enterprise router would have 2-3 peers if it does BGP.) If a router wants to learn full internet routes from its peers, it might learn 1-200,000, but that's not the number of direct connections that it has - it's information it learns using those connections. And the peers don't have to be configured "rapidly without external assistance" - you typically set up the peering link when you're setting up the connection between an ISP and a customer or a pair of ISPs, and if you want to use a CA mechanism to certify X.509 certs, you can set up that information at the same time. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
From: Joe Touch <[EMAIL PROTECTED]>
Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd frTo:
"Discussions of anonymous Internet security." <[EMAIL PROTECTED]>
Date: Fri, 10 Sep 2004 09:03:50 -0700
Reply-To: "Discussions of anonymous Internet security." <[EMAIL PROTECTED]>
Clarifications below...
Eugen Leitl wrote:
>- Forwarded message from "\"Hal Finney\"" <[EMAIL PROTECTED]> -
>
>From: [EMAIL PROTECTED] ("Hal Finney")
>Date: Thu, 9 Sep 2004 12:57:29 -0700 (PDT)
>To: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED]
>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.
>Rather it
>is a proposal to an extension to IPsec to allow for unauthenticated
>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
>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.
This is one option, but not the only one.
>It also proposes less authentication
>of IP message packets, covering smaller subsets, as an option.
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
>to secure against weaknesses in TCP which have begun to be exploited.
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.
>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.
Please be more specific; how would it be better?
>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.
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
>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 PROTECTED]
>
>- End forwarded message -
>
>
>
>
>___
___
--
--
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07078, 11.61144http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: Perplexing proof
On Fri, Sep 10, 2004 at 08:23:06AM -0400, R. A. Hettinga wrote: > "[The suggested proof] is rather incomprehensible," professor Marcus du > Sautoy of Oxford University told The Guardian, adding that if correct it > could lead to the creation of a "prime spectrometer" that would bring "the > whole of e-commerce to its knees overnight". http://www.maths.ox.ac.uk/~dusautoy/flash/1hard/listpub.htm So at least now we have a named source, even one who works on generalized zeta functions. The out of the blue "prime spectrometer" claim is still rather puzzling... Does anyone know why Du Sautoy is making this claim (if it is indeed reported correctly). -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
On 2004, Sep 09, , at 16:57, Hal Finney wrote: 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. ... 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. I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN this is called "opportunistic encryption". Regards, Zooko [1] http://www.templetons.com/brad/crypt.html [2] http://bitconjurer.org/envelope.html [3] http://pps.sourceforge.net/ [4] http://www.advogato.org/article/391.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
