From owner-ietf-sasl Mon Nov 4 16:02:40 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id QAA18185 for ietf-sasl-bks; Mon, 4 Nov 1996 16:02:40 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id QAA18162 for ; Mon, 4 Nov 1996 16:02:29 -0800 (PST) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.2/8.8.0) id TAA00464 for ietf-sasl@imc.org; Mon, 4 Nov 1996 19:04:55 -0500 Received: via switchmail; Mon, 4 Nov 1996 19:04:55 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 4 Nov 1996 19:03:35 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 4 Nov 1996 19:03:33 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54 via MS.5.6.hogtown.andrew.cmu.edu.sun4_51; Mon, 4 Nov 1996 19:03:31 -0500 (EST) Message-ID: Date: Mon, 4 Nov 1996 19:03:31 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: SASL mechanism registration issue Sender: owner-ietf-sasl@imc.org Precedence: bulk The ietf-sasl mailing list is now accepting posts. The draft SASL specification is draft-myers-auth-sasl-05.txt. The first issue we have to deal with is the registration procedure for SASL mechanisms. Section 5 of the internet-draft currently establishes a first-come first-served registry for SASL mechanims names, keeping the issue of the standardization status of particular SASL mechanism as an issue orthogonal to its name. Some people have stated that the namespaces for standardized and private mechanisms should be segregated. I believe segregating the namespaces will lead to repeats of problems we have already had with segregated namespaces, whereas we have had good experience with combined namespaces. A copy of a message I have previously sent on the topic follows: Date: Mon, 7 Oct 1996 18:09:56 -0400 (EDT) From: John Gardiner Myers To: cat-ietf@mit.edu Subject: Re: SASL Ran Atkinson writes: > I support Ted's suggestion. The de facto reality is that if an > experimental/private namespace isn't made available, some implementers will > just take (without asking IANA or IESG) part of the namespace for their own > use. Said implementers will just take whatever namespace they want without paying attention to experimental/private namespace distinctions. I don't follow your logic: how is segmenting the namespace going to lead to these people registering their names? > There is significant historical precedent (predating but including MIME) in > various IETF standards for the "X-" prefix to be explicitly set aside for > private uses or experimental uses. There is significant experience with problems caused by this "X-" prefix. Over in the NNTP WG, they're right now facing the problem that there are a number of commands, such as XOVER, which are in wide deployment and which should be standardized, but which have a name in the wrong namespace. Changing the name would cause widespread disruption in the installed base. [[Irrelevant paragraph removed.]] In ESMTP, the specification had to at one point be changed retroactively to allow Experimental extensions to use the non-X namespace when it became apparent that there was no other way for an experimental extension to later become standardized. There is still the lurking problem that some day the X- namespace issue will prevent a private ESMTP extension from being standardized. There is significant historical precident for permitting private and standard protocols to share the same namespace, using registration to prevent conflicts. A quick scan of the IANA registries shows as examples: * The TCP/UDP ports * The various DNS parameters * IP options * Telnet options -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Tue Nov 5 09:06:34 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id JAA08428 for ietf-sasl-bks; Tue, 5 Nov 1996 09:06:34 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from [165.227.113.247] (phoffman.sc.scruznet.com [165.227.113.247]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id JAA08423 for ; Tue, 5 Nov 1996 09:06:29 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 1996 09:09:14 -0800 To: ietf-sasl@imc.org From: "Paul E. Hoffman" Subject: Re: SASL mechanism registration issue Sender: owner-ietf-sasl@imc.org Precedence: bulk At 4:03 PM -0800 11/4/96, John Gardiner Myers wrote: >The ietf-sasl mailing list is now accepting posts. The draft SASL >specification is draft-myers-auth-sasl-05.txt. For everyone's information, the most current version of the spec is always available at . This gets updated whenever the Internet Drafts site gets updated. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Tue Nov 5 09:15:31 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id JAA08533 for ietf-sasl-bks; Tue, 5 Nov 1996 09:15:31 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id JAA08528 for ; Tue, 5 Nov 1996 09:15:28 -0800 (PST) Received: from eleanor.innosoft.com ("port 35336"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01IBHCMOT4T69ODPL9@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 05 Nov 1996 09:16:56 -0800 (PST) Date: Tue, 05 Nov 1996 09:17:29 -0800 (PST) From: Chris Newman Subject: Re: SASL mechanism registration issue In-reply-to: To: ietf-sasl@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-sasl@imc.org Precedence: bulk On Mon, 4 Nov 1996, John Gardiner Myers wrote: > Some people have stated that the namespaces for standardized and > private mechanisms should be segregated. > > I believe segregating the namespaces will lead to repeats of problems > we have already had with segregated namespaces, whereas we have had > good experience with combined namespaces. A copy of a message I have > previously sent on the topic follows: I agree that the "X-" convention has caused numerous problems and uglyness. I don't wish to see it continue. On the other hand, I think it is important to distinguish published non-proprietary authentication mechanisms from vendor specific proprietary or patented solutions. While there hasn't been much experience in the area, I happen to find the new rules for media types attractive (minus the historical X- garbage). Specificly have a "vnd." prefix with a trivial registration requirement, and reserve other names for protocols intended for wide deployment with a published specification. - Chris From owner-ietf-sasl Tue Nov 5 11:43:20 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id LAA09912 for ietf-sasl-bks; Tue, 5 Nov 1996 11:43:20 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id LAA09907 for ; Tue, 5 Nov 1996 11:43:16 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 1)); Tue, 5 Nov 1996 13:29:46 -0500 Received: by lacroix.wildbear.on.ca from tester.wildbear.on.ca (199.246.132.199::mail daemon,SLmailNT V3.0 (alpha 1)); Tue, 5 Nov 1996 13:29:46 -0500 Message-Id: <3.0.32.19961105133341.00cd5d78@lacroix> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 05 Nov 1996 13:33:42 -0500 To: Chris Newman , ietf-sasl@imc.org From: "Jack De Winter" Subject: Re: SASL mechanism registration issue Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk >I agree that the "X-" convention has caused numerous problems and >uglyness. I don't wish to see it continue. > >On the other hand, I think it is important to distinguish published >non-proprietary authentication mechanisms from vendor specific proprietary >or patented solutions. While there hasn't been much experience in the >area, I happen to find the new rules for media types attractive (minus the >historical X- garbage). Specificly have a "vnd." prefix with a trivial >registration requirement, and reserve other names for protocols intended >for wide deployment with a published specification. At least is might curtail such things as the Microsoft Mail Client trying to support an authentication type of 'twinkie'. ;-) Two things in the base spec I would like to address though: 1) Is it possible for the encryption/authentication examples to include relevant data for a non-existant user. One of the hard parts in implementing these is having a solid example to test against. For example, the SKEY example does not say if it uses MD4/MD5 and does not provide information on what the original password was. Adding this would give a solid beginning test for implementors. Building a couple of examples would be even better. 2) Is it possible to state explicitly whether or not to use MD4/MD5 for the SKEY implementation? Or even have a SKEY-4 and SKEY-5 to distinguish between the two? regards, Jack From owner-ietf-sasl Tue Nov 5 13:47:17 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id NAA11044 for ietf-sasl-bks; Tue, 5 Nov 1996 13:47:17 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id NAA11039 for ; Tue, 5 Nov 1996 13:47:15 -0800 (PST) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.2/8.8.0) id QAA01025 for ietf-sasl@imc.org; Tue, 5 Nov 1996 16:49:46 -0500 Received: via switchmail; Tue, 5 Nov 1996 16:49:45 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 5 Nov 1996 16:48:19 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 5 Nov 1996 16:48:17 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54 via MS.5.6.hogtown.andrew.cmu.edu.sun4_51; Tue, 5 Nov 1996 16:48:15 -0500 (EST) Message-ID: Date: Tue, 5 Nov 1996 16:48:15 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: S/KEY mechanism Sender: owner-ietf-sasl@imc.org Precedence: bulk I believe the base S/Key specification says to use MD4. Actually, I've been considering removing the S/Key mechanism from the base specification, possibly doing an OTP mechanism later. OTP carries information on the hash algorithm used, and there is an OTP rekeying mechanism, which will be necessary for using it with protocols (such as IMAP and SMTP) which treat connections as being relatively cheap. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Tue Nov 5 14:01:16 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id OAA11150 for ietf-sasl-bks; Tue, 5 Nov 1996 14:01:16 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from jimi-hendrix.mcom.com (h-207-1-136-56.netscape.com [207.1.136.56]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id OAA11145 for ; Tue, 5 Nov 1996 14:01:14 -0800 (PST) Received: from jimi-hendrix.mcom.com ([207.1.136.56]) by jimi-hendrix.mcom.com (Netscape Messaging Server 2.0) with SMTP id AAA24959; Tue, 5 Nov 1996 14:03:19 -0700 Date: Tue, 5 Nov 1996 14:03:19 -0800 (PST) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: SASL mechanism registration issue To: Jack De Winter cc: Chris Newman , ietf-sasl@imc.org In-Reply-To: <3.0.32.19961105133341.00cd5d78@lacroix> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk > 1) Is it possible for the encryption/authentication examples > to include relevant data for a non-existant user. One of the > hard parts in implementing these is having a solid example to > test against. For example, the SKEY example does not say if > it uses MD4/MD5 and does not provide information on what the > original password was. Adding this would give a solid beginning > test for implementors. Building a couple of examples would be > even better. > > 2) Is it possible to state explicitly whether or not to use MD4/MD5 > for the SKEY implementation? Or even have a SKEY-4 and SKEY-5 to > distinguish between the two? Having a commercial product which uses S/Key, we've also noticed that this is a deficiency. There is a secondary problem with S/Key in that the count needs to be reset occasionally, and there is no standard protocol which addresses this. I'd like to see both of these handled - hopefully within SASL. The S/Key RFC is MD4 based, but there is no reason why we can't plan for the future. Putting MD5 capability in is the easy one; since we still run under the same framework. Just declare a new type like SKEY+ or something which provides the algorithm as an argument in the server prompt. Under IMAP, this could look like C: A001 AUTHENTICATE SKEY+ S: + 64 C: 64 S: A001 OK S/Key initialize is a stranger beast. It actually needs to live in the application protocol as a separate command unless we can shoe-horn it into SASL. C: A002 SKEYINIT [[count] [seed] [algorithm]] S: 64 C: 64 S: A002 OK This works as long as one provides the rule that SKEYINIT can only be issued in the authenticated state. The algorithm is then used for all subsequent S/Key sessions. Note that here we run into the problem of negotiating which algorithms are supported on both ends; which speaks to a broader problem of changing passwords remotely. Before this list really got going I posted a message to the effect that in both this (s/key) and SSL, we have needs which no longer qualify as "simple" and which stretch SASL quite a bit. Can it be stretched, or do we have to live with it? That's the $64M Q. SASL was born around a simple challenge/response mechanism for authentication, primarily to allow Kerberos and S/Key. SSL is a case where the rules are reversed from Kerberos - one needs to negotiate _encryption_ which may or may not _authenticate_ as a side result. This means that "AUTHENTICATE" or "AUTH" would be overloaded. S/Key basically works but there is more we'd like to see done with it to make it practical. We also have a problem of servers "advertising" their local policy and mechanisms (although at least the mechanisms are advertised in IMAP4rev1). The case I'm thinking of is a server policy which says "we do not accept authentication without a security layer; we support SSL or Kerberos5. If you provide SSL security, you may authenticate with SSL client credentials, LOGIN, SKEY, or CRAM." But this brings a lot of complexity to an otherwise simple challenge/response scheme. I'm prepared for flames which say this isn't the proper place to address these issues. Problem is, no place else is any better. If SASL can't live up to this challenge, it may not be general enough to extend to protocol 'n' - which doesn't make it (SASL) a perfect solution for extendable security. This may be OK and SASL may end up being to security what POP is to IMAP - simple, but not powerful enough for the long haul. Do we need a framework which fits this need? I say yes. Mike Macgirvin Postmaster General Netscape Communications Corporation Mail Server Engineering http://netscape/people/max/ Any views expressed etc., etc. From owner-ietf-sasl Tue Nov 5 14:11:28 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id OAA11298 for ietf-sasl-bks; Tue, 5 Nov 1996 14:11:28 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id OAA11293 for ; Tue, 5 Nov 1996 14:11:26 -0800 (PST) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.2/8.8.0) id RAA01038 for ietf-sasl@imc.org; Tue, 5 Nov 1996 17:13:59 -0500 Received: via switchmail; Tue, 5 Nov 1996 17:13:58 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 5 Nov 1996 17:13:27 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 5 Nov 1996 17:13:25 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54 via MS.5.6.hogtown.andrew.cmu.edu.sun4_51; Tue, 5 Nov 1996 17:13:24 -0500 (EST) Message-ID: <8mTvk4600WBw0NXlI0@andrew.cmu.edu> Date: Tue, 5 Nov 1996 17:13:24 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: vnd.* Sender: owner-ietf-sasl@imc.org Precedence: bulk One difference between media types and SASL mechanisms to keep in mind is that there are expected to be far more media types than SASL mechanisms. We don't need quite all the various little sub-registries that media types have. I personally don't have any problem with Micorosoft calling their mechanism "twinkie"; what I would have a problem with is their then claiming that it makes their authentication process standards-conforming. One could always go to the IANA site and point out where in the registry "twinkie" has a standardization state of "non-standard". In any case, I am a bit more amenable to drawing the line between published/unpublished rather than standard/nonstandard. But then that begs the question of what constitutes a "published" specification. One can always publish a thin (or not so thin) document which refers to some other non-freely-available document for some key part of the protocol. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Tue Nov 5 15:01:58 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id PAA11698 for ietf-sasl-bks; Tue, 5 Nov 1996 15:01:58 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from lacroix.wildbear.on.ca ([199.246.132.198]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id PAA11693 for ; Tue, 5 Nov 1996 15:01:38 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 1)); Tue, 5 Nov 1996 17:59:08 -0500 Received: by lacroix.wildbear.on.ca from tester.wildbear.on.ca (199.246.132.199::mail daemon,SLmailNT V3.0 (alpha 1)); Tue, 5 Nov 1996 17:59:08 -0500 Message-Id: <3.0.32.19961105180258.00690f78@lacroix> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 05 Nov 1996 18:02:59 -0500 To: John Gardiner Myers From: "Jack De Winter" Subject: Re: S/KEY mechanism Cc: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk At 04:48 PM 11/5/96 -0500, you wrote: >I believe the base S/Key specification says to use MD4. > >Actually, I've been considering removing the S/Key mechanism from the >base specification, possibly doing an OTP mechanism later. OTP >carries information on the hash algorithm used, and there is an OTP >rekeying mechanism, which will be necessary for using it with >protocols (such as IMAP and SMTP) which treat connections as being >relatively cheap. Actually, the way it is specified in the current SASL draft can lead on to believe that there are implmentations out there that use SKEY with MD5, and makes mention of this in the spec. But it leaves a lot of ambiguity in the document about whether or not MD5 is valid with SKEY, and if so, makes no allowance to allow for differentiating SKEY based on MD5. regards, Jack From owner-ietf-sasl Tue Nov 5 15:09:44 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.2/8.7.3) id PAA11807 for ietf-sasl-bks; Tue, 5 Nov 1996 15:09:44 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id PAA11801 for ; Tue, 5 Nov 1996 15:09:33 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 1)); Tue, 5 Nov 1996 18:07:08 -0500 Received: by lacroix.wildbear.on.ca from tester.wildbear.on.ca (199.246.132.199::mail daemon,SLmailNT V3.0 (alpha 1)); Tue, 5 Nov 1996 18:07:08 -0500 Message-Id: <3.0.32.19961105181058.00696b7c@lacroix> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 05 Nov 1996 18:10:59 -0500 To: John Gardiner Myers From: "Jack De Winter" Subject: Re: S/KEY mechanism Cc: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk OTP? And rekeying? regards, Jack At 04:48 PM 11/5/96 -0500, you wrote: >I believe the base S/Key specification says to use MD4. > >Actually, I've been considering removing the S/Key mechanism from the >base specification, possibly doing an OTP mechanism later. OTP >carries information on the hash algorithm used, and there is an OTP >rekeying mechanism, which will be necessary for using it with >protocols (such as IMAP and SMTP) which treat connections as being >relatively cheap. From owner-ietf-sasl Tue Nov 19 08:17:59 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.3/8.7.3) id IAA07300 for ietf-sasl-bks; Tue, 19 Nov 1996 08:16:27 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.3/8.7.3) with SMTP id IAA07293 for ; Tue, 19 Nov 1996 08:16:13 -0800 (PST) Received: from ietf.org by ietf.org id aa15628; 19 Nov 96 10:01 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-sasl-pop3-00.txt Date: Tue, 19 Nov 1996 10:01:58 -0500 Message-ID: <9611191001.aa15628@ietf.org> Sender: owner-ietf-sasl@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : POP3 AUTHentication command Author(s) : J. Myers Filename : draft-myers-sasl-pop3-00.txt Pages : 6 Date : 11/18/1996 This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Session Layer [SASL]. Internet-Drafts are 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-myers-sasl-pop3-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-sasl-pop3-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-sasl-pop3-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961118145257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-sasl-pop3-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-sasl-pop3-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118145257.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Nov 19 08:37:59 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.3/8.7.3) id IAA07290 for ietf-sasl-bks; Tue, 19 Nov 1996 08:16:05 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.3/8.7.3) with SMTP id IAA07280 for ; Tue, 19 Nov 1996 08:16:00 -0800 (PST) Received: from ietf.org by ietf.org id aa15434; 19 Nov 96 9:59 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-smtp-auth-04.txt Date: Tue, 19 Nov 1996 09:59:56 -0500 Message-ID: <9611190959.aa15434@ietf.org> Sender: owner-ietf-sasl@imc.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP Service Extension for Authentication Author(s) : J. Myers Filename : draft-myers-smtp-auth-04.txt Pages : 7 Date : 11/18/1996 This document defines an extension to the SMTP service whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL]. Internet-Drafts are 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-myers-smtp-auth-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-smtp-auth-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-smtp-auth-04.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961118110730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-smtp-auth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-smtp-auth-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118110730.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Nov 19 08:38:31 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.3/8.7.3) id IAA07291 for ietf-sasl-bks; Tue, 19 Nov 1996 08:16:07 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.3/8.7.3) with SMTP id IAA07282 for ; Tue, 19 Nov 1996 08:16:02 -0800 (PST) Received: from ietf.org by ietf.org id aa15462; 19 Nov 96 10:00 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-auth-sasl-06.txt Date: Tue, 19 Nov 1996 10:00:07 -0500 Message-ID: <9611191000.aa15462@ietf.org> Sender: owner-ietf-sasl@imc.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Authentication and Security Layer Author(s) : J. Myers Filename : draft-myers-auth-sasl-06.txt Pages : 13 Date : 11/18/1996 This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection. Internet-Drafts are 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-myers-auth-sasl-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-auth-sasl-06.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961118111104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-auth-sasl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-auth-sasl-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118111104.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Dec 10 13:40:11 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.3/8.7.3) id NAA17809 for ietf-sasl-bks; Tue, 10 Dec 1996 13:40:11 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.3/8.7.3) with ESMTP id NAA17800 for ; Tue, 10 Dec 1996 13:39:48 -0800 (PST) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.2/8.8.2) id QAA00994 for ietf-sasl@imc.org; Tue, 10 Dec 1996 16:41:41 -0500 Received: via switchmail; Tue, 10 Dec 1996 16:41:40 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 10 Dec 1996 16:41:13 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 10 Dec 1996 16:41:10 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54 via MS.5.6.hogtown.andrew.cmu.edu.sun4_51; Tue, 10 Dec 1996 16:41:05 -0500 (EST) Message-ID: Date: Tue, 10 Dec 1996 16:41:05 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: MAILING LIST LAST CALL Sender: owner-ietf-sasl@imc.org Precedence: bulk Given the lack of a concrete proposal to the registration scheme in draft-myers-auth-sasl-06.txt, and also given the lack of discussion leading towards such a proposal, I am now issuing a mailing list last call for the following documents. draft-myers-sasl-pop3-00.txt draft-myers-smtp-auth-04.txt draft-myers-auth-sasl-06.txt Unless I get a significant negative response by this time next week, I intend to request an appropriate Area Director to review the documents and issue an IETF-wide Last Call. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Mon Dec 16 14:22:54 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA08743 for ietf-sasl-bks; Mon, 16 Dec 1996 14:22:54 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id OAA08738 for ; Mon, 16 Dec 1996 14:22:51 -0800 (PST) Received: from eleanor.innosoft.com ("port 49143"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.0-8 #8694) id <01ID2X8T7QKMA8C9QW@INNOSOFT.COM>; Mon, 16 Dec 1996 14:22:35 -0800 (PST) Date: Mon, 16 Dec 1996 14:23:22 -0800 (PST) From: Chris Newman Subject: Re: MAILING LIST LAST CALL In-reply-to: To: ietf-sasl@imc.org Cc: John C Klensin Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-sasl@imc.org Precedence: bulk On Tue, 10 Dec 1996, John Gardiner Myers wrote: > [mailing list last call on:] > draft-myers-auth-sasl-06.txt The S/Key mechanism should state explicitly that it uses MD4, or be flushed from the base spec. I'd like to see CRAM-MD5 folded into the base SASL spec, if John Klensin agrees. The mechanisms in the document should be defined according the the registration template, so they can better serve as examples. I'm looking forward to seeing this go standards track ASAP, and don't consider any of the above three suggestions show stoppers. From owner-ietf-sasl Mon Dec 16 14:30:02 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA08818 for ietf-sasl-bks; Mon, 16 Dec 1996 14:30:02 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id OAA08810 for ; Mon, 16 Dec 1996 14:29:58 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Mon, 16 Dec 1996 17:23:32 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Mon, 16 Dec 1996 17:23:31 -0500 Message-Id: <3.0.32.19961216172757.00db42bc@lacroix> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 16 Dec 1996 17:27:58 -0500 To: Chris Newman , ietf-sasl@imc.org From: "Jack De Winter" Subject: Re: MAILING LIST LAST CALL Cc: John C Klensin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk >The S/Key mechanism should state explicitly that it uses MD4, or >be flushed from the base spec. > >I'd like to see CRAM-MD5 folded into the base SASL spec, if John Klensin >agrees. > >The mechanisms in the document should be defined according the the >registration template, so they can better serve as examples. > >I'm looking forward to seeing this go standards track ASAP, and don't >consider any of the above three suggestions show stoppers. I concur. One of my problems with SKEY has always been the 'use MD4 but a lot of implementations use MD5' line in the SKEY spec. And as someone who just implemented CRAM, it is very easy to do as soon as you make sure you read the example in the spec very carefully. Also, since San Jose, I assume that we now have a IANA process for registering new SASL types, and that should explicitly be spelled out, as well as what to do in cases of collision and proprietary or testing extensions. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products. From owner-ietf-sasl Mon Dec 16 14:50:39 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA09022 for ietf-sasl-bks; Mon, 16 Dec 1996 14:50:39 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from jimi-hendrix.mcom.com (h-207-1-136-56.netscape.com [207.1.136.56]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id OAA09017 for ; Mon, 16 Dec 1996 14:50:37 -0800 (PST) Received: from jimi-hendrix.mcom.com ([207.1.136.56]) by jimi-hendrix.mcom.com (Netscape Messaging Server 2.0) with SMTP id AAA1767; Mon, 16 Dec 1996 14:50:13 -0700 Date: Mon, 16 Dec 1996 14:50:12 -0800 (PST) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: MAILING LIST LAST CALL To: Jack De Winter cc: Chris Newman , ietf-sasl@imc.org, John C Klensin In-Reply-To: <3.0.32.19961216172757.00db42bc@lacroix> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk > One of my problems with SKEY has always been the 'use MD4 but > a lot of implementations use MD5' line in the SKEY spec. IMAO, S/Key will probably be subsumed rapidly by OTP; which allows for passing the hash algorithm name between the comm end-points and also allows resets (when coupled with the OTP extended response draft). So AUTH=SKEY will certainly be MD4 and only MD4. Anybody using MD5 or SHA hashes should use OTP instead. The OTP negotiation itself is similiar enough to S/Key that folks can probably implement at least the authentication phases based on how s/key works today. The only question mark is the status of the OTP extended response draft, which might affect how resets are done. (Maybe this has stabilized, I haven't looked for a few weeks). Mike Macgirvin Postmaster General Netscape Communications Corporation Mail Server Engineering http://netscape/people/max/ Any views expressed etc., etc. From owner-ietf-sasl Wed Dec 18 13:28:20 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id NAA08195 for ietf-sasl-bks; Wed, 18 Dec 1996 13:28:20 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-sasl using -f Received: from po11.andrew.cmu.edu (PO11.ANDREW.CMU.EDU [128.2.10.111]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id NAA08190 for ; Wed, 18 Dec 1996 13:28:18 -0800 (PST) Received: (from postman@localhost) by po11.andrew.cmu.edu (8.8.2/8.8.2) id QAA00897 for ietf-sasl@imc.org; Wed, 18 Dec 1996 16:28:32 -0500 (EST) Received: via switchmail; Wed, 18 Dec 1996 16:28:32 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 18 Dec 1996 16:27:06 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 18 Dec 1996 16:27:05 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54 via MS.5.6.hogtown.andrew.cmu.edu.sun4_51; Wed, 18 Dec 1996 16:27:03 -0500 (EST) Message-ID: Date: Wed, 18 Dec 1996 16:27:03 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: last cut of SASL Sender: owner-ietf-sasl@imc.org Precedence: bulk I'm putting out an -07 version of the base spec and will be immediately asking for it to go to Last Call. This version fixes a typo and clarifies that the SKEY mechanism is for S/Key used with MD4. > The mechanisms in the document should be defined according the the > registration template, so they can better serve as examples. The registration of a mechanism and its description are two different things. When the draft gets approved, I will be sending in registrations for the mechanism defined in the document, referring to the document for the mechanisms' description. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Fri Feb 28 12:19:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA11910 for ietf-sasl-bks; Fri, 28 Feb 1997 12:19:46 -0800 (PST) Received: from motorcity4.lotus.com ([204.166.182.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA11906 for ; Fri, 28 Feb 1997 12:19:42 -0800 (PST) From: Rachel_Snyer@motorcity2.lotus.com Received: from motorcity2.lotus.com by motorcity4.lotus.com (Lotus SMTP MTA v1.05 (274.9 11-27-1996)) with SMTP id 8525644C.006FEBA5; Fri, 28 Feb 1997 15:22:28 -0400 Received: by motorcity2.lotus.com(Lotus SMTP MTA v1.05b4 (319.2 2-8-1997)) id 8525644C.007094B4 ; Fri, 28 Feb 1997 15:29:41 -0400 X-Lotus-FromDomain: NOTES@ALPHABETA To: ietf-sasl@imc.org Message-ID: <8525644C.006F8CB5.00@motorcity2.lotus.com> Date: Fri, 28 Feb 1997 15:31:07 -0400 Subject: please SUBSCRIBE: Imap subscribe@lotus.com Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@imc.org Precedence: bulk Please subscribe user to list : imap subscribe@lotus.com From owner-ietf-sasl Tue Mar 18 17:46:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA05330 for ietf-sasl-bks; Tue, 18 Mar 1997 17:46:06 -0800 (PST) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA05326 for ; Tue, 18 Mar 1997 17:46:03 -0800 (PST) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 17:52:51 -0800 To: ietf-sasl@imc.org From: "Paul E. Hoffman" Subject: SSL under SASL Sender: owner-ietf-sasl@imc.org Precedence: bulk Hi, again. I'm going to be writing drafts on how to do SMTP, IMAP, and POP over SSL. I sent the following message to the ietf-tls list earlier this week: ========================= Greetings. I'm going to be writing drafts on how to run the three primary email protocols (SMTP, IMAP, and POP) over TLS. There is already an active draft out for these three protocols that acts as a "front end" to authentication and security protocols. This over-protocol, SASL, doesn't yet have a mechanism for TLS built into it: it now covers Kerberos 4, GSSAPI, and S/Key. In talking to the SASL author about this, he has no strong feeling whether I should add TLS to SASL or just come up with a set of non-SASL proposals for SMTP/IMAP/POP over TLS. I'd like some TLS-savvy folks to take a look at the SASL draft and discuss the merits of calling TLS from SASL on the SASL mailing list. I don't think it is necessary to Cc this list on the discussion; I'll summarize the results later. To find the current SASL drafts and info on how to subscribe to the SASL mailing list, please see . Thanks in advance. ========================= Unfortunately, only two people signed up to this (ief-sasl) list in response to this. I'd like to hear people's thoughts here before I decide whether to use SASL as the mechanism for SSL or whether to do an orthogonal approach. My biggest concern is the last paragraph of section 3. Part of it says "Each buffer is transferred over the connection as a stream of octets prepended with a four octet field in network byte order that represents the length of the following buffer." If I'm not mistaken, this means that if someone has implemented SSL, they must *also* add this count to each buffer. That would make it very difficult for people to use out-of-the-box SSL kits. Comments? --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Tue Mar 18 20:40:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA06748 for ietf-sasl-bks; Tue, 18 Mar 1997 20:40:15 -0800 (PST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA06744 for ; Tue, 18 Mar 1997 20:40:11 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Tue, 18 Mar 1997 23:35:22 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Tue, 18 Mar 1997 23:35:20 -0500 Message-Id: <3.0.32.19970318234131.00d6c2a0@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Mar 1997 23:41:32 -0500 To: ietf-sasl@imc.org From: "Jack De Winter" Subject: anyone else on this list? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk how many people are on this list? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-sasl Wed Mar 19 12:36:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17501 for ietf-sasl-bks; Wed, 19 Mar 1997 12:36:48 -0800 (PST) Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA17497 for ; Wed, 19 Mar 1997 12:36:45 -0800 (PST) Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0w7SCt-000UmfC; Wed, 19 Mar 97 13:43 MST Received: from picasso.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0w7SAq-000RXNC; Wed, 19 Mar 97 13:41 MST Received: from picasso.esys.ca (picasso [198.161.92.3]) by picasso.esys.ca (8.8.5/8.8.5) with SMTP id NAA10440; Wed, 19 Mar 1997 13:41:27 -0700 (MST) From: Mark Miller Reply-To: Mark.Miller@esys.ca To: Jack De Winter cc: ietf-sasl@imc.org Subject: Re: anyone else on this list? In-Reply-To: <3.0.32.19970318234131.00d6c2a0@lacroix.wildbear.on.ca> Message-ID: Date: Wed, 19 Mar 1997 13:41:27 -0700 (MST) X-Mailer: Simeon for OSF/1 Motif Version 4.1.1b1 Build (5) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk ++count; Mark. On Tue, 18 Mar 1997 23:41:32 -0500 Jack De Winter wrote: > how many people are on this list? > > regards, > Jack > ------------------------------------------------- > Jack De Winter - Wildbear Consulting, Inc. > (519) 576-3873 http://www.wildbear.on.ca/ > > Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------- Mark Miller Mark.Miller@esys.ca From owner-ietf-sasl Wed Mar 19 15:15:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA19017 for ietf-sasl-bks; Wed, 19 Mar 1997 15:15:34 -0800 (PST) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA19013; Wed, 19 Mar 1997 15:15:26 -0800 (PST) Message-Id: In-Reply-To: <3.0.32.19970318234131.00d6c2a0@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Mar 1997 15:22:20 -0800 To: "Jack De Winter" , ietf-sasl@imc.org From: "Paul E. Hoffman" Subject: Re: anyone else on this list? Sender: owner-ietf-sasl@imc.org Precedence: bulk At 8:41 PM -0800 3/18/97, Jack De Winter wrote: >how many people are on this list? Believe it or not, 46. *Someone* out there must have an opinion about SSL under SASL... --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Wed Mar 19 16:29:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA19505 for ietf-sasl-bks; Wed, 19 Mar 1997 16:29:36 -0800 (PST) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA19500; Wed, 19 Mar 1997 16:29:34 -0800 (PST) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0b2) with SMTP id AAA13969; Wed, 19 Mar 1997 16:32:55 -0800 Date: Wed, 19 Mar 1997 16:32:55 -0800 (PST) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: anyone else on this list? To: "Paul E. Hoffman" cc: Jack De Winter , ietf-sasl@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk > Believe it or not, 46. *Someone* out there must have an opinion about SSL > under SASL... Yes, actually, but too busy to respond in depth currently. I've discussed this offline with John Meyers and Larry Osterman (Microsoft) several months back. The main protocol issue is the one pointed out in your earlier message, i.e. framing and the size field. The secondary issue, and the reason Netscape isn't pushing real hard on this right now is the problem of session hijacking. It would be the responsibility of the _client_ to refuse to fall back on lesser forms of authentication if a server which was previously known to provide an SSL mechanism all of a sudden doesn't. (The assumption is the session could be hijacked and a phony CAPABILITY response returned, minus AUTH=SSL - in the case of IMAP). This puts the burden on the client to know in advance the supported auth mechanisms. It is the prevailing opinion here that this makes the ability to go from plaintext to "secure" fundamentally flawed. We are therefore assuming a reserved port. This actually works quite well in the IMAP model because with SSLv3 client authentication, we can issue a PREAUTH banner if the client certificate maps to one we will accept. Otherwise, a normal password login may be done over the secured channel. Another lesser concern is that SSL is primarily a stream protection mechanism, where client authentication is secondary. This doesn't quite fit the SASL model which general assumes the opposite. SASL is an authentication mechansim, and stream protection is secondary. It's also optional, under Kerberos anyway. SASL also - while providing a list of authentication mechanisms, doesn't allow one to specify the preferred or perhaps enforced order of them. It also doesn't map easily onto directory services, where credentials could be mapped to specific types of authentication. For instance, under LDAP, the "password" field of the typical inetOrg person typically also defines and includes the encryption algorithm. For us to announce (again assuming IMAP) a list of authentication types before knowing the identity of the principal, we may be providing bogus information because only one type might ulitmately succeed; that or those which the directory service recognizes for this particular individual. In other words, despite SASL's elegance in theory, and with a known subset of auth services like Kerberos and perhaps GSSAPI and S/KEY, in practice, and once you step outside those boundaries, it can be a bloody pain in the arse. /* ==================== PERSONAL OPINION of ======================== */ /* Mike "The MAX" Macgirvin mailto:MAX@Netscape.COM */ /* Postmaster General http://www.netscape.com/people/max/ */ /* Messaging Server Development Netscape Communications Corporation */ /* ================================================================= */ From owner-ietf-sasl Wed Mar 19 18:00:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA20123 for ietf-sasl-bks; Wed, 19 Mar 1997 18:00:15 -0800 (PST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA20119 for ; Wed, 19 Mar 1997 18:00:11 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Wed, 19 Mar 1997 20:55:41 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Wed, 19 Mar 1997 20:55:39 -0500 Message-Id: <3.0.32.19970319210127.00d66fc4@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 21:01:30 -0500 To: ietf-sasl@imc.org From: "Jack De Winter" Subject: Re: anyone else on this list? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk Sent this to Paul personally, instead of Paul and the list... regards, Jack >>From phoffman@imc.org Wed Mar 19 20:14:31 1997 >Date: Wed, 19 Mar 1997 17:25:27 -0800 >To: "Jack De Winter" >From: "Paul E. Hoffman" >Subject: Re: anyone else on this list? > >Jack, I noticed that you sent this to me personally. Given that someone >from Netscape just said pretty much the opposite as you, I think you should >send this to the list as well. > >--Paul Hoffman > >>At 03:22 PM 3/19/97 -0800, you wrote: >>>At 8:41 PM -0800 3/18/97, Jack De Winter wrote: >>>>how many people are on this list? >>> >>>Believe it or not, 46. *Someone* out there must have an opinion about SSL >>>under SASL... >> >>okay... my opinion is that ANY authentication/encryption thing should be >>done under SASL. SASL is a great portable framework for adapting a whole >>slew of interfaces to one interfacing method. >> >>That being said, is there anything in the specs for SSL that would forbid >>it to be "switched on" when negotiated, as opposed to from the beginning of >>the session? Would this be against what it is set up for with HTTP? Does >>it need anything outside of the given protocol implementing SASL to function >>properly? >> >>regards, >>Jack >>------------------------------------------------- >>Jack De Winter - Wildbear Consulting, Inc. >>(519) 576-3873 http://www.wildbear.on.ca/ >> >>Author of SLMail for 95 & NT (http://www.seattlelab.com/) > > > > > > ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-sasl Thu Mar 20 09:23:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA28299 for ietf-sasl-bks; Thu, 20 Mar 1997 09:23:06 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA28283 for ; Thu, 20 Mar 1997 09:23:03 -0800 (PST) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IGPYAKN2O68WWP4Q@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 20 Mar 1997 09:26:02 PST Date: Thu, 20 Mar 1997 09:27:15 -0800 (PST) From: Chris Newman Subject: Re: anyone else on this list? In-reply-to: <3.0.32.19970319210127.00d66fc4@lacroix.wildbear.on.ca> To: ietf-sasl@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk SSL has a number of other problems. I doubt it permits both authentication and authorization as the SASL kerberos mechanism does. Specificly, it's useful to have an authentication credential that's capable of authorizing access to multiple accounts. This is especially important for proxy operations. In addition, SSL is primarily used in an RSA framework. This requires patent blood money, and thanks to RSA's rather annoying licensing rules it's nearly impossible to get a "site license" for RSA. By the IETF's rules, that would tend to rule out standardization of any RSA-only mechanism. SSL is currently a session/presentation level mechanism, while SASL is an application level mechanism. Trying to fit these two different paradigms together isn't easy, either. It's probably worth trying to fit SSL under SASL to get the nice authentication/encryption plug-in model that SASL provides and to avoid SSL's excessive use of reserved ports in the case of IMAP, POP and SMTP. It's probably a toss up whether to try to shoehorn SSL's session layer on top of SASL's or to make an exception to SASL and replace its session layer with SSL's session layer. Pick one and see how it implements. From owner-ietf-sasl Thu Mar 20 12:38:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA00284 for ietf-sasl-bks; Thu, 20 Mar 1997 12:38:50 -0800 (PST) Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA00280 for ; Thu, 20 Mar 1997 12:38:47 -0800 (PST) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.2/8.8.2) id PAA15302 for ietf-sasl@imc.org; Thu, 20 Mar 1997 15:42:36 -0500 Received: via switchmail; Thu, 20 Mar 1997 15:42:33 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 20 Mar 1997 15:41:19 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 20 Mar 1997 15:41:12 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 20 Mar 1997 15:41:12 -0500 (EST) Message-ID: Date: Thu, 20 Mar 1997 15:41:12 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: TLS/SASL Sender: owner-ietf-sasl@imc.org Precedence: bulk > In talking to the SASL author about this, he has no strong feeling whether > I should add TLS to SASL or just come up with a set of non-SASL proposals > for SMTP/IMAP/POP over TLS. I think a better way to charactarize my opinion is that I am not dead-set on using SASL to the exclusion of considering other alternatives. There are numerous possible approaches, each with its advantages and disadvantages. These need to be discussed. > That would make it very difficult for people to use out-of-the-box > SSL kits. We should not put the cart before the horse. If, as I believe, existing out-of-the-box SSL kits do not adequately solve the problem, we should not be driven by what out-of-the-box SSL kits can do. We should be driven by what solves the problem. A summary of the possible approaches are: 1) TLS on separate port. Advantages: 1a) can use SSL kits "out of the box" Disadvantages: 1b) Consumes an additional port per protocol. 1c) Does not include a mechanism to communicate an authorization identity (userid) separate from user credentials. (This is necessary to handle cases such as where an admin or proxy is acting on behalf of another user.) 1d) Does not necessarily authenticate the user, leading to different parts of the authentication being handled at different layers. (e.g. server authentication at SSL layer, user authentication using plaintext passwords at the protocol layer.) 2) Add a command to "turn on" TLS Advantages: 2a) Less bit twiddling than SSL under SASL. 2b) Doesn't consume additional port Disadvantages: 2c) Same as 1c (communicate userid) 2d) Same as 1d (authentication spread over multiple layers) 2e) If no acceptable common TLS mechanism can be negotiated, attempting to use a non-TLS authentication mechanism requires closing and re-opening the connection. 2f) Differences in the framing for TLS and SASL requires a slightly more complex I/O routines for applications which use non-blocking or asynchronous I/O. 3) TLS under SASL Advantages: 3a) More flexible choice of authentication/security mechanisms. (e.g. Don't get tied to RSA) 3b) Same as 2b (doesn't consume additional port) 3c) Converse of 1c (can communicate userid) 3d) Converse of 1d (authentication is a single layer, useful to the application) Disadvantages: 3e) More bit-twiddling, especially for folks who only care about TLS. 3f) Overlap/mismatch between TLS and SASL. I'm sure others can add to these. The key point I want to get across to those with a SSL/TLS background is that TLS as a framework and as an existing implementation lacks some features/capabilities which are very important to the applications/mail community. I don't have religious convictions on how these capabilities are provided, but I don't see current straight-SSL approaches moving towards providing those capabilities. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Thu Mar 20 13:15:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA00573 for ietf-sasl-bks; Thu, 20 Mar 1997 13:15:11 -0800 (PST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA00569 for ; Thu, 20 Mar 1997 13:15:04 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Thu, 20 Mar 1997 16:10:42 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Thu, 20 Mar 1997 16:10:40 -0500 Message-Id: <3.0.32.19970320161609.00e1f908@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Mar 1997 16:16:11 -0500 To: John Gardiner Myers , ietf-sasl@imc.org From: "Jack De Winter" Subject: Re: TLS/SASL Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk >I'm sure others can add to these. The key point I want to get across >to those with a SSL/TLS background is that TLS as a framework and as >an existing implementation lacks some features/capabilities which are >very important to the applications/mail community. I don't have >religious convictions on how these capabilities are provided, but I >don't see current straight-SSL approaches moving towards providing >those capabilities. I guess from my viewpoint, I would prefer to see everything 'under the auspices of SASL'... face it, having one interface that takes care of the other authentications and encryptions is a lot easier to code to and explain than having this command for this authentication and that command for that encryption. Where this breaks down is applicability. I have heard some verifiable comments from a couple of sources that worry about a SASL-SSL downgrading to a SASL- without warning the user. While I think this is a client and server problem (both should have restrictions to limit the concept of a secure connection and should notify the user if possible), it is still a problem. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-sasl Thu Mar 20 14:28:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA01273 for ietf-sasl-bks; Thu, 20 Mar 1997 14:28:10 -0800 (PST) Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA01269 for ; Thu, 20 Mar 1997 14:28:06 -0800 (PST) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.2/8.8.2) id RAA19116 for ietf-sasl@imc.org; Thu, 20 Mar 1997 17:31:32 -0500 Received: via switchmail; Thu, 20 Mar 1997 17:31:24 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 20 Mar 1997 17:29:31 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 20 Mar 1997 17:29:30 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 20 Mar 1997 17:29:28 -0500 (EST) Message-ID: Date: Thu, 20 Mar 1997 17:29:28 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org In-reply-to: Subject: Session hijacking Sender: owner-ietf-sasl@imc.org Precedence: bulk Mike Macgirvin writes: > The secondary issue, and the reason Netscape isn't pushing real hard > on this right now is the problem of session hijacking. It would be the > responsibility of the _client_ to refuse to fall back on lesser forms of > authentication if a server which was previously known to provide an > SSL mechanism all of a sudden doesn't. (The assumption is the > session could be hijacked and a phony CAPABILITY response returned, > minus AUTH=SSL - in the case of IMAP). This puts the burden on the > client to know in advance the supported auth mechanisms. > It is the prevailing opinion here that this makes the ability to go > from plaintext to "secure" fundamentally flawed. We are therefore assuming > a reserved port. I'm sorry, but this last bit of reasoning is flawed. A separate port does not solve this problem. An active attacker could similarly cause the attempt to connect to the SSL port to fail with "connection refused", causing a client to fall back on lesser forms of authentication on a non-SSL port. No matter how you slice it, both the server and client are responsible for having and imposing some policy on the minimum acceptable security it is willing to use. > Another lesser concern is that SSL is primarily a stream protection > mechanism, where client authentication is secondary. This doesn't > quite fit the SASL model which general assumes the opposite. SASL is > an authentication mechansim, and stream protection is secondary. > It's also optional, under Kerberos anyway. For protocols such as POP/IMAP, client authentication is critical. Effort spent protecting the stream without addressing the client authentication problem is misdirected. You end up with the illusion of solving the "security" problem without actually having done so. Solving authentication without stream protection is a relatively weak quality of security, but it is unfortunately a quality made necessary by export controls. It is roughly the same level of quality as doing stream "protection" with 40-bit crypto. I'm not trying to bash SSL/TLS; it's got some great engineering in it. I just want to point out where some of the assumptions/dogma of current SSL practice are flawed and hopefully engineer the best solution. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Thu Mar 20 14:55:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA01660 for ietf-sasl-bks; Thu, 20 Mar 1997 14:55:27 -0800 (PST) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA01653 for ; Thu, 20 Mar 1997 14:55:20 -0800 (PST) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0b2) with SMTP id AAA1958; Thu, 20 Mar 1997 14:58:45 -0800 Date: Thu, 20 Mar 1997 14:58:45 -0800 (PST) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: TLS/SASL To: John Gardiner Myers cc: ietf-sasl@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk > A summary of the possible approaches are: > > 1) TLS on separate port. > Disadvantages: > > 1b) Consumes an additional port per protocol. No argument. I would point out that there are a huge number of orphaned braindumps populating the reserved port range. We really aren't anywhere close to running out if somebody would just do a gc. > 1c) Does not include a mechanism to communicate an authorization > identity (userid) separate from user credentials. (This is necessary > to handle cases such as where an admin or proxy is acting on behalf of > another user.) This is not built into the application protocol anyway. In fact, I'd say that the opposite is true. Under SSLv3 client auth, there are two possible identities depending on how the server is configured to handle client SSL credentials. It may accept or reject either the SSL credentials and/or the LOGIN (or other AUTHENTICATE) credentials. ...I've actually been working on the framework for a proxy authentication extension to IMAP because the protocol itself does not define a mechanism for this {outside of ACL control}, and customers require it. (If anybody is interested, please reply. I'll publish when a few other folks have reviewed it). > 1d) Does not necessarily authenticate the user, leading to different > parts of the authentication being handled at different layers. > (e.g. server authentication at SSL layer, user authentication using > plaintext passwords at the protocol layer.) Again, the server may be configured in such a way that enforces user authentication in the SSL layer (i.e. issuing a PREAUTH in the IMAP case), or on failure 1. rejecting the client 2. allow a normal login So you have a choice of certificates or passwords or both. This is all a matter of site policy. I suspect many sites will opt for both in the near future while certificate infrastructures are under construction. They gain the immediate advantage of un-sniffable communications and a much greater immunity from session hijacking; and they can still use their existing password based authentication databases. Once they have a certificate infrastructure, (should they choose to) they can turn off the password login. Yes, there could potentially be a layer mismatch, or not... > We should not put the cart before the horse. If, as I believe, > existing out-of-the-box SSL kits do not adequately solve the problem, > we should not be driven by what out-of-the-box SSL kits can do. We > should be driven by what solves the problem. Exactly. Jack De Winter: > I guess from my viewpoint, I would prefer to see everything 'under > the auspices of SASL'... face it, having one interface that takes > care of the other authentications and encryptions is a lot easier to > code to and explain than having this command for this authentication > and that command for that encryption. As I tried to point out in an earlier message, I too would prefer to see this. The concept is elegant. But as I also pointed out, SASL does not provide for the full spectrum of authentication and encryption possibilities because it is at its core an authentication mechanism; and at a minimum would need to be extended to cover a separate encryption function to allow SSL to map to it effectively. To really be viable it also would need to be able to implement and make known site policy on both a per-server and per-user basis. To solve this introduces the same problem John brought up earlier in another context, that of layering. We would conceivable have an application layer trying to deal with system configuration and site policy issues which live elsewhere. Also due to export restrictions, SASL (or at least the encryption algorithms it supports) generally need to be embedded in the application if the application will be exported and contains any munitions - shared libs are a no-no. So the entire concept of plugin authentication is thrown to the wind anyway. This isn't an indictment of SASL so much as one of government policy, but I mention it because it is yet another factor in extensibility. - I'm also not trying to slam SASL. I'm just pointing out my observations over the last year or two in trying to make use of it effectively. I've currently shelved the effort of shoehorning SSL into it; but still willing to do so if we can nail down the couple of issues which make it sticky. jgm: > I'm not trying to bash SSL/TLS; it's got some great engineering in it. > I just want to point out where some of the assumptions/dogma of > current SSL practice are flawed and hopefully engineer the best > solution. - Came in after I had composed the last paragraph - honest... > I'm sorry, but this last bit of reasoning is flawed. A separate port > does not solve this problem. An active attacker could similarly cause > the attempt to connect to the SSL port to fail with "connection > refused", causing a client to fall back on lesser forms of > authentication on a non-SSL port. > No matter how you slice it, both the server and client are responsible > for having and imposing some policy on the minimum acceptable security > it is willing to use. Not if there is no server on that port. It is entirely reasonable and completely justified for site policy to dictate that it is imaps or nada. The client has no say in the matter. > For protocols such as POP/IMAP, client authentication is critical. > Effort spent protecting the stream without addressing the client > authentication problem is misdirected. You end up with the illusion > of solving the "security" problem without actually having done so. I covered this earlier. Client authentication may be enforced by the site mandating SSLv3 client auth or nada. When client and server start exchanging IMAP protocol, they have already both established the other one's identity beyond any reasonable doubt and protected the stream. IMAP only needs to be involved in this effort to the extent of displaying a PREAUTH banner and putting its command loop in the appropriate authenticated state. Apologies for the long-winded reply... From owner-ietf-sasl Thu Mar 20 17:25:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA02876 for ietf-sasl-bks; Thu, 20 Mar 1997 17:25:34 -0800 (PST) Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA02872 for ; Thu, 20 Mar 1997 17:25:31 -0800 (PST) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.2/8.8.2) id UAA23437 for ietf-sasl@imc.org; Thu, 20 Mar 1997 20:29:20 -0500 Received: via switchmail; Thu, 20 Mar 1997 20:29:17 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 20 Mar 1997 20:29:11 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 20 Mar 1997 20:29:09 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 20 Mar 1997 20:29:07 -0500 (EST) Message-ID: <8nASFXK00UMdBcIIoB@andrew.cmu.edu> Date: Thu, 20 Mar 1997 20:29:07 -0500 (EST) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: Re: TLS/SASL In-Reply-To: References: Sender: owner-ietf-sasl@imc.org Precedence: bulk Mike Macgirvin writes: > > 1c) Does not include a mechanism to communicate an authorization > > identity (userid) separate from user credentials. (This is necessary > > to handle cases such as where an admin or proxy is acting on behalf of > > another user.) > > This is not built into the application protocol anyway. I'm not sure what you mean here. Most protocols have an "unauthenticated" and an "authenticated" state. When they get to the "authenticated" state, they have a concept of a userid which is a key used for determining what kind of access they give to the client. With plaintext passwords, the credentials are replayable, so having different authorization and authentication identities was not an issue. With non-replayable credentials, the concept of having an authentication identity separate from the identity in the credentials still fits in with the "something happens and then you're authenticated" model. > In fact, I'd say that the opposite is true. Under SSLv3 client auth, > there are two possible identities depending on how the server is > configured to handle client SSL credentials. It may accept or reject > either the SSL credentials and/or the LOGIN (or other AUTHENTICATE) > credentials. Here you're not talking about separate authentication and authorization identities, you're talking about having two different authentication credentials at two different layers. This is a really messy way of doing things. > ...I've actually been working on the framework for a proxy > authentication extension to IMAP because the protocol itself does > not define a mechanism for this {outside of ACL control}, and > customers require it. I'm surprised. CMU was doing proxy authentication in IMAP years ago, using the mechanisms defined in 1730 and 1731. The SASL framework, along with a SASL mechanism that supports a separate authorization identity and an implementation which knows how to apply a policy on what authentication idenity can use what authorization identiy, supports this. > > 1d) Does not necessarily authenticate the user, leading to different > > parts of the authentication being handled at different layers. > > (e.g. server authentication at SSL layer, user authentication using > > plaintext passwords at the protocol layer.) > > Again, the server may be configured in such a way that enforces user > authentication in the SSL layer (i.e. issuing a PREAUTH in the IMAP case), or > on failure > 1. rejecting the client > 2. allow a normal login > > So you have a choice of certificates or passwords or both. So in the absense of certificates, you have to do an authentication at a different layer. Extremely messy. > But as I also pointed out, SASL does not provide for > the full spectrum of authentication and encryption possibilities because it is > at its core an authentication mechanism; and at a minimum would need to be > extended to cover a separate encryption function to allow SSL to map to it > effectively. In the case of POP and IMAP, encryption without authentication is practically useless. (In the case of SMTP, lack of authentication may be useful, but in a SASL model, this can be handled by authenticating as the anonymous identity.) A mapping of SSL under SASL will likely require some post-traditional-SSL negotiation of an authorization identity and possibly a password (to handle the encrypted-plaintext-password case of classic-SSL.) I personally think it would be cleaner if the first or both of these negotiations were in SSL proper as opposed to being in a SSL-under-SASL spec. This would have the added advantage of being cleaner in a SSL-on-separate-port advantage as well. > To really be viable it also would need to be able to implement and > make known site policy on both a per-server and per-user basis. To > solve this introduces the same problem John brought up earlier in > another context, that of layering. We would conceivable have an > application layer trying to deal with system configuration and site > policy issues which live elsewhere. I'm missing the step explaining how SSL-on-separate-port more easily facilitates dealing with system configuration and site policy issues elsewhere. I know of the argument where one can shut off access to the non-SSL port on a system or firewall basis, but that only lets one set a policy with the same minimums as the SSL protocol itself. Given SSL effectively permits plaintext passwords encrypted with 40-bit keys, this isn't compelling. > Also due to export restrictions, SASL (or at least the encryption > algorithms it supports) generally need to be embedded in the > application if the application will be exported and contains any > munitions - shared libs are a no-no. Similar arguments apply to SSL. SSL libs would similarly need to be embedded in the application. Wherever the policy comes from, it needs to be known by some part of the application. > > No matter how you slice it, both the server and client are responsible > > for having and imposing some policy on the minimum acceptable security > > it is willing to use. > > Not if there is no server on that port. It is entirely reasonable and > completely justified for site policy to dictate that it is imaps or nada. The > client has no say in the matter. If the active attacker fakes a connection refused on imaps and poses as a plain-imap service, it can fool the client into doing weak authentication. It does not matter whether or not the real server supports the plain-imap service. Removing support for the plain-imap service is exactly equivalent to the server imposing a minimum acceptable security policy equivalent to the minimum security of SSL. It is only interesting when the minimum security policy of the site matches the minimum security provied by SSL. > I covered this earlier. Client authentication may be enforced by the site > mandating SSLv3 client auth or nada. This is only interesting when SSLv3 client certificates is the only authentication mechanism to be supported. And it does not address the proxying issue. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Fri Apr 18 06:53:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA01261 for ietf-sasl-bks; Fri, 18 Apr 1997 06:53:49 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA01255 for ; Fri, 18 Apr 1997 06:53:46 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa22135; 18 Apr 97 9:53 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-auth-sasl-09.txt Date: Fri, 18 Apr 1997 09:53:55 -0400 Message-ID: <9704180953.aa22135@ietf.org> Sender: owner-ietf-sasl@imc.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Authentication and Security Layer (SASL) Author(s) : J. Myers Filename : draft-myers-auth-sasl-09.txt Pages : 14 Date : 04/17/1997 This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection. Internet-Drafts are 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-myers-auth-sasl-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-09.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-auth-sasl-09.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970417110115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-auth-sasl-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-auth-sasl-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970417110115.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Apr 18 16:27:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA07877 for ietf-sasl-bks; Fri, 18 Apr 1997 16:27:43 -0700 (PDT) Received: from po7.andrew.cmu.edu (PO7.ANDREW.CMU.EDU [128.2.10.107]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA07873 for ; Fri, 18 Apr 1997 16:27:40 -0700 (PDT) Received: (from postman@localhost) by po7.andrew.cmu.edu (8.8.5/8.8.2) id TAA25524 for ietf-sasl@imc.org; Fri, 18 Apr 1997 19:28:27 -0400 (EDT) Received: via switchmail; Fri, 18 Apr 1997 19:28:26 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 18 Apr 1997 19:28:05 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 18 Apr 1997 19:28:04 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 18 Apr 1997 19:28:01 -0400 (EDT) Message-ID: Date: Fri, 18 Apr 1997 19:28:01 -0400 (EDT) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: SASL draft 09 Sender: owner-ietf-sasl@imc.org Precedence: bulk Draft 08 went out recently, I've just submitted 09 and it should be out soon. After 09 comes out, please review it and quickly give comments. I'd like to get this to IETF Last Call real soon. Changes in 08: * Specified that the null string as an authorization identity means the server should use a default identity based on the authentication credentials. * Changed some GSSAPI v1 language to equivalent GSSAPI v2 language. * Added a "specific issues" section to specify out some edge conditions that the LDAP protocol brought to light. * Moved some of the "initial response" language to the specific issues section. Changed the definitions to be in terms of mechanisms in which the client sends the first data (instead of in terms of mechanisms in which the server sends an initial challenge with no data.) The protocol is the same, the definitions should be clearer. * Added "Appendix A" to discuss the relation of SASL to TLS and IPsec Changes in 09: * Added the definition of the "EXTERNAL" SASL mechanism. * Added more stuff to Appendix A and hopefully made it clearer. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Fri Apr 18 16:34:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA07929 for ietf-sasl-bks; Fri, 18 Apr 1997 16:34:03 -0700 (PDT) Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA07925 for ; Fri, 18 Apr 1997 16:34:00 -0700 (PDT) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.2/8.8.2) id TAA20166 for ietf-sasl@imc.org; Fri, 18 Apr 1997 19:34:34 -0400 Received: via switchmail; Fri, 18 Apr 1997 19:34:28 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 18 Apr 1997 19:34:07 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 18 Apr 1997 19:34:06 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 18 Apr 1997 19:34:05 -0400 (EDT) Message-ID: <0nK0Hhu00UMd1oZ4sE@andrew.cmu.edu> Date: Fri, 18 Apr 1997 19:34:05 -0400 (EDT) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: SASL draft 10 Sender: owner-ietf-sasl@imc.org Precedence: bulk Oops, I seem to be off by one. -09 is out and I recently submitted -10. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Wed Apr 23 07:22:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA11374 for ietf-sasl-bks; Wed, 23 Apr 1997 07:22:51 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.5/8.7.3) with SMTP id HAA11370 for ; Wed, 23 Apr 1997 07:22:48 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa03875; 23 Apr 97 9:45 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-auth-sasl-10.txt Date: Wed, 23 Apr 1997 09:45:10 -0400 Message-ID: <9704230945.aa03875@ietf.org> Sender: owner-ietf-sasl@imc.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Authentication and Security Layer (SASL) Author(s) : J. Myers Filename : draft-myers-auth-sasl-10.txt Pages : 15 Date : 04/22/1997 This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection. Internet-Drafts are 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-myers-auth-sasl-10.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-10.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-auth-sasl-10.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970422164424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-auth-sasl-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-auth-sasl-10.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970422164424.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri May 2 15:25:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA05164 for ietf-sasl-bks; Fri, 2 May 1997 15:25:17 -0700 (PDT) Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA05160 for ; Fri, 2 May 1997 15:25:11 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Fri, 2 May 1997 15:26:15 -0700 Message-ID: From: "Jeff Stephenson (Exchange)" To: "'ietf-sasl@imc.org'" Cc: "'jgm@cmu.edu'" Subject: Clear text authentication in SASL? Date: Fri, 2 May 1997 15:19:33 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@imc.org Precedence: bulk Has anybody been working on or thinking about a clear-text userid/password authentication mechanism for SASL? Combined with an already secured connection via, say, STARTTLS, it would provide a simple way to obtain a decent level of authentication in a secure manner. In SMTP it might look like S: 220 mail.whitehouse.gov ready C: EHLO elvis.graceland.com S: 250-mail.whitehouse.gov S: 250-TLS S: 250 AUTH=CLEAR C: STARTTLS SSL3.0 S: 220 Go ahead with SSL3.0 C: AUTH CLEAR userid password S: 235 Clear text authentication successful ... From owner-ietf-sasl Fri May 2 16:07:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA05625 for ietf-sasl-bks; Fri, 2 May 1997 16:07:33 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA05621 for ; Fri, 2 May 1997 16:07:25 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Fri, 2 May 1997 19:08:23 -0400 Received: by lacroix.wildbear.on.ca from AZRAEL (204.250.145.140::mail daemon,SLmailNT V3.0 (alpha 10)); Fri, 2 May 1997 19:08:21 -0400 X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jeff Stephenson (Exchange)" , "'ietf-sasl@imc.org'" From: "Jack De Winter" Subject: Re: Clear text authentication in SASL? Cc: "'jgm@cmu.edu'" Date: Fri, 2 May 1997 19:08:23 -0400 Message-Id: <19970502190823.0a77463b.in@lacroix.wildbear.on.ca> Sender: owner-ietf-sasl@imc.org Precedence: bulk At 03:19 PM 5/2/97 -0700, Jeff Stephenson (Exchange) wrote: >Has anybody been working on or thinking about a clear-text >userid/password authentication mechanism for SASL? Combined with an >already secured connection via, say, STARTTLS, it would provide a simple >way to obtain a decent level of authentication in a secure manner. In >SMTP it might look like > > S: 220 mail.whitehouse.gov ready > C: EHLO elvis.graceland.com > S: 250-mail.whitehouse.gov > S: 250-TLS > S: 250 AUTH=CLEAR > C: STARTTLS SSL3.0 > S: 220 Go ahead with SSL3.0 > > C: AUTH CLEAR userid password > S: 235 Clear text authentication successful I have to admit that John gave me this task and I am a touch behind. I will be sending in the draft on Monday as soon as I check something out with John. regards, Jack From owner-ietf-sasl Fri May 2 16:09:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA05646 for ietf-sasl-bks; Fri, 2 May 1997 16:09:19 -0700 (PDT) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA05642 for ; Fri, 2 May 1997 16:09:16 -0700 (PDT) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA27602; Fri, 2 May 1997 16:10:25 -0700 Date: Fri, 2 May 1997 16:10:25 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: Clear text authentication in SASL? To: "Jeff Stephenson (Exchange)" cc: "'ietf-sasl@imc.org'" , "'jgm@cmu.edu'" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk > Has anybody been working on or thinking about a clear-text > userid/password authentication mechanism for SASL? Combined with an > already secured connection via, say, STARTTLS, it would provide a simple > way to obtain a decent level of authentication in a secure manner. In > SMTP it might look like > > S: 220 mail.whitehouse.gov ready > C: EHLO elvis.graceland.com > S: 250-mail.whitehouse.gov > S: 250-TLS > S: 250 AUTH=CLEAR > C: STARTTLS SSL3.0 > S: 220 Go ahead with SSL3.0 > > C: AUTH CLEAR userid password > S: 235 Clear text authentication successful > ... This is likely to raise some flak. There is a "de-facto" plaintext auth method called "LOGIN" which is used already by several vendors (including us). The protocol is: C: AUTH LOGIN S: 220 ok (or server profile defined response) C: S: 220 ok C: S: 235 you're in. ...However, there are some purists who don't feel that plaintext logins have any place in the modern world. I wholeheartedly agree; but counter that they are the only thing we can easily deploy in an existing infrastructure before raising the bar to other more secure methods; and which doesn't pass _obvious_ plain text. The obfuscation is minor, but important; and this also jibes with our SSL/TLS strategy. If the connection is secured, how the password is presented is irrelevant. AUTH LOGIN is used in (correct me if I get any of these wrong) Sun's Solstice IMAP products, the UW IMAP server, NetManage's IMAP client, Sun's java IMAP client, and Netscape's Messaging products. It was actually in common use in the UW server long before "IMAP authentication" became "SASL" and started requiring registration of methods; and it was never pulled into SASL because of its politically incorrectness. I have absolutely no qualms supporting it; but would like to see it standardized. Problem is I don't think we can pull off registration of essentially a plaintext auth type in this day and age. With the exception of perhaps PKL, I haven't see any authenticators I can really buy into. Customers won't touch CRAM once you let them know that the stored secret is really no more secure than APOP. S/KEY doesn't scale well. Kerberos and GSSAPI require additional heavy-duty security infrastructures which aren't totally compatible with my company's products. From owner-ietf-sasl Fri May 2 20:46:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA07713 for ietf-sasl-bks; Fri, 2 May 1997 20:46:57 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA07709 for ; Fri, 2 May 1997 20:46:53 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id UAA06045; Fri, 2 May 1997 20:48:25 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id UAA19380; Fri, 2 May 1997 20:48:24 -0700 (PDT) Message-Id: <199705030348.UAA19380@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Fri, 2 May 97 20:48:22 -0700 To: "Jeff Stephenson (Exchange)" Subject: Re: Clear text authentication in SASL? cc: "'ietf-sasl@imc.org'" , "'jgm@cmu.edu'" Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ietf-sasl@imc.org Precedence: bulk From: "Jeff Stephenson (Exchange)" Date: Fri, 2 May 1997 15:19:33 -0700 > Has anybody been working on or thinking about a clear-text > userid/password authentication mechanism for SASL? > Combined with an already secured connection via, say, > STARTTLS, it would provide a simple way to obtain a decent level > of authentication in a secure manner. In SMTP it might look like > > S: 220 mail.whitehouse.gov ready > C: EHLO elvis.graceland.com > S: 250-mail.whitehouse.gov > S: 250-TLS > S: 250 AUTH=CLEAR > C: STARTTLS SSL3.0 > S: 220 Go ahead with SSL3.0 > > C: AUTH CLEAR userid password > S: 235 Clear text authentication successful > ... > That could be done, but would we want to? The question is how do you limit combinations? For example, an identifier/password scheme protected by TLS seems reasonable (unless you have client-side certificates--in which case it makes little sense), but do you want allow identifier/password then TLS? What if you had three authentication schemes? That's fifteen combinations! Managing this can quickly get out of hand and combinations can weaken each other. My answer is combinations are not always a good idea and avoiding bad combinations can be difficult. In this case, client-side certificates is a reasonable authorization scheme as would an SPEKE extension. -dpg From owner-ietf-sasl Mon May 5 09:09:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA24444 for ietf-sasl-bks; Mon, 5 May 1997 09:09:37 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA24440 for ; Mon, 5 May 1997 09:09:34 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 May 1997 09:16:10 -0700 To: ietf-sasl@imc.org From: "Paul E. Hoffman" Subject: New mailing list for discussing applications over TLS Sender: owner-ietf-sasl@imc.org Precedence: bulk As I was revising my SMTP over TLS draft and looking at some of the issues with creating IMAP over TLS and POP over TLS drafts, I realized that it would be good to have a place where people could discuss the issues. After the discussion of the first SMTP/TLS draft, I realize that the TLS mailing list isn't the best place to have this discussion because there aren't many apps people here. This issue directly affects many SASL implementors, inasmuch as SASL doesn't handle TLS directly. Thus, SASL folk might be interested in the new list as well. Thus, I've created a new mailing list for discussion of applications running over TLS. This will keep the TLS folks from having to read the debates between the apps folks about what is the best wording for the "start TLS now" commands, and the apps folks from having to follow the crypto stuff that goes on the TLS list. The new list is called "ietf-apps-tls@imc.org", and you subscribe by sending mail to: ietf-apps-tls-request@imc.org with the single word: subscribe in the body of the message. There is also a Web page for the list at which will have links to the drafts being discussed and so on. I'll update the ietf-tls mailing list every so often about new things on the other mailing list, and of course invite people to come over to the list if they're interested in how the apps folks are doing with TLS. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Mon May 5 10:57:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA26125 for ietf-sasl-bks; Mon, 5 May 1997 10:57:01 -0700 (PDT) Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA26121 for ; Mon, 5 May 1997 10:56:56 -0700 (PDT) Received: (from postman@localhost) by andrew.cmu.edu (8.8.2/8.8.2) id NAA17626 for ietf-sasl@imc.org; Mon, 5 May 1997 13:57:27 -0400 Received: via switchmail; Mon, 5 May 1997 13:57:21 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 5 May 1997 13:56:06 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 5 May 1997 13:56:05 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 5 May 1997 13:56:04 -0400 (EDT) Message-ID: Date: Mon, 5 May 1997 13:56:04 -0400 (EDT) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: Re: Clear text authentication in SASL? In-Reply-To: References: Sender: owner-ietf-sasl@imc.org Precedence: bulk The "LOGIN" mechanism is defective in two ways: it does not permit the negotiation of an authorization ID separate from the authentictation ID and it would seem to require an unnecessary network round trip. It's also extremely poorly named. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Mon May 5 11:12:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA26393 for ietf-sasl-bks; Mon, 5 May 1997 11:12:01 -0700 (PDT) Received: from monet.esys.ca (0@[198.161.92.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA26389 for ; Mon, 5 May 1997 11:11:54 -0700 (PDT) Received: from lautrec.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wOSGV-000RXnC; Mon, 5 May 97 12:13 MDT Received: from localhost (lyndon@localhost) by lautrec.esys.ca (8.8.5/8.8.5) with SMTP id MAA17638; Mon, 5 May 1997 12:13:34 -0600 (MDT) Message-Id: <199705051813.MAA17638@lautrec.esys.ca> X-Authentication-Warning: lautrec.esys.ca: lyndon@localhost didn't use HELO protocol To: John Gardiner Myers cc: ietf-sasl@imc.org Subject: Re: Clear text authentication in SASL? In-reply-to: Your message of "Mon, 05 May 1997 13:56:04 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 May 1997 12:13:33 -0600 From: Lyndon Nerenberg Sender: owner-ietf-sasl@imc.org Precedence: bulk Didn't Jeff Schiller state that the IETF was going to bounce any new security/authentication schemes incorporating cleartext passwords? Personally, I don't see that problem with using an existing non-cleartext authentication scheme inside of an encrypted pipe. Both ends have to (should) support this for situations where an encrypted pipe is not available. Just FYI, the next release of our IMAP and IMSP servers will default to having all cleartext authentication schemes turned off -- the site admin will have to take explicit steps to turn on non-secure "security." A not-too-distant release of our IMAP4 client will also let you disable cleartext authentication schemes. I really don't see any reason at all to continue to introduce flawed authentication schemes such as AUTH LOGIN. --lyndon From owner-ietf-sasl Mon May 5 11:26:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA26583 for ietf-sasl-bks; Mon, 5 May 1997 11:26:16 -0700 (PDT) Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA26579 for ; Mon, 5 May 1997 11:26:13 -0700 (PDT) Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA8960; Mon, 5 May 1997 11:27:32 -0700 Date: Mon, 5 May 1997 11:27:31 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: Clear text authentication in SASL? To: John Gardiner Myers cc: ietf-sasl@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk > The "LOGIN" mechanism is defective in two ways: it does not permit the > negotiation of an authorization ID separate from the authentictation > ID and it would seem to require an unnecessary network round trip. > It's also extremely poorly named. Agreed. I think it should be fixed, and in so doing will likely need a new name. My last message on the subject was mostly to provide some historical context w/r/t plaintext mechanisms. From owner-ietf-sasl Mon May 5 12:11:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA27418 for ietf-sasl-bks; Mon, 5 May 1997 12:11:10 -0700 (PDT) Received: from po7.andrew.cmu.edu (PO7.ANDREW.CMU.EDU [128.2.10.107]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA27414 for ; Mon, 5 May 1997 12:11:07 -0700 (PDT) Received: (from postman@localhost) by po7.andrew.cmu.edu (8.8.5/8.8.2) id PAA25641 for ietf-sasl@imc.org; Mon, 5 May 1997 15:00:52 -0400 (EDT) Received: via switchmail; Mon, 5 May 1997 15:00:51 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 5 May 1997 14:59:09 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 5 May 1997 14:59:08 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 5 May 1997 14:59:06 -0400 (EDT) Message-ID: Date: Mon, 5 May 1997 14:59:06 -0400 (EDT) From: John Gardiner Myers To: ietf-sasl@imc.org Subject: TLS/SASL relationship In-Reply-To: <199705030348.UAA19380@imo.plaintalk.bellevue.wa.us> References: <199705030348.UAA19380@imo.plaintalk.bellevue.wa.us> Sender: owner-ietf-sasl@imc.org Precedence: bulk Dennis Glatting writes: > That could be done, but would we want to? Yes. TLS doesn't provide all of the functionality needed for appliation-level security, so there needs to be a mechanism to get what's not there. > The question is how do you limit combinations? You have to keep an eye on your minimum security requirements and not offer choices weaker than your security policy. > For example, an > identifier/password scheme protected by TLS seems > reasonable (unless you have client-side certificates--in > which case it makes little sense), but do you want allow > identifier/password then TLS? Allowing identifier/password than TLS is no weaker than allowing just identifier/password alone. It's also not much stronger. If identifier/password alone is weaker than allowed by policy, but identifier/password under TLS is allowed by policy, then don't allow identifier/password until TLS has been negotiated on with the strength required by policy. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-sasl Mon May 5 18:16:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA01490 for ietf-sasl-bks; Mon, 5 May 1997 18:16:05 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA01486 for ; Mon, 5 May 1997 18:15:59 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id SAA09003; Mon, 5 May 1997 18:17:44 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id SAA01977; Mon, 5 May 1997 18:17:40 -0700 (PDT) Message-Id: <199705060117.SAA01977@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Mon, 5 May 97 18:17:38 -0700 To: John Gardiner Myers Subject: Re: TLS/SASL relationship cc: ietf-sasl@imc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199705030348.UAA19380@imo.plaintalk.bellevue.wa.us> Sender: owner-ietf-sasl@imc.org Precedence: bulk Date: Mon, 5 May 1997 14:59:06 -0400 (EDT) From: John Gardiner Myers > Dennis Glatting writes: > > That could be done, but would we want to? > > Yes. TLS doesn't provide all of the functionality needed for > appliation-level security, so there needs to be a mechanism to > get what's not there. > What does application level security need, that identifier/password provides, but isn't provided by client-side certs? -dpg From owner-ietf-sasl Tue May 6 08:42:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA12045 for ietf-sasl-bks; Tue, 6 May 1997 08:42:50 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA12040 for ; Tue, 6 May 1997 08:42:45 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 6 May 1997 11:42:17 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 6 May 1997 11:42:15 -0400 Message-Id: <3.0.1.32.19970506114405.0071111c@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 06 May 1997 11:44:05 -0400 To: dennis.glatting@plaintalk.bellevue.wa.us, John Gardiner Myers From: "Jack De Winter" Subject: Re: TLS/SASL relationship Cc: ietf-sasl@imc.org In-Reply-To: <199705060117.SAA01977@imo.plaintalk.bellevue.wa.us> References: <199705030348.UAA19380@imo.plaintalk.bellevue.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 06:17 PM 5/5/97 -0700, Dennis Glatting wrote: > >Date: Mon, 5 May 1997 14:59:06 -0400 (EDT) >From: John Gardiner Myers > >> Dennis Glatting writes: >> > That could be done, but would we want to? >> >> Yes. TLS doesn't provide all of the functionality needed for >> appliation-level security, so there needs to be a mechanism to >> get what's not there. >> > >What does application level security need, that >identifier/password provides, but isn't provided by >client-side certs? Say you use TLS to negotiate certificates. One of them may be the accounts that you are authorized to access the system on. Say jack, webmaster, and mailmaster for arguments sake. You still don't know which one of these roles you are going to assume from the application's viewpoint. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-sasl Tue May 6 14:35:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA17309 for ietf-sasl-bks; Tue, 6 May 1997 14:35:56 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA17305 for ; Tue, 6 May 1997 14:35:52 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id OAA00378; Tue, 6 May 1997 14:36:00 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id OAA00302; Tue, 6 May 1997 14:35:56 -0700 (PDT) Message-Id: <199705062135.OAA00302@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Tue, 6 May 97 14:35:53 -0700 To: "Jack De Winter" Subject: Re: TLS/SASL relationship cc: John Gardiner Myers , ietf-sasl@imc.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199705030348.UAA19380@imo.plaintalk.bellevue.wa.us> <3.0.1.32.19970506114405.0071111c@lacroix.wildbear.on.ca> Sender: owner-ietf-sasl@imc.org Precedence: bulk Date: Tue, 06 May 1997 11:44:05 -0400 Subject: Re: TLS/SASL relationship > At 06:17 PM 5/5/97 -0700, Dennis Glatting wrote: > > > >What does application level security need, that > >identifier/password provides, but isn't provided by > >client-side certs? > > Say you use TLS to negotiate certificates. One of them may be the > accounts that you are authorized to access the system on. Say > jack, webmaster, and mailmaster for arguments sake. You still > don't know which one of these roles you are going to assume from > the application's viewpoint. > Okay, I accept that, but I'm having difficulty with the concept of using one or more authentication technologies (i.e., SASL) within a technology that supports good authentication (TLS). If SASL's role is authentication then why use TLS? The TLS client cert has no value and, probably, the server's doesn't either. What is provided by TLS, then, is merely an encrypted tunnel, which is not using TLS to its potential and can be done with less complexity and bulk. If SASL's role is identification of role then you only need a fraction of SASL, i.e., only an identifier. The remainder of SASL's functionality--as far as I can tell--is useless, i.e., it doesn't make sense to use GSSAPI, Kerberos, CRAM, and other technologies identifiable by SASL when the session is encapsulated by TLS. So what else is there other than identifier/password and, if the tunnel is mutually authenticated, why have a password? -dpg From owner-ietf-sasl Tue May 6 15:01:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA17688 for ietf-sasl-bks; Tue, 6 May 1997 15:01:42 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA17684 for ; Tue, 6 May 1997 15:01:39 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIJXP3Y2AY99GXNA@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 6 May 1997 15:01:47 PDT Date: Tue, 06 May 1997 15:03:17 -0700 (PDT) From: Chris Newman Subject: Re: Clear text authentication in SASL? In-reply-to: To: ietf-sasl@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-sasl@imc.org Precedence: bulk On Mon, 5 May 1997, John Gardiner Myers wrote: > The "LOGIN" mechanism is defective in two ways: it does not permit the > negotiation of an authorization ID separate from the authentictation > ID and it would seem to require an unnecessary network round trip. > It's also extremely poorly named. Another flaw is that it opens up the possiblity of failing after the user name is sent but before the password is sent. This can reveal information about what users are on the system to an attacker. From owner-ietf-sasl Tue May 6 15:29:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA18005 for ietf-sasl-bks; Tue, 6 May 1997 15:29:12 -0700 (PDT) Received: from THOR.INNOSOFT.CO