Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
Hadmut Danisch wrote: On Thu, Sep 16, 2004 at 12:41:41AM +0100, Ian Grigg wrote: It occurs to me that a number of these ideas could be written up over time ... a wiki, anyone? I think it is high past time to start documenting crypto patterns. Wikis are not that good for discussions, and I do believe that this requires some discussion. I'd propose a separate mailing list for that. It possibly requires both. A mailing list by itself tends to generate great thoughts that don't get finished by being turned into summaries. Also, those in charge tend to slow the process, just through being too busy. (I'm not talking about just this list, I've noticed the effect on RFC lists where the editor wakes up after a week and skips all the debate and starts again.) A wiki working with a mailing list might address both those issues. (It's just a guess, I've never really worked with a Wiki, just read some entries over at wikipedia.) iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
On Thu, Sep 16, 2004 at 12:41:41AM +0100, Ian Grigg wrote: It occurs to me that a number of these ideas could be written up over time ... a wiki, anyone? I think it is high past time to start documenting crypto patterns. Wikis are not that good for discussions, and I do believe that this requires some discussion. I'd propose a separate mailing list for that. regards Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
On 2004, Sep 11, , at 17:20, Sandy Harris wrote: Zooko O'Whielcronx wrote: 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 That link leads to the following definition: A situation in which any two IPsec-aware machines can secure their communications, without a pre-shared secret and without a common PKI or previous exchange of public keys. This is one of the goals of the Linux FreeS/WAN project, discussed in our introduction section. Setting up for opportunistic encryption is described in our configuration document. This definition is indeed consistent with the concept that we are discussing. If FreeS/WAN's implementation boils down to using DNS as a common PKI that is too bad, but their definition (which explicitly excludes a common PKI) seems to be the same as mine. This concept is too important to go without a name. Currently the best way to tell your interlocutor what concept you are talking about seems to be you know, the way SSH does it, with the first-time-unauthenticated public key exchange. I heartily approve of Peter Gutmann's suggestion to write an RFC for it. Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
In message [EMAIL PROTECTED], Peter Gutmann writes: Eugen Leitl [EMAIL PROTECTED] writes: 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. Sounds good. Who wants to write it...? --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
Steven M. Bellovin [EMAIL PROTECTED] writes: 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, Sounds good. Who wants to write it...? Since there seems to be at least some interest in this, I'll make a start on it. If anyone else wants to add their $0.03 to it [0], let me know. Peter. [0] Or $0.04 if you're paying in Euros. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
Tim == Tim Shepard [EMAIL PROTECTED] writes: Tim Sam said: No. opportunistic encryption means I have retrieved a key or cert for the other party, but do not know whether it is actually the right cert. Tim If the key is retrieved from the other end of a TCP Tim connection (like vanilla ssh works the first time), is that Tim included within the definition of opportunistic encryption? Yes. Note that for at least one of the uses of anonymous ipsec you specifically don't want this behavior because you specifically don't want people to cache keys in an ssh known_hosts style. For other uses you would want this behavior. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
At 11:45 AM 9/12/2004, Sam Hartman wrote: No. opportunistic encryption means I have retrieved a key or cert for the other party, but do not know whether it is actually the right cert. This is slightly different although at the level of current discussion it has the same security properties. Actually, FreeSWAN's Opportunistic Encryption meant if you've got IP traffic for somebody, see if they can do encryption with you and use it if you can. Because Gilmore wanted to make sure encryption was always done securely, their implementation used a common PKI - DNSSEC and inverse DNS - which has the advantage that a security gateway can use it when all it knows is the IP address of the destination (which is typically the case), but the severe disadvantage that very few people have control over that DNS space and also that an IP address may belong to more than one domain. There's a significant policy question there - if you don't have a common PKI of some sort, is it worthwhile encrypting anyway, protecting against passive eavesdroppers but not MITM, or is that a false sense of security because the people who most need security are the people most likely to have a government annoyed enough at them to do the work of running a MITM attack? Encryption against passive eavesdroppers makes password-stealing and traffic analysis harder, so it's probably worth the risk, but that wasn't the choice that FreeSWAM made. 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 [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
At 11:43 AM 9/11/2004, Peter Gutmann wrote: 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 :-). i've referred to it as identity agnostic ... as opposed to anonymous ... even with public key use. the scenario is that the original identity x.509 certificates created huge privacy issues. the the current credit card scenario, it carries a name ... in theory so that the merchant or point-of-sale can cross-check the name against additional forms of identification as a means of authentication (where the merchant is sort of a stand-in agent for the consumer's financial institution even tho the merchant and the consumer's financial institution may have significantly different and possibly opposing interests). in effect it is transforming something that should be purely an authentication operation (is the entity entitled to perform a transaction for the account) into a much more difficult (and privacy invasive) identification operation. the x9.59 scenario is that the transaction is simply authenticated with a digital signature that the merchant passes thru to the consumer's financial institution. the consumer financial institution verifies the digital signature with public key on file for that account. the verification of the digital signature implies some form of something you have authentication (implies that you uniquely have the corresponding private key). it becomes a straight-forward authentication operation and identity agnostic ... w/o the horrible identity and privacy invasive that can accompany a x.509 identity certificate. while it may be possible for various agents to associated the authentication operation the operations themselves, at least don't carry the possibly mandatory identity information privacy invasive information that can be found in identity x.509 certificates. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - 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 a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgphSDUxjY0Or.pgp
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]
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: 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]
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: [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: 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 PROTECTED]
