From bounce-ietf-tls-3458737@lists.certicom.com Thu Feb 1 04:41:23 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22405 for ; Thu, 1 Feb 2001 04:41:22 -0500 (EST) Message-ID: From: David Taylor To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Proposal: SRP authentication for TLS Date: Tue, 20 Jan 1998 20:39:11 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <01BD25E3.B05C8820@CWIP-T-003-p-213-233.tmns.net.au> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA22405 Following my message from yesterday, I have the proof of concept working. Here are some details of the changes I made to the handshake. I don't claim this is a secure solution, or that it is not open to attack - I would appreciate it if the list members would look over it and see where it needs to be improved, and whether it it worth pursuing. TLS Handshake Sequence ---------------------- Client Server | | Client Hello (U) ------------------------> | | <---------------------------- Server Hello | <---------------------------- Server Key Exchange (g, N, s) Client Key Exchange (A) -----------------> | | <---------------------------- Server Key Exchange (B) | <---------------------------- Server Hello Done change cipher spec | Finished --------------------------------> | | change cipher spec | <---------------------------- Finished | | The identifiers in () refer to variables defined in RFC-2945. This new handshake sequence has a number of differences from the standard TLS handshake sequence: o The client hello message has the user name appended to the message. This is allowable as stated in section 7.4.1.2 of RFC-2246. o The client must respond with a message before it receives the server hello done message, due to the data exchange sequence requirements stated in section 3 of RFC-2945: The server cannot send B until it has received A from the client. If this was not the case, the server could send B in the first server key exchange message. o The server key exchange message is sent twice, due to the reasons stated above. o The client and server messages are now interleaved due to the reasons stated above. o There is no server authentication in this version of a TLS handshake. The Client Hello Message ------------------------ Appended to the standard client hello message is the user name. This is encoded as: opaque username<1..2^8-1> This data will be included in the record length, so the server knows to read it. The Server Key Exchange Messages -------------------------------- The server key exchange message in the first round contains the generator (g), the prime (N), and the salt value read from the "password" file. The server key exchange message in the second round contains the servers ephemeral public key (B). The associated data structures are modified as follows: enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm; enum { first, second } KeyExchangeRound; struct { select (KeyExchangeRound) { case first: opaque srp_salt<1..2^8-1> opaque srp_N<1..2^16-1>; opaque srp_g<1..2^16-1>; case second: opaque srp_b<1..2^16-1>; }; } ServerSRPParams; /* SRP parameters */ srp_N The prime modulus used for the SRP operation. srp_g The generator used for the SRP operation. srp_b The servers ephemeral public key. struct { select (KeyExchangeAlgorithm) { case diffie_hellman: ServerDHParams params; Signature signed_params; case rsa: ServerRSAParams params; Signature signed_params; case srp: ServerSRPParams params; }; } ServerKeyExchange; The Client Key Exchange Messages -------------------------------- The client key exchange message for the first round carries the clients ephemeral public key (A), which is calculated using information known locally and received in the first server key exchange message. This message must be sent between the first and second server key exchange messages. The associated data structures are modified as follows: struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; case srp: SRPClientEphemeralPublic; } exchange_keys; } ClientKeyExchange; struct { opaque srp_A<1..2^16-1>; } SRPClientEphemeralPublic; The Pre-Master Secret --------------------- After the second server key exchange message, both sides have enough information to calculate the shared secret. If this is sent through the interleaved SHA-1 hash function as explained in 3.1 of RFC-2945, it is suitable for use as a pre-master secret. Cipher Suites ------------- CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_SHA = { 0x00,0x31 }; CipherSuite TLS_SRP_WITH_RC4_128_SHA = { 0x00,0x32 }; CipherSuite TLS_SRP_WITH_IDEA_CBC_SHA = { 0x00,0x33 }; CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x35 }; CipherSuite TLS_SRP_WITH_RC4_128_MD5 = { 0x00,0x36 }; CipherSuite TLS_SRP_WITH_IDEA_CBC_MD5 = { 0x00,0x37 }; These numbers are for example only, and will be changed to something more appropriate. Regards, David Taylor. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Feb 1 07:37:01 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24864 for ; Thu, 1 Feb 2001 07:37:00 -0500 (EST) Date: Thu, 1 Feb 2001 12:36:48 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] New AES ciphersuite draft Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010201123647.B2133@hyena.skygate.co.uk> X-List-Host: SKYLIST.net I have put together a new AES ciphersuite draft, which will be published by IETF shortly. In the meantime you can see it at: ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-ietf-tls-ciphersuite-03.txt My main aim has been to bring the draft into line with the decisions taken at the last IETF meeting. This means that: 1. There are now no mandatory ciphersuites. I agree with this decision because while it is sub-optimal in a way, I doubt that consensus could ever have been achieved. 2. 256-bit ciphersuites are now included. I have also fixed some minor issues which were sent to me in private mail. -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Feb 2 08:07:09 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07209 for ; Fri, 2 Feb 2001 08:07:08 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ciphersuite-03.txt Date: Fri, 02 Feb 2001 08:06:50 -0500 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200102021306.IAA07174@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : AES Ciphersuites for TLS Author(s) : P. Chown Filename : draft-ietf-tls-ciphersuite-03.txt Pages : 8 Date : 01-Feb-01 At present, the symmetric ciphers supported by TLS are RC2, RC4, IDEA, DES and triple DES. The protocol would be enhanced by the addition of AES [AES] ciphersuites, for the following reasons: 1. RC2, RC4 and IDEA are all subject to intellectual property claims. RSA Security Inc has trademark rights in the names RC2 and RC4, and claims that the RC4 algorithm itself is a trade secret. Ascom Systec Ltd owns a patent on the IDEA algorithm. 2. Triple DES is much less efficient than more modern ciphers. 3. Now the AES process is completed there will be commercial pres¡ sure to use the selected cipher. The AES is efficient and has withstood extensive cryptanalytic efforts. The AES is therefore a desirable choice. 4. Currently the DHE ciphersuites only allow triple DES (along with some ``export'' variants which offer reduced key lengths). At the same time the DHE ciphersuites are the only ones to offer forward secrecy. This document proposes two new ciphersuites, with the aim of over¡ coming these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ciphersuite-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ciphersuite-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010201080732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ciphersuite-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ciphersuite-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010201080732.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Fri Feb 9 13:24:10 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27623 for ; Fri, 9 Feb 2001 13:24:08 -0500 (EST) Message-ID: From: "Walker, Jesse" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Query on draft-ietf-tls-ciphersuite-03.txt Date: Fri, 9 Feb 2001 10:23:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <10C8636AE359D4119118009027AE9987064C42CD@FMSMSX34> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net The document specifies CBC mode for 128- and 256-bit AES. Why? Why not counter mode? It appears TLS could experience a big boost in performance without sacrificing any security by changing this. Feedback modes like CBC squander AES's ability to exploit the parallelism available in modern processors, while counter mode is fully parallizable; and TLS seems to have the right properties to make counter mode just as safe as CBC mode. I don't understand what tradeoffs have led to the selection of CBC mode. -- Jesse --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Feb 9 17:47:33 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04063 for ; Fri, 9 Feb 2001 17:47:32 -0500 (EST) Message-ID: Date: Fri, 09 Feb 2001 22:47:36 +0000 From: David Hopwood Reply-To: "IETF Transport Layer Security WG" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Query on draft-ietf-tls-ciphersuite-03.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A847388.52DD1078@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- "Walker, Jesse" wrote: > The document specifies CBC mode for 128- and 256-bit AES. Why? Why not > counter mode? It appears TLS could experience a big boost in performance > without sacrificing any security by changing this. Not really, because HMAC is still not parallelisable. IMHO we should wait until there is a good candidate for a fully parallelisable ciphersuite. Several possible candidate modes were presented at the AES modes conference (see http://csrc.nist.gov/encryption/modes/ and http://csrc.nist.gov/encryption/modes/workshop1/), but they should really have a bit more analysis, as well as sorting out patent issues in some cases. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOoRzXjkCAxeYt5gVAQF51QgAqDV2Emwlg4mcGlAjye51ZAbhJwJAbbz5 rEuIyh0zkVO8LNoKvEE7GFd2mS6jGVKcga7JjxgKS8YCY5Ywha+zcJocV++wqqi6 xr9LB5hRk3ddvs6hcGbcXpRP6IsUE/YqpyouKfJnMJdhUlxo3Od12h4cPKmSv6qi agzmqfgwbPcME155c4oistXXw1GtHMyvovAtqtcwENfaqgmB8tzXTOAamPYPcEaQ UQszpDvL8rGOF6ACm4kc076Pkou3K8D37cncjAFp7ApreVg6o4jpyQcc2++W9tkc 5OE6LVxC11eyFriz+nfUxzlzoT6noMHZ0IOvc0Hvpo/wl2aZsJdRug== =Mvpt -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Feb 21 19:00:35 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14429 for ; Wed, 21 Feb 2001 19:00:33 -0500 (EST) X-Lotus-FromDomain: 3COM From: Areg_Alimian@3com.com To: "IETF Transport Layer Security WG" Message-ID: Date: Wed, 21 Feb 2001 16:02:04 -0800 Subject: [ietf-tls] Use of TLS for authentication/encryption in wireless( LANS ) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <882569FB.00002608.00@hqoutbound.ops.3com.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi All, Can you point me to any comprehensive references/books on use of TLS for authentication of wireless clients/servers in a WLAN? Thank you, Areg Alimian --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Feb 27 14:53:27 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26555 for ; Tue, 27 Feb 2001 14:53:26 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] TLS: no meeting in Minneapolis Date: Tue, 27 Feb 2001 14:45:07 -0500 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200102271945.f1RJjC104987@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Just so everyone knows, the TLS working group will not be meeting in Minneapolis. - Win Treese --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com