Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
Guus Sliepen [EMAIL PROTECTED] writes: Compared with the entire TLS protocol it is much simpler, compared with just the handshake protocol it is about as simple and probably just as efficient, but as I said earlier, I want to get rid of the client/server distinction. You can't get rid of the distinction. You will always have a client and a server -- however you may just rename it Initiator and Responder to make it sound more peer-like, but it's just the same emperor in different clothes. The only real distinction between a _pure_ client-server protocol and a peer-to-peer protocol is that the latter is generally reversible where the former is not. By reversible I mean that either party could be the initiator and either could be the responder. HOWEVER, during the run of a protocol it behooves you to label the parties, and client/server is just as valid a naming as initiator/responder. IPsec (IKE) is clearly peer/peer. Even with TLS the protocol is reversible if you perform the name mappings and assume both ends have certificates. So, I urge you to be careful with trying to get rid of a distinction that really has little meaning in most protocols. -derek -- Derek Atkins 617-623-3745 [EMAIL PROTECTED] www.ihtfp.com Computer and Internet Security Consultant - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
=Step 1: Exchange ID messages. An ID message contains the name of the tinc daemon which sends it, the protocol version it uses, and various options (like which cipher and digest algorithm it wants to use). By name of the tinc daemon, do you mean identification information? That data should be encrypted, and therefore in step 2. (Alternatively, if you just mean tincd version 1.2.3.4, that's fine. Step 2: Exchange METAKEY messages. The METAKEY message contains the public part of a key used in a Diffie-Hellman key exchange. This message is encrypted using RSA with OAEP padding, using the public key of the intended recipient. You can't encrypt the DH keyparts using RSA unless you first exchange RSA public key information, which the server can't do without knowing who the client is (the client presumably knows who the server is, so you _could_ have the client send the key encrypted to annoy MITMs.) To make the protocol generally useful for privacy protection, you shouldn't exchange this information unencrypted. So do a Diffie-Hellman exchange first, then exchange any other information, including RSA signatures on the DH keyparts. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
I wrote: For some recent relevant papers, see the ACM-CCS '02 paper my colleagues and I wrote on our JFK protocol (http://www.crypto.com/papers/jfk-ccs.ppt), ... But of course I meant the url to be http://www.crypto.com/papers/jfk-ccs.pdf I don't know what I could have been thinking; I don't use the program that produces files with that extension unless a gun is pointed to my head. -matt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
If we use RSA encryption, then both sides know their message can only be received by the intended recipient. If we use RSA signing, then we both sides know the message they receive can only come from the assumed sender. For the purpose of tinc's authentication protocol, I don't see the difference, but... Now, the attacker chooses 0 as his DH public. This makes ZZ always equal to zero, no matter what the peer's DH key is. You need to validate the DH keyparts even if you're corresponding with the person you thought you were. This is true whether you're using signatures, encryption, or neither. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
Guus Sliepen [EMAIL PROTECTED] writes: On Mon, Sep 29, 2003 at 09:35:56AM -0700, Eric Rescorla wrote: Was there any technical reason why the existing cryptographic skeletons wouldn't have been just as good? Well all existing authentication schemes do what they are supposed do, that's not the problem. We just want one that is as simple as possible (so we can understand it better and implement it more easily), and which is efficient (both speed and bandwidth). In what way is your protocol either simpler or more efficient than, say, JFK or the TLS skeleton? And I just ripped TLS from the list. Define ripped. This certainly is not the same as TLS. Used as a skeleton. Don't ask me to define that as well. It doesn't appear to me that you've used the TLS skeleton. The protocol you described really isn't much more like TLS than it is like STS or JFK. On the other hand, all these back and forth DH-based protocols look more or less the same, except for some important details. That's not the same a sdoing a thorough analysis, which can take years, as Steve Bellovin has pointed out about Needham-Schroeder. True, but we can learn even from the bullet holes. Again, it's important to distinguish between learning experiences and deployed protocols. I agree that it's worthwhile to try to do new protocols and let other people analyze them as a learning experience. But that's different from putting a not fully analyzed protocol into a deployed system. Look, there's nothing wrong with trying to invent new protocols, especially as a learning experience. What I'm trying to figure out is why you would put them in a piece of software rather than using one that has undergone substantial analysis unless your new protocol has some actual advantages. Does it? We're trying to find that out. If we figure out it doesn't, we'll use one of the standard protocols. Well, I'd start by doing a back of the envelope performance analysis. If that doesn't show that your approach is better, then I'm not sure why you would wish to pursue it as a deployed solution. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
Bill Stewart [EMAIL PROTECTED] writes: If we use RSA encryption, then both sides know their message can only be received by the intended recipient. If we use RSA signing, then we both sides know the message they receive can only come from the assumed sender. For the purpose of tinc's authentication protocol, I don't see the difference, but... Now, the attacker chooses 0 as his DH public. This makes ZZ always equal to zero, no matter what the peer's DH key is. You need to validate the DH keyparts even if you're corresponding with the person you thought you were. This is true whether you're using signatures, encryption, or neither. Not necessarily. If you're using fully ephemeral DH keys and a properly designed key, then you shouldn't need to validate the other public share. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
On Mon, Sep 29, 2003 at 11:54:20AM -0700, Eric Rescorla wrote: Well all existing authentication schemes do what they are supposed do, that's not the problem. We just want one that is as simple as possible (so we can understand it better and implement it more easily), and which is efficient (both speed and bandwidth). In what way is your protocol either simpler or more efficient than, say, JFK or the TLS skeleton? Compared with JFK: http://www.crypto.com/papers/jfk-ccs.pdf section 2.2 shows a lot of keys, IDs, derivatives of keys, random numbers and hashes of various combinations of the previous, 3 public key encryptions and 2 symmetric cipher encryptions and HMACs. I do not consider that simple. Compared with the entire TLS protocol it is much simpler, compared with just the handshake protocol it is about as simple and probably just as efficient, but as I said earlier, I want to get rid of the client/server distinction. Again, it's important to distinguish between learning experiences and deployed protocols. I agree that it's worthwhile to try to do new protocols and let other people analyze them as a learning experience. But that's different from putting a not fully analyzed protocol into a deployed system. [...] Well, I'd start by doing a back of the envelope performance analysis. If that doesn't show that your approach is better, then I'm not sure why you would wish to pursue it as a deployed solution. I will not repeat our motiviations again. Please don't bother arguing about this. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
On Mon, Sep 29, 2003 at 09:51:20AM -0700, Bill Stewart wrote: =Step 1: Exchange ID messages. An ID message contains the name of the tinc daemon which sends it, the protocol version it uses, and various options (like which cipher and digest algorithm it wants to use). By name of the tinc daemon, do you mean identification information? That data should be encrypted, and therefore in step 2. (Alternatively, if you just mean tincd version 1.2.3.4, that's fine. No, identification information. But still, it's just a name, not a public key or certificate. It is only used by the receiver to choose which public key (or certificate etc) to use in Step 2. This information does not have to be encrypted, it has just as much meaning as the IP address the sender has. Step 2: Exchange METAKEY messages. The METAKEY message contains the public part of a key used in a Diffie-Hellman key exchange. This message is encrypted using RSA with OAEP padding, using the public key of the intended recipient. You can't encrypt the DH keyparts using RSA unless you first exchange RSA public key information, which the server can't do without knowing who the client is (the client presumably knows who the server is, so you _could_ have the client send the key encrypted to annoy MITMs.) With tinc, public keys are never exchanged during authentication, they are known beforehand. And again, there is no distinction between a client and a server, it is peer to peer. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
Guus Sliepen [EMAIL PROTECTED] writes: On Mon, Sep 29, 2003 at 02:07:04PM +0200, Guus Sliepen wrote: Step 2: Exchange METAKEY messages. The METAKEY message contains the public part of a key used in a Diffie-Hellman key exchange. This message is encrypted using RSA with OAEP padding, using the public key of the intended recipient. After comments and reading up on suggested key exchange schemes, I think this step should be changed to send the Diffie-Hellman public key in plaintext, along with a nonce (large random number) to prevent replays and the effects of bad DH public keys. Instead of encrypting both with RSA, they should instead be signed using the private key of the sender (the DH public key and nonce wouldn't fit in a single RSA message anyway). IKEv2 (as described in draft-ietf-ipsec-ikev2-10.txt) does almost the same. However, IKEv2 does not send the signature directly, but first computes the shared key, and uses that to encrypt (using a symmetric cipher) the signature. I do not see why they do it that way; the signature has to be checked anyway, if it can be done before computing the shared key it saves CPU time. Encrypting it does not prevent a man in the middle from reading or altering it, since a MITM can first exchange his own DH public key with both sides (and hence he can know the shared keys). So actually, I don't see the point in encrypting message 3 and 4 as described at page 8 of that draft at all. In order to hide the identities of the communicating peers. Personally, I don't have much use for identity protection, but this is the reason as I understand it. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
On Mon, 2003-09-29 at 06:07, Guus Sliepen wrote: TLS makes a distinction between a client and a server. If possible I wish to avoid making that distinction. If possible, I would also like to continue to be able to use an RSA public/private keypair. This made me *sketch* the following _authentication_ protocol: ... snip ... Some questions: - Some people keep saying that you shouldn't send the same kinds of messages. TLS sends different kinds of messages depending on its role (client or server). Is there a reason behind this? - Would it be nice to move all the cryptographic parameters exchanged in step 1 into the encrypted message in step 2? That way an attacker cannot see which encryption and digest algorithms will be used, which might make an attack less feasible. - Did I miss something? 1) TLS both authenticates the server and establishes an encrypted session in the server part of the transaction. 2) The original SSL somewhat assumed that the business requirements are different for server authentication (and encrypted session) vis-a-vis client authentication. The original SSL requirement a) was to give some level of confidence to the client that the server that the client thot it was talking to was actually the server it was talking to and b) provide an encrypted session. There wasn't actually a threat model requiring proving who you are ... just a threat model that the server prove that it was who the client supposedly thot it was. 3) SSL was being deployed with a requirement for encrypted session in an environment where client authentication: a) might not be required b) was not required as part of the transport protocol c) was used to webize/tunnel an existing legacy application where the client might use userid/password or other authentication previously established d) wouldn't be public key based because the clients were not expected to have public/private key pairs and certificates Some web'ized legacy applications were adopted from a private network environment ... where the client as part of making the connection knew that it was talking to the correct server. The minimum required to move that to the wide-open web ... was to provide server authentication and encrypted session ... and then tunnel the legacy app thru the encrypted session. The business requirement and threat model wasn't to invent a brand new environment from scratch ... but to adapt existing business operations to the wide-open web. Mutual authentication was somewhat an add-on of client authentication to the base infrastructure. In fact, I think that we were the first to specify and required the first implementation as part of the back-end of this thing that has come to be called electronic commerce. random electronic commerce refs: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 The trivial e-commerce is that the merchant server didn't really care who the client was ... just that the client bought something and the merchant was going to get paid. The merchant needed to provide some assurance that the credit card transaction being passed thru to the financial infrastructure was protected. The merchant relied on the financial infrastructure authenticating the credit card transaction ... and, in fact, any mutual authentication that might be done as part of the SSL transaction had no impact on the credit card transaction. To some extent, both VPN and SSL come into existence about the same time to satisfy specific business requirement(s) (and in part because it was taking so long to see any progress with ipsec). -- Anne Lynn Wheeler - http://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
Guus Sliepen [EMAIL PROTECTED] writes:
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:
TLS makes a distinction between a client and a server. If possible I
wish to avoid making that distinction. If possible, I would also like to
continue to be able to use an RSA public/private keypair. This made me
*sketch* the following _authentication_ protocol:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature and ripping
off one of the many skeletons that already exist (STS, JFK, IKE,
SKEME, SIGMA, etc.). That would save people from the trouble
of having to analyze the details of your new protoocl.
==
Step 1:
Exchange ID messages. An ID message contains the name of the tinc daemon
which sends it, the protocol version it uses, and various options (like
which cipher and digest algorithm it wants to use).
Step 2:
Exchange METAKEY messages. The METAKEY message contains the public part
of a key used in a Diffie-Hellman key exchange. This message is
encrypted using RSA with OAEP padding, using the public key of the
intended recipient.
After this step, both sides use Diffie-Hellman to compute the shared
secret key. From this master key, keys and IVs for symmetric ciphers and
digest algorithms will be derived, as well as verification data. From
this point on all messages will be encrypted.
Why are you using RSA encryption to authenticate your DH rather
than using RSA signature?
Depending on *exactly* how you do things, there are MITM attacks:
Consider the following protocol:
M1={DHx}RSAy -
- M2={DHy}RSAx
ZZ = DH shared key
HMAC(ZZ,M1,M2) -
- HMAC(ZZ,M2,M1) [Reverse order to prevent
replay]
Now, the attacker chooses 0 as his DH public. This makes ZZ always
equal to zero, no matter what the peer's DH key is. He can now forge
the rest of the exchange and intercept the connection.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
On Mon, Sep 29, 2003 at 07:53:29AM -0700, Eric Rescorla wrote: I'm trying to figure out why you want to invent a new authentication protocol rather than just going back to the literature and ripping off one of the many skeletons that already exist ( Several reasons. Because it's fun, because we learn more from doing it ourselves (we learn from our mistakes too), because we want something that fits our needs. We could've just grabbed one from the shelf, but then we could also have grabbed IPsec or PPP-over-SSH from the shelf, instead of writing our own VPN daemon. However, we wanted something different. STS, If you mean station-to-station protocol, then actually that is pretty much what we are doing now, except for encrypting instead of signing using RSA. JFK, IKE, SKEME, SIGMA, etc.). And I just ripped TLS from the list. That would save people from the trouble of having to analyze the details of your new protoocl. Several people on this list have already demonstrated that they are very willing to analyse new protocols. Also, I don't *expect* you to do so, if you don't want to ignore me. Why are you using RSA encryption to authenticate your DH rather than using RSA signature? If we use RSA encryption, then both sides know their message can only be received by the intended recipient. If we use RSA signing, then we both sides know the message they receive can only come from the assumed sender. For the purpose of tinc's authentication protocol, I don't see the difference, but... Now, the attacker chooses 0 as his DH public. This makes ZZ always equal to zero, no matter what the peer's DH key is. I think you mean it is equal to 1 (X^0 is always 1). This is the first time I've heard of this, I've never thought of this myself. In that case I see the point of signing instead of encrypting. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
On Mon, Sep 29, 2003 at 05:57:46PM +0200, Guus Sliepen wrote: Now, the attacker chooses 0 as his DH public. This makes ZZ always equal to zero, no matter what the peer's DH key is. I think you mean it is equal to 1 (X^0 is always 1). Whoops, stupid me. Please ignore that. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
EKR writes: I'm trying to figure out why you want to invent a new authentication protocol rather than just going back to the literature and ripping off one of the many skeletons that already exist (STS, JFK, IKE, SKEME, SIGMA, etc.). That would save people from the trouble of having to analyze the details of your new protoocl. Indeed. It's also worth pointing out that the standards for authentication / key exchange / key agreement protocols (and the techniques for attacking them) have improved over the last few years, to the point that if you want your protocol to have any chance of being taken seriously, you'd better have both a clear statement of why your protocol is an improvement over those in the existing literature, and some kind of proof of security under an appropriate model. Key agreement turns out to be a surprisingly hard problem, especially in any context that's to be used in a real protocol. (For evidence of this, you need look no further than the fact that research papers on the subject are still being written and published in competitive conferences and journals). Even defining the security model under which such protocols should be analyzed is a hard problem and the subject of current research. It is probably no longer acceptable, as it was just a few years ago, to throw together an ad-hoc authentication or key agreement protocol based on informal obvious security properties, without a strong proof of security and a clear statement of the model under which the security holds. For some recent relevant papers, see the ACM-CCS '02 paper my colleagues and I wrote on our JFK protocol (http://www.crypto.com/papers/jfk-ccs.ppt), and Ran Canetti and Hugo Krawczyk's several recent papers on the design and analysis of various IPSEC key exchange protocols (especially their CRYPTO'02 paper). -matt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to Linux's answer to MS-PPTP
Guus Sliepen [EMAIL PROTECTED] writes: On Mon, Sep 29, 2003 at 07:53:29AM -0700, Eric Rescorla wrote: I'm trying to figure out why you want to invent a new authentication protocol rather than just going back to the literature and ripping off one of the many skeletons that already exist ( Several reasons. Because it's fun, because we learn more from doing it ourselves (we learn from our mistakes too), because we want something that fits our needs. We could've just grabbed one from the shelf, but then we could also have grabbed IPsec or PPP-over-SSH from the shelf, instead of writing our own VPN daemon. However, we wanted something different. And I'm trying to understand why. This answer sounds a lot like NIH. Was there any technical reason why the existing cryptographic skeletons wouldn't have been just as good? STS, If you mean station-to-station protocol, then actually that is pretty much what we are doing now, except for encrypting instead of signing using RSA. But that's not a harmless change, which is the point of the potential attack I just described. JFK, IKE, SKEME, SIGMA, etc.). And I just ripped TLS from the list. Define ripped. This certainly is not the same as TLS. That would save people from the trouble of having to analyze the details of your new protoocl. Several people on this list have already demonstrated that they are very willing to analyse new protocols. Actually, no. People are willing to take a quick look and then shoot bullets at your protocol. That's not the same as doing a thorough analysis, which can take years, as Steve Bellovin has pointed out about Needham-Schroeder. Why are you using RSA encryption to authenticate your DH rather than using RSA signature? If we use RSA encryption, then both sides know their message can only be received by the intended recipient. If we use RSA signing, then we both sides know the message they receive can only come from the assumed sender. For the purpose of tinc's authentication protocol, I don't see the difference, but... There's no difference if it's done correctly. If it's not done correctly... Now, the attacker chooses 0 as his DH public. This makes ZZ always equal to zero, no matter what the peer's DH key is. I think you mean it is equal to 1 (X^0 is always 1). This is the first time I've heard of this, I've never thought of this myself. In that case I see the point of signing instead of encrypting. Except that the way you compute DH is to do Y^X rather than X^Y. Look, there's nothing wrong with trying to invent new protocols, especially as a learning experience. What I'm trying to figure out is why you would put them in a piece of software rather than using one that has undergone substantial analysis unless your new protocol has some actual advantages. Does it? -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
M Taylor [EMAIL PROTECTED] writes: On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote: Both SSL and SSH have had their security problems . . , as perfect as Peter Gutmann would let us believe. They may not be perfect but in neither case can Mallet do as much damage as easily, even the recent break in OpenSSH did not allow a compromise as big as even the smallest of the problems briefly explored in tinc. Oh, and they fixed their flaws. SSHv1 is not recommended for use at all, and most systems use SSHv2 now which is based upon a draft IETF standard. SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF standard. Nitpicking alert: Draft Standard is the technical term for the second tier of IETF standardization. (Proposed, Draft, Full). The term for something that has not yet been approved and given an RFC # is Internet Draft. SSHv2 and TLSv1.1 are Internet Drafts. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote: Perhaps a HMAC per chunk, rather than per the payload of a single UDP datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of payload may work. This will increase latency. That would not work either. It would have the same problems as a packet that has been split into 5 fragments: if one of the fragments gets lost, the whole packet will be discarded. Fragment reassembly is also something that is not completely trivial, in the past there have been some simple DoS attacks for various operating systems that did not implement IP fragment reassembly correctly. Each UDP packet must stand on its own, just like the network packet that has been encapsulated within it. This should be redone from scratch, I would look at either using Diffie Hellman Key Exchange combined with digital signatures or the updated Needham Schroeder Public Key Protocol. Exchange two symmetric keys, one used for bulk data encryption, the other used for the HMAC authentication. I think I prefer the Diffie-Hellman key exchange; the Needham Schroeder public key protocol needs more round trips and one more RSA encryption/decryption step. I expect this is a reference to Why TCP Over TCP Is A Bad Idea http://sites.inka.de/~bigred/devel/tcp-tcp.html Yes. If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their high tolerance for unncessary weakness, I think tinc 2.0 could end up being a secure piece of software. I hope Guus and Ivo circulate their version 2.0 protocol before they do any coding, so that any remaining flaws can be easily fixed in the paper design without changing a single line of code, saving time and effort. Those are the first encouraging words I've heard since Peter Gutmann's writeup was posted on Slashdot, thank you! We do plan to get rid of all the weaknesses, and once we know what we want and we have a draft, I'll post it in this mailing list. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tinc's response to Linux's answer to MS-PPTP
M Taylor wrote: Oh, and they fixed their flaws. SSHv1 is not recommended for use at all, and most systems use SSHv2 now which is based upon a draft IETF standard. SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF standard. It is curious, is it not, that there has been no well written protocol that became successful on its first attempt? And, contrariwise, all successful systems started out with crypto that slept shamefully with ROT13. If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their high tolerance for unncessary weakness, I think tinc 2.0 could end up being a secure piece of software. I hope Guus and Ivo circulate their version 2.0 protocol before they do any coding, so that any remaining flaws can be easily fixed in the paper design without changing a single line of code, saving time and effort. This is the best thing written so far. Even if Guus and Ivo were not to distribute their designs for 2.0, I would salute their efforts so far. It is clear that they have users. Hoorah! I say. It is clear that they have successfully enabled millions of VPN connections. There art we happy! It is fair to say that through their efforts, many hundreds or thousands of Linux boxen have escaped becoming part of the lamented and hacked 43,000. A pack of blessings light upon the backs of cryptographers! The notion that Guus and Ivo have done anything in the slightest sense, wrong, is mysterious to me. It defies explanation. They built a product. They protected users. Now, later on, after *proving* the product meets the needs of the market place, is the time to clean up the stopgap home-brewed crypto. It's not the most urgent thing. Only if the product is under sustained and unavoidable attack by the bad guys - like HTTPS - is it urgent to get in there and fix the security. And from the absence of any commentary on actual attacks, there seems all the time in Mantua to prepare a killer 2.0 crypto layer. Or am I missing something? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: efficiency?? vs security with symmetric crypto? (Re: Tinc's response to Linux's answer to MS-PPTP)
Adam Back wrote: What conceivable trade-offs could you have to make to get acceptable performance out of symmetric crypto encrypted+authenticated tunnel? All ciphers you should be using are like 50MB/sec on a 1Ghz machine!! There's fairly detailed performance data for Linux FreeS/WAN IPsec http://www.freeswan.org/freeswan_trees/freeswan-2.02/doc/performance.html It's around 50 M bit/second on a GHz machine with 3DES. You can roughly double that with AES. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote: I would have CC'd the author of the response page, but it fails to mention an author, in spite of the Comments are welcome statement at the beginning. There is a Contact link left of it. You could've replied to me as well. Truncated MAC tinc will continue to use only the first 32 bits by default. Simply put this is unacceptable from a security standpoint. The view taken is that the extra 128 bits represents a significant overhead in the communication. So I did the math, sending the extra 128 bits over a 52kbs would take 0.002 seconds, and over a T1 the time cost is an absolutely enormous 0.8 seconds. It is not the delay that matters, it is the bandwidth that is reduced. And by enlarging the packets, the chance that they will be fragmented is greater, which is also bad for performance. Some people want less overhead instead of more security, silly as that may sound to you. The other consideration is the potentially the computation time argument, but SHA-1 is used regardless, the computation time is identical. There is no justification in even a dialup environment for not using the full HMAC. For those who can't even spare the computation time, tinc allows you to disable HMAC completely. A message is sent which has the same length as the RSA key, and is completely filled . . .using real random data (OpenSSL's RAND_bytes()). I really wish people would actually read documentation *before* making stupid claims like this, in fact to quote the OpenSSL docs These functions implement a cryptographically secure pseudo-random number generator (PRNG). Any claim that OpenSSL implements a real random number generator are completely false. Ok, I guess you can read that sentence in that way. But what you cut out was: with the output of a PRNG which is seeded And I meant that PRNG which is seeded using ... with RAND_bytes(). And by seeding it with real random data I mean seeding using /dev/random. [...] What you're missing is that the connection iniator sets all the keys and can determine all the keys (assuming the uncontested simplified message flow is correct). Mallet can very easily perform a complete man-in-the-middle attack Your assumption that the connection initiator sets all the keys in tinc is wrong. [...] planned for tinc 2.0. My guess is that you will once again use it in an insecure method, use either signed ephemeral keys, or introduce randomness form both sides, otherwise you will have the same problems from slightly different angles. Finally, some constructive arguments. We are indeed considering the things you mention. We might even switch to TLS for the TCP connections. [...] - Don't act as an oracle for an attacker. Apart from possibly being susceptible to a timing attack, we don't believe, and Peter Gutmann has not convinced us, that tinc can be used as any other kind of oracle. You provide all the chosen ciphertext information Mallet could want. You act as an oracle. You can only provide so much ciphertext as an attacker before the connection is closed. I do not see how this is different from, say, SSL. What information can be obtained from our alledged oracle (apart from being a timing oracle)? Furthermore, SSL and SSH are reliable stream based protocols, unsuitable for VPNs Someone doesn't pay much attention to what they write. Both SSL and SSH _ARE_ VPN protocols, that you don't recognise them as such reflects a great deal on lack of knowledge in the area of security. [VPNs] work best with unreliable datagrams U, do you realize how dumb that sounds? I'm afraid we have totally different views of a VPN here. Anyway, tunneling traffic over SSH or an SSL connection would give us the awful performance of TCP-over-TCP, which we want to avoid. Apart from that, there is no reason why people shouldn't create new protocols, which might in time become just as strong or even stronger. Even great names as Ron Rivest didn't get it right the first time. Yeah but the great names admit they are wrong, and fix things. You have instead taken every possible moment to insist that tinc is good, something that even the barest educated layperson can see is simply and completely false. When our response says Will be fixed in 2.0 multiple times, does that sound like we don't think Peter Gutmann has valid points and that we won't fix things? I think here Gutmann went a bit overboard in his recommendation, but regardless the idea that someone should replace SSH/SSL with something designed by an amateur without the knowledge necessary to make it correct is a bad idea. In fact I have several years of experience and I have a potential replacement protocol that I think may in some cases be better than SSL/SSH, even with my experience I have held off publishing it for about 4 years now while I verify that it will in fact stand up to attack. How long was it
Re: Tinc's response to Linux's answer to MS-PPTP
On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote: Truncated MAC tinc will continue to use only the first 32 bits by default. Simply put this is unacceptable from a security standpoint. The view taken is that the extra 128 bits represents a significant overhead in the communication. So I did the math, sending the extra 128 bits over a 52kbs It appears Guus Sliepen (and/or Ivo Timmermans) are worried about the tinc protocol overhead per packet. This reduces the size of the data payload per packet, which could impact perforcemance due to IP fragmentation. Because the IP packet length is often restricted due to Ethernet frame size (1500 bytes), it can is more efficient to design the protocol so each UDP datagram is a full IP packet (1500 bytes Ethernet frame minus the 20 bytes for IP header, and 8 bytes for the UDP header) with a payload of 1472 bytes. Perhaps a HMAC per chunk, rather than per the payload of a single UDP datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of payload may work. This will increase latency. Authentication protocol This should be redone from scratch, I would look at either using Diffie Hellman Key Exchange combined with digital signatures or the updated Needham Schroeder Public Key Protocol. Exchange two symmetric keys, one used for bulk data encryption, the other used for the HMAC authentication. [VPNs] work best with unreliable datagrams U, do you realize how dumb that sounds? I expect this is a reference to Why TCP Over TCP Is A Bad Idea http://sites.inka.de/~bigred/devel/tcp-tcp.html Both SSL and SSH have had their security problems . . , as perfect as Peter Gutmann would let us believe. They may not be perfect but in neither case can Mallet do as much damage as easily, even the recent break in OpenSSH did not allow a compromise as big as even the smallest of the problems briefly explored in tinc. Oh, and they fixed their flaws. SSHv1 is not recommended for use at all, and most systems use SSHv2 now which is based upon a draft IETF standard. SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF standard. If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their high tolerance for unncessary weakness, I think tinc 2.0 could end up being a secure piece of software. I hope Guus and Ivo circulate their version 2.0 protocol before they do any coding, so that any remaining flaws can be easily fixed in the paper design without changing a single line of code, saving time and effort. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Tinc's response to Linux's answer to MS-PPTP
Hello Peter Gutmann and others, Because of its appearance on this mailing list and the Slashdot posting about Linux's answer to MS-PPTP, and in the tinc users' interest, we have created a section about the current security issues in tinc, which currently contains a response to Peter Gutmann's writeup: http://tinc.nl.linux.org/security I want to emphasize for the cryptography community here that certain tradeoffs have been made between security and efficiency in tinc. So please read the response as why we think we need to do/used to do it this way instead of why we think tinc is still as secure as anything else. Comments are welcome. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
efficiency?? vs security with symmetric crypto? (Re: Tinc's response to Linux's answer to MS-PPTP)
What conceivable trade-offs could you have to make to get acceptable performance out of symmetric crypto encrypted+authenticated tunnel? All ciphers you should be using are like 50MB/sec on a 1Ghz machine!! If you look at eg cebolla (more anonymity than VPN, but it's a nested forward-secret VPN related thing) it's even possible to do pretty immediate forward secrecy every second or something at minimal CPU cost. (I'll read the writeup but that trade-off argument sounds very wrong.) Adam On Fri, Sep 26, 2003 at 12:12:03PM +0200, Guus Sliepen wrote: Hello Peter Gutmann and others, Because of its appearance on this mailing list and the Slashdot posting about Linux's answer to MS-PPTP, and in the tinc users' interest, we have created a section about the current security issues in tinc, which currently contains a response to Peter Gutmann's writeup: http://tinc.nl.linux.org/security I want to emphasize for the cryptography community here that certain tradeoffs have been made between security and efficiency in tinc. So please read the response as why we think we need to do/used to do it this way instead of why we think tinc is still as secure as anything else. Comments are welcome. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
And a response. I have taken the liberty of copying the various portions of the contents of the webpage to this email for response. I apologize for the formatting confusion which may mistake Peter Gutmann's comments with those of the semi-anonymous misinformed person under scrutiny. I would have CC'd the author of the response page, but it fails to mention an author, in spite of the Comments are welcome statement at the beginning. On September the 15th Peter Gutmann contacted us and showed us part of a writeup which he posted to a cryptography mailing list on the 22th. In this writeup he identifies several security issues in CIPE, VTun and tinc. Below we will examine his findings and explain why some flaws or weaknesses Peter Gutmann found are in fact not a problem at all for a VPN daemon like tinc. As a reader you are ultimately left to draw your own conclusions, I encourage you to read all the arguments from both sides and, if possible, verify them by reading the documentation and source code of tinc. Comments are welcome. Predictable IV Proposed solution: provide the option of a full IV and move the sequence number out of the ciphertext, note that this is an _option_, instead of the necessary for security always. Truncated MAC tinc will continue to use only the first 32 bits by default. Simply put this is unacceptable from a security standpoint. The view taken is that the extra 128 bits represents a significant overhead in the communication. So I did the math, sending the extra 128 bits over a 52kbs would take 0.002 seconds, and over a T1 the time cost is an absolutely enormous 0.8 seconds. The other consideration is the potentially the computation time argument, but SHA-1 is used regardless, the computation time is identical. There is no justification in even a dialup environment for not using the full HMAC. Use of RSA Tinc uses RSA encryption only once, during authentication. sarcasm Yeah authentication is such a minor thing that major flaws are completely aceptable./sarcasm A message is sent which has the same length as the RSA key, and is completely filled . . .using real random data (OpenSSL's RAND_bytes()). I really wish people would actually read documentation *before* making stupid claims like this, in fact to quote the OpenSSL docs These functions implement a cryptographically secure pseudo-random number generator (PRNG). Any claim that OpenSSL implements a real random number generator are completely false. So, the message does not have low entropy and doesn't contain predictable bits. Read the docs, the message has 0 entropy (actually marginally above 0, but these are simple rounding errors), that's what a pseudo-random number generator means. However, there is no guarantee that the message was encrypted using the correct public key or that noone has tampered with it. This is of no concern for tinc though. There goes that authentication doesn't matter problem again, remind is tinc supposed to have any sembalnce of security? or is it just a stupid toy designed for young children to keep they're even younger siblings out of their personal matters? Part of the message is used as the key for the symmetric cipher that is used by the sender of this key to encrypt the rest of the messages it will send. A challenge-response exchange right after exchanging the RSA encrypted messages is done to ensure that both the sender of the symmetric cipher key has the right public key, the recipient has the right corresponding private key, and the message was not tampered with (because that would change the symmetric cipher key). Whoever designed and stated this has no idea about cryptographic security. Using a part of a shared secret, generated by a pRNG on only one side, introduces horrific flaws in the protocol. Pretending that poorly done RSA encryption magically solves the problem will only risk everything that has ever been encrypted using tinc. Authentication protocol First of all, we assume Mallet does not know the private keys of Bob and Alice (Bob and Alice are not compromised), and Bob and Alice do not know Mallet at all (they don't trust Mallet, otherwise he could've made a connection without having to resort to a cryptographic attack). Good luck keeping that assumption true, with the oracle attack listed above that won't stay true very long at all. First, keys for the symmetric cipher encryption are exchanged. Mallet cannot decrypt keys he gets from Bob and Alice, because he doesn't have their private keys. But he does, he spoofed each connection and acted as initiator for both, now it's a simple matter of resending. Your entire model is based on a misunderstanding of what RSA does and does not offer. What you're missing is that the connection iniator sets all the keys and can determine all the keys (assuming the uncontested simplified message flow is correct). Mallet can very easily perform a complete man-in-the-middle attack Configuration
