From owner-ietf-sasl Sun Feb 11 12:26:01 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA23147 for ietf-sasl-bks; Sun, 11 Feb 2001 12:26:01 -0800 (PST) Received: from rucus.ru.ac.za (qmailr@rucus.ru.ac.za [146.231.29.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA23143 for ; Sun, 11 Feb 2001 12:25:57 -0800 (PST) Received: (qmail 21209 invoked by uid 283); 11 Feb 2001 20:19:11 -0000 Date: Sun, 11 Feb 2001 22:19:11 +0200 From: Keith Burdis To: ietf-sasl@imc.org Subject: SRP SASL draft Message-ID: <20010211221911.A76605@rucus.ru.ac.za> Mail-Followup-To: Keith Burdis , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Time for something on this list other than SPAM :-) As some of you may have noticed a new version of the SRP SASL mechanism draft is out: draft-burdis-cat-srp-sasl-04.txt The most important thing about this draft is that I now have a co-author (Raif Naffah from Down Under) and the draft is the better for it. In particular, Raif should get credit for improvements in the mechanism element encodings and in how the security layer works, as well as many of the changes below. Here are some of the changes: - Describes a family of SASL mechanisms based on SRP. Each actual mechanism can use a different underlying one-way function. Previously only SRP-SHA1 was supported. - Dropped the use of Netstrings in favour of encodings that prepend the length of the following field using a fixed number of bytes. - Changed the authentication protocol so that the client sends its username as the first message in the protocol exchange. This allows the server to have a different exponent and generator for each client. The cost of the extra message can be eliminated by having the client send it as part of its initial response. - Changed the mandatory confidentiality algorithm (when confidentiality protection is supported) from Blowfish to AES (Rijndael). Designated that block ciphers should use OFB (Output Feedback Block) mode with PKCS #7 padding. - The security layer is now much more clearly explained as a three-stage filter consisting of the confidentiality protection, replay detection and integrity protection stages, which may be inactive. Raif and I have also released a new version of the Cryptix SASL library that implements the Java SASL bindings and some SASL mechanisms, including this one. http://www.cryptix.org/~keith/0_8_5/ We'd appreciate any comments, criticism, or suggestions any of you might have. Thanks. - Keith PS: Sorry Paul, I haven't got any further with the Digest implementation :( -- Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa IRC: Panthras JAPH QEFH --- From owner-ietf-sasl Thu Feb 22 09:17:42 2001 Received: by above.proper.com (8.9.3/8.9.3) id JAA22989 for ietf-sasl-bks; Thu, 22 Feb 2001 09:17:42 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA22985 for ; Thu, 22 Feb 2001 09:17:40 -0800 (PST) Received: (qmail 58545 invoked from network); 22 Feb 2001 17:17:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 22 Feb 2001 17:17:40 -0000 Received: (qmail 11208 invoked by uid 1183); 22 Feb 2001 17:17:38 -0000 Date: Thu, 22 Feb 2001 18:17:38 +0100 (MET) From: Magnus Nystrom X-Sender: Reply-To: Magnus Nystrom To: cc: Subject: I-D Action: draft-nystrom-http-sasl-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id JAA22986 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear mailinglist members, The above mentioned draft is now available for your review. While it is possible that some time will be spent on this during the SAAG at the upcoming IETF Minneapolis meeting, we certainly would appreciate your comments and suggestions. Thanks, -- Magnus Magnus Nyström RSA Security From owner-ietf-sasl Sun Feb 25 11:52:15 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA01271 for ietf-sasl-bks; Sun, 25 Feb 2001 11:52:15 -0800 (PST) Received: from rucus.ru.ac.za (qmailr@rucus.ru.ac.za [146.231.29.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA01264 for ; Sun, 25 Feb 2001 11:52:10 -0800 (PST) Received: (qmail 64011 invoked by uid 283); 25 Feb 2001 19:51:50 -0000 Date: Sun, 25 Feb 2001 21:51:50 +0200 From: Keith Burdis To: ietf-sasl@imc.org, saag@lists.tislabs.com Subject: HTTP over SASL Message-ID: <20010225215150.A51335@rucus.ru.ac.za> Mail-Followup-To: Keith Burdis , ietf-sasl@imc.org, saag@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Magnus Nystrom and Robert Zuccherato have submitted a proposal for using SASL with HTTP (draft-nystrom-http-sasl-00). I have an alternative proposal based on RFC 2817 "Upgrading to TLS Within HTTP/1.1". RFC 2817 describes a means of using TLS with HTTP by upgrading to TLS from within HTTP. The advantage of this is that a separate port is not required for a secure connection. Once the upgrade is initiated the TLS protocol starts. If TLS authentication is successful, a secure connection is established and subsequent HTTP messages are tunnelled through this connection. The same procedure can be used with SASL. An HTTP client and server negotiate an upgrade to an SASL mechanism. Once the upgrade is initiated, the SASL mechanism protocol starts. If the authentication procedure using this mechanism is successful, subsequent HTTP messages are tunnelled through this SASL connection. If a security layer was negotiated as part of the SASL mechanism exchange then it is used to protect any messages passing through the connection, otherwise the messages are passed through unchanged. The benefit of tunnelling HTTP through an SASL connection, rather than making the SASL exchange part of HTTP, is that the TCP connection is protected. This means that the entire HTTP message is protected when transmitted along this connection rather than just the HTTP body. Also, as with TLS, once the upgrade has taken place, the HTTP protocol exchanges continue unaware that they are being protected. A copy of the full proposal is available at: http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.html http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.txt Any comments are welcome. Thanks. - Keith -- Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa IRC: Panthras JAPH QEFH --- From owner-ietf-sasl Sun Feb 11 12:26:01 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA23147 for ietf-sasl-bks; Sun, 11 Feb 2001 12:26:01 -0800 (PST) Received: from rucus.ru.ac.za (qmailr@rucus.ru.ac.za [146.231.29.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA23143 for ; Sun, 11 Feb 2001 12:25:57 -0800 (PST) Received: (qmail 21209 invoked by uid 283); 11 Feb 2001 20:19:11 -0000 Date: Sun, 11 Feb 2001 22:19:11 +0200 From: Keith Burdis To: ietf-sasl@imc.org Subject: SRP SASL draft Message-ID: <20010211221911.A76605@rucus.ru.ac.za> Mail-Followup-To: Keith Burdis , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Time for something on this list other than SPAM :-) As some of you may have noticed a new version of the SRP SASL mechanism draft is out: draft-burdis-cat-srp-sasl-04.txt The most important thing about this draft is that I now have a co-author (Raif Naffah from Down Under) and the draft is the better for it. In particular, Raif should get credit for improvements in the mechanism element encodings and in how the security layer works, as well as many of the changes below. Here are some of the changes: - Describes a family of SASL mechanisms based on SRP. Each actual mechanism can use a different underlying one-way function. Previously only SRP-SHA1 was supported. - Dropped the use of Netstrings in favour of encodings that prepend the length of the following field using a fixed number of bytes. - Changed the authentication protocol so that the client sends its username as the first message in the protocol exchange. This allows the server to have a different exponent and generator for each client. The cost of the extra message can be eliminated by having the client send it as part of its initial response. - Changed the mandatory confidentiality algorithm (when confidentiality protection is supported) from Blowfish to AES (Rijndael). Designated that block ciphers should use OFB (Output Feedback Block) mode with PKCS #7 padding. - The security layer is now much more clearly explained as a three-stage filter consisting of the confidentiality protection, replay detection and integrity protection stages, which may be inactive. Raif and I have also released a new version of the Cryptix SASL library that implements the Java SASL bindings and some SASL mechanisms, including this one. http://www.cryptix.org/~keith/0_8_5/ We'd appreciate any comments, criticism, or suggestions any of you might have. Thanks. - Keith PS: Sorry Paul, I haven't got any further with the Digest implementation :( -- Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa IRC: Panthras JAPH QEFH --- From owner-ietf-sasl Thu Feb 22 09:17:42 2001 Received: by above.proper.com (8.9.3/8.9.3) id JAA22989 for ietf-sasl-bks; Thu, 22 Feb 2001 09:17:42 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA22985 for ; Thu, 22 Feb 2001 09:17:40 -0800 (PST) Received: (qmail 58545 invoked from network); 22 Feb 2001 17:17:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 22 Feb 2001 17:17:40 -0000 Received: (qmail 11208 invoked by uid 1183); 22 Feb 2001 17:17:38 -0000 Date: Thu, 22 Feb 2001 18:17:38 +0100 (MET) From: Magnus Nystrom X-Sender: Reply-To: Magnus Nystrom To: cc: Subject: I-D Action: draft-nystrom-http-sasl-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id JAA22986 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear mailinglist members, The above mentioned draft is now available for your review. While it is possible that some time will be spent on this during the SAAG at the upcoming IETF Minneapolis meeting, we certainly would appreciate your comments and suggestions. Thanks, -- Magnus Magnus Nyström RSA Security From owner-ietf-sasl Sun Feb 25 11:52:15 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA01271 for ietf-sasl-bks; Sun, 25 Feb 2001 11:52:15 -0800 (PST) Received: from rucus.ru.ac.za (qmailr@rucus.ru.ac.za [146.231.29.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA01264 for ; Sun, 25 Feb 2001 11:52:10 -0800 (PST) Received: (qmail 64011 invoked by uid 283); 25 Feb 2001 19:51:50 -0000 Date: Sun, 25 Feb 2001 21:51:50 +0200 From: Keith Burdis To: ietf-sasl@imc.org, saag@lists.tislabs.com Subject: HTTP over SASL Message-ID: <20010225215150.A51335@rucus.ru.ac.za> Mail-Followup-To: Keith Burdis , ietf-sasl@imc.org, saag@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Magnus Nystrom and Robert Zuccherato have submitted a proposal for using SASL with HTTP (draft-nystrom-http-sasl-00). I have an alternative proposal based on RFC 2817 "Upgrading to TLS Within HTTP/1.1". RFC 2817 describes a means of using TLS with HTTP by upgrading to TLS from within HTTP. The advantage of this is that a separate port is not required for a secure connection. Once the upgrade is initiated the TLS protocol starts. If TLS authentication is successful, a secure connection is established and subsequent HTTP messages are tunnelled through this connection. The same procedure can be used with SASL. An HTTP client and server negotiate an upgrade to an SASL mechanism. Once the upgrade is initiated, the SASL mechanism protocol starts. If the authentication procedure using this mechanism is successful, subsequent HTTP messages are tunnelled through this SASL connection. If a security layer was negotiated as part of the SASL mechanism exchange then it is used to protect any messages passing through the connection, otherwise the messages are passed through unchanged. The benefit of tunnelling HTTP through an SASL connection, rather than making the SASL exchange part of HTTP, is that the TCP connection is protected. This means that the entire HTTP message is protected when transmitted along this connection rather than just the HTTP body. Also, as with TLS, once the upgrade has taken place, the HTTP protocol exchanges continue unaware that they are being protected. A copy of the full proposal is available at: http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.html http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.txt Any comments are welcome. Thanks. - Keith -- Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa IRC: Panthras JAPH QEFH --- Received: by above.proper.com (8.9.3/8.9.3) id LAA01271 for ietf-sasl-bks; Sun, 25 Feb 2001 11:52:15 -0800 (PST) Received: from rucus.ru.ac.za (qmailr@rucus.ru.ac.za [146.231.29.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA01264 for ; Sun, 25 Feb 2001 11:52:10 -0800 (PST) Received: (qmail 64011 invoked by uid 283); 25 Feb 2001 19:51:50 -0000 Date: Sun, 25 Feb 2001 21:51:50 +0200 From: Keith Burdis To: ietf-sasl@imc.org, saag@lists.tislabs.com Subject: HTTP over SASL Message-ID: <20010225215150.A51335@rucus.ru.ac.za> Mail-Followup-To: Keith Burdis , ietf-sasl@imc.org, saag@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Magnus Nystrom and Robert Zuccherato have submitted a proposal for using SASL with HTTP (draft-nystrom-http-sasl-00). I have an alternative proposal based on RFC 2817 "Upgrading to TLS Within HTTP/1.1". RFC 2817 describes a means of using TLS with HTTP by upgrading to TLS from within HTTP. The advantage of this is that a separate port is not required for a secure connection. Once the upgrade is initiated the TLS protocol starts. If TLS authentication is successful, a secure connection is established and subsequent HTTP messages are tunnelled through this connection. The same procedure can be used with SASL. An HTTP client and server negotiate an upgrade to an SASL mechanism. Once the upgrade is initiated, the SASL mechanism protocol starts. If the authentication procedure using this mechanism is successful, subsequent HTTP messages are tunnelled through this SASL connection. If a security layer was negotiated as part of the SASL mechanism exchange then it is used to protect any messages passing through the connection, otherwise the messages are passed through unchanged. The benefit of tunnelling HTTP through an SASL connection, rather than making the SASL exchange part of HTTP, is that the TCP connection is protected. This means that the entire HTTP message is protected when transmitted along this connection rather than just the HTTP body. Also, as with TLS, once the upgrade has taken place, the HTTP protocol exchanges continue unaware that they are being protected. A copy of the full proposal is available at: http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.html http://www.cryptix.org/~keith/http-sasl/draft-burdis-http-sasl-00.txt Any comments are welcome. Thanks. - Keith -- Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa IRC: Panthras JAPH QEFH --- Received: by above.proper.com (8.9.3/8.9.3) id JAA22989 for ietf-sasl-bks; Thu, 22 Feb 2001 09:17:42 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA22985 for ; Thu, 22 Feb 2001 09:17:40 -0800 (PST) Received: (qmail 58545 invoked from network); 22 Feb 2001 17:17:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 22 Feb 2001 17:17:40 -0000 Received: (qmail 11208 invoked by uid 1183); 22 Feb 2001 17:17:38 -0000 Date: Thu, 22 Feb 2001 18:17:38 +0100 (MET) From: Magnus Nystrom X-Sender: Reply-To: Magnus Nystrom To: cc: Subject: I-D Action: draft-nystrom-http-sasl-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id JAA22986 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear mailinglist members, The above mentioned draft is now available for your review. While it is possible that some time will be spent on this during the SAAG at the upcoming IETF Minneapolis meeting, we certainly would appreciate your comments and suggestions. Thanks, -- Magnus Magnus Nyström RSA Security Received: by above.proper.com (8.9.3/8.9.3) id MAA23147 for ietf-sasl-bks; Sun, 11 Feb 2001 12:26:01 -0800 (PST) Received: from rucus.ru.ac.za (qmailr@rucus.ru.ac.za [146.231.29.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA23143 for ; Sun, 11 Feb 2001 12:25:57 -0800 (PST) Received: (qmail 21209 invoked by uid 283); 11 Feb 2001 20:19:11 -0000 Date: Sun, 11 Feb 2001 22:19:11 +0200 From: Keith Burdis To: ietf-sasl@imc.org Subject: SRP SASL draft Message-ID: <20010211221911.A76605@rucus.ru.ac.za> Mail-Followup-To: Keith Burdis , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Time for something on this list other than SPAM :-) As some of you may have noticed a new version of the SRP SASL mechanism draft is out: draft-burdis-cat-srp-sasl-04.txt The most important thing about this draft is that I now have a co-author (Raif Naffah from Down Under) and the draft is the better for it. In particular, Raif should get credit for improvements in the mechanism element encodings and in how the security layer works, as well as many of the changes below. Here are some of the changes: - Describes a family of SASL mechanisms based on SRP. Each actual mechanism can use a different underlying one-way function. Previously only SRP-SHA1 was supported. - Dropped the use of Netstrings in favour of encodings that prepend the length of the following field using a fixed number of bytes. - Changed the authentication protocol so that the client sends its username as the first message in the protocol exchange. This allows the server to have a different exponent and generator for each client. The cost of the extra message can be eliminated by having the client send it as part of its initial response. - Changed the mandatory confidentiality algorithm (when confidentiality protection is supported) from Blowfish to AES (Rijndael). Designated that block ciphers should use OFB (Output Feedback Block) mode with PKCS #7 padding. - The security layer is now much more clearly explained as a three-stage filter consisting of the confidentiality protection, replay detection and integrity protection stages, which may be inactive. Raif and I have also released a new version of the Cryptix SASL library that implements the Java SASL bindings and some SASL mechanisms, including this one. http://www.cryptix.org/~keith/0_8_5/ We'd appreciate any comments, criticism, or suggestions any of you might have. Thanks. - Keith PS: Sorry Paul, I haven't got any further with the Digest implementation :( -- Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa IRC: Panthras JAPH QEFH ---