Re: potential new IETF WG on anonymous IPSec
From: Major Variola (ret) [EMAIL PROTECTED] Sent: Sep 17, 2004 10:27 PM To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: potential new IETF WG on anonymous IPSec At 06:20 AM 9/17/04 +, Justin wrote: On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: ... Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there. DoD certs are good enough for DoD slaves. Hospital certs are good enough for their employees. Joe's Bait Und Tackle certs are good enough for Joe's employees. Do you think that Verislime is good enough for you? You seem to have rediscovered the fact that crypto can move trust around, but can't create any. You have to decide to trust someone for it to be useful. The great problem with practically using this stuff is getting someone that you're comfortable trusting, who can then use crypto to move the trust around in a sensible way. The condition necessary for Verisign certificates to have a lot of trust, to me, is for the appearance of a fraudulent Verisign certificate to be a major scandal, leading to the CEO getting canned, the stock price dropping by some large fraction, and a huge fall-off of business for their CA. When that isn't the case (for the high security certs; it's clearly silly to expect it for low-security ones), the CA doesn't have as much incentive as I'd like to be careful about forgeries. You'd like the exposure of a fraudulent certificate signed by a CA to have the same kind of effect as the exposure of a bank being unable to produce the money a depositor demands. Fraudulent certificates issued for any purpose--whether furnishing fake IDs to FBI agents, or to Al Qaida terrorists, or to random Nigerian-scam operators--leave a permanent trail; the recipient of the certificate can show it around when he discovers it's fraudulent. If the last step of this protocol for the CA is and then you go out of business, the incentives not to issue fraudulent certificates looks right. --John
Re: potential new IETF WG on anonymous IPSec
From: Major Variola (ret) [EMAIL PROTECTED] Sent: Sep 17, 2004 10:27 PM To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: potential new IETF WG on anonymous IPSec At 06:20 AM 9/17/04 +, Justin wrote: On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: .. Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there. DoD certs are good enough for DoD slaves. Hospital certs are good enough for their employees. Joe's Bait Und Tackle certs are good enough for Joe's employees. Do you think that Verislime is good enough for you? You seem to have rediscovered the fact that crypto can move trust around, but can't create any. You have to decide to trust someone for it to be useful. The great problem with practically using this stuff is getting someone that you're comfortable trusting, who can then use crypto to move the trust around in a sensible way. The condition necessary for Verisign certificates to have a lot of trust, to me, is for the appearance of a fraudulent Verisign certificate to be a major scandal, leading to the CEO getting canned, the stock price dropping by some large fraction, and a huge fall-off of business for their CA. When that isn't the case (for the high security certs; it's clearly silly to expect it for low-security ones), the CA doesn't have as much incentive as I'd like to be careful about forgeries. You'd like the exposure of a fraudulent certificate signed by a CA to have the same kind of effect as the exposure of a bank being unable to produce the money a depositor demands. Fraudulent certificates issued for any purpose--whether furnishing fake IDs to FBI agents, or to Al Qaida terrorists, or to random Nigerian-scam operators--leave a permanent trail; the recipient of the certificate can show it around when he discovers it's fraudulent. If the last step of this protocol for the CA is and then you go out of business, the incentives not to issue fraudulent certificates looks right. --John
Re: potential new IETF WG on anonymous IPSec
At 09:09 AM 9/17/04 +0200, Thomas Shaddack wrote: On Thu, 16 Sep 2004, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. You don't have to sign the certs. Use self-signed ones, then publish a GPG signature of your certificate in a known place; make bloody sure your GPG key is firmly embedded in the web-of-trust. Right. And the known trusted place is 0wn3d by the Man. The web of trust is a scam. Know your pharmacist.
Re: potential new IETF WG on anonymous IPSec
On 2004-09-17T19:27:09-0700, Major Variola (ret) wrote: At 06:20 AM 9/17/04 +, Justin wrote: On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there. DoD certs are good enough for DoD slaves. Hospital certs are good enough for their employees. Joe's Bait Und Tackle certs are good enough for Joe's employees. Do you think that Verislime is good enough for you? No, verislime is not good enough for me, for ethical reasons, not security reasons. What's good enough for most businesses is anything that keeps customers from seeing self-signed cert warnings. Given the choice, I'd pick geotrust over no-thawte or verislime. The only reason they're in business is because of browser warnings. It has nothing to do with physical security offered by the CA, or threat models, or anything of that sort. For e-commerce, nobody needs high security. Anyone using a high-credit-limit account online without a liability limit in case of account theft is a moron. -- The old must give way to the new, falsehood must become exposed by truth, and truth, though fought, always in the end prevails. -- L. Ron Hubbard
Re: potential new IETF WG on anonymous IPSec
At 04:05 PM 9/16/2004, Joe Touch wrote: FWIW, the other system we were referring to - TCP-MD5 - works at the TCP layer. It rejects packets within TCP, before any further TCP processing, that don't match the MD5 hash. It isn't BGP authentication. Oh - I'd misunderstood. Yes, that sounds much harder to forge, so it's actually useful for DOS reduction. At 03:27 AM 9/17/2004, Ian Grigg wrote: I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. ... When we come to BGP, it seems that BGP routing parties have a very high level of trust between them. And this trust is likely to exceed by orders of magnitude any trust that a third party could generate. Hence, adding certs signed by this TTP (well known CA or not) is unlikely to add anything, and will thus likely add costs for no benefit. If anyone tried to impose a TTP for this purpose, I'd suspect the BGP admins would ignore it. Another way of thinking about it is to ask who would the two BGP operators trust more than each other? There are two reasons to use the CA. One is if the parties don't know each other (not a problem here), but the other is so the VPN receiver has some external validation on the data it receives, making MITM attacks harder. For applications like BGP, you don't care if the CA is Dun Bradstreet or if it's just Alice's own CA, because it's really functioning as a shared secret but the commodity VPN hardware wants an X.509 cert for MITM protection. Bill Stewart [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
At 06:20 AM 9/17/04 +, Justin wrote: On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there. DoD certs are good enough for DoD slaves. Hospital certs are good enough for their employees. Joe's Bait Und Tackle certs are good enough for Joe's employees. Do you think that Verislime is good enough for you?
Re: potential new IETF WG on anonymous IPSec
On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there.
Re: potential new IETF WG on anonymous IPSec
On Thu, 16 Sep 2004, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. You don't have to sign the certs. Use self-signed ones, then publish a GPG signature of your certificate in a known place; make bloody sure your GPG key is firmly embedded in the web-of-trust. This can be done with certs signed by an untrusted (read: any other than the one you operate yourself) CA as well. For HTTPS, there can be a negotiated standard location and format of the certificate signature file, stored in eg. /gpgsigned.xml location; the certificate is transported during the SSL handshake, so you can validate it within a single HTTPS request for the file. Similar thing applies for the client certificates and the servers; but then the server has to request the certificate signature from somewhere else (the location may be specified as an URL in the comment field of the client certificate). This should be easy to implement with PHP scripts, if Apache is configured to make the certificate visible as an environmental variable.
Re: potential new IETF WG on anonymous IPSec
Joe Touch wrote: Ian Grigg wrote: On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) While inspired by this issue, there may be other solutions (e.g., IMO IPsec) which are more appropriate for BGP peers. Thanks for the clarification. Re-reading (all) of the above, I noticed that these are DOS attacks. (That changes things - crypto protocols don't really a priori stop or defeat DOS attacks. They can help, or they may not, it all depends.) It's then important to examine the threat here. Who is the attacker and what motives and tools does he have available? It would be annoying to do all the work, only to discover that he has other tools that are just as easy... (This is called what's-your-threat-model, sometimes abbreviated to WYTM?) The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place Except that certs need to be signed by authorities that are trusted. Right, in that the CA model seeks to add trust to the wild wild west by the provision of these signed / trusted certs. Whether it achieves that depends on the details. It is not wise to just assume it succeeds because someone said so. - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? iang I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. In the world of PKIs, there are some big assumptions. Here's two of them: Alice and Bob don't know each other, and don't necessarily trust each other. There exists a central stable party that *both* Alice and Bob know better than each other and can be trusted to pass the trust on. Known as a trusted third party, TTP, or a certificate authority, CA, in particular. This situation exists in large companies for example - the company knows Alice and Bob better than they may know each other. (In theory.) Now, whether it exists in any real world depends on which world pertains. In the world of browsing, it is .. assumed to exist, but that can be challenged. In the world of email, it pretty clearly doesn't exist - almost all (desired) email is done between known parties, and the two parties generally have much better ways of establishing and bootstrapping a crypto relationship than asking for some centralised party to do it. (Hence, the relative success of PGP over S/MIME.) Ditto for the world of secure systems administration (SSH). When we come to BGP, it seems that BGP routing parties have a very high level of trust between them. And this trust is likely to exceed by orders of magnitude any trust that a third party could generate. Hence, adding certs signed by this TTP (well known CA or not) is unlikely to add anything, and will thus likely add costs for no benefit. If anyone tried to impose a TTP for this purpose, I'd suspect the BGP admins would ignore it. Another way of thinking about it is to ask who would the two BGP operators trust more than each other? In such a world, a CA-signed certificate is an encumberance only, and seems to be matched by comments in the AnonSec draft that they are unlikely to be deployed. iang PS: on the general issue of doing what you call anonSec, I'd say, fantastic, definately overdue, could save IPSec from an embarrassingly slow adoption! I do concur with all the other posts about how anon is the wrong word, but I'd say that getting the right term is not so important as doing the work! On the point of what the right word is, that depends on the technique chosen. I haven't got that far in the draft as yet.
Re: potential new IETF WG on anonymous IPSec
Ian Grigg wrote: ... I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. I should have said could have certs. BGP could use shared secrets or CAs; it may be the case that anonymous security (as at least I call it) doesn't map well to BGP, in which you usually know who you want to trust. It may still help, though - e.g., in the case of the recent TCP RST attacks, it would have. The rest of your note focuses on the difference between two-party trust and trust using a shared third party. The former degenerates to the latter where I sign your cert, though ;-) I agree that for BGP the two-party case is probably more relevant, though there some BGP peerings are based on trust relationships of sets of parties that can - or already do - have trusted third-party coordination outside BGP. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
At 06:20 AM 9/17/04 +, Justin wrote: On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there. DoD certs are good enough for DoD slaves. Hospital certs are good enough for their employees. Joe's Bait Und Tackle certs are good enough for Joe's employees. Do you think that Verislime is good enough for you?
Re: potential new IETF WG on anonymous IPSec
At 09:09 AM 9/17/04 +0200, Thomas Shaddack wrote: On Thu, 16 Sep 2004, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. You don't have to sign the certs. Use self-signed ones, then publish a GPG signature of your certificate in a known place; make bloody sure your GPG key is firmly embedded in the web-of-trust. Right. And the known trusted place is 0wn3d by the Man. The web of trust is a scam. Know your pharmacist.
Re: potential new IETF WG on anonymous IPSec
On 2004-09-17T19:27:09-0700, Major Variola (ret) wrote: At 06:20 AM 9/17/04 +, Justin wrote: On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there. DoD certs are good enough for DoD slaves. Hospital certs are good enough for their employees. Joe's Bait Und Tackle certs are good enough for Joe's employees. Do you think that Verislime is good enough for you? No, verislime is not good enough for me, for ethical reasons, not security reasons. What's good enough for most businesses is anything that keeps customers from seeing self-signed cert warnings. Given the choice, I'd pick geotrust over no-thawte or verislime. The only reason they're in business is because of browser warnings. It has nothing to do with physical security offered by the CA, or threat models, or anything of that sort. For e-commerce, nobody needs high security. Anyone using a high-credit-limit account online without a liability limit in case of account theft is a moron. -- The old must give way to the new, falsehood must become exposed by truth, and truth, though fought, always in the end prevails. -- L. Ron Hubbard
Re: potential new IETF WG on anonymous IPSec
At 04:05 PM 9/16/2004, Joe Touch wrote: FWIW, the other system we were referring to - TCP-MD5 - works at the TCP layer. It rejects packets within TCP, before any further TCP processing, that don't match the MD5 hash. It isn't BGP authentication. Oh - I'd misunderstood. Yes, that sounds much harder to forge, so it's actually useful for DOS reduction. At 03:27 AM 9/17/2004, Ian Grigg wrote: I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. ... When we come to BGP, it seems that BGP routing parties have a very high level of trust between them. And this trust is likely to exceed by orders of magnitude any trust that a third party could generate. Hence, adding certs signed by this TTP (well known CA or not) is unlikely to add anything, and will thus likely add costs for no benefit. If anyone tried to impose a TTP for this purpose, I'd suspect the BGP admins would ignore it. Another way of thinking about it is to ask who would the two BGP operators trust more than each other? There are two reasons to use the CA. One is if the parties don't know each other (not a problem here), but the other is so the VPN receiver has some external validation on the data it receives, making MITM attacks harder. For applications like BGP, you don't care if the CA is Dun Bradstreet or if it's just Alice's own CA, because it's really functioning as a shared secret but the commodity VPN hardware wants an X.509 cert for MITM protection. Bill Stewart [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
Ian Grigg wrote: .. I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. I should have said could have certs. BGP could use shared secrets or CAs; it may be the case that anonymous security (as at least I call it) doesn't map well to BGP, in which you usually know who you want to trust. It may still help, though - e.g., in the case of the recent TCP RST attacks, it would have. The rest of your note focuses on the difference between two-party trust and trust using a shared third party. The former degenerates to the latter where I sign your cert, though ;-) I agree that for BGP the two-party case is probably more relevant, though there some BGP peerings are based on trust relationships of sets of parties that can - or already do - have trusted third-party coordination outside BGP. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
Ian Grigg wrote: Bill Stewart wrote: 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. On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) While inspired by this issue, there may be other solutions (e.g., IMO IPsec) which are more appropriate for BGP peers. The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place Except that certs need to be signed by authorities that are trusted. - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? iang I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
Joe Touch wrote: Ian Grigg wrote: On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) While inspired by this issue, there may be other solutions (e.g., IMO IPsec) which are more appropriate for BGP peers. Thanks for the clarification. Re-reading (all) of the above, I noticed that these are DOS attacks. (That changes things - crypto protocols don't really a priori stop or defeat DOS attacks. They can help, or they may not, it all depends.) It's then important to examine the threat here. Who is the attacker and what motives and tools does he have available? It would be annoying to do all the work, only to discover that he has other tools that are just as easy... (This is called what's-your-threat-model, sometimes abbreviated to WYTM?) The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place Except that certs need to be signed by authorities that are trusted. Right, in that the CA model seeks to add trust to the wild wild west by the provision of these signed / trusted certs. Whether it achieves that depends on the details. It is not wise to just assume it succeeds because someone said so. - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? iang I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. In the world of PKIs, there are some big assumptions. Here's two of them: Alice and Bob don't know each other, and don't necessarily trust each other. There exists a central stable party that *both* Alice and Bob know better than each other and can be trusted to pass the trust on. Known as a trusted third party, TTP, or a certificate authority, CA, in particular. This situation exists in large companies for example - the company knows Alice and Bob better than they may know each other. (In theory.) Now, whether it exists in any real world depends on which world pertains. In the world of browsing, it is .. assumed to exist, but that can be challenged. In the world of email, it pretty clearly doesn't exist - almost all (desired) email is done between known parties, and the two parties generally have much better ways of establishing and bootstrapping a crypto relationship than asking for some centralised party to do it. (Hence, the relative success of PGP over S/MIME.) Ditto for the world of secure systems administration (SSH). When we come to BGP, it seems that BGP routing parties have a very high level of trust between them. And this trust is likely to exceed by orders of magnitude any trust that a third party could generate. Hence, adding certs signed by this TTP (well known CA or not) is unlikely to add anything, and will thus likely add costs for no benefit. If anyone tried to impose a TTP for this purpose, I'd suspect the BGP admins would ignore it. Another way of thinking about it is to ask who would the two BGP operators trust more than each other? In such a world, a CA-signed certificate is an encumberance only, and seems to be matched by comments in the AnonSec draft that they are unlikely to be deployed. iang PS: on the general issue of doing what you call anonSec, I'd say, fantastic, definately overdue, could save IPSec from an embarrassingly slow adoption! I do concur with all the other posts about how anon is the wrong word, but I'd say that getting the right term is not so important as doing the work! On the point of what the right word is, that depends on the technique chosen. I haven't got that far in the draft as yet.
Re: potential new IETF WG on anonymous IPSec
On Thu, 16 Sep 2004, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. You don't have to sign the certs. Use self-signed ones, then publish a GPG signature of your certificate in a known place; make bloody sure your GPG key is firmly embedded in the web-of-trust. This can be done with certs signed by an untrusted (read: any other than the one you operate yourself) CA as well. For HTTPS, there can be a negotiated standard location and format of the certificate signature file, stored in eg. /gpgsigned.xml location; the certificate is transported during the SSL handshake, so you can validate it within a single HTTPS request for the file. Similar thing applies for the client certificates and the servers; but then the server has to request the certificate signature from somewhere else (the location may be specified as an URL in the comment field of the client certificate). This should be easy to implement with PHP scripts, if Apache is configured to make the certificate visible as an environmental variable.
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: At 02:17 PM 9/16/2004, Joe Touch wrote: Ian Grigg wrote: On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) The interesting attacks were a sequence-number guessing attack using forged TCP RST packets, which tell the TCP session to tear down, therefore dropping the BGP connection (typically between two ISPs). The attackers didn't need to be trusted backbone routers - they could be randoms anywhere on the Internet. BGP authentication doesn't actually help this problem, because the attack simply kills the connection at a TCP layer rather than lying to the BGP application. FWIW, the other system we were referring to - TCP-MD5 - works at the TCP layer. It rejects packets within TCP, before any further TCP processing, that don't match the MD5 hash. It isn't BGP authentication. This is why I refer to it as TCP-MD5 rather than BGP-MD5, even though the latter is more common. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one.
Re: potential new IETF WG on anonymous IPSec
On 2004-09-16T20:11:56-0700, Major Variola (ret) wrote: At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one. Oh, come on. Nothing can be absolutely trusted. How much security is enough? Aren't the DOD CAs trusted enough for your tastes? Of course, 'tis problematic for civilians to get certs from there.
Re: potential new IETF WG on anonymous IPSec
At 02:17 PM 9/16/2004, Joe Touch wrote: Ian Grigg wrote: On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) The interesting attacks were a sequence-number guessing attack using forged TCP RST packets, which tell the TCP session to tear down, therefore dropping the BGP connection (typically between two ISPs). The attackers didn't need to be trusted backbone routers - they could be randoms anywhere on the Internet. BGP authentication doesn't actually help this problem, because the attack simply kills the connection at a TCP layer rather than lying to the BGP application. A simple way to avoid most of this problem is to filter packets at the edges so that customer connections can't send IP (or ICMP, while you're at it) packets to the core addresses on the routers that do the BGP signalling. (It's not a complete solution, because both ends of the connection need to so that, or need to do spoof-proofing so nobody can forge packets from those addresses, or both.) Customers can still send packets to the ISP edge routers supporting their own connections, but killing your own internet connection is much less entertaining than killing somebody else's, and if the customer is managing their own router, their users probably have an easier time killing that end of the connection than convincing the ISP's end to drop the connection. (One downside to this approach is that customers can't simply ping routers to get information about paths, latencies, capacities, etc., but that's not necessarily a bad thing. Also, you can set things up so they can traceroute to the far end of a connection and still get traceroute responses from the intermediate routers.) While inspired by this issue, there may be other solutions (e.g., IMO IPsec) which are more appropriate for BGP peers. ... I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. I agree with Joe. You can fix most of the problems using ACLs, but IPSEC does have some appeal to it. You don't even need CAs - pre-shared secrets are perfectly adequate, but if you want to use a CA-based IPSEC implementation for convenience, you can agree on what CA to use when you're agreeing on other parameters. Bill Stewart [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
Ian Grigg wrote: Bill Stewart wrote: 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. On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) While inspired by this issue, there may be other solutions (e.g., IMO IPsec) which are more appropriate for BGP peers. The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place Except that certs need to be signed by authorities that are trusted. - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? iang I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
At 02:17 PM 9/16/2004, Joe Touch wrote: Ian Grigg wrote: On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) The interesting attacks were a sequence-number guessing attack using forged TCP RST packets, which tell the TCP session to tear down, therefore dropping the BGP connection (typically between two ISPs). The attackers didn't need to be trusted backbone routers - they could be randoms anywhere on the Internet. BGP authentication doesn't actually help this problem, because the attack simply kills the connection at a TCP layer rather than lying to the BGP application. A simple way to avoid most of this problem is to filter packets at the edges so that customer connections can't send IP (or ICMP, while you're at it) packets to the core addresses on the routers that do the BGP signalling. (It's not a complete solution, because both ends of the connection need to so that, or need to do spoof-proofing so nobody can forge packets from those addresses, or both.) Customers can still send packets to the ISP edge routers supporting their own connections, but killing your own internet connection is much less entertaining than killing somebody else's, and if the customer is managing their own router, their users probably have an easier time killing that end of the connection than convincing the ISP's end to drop the connection. (One downside to this approach is that customers can't simply ping routers to get information about paths, latencies, capacities, etc., but that's not necessarily a bad thing. Also, you can set things up so they can traceroute to the far end of a connection and still get traceroute responses from the intermediate routers.) While inspired by this issue, there may be other solutions (e.g., IMO IPsec) which are more appropriate for BGP peers. ... I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. I agree with Joe. You can fix most of the problems using ACLs, but IPSEC does have some appeal to it. You don't even need CAs - pre-shared secrets are perfectly adequate, but if you want to use a CA-based IPSEC implementation for convenience, you can agree on what CA to use when you're agreeing on other parameters. Bill Stewart [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: At 02:17 PM 9/16/2004, Joe Touch wrote: Ian Grigg wrote: On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) The interesting attacks were a sequence-number guessing attack using forged TCP RST packets, which tell the TCP session to tear down, therefore dropping the BGP connection (typically between two ISPs). The attackers didn't need to be trusted backbone routers - they could be randoms anywhere on the Internet. BGP authentication doesn't actually help this problem, because the attack simply kills the connection at a TCP layer rather than lying to the BGP application. FWIW, the other system we were referring to - TCP-MD5 - works at the TCP layer. It rejects packets within TCP, before any further TCP processing, that don't match the MD5 hash. It isn't BGP authentication. This is why I refer to it as TCP-MD5 rather than BGP-MD5, even though the latter is more common. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
At 02:17 PM 9/16/04 -0700, Joe Touch wrote: Except that certs need to be signed by authorities that are trusted. Name one.
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: 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. On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? iang
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: 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. On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? iang
Re: potential new IETF WG on anonymous IPSec
On Wed, 15 Sep 2004, Ian Grigg wrote: The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? If I remember correctly, the TCP MD5 option field was designed for securing BGP traffic, using the shared secret approach. I was also thinking about borrowing this feature for things like announcement of additional features, eg. the possibility of opportunistic encryption, in eg. the TCP/SYNACK packets. There's space for 16 bytes of magic numbers.
Re: potential new IETF WG on anonymous IPSec
Currently BGP is secured by 1. accepting BGP info only from known router IPs 2. ISPs not propogating BGP from the edge inwards Its a serious vulnerability (as in, take down the net), equivalent to the ability to confuse the post office machinery that sorts postcards. All you need to do is subvert some trusted routers. At 10:54 PM 9/10/04 -0700, Bill Stewart wrote: 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.
Re: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org))
On Sun, 12 Sep 2004, R. A. Hettinga wrote: From: Adam Back [EMAIL PROTECTED] Subject: Re: anonymous IP terminology (Re: [anonsec] Re: potential new IETF 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. Wouldn't it be relatively easy to regenerate the MIME boundary strings on the level of the remailer, and filter the content of the headers? Various mail clients have various peculiarities, fingerprints. Shouldn't the remailer be able to break the message down to individual data objects (subject, message text, attachments...) and then reassemble them back, in a sanitized way?
Re: potential new IETF WG on anonymous IPSec
Currently BGP is secured by 1. accepting BGP info only from known router IPs 2. ISPs not propogating BGP from the edge inwards Its a serious vulnerability (as in, take down the net), equivalent to the ability to confuse the post office machinery that sorts postcards. All you need to do is subvert some trusted routers. At 10:54 PM 9/10/04 -0700, Bill Stewart wrote: 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.
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]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Fri, 10 Sep 2004 18:20:28 +0200 From: Eugen Leitl [EMAIL PROTECTED] To: Cryptography List [EMAIL PROTECTED] Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED]) User-Agent: Mutt/1.4i Sender: [EMAIL PROTECTED] 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
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: 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. That is part of the solution, but not all, as noted below. 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. That is corrected in draft-touch-tcp-antispoof, which contains the BGP focus of anonsec-00; anonsec-01 (to appear in about 2 weeks) focuses on just the anonsec portion of 00. 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. Thanks for that input; the claim that BGP in core Internet routers required intractible setup for TCP-MD5 has been refuted by experience noted during the TCPM WG meeting in San Diego as well. This section of tcp-antispoof will be updated accordingly. Joe Bill Stewart [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org))
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Sat, 11 Sep 2004 15:09:54 -0400 From: Adam Back [EMAIL PROTECTED] To: Joe Touch [EMAIL PROTECTED] Cc: Eugen Leitl [EMAIL PROTECTED], Cryptography List [EMAIL PROTECTED], Adam Back [EMAIL PROTECTED] Subject: Re: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED])) User-Agent: Mutt/1.4.1i Sender: [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] --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Sat, 11 Sep 2004 14:53:59 -0700 (PDT) From: bear [EMAIL PROTECTED] To: Eugen Leitl [EMAIL PROTECTED] Cc: Cryptography List [EMAIL PROTECTED] Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED]) Sender: [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] --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
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]
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: 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. That is part of the solution, but not all, as noted below. 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. That is corrected in draft-touch-tcp-antispoof, which contains the BGP focus of anonsec-00; anonsec-01 (to appear in about 2 weeks) focuses on just the anonsec portion of 00. 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. Thanks for that input; the claim that BGP in core Internet routers required intractible setup for TCP-MD5 has been refuted by experience noted during the TCPM WG meeting in San Diego as well. This section of tcp-antispoof will be updated accordingly. Joe Bill Stewart [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
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
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
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
