Re: ad hoc IPsec or similiar
At 3:26 PM -0500 6/26/07, Nicolas Williams wrote: I strongly dislike the WG's name. Suffice it to say that it was not my idea :); it created a lot of controversy at the time, though perhaps that controversy helped sell the idea ("why would you want this silly, insecure stuff?" "because it enables this other actually secure stuff"). Whereas I was in the camp of liking the name very much for the very reason that this thread was started: "because it lets you encrypt an arbitrary conversation with essentially no startup cost". --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Tue, Jun 26, 2007 at 01:20:41PM -0700, Paul Hoffman wrote: > >For all the other aspects of BTNS (IPsec connection latching [and > >channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a > >globally shared secret does not come close to being sufficient. > > Fully agree. BTNS will definitely give you more than just one-off > encrypted tunnels, once the work is finished. But then, it should > probably be called MMTBTNS (Much More Than...). I strongly dislike the WG's name. Suffice it to say that it was not my idea :); it created a lot of controversy at the time, though perhaps that controversy helped sell the idea ("why would you want this silly, insecure stuff?" "because it enables this other actually secure stuff"). Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
At 2:49 PM -0500 6/26/07, Nicolas Williams wrote: On Fri, Jun 22, 2007 at 10:43:16AM -0700, Paul Hoffman wrote: > This was discussed many times, and always rejected as "not good enough" by the purists. Then the IETF created the BTNS Working Group which is spending huge amounts of time getting close to purity again. That's pretty funny, actually, although I don't quite agree with the substance (surprise!) :) Why, are you some sort or purist? :-) (For those outside the IETF, Nico is one of the main movers and shakers in BTNS, and is probably one of the main reasons it looks like it will actually finish its work.) Seriously, for those who merely want unauthenticated IPsec, MITMs and all, then yes, agreeing on a globally shared secret would suffice. Well, almost suffice. You also need a way of signalling before the Diffie-Hellman that this is what you are doing, but that's a trivial extension to both IKEv1 and IKEv2. For all the other aspects of BTNS (IPsec connection latching [and channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a globally shared secret does not come close to being sufficient. Fully agree. BTNS will definitely give you more than just one-off encrypted tunnels, once the work is finished. But then, it should probably be called MMTBTNS (Much More Than...). --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Fri, Jun 22, 2007 at 10:43:16AM -0700, Paul Hoffman wrote: > Note that that RFC is Informational only. There were a bunch of > perceived issues with it, although I think they were more purity > disagreements than anything. > > FWIW, if you do *not* care about man-in-the-middle attacks (called > active attacks in RFC 4322), the solution is much, much simpler than > what is given in RFC 4322: everyone on the Internet agrees on a > single pre-shared secret and uses it. You lose any authentication > from IPsec, but if all you want is an encrypted tunnel that you will > authenticate all or parts of later, you don't need RFC 4322. > > This was discussed many times, and always rejected as "not good > enough" by the purists. Then the IETF created the BTNS Working Group > which is spending huge amounts of time getting close to purity again. That's pretty funny, actually, although I don't quite agree with the substance (surprise!) :) Seriously, for those who merely want unauthenticated IPsec, MITMs and all, then yes, agreeing on a globally shared secret would suffice. For all the other aspects of BTNS (IPsec connection latching [and channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a globally shared secret does not come close to being sufficient. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/26/07, Sandy Harris <[EMAIL PROTECTED]> wrote: It is certainly a problem, but you can get around it partially even if your IP address is dynamically assigned: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html#opp.client You do need to use a dynamic DNS server to handle your keys, but there are lots of those, and many do provide that service. Also, this is limited to "initiate-only" IPsec; it does not handle incoming connections. However, that may be enough for many client machines that live in dynamic address space. I don't get it. Why is it so limited? Reverse DNS is not significantly more trustworthy than simply querying the remote host on a known port if you don't have DNSSEC. -- Taral <[EMAIL PROTECTED]> "Please let me know if there's any further trouble I can give you." -- Unknown - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/23/07, Eugen Leitl <[EMAIL PROTECTED]> wrote: > The general idea is that if you use keys in DNS to authenticate gateways Aye, that's the rub. Most hosts are in dynamic address space, and anything involving DNS will not fly. It is certainly a problem, but you can get around it partially even if your IP address is dynamically assigned: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html#opp.client You do need to use a dynamic DNS server to handle your keys, but there are lots of those, and many do provide that service. Also, this is limited to "initiate-only" IPsec; it does not handle incoming connections. However, that may be enough for many client machines that live in dynamic address space. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
The wikipedia article has some information, but it could use some edits if you have new information. http://en.wikipedia.org/wiki/Opportunistic_encryption rearden On Fri, 22 Jun 2007 11:52:13 -0400 Sandy Harris <[EMAIL PROTECTED]> wrote: >On 6/22/07, Eugen Leitl <[EMAIL PROTECTED]> wrote: > >> So what's the state in ad hoc IPsec/VPN setup for any end >points? > >The Linux FreeS/WAN project was working on "opportunistic >encryption". > >The general idea is that if you use keys in DNS to authenticate >gateways >and IPsec for secure tunnels then any two machines can communicate >securely without their administrators needing to talk to each >other or to >set up specific pre-arranged tunnels. > >http://www.freeswan.org/freeswan_trees/freeswan- >2.00/doc/glossary.html#carpediem >http://www.freeswan.org/freeswan_trees/freeswan- >2.00/doc/quickstart.html > >There is an RFC based on that work: >ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt > >The FreeS/WAN project has ended. I do no know if the follow-on >projects, >openswan.org and strongswan.org, support OE. > >-- >Sandy Harris >Quanzhou, Fujian, China > >--- >-- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to >[EMAIL PROTECTED] -- Click here to double your salary by becoming a medical transcriber http://tagline.hushmail.com/fc/Ioyw6h4eKoYjYstwQcEy9UxPRDQcZZyB8BukGw6meHWNNe4g9MQFew/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
At 11:52 PM +0800 6/22/07, Sandy Harris wrote: On 6/22/07, Eugen Leitl <[EMAIL PROTECTED]> wrote: So what's the state in ad hoc IPsec/VPN setup for any end points? The Linux FreeS/WAN project was working on "opportunistic encryption". The general idea is that if you use keys in DNS to authenticate gateways and IPsec for secure tunnels then any two machines can communicate securely without their administrators needing to talk to each other or to set up specific pre-arranged tunnels. http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html There is an RFC based on that work: ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt The FreeS/WAN project has ended. I do no know if the follow-on projects, openswan.org and strongswan.org, support OE. Note that that RFC is Informational only. There were a bunch of perceived issues with it, although I think they were more purity disagreements than anything. FWIW, if you do *not* care about man-in-the-middle attacks (called active attacks in RFC 4322), the solution is much, much simpler than what is given in RFC 4322: everyone on the Internet agrees on a single pre-shared secret and uses it. You lose any authentication from IPsec, but if all you want is an encrypted tunnel that you will authenticate all or parts of later, you don't need RFC 4322. This was discussed many times, and always rejected as "not good enough" by the purists. Then the IETF created the BTNS Working Group which is spending huge amounts of time getting close to purity again. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/22/07, Eugen Leitl <[EMAIL PROTECTED]> wrote: So what's the state in ad hoc IPsec/VPN setup for any end points? The Linux FreeS/WAN project was working on "opportunistic encryption". The general idea is that if you use keys in DNS to authenticate gateways and IPsec for secure tunnels then any two machines can communicate securely without their administrators needing to talk to each other or to set up specific pre-arranged tunnels. http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html There is an RFC based on that work: ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt The FreeS/WAN project has ended. I do no know if the follow-on projects, openswan.org and strongswan.org, support OE. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Thu, Jun 21, 2007 at 06:00:48PM +0100, Richard Clayton wrote: > (a) the EU legislation was actually passed well over a year ago > > http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2006/l_105/l_10520060413en00540063.pdf It is not national law yet. I'm only concerned about when I have to deal with it personally. > and applies to "service providers" so "random endpoints" will be The pending legislation is stated broadly enough to include anyone with a proxy or a mix cascade, company or private body, for-profit or non-profit. It threatens up to half a megaeuro penalty and up to two years in jail. > unlikely to be caught by its requirements. Any random endpoints will be passing through the ISP, and hence subject to retention. An ad hoc IPsec or VPN tunnel setup will make data analysis more difficult, especially if there's traffic background (P2P, etc). So what's the state in ad hoc IPsec/VPN setup for any end points? > (b) what the Directive exactly means is anyone's guess (the wording > shows a deep failure to understand how the Internet works), and it is > entirely clear that it will in practice mean different things in > different EU countries. I've been told this legislation will be used by several persons within BKA etc. to harass Tor operators. This is not a guess; I'm not sure how reliable that source is, however. > In the UK it's likely to only apply to large public ISPs -- and > retention will be restricted to records of who used which IP address, > email server records, and possibly web cache logs (possibly not, since > web caches may not be economic if the logs have to be retained)... The financial burden is completely on the side of the providers. > ... the wikipedia page on the topic > > http://en.wikipedia.org/wiki/Data_retention > > ... has information for other countries that looks fairly plausible from > what I know about their plans. Unfortunately, I know more about the plans than I ever wished. > Note that the Directive also applies to phone calls ... and the It also applies to mobile phone location in the cell. > transposition of that into national laws is supposed to be completed by > October 2007; most countries have until March 2009 for Internet logs Apparently, Germany will implement Internet connection retention by end of the year/beginning of 2008 latest. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
In article <[EMAIL PROTECTED]>, Eugen Leitl <[EMAIL PROTECTED]> writes >There's a rather ominous EU legislation to be passed soon, >which requires any party acting as a provider (you run anonymous >proxy, or mix cascade, you are a provider) to log all connection >info (when, who, with whom). What's the status of ad hoc IPsec >or any other TCP/IP-tunneling VPN for random endpoints? (a) the EU legislation was actually passed well over a year ago http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2006/l_105/l_1052 0060413en00540063.pdf and applies to "service providers" so "random endpoints" will be unlikely to be caught by its requirements. (b) what the Directive exactly means is anyone's guess (the wording shows a deep failure to understand how the Internet works), and it is entirely clear that it will in practice mean different things in different EU countries. In the UK it's likely to only apply to large public ISPs -- and retention will be restricted to records of who used which IP address, email server records, and possibly web cache logs (possibly not, since web caches may not be economic if the logs have to be retained)... ... the wikipedia page on the topic http://en.wikipedia.org/wiki/Data_retention ... has information for other countries that looks fairly plausible from what I know about their plans. Note that the Directive also applies to phone calls ... and the transposition of that into national laws is supposed to be completed by October 2007; most countries have until March 2009 for Internet logs -- richard Richard Clayton They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]