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: 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"
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"
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"
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, 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]
New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote: > 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. I've been comparing tinc's current authentication protocol with the TLS handshake protocol as described in draft-ietf-tls-rfc2246-bis-05.txt. The basic structure is mostly the same: the ID messages in tinc are TLS's Hello messages, the METAKEY message in tinc is similar to TLS's RSA encrypted premaster secret message, the ChangeCipherSpec is implicit in tinc, and tinc's CHALLENGE/RESPONSE messages serve the same purpose as TLS's finished message (which contains verify_data). 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: == 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. Step 3: Exchange VERIFY messages. The VERIFY message contains verification data extracted from the master key, so each recipient can verify that the key exchange went well. Step 4: Exchange ACK messages. This will signal each side that the other side acknowledges the authentication. The ACK message will contain some more data which has nothing to do with authentication. == I currently think this has none of the problems the current protocol has, and also makes sure we have perfect forward security (if keys are renewed using Diffie-Hellman periodically). 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? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Can Eve repeat?
On Fri, 26 Sep 2003 09:10:05 -0400, Greg Troxel <[EMAIL PROTECTED]> wrote: [snip] The current canoncial paper on how to calculate the number of bits that must be hashed away due to detected eavesdropping and the inferred amount of undetected eavesdropping is "Defense frontier analysis of quantum cryptographic systems" by Slutsky et al: http://topaz.ucsd.edu/papers/defense.pdf Up-front disclaimer: I haven't had time to study this paper with the level of attention it likely deserves, so I apologize if the following contains incorrect logic. However, from glancing over it, it appears the assumptions on which the entire paper rests are undermined by work such as that of Elitzur and Vaidman (see the article I linked previously). Specifically, note the following: "This security is derived from encoding the data on nonorthogonal quantum states of a physical carrier particle. Since such quantum states cannot be duplicated or analyzed in transit without disturbing them, any attempt to interfere with the particle introduces transmission errors and thereby reveals itself to Alice and Bob." And: "They [Alice and Bob] then assume that all errors are eavesdropping induced and estimate Eve's potential knowledge of their data in this worst-case situation." If we do away with the idea that there are no interaction-free measurements (which was, at least to me, convincingly shown by the Quantum seeing in the dark article), this paper becomes considerably less useful; the first claim's validity is completely nullified (no longer does interference with particles necessarily introduce transmission errors), while the effect on the second statement is evil: employing the proposed key distillation techniques, the user might be given a (very) false sense of security, as only a small percentage of the particles that Eve observes register as transmission errors (<=15%, according to the LANL figure). Best regards, Ivan Krstic - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
