From owner-ietf-sasl Sun Mar 2 17:03:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h2313pd26748 for ietf-sasl-bks; Sun, 2 Mar 2003 17:03:51 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h2313nY26744 for ; Sun, 2 Mar 2003 17:03:49 -0800 (PST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Mon, 3 Mar 2003 12:03:53 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hansen-sasl-pki-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Index: AcLfYI/CtyRFQhVfQdiIx7kpykYX/QBvmhAw From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , "Lawrence Greenfield" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2313oY26745 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Kurt, I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Saturday, 1 March 2003 06:22 To: Lawrence Greenfield Cc: tony@att.com; ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt At 11:02 AM 2/28/2003, Lawrence Greenfield wrote: > Date: Fri, 28 Feb 2003 10:06:54 -0800 > From: "Kurt D. Zeilenga" > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? > >You don't close TLS; you can renegotiate to the NULL cipher. Application-level protocols may permit use the stream after TLS closure. See RFC 2246, Section 7.2.1. LDAPv3 is an example, RFC 2830, of an application-level protocol which explicitly permits such use. Kurt From owner-ietf-sasl Sun Mar 2 17:19:14 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h231JEi26940 for ietf-sasl-bks; Sun, 2 Mar 2003 17:19:14 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h231JCY26935 for ; Sun, 2 Mar 2003 17:19:12 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h231J88q054126; Mon, 3 Mar 2003 01:19:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030302171418.02728f20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 02 Mar 2003 17:17:23 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: "Lawrence Greenfield" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:03 PM 3/2/2003, Ramsay, Ron wrote: >I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Good catch. I then say that the I-D should note that one of the reasons why TLS+SASL/PLAIN+closure is that application profiles of TLS define inconsistent TLS closure semantics. Kurt From owner-ietf-sasl Sun Mar 2 17:32:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h231WkF27164 for ietf-sasl-bks; Sun, 2 Mar 2003 17:32:46 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h231WjY27160 for ; Sun, 2 Mar 2003 17:32:45 -0800 (PST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Mon, 3 Mar 2003 12:32:49 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hansen-sasl-pki-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Index: AcLhIuxhiR6kYURFS8y1afstPqyX+gAAYnMg From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: "Lawrence Greenfield" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h231WjY27161 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, Kurt, you're the only one who has tried to make the TLS session transient. I go with the author who said it should last for the whole session. You don't put up an Aunt Sally just to knock it down again! Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, 3 March 2003 12:17 To: Ramsay, Ron Cc: Lawrence Greenfield; tony@att.com; ietf-sasl@imc.org Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt At 05:03 PM 3/2/2003, Ramsay, Ron wrote: >I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Good catch. I then say that the I-D should note that one of the reasons why TLS+SASL/PLAIN+closure is that application profiles of TLS define inconsistent TLS closure semantics. Kurt From owner-ietf-sasl Sun Mar 2 18:10:58 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h232Aw027942 for ietf-sasl-bks; Sun, 2 Mar 2003 18:10:58 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h232AuY27936 for ; Sun, 2 Mar 2003 18:10:56 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h232At8q054329; Mon, 3 Mar 2003 02:10:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030302173345.02722560@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 02 Mar 2003 18:09:10 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: "Lawrence Greenfield" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:32 PM 3/2/2003, Ramsay, Ron wrote: >Well, Kurt, you're the only one who has tried to make the TLS session transient. As I noted in my last response, it is now clear to me is that TLS+SASL/PLAIN+closure is not a viable approach. However, I content that it is not obviously so. TLS is transient by design. And application protocol profiles of TLS could be defined which support this approach. And existing TLS and SASL libraries would allow implementation of the approach. And there existing implementations of application protocols which do use this approach today. So, I think, my original question was quite reasonable to ask. Personally, I think the answer deserves brief mention in the I-D. Kurt From owner-ietf-sasl Wed Mar 5 03:32:35 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25BWZj10174 for ietf-sasl-bks; Wed, 5 Mar 2003 03:32:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25BWY310170 for ; Wed, 5 Mar 2003 03:32:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25941; Wed, 5 Mar 2003 06:30:19 -0500 (EST) Message-Id: <200303051130.GAA25941@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-http-wg@w3.org, ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-06.txt Date: Wed, 05 Mar 2003 06:30:19 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, R. Zuccherato, A. Melnikov Filename : draft-nystrom-http-sasl-06.txt Pages : 32 Date : 2003-3-4 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nystrom-http-sasl-06.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-nystrom-http-sasl-06.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: <2003-3-4174121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174121.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Mar 7 10:00:08 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27I08508303 for ietf-sasl-bks; Fri, 7 Mar 2003 10:00:08 -0800 (PST) Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by above.proper.com (8.11.6/8.11.6) with SMTP id h27I06308298 for ; Fri, 7 Mar 2003 10:00:07 -0800 (PST) Received: (covad.net 18605 invoked from network); 7 Mar 2003 18:00:07 -0000 Received: from unknown (HELO STUDY) (66.167.13.108) by sun-qmail16 with SMTP; 7 Mar 2003 18:00:07 -0000 To: ietf-sasl@imc.org Cc: Subject: Re: draft-nystrom-http-sasl-06.txt References: <200303051130.GAA25941@ietf.org> <20030305214824.GD3505@manyfish.co.uk> Organization: Seeking Work... From: Scott Lawrence Date: 07 Mar 2003 12:59:55 -0500 In-Reply-To: <20030305214824.GD3505@manyfish.co.uk> Message-ID: Lines: 109 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for posting this notice to ietf-http-wg; I hadn't heard of it before then. I'd like to support most of the comments made by Joe Orton, and amplify on couple. Joe Orton writes: > The 1xx status-codes are reserved for "interim" HTTP responses, but the > draft is now using 102 for a final response here, which won't work (or > at least, isn't compatible with HTTP/1.1). In particular, current clients (including proxies) will just treat a 102 as 100 and probably ignore it. > Draft is confused about whether HTTP auth is per-request or > per-connection. Restrictions on not mixing auth sessions on a single > connection etc should be dropped. This gets to the heart of the issue, really. HTTP is stateless by definition, and the connection has no semantic importance; as such, it can't (in HTTP alone) have any security significance. Earlier efforts to apply SASL to HTTP (drafts long expired) failed on just this point; they tried to wedge SASL mechanisms into the stateless HTTP framework (without success). You've mostly recognized this and gotten a better model, but I think you've not quite taken it far enough, and I think that fixing it actually makes the suggested changes simpler. As you point out in your Introduction, SASL is connection-oriented, so in order to exploit it, the HTTP server must recognize that it is using different rules - that the connection provides the security. This is essentially the same as what we described (and you cited) in RFC 2817. I think therefor that rather than defining new authentication responses you should just use the existing Upgrade framework. I'll try to illustrate how this goes - fleshing it out will require a bit more study (with which I'm happy to help). This example assumes no intermediaries (which would just add the required CONNECT handshaking to make a tunnel over which to do this sequence) Client: Server: 1) (original request) --------------> [determines that SASL service is required] 2) <-------------------------------- 426 Upgrade Required Upgrade: SASL/1.0, HTTP/1.1 Connection: Upgrade WWW-Authenticate: sasl (mechanisms) 3) (request) -----------------------> [changes semantics of Upgrade: SASL/1.0 connection to be SASL but not yet unauthenticated] 4a) <-------------------------------- 101 Switching Protocols Upgrade: SASL/1.0, HTTP/1.1 4b) <-------------------------------- 401 Unauthorized WWW-Authenticate: sasl (sasl challenge) 5) (original request) -------------> Authorization: sasl (sasl-response) Step 1 is the client naively attempting the unauthenticated request. Step 2 is the server insisting on SASL security for it, and including the available mechanisms (if it is willing, it could also include other WWW-Authenticate options such as digest, with the attendant problems in downgrade attacks). The request in step 3 above (which is indicating that the client is SASL-capable, and a desire to activate it) could be either the original request, or a dummy request (OPTIONS would do) that exists just to trigger the protocol upgrade. 4a is the server signalling that the new connection-oriented security rules apply. It's an intermediate response - the client can't send anything in response to it. 4b is the server actually beginning the (mechanism-dependant) SASL handshake by sending the challenge. I suspect that may be possible to fold some of these steps together, by including the SASL challenge with the 426, enabling the client to include Authorization in step 3. > The draft doesn't actually make any requirements on how the server > responds to an OPTIONS request, so it's pointless as as well as > misguided :) Alas, we tried to make a formal definition of the response to OPTIONS that would be programatically useful, but never got there. > The CONNECT-to-port-80/SASL-security-layer-negotiation bits aren't > compatible with HTTP, and Just Won't Work with deployed HTTP proxies, > most of which don't even grok HTTP/1.1 properly. This can be made to work - if SASL is genuinely better and offers value, then perhaps vendors at all levels would find reasons to support them. I have some skepticism about this, but one can hope. In any event, we have what we need in tbe protocol now to determine _why_ (and where) things fail, which is the first step. -- Scott Lawrence Actively seeking work http://skrb.org/scott/ [ is deprecated ] From owner-ietf-sasl Sat Mar 8 12:16:50 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28KGoJ11506 for ietf-sasl-bks; Sat, 8 Mar 2003 12:16:50 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-SEVENTY-FOUR.MIT.EDU [18.187.6.219]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28KGn311502 for ; Sat, 8 Mar 2003 12:16:49 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 5E825151F11; Sat, 8 Mar 2003 15:16:51 -0500 (EST) To: Internet-Drafts@ietf.org Cc: IETF-Announce: ;, ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <200302281225.HAA22735@ietf.org> From: Sam Hartman Date: Sat, 08 Mar 2003 15:16:51 -0500 In-Reply-To: <200302281225.HAA22735@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 28 Feb 2003 07:25:47 -0500") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems that we really already have enough mechanisms for doing PKI-like things with SASL: * SPKM * LIPKI * TLS + plain What's wrong with using something like LIPKI and negotiating no integrity protection? If your complaint is simply the lack of implementations of LIPKI, then I think that the advantages of having fewer standards outweigh the implementation complexity of LIPKI. If your complaint is that you don't want the complexity of a GSS library, then you should realize that you can implement the LIPKI protocol without actually using a GSSAPI library. From owner-ietf-sasl Sat Mar 8 12:49:02 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28Kn2v12043 for ietf-sasl-bks; Sat, 8 Mar 2003 12:49:02 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-SEVENTY-FOUR.MIT.EDU [18.187.6.219]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28Kn1312039 for ; Sat, 8 Mar 2003 12:49:01 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 9F443151F11; Sat, 8 Mar 2003 15:49:03 -0500 (EST) To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <200302281225.HAA22735@ietf.org> From: Sam Hartman In-Reply-To: <200302281225.HAA22735@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 28 Feb 2003 07:25:47 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) Date: Sat, 08 Mar 2003 15:49:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems that we really already have enough mechanisms for doing PKI-like things with SASL: * SPKM * LIPKI * TLS + plain What's wrong with using something like LIPKI and negotiating no integrity protection? If your complaint is simply the lack of implementations of LIPKI, then I think that the advantages of having fewer standards outweigh the implementation complexity of LIPKI. If your complaint is that you don't want the complexity of a GSS library, then you should realize that you can implement the LIPKI protocol without actually using a GSSAPI library. From owner-ietf-sasl Sun Mar 9 18:21:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2A2Lb711489 for ietf-sasl-bks; Sun, 9 Mar 2003 18:21:37 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A2LZ311485 for ; Sun, 9 Mar 2003 18:21:35 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2A2LcCa038999 for ; Mon, 10 Mar 2003 02:21:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030309181539.02bc0c80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 09 Mar 2003 18:19:51 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Agenda items for IETF#56 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam and I are now putting together the agenda for IETF#56. Editors (and others), please send us a quick note with I-D name(s), list of outstanding issues you would like to discuss, and a estimate of the time needed. Thanks, Kurt & Sam From owner-ietf-sasl Tue Mar 18 13:27:16 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ILRGv08598 for ietf-sasl-bks; Tue, 18 Mar 2003 13:27:16 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILREg08593 for ; Tue, 18 Mar 2003 13:27:14 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Tue, 18 Mar 2003 21:26:19 +0000 Message-ID: <3E777F2E.854166@messagingdirect.com> Date: Tue, 18 Mar 2003 13:18:54 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SASL WG Subject: SASL C API meeting? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there enough interest to have an informal meeting to discuss changes to SASL C API draft (currently draft-newman-sasl-c-api-01.txt)? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 18 13:43:05 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ILh5j09210 for ietf-sasl-bks; Tue, 18 Mar 2003 13:43:05 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILh3g09206 for ; Tue, 18 Mar 2003 13:43:04 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Tue, 18 Mar 2003 21:42:48 +0000 Message-ID: <3E7792F5.500F1EFE@messagingdirect.com> Date: Tue, 18 Mar 2003 14:43:17 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Morteza Ansari CC: SASL WG Subject: Re: SASL C API meeting? References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Morteza ANSI wrote: > I think that would be a good idea. Any preferences? Thursday would be too busy for me, so I would rather do this today or Wednesday. Wednesday morning at 9:00 (or today) works for me. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 18 15:45:17 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2INjHj16181 for ietf-sasl-bks; Tue, 18 Mar 2003 15:45:17 -0800 (PST) Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2INjGg16177 for ; Tue, 18 Mar 2003 15:45:16 -0800 (PST) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2INjIpf027441; Tue, 18 Mar 2003 18:45:18 -0500 Date: Tue, 18 Mar 2003 18:45:17 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: Morteza Ansari , SASL WG Subject: Re: SASL C API meeting? In-Reply-To: <3E7792F5.500F1EFE@messagingdirect.com> Message-ID: References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 18 Mar 2003, Alexey Melnikov wrote: > Any preferences? > Thursday would be too busy for me, so I would rather do this today or > Wednesday. > Wednesday morning at 9:00 (or today) works for me. We'll be meeting at 1815 near the message board, and probably getting some sort of food this evening. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Tue Mar 18 16:01:48 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J01mm16557 for ietf-sasl-bks; Tue, 18 Mar 2003 16:01:48 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J01kg16553 for ; Tue, 18 Mar 2003 16:01:46 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Wed, 19 Mar 2003 00:01:33 +0000 Message-ID: <3E77B37C.A8173C85@messagingdirect.com> Date: Tue, 18 Mar 2003 17:02:04 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Morteza Ansari , SASL WG Subject: Re: SASL C API meeting? References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Tue, 18 Mar 2003, Alexey Melnikov wrote: > > > Any preferences? > > Thursday would be too busy for me, so I would rather do this today or > > Wednesday. > > Wednesday morning at 9:00 (or today) works for me. > > We'll be meeting at 1815 near the message board, and probably getting some > sort of food this evening. And this is not going to be long. Anyway, all results will be discussed at SASL WG meeting on Thursday. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 18 16:34:20 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J0YKl17823 for ietf-sasl-bks; Tue, 18 Mar 2003 16:34:20 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J0YIg17817 for ; Tue, 18 Mar 2003 16:34:18 -0800 (PST) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2J0YK6t023603; Tue, 18 Mar 2003 19:34:20 -0500 Date: Tue, 18 Mar 2003 19:34:20 -0500 (EST) From: Rob Siemborski To: Morteza Ansari cc: Alexey Melnikov , SASL WG Subject: Re: SASL C API meeting? In-Reply-To: <3E77BAD8.1060401@sun.com> Message-ID: References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> <3E77B37C.A8173C85@messagingdirect.com> <3E77BAD8.1060401@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 18 Mar 2003, Morteza Ansari wrote: > > And this is not going to be long. > > > > Anyway, all results will be discussed at SASL WG meeting on Thursday. > > Is this Wed. 18:15? Sorry, Tonight, (Tuesday) 1815. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Mar 19 14:52:45 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JMqj219051 for ietf-sasl-bks; Wed, 19 Mar 2003 14:52:45 -0800 (PST) Received: from konishi-polis.mit.edu (wl-132-53.wireless.ietf56.ietf.org [130.129.132.53]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JMqig19045 for ; Wed, 19 Mar 2003 14:52:44 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 96C09152124; Wed, 19 Mar 2003 17:52:47 -0500 (EST) To: ietf-sasl@imc.org Subject: SASL applicability statement From: Sam Hartman Date: Wed, 19 Mar 2003 17:52:47 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At this week's security directorate meeting, we discussed the need for applicability statements for security protocols that both describe how they should be used in another protocol and when they are appropriate. Such a statement is being developed for TLS. Some people felt that SASL didn't need such a statement because it was sufficiently well understood by the applications area that nothing needed to be said. I and some others at the lunch disagreed and believe that SASL tends to be misused in new protocols that try and adopt it just like other security technologies. The reason this tends not to be a problem is that several people do a good job of looking at SASL usage and fixing problems that we discover. Do people believe such an applicability statement is useful? Would someone volunteer to be an editor? Steve indicated that asking for this work to be added to our charter would be a reasonable thing to do. --Sam From owner-ietf-sasl Wed Mar 19 19:56:07 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K3u7E03394 for ietf-sasl-bks; Wed, 19 Mar 2003 19:56:07 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K3u6g03390 for ; Wed, 19 Mar 2003 19:56:06 -0800 (PST) Received: from majormajor.ietf56.ietf.org (wl-142-65.wireless.ietf56.ietf.org [130.129.142.65]) (user=leg mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2K3u46t007234 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 19 Mar 2003 22:56:08 -0500 Date: Wed, 19 Mar 2003 19:55:50 -0800 From: Lawrence Greenfield To: Sam Hartman , ietf-sasl@imc.org Subject: Re: SASL applicability statement Message-ID: <121626579.1048103750@majormajor.ietf56.ietf.org> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, March 19, 2003 5:52 PM -0500 Sam Hartman wrote: > Do people believe such an applicability statement is useful? Would > someone volunteer to be an editor? It would be useful to have such a statement at times, especially since SASL tends to be underutilized in protocols that could easily make use of it without making any or little over-the-wire changes to them. There are still generic authentication frameworks being developed in protocol specific contexts (iSCSI, some proposals for IPsec). It would be nice if these attempts could instead be guided to strongly considering SASL. But it's not clear to me that (for instance) TLS and SASL should be discussed in separate documents. I think the document would be more useful for non-application area protocols, since the application area has (generally) become much more standardized on TLS and SASL usage. Larry From owner-ietf-sasl Wed Mar 19 20:16:38 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K4Gcl03944 for ietf-sasl-bks; Wed, 19 Mar 2003 20:16:38 -0800 (PST) Received: from konishi-polis.mit.edu (wl-132-53.wireless.ietf56.ietf.org [130.129.132.53]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K4Gbg03940 for ; Wed, 19 Mar 2003 20:16:37 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2F8A6152124; Wed, 19 Mar 2003 23:16:36 -0500 (EST) To: Lawrence Greenfield Cc: ietf-sasl@imc.org Subject: Re: SASL applicability statement References: <121626579.1048103750@majormajor.ietf56.ietf.org> From: Sam Hartman Date: Wed, 19 Mar 2003 23:16:36 -0500 In-Reply-To: <121626579.1048103750@majormajor.ietf56.ietf.org> (Lawrence Greenfield's message of "Wed, 19 Mar 2003 19:55:50 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think the document should discuss both TLS and SASL, but should refer to a TLS applicability statement being written elsewhere for specific TLS issues. I suspect politically completely combining the documents will be challenging. From owner-ietf-sasl Sun Mar 23 16:57:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2O0vhP10859 for ietf-sasl-bks; Sun, 23 Mar 2003 16:57:43 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O0vfg10851 for ; Sun, 23 Mar 2003 16:57:41 -0800 (PST) Received: from messagingdirect.com (actually [66.222.133.179]) by woozle.isode.com (remote) with ESMTP; Mon, 24 Mar 2003 00:57:03 +0000 Message-ID: <3E7E57DC.7137D4CC@messagingdirect.com> Date: Sun, 23 Mar 2003 17:57:00 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: SASL WG Subject: Re: [SASL] Comments about draft-ietf-sasl-plain-00.txt References: <3E7E1FF2.309D8DAA@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: More comments below. Alexey Melnikov wrote: > 2. PLAIN SASL mechanism > > The mechanism consists of a single message from the client to the > server. The client sends the authorization identity (identity to > login as), followed by a NUL character, followed by the authentication > identity (identity whose password will be used), followed by a NUL > character, followed by the clear-text password. The client leaves > the authorization identity empty if wishes the server to derive the > authorization identity from the provided the authentication identity. Last line: drop "the" before "authentication identity". > Appendix A. Changes since RFC 2595 > > The specification details how the server is to compare client-provided > character strings with stored character strings. I suggest that the example code be moved to SASLPrep document or the base SASL spec. Or maybe not, as it has some PLAIN specific checks, but some pieces of it are generic and I would hate to cut & paste them into every SASL mechanism that requires SASLPrep. > The ABNF grammar was updated. In particular, the grammar now allows > LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the > authzid, authcid, passwd productions. However, whether these control > characters may be used depends on the string preparation rules > applicable to the production. For authcid, control characters are > prohibited. For passwd, control characters are allowed. IMHO, CRs and LFs must not be allowed in passwords. They are almost impossible to enter in UI and this change might break existing protocols, like ACAP. > For authzid, > one must consult the application-level SASL profile. ...if the one exists. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 25 06:40:47 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PEel018134 for ietf-sasl-bks; Tue, 25 Mar 2003 06:40:47 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PEekg18129 for ; Tue, 25 Mar 2003 06:40:46 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h2PEek3c010324 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA11352 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2PEej0x001925 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id JAA16446; Tue, 25 Mar 2003 09:40:45 -0500 (EST) Date: Tue, 25 Mar 2003 09:40:45 -0500 (EST) Message-Id: <200303251440.JAA16446@tir-na-nogth.mit.edu> From: Sam Hartman To: ietf-sasl@imc.org Subject: Comments on draft-ietf-sasl-rfc2831 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In section 2.1.1, the draft states: Note, that this directive doesn't affect authorization id ("authzid") which is always in UTF-8. It is not the place of the mechanism spec to say anything about the character set of the authorization ID; the mechanism should treat the authorization ID as an opaque string and leave it up to the application to specify the meaning of the authorization id. In section 2.1.2.1, is exchange protected against a downgrade attack from auth-conf, auth-int to auth? I.E. Looking at the definition of a2 and response, I see where the client value of qop is used, but not the server supplied qop options. The security discussion seems inadequate. From owner-ietf-sasl Mon Mar 31 09:29:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHTHJM029698 for ; Mon, 31 Mar 2003 09:29:17 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VHTH6I029697 for ietf-sasl-bks; Mon, 31 Mar 2003 09:29:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHTFJM029693 for ; Mon, 31 Mar 2003 09:29:16 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1B4B4152124; Mon, 31 Mar 2003 12:28:23 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft minutes for IETF 56 SASL working group meeting Message-Id: <20030331172823.1B4B4152124@konishi-polis.mit.edu> Date: Mon, 31 Mar 2003 12:28:23 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send any corrections; the corrected minutes will be submitted later this week for the proceedings. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. From owner-ietf-sasl Mon Mar 31 09:36:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHaMJM029818 for ; Mon, 31 Mar 2003 09:36:22 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VHaMcj029817 for ietf-sasl-bks; Mon, 31 Mar 2003 09:36:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHaKJM029813 for ; Mon, 31 Mar 2003 09:36:21 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A3AAD152124; Mon, 31 Mar 2003 12:35:28 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft minutes for IETF 56 SASL working group meeting Message-Id: <20030331173528.A3AAD152124@konishi-polis.mit.edu> Date: Mon, 31 Mar 2003 12:35:28 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send any corrections; the corrected minutes will be submitted later this week for the proceedings. Minutes based on notes from Chris Newman and Sam Hartman. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. From owner-ietf-sasl Mon Mar 31 12:26:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKQnJM009099 for ; Mon, 31 Mar 2003 12:26:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VKQnd8009098 for ietf-sasl-bks; Mon, 31 Mar 2003 12:26:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKQlJM009089 for ; Mon, 31 Mar 2003 12:26:48 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E1B98152124; Mon, 31 Mar 2003 15:25:53 -0500 (EST) To: ietf-sasl@imc.org Cc: ekr@rtfm.com Subject: security report for sasl digest-md5 From: Sam Hartman Date: Mon, 31 Mar 2003 15:25:53 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: During the SASL working group meeting at IETF 56, Eric Rescorla and I agreed to review the security of cipher usage in the digest-md5 SASL mechanism draft (draft-ietf-sasl-rfc2831bis). We have reached the following conclusions: 1) Instructions on how to use rc4 are unclear; an implementation might read the draft and assume that the PRNG should be initialized for every message sent. This would allow an attacker to retrieve the xor of multiple plaintext messages given the ciphertext and in most situations would completely compromise confidentiality. 2) The use of CBC is unclear. The draft does not specify whether the IV is reinitialized from one message to the next or whether the the last block of ciphertext becomes the IV of the next message. From a security standpoint the IV should not be reinitialized and instead should be chained between messages. 3) The handling of parity bits is significantly different from other protocols that specify how to set up keys and may lead to confusion. 4) Part of the key material is used as the IV for the 3DES cipher. 5) As previously discussed on the SASL list, the protocol is vulnerable to CBC chaining issue (the Rogaway attack). 6) Implementation guidance on avoiding timing attacks related to verifying padding before performing the MAC operations needs to be given. See http://lasecwww.epfl.ch/memo_ssl.shtml. Since existing implementations of the RC4 cipher do preserve PRNG state between messages, there is no technical objection to retaining the existing RC4 cipher or even to making it mandatory to implement. An appropriate document for a normative reference will need to be found and the text will need to be clarified if the working group wishes to proceed in this direction. We recommend that the working group deprecate the existing DES and 3DES ciphers. An AES cipher should be specified. The AES cipher can either use counter mode or avoid the CBC chaining attack in some other way such as the addition of random text to each message. The AES cipher should not use key material as part of the IV. From owner-ietf-sasl Mon Mar 31 21:43:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h315hdJM003657 for ; Mon, 31 Mar 2003 21:43:39 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h315hd3H003656 for ietf-sasl-bks; Mon, 31 Mar 2003 21:43:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h315hZJM003652 for ; Mon, 31 Mar 2003 21:43:38 -0800 (PST) Received: from messagingdirect.com (1Cust86.tnt3.edmonton.ab.da.uu.net [64.10.184.86]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h315kwV11249; Mon, 31 Mar 2003 22:46:58 -0700 Message-ID: <3E89239B.1E03F4FE@messagingdirect.com> Date: Mon, 31 Mar 2003 22:28:59 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > In section 2.1.1, the draft states: > > Note, that this directive doesn't affect authorization id > ("authzid") which is always in UTF-8. > > It is not the place of the mechanism spec to say anything about the > character set of the authorization ID; the mechanism should treat the > authorization ID as an opaque string and leave it up to the > application to specify the meaning of the authorization id. We have to be clear that for the protocols that use the same format for authentication and authorization ids, "authzid" is in UTF-8 and MUST NOT be converted to ISO-8859-1 as username/password are. This doesn't belong to protocol profiles either, I don't think we should special case DIGEST-MD5 in all protocol profiles. > In section 2.1.2.1, is exchange protected against a downgrade attack > from auth-conf, auth-int to auth? > I.E. Looking at the definition of a2 and response, I see where the > client value of qop is used, but not > the server supplied qop options. You are right, server supplied list of supported qop options is not protected. An attacker can remove all but the weakest (i.e. "auth"). > The security discussion seems inadequate. Suggestions? Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Sun Mar 2 17:03:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h2313pd26748 for ietf-sasl-bks; Sun, 2 Mar 2003 17:03:51 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h2313nY26744 for ; Sun, 2 Mar 2003 17:03:49 -0800 (PST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Mon, 3 Mar 2003 12:03:53 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hansen-sasl-pki-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Index: AcLfYI/CtyRFQhVfQdiIx7kpykYX/QBvmhAw From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , "Lawrence Greenfield" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2313oY26745 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Kurt, I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Saturday, 1 March 2003 06:22 To: Lawrence Greenfield Cc: tony@att.com; ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt At 11:02 AM 2/28/2003, Lawrence Greenfield wrote: > Date: Fri, 28 Feb 2003 10:06:54 -0800 > From: "Kurt D. Zeilenga" > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? > >You don't close TLS; you can renegotiate to the NULL cipher. Application-level protocols may permit use the stream after TLS closure. See RFC 2246, Section 7.2.1. LDAPv3 is an example, RFC 2830, of an application-level protocol which explicitly permits such use. Kurt From owner-ietf-sasl Sun Mar 2 17:19:14 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h231JEi26940 for ietf-sasl-bks; Sun, 2 Mar 2003 17:19:14 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h231JCY26935 for ; Sun, 2 Mar 2003 17:19:12 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h231J88q054126; Mon, 3 Mar 2003 01:19:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030302171418.02728f20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 02 Mar 2003 17:17:23 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: "Lawrence Greenfield" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:03 PM 3/2/2003, Ramsay, Ron wrote: >I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Good catch. I then say that the I-D should note that one of the reasons why TLS+SASL/PLAIN+closure is that application profiles of TLS define inconsistent TLS closure semantics. Kurt From owner-ietf-sasl Sun Mar 2 17:32:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h231WkF27164 for ietf-sasl-bks; Sun, 2 Mar 2003 17:32:46 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h231WjY27160 for ; Sun, 2 Mar 2003 17:32:45 -0800 (PST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Mon, 3 Mar 2003 12:32:49 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hansen-sasl-pki-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Index: AcLhIuxhiR6kYURFS8y1afstPqyX+gAAYnMg From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: "Lawrence Greenfield" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h231WjY27161 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, Kurt, you're the only one who has tried to make the TLS session transient. I go with the author who said it should last for the whole session. You don't put up an Aunt Sally just to knock it down again! Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, 3 March 2003 12:17 To: Ramsay, Ron Cc: Lawrence Greenfield; tony@att.com; ietf-sasl@imc.org Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt At 05:03 PM 3/2/2003, Ramsay, Ron wrote: >I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Good catch. I then say that the I-D should note that one of the reasons why TLS+SASL/PLAIN+closure is that application profiles of TLS define inconsistent TLS closure semantics. Kurt From owner-ietf-sasl Sun Mar 2 18:10:58 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h232Aw027942 for ietf-sasl-bks; Sun, 2 Mar 2003 18:10:58 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h232AuY27936 for ; Sun, 2 Mar 2003 18:10:56 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h232At8q054329; Mon, 3 Mar 2003 02:10:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030302173345.02722560@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 02 Mar 2003 18:09:10 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: "Lawrence Greenfield" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:32 PM 3/2/2003, Ramsay, Ron wrote: >Well, Kurt, you're the only one who has tried to make the TLS session transient. As I noted in my last response, it is now clear to me is that TLS+SASL/PLAIN+closure is not a viable approach. However, I content that it is not obviously so. TLS is transient by design. And application protocol profiles of TLS could be defined which support this approach. And existing TLS and SASL libraries would allow implementation of the approach. And there existing implementations of application protocols which do use this approach today. So, I think, my original question was quite reasonable to ask. Personally, I think the answer deserves brief mention in the I-D. Kurt From owner-ietf-sasl Wed Mar 5 03:32:35 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25BWZj10174 for ietf-sasl-bks; Wed, 5 Mar 2003 03:32:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25BWY310170 for ; Wed, 5 Mar 2003 03:32:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25941; Wed, 5 Mar 2003 06:30:19 -0500 (EST) Message-Id: <200303051130.GAA25941@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-http-wg@w3.org, ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-06.txt Date: Wed, 05 Mar 2003 06:30:19 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, R. Zuccherato, A. Melnikov Filename : draft-nystrom-http-sasl-06.txt Pages : 32 Date : 2003-3-4 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nystrom-http-sasl-06.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-nystrom-http-sasl-06.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: <2003-3-4174121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174121.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Mar 7 10:00:08 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27I08508303 for ietf-sasl-bks; Fri, 7 Mar 2003 10:00:08 -0800 (PST) Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by above.proper.com (8.11.6/8.11.6) with SMTP id h27I06308298 for ; Fri, 7 Mar 2003 10:00:07 -0800 (PST) Received: (covad.net 18605 invoked from network); 7 Mar 2003 18:00:07 -0000 Received: from unknown (HELO STUDY) (66.167.13.108) by sun-qmail16 with SMTP; 7 Mar 2003 18:00:07 -0000 To: ietf-sasl@imc.org Cc: Subject: Re: draft-nystrom-http-sasl-06.txt References: <200303051130.GAA25941@ietf.org> <20030305214824.GD3505@manyfish.co.uk> Organization: Seeking Work... From: Scott Lawrence Date: 07 Mar 2003 12:59:55 -0500 In-Reply-To: <20030305214824.GD3505@manyfish.co.uk> Message-ID: Lines: 109 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for posting this notice to ietf-http-wg; I hadn't heard of it before then. I'd like to support most of the comments made by Joe Orton, and amplify on couple. Joe Orton writes: > The 1xx status-codes are reserved for "interim" HTTP responses, but the > draft is now using 102 for a final response here, which won't work (or > at least, isn't compatible with HTTP/1.1). In particular, current clients (including proxies) will just treat a 102 as 100 and probably ignore it. > Draft is confused about whether HTTP auth is per-request or > per-connection. Restrictions on not mixing auth sessions on a single > connection etc should be dropped. This gets to the heart of the issue, really. HTTP is stateless by definition, and the connection has no semantic importance; as such, it can't (in HTTP alone) have any security significance. Earlier efforts to apply SASL to HTTP (drafts long expired) failed on just this point; they tried to wedge SASL mechanisms into the stateless HTTP framework (without success). You've mostly recognized this and gotten a better model, but I think you've not quite taken it far enough, and I think that fixing it actually makes the suggested changes simpler. As you point out in your Introduction, SASL is connection-oriented, so in order to exploit it, the HTTP server must recognize that it is using different rules - that the connection provides the security. This is essentially the same as what we described (and you cited) in RFC 2817. I think therefor that rather than defining new authentication responses you should just use the existing Upgrade framework. I'll try to illustrate how this goes - fleshing it out will require a bit more study (with which I'm happy to help). This example assumes no intermediaries (which would just add the required CONNECT handshaking to make a tunnel over which to do this sequence) Client: Server: 1) (original request) --------------> [determines that SASL service is required] 2) <-------------------------------- 426 Upgrade Required Upgrade: SASL/1.0, HTTP/1.1 Connection: Upgrade WWW-Authenticate: sasl (mechanisms) 3) (request) -----------------------> [changes semantics of Upgrade: SASL/1.0 connection to be SASL but not yet unauthenticated] 4a) <-------------------------------- 101 Switching Protocols Upgrade: SASL/1.0, HTTP/1.1 4b) <-------------------------------- 401 Unauthorized WWW-Authenticate: sasl (sasl challenge) 5) (original request) -------------> Authorization: sasl (sasl-response) Step 1 is the client naively attempting the unauthenticated request. Step 2 is the server insisting on SASL security for it, and including the available mechanisms (if it is willing, it could also include other WWW-Authenticate options such as digest, with the attendant problems in downgrade attacks). The request in step 3 above (which is indicating that the client is SASL-capable, and a desire to activate it) could be either the original request, or a dummy request (OPTIONS would do) that exists just to trigger the protocol upgrade. 4a is the server signalling that the new connection-oriented security rules apply. It's an intermediate response - the client can't send anything in response to it. 4b is the server actually beginning the (mechanism-dependant) SASL handshake by sending the challenge. I suspect that may be possible to fold some of these steps together, by including the SASL challenge with the 426, enabling the client to include Authorization in step 3. > The draft doesn't actually make any requirements on how the server > responds to an OPTIONS request, so it's pointless as as well as > misguided :) Alas, we tried to make a formal definition of the response to OPTIONS that would be programatically useful, but never got there. > The CONNECT-to-port-80/SASL-security-layer-negotiation bits aren't > compatible with HTTP, and Just Won't Work with deployed HTTP proxies, > most of which don't even grok HTTP/1.1 properly. This can be made to work - if SASL is genuinely better and offers value, then perhaps vendors at all levels would find reasons to support them. I have some skepticism about this, but one can hope. In any event, we have what we need in tbe protocol now to determine _why_ (and where) things fail, which is the first step. -- Scott Lawrence Actively seeking work http://skrb.org/scott/ [ is deprecated ] From owner-ietf-sasl Sat Mar 8 12:16:50 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28KGoJ11506 for ietf-sasl-bks; Sat, 8 Mar 2003 12:16:50 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-SEVENTY-FOUR.MIT.EDU [18.187.6.219]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28KGn311502 for ; Sat, 8 Mar 2003 12:16:49 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 5E825151F11; Sat, 8 Mar 2003 15:16:51 -0500 (EST) To: Internet-Drafts@ietf.org Cc: IETF-Announce: ;, ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <200302281225.HAA22735@ietf.org> From: Sam Hartman Date: Sat, 08 Mar 2003 15:16:51 -0500 In-Reply-To: <200302281225.HAA22735@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 28 Feb 2003 07:25:47 -0500") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems that we really already have enough mechanisms for doing PKI-like things with SASL: * SPKM * LIPKI * TLS + plain What's wrong with using something like LIPKI and negotiating no integrity protection? If your complaint is simply the lack of implementations of LIPKI, then I think that the advantages of having fewer standards outweigh the implementation complexity of LIPKI. If your complaint is that you don't want the complexity of a GSS library, then you should realize that you can implement the LIPKI protocol without actually using a GSSAPI library. From owner-ietf-sasl Sat Mar 8 12:49:02 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28Kn2v12043 for ietf-sasl-bks; Sat, 8 Mar 2003 12:49:02 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-SEVENTY-FOUR.MIT.EDU [18.187.6.219]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28Kn1312039 for ; Sat, 8 Mar 2003 12:49:01 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 9F443151F11; Sat, 8 Mar 2003 15:49:03 -0500 (EST) To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <200302281225.HAA22735@ietf.org> From: Sam Hartman In-Reply-To: <200302281225.HAA22735@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 28 Feb 2003 07:25:47 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) Date: Sat, 08 Mar 2003 15:49:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems that we really already have enough mechanisms for doing PKI-like things with SASL: * SPKM * LIPKI * TLS + plain What's wrong with using something like LIPKI and negotiating no integrity protection? If your complaint is simply the lack of implementations of LIPKI, then I think that the advantages of having fewer standards outweigh the implementation complexity of LIPKI. If your complaint is that you don't want the complexity of a GSS library, then you should realize that you can implement the LIPKI protocol without actually using a GSSAPI library. From owner-ietf-sasl Sun Mar 9 18:21:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2A2Lb711489 for ietf-sasl-bks; Sun, 9 Mar 2003 18:21:37 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A2LZ311485 for ; Sun, 9 Mar 2003 18:21:35 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2A2LcCa038999 for ; Mon, 10 Mar 2003 02:21:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030309181539.02bc0c80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 09 Mar 2003 18:19:51 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Agenda items for IETF#56 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam and I are now putting together the agenda for IETF#56. Editors (and others), please send us a quick note with I-D name(s), list of outstanding issues you would like to discuss, and a estimate of the time needed. Thanks, Kurt & Sam From owner-ietf-sasl Tue Mar 18 13:27:16 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ILRGv08598 for ietf-sasl-bks; Tue, 18 Mar 2003 13:27:16 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILREg08593 for ; Tue, 18 Mar 2003 13:27:14 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Tue, 18 Mar 2003 21:26:19 +0000 Message-ID: <3E777F2E.854166@messagingdirect.com> Date: Tue, 18 Mar 2003 13:18:54 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SASL WG Subject: SASL C API meeting? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there enough interest to have an informal meeting to discuss changes to SASL C API draft (currently draft-newman-sasl-c-api-01.txt)? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 18 13:43:05 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ILh5j09210 for ietf-sasl-bks; Tue, 18 Mar 2003 13:43:05 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILh3g09206 for ; Tue, 18 Mar 2003 13:43:04 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Tue, 18 Mar 2003 21:42:48 +0000 Message-ID: <3E7792F5.500F1EFE@messagingdirect.com> Date: Tue, 18 Mar 2003 14:43:17 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Morteza Ansari CC: SASL WG Subject: Re: SASL C API meeting? References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Morteza ANSI wrote: > I think that would be a good idea. Any preferences? Thursday would be too busy for me, so I would rather do this today or Wednesday. Wednesday morning at 9:00 (or today) works for me. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 18 15:45:17 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2INjHj16181 for ietf-sasl-bks; Tue, 18 Mar 2003 15:45:17 -0800 (PST) Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2INjGg16177 for ; Tue, 18 Mar 2003 15:45:16 -0800 (PST) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2INjIpf027441; Tue, 18 Mar 2003 18:45:18 -0500 Date: Tue, 18 Mar 2003 18:45:17 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: Morteza Ansari , SASL WG Subject: Re: SASL C API meeting? In-Reply-To: <3E7792F5.500F1EFE@messagingdirect.com> Message-ID: References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 18 Mar 2003, Alexey Melnikov wrote: > Any preferences? > Thursday would be too busy for me, so I would rather do this today or > Wednesday. > Wednesday morning at 9:00 (or today) works for me. We'll be meeting at 1815 near the message board, and probably getting some sort of food this evening. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Tue Mar 18 16:01:48 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J01mm16557 for ietf-sasl-bks; Tue, 18 Mar 2003 16:01:48 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J01kg16553 for ; Tue, 18 Mar 2003 16:01:46 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Wed, 19 Mar 2003 00:01:33 +0000 Message-ID: <3E77B37C.A8173C85@messagingdirect.com> Date: Tue, 18 Mar 2003 17:02:04 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Morteza Ansari , SASL WG Subject: Re: SASL C API meeting? References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Tue, 18 Mar 2003, Alexey Melnikov wrote: > > > Any preferences? > > Thursday would be too busy for me, so I would rather do this today or > > Wednesday. > > Wednesday morning at 9:00 (or today) works for me. > > We'll be meeting at 1815 near the message board, and probably getting some > sort of food this evening. And this is not going to be long. Anyway, all results will be discussed at SASL WG meeting on Thursday. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 18 16:34:20 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J0YKl17823 for ietf-sasl-bks; Tue, 18 Mar 2003 16:34:20 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J0YIg17817 for ; Tue, 18 Mar 2003 16:34:18 -0800 (PST) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2J0YK6t023603; Tue, 18 Mar 2003 19:34:20 -0500 Date: Tue, 18 Mar 2003 19:34:20 -0500 (EST) From: Rob Siemborski To: Morteza Ansari cc: Alexey Melnikov , SASL WG Subject: Re: SASL C API meeting? In-Reply-To: <3E77BAD8.1060401@sun.com> Message-ID: References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> <3E77B37C.A8173C85@messagingdirect.com> <3E77BAD8.1060401@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 18 Mar 2003, Morteza Ansari wrote: > > And this is not going to be long. > > > > Anyway, all results will be discussed at SASL WG meeting on Thursday. > > Is this Wed. 18:15? Sorry, Tonight, (Tuesday) 1815. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Mar 19 14:52:45 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JMqj219051 for ietf-sasl-bks; Wed, 19 Mar 2003 14:52:45 -0800 (PST) Received: from konishi-polis.mit.edu (wl-132-53.wireless.ietf56.ietf.org [130.129.132.53]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JMqig19045 for ; Wed, 19 Mar 2003 14:52:44 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 96C09152124; Wed, 19 Mar 2003 17:52:47 -0500 (EST) To: ietf-sasl@imc.org Subject: SASL applicability statement From: Sam Hartman Date: Wed, 19 Mar 2003 17:52:47 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At this week's security directorate meeting, we discussed the need for applicability statements for security protocols that both describe how they should be used in another protocol and when they are appropriate. Such a statement is being developed for TLS. Some people felt that SASL didn't need such a statement because it was sufficiently well understood by the applications area that nothing needed to be said. I and some others at the lunch disagreed and believe that SASL tends to be misused in new protocols that try and adopt it just like other security technologies. The reason this tends not to be a problem is that several people do a good job of looking at SASL usage and fixing problems that we discover. Do people believe such an applicability statement is useful? Would someone volunteer to be an editor? Steve indicated that asking for this work to be added to our charter would be a reasonable thing to do. --Sam From owner-ietf-sasl Wed Mar 19 19:56:07 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K3u7E03394 for ietf-sasl-bks; Wed, 19 Mar 2003 19:56:07 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K3u6g03390 for ; Wed, 19 Mar 2003 19:56:06 -0800 (PST) Received: from majormajor.ietf56.ietf.org (wl-142-65.wireless.ietf56.ietf.org [130.129.142.65]) (user=leg mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2K3u46t007234 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 19 Mar 2003 22:56:08 -0500 Date: Wed, 19 Mar 2003 19:55:50 -0800 From: Lawrence Greenfield To: Sam Hartman , ietf-sasl@imc.org Subject: Re: SASL applicability statement Message-ID: <121626579.1048103750@majormajor.ietf56.ietf.org> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, March 19, 2003 5:52 PM -0500 Sam Hartman wrote: > Do people believe such an applicability statement is useful? Would > someone volunteer to be an editor? It would be useful to have such a statement at times, especially since SASL tends to be underutilized in protocols that could easily make use of it without making any or little over-the-wire changes to them. There are still generic authentication frameworks being developed in protocol specific contexts (iSCSI, some proposals for IPsec). It would be nice if these attempts could instead be guided to strongly considering SASL. But it's not clear to me that (for instance) TLS and SASL should be discussed in separate documents. I think the document would be more useful for non-application area protocols, since the application area has (generally) become much more standardized on TLS and SASL usage. Larry From owner-ietf-sasl Wed Mar 19 20:16:38 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K4Gcl03944 for ietf-sasl-bks; Wed, 19 Mar 2003 20:16:38 -0800 (PST) Received: from konishi-polis.mit.edu (wl-132-53.wireless.ietf56.ietf.org [130.129.132.53]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K4Gbg03940 for ; Wed, 19 Mar 2003 20:16:37 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2F8A6152124; Wed, 19 Mar 2003 23:16:36 -0500 (EST) To: Lawrence Greenfield Cc: ietf-sasl@imc.org Subject: Re: SASL applicability statement References: <121626579.1048103750@majormajor.ietf56.ietf.org> From: Sam Hartman Date: Wed, 19 Mar 2003 23:16:36 -0500 In-Reply-To: <121626579.1048103750@majormajor.ietf56.ietf.org> (Lawrence Greenfield's message of "Wed, 19 Mar 2003 19:55:50 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think the document should discuss both TLS and SASL, but should refer to a TLS applicability statement being written elsewhere for specific TLS issues. I suspect politically completely combining the documents will be challenging. From owner-ietf-sasl Sun Mar 23 16:57:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2O0vhP10859 for ietf-sasl-bks; Sun, 23 Mar 2003 16:57:43 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O0vfg10851 for ; Sun, 23 Mar 2003 16:57:41 -0800 (PST) Received: from messagingdirect.com (actually [66.222.133.179]) by woozle.isode.com (remote) with ESMTP; Mon, 24 Mar 2003 00:57:03 +0000 Message-ID: <3E7E57DC.7137D4CC@messagingdirect.com> Date: Sun, 23 Mar 2003 17:57:00 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: SASL WG Subject: Re: [SASL] Comments about draft-ietf-sasl-plain-00.txt References: <3E7E1FF2.309D8DAA@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: More comments below. Alexey Melnikov wrote: > 2. PLAIN SASL mechanism > > The mechanism consists of a single message from the client to the > server. The client sends the authorization identity (identity to > login as), followed by a NUL character, followed by the authentication > identity (identity whose password will be used), followed by a NUL > character, followed by the clear-text password. The client leaves > the authorization identity empty if wishes the server to derive the > authorization identity from the provided the authentication identity. Last line: drop "the" before "authentication identity". > Appendix A. Changes since RFC 2595 > > The specification details how the server is to compare client-provided > character strings with stored character strings. I suggest that the example code be moved to SASLPrep document or the base SASL spec. Or maybe not, as it has some PLAIN specific checks, but some pieces of it are generic and I would hate to cut & paste them into every SASL mechanism that requires SASLPrep. > The ABNF grammar was updated. In particular, the grammar now allows > LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the > authzid, authcid, passwd productions. However, whether these control > characters may be used depends on the string preparation rules > applicable to the production. For authcid, control characters are > prohibited. For passwd, control characters are allowed. IMHO, CRs and LFs must not be allowed in passwords. They are almost impossible to enter in UI and this change might break existing protocols, like ACAP. > For authzid, > one must consult the application-level SASL profile. ...if the one exists. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Tue Mar 25 06:40:47 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PEel018134 for ietf-sasl-bks; Tue, 25 Mar 2003 06:40:47 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PEekg18129 for ; Tue, 25 Mar 2003 06:40:46 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h2PEek3c010324 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA11352 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2PEej0x001925 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id JAA16446; Tue, 25 Mar 2003 09:40:45 -0500 (EST) Date: Tue, 25 Mar 2003 09:40:45 -0500 (EST) Message-Id: <200303251440.JAA16446@tir-na-nogth.mit.edu> From: Sam Hartman To: ietf-sasl@imc.org Subject: Comments on draft-ietf-sasl-rfc2831 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In section 2.1.1, the draft states: Note, that this directive doesn't affect authorization id ("authzid") which is always in UTF-8. It is not the place of the mechanism spec to say anything about the character set of the authorization ID; the mechanism should treat the authorization ID as an opaque string and leave it up to the application to specify the meaning of the authorization id. In section 2.1.2.1, is exchange protected against a downgrade attack from auth-conf, auth-int to auth? I.E. Looking at the definition of a2 and response, I see where the client value of qop is used, but not the server supplied qop options. The security discussion seems inadequate. From owner-ietf-sasl Mon Mar 31 09:29:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHTHJM029698 for ; Mon, 31 Mar 2003 09:29:17 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VHTH6I029697 for ietf-sasl-bks; Mon, 31 Mar 2003 09:29:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHTFJM029693 for ; Mon, 31 Mar 2003 09:29:16 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1B4B4152124; Mon, 31 Mar 2003 12:28:23 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft minutes for IETF 56 SASL working group meeting Message-Id: <20030331172823.1B4B4152124@konishi-polis.mit.edu> Date: Mon, 31 Mar 2003 12:28:23 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send any corrections; the corrected minutes will be submitted later this week for the proceedings. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. From owner-ietf-sasl Mon Mar 31 09:36:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHaMJM029818 for ; Mon, 31 Mar 2003 09:36:22 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VHaMcj029817 for ietf-sasl-bks; Mon, 31 Mar 2003 09:36:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHaKJM029813 for ; Mon, 31 Mar 2003 09:36:21 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A3AAD152124; Mon, 31 Mar 2003 12:35:28 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft minutes for IETF 56 SASL working group meeting Message-Id: <20030331173528.A3AAD152124@konishi-polis.mit.edu> Date: Mon, 31 Mar 2003 12:35:28 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send any corrections; the corrected minutes will be submitted later this week for the proceedings. Minutes based on notes from Chris Newman and Sam Hartman. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. From owner-ietf-sasl Mon Mar 31 12:26:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKQnJM009099 for ; Mon, 31 Mar 2003 12:26:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VKQnd8009098 for ietf-sasl-bks; Mon, 31 Mar 2003 12:26:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKQlJM009089 for ; Mon, 31 Mar 2003 12:26:48 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E1B98152124; Mon, 31 Mar 2003 15:25:53 -0500 (EST) To: ietf-sasl@imc.org Cc: ekr@rtfm.com Subject: security report for sasl digest-md5 From: Sam Hartman Date: Mon, 31 Mar 2003 15:25:53 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: During the SASL working group meeting at IETF 56, Eric Rescorla and I agreed to review the security of cipher usage in the digest-md5 SASL mechanism draft (draft-ietf-sasl-rfc2831bis). We have reached the following conclusions: 1) Instructions on how to use rc4 are unclear; an implementation might read the draft and assume that the PRNG should be initialized for every message sent. This would allow an attacker to retrieve the xor of multiple plaintext messages given the ciphertext and in most situations would completely compromise confidentiality. 2) The use of CBC is unclear. The draft does not specify whether the IV is reinitialized from one message to the next or whether the the last block of ciphertext becomes the IV of the next message. From a security standpoint the IV should not be reinitialized and instead should be chained between messages. 3) The handling of parity bits is significantly different from other protocols that specify how to set up keys and may lead to confusion. 4) Part of the key material is used as the IV for the 3DES cipher. 5) As previously discussed on the SASL list, the protocol is vulnerable to CBC chaining issue (the Rogaway attack). 6) Implementation guidance on avoiding timing attacks related to verifying padding before performing the MAC operations needs to be given. See http://lasecwww.epfl.ch/memo_ssl.shtml. Since existing implementations of the RC4 cipher do preserve PRNG state between messages, there is no technical objection to retaining the existing RC4 cipher or even to making it mandatory to implement. An appropriate document for a normative reference will need to be found and the text will need to be clarified if the working group wishes to proceed in this direction. We recommend that the working group deprecate the existing DES and 3DES ciphers. An AES cipher should be specified. The AES cipher can either use counter mode or avoid the CBC chaining attack in some other way such as the addition of random text to each message. The AES cipher should not use key material as part of the IV. From owner-ietf-sasl Mon Mar 31 21:43:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h315hdJM003657 for ; Mon, 31 Mar 2003 21:43:39 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h315hd3H003656 for ietf-sasl-bks; Mon, 31 Mar 2003 21:43:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h315hZJM003652 for ; Mon, 31 Mar 2003 21:43:38 -0800 (PST) Received: from messagingdirect.com (1Cust86.tnt3.edmonton.ab.da.uu.net [64.10.184.86]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h315kwV11249; Mon, 31 Mar 2003 22:46:58 -0700 Message-ID: <3E89239B.1E03F4FE@messagingdirect.com> Date: Mon, 31 Mar 2003 22:28:59 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > In section 2.1.1, the draft states: > > Note, that this directive doesn't affect authorization id > ("authzid") which is always in UTF-8. > > It is not the place of the mechanism spec to say anything about the > character set of the authorization ID; the mechanism should treat the > authorization ID as an opaque string and leave it up to the > application to specify the meaning of the authorization id. We have to be clear that for the protocols that use the same format for authentication and authorization ids, "authzid" is in UTF-8 and MUST NOT be converted to ISO-8859-1 as username/password are. This doesn't belong to protocol profiles either, I don't think we should special case DIGEST-MD5 in all protocol profiles. > In section 2.1.2.1, is exchange protected against a downgrade attack > from auth-conf, auth-int to auth? > I.E. Looking at the definition of a2 and response, I see where the > client value of qop is used, but not > the server supplied qop options. You are right, server supplied list of supported qop options is not protected. An attacker can remove all but the weakest (i.e. "auth"). > The security discussion seems inadequate. Suggestions? Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h315hdJM003657 for ; Mon, 31 Mar 2003 21:43:39 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h315hd3H003656 for ietf-sasl-bks; Mon, 31 Mar 2003 21:43:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h315hZJM003652 for ; Mon, 31 Mar 2003 21:43:38 -0800 (PST) Received: from messagingdirect.com (1Cust86.tnt3.edmonton.ab.da.uu.net [64.10.184.86]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h315kwV11249; Mon, 31 Mar 2003 22:46:58 -0700 Message-ID: <3E89239B.1E03F4FE@messagingdirect.com> Date: Mon, 31 Mar 2003 22:28:59 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > In section 2.1.1, the draft states: > > Note, that this directive doesn't affect authorization id > ("authzid") which is always in UTF-8. > > It is not the place of the mechanism spec to say anything about the > character set of the authorization ID; the mechanism should treat the > authorization ID as an opaque string and leave it up to the > application to specify the meaning of the authorization id. We have to be clear that for the protocols that use the same format for authentication and authorization ids, "authzid" is in UTF-8 and MUST NOT be converted to ISO-8859-1 as username/password are. This doesn't belong to protocol profiles either, I don't think we should special case DIGEST-MD5 in all protocol profiles. > In section 2.1.2.1, is exchange protected against a downgrade attack > from auth-conf, auth-int to auth? > I.E. Looking at the definition of a2 and response, I see where the > client value of qop is used, but not > the server supplied qop options. You are right, server supplied list of supported qop options is not protected. An attacker can remove all but the weakest (i.e. "auth"). > The security discussion seems inadequate. Suggestions? Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKQnJM009099 for ; Mon, 31 Mar 2003 12:26:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VKQnd8009098 for ietf-sasl-bks; Mon, 31 Mar 2003 12:26:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKQlJM009089 for ; Mon, 31 Mar 2003 12:26:48 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E1B98152124; Mon, 31 Mar 2003 15:25:53 -0500 (EST) To: ietf-sasl@imc.org Cc: ekr@rtfm.com Subject: security report for sasl digest-md5 From: Sam Hartman Date: Mon, 31 Mar 2003 15:25:53 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: During the SASL working group meeting at IETF 56, Eric Rescorla and I agreed to review the security of cipher usage in the digest-md5 SASL mechanism draft (draft-ietf-sasl-rfc2831bis). We have reached the following conclusions: 1) Instructions on how to use rc4 are unclear; an implementation might read the draft and assume that the PRNG should be initialized for every message sent. This would allow an attacker to retrieve the xor of multiple plaintext messages given the ciphertext and in most situations would completely compromise confidentiality. 2) The use of CBC is unclear. The draft does not specify whether the IV is reinitialized from one message to the next or whether the the last block of ciphertext becomes the IV of the next message. From a security standpoint the IV should not be reinitialized and instead should be chained between messages. 3) The handling of parity bits is significantly different from other protocols that specify how to set up keys and may lead to confusion. 4) Part of the key material is used as the IV for the 3DES cipher. 5) As previously discussed on the SASL list, the protocol is vulnerable to CBC chaining issue (the Rogaway attack). 6) Implementation guidance on avoiding timing attacks related to verifying padding before performing the MAC operations needs to be given. See http://lasecwww.epfl.ch/memo_ssl.shtml. Since existing implementations of the RC4 cipher do preserve PRNG state between messages, there is no technical objection to retaining the existing RC4 cipher or even to making it mandatory to implement. An appropriate document for a normative reference will need to be found and the text will need to be clarified if the working group wishes to proceed in this direction. We recommend that the working group deprecate the existing DES and 3DES ciphers. An AES cipher should be specified. The AES cipher can either use counter mode or avoid the CBC chaining attack in some other way such as the addition of random text to each message. The AES cipher should not use key material as part of the IV. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHaMJM029818 for ; Mon, 31 Mar 2003 09:36:22 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VHaMcj029817 for ietf-sasl-bks; Mon, 31 Mar 2003 09:36:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHaKJM029813 for ; Mon, 31 Mar 2003 09:36:21 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A3AAD152124; Mon, 31 Mar 2003 12:35:28 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft minutes for IETF 56 SASL working group meeting Message-Id: <20030331173528.A3AAD152124@konishi-polis.mit.edu> Date: Mon, 31 Mar 2003 12:35:28 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send any corrections; the corrected minutes will be submitted later this week for the proceedings. Minutes based on notes from Chris Newman and Sam Hartman. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHTHJM029698 for ; Mon, 31 Mar 2003 09:29:17 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VHTH6I029697 for ietf-sasl-bks; Mon, 31 Mar 2003 09:29:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHTFJM029693 for ; Mon, 31 Mar 2003 09:29:16 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1B4B4152124; Mon, 31 Mar 2003 12:28:23 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft minutes for IETF 56 SASL working group meeting Message-Id: <20030331172823.1B4B4152124@konishi-polis.mit.edu> Date: Mon, 31 Mar 2003 12:28:23 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send any corrections; the corrected minutes will be submitted later this week for the proceedings. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PEel018134 for ietf-sasl-bks; Tue, 25 Mar 2003 06:40:47 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PEekg18129 for ; Tue, 25 Mar 2003 06:40:46 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h2PEek3c010324 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA11352 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2PEej0x001925 for ; Tue, 25 Mar 2003 09:40:46 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id JAA16446; Tue, 25 Mar 2003 09:40:45 -0500 (EST) Date: Tue, 25 Mar 2003 09:40:45 -0500 (EST) Message-Id: <200303251440.JAA16446@tir-na-nogth.mit.edu> From: Sam Hartman To: ietf-sasl@imc.org Subject: Comments on draft-ietf-sasl-rfc2831 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In section 2.1.1, the draft states: Note, that this directive doesn't affect authorization id ("authzid") which is always in UTF-8. It is not the place of the mechanism spec to say anything about the character set of the authorization ID; the mechanism should treat the authorization ID as an opaque string and leave it up to the application to specify the meaning of the authorization id. In section 2.1.2.1, is exchange protected against a downgrade attack from auth-conf, auth-int to auth? I.E. Looking at the definition of a2 and response, I see where the client value of qop is used, but not the server supplied qop options. The security discussion seems inadequate. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2O0vhP10859 for ietf-sasl-bks; Sun, 23 Mar 2003 16:57:43 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O0vfg10851 for ; Sun, 23 Mar 2003 16:57:41 -0800 (PST) Received: from messagingdirect.com (actually [66.222.133.179]) by woozle.isode.com (remote) with ESMTP; Mon, 24 Mar 2003 00:57:03 +0000 Message-ID: <3E7E57DC.7137D4CC@messagingdirect.com> Date: Sun, 23 Mar 2003 17:57:00 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: SASL WG Subject: Re: [SASL] Comments about draft-ietf-sasl-plain-00.txt References: <3E7E1FF2.309D8DAA@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: More comments below. Alexey Melnikov wrote: > 2. PLAIN SASL mechanism > > The mechanism consists of a single message from the client to the > server. The client sends the authorization identity (identity to > login as), followed by a NUL character, followed by the authentication > identity (identity whose password will be used), followed by a NUL > character, followed by the clear-text password. The client leaves > the authorization identity empty if wishes the server to derive the > authorization identity from the provided the authentication identity. Last line: drop "the" before "authentication identity". > Appendix A. Changes since RFC 2595 > > The specification details how the server is to compare client-provided > character strings with stored character strings. I suggest that the example code be moved to SASLPrep document or the base SASL spec. Or maybe not, as it has some PLAIN specific checks, but some pieces of it are generic and I would hate to cut & paste them into every SASL mechanism that requires SASLPrep. > The ABNF grammar was updated. In particular, the grammar now allows > LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the > authzid, authcid, passwd productions. However, whether these control > characters may be used depends on the string preparation rules > applicable to the production. For authcid, control characters are > prohibited. For passwd, control characters are allowed. IMHO, CRs and LFs must not be allowed in passwords. They are almost impossible to enter in UI and this change might break existing protocols, like ACAP. > For authzid, > one must consult the application-level SASL profile. ...if the one exists. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K4Gcl03944 for ietf-sasl-bks; Wed, 19 Mar 2003 20:16:38 -0800 (PST) Received: from konishi-polis.mit.edu (wl-132-53.wireless.ietf56.ietf.org [130.129.132.53]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K4Gbg03940 for ; Wed, 19 Mar 2003 20:16:37 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2F8A6152124; Wed, 19 Mar 2003 23:16:36 -0500 (EST) To: Lawrence Greenfield Cc: ietf-sasl@imc.org Subject: Re: SASL applicability statement References: <121626579.1048103750@majormajor.ietf56.ietf.org> From: Sam Hartman Date: Wed, 19 Mar 2003 23:16:36 -0500 In-Reply-To: <121626579.1048103750@majormajor.ietf56.ietf.org> (Lawrence Greenfield's message of "Wed, 19 Mar 2003 19:55:50 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think the document should discuss both TLS and SASL, but should refer to a TLS applicability statement being written elsewhere for specific TLS issues. I suspect politically completely combining the documents will be challenging. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K3u7E03394 for ietf-sasl-bks; Wed, 19 Mar 2003 19:56:07 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K3u6g03390 for ; Wed, 19 Mar 2003 19:56:06 -0800 (PST) Received: from majormajor.ietf56.ietf.org (wl-142-65.wireless.ietf56.ietf.org [130.129.142.65]) (user=leg mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2K3u46t007234 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 19 Mar 2003 22:56:08 -0500 Date: Wed, 19 Mar 2003 19:55:50 -0800 From: Lawrence Greenfield To: Sam Hartman , ietf-sasl@imc.org Subject: Re: SASL applicability statement Message-ID: <121626579.1048103750@majormajor.ietf56.ietf.org> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, March 19, 2003 5:52 PM -0500 Sam Hartman wrote: > Do people believe such an applicability statement is useful? Would > someone volunteer to be an editor? It would be useful to have such a statement at times, especially since SASL tends to be underutilized in protocols that could easily make use of it without making any or little over-the-wire changes to them. There are still generic authentication frameworks being developed in protocol specific contexts (iSCSI, some proposals for IPsec). It would be nice if these attempts could instead be guided to strongly considering SASL. But it's not clear to me that (for instance) TLS and SASL should be discussed in separate documents. I think the document would be more useful for non-application area protocols, since the application area has (generally) become much more standardized on TLS and SASL usage. Larry Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JMqj219051 for ietf-sasl-bks; Wed, 19 Mar 2003 14:52:45 -0800 (PST) Received: from konishi-polis.mit.edu (wl-132-53.wireless.ietf56.ietf.org [130.129.132.53]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JMqig19045 for ; Wed, 19 Mar 2003 14:52:44 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 96C09152124; Wed, 19 Mar 2003 17:52:47 -0500 (EST) To: ietf-sasl@imc.org Subject: SASL applicability statement From: Sam Hartman Date: Wed, 19 Mar 2003 17:52:47 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At this week's security directorate meeting, we discussed the need for applicability statements for security protocols that both describe how they should be used in another protocol and when they are appropriate. Such a statement is being developed for TLS. Some people felt that SASL didn't need such a statement because it was sufficiently well understood by the applications area that nothing needed to be said. I and some others at the lunch disagreed and believe that SASL tends to be misused in new protocols that try and adopt it just like other security technologies. The reason this tends not to be a problem is that several people do a good job of looking at SASL usage and fixing problems that we discover. Do people believe such an applicability statement is useful? Would someone volunteer to be an editor? Steve indicated that asking for this work to be added to our charter would be a reasonable thing to do. --Sam Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J0YKl17823 for ietf-sasl-bks; Tue, 18 Mar 2003 16:34:20 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J0YIg17817 for ; Tue, 18 Mar 2003 16:34:18 -0800 (PST) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2J0YK6t023603; Tue, 18 Mar 2003 19:34:20 -0500 Date: Tue, 18 Mar 2003 19:34:20 -0500 (EST) From: Rob Siemborski To: Morteza Ansari cc: Alexey Melnikov , SASL WG Subject: Re: SASL C API meeting? In-Reply-To: <3E77BAD8.1060401@sun.com> Message-ID: References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> <3E77B37C.A8173C85@messagingdirect.com> <3E77BAD8.1060401@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 18 Mar 2003, Morteza Ansari wrote: > > And this is not going to be long. > > > > Anyway, all results will be discussed at SASL WG meeting on Thursday. > > Is this Wed. 18:15? Sorry, Tonight, (Tuesday) 1815. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J01mm16557 for ietf-sasl-bks; Tue, 18 Mar 2003 16:01:48 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J01kg16553 for ; Tue, 18 Mar 2003 16:01:46 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Wed, 19 Mar 2003 00:01:33 +0000 Message-ID: <3E77B37C.A8173C85@messagingdirect.com> Date: Tue, 18 Mar 2003 17:02:04 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Morteza Ansari , SASL WG Subject: Re: SASL C API meeting? References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Tue, 18 Mar 2003, Alexey Melnikov wrote: > > > Any preferences? > > Thursday would be too busy for me, so I would rather do this today or > > Wednesday. > > Wednesday morning at 9:00 (or today) works for me. > > We'll be meeting at 1815 near the message board, and probably getting some > sort of food this evening. And this is not going to be long. Anyway, all results will be discussed at SASL WG meeting on Thursday. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2INjHj16181 for ietf-sasl-bks; Tue, 18 Mar 2003 15:45:17 -0800 (PST) Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2INjGg16177 for ; Tue, 18 Mar 2003 15:45:16 -0800 (PST) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2INjIpf027441; Tue, 18 Mar 2003 18:45:18 -0500 Date: Tue, 18 Mar 2003 18:45:17 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: Morteza Ansari , SASL WG Subject: Re: SASL C API meeting? In-Reply-To: <3E7792F5.500F1EFE@messagingdirect.com> Message-ID: References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> <3E7792F5.500F1EFE@messagingdirect.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 18 Mar 2003, Alexey Melnikov wrote: > Any preferences? > Thursday would be too busy for me, so I would rather do this today or > Wednesday. > Wednesday morning at 9:00 (or today) works for me. We'll be meeting at 1815 near the message board, and probably getting some sort of food this evening. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ILh5j09210 for ietf-sasl-bks; Tue, 18 Mar 2003 13:43:05 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILh3g09206 for ; Tue, 18 Mar 2003 13:43:04 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Tue, 18 Mar 2003 21:42:48 +0000 Message-ID: <3E7792F5.500F1EFE@messagingdirect.com> Date: Tue, 18 Mar 2003 14:43:17 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Morteza Ansari CC: SASL WG Subject: Re: SASL C API meeting? References: <3E777F2E.854166@messagingdirect.com> <3E7791C9.8020008@sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Morteza ANSI wrote: > I think that would be a good idea. Any preferences? Thursday would be too busy for me, so I would rather do this today or Wednesday. Wednesday morning at 9:00 (or today) works for me. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ILRGv08598 for ietf-sasl-bks; Tue, 18 Mar 2003 13:27:16 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILREg08593 for ; Tue, 18 Mar 2003 13:27:14 -0800 (PST) Received: from messagingdirect.com (actually ca-75-228.wired.ietf56.ietf.org) by woozle.isode.com (remote) with ESMTP; Tue, 18 Mar 2003 21:26:19 +0000 Message-ID: <3E777F2E.854166@messagingdirect.com> Date: Tue, 18 Mar 2003 13:18:54 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SASL WG Subject: SASL C API meeting? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there enough interest to have an informal meeting to discuss changes to SASL C API draft (currently draft-newman-sasl-c-api-01.txt)? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2A2Lb711489 for ietf-sasl-bks; Sun, 9 Mar 2003 18:21:37 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A2LZ311485 for ; Sun, 9 Mar 2003 18:21:35 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2A2LcCa038999 for ; Mon, 10 Mar 2003 02:21:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030309181539.02bc0c80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 09 Mar 2003 18:19:51 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Agenda items for IETF#56 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam and I are now putting together the agenda for IETF#56. Editors (and others), please send us a quick note with I-D name(s), list of outstanding issues you would like to discuss, and a estimate of the time needed. Thanks, Kurt & Sam Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28Kn2v12043 for ietf-sasl-bks; Sat, 8 Mar 2003 12:49:02 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-SEVENTY-FOUR.MIT.EDU [18.187.6.219]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28Kn1312039 for ; Sat, 8 Mar 2003 12:49:01 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 9F443151F11; Sat, 8 Mar 2003 15:49:03 -0500 (EST) To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <200302281225.HAA22735@ietf.org> From: Sam Hartman In-Reply-To: <200302281225.HAA22735@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 28 Feb 2003 07:25:47 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) Date: Sat, 08 Mar 2003 15:49:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems that we really already have enough mechanisms for doing PKI-like things with SASL: * SPKM * LIPKI * TLS + plain What's wrong with using something like LIPKI and negotiating no integrity protection? If your complaint is simply the lack of implementations of LIPKI, then I think that the advantages of having fewer standards outweigh the implementation complexity of LIPKI. If your complaint is that you don't want the complexity of a GSS library, then you should realize that you can implement the LIPKI protocol without actually using a GSSAPI library. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28KGoJ11506 for ietf-sasl-bks; Sat, 8 Mar 2003 12:16:50 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-SEVENTY-FOUR.MIT.EDU [18.187.6.219]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28KGn311502 for ; Sat, 8 Mar 2003 12:16:49 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 5E825151F11; Sat, 8 Mar 2003 15:16:51 -0500 (EST) To: Internet-Drafts@ietf.org Cc: IETF-Announce: ;, ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <200302281225.HAA22735@ietf.org> From: Sam Hartman Date: Sat, 08 Mar 2003 15:16:51 -0500 In-Reply-To: <200302281225.HAA22735@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 28 Feb 2003 07:25:47 -0500") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems that we really already have enough mechanisms for doing PKI-like things with SASL: * SPKM * LIPKI * TLS + plain What's wrong with using something like LIPKI and negotiating no integrity protection? If your complaint is simply the lack of implementations of LIPKI, then I think that the advantages of having fewer standards outweigh the implementation complexity of LIPKI. If your complaint is that you don't want the complexity of a GSS library, then you should realize that you can implement the LIPKI protocol without actually using a GSSAPI library. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27I08508303 for ietf-sasl-bks; Fri, 7 Mar 2003 10:00:08 -0800 (PST) Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by above.proper.com (8.11.6/8.11.6) with SMTP id h27I06308298 for ; Fri, 7 Mar 2003 10:00:07 -0800 (PST) Received: (covad.net 18605 invoked from network); 7 Mar 2003 18:00:07 -0000 Received: from unknown (HELO STUDY) (66.167.13.108) by sun-qmail16 with SMTP; 7 Mar 2003 18:00:07 -0000 To: ietf-sasl@imc.org Cc: Subject: Re: draft-nystrom-http-sasl-06.txt References: <200303051130.GAA25941@ietf.org> <20030305214824.GD3505@manyfish.co.uk> Organization: Seeking Work... From: Scott Lawrence Date: 07 Mar 2003 12:59:55 -0500 In-Reply-To: <20030305214824.GD3505@manyfish.co.uk> Message-ID: Lines: 109 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for posting this notice to ietf-http-wg; I hadn't heard of it before then. I'd like to support most of the comments made by Joe Orton, and amplify on couple. Joe Orton writes: > The 1xx status-codes are reserved for "interim" HTTP responses, but the > draft is now using 102 for a final response here, which won't work (or > at least, isn't compatible with HTTP/1.1). In particular, current clients (including proxies) will just treat a 102 as 100 and probably ignore it. > Draft is confused about whether HTTP auth is per-request or > per-connection. Restrictions on not mixing auth sessions on a single > connection etc should be dropped. This gets to the heart of the issue, really. HTTP is stateless by definition, and the connection has no semantic importance; as such, it can't (in HTTP alone) have any security significance. Earlier efforts to apply SASL to HTTP (drafts long expired) failed on just this point; they tried to wedge SASL mechanisms into the stateless HTTP framework (without success). You've mostly recognized this and gotten a better model, but I think you've not quite taken it far enough, and I think that fixing it actually makes the suggested changes simpler. As you point out in your Introduction, SASL is connection-oriented, so in order to exploit it, the HTTP server must recognize that it is using different rules - that the connection provides the security. This is essentially the same as what we described (and you cited) in RFC 2817. I think therefor that rather than defining new authentication responses you should just use the existing Upgrade framework. I'll try to illustrate how this goes - fleshing it out will require a bit more study (with which I'm happy to help). This example assumes no intermediaries (which would just add the required CONNECT handshaking to make a tunnel over which to do this sequence) Client: Server: 1) (original request) --------------> [determines that SASL service is required] 2) <-------------------------------- 426 Upgrade Required Upgrade: SASL/1.0, HTTP/1.1 Connection: Upgrade WWW-Authenticate: sasl (mechanisms) 3) (request) -----------------------> [changes semantics of Upgrade: SASL/1.0 connection to be SASL but not yet unauthenticated] 4a) <-------------------------------- 101 Switching Protocols Upgrade: SASL/1.0, HTTP/1.1 4b) <-------------------------------- 401 Unauthorized WWW-Authenticate: sasl (sasl challenge) 5) (original request) -------------> Authorization: sasl (sasl-response) Step 1 is the client naively attempting the unauthenticated request. Step 2 is the server insisting on SASL security for it, and including the available mechanisms (if it is willing, it could also include other WWW-Authenticate options such as digest, with the attendant problems in downgrade attacks). The request in step 3 above (which is indicating that the client is SASL-capable, and a desire to activate it) could be either the original request, or a dummy request (OPTIONS would do) that exists just to trigger the protocol upgrade. 4a is the server signalling that the new connection-oriented security rules apply. It's an intermediate response - the client can't send anything in response to it. 4b is the server actually beginning the (mechanism-dependant) SASL handshake by sending the challenge. I suspect that may be possible to fold some of these steps together, by including the SASL challenge with the 426, enabling the client to include Authorization in step 3. > The draft doesn't actually make any requirements on how the server > responds to an OPTIONS request, so it's pointless as as well as > misguided :) Alas, we tried to make a formal definition of the response to OPTIONS that would be programatically useful, but never got there. > The CONNECT-to-port-80/SASL-security-layer-negotiation bits aren't > compatible with HTTP, and Just Won't Work with deployed HTTP proxies, > most of which don't even grok HTTP/1.1 properly. This can be made to work - if SASL is genuinely better and offers value, then perhaps vendors at all levels would find reasons to support them. I have some skepticism about this, but one can hope. In any event, we have what we need in tbe protocol now to determine _why_ (and where) things fail, which is the first step. -- Scott Lawrence Actively seeking work http://skrb.org/scott/ [ is deprecated ] Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25BWZj10174 for ietf-sasl-bks; Wed, 5 Mar 2003 03:32:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25BWY310170 for ; Wed, 5 Mar 2003 03:32:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25941; Wed, 5 Mar 2003 06:30:19 -0500 (EST) Message-Id: <200303051130.GAA25941@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-http-wg@w3.org, ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-06.txt Date: Wed, 05 Mar 2003 06:30:19 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, R. Zuccherato, A. Melnikov Filename : draft-nystrom-http-sasl-06.txt Pages : 32 Date : 2003-3-4 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nystrom-http-sasl-06.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-nystrom-http-sasl-06.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: <2003-3-4174121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174121.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h232Aw027942 for ietf-sasl-bks; Sun, 2 Mar 2003 18:10:58 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h232AuY27936 for ; Sun, 2 Mar 2003 18:10:56 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h232At8q054329; Mon, 3 Mar 2003 02:10:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030302173345.02722560@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 02 Mar 2003 18:09:10 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: "Lawrence Greenfield" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:32 PM 3/2/2003, Ramsay, Ron wrote: >Well, Kurt, you're the only one who has tried to make the TLS session transient. As I noted in my last response, it is now clear to me is that TLS+SASL/PLAIN+closure is not a viable approach. However, I content that it is not obviously so. TLS is transient by design. And application protocol profiles of TLS could be defined which support this approach. And existing TLS and SASL libraries would allow implementation of the approach. And there existing implementations of application protocols which do use this approach today. So, I think, my original question was quite reasonable to ask. Personally, I think the answer deserves brief mention in the I-D. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h231WkF27164 for ietf-sasl-bks; Sun, 2 Mar 2003 17:32:46 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h231WjY27160 for ; Sun, 2 Mar 2003 17:32:45 -0800 (PST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Mon, 3 Mar 2003 12:32:49 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hansen-sasl-pki-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Index: AcLhIuxhiR6kYURFS8y1afstPqyX+gAAYnMg From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: "Lawrence Greenfield" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h231WjY27161 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, Kurt, you're the only one who has tried to make the TLS session transient. I go with the author who said it should last for the whole session. You don't put up an Aunt Sally just to knock it down again! Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, 3 March 2003 12:17 To: Ramsay, Ron Cc: Lawrence Greenfield; tony@att.com; ietf-sasl@imc.org Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt At 05:03 PM 3/2/2003, Ramsay, Ron wrote: >I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Good catch. I then say that the I-D should note that one of the reasons why TLS+SASL/PLAIN+closure is that application profiles of TLS define inconsistent TLS closure semantics. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h231JEi26940 for ietf-sasl-bks; Sun, 2 Mar 2003 17:19:14 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h231JCY26935 for ; Sun, 2 Mar 2003 17:19:12 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h231J88q054126; Mon, 3 Mar 2003 01:19:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030302171418.02728f20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 02 Mar 2003 17:17:23 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: "Lawrence Greenfield" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:03 PM 3/2/2003, Ramsay, Ron wrote: >I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Good catch. I then say that the I-D should note that one of the reasons why TLS+SASL/PLAIN+closure is that application profiles of TLS define inconsistent TLS closure semantics. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h2313pd26748 for ietf-sasl-bks; Sun, 2 Mar 2003 17:03:51 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h2313nY26744 for ; Sun, 2 Mar 2003 17:03:49 -0800 (PST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Mon, 3 Mar 2003 12:03:53 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hansen-sasl-pki-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Index: AcLfYI/CtyRFQhVfQdiIx7kpykYX/QBvmhAw From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , "Lawrence Greenfield" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2313oY26745 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Kurt, I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Saturday, 1 March 2003 06:22 To: Lawrence Greenfield Cc: tony@att.com; ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt At 11:02 AM 2/28/2003, Lawrence Greenfield wrote: > Date: Fri, 28 Feb 2003 10:06:54 -0800 > From: "Kurt D. Zeilenga" > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? > >You don't close TLS; you can renegotiate to the NULL cipher. Application-level protocols may permit use the stream after TLS closure. See RFC 2246, Section 7.2.1. LDAPv3 is an example, RFC 2830, of an application-level protocol which explicitly permits such use. Kurt