Subject: HTTP over SASL

From: Keith Burdis <[email-masked]>
Date: Sun, 25 Feb 2001 21:51:50 +0200

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
---

Date: Sun, 25 Feb 2001 21:51:50 +0200
From: Keith Burdis <[email-masked]>
To: [email-masked], [email-masked]
Subject: HTTP over SASL
Mail-Followup-To: Keith Burdis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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
---

Date: Thu, 22 Feb 2001 18:17:38 +0100 (MET)
From: Magnus Nystrom <[email-masked]>
Reply-To: Magnus Nystrom <[email-masked]>
To: <[email-masked]>
cc: <[email-masked]>
Subject: I-D Action: draft-nystrom-http-sasl-00.txt
Sender: [email-masked]

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

Date: Sun, 11 Feb 2001 22:19:11 +0200
From: Keith Burdis <[email-masked]>
To: [email-masked]
Subject: SRP SASL draft
Mail-Followup-To: Keith Burdis <[email-masked]>, [email-masked]
Sender: [email-masked]

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
---