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.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA18001 for ; Tue, 6 May 1997 15:29:10 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIJYNSUXN499GXNA@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 6 May 1997 15:28:58 PDT Date: Tue, 06 May 1997 15:30:28 -0700 (PDT) From: Chris Newman Subject: Re: TLS/SASL relationship In-reply-to: <199705062135.OAA00302@imo.plaintalk.bellevue.wa.us> To: Dennis Glatting Cc: 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 The TLS/SASL relationship is as follows: TLS needs at least the SASL EXTERNAL mechanism to work with an application requiring client authentication (e.g. anything other than HTTP). Simple SASL mechanisms (e.g. CRAM-MD5, potentally a cleartext password mechanism) benefit from using TLS's encrypted tunnel features to hide the actual content of the connection. This can be deployed without changing the client authentication framework and thus is a useful combination. Complete SASL mechanisms (e.g. Kerberos) never need TLS. >From an architectural standpoint, I'd prefer to always use a complete SASL mechanism and never use TLS. But that ignores the following realities: (1) There are a number of legacy client authentication frameworks which work, but can't be changed easily and don't support encryption. (2) There is a deployed server SSL public-key framework which works for encryption. (3) SSL/TLS has lots of hype and is what customers request now, even if SASL would better serve their needs. Recognizing this reality means that SASL and TLS will co-exist with largely overlapping functionality for quite a while. From owner-ietf-sasl Thu May 8 13:43:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03355 for ietf-sasl-bks; Thu, 8 May 1997 13:43:54 -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 NAA03351 for ; Thu, 8 May 1997 13:43:52 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIMNKDD07299G2YR@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 8 May 1997 13:44:01 PDT Date: Thu, 08 May 1997 13:45:31 -0700 (PDT) From: Chris Newman Subject: draft-myers-auth-sasl-10.txt 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 Comments on the new draft: Section 3, second paragraph say "The command has a single argument." Perhaps this should say "a single required argument" to be more precise. Section 3, 7th paragraph mentions "null string". Is this synonymous with "empty string"? Section 6.2 has some quoted strings which are wrapped poorly. Using the nroff "\%" prefix in front of those quoted strings might help. Section 8, third paragraph. Should "an SASL" be "a SASL"? I'm also unclear of exactly what restrictions this paragraph places on the mechanism name. In any discussion of listing available mechanisms and the security impact thereof necessary? Otherwise the spec looks great. From owner-ietf-sasl Wed May 14 12:13:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA04727 for ietf-sasl-bks; Wed, 14 May 1997 12:13:31 -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 MAA04723 for ; Wed, 14 May 1997 12:13:29 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Wed, 14 May 1997 12:13:58 -0700 Message-ID: From: "Jeff Stephenson (Exchange)" To: "'ietf-sasl@imc.org'" Subject: Response codes for SMTP servers requiring auth/security Date: Wed, 14 May 1997 12:14:07 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-sasl@imc.org Precedence: bulk There are many cases in which an SMTP server might wish to require that all connections to it be secure, authenticated, or both. In those cases it would be nice if the server could reject SMTP commands with a more informative response code than "554 Transaction failed" so that the client software could know to authenticate or initiate security. I think that such reply codes should be included in the SMTP-AUTH draft. A provision has been added to the most recent SMTP-SSL draft (draft-hoffman-smtp-ssl-02.txt) for this, though the reply code specified there will probably change. The SMTP-AUTH and SMTP-SSL drafts should coordinate on this so that there is a generic "Secure channel required" reply code. I would suggest something along the lines of: 555 Secure channel required 556 Client authentication required Another approach would be to go to the enhanced status codes of RFC 1893 - codes in the 5.7.x category would seem appropriate there. -- jeff From owner-ietf-sasl Wed May 21 22:56:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA15230 for ietf-sasl-bks; Wed, 21 May 1997 22:56:32 -0700 (PDT) Received: from cygnus.com (cygnus.com [205.180.230.20]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA15226 for ; Wed, 21 May 1997 22:56:30 -0700 (PDT) Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.8.5/8.8.5) with SMTP id WAA15916 for ; Wed, 21 May 1997 22:57:36 -0700 (PDT) Received: from kr-pc.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA20621; Thu, 22 May 97 01:57:29 EDT Received: (from raeburn@localhost) by kr-pc.cygnus.com (8.7.6/8.6.9) id BAA01627; Thu, 22 May 1997 01:58:50 -0400 (EDT) Date: Thu, 22 May 1997 01:58:50 -0400 (EDT) Message-Id: <199705220558.BAA01627@kr-pc.cygnus.com> From: Ken Raeburn To: ietf-sasl@imc.org Subject: SASL questions: krb4, cleartext, code Sender: owner-ietf-sasl@imc.org Precedence: bulk Hi. I've just joined the list. Sorry if I'm rehashing anything that hasn't made it to the mail-archive web site. I've been looking over the SASL draft 10, with an eye towards using it to negotiate authentication in CVS. A few comments and questions have come to mind. Kerberos 4: You require three round-trips to complete the authentication scheme. But it seems to me that two round-trips should suffice, if client data can be sent in the first message. Is there some reason (other than historical, relating to IMAP) that I'm missing? I suppose it's too late to change it.... Cleartext-password mechanisms: I don't think there's any way I can get out of continuing to support this in some form. (I mean, really cleartext, not just passwords sent over SSL-protected sessions.) It's not secure, but the reality is that it gets used. Has someone confirmed, as Lyndon Nerenberg thought: > Didn't Jeff Schiller state that the IETF was going to bounce any new > security/authentication schemes incorporating cleartext passwords? That would be unfortunate, since the schemes will exist anyways. And a mechanism for SASL would be more of an attempt to make such schemes fit into a general authentication-negotiation protocol than an attempt to promote insecure mechanisms. Code: Is there a publicly available implementation I can try out? If not to actually incorporate into CVS, at least to use for interoperability testing? Ken From owner-ietf-sasl Thu May 22 10:11:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA23897 for ietf-sasl-bks; Thu, 22 May 1997 10:11:30 -0700 (PDT) Received: from tyholt.uninett.no (tyholt.uninett.no [129.241.131.12]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA23891 for ; Thu, 22 May 1997 10:11:25 -0700 (PDT) Received: from munken.uninett.no (munken.uninett.no [129.241.131.10]) by tyholt.uninett.no (8.7.6/8.7.3) with SMTP id TAA08930; Thu, 22 May 1997 19:11:11 +0200 (METDST) X-Authentication-Warning: tyholt.uninett.no: Host munken.uninett.no [129.241.131.10] didn't use HELO protocol X-Mailer: exmh version 1.6.7 5/3/96 From: Harald.T.Alvestrand@uninett.no To: Ken Raeburn cc: ietf-sasl@imc.org Subject: Re: SASL questions: krb4, cleartext, code In-reply-to: Your message of "Thu, 22 May 1997 01:58:50 EDT." <199705220558.BAA01627@kr-pc.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 May 1997 19:12:09 +0200 Message-ID: <89.864321129@munken.uninett.no> Sender: owner-ietf-sasl@imc.org Precedence: bulk FYI, the IESG just passed a protocol action (recycle at Draft due to procedural issues; otherwise it would have been Full) that included cleartext passwords: OSPF. The relevant section of the document says: Simple password authentication guards against routers inadvertently joining the routing domain; each router must first be configured with its attached networks' passwords before it can participate in routing. However, simple password authentication is vulnerable to passive attacks currently widespread in the Internet (see [Ref16]). Anyone with physical access to the network can learn the password and compromise the security of the OSPF routing domain. It's not illegal to put out passwords, it's just illegal to say that they provide security. (But this had the advantage of being a deployed mechanism; it's dangerous to assume that SASL gets the same liberty) BTW: One reason for doing CRAM was the shudders people got when they were thinking about passing cleartext passwords inside RC2/40bit encrypted channels. Harald A From owner-ietf-sasl Thu May 22 12:10:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA25138 for ietf-sasl-bks; Thu, 22 May 1997 12:10:28 -0700 (PDT) Received: from monet.esys.ca (0@monet.esys.ca [198.161.92.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA25133 for ; Thu, 22 May 1997 12:10:24 -0700 (PDT) Received: from lautrec.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wUdGn-000RXPC; Thu, 22 May 97 13:11 MDT Received: from localhost (lyndon@localhost) by lautrec.esys.ca (8.8.5/8.8.5) with SMTP id NAA20898; Thu, 22 May 1997 13:11:26 -0600 (MDT) Message-Id: <199705221911.NAA20898@lautrec.esys.ca> X-Authentication-Warning: lautrec.esys.ca: lyndon@localhost didn't use HELO protocol To: Harald.T.Alvestrand@uninett.no cc: Ken Raeburn , ietf-sasl@imc.org Subject: Re: SASL questions: krb4, cleartext, code In-reply-to: Your message of "Thu, 22 May 1997 19:12:09 +0200." <89.864321129@munken.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 May 1997 13:11:25 -0600 From: Lyndon Nerenberg Sender: owner-ietf-sasl@imc.org Precedence: bulk > FYI, the IESG just passed a protocol action (recycle at Draft > due to procedural issues; otherwise it would have been Full) > that included cleartext passwords: OSPF. I don't know if I would call that a "password." It's more like a "co-operative routing domain identifier." --lyndon Lyndon Nerenberg Sr. Software Developer Server Products From owner-ietf-sasl Thu May 22 15:23:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA27700 for ietf-sasl-bks; Thu, 22 May 1997 15:23:01 -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 PAA27694 for ; Thu, 22 May 1997 15:22:59 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IJ6B3Z5B989X3XQF@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 22 May 1997 15:23:02 PDT Date: Thu, 22 May 1997 15:24:35 -0700 (PDT) From: Chris Newman Subject: Re: SASL questions: krb4, cleartext, code In-reply-to: <199705220558.BAA01627@kr-pc.cygnus.com> To: Ken Raeburn Cc: 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 Thu, 22 May 1997, Ken Raeburn wrote: > Cleartext-password mechanisms: > > I don't think there's any way I can get out of continuing to support > this in some form. (I mean, really cleartext, not just passwords sent > over SSL-protected sessions.) It's not secure, but the reality is > that it gets used. I absolutely think we need such a mechanism. I have no problems if the definition states SHOULD NOT be used unless strong encryption (e.g. greater than 56 bit key) is active on the channel. I also wouldn't object if it said "clients which implement this MUST also implement a stronger mechanism such as CRAM-MD5." I also think this mechanism shouldn't be in the SASL base spec (so it can be depricated if we reach authentication paradise). I'm all for discouraging cleartext passwords, but it will be a long time before we can get rid of them from a practical standpoint. Forcing people to implement the SASL framework in order to use cleartext passwords is worth doing, IMHO. From owner-ietf-sasl Fri May 23 01:08:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA09741 for ietf-sasl-bks; Fri, 23 May 1997 01:08:30 -0700 (PDT) Received: from tyholt.uninett.no (tyholt.uninett.no [129.241.131.12]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA09737 for ; Fri, 23 May 1997 01:08:27 -0700 (PDT) Received: from munken.uninett.no (munken.uninett.no [129.241.131.10]) by tyholt.uninett.no (8.7.6/8.7.3) with SMTP id KAA12292; Fri, 23 May 1997 10:08:19 +0200 (METDST) X-Authentication-Warning: tyholt.uninett.no: Host munken.uninett.no [129.241.131.10] didn't use HELO protocol X-Mailer: exmh version 1.6.7 5/3/96 From: Harald.T.Alvestrand@uninett.no To: Lyndon Nerenberg cc: Ken Raeburn , ietf-sasl@imc.org Subject: Re: SASL questions: krb4, cleartext, code In-reply-to: Your message of "Thu, 22 May 1997 13:11:25 MDT." <199705221911.NAA20898@lautrec.esys.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 23 May 1997 10:09:17 +0200 Message-ID: <2214.864374957@munken.uninett.no> Sender: owner-ietf-sasl@imc.org Precedence: bulk lyndon@esys.ca said: > I don't know if I would call that a "password." It's more like a = > "co-operative routing domain identifier." = That's what it is - same as the "community" string in SNMPv1. But it's called a password, so it's possible to use the same argument for something else also called a password. Have fun! Harald A From owner-ietf-sasl Fri May 23 08:52:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA15884 for ietf-sasl-bks; Fri, 23 May 1997 08:52:42 -0700 (PDT) Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA15871 for ; Fri, 23 May 1997 08:52:33 -0700 (PDT) Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA136162817; Fri, 23 May 1997 08:53:38 -0700 Message-Id: <199705231553.AA136162817@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA031522817; Fri, 23 May 1997 11:53:37 -0400 To: Ken Raeburn Cc: ietf-sasl@imc.org Subject: Re: SASL questions: krb4, cleartext, code In-Reply-To: raeburn's message of Thu, 22 May 1997 01:58:50 -0400. <199705220558.BAA01627@kr-pc.cygnus.com> Date: Fri, 23 May 1997 11:53:36 -0400 From: Bill Sommerfeld Sender: owner-ietf-sasl@imc.org Precedence: bulk > Has someone confirmed, as Lyndon Nerenberg thought: > > Didn't Jeff Schiller state that the IETF was going to bounce any new > > security/authentication schemes incorporating cleartext passwords? > > That would be unfortunate, since the schemes will exist anyways. See http://www.iab.org/iab/secrets.html, which is the result of an IAB workshop on security.. There was consensus among the attendees that plaintext passwords need to be killed completely, and that one way to accomplish this is to avoid "blessing" protocols which require/use them.. The verdict of the workshop: > To be Killed: Plaintext Passwords > > Any protocol that relies on the transmission of unencrypted > passwords is terminally broken. Any protocol that puts confidential > information in public places (such as URLs) is similarly broken. I see no reason to dispute this. - Bill From owner-ietf-sasl Thu Jun 12 15:07:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA02335 for ietf-sasl-bks; Thu, 12 Jun 1997 15:07:51 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA02330; Thu, 12 Jun 1997 15:07:45 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1608.0) id ; Thu, 12 Jun 1997 15:10:18 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050E8254@DINO> From: "Jeff Stephenson (Exchange)" To: "'John Gardiner Myers'" , "'Paul E. Hoffman'" Cc: "'ietf-sasl@imc.org'" , "'ietf-apps-tls@imc.org'" Subject: SMTP servers requiring security/authentication Date: Thu, 12 Jun 1997 15:10:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1608.0) Content-Type: text/plain Sender: owner-ietf-sasl@imc.org Precedence: bulk The SMTP AUTH draft (draft-myers-smtp-auth-05.txt), while providing a mechanism for a submitting client to authenticate to the server and establish a secure session, doesn't contain a provision for the server to inform the client that authentication or security are _required_ for submission. I'd like to see an addition to the draft which addresses how an SMTP server responds to SMTP commands when authentication or security are required but the client has not successfully issued an appropriate AUTH command. The current STARTTLS command (draft-hoffman-smtp-ssl-03.txt) has a provision along these lines, specifying a response of "505 Must issue a STARTTLS command first" to any command other than STARTTLS or QUIT if the server requires TLS. This might best be generalized to "505 Secure SMTP session required" and used in both the SMTP AUTH and STARTTLS worlds. Similarly, a server which required the client to authenticate could respond with "506 Authentication required" to anything but a command which could establish authentication. Clearly there are some ordering problems to be worked out here - if someone wants to do a STARTTLS to establish security (but not client identity) and an AUTH command to authenticate, we don't want the STARTTLS rejected because of lack of authentication. From owner-ietf-sasl Thu Jun 12 16:05:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03077 for ietf-sasl-bks; Thu, 12 Jun 1997 16:05:01 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA03063; Thu, 12 Jun 1997 16:04:51 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id SAA14422; Thu, 12 Jun 1997 18:06:27 -0500 (CDT) Received: from kcx-ks6-21.ix.netcom.com(204.30.70.213) by dfw-ix10.ix.netcom.com via smap (V1.3) id sma014375; Thu Jun 12 18:05:54 1997 Message-ID: <33A02B1D.32C2@ix.netcom.com> Date: Thu, 12 Jun 1997 18:00:13 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: "Jeff Stephenson (Exchange)" CC: "'John Gardiner Myers'" , "'Paul E. Hoffman'" , "'ietf-sasl@imc.org'" , "'ietf-apps-tls@imc.org'" Subject: Re: SMTP servers requiring security/authentication References: <2FBF98FC7852CF11912A000000000001050E8254@DINO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk Jeff, Jeff Stephenson (Exchange) wrote: > > The SMTP AUTH draft (draft-myers-smtp-auth-05.txt), while providing a > mechanism for a submitting client to authenticate to the server and > establish a secure session, doesn't contain a provision for the server > to inform the client that authentication or security are _required_ for > submission. I'd like to see an addition to the draft which addresses > how an SMTP server responds to SMTP commands when authentication or > security are required but the client has not successfully issued an > appropriate AUTH command. This is absolutely a good idea and we have included this ability already in our "Interface Facility" or MLPI to facilitate this through a direct call passing the command(S) that can be defined. But I agree with Jeff here, this should be part of the Draft. > > The current STARTTLS command (draft-hoffman-smtp-ssl-03.txt) has a > provision along these lines, specifying a response of "505 Must issue a > STARTTLS command first" to any command other than STARTTLS or QUIT if > the server requires TLS. This might best be generalized to "505 Secure > SMTP session required" and used in both the SMTP AUTH and STARTTLS > worlds. Similarly, a server which required the client to authenticate > could respond with "506 Authentication required" to anything but a > command which could establish authentication. Agreed again here. And again, we do include this capability in our "Interface Facility? or MLPI. Yet I might add that limiting the diffrent "Start Commands", for simplifacation here, should not just be limited to TLS for SMTP. And we do provide this capability as well that can be defined in addition to any other command structure,or in addition to existing command structure that may already exist. >;) > > Clearly there are some ordering problems to be worked out here - if > someone wants to do a STARTTLS to establish security (but not client > identity) and an AUTH command to authenticate, we don't want the > STARTTLS rejected because of lack of authentication. This is very simply workable. Many diffrent approaches can be used to achiev this consideration. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com From owner-ietf-sasl Wed Jun 25 14:55:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA28558 for ietf-sasl-bks; Wed, 25 Jun 1997 14:55:46 -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 OAA28553 for ; Wed, 25 Jun 1997 14:55:37 -0700 (PDT) Received: from eleanor.innosoft.com ("port 65154"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IKHS3SDHGCANC6LU@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 25 Jun 1997 14:56:30 PDT Date: Wed, 25 Jun 1997 14:58:12 -0700 (PDT) From: Chris Newman Subject: Application Authentication/Authorization To: ietf-sasl@imc.org, IETF ACAP Mailing List , John C Klensin , Paul Krumviede , "David P. Jablon" , Harald Alvestrand , Keith Moore Reply-to: Chris Newman Message-id: Content-id: MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="-559023410-162216788-867275892=:19594" Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-sasl@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-162216788-867275892=:19594 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: A mailing list has been set up to discuss the problem of Application Authentication/Authorization with the intent of eliminating the need to send unencrypted plaintext passwords over the Internet. The intention is to build upon the work done by the ietf-sasl mailing list. To subscribe, send a message to with "subscribe" in the body. The list will be activated once a reasonable number of subscriptions have been received. Attached is a preliminary draft for an IETF WG charter. - Chris ---559023410-162216788-867275892=:19594 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="aaarg-charter.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpBcHBsaWNhdGlvbiBBdXRoZW50aWNhdGlvbi9BdXRob3JpemF0aW9uIFJl dmlldyBHcm91cCAoQUFBUkcpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQogQ2hh cnRlciANCiANCiBDdXJyZW50IHN0YXR1czogcHJvcG9zZWQgd29ya2luZyBn cm91cA0KIA0KIENoYWlyKHMpOg0KICAgICBUQkQNCiANCiBBcHBsaWNhdGlv bnMgQXJlYSBEaXJlY3RvcihzKTogDQogICAgIEtlaXRoIE1vb3JlICA8bW9v cmUraWVzZ0Bjcy51dGsuZWR1Pg0KICAgICBIYXJhbGQgQWx2ZXN0cmFuZCAg PEhhcmFsZC5ULkFsdmVzdHJhbmRAdW5pbmV0dC5ubz4NCiANCiBNYWlsaW5n IGxpc3RzOg0KICAgICBHZW5lcmFsIERpc2N1c3Npb246IGlldGYtYWFhcmdA aW1jLm9yZw0KICAgICBUbyBTdWJzY3JpYmU6ICAgICAgIGlldGYtYWFhcmct cmVxdWVzdEBpbWMub3JnDQogICAgIEFyY2hpdmU6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pbWMub3JnL2lldGYtYWFhcmcvDQogDQpEZXNjcmlwdGlvbiBv ZiBXb3JraW5nIEdyb3VwOg0KDQpUaGUgSUVTRy9JQUIgc2VjdXJpdHkgd29y a3Nob3AgY29uY2x1ZGVkIHRoYXQgcGxhaW50ZXh0IHBhc3N3b3JkcyBhcmUN Cm5vIGxvbmdlciBhY2NlcHRhYmxlIGluIG5ldyBwcm90b2NvbHMuICBVbmZv cnR1bmF0ZWx5LCBhIGxhcmdlIG51bWJlcg0Kb2YgY29tcGxleCBwcm9ibGVt cyBuZWVkIHRvIGJlIHNvbHZlZCBpbiBvcmRlciBmb3IgdGhlcmUgdG8gYmUg YQ0KcHJhY3RpY2FsIGFsdGVybmF0aXZlIGZvciBhcHBsaWNhdGlvbiBwcm90 b2NvbHMuICBUaGUgZ29hbCBvZiB0aGlzDQp3b3JraW5nIGdyb3VwIGlzIHRv IGlkZW50aWZ5IG9yIGRldmVsb3AgY29tcG9uZW50cyBmb3IgYSBiYXNlbGlu ZQ0KYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBzeXN0ZW0gZm9yIHVz ZSBieSBJbnRlcm5ldCBhcHBsaWNhdGlvbg0KcHJvdG9jb2xzLiAgVGhpcyBz eXN0ZW0gbXVzdCBoYXZlIHRoZSBmb2xsb3dpbmcgY2hhcmFjdGVyaXN0aWNz Og0KDQoqIEJlIGFzIHNpbXBsZSBhcyBwb3NzaWJsZSAtLSBzcGVjaWZpY2Fs bHksIGJhc2VsaW5lIGF1dGhlbnRpY2F0aW9uLA0KICBhdXRob3JpemF0aW9u IGFuZCBpbnRlZ3JpdHkgc2VydmljZXMgbXVzdCBub3QgcmVxdWlyZSBBU04u MSBvciB0aGUNCiAgZGVwbG95bWVudCBvZiBhIGNlcnRpZmljYXRlIGluZnJh c3RydWN0dXJlLg0KDQoqIEhhdmUgbm8gZGVwZW5kZW5jaWVzIHdoaWNoIHJl cXVpcmUgb3IgaGF2ZSB0aGUgZWZmZWN0IG9mIHJlcXVpcmluZw0KICB0cmFk ZSBzZWNyZXQgdGVjaG5vbG9neQ0KDQoqIEhhdmUgbm8gZGVwZW5kZW5jaWVz IHdoaWNoIHdvdWxkIHByZXZlbnQgb3IgdW5uZWNlc3NhcmlseSBjb21wbGlj YXRlDQogIGZyZWVseSBhdmFpbGFibGUgb3Igc2hhcmV3YXJlIGltcGxlbWVu dGF0aW9ucy4gIFNwZWNpZmljYWxseSwgcGF0ZW50cw0KICBhcmUgYSBzZXJp b3VzIGNvbmNlcm4uDQoNCiogUHJvdmlkZSBhIHRyYW5zaXRpb24gc3RyYXRl Z3kgZm9yIG1vdmluZyBmcm9tIGN1cnJlbnQgcGxhaW50ZXh0DQogIHBhc3N3 b3JkIHN5c3RlbXMNCg0KKiBBbGxvdyBmb3IgdGhlIGV4aXN0ZW5jZSBvZiBw cm94eSBzZXJ2ZXJzIGluIHRoZSBhcmNoaXRlY3R1cmUNCg0KKiBBdm9pZCBw b3RlbnRpYWwgZXhwb3J0IHJlc3RyaWN0aW9ucyBhcyBtdWNoIGFzIHBvc3Np YmxlDQoNClRoZSB0b3AgcHJpb3JpdHkgZGVsaXZlcmFibGVzIGFyZToNCg0K KiBBIFNBU0wgbWVjaGFuaXNtIGludGVuZGVkIHRvIHJlcGxhY2UgQ1JBTS1N RDUgd2hpY2ggcmVwYWlycyB0aGUNCiAgd2Vha25lc3Mgb2YgTUQ1LCB0aGUg bGFjayBvZiBhbiBhdXRob3JpemF0aW9uIGlkZW50aWZpZXIsIGFuZA0KICBw b3NzaWJseSBhbHNvIGFkZHJlc3NlcyB0aGUgbGFjayBvZiBvcHRpb25hbCBp bnRlZ3JpdHkgcHJvdGVjdGlvbg0KICBhbmQgQ1JBTSdzIHN1c2NlcHRpYmls aXR5IHRvIGRpY3Rpb25hcnkgYXR0YWNrcyBieSBhIHBhc3NpdmUNCiAgb2Jz ZXJ2ZXIuICBUaGlzIGRvY3VtZW50IHNob3VsZCBpbmNsdWRlIHNhbXBsZSBz b3VyY2UgY29kZSBpbiBhbg0KICBhcHBlbmRpeCB0byBhc3Npc3QgaW1wbGVt ZW50b3JzIHdpdGggbm8gc2VjdXJpdHkgZXhwZXJpZW5jZSBvcg0KICByZWZl cmVuY2VzLg0KDQoqIEEgc2ltcGxlIHBhc3N3b3JkIGNoYW5naW5nIHByb3Rv Y29sIHRvIHJlcGxhY2UgdGhlIGRlZmFjdG8gc3RhbmRhcmQNCiAgInBvcHBh c3NkIiB3aGljaCB1c2VzIHBsYWludGV4dCBwYXNzd29yZHMuDQoNCiogQSBT QVNMIG1lY2hhbmlzbSB3aGljaCBjYW4gYmUgdXNlZCB0byB0cmFuc2l0aW9u IGZyb20gcGxhaW50ZXh0DQogIHBhc3N3b3Jkcw0KDQoqIEEgc2ltcGxlIHBy b3RvY29sIHRvIHBlcm1pdCB0aGUgdmVyaWZpY2F0aW9uIG9mIGF1dGhlbnRp Y2F0aW9uDQogIGNyZWRlbnRpYWxzIGFnYWluc3QgYW4gYXV0aGVudGljYXRp b24vYXV0aG9yaXphdGlvbiBkYXRhYmFzZS4NCiAgUkFESVVTIHdpbGwgYmUg cmV2aWV3ZWQgdG8gZGV0ZXJtaW5lIGlmIGl0IGlzIGFwcHJvcHJpYXRlIGZv cg0KICBhcHBsaWNhdGlvbiBsZXZlbCB1c2UuDQoNCiogQW4gUkZDIHdoaWNo IGRvY3VtZW50cyB0aGUgb3ZlcmFsbCBhcmNoaXRlY3R1cmUgZm9yIGFwcGxp Y2F0aW9uDQogIHByb3RvY29scyBhbmQgbWFrZXMgcmVjb21tZW5kYXRpb25z IGZvciBob3cgYXBwbGljYXRpb24gcHJvdG9jb2wNCiAgaW1wbGVtZW50b3Jz IGNhbiBzdXBwb3J0IHZhcmlvdXMgc2VjdXJpdHkgc2NlbmFyaW9zLg0KDQpU aGUgc2Vjb25kIHByaW9yaXR5IGRlbGl2ZXJhYmxlcyBhcmU6DQoNCiogQW4g SW5mb3JtYXRpb25hbCBSRkMgd2hpY2ggZG9jdW1lbnRzIHZlbmRvciBzdXBw b3J0IGZvciB0aGlzDQogIGFyY2hpdGVjdHVyZS4gIFRoaXMgd2lsbCByZXF1 aXJlIGFuIG91dHJlYWNoIGVmZm9ydCB0byBJbnRlcm5ldA0KICBzZXJ2ZXIg dmVuZG9ycyB0byBkZXRlcm1pbmUgaG93IHRoZXkgY2FuIGludGVncmF0ZSBh ICJubyBwbGFpbnRleHQNCiAgcGFzc3dvcmRzIG9uIHRoZSBuZXR3b3JrIiBh cmNoaXRlY3R1cmUgaW50byBvcGVyYXRpbmcgc3lzdGVtDQogIHNlcnZpY2Vz IHN1Y2ggYXMgbG9naW4sIGNoYW5nZSBwYXNzd29yZCwgc3dpdGNoIHVzZXIg YW5kIHByb3ByaWV0YXJ5DQogIHNlY3VyZSBzZXJ2aWNlcy4NCg0KKiBBbiBS RkMgd2hpY2ggbWFrZXMgYSByZWNvbW1lbmRhdGlvbiBmb3IgYSBzbWFsbCBz ZXQgb2YgZW5jcnlwdGlvbg0KICB0ZWNobm9sb2dpZXMgZm9yIHVzZSBpbiBh cHBsaWNhdGlvbiBwcm90b2NvbHMgd2hpY2ggbWVldCB0aGUNCiAgYXJjaGl0 ZWN0dXJlIGNyaXRlcmlhIGxpc3RlZCBhYm92ZS4gIFRoZSBnb2FsIGlzIHRv IG1ha2UNCiAgaW50ZXJvcGVyYWJsZSBlbmNyeXB0aW9uIGVhc2llciB0byBk ZXBsb3kuDQoNCiogQW4gUkZDIHdoaWNoIHJlY29tbWVuZHMgYSBzaW5nbGUg cmVtb3RlIGxvZ2luIHByb3RvY29sIGZvciB1c2Ugd2l0aA0KICB0aGlzIGFy Y2hpdGVjdHVyZS4gIElmIG5lY2Vzc2FyeSB0aGlzIHdpbGwgcmVwYWlyIHBy b2JsZW1zIGluIHRoYXQNCiAgcHJvdG9jb2wgb3IgZXh0ZW5kIGl0IHRvIG1l ZXQgdGhlIGFyY2hpdGVjdHVyZSBjcml0ZXJpYS4NCg0KKiBBbiBSRkMgd2hp Y2ggZG9jdW1lbnRzIGFuIEFQSSBmb3IgdXNlIHdpdGggU0FTTA0KIA0KIEdv YWxzIGFuZCBNaWxlc3RvbmVzOiANCg0KICAgSnVuIDk3ICAgICAgIEZpcnN0 IGRyYWZ0IG9mIFNBU0wgcGFzc3dvcmQgdHJhbnNpdGlvbiBkb2N1bWVudA0K DQogICBKdWwgOTcgICAgICAgRmlyc3QgZHJhZnQgb2YgcGFzc3dvcmQgY2hh bmdlIGRvY3VtZW50DQoNCiAgIEF1ZyA5NyAgICAgICBGaXJzdCBkcmFmdCBv ZiBhdXRoZW50aWNhdGlvbiB2ZXJpZmljYXRpb24gcHJvdG9jb2wsDQogICAg ICAgICAgICAgICAgaWYgZGVlbWVkIG5lY2Vzc2FyeQ0KDQogICBBdWcgOTcg ICAgICAgRmlyc3QgZHJhZnQgb2YgQ1JBTS1NRDUgcmVwbGFjZW1lbnQgZG9j dW1lbnQNCg0KICAgQXVnIDk3ICAgICAgIE1lZXQgaW4gTXVuaWNoDQoNCiAg IFNlcCA5NyAgICAgICBGaXJzdCBkcmFmdCBvZiBhcmNoaXRlY3R1cmUgZG9j dW1lbnQNCg0KICAgU2VwIDk3ICAgICAgIFNBU0wgdHJhbnNpdGlvbiBzdWJt aXR0ZWQgdG8gSUVTRyBmb3IgcHJvcG9zZWQgc3RhbmRhcmQNCg0KICAgU2Vw IDk3ICAgICAgIFBhc3N3b3JkIGNoYW5nZSBzdWJtaXR0ZWQgdG8gSUVTRyBm b3IgcHJvcG9zZWQgc3RhbmRhcmQNCg0KICAgT2N0IDk3ICAgICAgIEF1dGgg dmVyaWZpY2F0aW9uIHN1Ym1pdHRlZCB0byBJRVNHIGZvciBwcm9wb3NlZCBz dGFuZGFyZA0KDQogICBOb3YgOTcgICAgICAgQ1JBTS1NRDUgcmVwbGFjZW1l bnQgc3VibWl0dGVkIHRvIElFU0cgZm9yIHByb3Bvc2VkIHN0YW5kYXJkDQoN CiAgIE5vdiA5NyAgICAgICBGaXJzdCBkcmFmdCBvZiBlbmNyeXB0aW9uIGRv Y3VtZW50DQoNCiAgIE5vdiA5NyAgICAgICBGaXJzdCBkcmFmdCBvZiBTQVNM IEFQSQ0KDQogICBOb3YgOTcgICAgICAgRmlyc3QgZHJhZnQgb2YgcmVtb3Rl IGxvZ2luIGRvY3VtZW50DQoNCiAgIERlYyA5NyAgICAgICBGaXJzdCBkcmFm dCBvZiB2ZW5kb3IgZG9jdW1lbnQNCg0KICAgRGVjIDk3ICAgICAgIEFyY2hp dGVjdHVyZSBkb2N1bWVudCBzdWJtaXR0ZWQgdG8gSUVTRyBmb3IgPz8gc3Rh dHVzDQoNCiAgIEp1biA5OCAgICAgICBDb25jbHVkZSBXb3JraW5nIEdyb3Vw DQoNCiBJbnRlcm5ldC1EcmFmdHM6DQoNClBvc3RlZCBSZXZpc2VkICAgICAg IEktRCBUaXRsZSAgPEZpbGVuYW1lPg0KLS0tLS0tIC0tLS0tLS0gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiBSZXF1 ZXN0IEZvciBDb21tZW50czoNCg0KICBOb25lIHRvIGRhdGUuDQo= ---559023410-162216788-867275892=:19594-- From owner-ietf-sasl Tue Jul 8 11:26:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25850 for ietf-sasl-bks; Tue, 8 Jul 1997 11:26:49 -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 LAA25845 for ; Tue, 8 Jul 1997 11:26:41 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 8 Jul 1997 14:27:13 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 8 Jul 1997 14:27:12 -0400 Message-Id: <3.0.1.32.19970708143008.00b06540@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 08 Jul 1997 14:30:08 -0400 To: ietf-sasl@imc.org From: "Jack De Winter" Subject: regarding authentication IDs... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk okay, this may sound stupid, but bear with me... when we are adding SASL support to a layer like IMAP, POP3, or ACAP, it is easy to establish the identity of the remote user, and assign priviledges. Encryption just bolsters security. Now, if we are doing this at the transport level, say SMTP, is authentication pretty useless? If not, what kind of authentication should we all be promoting between SMTP servers? I can see the encryption having a strong case, but even in those cases, there might need to be some keys exchanged and this issue of 'identity' may come up again. regards, Jack p.s. Almost forgot, if you are submitting a message into a system using SMTP, then the above is easy. It's more of the 'once I have submitted the message' case that I am concerned with. ------------------------------------------------- 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 Jul 8 12:10:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA26400 for ietf-sasl-bks; Tue, 8 Jul 1997 12:10:07 -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 MAA26394 for ; Tue, 8 Jul 1997 12:10:01 -0700 (PDT) Received: from eleanor.innosoft.com ("port 37455"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IKZS4W6Q8Q8WW2L9@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 8 Jul 1997 12:11:38 PDT Date: Tue, 08 Jul 1997 12:13:24 -0700 (PDT) From: Chris Newman Subject: Re: regarding authentication IDs... In-reply-to: <3.0.1.32.19970708143008.00b06540@lacroix.wildbear.on.ca> To: Jack De Winter Cc: 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 Tue, 8 Jul 1997, Jack De Winter wrote: > Now, if we are doing this at the transport level, say SMTP, > is authentication pretty useless? It can be used within an enclave to prevent forged email, or to authenticate/bill services such as an email->fax gateway. It's also necessary to prevent man-in-the-middle attacks when doing encryption. From owner-ietf-sasl Tue Jul 8 12:22:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA26520 for ietf-sasl-bks; Tue, 8 Jul 1997 12:22:38 -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 MAA26516 for ; Tue, 8 Jul 1997 12:22:30 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 8 Jul 1997 15:23:05 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 8 Jul 1997 15:23:05 -0400 Message-Id: <3.0.1.32.19970708152601.00b14b80@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 08 Jul 1997 15:26:01 -0400 To: Chris Newman From: "Jack De Winter" Subject: Re: regarding authentication IDs... Cc: ietf-sasl@imc.org In-Reply-To: References: <3.0.1.32.19970708143008.00b06540@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 12:13 PM 7/8/97 -0700, Chris Newman wrote: >On Tue, 8 Jul 1997, Jack De Winter wrote: >> Now, if we are doing this at the transport level, say SMTP, >> is authentication pretty useless? > >It can be used within an enclave to prevent forged email, or to >authenticate/bill services such as an email->fax gateway. It's also >necessary to prevent man-in-the-middle attacks when doing encryption. True... I can see those uses. However, if we are going to use this at a SMTP level generically, shouldn't we try to agree on certain types of methods for exchanging information about the authentication types? A good example are two servers we have, one on a separate system. I would like to set them up to allow for full permissions from within the environ, but accept only incoming mail from outside of the environ. Now, should we simply agree on a format for exchanging the names of the servers? Or do we just create dummy accounts on the systems that would allow the other system to authenticate? I personally would prefer to see a difference between system level and user level accounts, and would prefer if it was interoperable on a large scale. I.e. So I could set it up so that I could get Chris' system to authenticate relatively easily. i.e. can we make a decision on how systems should authenticate, independant of the user? or at least make recommendations for the people writing the profiles for system to system protocols? 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 Jul 8 15:14:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA28593 for ietf-sasl-bks; Tue, 8 Jul 1997 15:14:40 -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 PAA28589 for ; Tue, 8 Jul 1997 15:14:36 -0700 (PDT) Received: from eleanor.innosoft.com ("port 37552"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IKZYKYWIVK8WW7EN@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 8 Jul 1997 15:16:24 PDT Date: Tue, 08 Jul 1997 15:18:11 -0700 (PDT) From: Chris Newman Subject: Re: regarding authentication IDs... In-reply-to: <3.0.1.32.19970708152601.00b14b80@lacroix.wildbear.on.ca> To: Jack De Winter Cc: 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 Tue, 8 Jul 1997, Jack De Winter wrote: > True... I can see those uses. However, if we are going to use > this at a SMTP level generically, shouldn't we try to agree on > certain types of methods for exchanging information about the > authentication types? The authentication types are listed as arguments to the AUTH EHLO keyward. > i.e. can we make a decision on how systems should authenticate, > independant of the user? or at least make recommendations for the > people writing the profiles for system to system protocols? So you want a naming convention for services at a host? I'd suggest using the KerberosV4 naming convention: . So the user "smtp.innosoft.com" would refer to the SMTP service at the innosoft.com domain. From owner-ietf-sasl Wed Jul 9 07:18:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA09145 for ietf-sasl-bks; Wed, 9 Jul 1997 07:18:18 -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 HAA09140 for ; Wed, 9 Jul 1997 07:18:10 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Wed, 9 Jul 1997 10:19:22 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Wed, 9 Jul 1997 10:19:21 -0400 Message-Id: <3.0.1.32.19970709102157.00b2a700@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 09 Jul 1997 10:21:57 -0400 To: Chris Newman From: "Jack De Winter" Subject: Re: regarding authentication IDs... Cc: ietf-sasl@imc.org In-Reply-To: References: <3.0.1.32.19970708152601.00b14b80@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 03:18 PM 7/8/97 -0700, Chris Newman wrote: >> i.e. can we make a decision on how systems should authenticate, >> independant of the user? or at least make recommendations for the >> people writing the profiles for system to system protocols? > >So you want a naming convention for services at a host? > >I'd suggest using the KerberosV4 naming convention: >. > >So the user "smtp.innosoft.com" would refer to the SMTP service at the >innosoft.com domain. I think this is a good approach. This way I would be able to allow chris's server to do certain types of traffic and not others. Questions: 1) Would there by an all encompassing service type? 2) How to handle an entire domain? (i.e. how to allow *.innosoft.com to be able to use those services) 3) What kind of collision to expect between the system space and the user name space? How to handle them? 3a) Perhaps a variation, such as @ would avoid some of the collisions. Other than the questions though, it seems like a straightforward approach. 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 Wed Jul 9 09:34:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA11108 for ietf-sasl-bks; Wed, 9 Jul 1997 09:34:38 -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 JAA11104 for ; Wed, 9 Jul 1997 09:34:33 -0700 (PDT) Received: from eleanor.innosoft.com ("port 37704"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IL110O4BH88WW4RQ@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 9 Jul 1997 09:37:07 PDT Date: Wed, 09 Jul 1997 09:38:53 -0700 (PDT) From: Chris Newman Subject: Re: regarding authentication IDs... In-reply-to: <3.0.1.32.19970709102157.00b2a700@lacroix.wildbear.on.ca> To: Jack De Winter Cc: 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 Wed, 9 Jul 1997, Jack De Winter wrote: > I think this is a good approach. This way I would be able to allow > chris's server to do certain types of traffic and not others. > > Questions: > 1) Would there by an all encompassing service type? I'm not sure there's a need. > 2) How to handle an entire domain? (i.e. how to allow *.innosoft.com to > be able to use those services) To be more precise, Kerberos uses the convention: .@ is the identity, is an instance of that identity, and is the authentication database. For servers, Kerberos uses the service name for and the server name for . > 3) What kind of collision to expect between the system space and the user > name space? How to handle them? > 3a) Perhaps a variation, such as @ would > avoid some of the collisions. The "@" has a different meaning in the Kerberos model and I'd rather not create a new naming model. From owner-ietf-sasl Wed Jul 9 09:54:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA11365 for ietf-sasl-bks; Wed, 9 Jul 1997 09:54:41 -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 JAA11360 for ; Wed, 9 Jul 1997 09:54:34 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Wed, 9 Jul 1997 12:55:48 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Wed, 9 Jul 1997 12:55:47 -0400 Message-Id: <3.0.1.32.19970709125822.00a56630@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 09 Jul 1997 12:58:22 -0400 To: ietf-sasl@imc.org From: "Jack De Winter" Subject: regarding the CRAM-MD5/SHA authentication type Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk has anyone approached any of the MCI guys to resubmit a variant on their CRAM-MD5 SASL type so that it uses the authorization-id NUL authentication-id NUL digest NUL or something like that instead of the authentication/authorization-id SPACE digest model that is being used now? I.e. you can only 'login' as the identity that you are authenticating for. 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 Wed Jul 9 11:02:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12413 for ietf-sasl-bks; Wed, 9 Jul 1997 11:02:57 -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 LAA12409 for ; Wed, 9 Jul 1997 11:02:49 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Wed, 9 Jul 1997 14:03:58 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Wed, 9 Jul 1997 14:03:57 -0400 Message-Id: <3.0.1.32.19970709140631.0107ca50@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 09 Jul 1997 14:06:31 -0400 To: Chris Newman From: "Jack De Winter" Subject: Re: regarding authentication IDs... Cc: ietf-sasl@imc.org In-Reply-To: References: <3.0.1.32.19970709102157.00b2a700@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 09:38 AM 7/9/97 -0700, Chris Newman wrote: >On Wed, 9 Jul 1997, Jack De Winter wrote: >> I think this is a good approach. This way I would be able to allow >> chris's server to do certain types of traffic and not others. >> >> Questions: >> 1) Would there by an all encompassing service type? > >I'm not sure there's a need. I am thinking about cases where we want to have multiple server to server levels with different permissions. Or in that case, does the server just ignore the service type and use the rest? >> 2) How to handle an entire domain? (i.e. how to allow *.innosoft.com to >> be able to use those services) > >To be more precise, Kerberos uses the convention: .@ > > is the identity, is an instance of that identity, and > is the authentication database. For servers, Kerberos uses the >service name for and the server name for . Would an example of this be smtp.thor@innosoft.com? >> 3) What kind of collision to expect between the system space and the user >> name space? How to handle them? >> 3a) Perhaps a variation, such as @ would >> avoid some of the collisions. > >The "@" has a different meaning in the Kerberos model and I'd rather not >create a new naming model. fair enough... as long as we can come up with a good way to differntiate, for example, a client to a SMTP server and another server to that SMTP server, with no ambiguity. That is my main case. 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 Wed Jul 9 12:21:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA13444 for ietf-sasl-bks; Wed, 9 Jul 1997 12:21:58 -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 MAA13440 for ; Wed, 9 Jul 1997 12:21:54 -0700 (PDT) Received: from eleanor.innosoft.com ("port 37941"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IL16TYL38Q8WW6KD@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 9 Jul 1997 12:23:30 PDT Date: Wed, 09 Jul 1997 12:25:16 -0700 (PDT) From: Chris Newman Subject: Re: regarding the CRAM-MD5/SHA authentication type In-reply-to: <3.0.1.32.19970709125822.00a56630@lacroix.wildbear.on.ca> 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 Wed, 9 Jul 1997, Jack De Winter wrote: > has anyone approached any of the MCI guys to resubmit a > variant on their CRAM-MD5 SASL type so that it uses > the > > authorization-id NUL authentication-id NUL digest NUL > > or something like that instead of the > > authentication/authorization-id SPACE digest > > model that is being used now? I.e. you can only 'login' as > the identity that you are authenticating for. Ned is working on a draft describing the SHA1 hash algorithm. When that's done, I'll consider doing a CRAM-SHA1 which fixes the authorization-id problem in CRAM-MD5. Now whether we should do yet another hash-based mechanism is a good question. From owner-ietf-sasl Thu Jul 24 13:15:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA25530 for ietf-sasl-bks; Thu, 24 Jul 1997 13:15:49 -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 NAA25526 for ; Thu, 24 Jul 1997 13:15:46 -0700 (PDT) Received: from eleanor.innosoft.com ("port 47297"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILM74SSNN48WX7X0@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 24 Jul 1997 13:18:53 PDT Date: Thu, 24 Jul 1997 13:20:42 -0700 (PDT) From: Chris Newman Subject: Anonymous SASL mechanism To: ietf-sasl@imc.org, IETF ACAP Mailing List 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 I think is ready to go to IETF 4-week last call. Anyone have any last minute comments? - Chris From owner-ietf-sasl Mon Sep 15 14:29:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA14355 for ietf-sasl-bks; Mon, 15 Sep 1997 14:29:51 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA14351 for ; Mon, 15 Sep 1997 14:29:48 -0700 (PDT) Received: from eleanor.innosoft.com ("port 48404"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01INOB2W0PIY94G6CB@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 15 Sep 1997 14:30:29 PDT Date: Mon, 15 Sep 1997 14:32:28 -0700 (PDT) From: Chris Newman Subject: SCRAM mechanism 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 I've put together an internet draft for a new SASL mechanism. The draft is 12 pages, and located at: This is similar to CRAM-MD5 (RFC 2195), with a few additions: (1) The verifier stored on the server is not plaintext-equivalent. (2) It includes an authorization identity. (3) It uses SHA1, which is believed to be better than MD5. (4) It includes the service name and server name in the exchange to permit the server to proxy to a remote authentication database. (5) It adds a client nonce and mutual authentication step, to deal with spoof servers. Here are some issues I'd like to see discussion on: (A) SCRAM-SHA1 differs from CRAM-MD5 in that it uses binary encodings rather than textual encodings. Since about half of the data (nonces, hash results) is likely to be binary, I felt it was unnecessary complexity to add something like the hex-encoding that CRAM-MD5 uses. In addition, the binary encoding allows user names to have spaces, unlike CRAM-MD5. However, this makes debugging the textual portions of the protocol harder, as with all binary encodings. Anyone think I should go back to a more textual format? (B) I didn't bother adding an integrity layer because it would make the document quite a bit longer and more confusing. The dictionary attack and stolen verifier attacks against SCRAM are powerful enough that I think adding an integrity layer and pretending it's "secure from tampering" is misleading. Anyone think I should add an integrity option? (C) I didn't add an encryption option since there's no forward secrecy (a stolen verifier would expose all sessions encrypted with that password) so it didn't seem like a big enough gain for the complexity. (D) Tom Wu's "TWEKE" modification discussed in appendix B is probably safe from undetectable tampering (an active attack could be detected after the fact from logfiles on the machines). It also adds a Diffie-Hellman key exchange which is serious cryptography requiring a bignum math package (although not much else). I'd be willing to drop SCRAM in favor of TWEKE if people felt it was likely to be deployed. I think the bignum package would be an undesirable barrier to most client authors as opposed to the page or two of code for SCRAM, but I'm far from sure. Thoughts? (E) Should the server identifier also include a realm name? It's currently written so it would be easy to add later, but has no specific semantics. I don't want to add all the unnecessary complexity of Compuserve's RPA proposal, but I think its intended functionality is important. (F) CRAM-MD5 can use an authentication DB which doesn't include the plaintext itself (although it's still plaintext-equivalent) -- it basically involves saving the initialized HMAC-MD5 machinery. I could change SCRAM to use MD5 and HMAC on the first step so that it could share a CRAM-MD5 authentication DB. Would that be worthwhile? - Chris From owner-ietf-sasl Wed Oct 29 06:44:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA00720 for ietf-sasl-bks; Wed, 29 Oct 1997 06:44:36 -0800 (PST) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA00716 for ; Wed, 29 Oct 1997 06:44:32 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA17007; Wed, 29 Oct 1997 09:43:59 -0500 (EST) Message-Id: <199710291443.JAA17007@ietf.org> 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-smtp-auth-08.txt Date: Wed, 29 Oct 1997 09:43:58 -0500 Sender: owner-ietf-sasl@imc.org Precedence: bulk --NextPart A New 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-08.txt Pages : 8 Date : 28-Oct-97 This document defines an SMTP service extension [ESMTP] 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 wih 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-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-smtp-auth-08.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-08.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: <19971028151714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-smtp-auth-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-smtp-auth-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971028151714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Oct 29 08:20:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA02626 for ietf-sasl-bks; Wed, 29 Oct 1997 08:20:59 -0800 (PST) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA02619 for ; Wed, 29 Oct 1997 08:20:53 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA19431; Wed, 29 Oct 1997 11:19:22 -0500 (EST) Message-Id: <199710291619.LAA19431@ietf.org> 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-sasl-pop3-02.txt Date: Wed, 29 Oct 1997 11:19:21 -0500 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-02.txt Pages : 6 Date : 28-Oct-97 This document defines the optional AUTH command to POP3 [POP3], 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 wih 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-sasl-pop3-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.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: <19971028151358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-sasl-pop3-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-sasl-pop3-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971028151358.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Oct 29 09:26:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA03823 for ietf-sasl-bks; Wed, 29 Oct 1997 09:26:53 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA03819 for ; Wed, 29 Oct 1997 09:26:49 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id JAA05887 for ; Wed, 29 Oct 1997 09:24:09 -0800 (PST) Message-Id: <3.0.3.32.19971029092613.0086fa10@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 29 Oct 1997 09:26:13 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Approval as Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk I just noticed that this message didn't get sent to the ietf-sasl mailing list. Congradulations all around! --Paul Hoffman, Director --Internet Mail Consortium To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board From: The IESG Subject: Protocol Action: Simple Authentication and Security Layer (SASL) to Proposed Standard Date: Mon, 27 Oct 1997 07:47:46 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft "Simple Authentication and Security Layer (SASL)" as a Proposed Standard. It is not a product of an IETF working group. The IESG contact person is Jeffrey I. Schiller. Technical Summary SASL is a protocol suitable for command line protocols (such as POP, IMAP or SMTP) to negotiate an exercise a security method such as OTP (S/KEY), Kerberos, a GSSAPI mechanism or similar technology. Working Group Summary N/A Protocol Quality The Security Area Director (Jeffrey I. Schiller) has reviewed this document and concluded that it performs its function as described. There are no known security vulnerabilities (besides those inherent whenever a security mechanism is negotiated between two parties) introduced by the use of this protocol. Overall network security can be improved by appropriate use of SASL with mechanisms that do not expose passwords over the network unencrypted. From owner-ietf-sasl Tue Nov 4 15:34:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA15880 for ietf-sasl-bks; Tue, 4 Nov 1997 15:34:18 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA15875 for ; Tue, 4 Nov 1997 15:34:14 -0800 (PST) Received: from pferdle.mcom.com (pferdle.mcom.com [198.93.94.249]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA03156 for ; Tue, 4 Nov 1997 15:33:34 -0800 (PST) Received: (from dmose@localhost) by pferdle.mcom.com (8.8.5/8.8.5) id PAA10049; Tue, 4 Nov 1997 15:33:33 -0800 (PST) To: ietf-sasl@imc.org From: John Gardiner Myers Subject: SMTP SASL document Date: Mon, 03 Nov 1997 18:50:26 -0800 Organization: Netscape Communications Corporation Lines: 3 Message-ID: <345E8D72.A4960CA3@netscape.com> NNTP-Posting-Host: 205.217.229.208 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.03 [en] (WinNT; U) Sender: owner-ietf-sasl@imc.org Precedence: bulk Sorry folks, I neglected to deal with some comments I had received on the previous SMTP draft. Please ignore draft-myers-smtp-auth-08.txt and I'll issue a new document RSN. From owner-ietf-sasl Wed Nov 12 11:08:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA09115 for ietf-sasl-bks; Wed, 12 Nov 1997 11:08:26 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA09108 for ; Wed, 12 Nov 1997 11:08:22 -0800 (PST) Received: from eleanor.innosoft.com ("port 50124"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IPX4WSSENI9JF41E@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 12 Nov 1997 11:07:57 PST Date: Wed, 12 Nov 1997 11:10:08 -0800 (PST) From: Chris Newman Subject: Feedback on RFC 2195: CRAM-MD5 To: John C Klensin , Paul Krumviede , randy@mci.net Cc: 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 There was a discussion of the CRAM-MD5 mechanism on the LDAPEXT mailing list. Since LDAP uses spaces in user names, it's important that CRAM-MD5 implementations do a right-to-left parse to support that. I think this needs to be documented in the next revision to the spec (presumably a draft standard revision next March). A formal grammar and some sample code (which I'd be willing to supply, if you wish) would also be useful. - Chris From owner-ietf-sasl Wed Nov 12 21:24:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA18943 for ietf-sasl-bks; Wed, 12 Nov 1997 21:24:52 -0800 (PST) Received: from a4.jck.com ([206.99.215.40]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA18925 for ; Wed, 12 Nov 1997 21:24:46 -0800 (PST) Received: from tp7.Jck.com ("port 1554"@[206.99.215.42]) by a4.jck.com (PMDF V5.1-8 #25486) with SMTP id <0EJKKDU3V00OY8@a4.jck.com> for ietf-sasl@imc.org; Thu, 13 Nov 1997 00:25:06 -0500 (EST) Date: Thu, 13 Nov 1997 00:25:04 -0500 (EST) From: John C Klensin Subject: Re: Feedback on RFC 2195: CRAM-MD5 In-reply-to: To: Chris Newman Cc: randy@mci.net, Paul Krumviede , ietf-sasl@imc.org Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.3 Build (39) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-sasl@imc.org Precedence: bulk On Wed, 12 Nov 1997 11:10:08 -0800 (PST) Chris Newman wrote: > There was a discussion of the CRAM-MD5 mechanism on the LDAPEXT mailing > list. Since LDAP uses spaces in user names, it's important that CRAM-MD5 > implementations do a right-to-left parse to support that. >... > A formal grammar and some sample code (which I'd be willing to supply, if > you wish) would also be useful. If you supply it, we will enthusiastically review it and paste it in. john From owner-ietf-sasl Thu Nov 13 06:49:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA27426 for ietf-sasl-bks; Thu, 13 Nov 1997 06:49:44 -0800 (PST) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA27421 for ; Thu, 13 Nov 1997 06:49:40 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08456; Thu, 13 Nov 1997 09:50:01 -0500 (EST) Message-Id: <199711131450.JAA08456@ietf.org> 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-smtp-auth-09.txt Date: Thu, 13 Nov 1997 09:50:01 -0500 Sender: owner-ietf-sasl@imc.org Precedence: bulk --NextPart A New 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-09.txt Pages : 8 Date : 12-Nov-97 This document defines an SMTP service extension [ESMTP] 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-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-smtp-auth-09.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-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: <19971112114906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-smtp-auth-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-smtp-auth-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971112114906.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Nov 14 17:17:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA28896 for ietf-sasl-bks; Fri, 14 Nov 1997 17:17:12 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA28892 for ; Fri, 14 Nov 1997 17:17:08 -0800 (PST) Received: from eleanor.innosoft.com ("port 49976"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQ0ADLKMPW9LUYJH@INNOSOFT.COM> for ietf-sasl@imc.org; Fri, 14 Nov 1997 17:16:38 PST Date: Fri, 14 Nov 1997 17:18:52 -0800 (PST) From: Chris Newman Subject: I-D ACTION:draft-newman-sasl-plaintrans-04.txt (fwd) To: ietf-sasl@imc.org Message-id: Content-id: MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="-559023410-1903590565-879556732=:16241" Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-sasl@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1903590565-879556732=:16241 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I'm planning to ask that this become an Informational RFC. It defines the "PLAIN" SASL mechanism for plaintext login. Please review this if you get a chance. Thanks, - Chris ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 11:57:14 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce@ietf.org Subject: I-D ACTION:draft-newman-sasl-plaintrans-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Plaintext Password SASL Mechanism for Transitioning Author(s) : C. Newman Filename : draft-newman-sasl-plaintrans-04.txt Pages : 9 Date : 13-Nov-97 Unencrypted plaintext passwords are the biggest single risk to Internet application protocol security. Unfortunately, they are widely deployed, often tightly integrated into operating system services and very difficult to replace in an interoperable fashion. This specification discusses some methods which can be used to eliminate unencrypted plaintext passwords. It also defines a SASL mechanism [SASL] which may be used by newer protocols such as ACAP [ACAP] to transition away from a legacy authentication database. 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-newman-sasl-plaintrans-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-sasl-plaintrans-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu ---559023410-1903590565-879556732=:16241-- From owner-ietf-sasl Fri Nov 21 15:41:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA27100 for ietf-sasl-bks; Fri, 21 Nov 1997 15:41:36 -0800 (PST) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA27096 for ; Fri, 21 Nov 1997 15:41:31 -0800 (PST) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id PAA14222 for <@starfish.mcom.com:ietf-sasl@imc.org>; Fri, 21 Nov 1997 15:42:00 -0800 (PST) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA08169 for ; Fri, 21 Nov 1997 15:43:50 -0800 To: ietf-sasl@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-sasl Subject: mailing list last call: pop and smtp sasl Date: Fri, 21 Nov 1997 15:42:01 -0800 Organization: Netscape Communications Corporation Lines: 2 Message-ID: <34761C49.65CFC7F8@netscape.com> NNTP-Posting-Host: 205.217.229.208 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.03 [en] (WinNT; U) Sender: owner-ietf-sasl@imc.org Precedence: bulk I will shortly be asking the pop3 and smtp SASL drafts to go to IETF Last Call. Please send any last-minute comments. From owner-ietf-sasl Mon Nov 24 10:52:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07514 for ietf-sasl-bks; Mon, 24 Nov 1997 10:52:49 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA07509 for ; Mon, 24 Nov 1997 10:52:46 -0800 (PST) Received: from eleanor.innosoft.com ("port 34574"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQDVVLOBJS9LVDNB@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 24 Nov 1997 10:53:09 PST Date: Mon, 24 Nov 1997 10:55:22 -0800 (PST) From: Chris Newman Subject: Re: mailing list last call: pop and smtp sasl In-reply-to: <34761C49.65CFC7F8@netscape.com> To: John Gardiner Myers Cc: 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 Fri, 21 Nov 1997, John Gardiner Myers wrote: > I will shortly be asking the pop3 and smtp SASL drafts to go to IETF > Last Call. Please send any last-minute comments. When I was writing the TLS extension to POP3 draft, I realized it introduced an ugly mess in combination with the SASL AUTH command. A client has to probe both for the "AUTH" command and for the "STLS" command, then decide what security to do. I think the right way to address this is to have a proper extension mechanism for POP3. I wrote a first cut: draft-newman-pop3ext-00.txt - Chris From owner-ietf-sasl Mon Nov 24 11:15:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA07882 for ietf-sasl-bks; Mon, 24 Nov 1997 11:15:00 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA07877 for ; Mon, 24 Nov 1997 11:14:54 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA24270 for ; Mon, 24 Nov 1997 11:15:20 -0800 (PST) Received: from netscape.com ([205.217.229.208]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA19572 for ; Mon, 24 Nov 1997 11:15:20 -0800 Message-ID: <3479D248.1A69B5A0@netscape.com> Date: Mon, 24 Nov 1997 11:15:20 -0800 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.04b9 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: mailing list last call: pop and smtp sasl References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris Newman wrote: > I think the right way to > address this is to have a proper extension mechanism for POP3. I wrote a > first cut: draft-newman-pop3ext-00.txt There is existing widely deployed code using the mechanism described in the draft. From owner-ietf-sasl Mon Nov 24 11:45:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA08344 for ietf-sasl-bks; Mon, 24 Nov 1997 11:45:43 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA08338 for ; Mon, 24 Nov 1997 11:45:40 -0800 (PST) Received: from eleanor.innosoft.com ("port 34595"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQDXPRFD6K9LVDNB@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 24 Nov 1997 11:45:42 PST Date: Mon, 24 Nov 1997 11:47:58 -0800 (PST) From: Chris Newman Subject: Re: mailing list last call: pop and smtp sasl In-reply-to: <3479D248.1A69B5A0@netscape.com> To: John Myers Cc: 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, 24 Nov 1997, John Myers wrote: > Chris Newman wrote: > > I think the right way to > > address this is to have a proper extension mechanism for POP3. I wrote a > > first cut: draft-newman-pop3ext-00.txt > > There is existing widely deployed code using the mechanism described in > the draft. I still think that the extension mechanism is a better solution long term. Would you object to having the extension announcement mechanism in addition to what's in the POP3 AUTH spec? - Chris From owner-ietf-sasl Mon Nov 24 15:27:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA11094 for ietf-sasl-bks; Mon, 24 Nov 1997 15:27:47 -0800 (PST) Received: from clea.qualcomm.com (clea.qualcomm.com [129.46.52.24]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA11089 for ; Mon, 24 Nov 1997 15:27:44 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by clea.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id PAA14321; Mon, 24 Nov 1997 15:27:35 -0800 (PST) Message-Id: In-Reply-To: References: <3479D248.1A69B5A0@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Mon, 24 Nov 1997 15:13:20 -0800 To: Chris Newman From: Randall Gellens Subject: Re: mailing list last call: pop and smtp sasl Cc: John Myers , ietf-sasl@imc.org, lgl@qualcomm.com Sender: owner-ietf-sasl@imc.org Precedence: bulk At 11:47 AM -0800 11/24/97, Chris Newman wrote: >I still think that the extension mechanism is a better solution long term. >Would you object to having the extension announcement mechanism in >addition to what's in the POP3 AUTH spec? I'd go further; I think the standard should be a general extension announcement mechanism. The empty AUTH probe should be a MAY, and discouraged for new code. -- Randall Gellens || Opinions are personal; facts are suspect; randy@qualcomm.com || I speak for myself alone f u cn rd ths, itn tyg h myxbl cd. From owner-ietf-sasl Wed Nov 26 19:14:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA29407 for ietf-sasl-bks; Wed, 26 Nov 1997 19:14:46 -0800 (PST) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA29403 for ; Wed, 26 Nov 1997 19:14:42 -0800 (PST) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id WAA03051; Wed, 26 Nov 1997 22:15:57 -0500 (EST) Received: via switchmail; Wed, 26 Nov 1997 22:15:56 -0500 (EST) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 26 Nov 1997 22:15:04 -0500 (EST) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 26 Nov 1997 22:14:35 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Wed, 26 Nov 1997 22:14:22 -0500 (EST) Message-ID: <0oTCKC200WC7033LY0@andrew.cmu.edu> Date: Wed, 26 Nov 1997 22:14:22 -0500 (EST) From: Rob Earhart To: IETF ACAP Mailing List , ietf-sasl@imc.org Subject: Re: mailing list last call: pop and smtp sasl CC: John Gardiner Myers In-Reply-To: <01IQH2EW9TM89N3WJB@INNOSOFT.COM> References: <3479D248.1A69B5A0@netscape.com> <347CB1BA.77B054ED@netscape.com> <01IQH2EW9TM89N3WJB@INNOSOFT.COM> X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-sasl@imc.org Precedence: bulk (Is there any reason why this is being discussed on the ietf-acap mailing list, instead of ietf-sasl, where it started?) Personally, I'm with John; POP3's useful if you need to interact with legacy systems, but it seems a bit silly to take the time and effort to work on POP3 to the point of defining a generic extension mechanism that'll be good in the long run, since in the long run, everything ought to transition to IMAP anyway. Encouraging the use of POP3 seems harmful at this point; I'd rather see it just go away. )Rob From owner-ietf-sasl Mon Dec 1 10:22:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA29554 for ietf-sasl-bks; Mon, 1 Dec 1997 10:22:52 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA29550 for ; Mon, 1 Dec 1997 10:22:47 -0800 (PST) Received: from eleanor.innosoft.com ("port 38377"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQNMX39AQI9TCO9I@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 1 Dec 1997 10:24:10 PST Date: Mon, 01 Dec 1997 10:26:27 -0800 (PST) From: Chris Newman Subject: Re: mailing list last call: pop and smtp sasl In-reply-to: <0oTCKC200WC7033LY0@andrew.cmu.edu> To: ietf-sasl@imc.org Cc: John Gardiner Myers 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 Wed, 26 Nov 1997, Rob Earhart wrote: > (Is there any reason why this is being discussed on the ietf-acap > mailing list, instead of ietf-sasl, where it started?) [Moving conversation to SASL list] > Personally, I'm with John; POP3's useful if you need to interact > with legacy systems, but it seems a bit silly to take the time and > effort to work on POP3 to the point of defining a generic extension > mechanism that'll be good in the long run, since in the long run, > everything ought to transition to IMAP anyway. > > Encouraging the use of POP3 seems harmful at this point; I'd rather > see it just go away. I disagree. I'm of the opinion that use of IMAP for the offline access mode (as opposed to online or disconnected) is actively harmful and usually results in lost email. Therefore, anyone using offline access mode should use POP3. It's much simpler to explain to users that "POP3" means copy the email to your desktop machine and "IMAP" means keep the authoritative copy on the server. That's not strictly required by either protocol, but it results in a clean and safe architecture. There are few, if any, released disconnected mode IMAP clients. Until such clients are widely available and of comparable quality to POP clients, POP will have a long and useful life. Therefore POP deserves the same attention to security as any other widely used IETF protocol. Now it is unfortunate that there are released products supporting a nonstandard extension to the POP AUTH command which lists SASL mechanisms. But does that mean we must standardize the POP AUTH listing in a way which is different and inferior to the method used in other protocols? - Chris From owner-ietf-sasl Mon Dec 1 14:00:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA03150 for ietf-sasl-bks; Mon, 1 Dec 1997 14:00:47 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA03145 for ; Mon, 1 Dec 1997 14:00:44 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA20470 for ; Mon, 1 Dec 1997 14:01:50 -0800 (PST) Received: from netscape.com ([205.217.229.208]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA17482 for ; Mon, 1 Dec 1997 14:01:49 -0800 Message-ID: <348333CD.B2690872@netscape.com> Date: Mon, 01 Dec 1997 14:01:49 -0800 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.04b9 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: mailing list last call: pop and smtp sasl References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris Newman wrote: > I disagree. I'm of the opinion that use of IMAP for the offline access > mode (as opposed to online or disconnected) is actively harmful and > usually results in lost email. Let's break out one of the assumptions in this statement: This statement assumes the "download and delete" model of offline access that was pervasive about three years ago. Since then, the UIDL command has become widely deployed and the "leave mail on server" option of various POP clients has become fairly popular. A "leave mail on server" model of offline access does not have the problem you describe. > Therefore, anyone using offline access > mode should use POP3. It's much simpler to explain to users that "POP3" > means copy the email to your desktop machine and "IMAP" means keep the > authoritative copy on the server. That's not strictly required by either > protocol, but it results in a clean and safe architecture. The architecture is not any cleaner or safer: A user who mixes a "download and delete" POP client with an server-authoritative IMAP client is still going to lose their email. It just that the terminology used to explain to the hapless user why they lost their mail becomes more convenient. > There are few, if any, released disconnected mode IMAP clients. Until > such clients are widely available and of comparable quality to POP > clients, POP will have a long and useful life. This is an installed-base argument. It is good for establishing the short-term or medium-term importance of POP, but is not effective in establishing long-term importance of POP. > Therefore POP deserves the > same attention to security as any other widely used IETF protocol. To benefit from attention to POP in any area, one has to replace both the server and client base. Since your argument for paying attention to POP is that the installed base is entrenched, this is slightly contradictory. To keep from having to replace one's infrastructure, one will have to replace one's infrastructure. In actuality, there is a balance to be found between the benefits to people replacing their POP infrastructure with a new POP infrastructure and the cost of taking resources away from IMAP. It is arguable that security is critical enough to warrant POP extension. But your POP extension proposal is not necessary for security and goes into numerous areas that are in no way related to security. > Now it is unfortunate that there are released products supporting a > nonstandard extension to the POP AUTH command which lists SASL mechanisms. > But does that mean we must standardize the POP AUTH listing in a way which > is different and inferior to the method used in other protocols? The "nonstandard extension" represented consensus at the time, and the only reason it is not currently on the standards track is because it got procedurally held up by the inordinately long delay in the base SASL spec. The existence of an installed base requires one to consider the cost to said installed base when evaluating new proposals. From owner-ietf-sasl Mon Dec 1 16:30:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA05463 for ietf-sasl-bks; Mon, 1 Dec 1997 16:30:11 -0800 (PST) Received: from mysa.qualcomm.com (mysa.qualcomm.com [129.46.52.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA05459 for ; Mon, 1 Dec 1997 16:30:07 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by mysa.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id QAA14582; Mon, 1 Dec 1997 16:29:42 -0800 (PST) Message-Id: In-Reply-To: <347CCC50.88FDB753@netscape.com> References: <3479D248.1A69B5A0@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Mon, 1 Dec 1997 16:27:53 -0800 To: John Gardiner Myers From: Randall Gellens Subject: Re: mailing list last call: pop and smtp sasl Cc: ietf-sasl@imc.org, lgl@qualcomm.com Sender: owner-ietf-sasl@imc.org Precedence: bulk At 5:26 PM -0800 11/26/97, John Gardiner Myers wrote: >> There are cases where POP makes more sense. POP makes much fewer >> demands on the client. > >On what basis do you make this claim? If the client only wants POP >functionality, it's just a matter of which syntax to use. Maybe, but I still think a simple POP client is easier than a simple IMAP client. POP is also much better understood. And POP servers are very widely deployed. Upgrading a POP server to support SASL is a lot easier than converting a POP server to an IMAP server. Don't get me wrong: I very much support IMAP, and I agree that for most uses IMAP is much better than POP. But I think there is still a need for POP. If we get agreement on a standardized extension mechanism and SASL authentication for POP, I think Qualcomm would support it in QPopper. That would do a lot for SASL deployment. -- Randall Gellens || Opinions are personal; facts are suspect; randy@qualcomm.com || I speak for myself alone Mistakes are often the stepping stones to utter failure. From owner-ietf-sasl Tue Dec 2 09:52:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA21133 for ietf-sasl-bks; Tue, 2 Dec 1997 09:52:31 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA21129 for ; Tue, 2 Dec 1997 09:52:27 -0800 (PST) Received: from eleanor.innosoft.com ("port 38795"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQP052GN049TCPJT@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 2 Dec 1997 09:53:14 PST Date: Tue, 02 Dec 1997 09:55:32 -0800 (PST) From: Chris Newman Subject: Re: mailing list last call: pop and smtp sasl In-reply-to: <348333CD.B2690872@netscape.com> To: John Myers Cc: 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, 1 Dec 1997, John Myers wrote: > > I disagree. I'm of the opinion that use of IMAP for the offline access > > mode (as opposed to online or disconnected) is actively harmful and > > usually results in lost email. > ... > This statement assumes the "download and delete" model of offline access > that was pervasive about three years ago. Since then, the UIDL command > has become widely deployed and the "leave mail on server" option of > various POP clients has become fairly popular. The "leave mail on server" POP model is a poor man's disconnected mode access, IMHO. IMAP should be used instead for that purpose. However, I maintain that POP is the preferred protocol for the "download and delete" model and I don't forsee that usage model disappearing. It's far to useful for home users. Building "download and delete" IMAP clients is misleading to users and increases the risk of lost email. > To benefit from attention to POP in any area, one has to replace both > the server and client base. Since your argument for paying attention to > POP is that the installed base is entrenched, this is slightly > contradictory. To keep from having to replace one's infrastructure, one > will have to replace one's infrastructure. There is a difference between upgrading the POP server/client and switching to a different usage model. The former will be done by a good system manager periodically anyway, while the latter requires a testing, training and transition period. > It is arguable that security is critical enough to warrant POP > extension. But your POP extension proposal is not necessary for > security and goes into numerous areas that are in no way related to > security. The extension proposal also documents deployed variations in POP3 servers which are currently manually configured at the clients. If people ignore it, no harm done, if they use it, it simplifies things for the users. > The existence of an installed base requires one to consider the cost to > said installed base when evaluating new proposals. Here are the choices: (1) The capability command notes the presence of AUTH, but does not list mechanisms. Legacy clients which use AUTH to list mechanisms won't have to change. Newer clients will have an extra round trip on every connection and may break against servers which disconnect after two failed commands. Legacy servers will have to add the capability command if it becomes popular. Pros: low impact on legacy AUTH list clients Cons: bad architecture for new clients dissimilar to other SASL profiles works poorly with TLS (2) The capability command lists mechanisms as does the AUTH command. Legacy clients don't have to change. Newer clients will work better. Legacy servers will have to add the capability command if it becomes popular. Pros: low impact on legacy AUTH list clients. Cons: duplicate paths for same function creates possibility for silly state. (3) The capability command lists mechanisms, no requirement that AUTH command does. Legacy clients will have to be upgraded to interoperate with newer servers. Newer clients will work better. Legacy servers will have to add the capability command if it becomes popular. Pros: clean architecture Cons: upgrade to clients is a pain may have to deal with unpleasent server variations (4) Just use AUTH command. Pros: No impact on legacy AUTH list clients/servers. Cons: clients have to be manually configured bad architecture for new clients (probing) dissimilar to other SASL profiles works poorly with TLS I'd say that (2) or (3) is best, although I could live with (1). What do others think? - Chris From owner-ietf-sasl Tue Dec 2 10:24:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA21631 for ietf-sasl-bks; Tue, 2 Dec 1997 10:24:54 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA21627 for ; Tue, 2 Dec 1997 10:24:48 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IQOY41CQ409TCP0Q@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 2 Dec 1997 10:25:25 PST Date: Tue, 02 Dec 1997 10:04:34 -0800 (PST) From: Ned Freed Subject: Re: mailing list last call: pop and smtp sasl In-reply-to: "Your message dated Tue, 02 Dec 1997 09:55:32 -0800 (PST)" To: Chris Newman Cc: John Myers , ietf-sasl@imc.org Message-id: <01IQP18YE9C09TCP0Q@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <348333CD.B2690872@netscape.com> Sender: owner-ietf-sasl@imc.org Precedence: bulk > > > I disagree. I'm of the opinion that use of IMAP for the offline access > > > mode (as opposed to online or disconnected) is actively harmful and > > > usually results in lost email. > > This statement assumes the "download and delete" model of offline access > > that was pervasive about three years ago. Since then, the UIDL command > > has become widely deployed and the "leave mail on server" option of > > various POP clients has become fairly popular. > The "leave mail on server" POP model is a poor man's disconnected mode > access, IMHO. IMAP should be used instead for that purpose. > However, I maintain that POP is the preferred protocol for the "download > and delete" model and I don't forsee that usage model disappearing. It's > far to useful for home users. Building "download and delete" IMAP clients > is misleading to users and increases the risk of lost email. Perhaps an anecdote will help support this point. UIDL is easy to support with a VMS MAIL backing store so we implemented it fairly early. But after implementing it we almost immediately started receiving some pushback on it -- it makes "leave mail on server" operation a lot more attractive, and a significant number of our customers didn't want that. So we added options to disable UIDL. Since then we've continued to receive pushback on practically every feature of POP3 that can be used to facilitate the "leave mail on server" approach. We've implemented increasingly draconian settings to make this operational mode less and less attractive over time. Simply put, there are a lot of sites that want to operate dropboxes, not message stores. And while it is theoretically possible to configure IMAP4 to operate in a dropbox mode, I doubt very much that a server implementing such a mode would successfully interoperate with any extant IMAP client. Now, one can argue that the cost of hardware is now so low that the cost of running a full message store isn't all that great even for large numbers of users, and besides you can charge more for the increased functionality a message store provides over a simple dropbox. (And of course this can then be countered by saying that the real increase cost is in management of the store, not in equipment and software, and that even if the management costs are somehow held down the fact remains that significant numbers of people aren't willing to pay more for message store functionality when a dropbox does all they want.) But all this market analysis is irrelevant, really. The bottom line is that a significant number of people want to continue to use POP3 as a dropbox protocol rather than try to turn IMAP4 into one and they are going to enhance POP3 in various ways (mostly security related) rather than move to IMAP4. And the only choice we have is whether or not we impose some sort of structure on POP3 or cope with any additional enhancements that like it or not are going to happen on a case by case basis. > > To benefit from attention to POP in any area, one has to replace both > > the server and client base. Since your argument for paying attention to > > POP is that the installed base is entrenched, this is slightly > > contradictory. To keep from having to replace one's infrastructure, one > > will have to replace one's infrastructure. > There is a difference between upgrading the POP server/client and > switching to a different usage model. The former will be done by a good > system manager periodically anyway, while the latter requires a testing, > training and transition period. Our experience has been that the training involved is considerable, the costs are often quite high, and the transition is often quite painful. > Here are the choices: > (1) The capability command notes the presence of AUTH, but does not list > mechanisms. Legacy clients which use AUTH to list mechanisms won't have > to change. Newer clients will have an extra round trip on every > connection and may break against servers which disconnect after two failed > commands. Legacy servers will have to add the capability command if it > becomes popular. > Pros: low impact on legacy AUTH list clients > Cons: bad architecture for new clients > dissimilar to other SASL profiles > works poorly with TLS > (2) The capability command lists mechanisms as does the AUTH command. > Legacy clients don't have to change. Newer clients will work better. > Legacy servers will have to add the capability command if it becomes > popular. > Pros: low impact on legacy AUTH list clients. > Cons: duplicate paths for same function creates possibility for silly > state. > (3) The capability command lists mechanisms, no requirement that AUTH > command does. Legacy clients will have to be upgraded to interoperate > with newer servers. Newer clients will work better. Legacy servers will > have to add the capability command if it becomes popular. > Pros: clean architecture > Cons: upgrade to clients is a pain > may have to deal with unpleasent server variations > (4) Just use AUTH command. > Pros: No impact on legacy AUTH list clients/servers. > Cons: clients have to be manually configured > bad architecture for new clients (probing) > dissimilar to other SASL profiles > works poorly with TLS > I'd say that (2) or (3) is best, although I could live with (1). What do > others think? I prefer (2). I could live with (3) or (1). The TLS issues make (4) more than a little problematic for me. Ned From owner-ietf-sasl Tue Dec 2 11:46:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA23343 for ietf-sasl-bks; Tue, 2 Dec 1997 11:46:15 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA23339 for ; Tue, 2 Dec 1997 11:46:12 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id LAA05523; Tue, 2 Dec 1997 11:47:02 -0800 (PST) Message-Id: In-Reply-To: References: <348333CD.B2690872@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Tue, 2 Dec 1997 11:40:22 -0800 To: Chris Newman From: Randall Gellens Subject: Re: mailing list last call: pop and smtp sasl Cc: John Myers , ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 9:55 AM -0800 12/2/97, Chris Newman wrote: >I'd say that (2) or (3) is best, although I could live with (1). What do >others think? I agree. I'd prefer (3), that is, that servers MAY respond to an empty AUTH with a list of supported mechanisms, with a note in the spec about existing code that does so. However, I'd also settle for (2). From owner-ietf-sasl Tue Dec 2 11:43:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA23301 for ietf-sasl-bks; Tue, 2 Dec 1997 11:43:25 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA23294 for ; Tue, 2 Dec 1997 11:43:20 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id LAA15420; Tue, 2 Dec 1997 11:41:48 -0800 (PST) Message-Id: <3.0.5.32.19971202114440.007c1e60@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Dec 1997 11:44:40 -0800 To: Ned Freed , Chris Newman From: Paul Hoffman / IMC Subject: Re: mailing list last call: pop and smtp sasl Cc: John Myers , ietf-sasl@imc.org In-Reply-To: <01IQP18YE9C09TCP0Q@INNOSOFT.COM> References: <"Your message dated Tue, 02 Dec 1997 09:55:32 -0800 (PST)" <348333CD.B2690872@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 10:04 AM 12/2/97 -0800, Ned Freed wrote: >But all this market analysis is irrelevant, really. The bottom line is that a >significant number of people want to continue to use POP3 as a dropbox protocol >rather than try to turn IMAP4 into one and they are going to enhance POP3 in >various ways (mostly security related) rather than move to IMAP4. And the only >choice we have is whether or not we impose some sort of structure on POP3 or >cope with any additional enhancements that like it or not are going to happen >on a case by case basis. I have to agree with Ned here. In our talks with the press about IMAP adoption, we find that few companies that want to do dropbox want to go to IMAP, even with all the clients that are out there now. It seems prudent to continue to improve the POP standard until there is a groundswell of movement to IMAP. That hasn't happened yet. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Tue Dec 2 12:47:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA24378 for ietf-sasl-bks; Tue, 2 Dec 1997 12:47:10 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA24374 for ; Tue, 2 Dec 1997 12:47:06 -0800 (PST) Received: from eleanor.innosoft.com ("port 38859"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQP68AZXRI9TCRBV@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 2 Dec 1997 12:47:39 PST Date: Tue, 02 Dec 1997 12:49:55 -0800 (PST) From: Chris Newman Subject: SASL Registration list online 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 The SASL mechanism registration list is now online at: with a link from the IANA web page. The list currently includes: KERBEROS_V4, GSSAPI, SKEY, EXTERNAL, CRAM-MD5 and ANONYMOUS. Other mechanisms in the works: PLAIN in draft-newman-sasl-plaintrans-04.txt, which I'm aiming for publication as an informational RFC. I don't expect the mechanism to change at this point. SCRAM-MD5 in draft-newman-sasl-scram-01.txt which will undergo one more incompatible revision and some security review before hopefully going standards track. It's intended to fix some flaws in CRAM-MD5 with roughly equivalent complexity level and marginally better security. Should be good for thin clients with no backwards compatibility requirement. I'm also working on a PASS-DSS-SHA-3DES-1 mechanism which will use the same security model that the mandatory to implement mechanisms in draft-ietf-secsh-transport-03.txt use, except just for encrypting the client password. Should be viable for situations with a backwards compatiblity requirement. I may have a pre-release spec to circulate to interested parties at the IETF. I don't know if anyone is working on an OTP/RFC 2243 mechanism or SRP/B-SPEKE style mechanisms. - Chris From owner-ietf-sasl Wed Dec 3 10:43:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA04719 for ietf-sasl-bks; Wed, 3 Dec 1997 10:43:54 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA04714 for ; Wed, 3 Dec 1997 10:43:46 -0800 (PST) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id KAA04622; Wed, 3 Dec 1997 10:42:52 -0800 (PST) X-Sender: llundbla@mrw.qualcomm.com Message-Id: In-Reply-To: References: <348333CD.B2690872@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Dec 1997 10:27:51 -0800 To: Randall Gellens From: Laurence Lundblade Subject: Re: mailing list last call: pop and smtp sasl Cc: Chris Newman , John Myers , ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 11:40 AM -0800 12/2/97, Randall Gellens wrote: >At 9:55 AM -0800 12/2/97, Chris Newman wrote: > >>I'd say that (2) or (3) is best, although I could live with (1). What do >>others think? > >I agree. I'd prefer (3), that is, that servers MAY respond to an empty >AUTH with a list of supported mechanisms, with a note in the spec about >existing code that does so. However, I'd also settle for (2). Same for me - prefer (3), could live with (2). I'd prefer to have to implement only one way to discover the AUTH options. If two are acceptable some servers will do one, others may do the other, and the client really has to start probing to do the best job. Probing makes the implementations significantly messier. LL From owner-ietf-sasl Wed Dec 3 12:00:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06302 for ietf-sasl-bks; Wed, 3 Dec 1997 12:00:59 -0800 (PST) Received: from strange.qualcomm.com (strange.qualcomm.com [129.46.2.27]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06297 for ; Wed, 3 Dec 1997 12:00:47 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by strange.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id LAA14946; Wed, 3 Dec 1997 11:58:01 -0800 (PST) Message-Id: In-Reply-To: References: <348333CD.B2690872@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Wed, 3 Dec 1997 11:38:42 -0800 To: Laurence Lundblade From: Randall Gellens Subject: Re: mailing list last call: pop and smtp sasl Cc: Chris Newman , John Myers , ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 10:27 AM -0800 12/3/97, Laurence Lundblade wrote: >Same for me - prefer (3), could live with (2). I'd prefer to have to >implement only one way to discover the AUTH options. If two are acceptable >some servers will do one, others may do the other, and the client really >has to start probing to do the best job. Probing makes the implementations >significantly messier. Maybe the spec should say a server MUST support the capabilities response which lists the SASL mechanisms, and SHOULD respond to an empty AUTH by listing the mechanisms, and that clients SHOULD (MUST?) use the capabilities command to discover mechanisms. That way legacy code still works, but new code uses the capabilities command. A new client only has to implement one method, but a new server should support both. From owner-ietf-sasl Wed Dec 3 14:16:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08895 for ietf-sasl-bks; Wed, 3 Dec 1997 14:16:02 -0800 (PST) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA08891 for ; Wed, 3 Dec 1997 14:15:58 -0800 (PST) Received: by DOGGATE with Internet Mail Service (5.5.1960.3) id ; Wed, 3 Dec 1997 14:20:37 -0800 Message-ID: <2FBF98FC7852CF11912A00000000000106DD519F@DINO> From: "Larry Osterman (Exchange)" To: "'Chris Newman'" , John Myers Cc: ietf-sasl@imc.org Subject: RE: mailing list last call: pop and smtp sasl Date: Wed, 3 Dec 1997 14:20:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-sasl@imc.org Precedence: bulk John asked me to chime in, so... Putting on my "real world" hat, I think that since there's at least one widely deployed client out there that implements AUTH with no arguments (IE 3.0, IE 4.0), and since Exchange 5.0 and 5.5 have shipped with support for AUTH with no arguments, and since the POP3 SASL draft requires this (which is what we coded to), I'd rather see #2, instead of #3. The reality is that we're going to be seeing IE3.0 (and 4.0) clients out there for a long time now (probably several years), and there's no real way of upgrading those clients to a new mechanism. >From a purists standpoint, I agree with the discussion that that #3 is better, but... Personally I think 1 is a BAD IDEA(tm) - #1 requires that a client that supports CAPA make 2 round trips before authenticating to the server, there's no point in forcing them to make the additional round trip. If the writing on the wall goes towards 3, I would much rather see Randy's comment be adopted (SASL= is a MUST, AUTH is a SHOULD). That has the advantage of allowing legacy clients to continue to function against even new servers, but new clients will be able to transition to the new mechanism, and hopefully the AUTH mechanism will go softly into that good night.... I almost wish that Chris had proposed this 2 years ago when Mike Gahrns and I asked John to add AUTH to solve the AUTH TWINKIE (gag) issue, I'd have jumped on this in a heartbeat as a solution, but that's water under the dam.... Larry Osterman Via Exchange Osmium on Larryo-Laptop.dns.microsoft.com with NT 4.0. Since these are not all released products, please notify the sender of any difficulties. From owner-ietf-sasl Wed Dec 3 15:16:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA09746 for ietf-sasl-bks; Wed, 3 Dec 1997 15:16:50 -0800 (PST) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA09742 for ; Wed, 3 Dec 1997 15:16:47 -0800 (PST) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id PAA05346 for <@starfish.mcom.com:ietf-sasl@imc.org>; Wed, 3 Dec 1997 15:18:00 -0800 (PST) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA22397 for ; Wed, 3 Dec 1997 15:20:18 -0800 To: ietf-sasl@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-sasl Subject: Re: mailing list last call: pop and smtp sasl Date: Wed, 03 Dec 1997 15:17:59 -0800 Organization: Netscape Communications Corporation Lines: 12 Message-ID: <3485E8A7.D690013F@netscape.com> References: <348333CD.B2690872@netscape.com> NNTP-Posting-Host: 205.217.229.208 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.03 [en] (WinNT; U) Sender: owner-ietf-sasl@imc.org Precedence: bulk Let me propose (5): Reserve a SASL mechanism name STARTTLS. There is no such mechanism, but the name is used in POP3 AUTH-no-args to indicate the presence of the STARTTLS extension. Clients which want to use the capability command do so after authentication. Pros: returned capabilities are protected by any session integrity protection layer of TLS or SASL. most compatible with installed base Cons: Ugly From owner-ietf-sasl Wed Dec 3 19:36:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA13467 for ietf-sasl-bks; Wed, 3 Dec 1997 19:36:11 -0800 (PST) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.200.141]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA13463 for ; Wed, 3 Dec 1997 19:36:07 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id TAA28042; Wed, 3 Dec 1997 19:37:05 -0800 (PST) Message-Id: In-Reply-To: <3485E8A7.D690013F@netscape.com> References: <348333CD.B2690872@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Wed, 3 Dec 1997 19:32:32 -0800 To: John Gardiner Myers From: Randall Gellens Subject: Re: mailing list last call: pop and smtp sasl Cc: ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 3:17 PM -0800 12/3/97, John Gardiner Myers wrote: >Let me propose (5): > >Reserve a SASL mechanism name STARTTLS. There is no such mechanism, but >the name is used in POP3 AUTH-no-args to indicate the presence of the >STARTTLS extension. Clients which want to use the capability command do >so after authentication. > >Pros: returned capabilities are protected by any session integrity >protection layer of TLS or SASL. >most compatible with installed base > >Cons: Ugly There's an extra round-trip over (2) or (3), plus it turns AUTH-CRLF into a super-capabilities command. From owner-ietf-sasl Thu Dec 4 10:52:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA02546 for ietf-sasl-bks; Thu, 4 Dec 1997 10:52:38 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA02541 for ; Thu, 4 Dec 1997 10:52:29 -0800 (PST) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id KAA27826 for ; Thu, 4 Dec 1997 10:52:52 -0800 (PST) X-Sender: llundbla@mrw.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: <3485E8A7.D690013F@netscape.com> <348333CD.B2690872@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Dec 1997 09:45:53 -0800 To: ietf-sasl@imc.org From: Laurence Lundblade Subject: Re: mailing list last call: pop and smtp sasl Sender: owner-ietf-sasl@imc.org Precedence: bulk So do we have consensus.....? The POP extension/capabilities returns something like this: +OK USER APOP SASL=CRAM-MD5 KERBEROS_V4 SCRAM-MD5 PLAIN STLS . indicating it support 1939 User/Pass 1939 APOP 2195 CRAM-MD5 Kerberos version 4 Scram The SASL plain mechanism from the Newman draft The STLS command from the Newman draft Also a server *MAY* return the following list in response to AUTH +OK CRAM-MD5 KERBEROS_V4 SCRAM-MD5 PLAINTRANS . If the AUTH command with no arguments is not supported, it returns -ERR AUTH command must give SASL mechanism I expect nearly all servers will respond to AUTH with no args, because it's very easy to implement and provides good backwards compatibility. I expect all future clients will always use the extension/CAPA command in preference to AUTH with no arguments because it is more efficient and easier to implement. LL From owner-ietf-sasl Thu Dec 4 14:25:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA00534 for ietf-sasl-bks; Thu, 4 Dec 1997 14:25:37 -0800 (PST) Received: from aun.uninett.no (aun.uninett.no [129.241.1.99]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA00527 for ; Thu, 4 Dec 1997 14:25:31 -0800 (PST) Received: from dale.uninett.no (actually dale.htalvestrand.priv.no) by aun.uninett.no with SMTP (PP); Thu, 4 Dec 1997 23:27:07 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id XAA31065; Thu, 4 Dec 1997 23:27:05 +0100 From: Harald.T.Alvestrand@uninett.no To: Chris Newman cc: John Myers , ietf-sasl@imc.org Subject: POP extension mechanism (Re: mailing list last call: pop and..) In-reply-to: Your message of "Mon, 24 Nov 1997 11:47:58 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31062.881274423.1@dale.uninett.no> Date: Thu, 04 Dec 1997 23:27:04 +0100 Message-ID: <31063.881274424@dale.uninett.no> Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris, note that the number of strange (and I mean REALLY strange) proposals for POP extensions I've seen over the last 3 years is quite significant. POP's lack of an extension mechanism has been an advantage in keeping the hounds at bay and POP reasonably simple. A POP extension tool will be a strange attractor, precisely because POP is so widely deployed. IF we do this: Can I draft you as part of the POP Extensions Review Team, with License To Kill (and expect a fairly high kill percentage)? One of the first ones to be resurrected will probably be the one that wants to gzip the mail (AND bag it) before fetching it.... (apart from that, I tend to agree that extensions are better than variations......) Harald A From owner-ietf-sasl Thu Dec 4 16:23:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA02340 for ietf-sasl-bks; Thu, 4 Dec 1997 16:23:48 -0800 (PST) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.200.141]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA02336 for ; Thu, 4 Dec 1997 16:23:44 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id QAA04192; Thu, 4 Dec 1997 16:24:18 -0800 (PST) Message-Id: In-Reply-To: <31063.881274424@dale.uninett.no> References: Your message of "Mon, 24 Nov 1997 11:47:58 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Thu, 4 Dec 1997 16:19:12 -0800 To: Harald.T.Alvestrand@uninett.no From: Randall Gellens Subject: Re: POP extension mechanism (Re: mailing list last call: pop and..) Cc: Chris Newman , John Myers , ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 11:27 PM +0100 12/4/97, Harald.T.Alvestrand@uninett.no wrote: >POP's lack of an extension mechanism has been an advantage in >keeping the hounds at bay and POP reasonably simple. >A POP extension tool will be a strange attractor, precisely >because POP is so widely deployed. I'd suggest that the extensions mechanism specify that extensions MUST be published in standards-track or IESG-approved experimental RFCs. From owner-ietf-sasl Thu Dec 4 16:28:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA02409 for ietf-sasl-bks; Thu, 4 Dec 1997 16:28:02 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA02401 for ; Thu, 4 Dec 1997 16:27:58 -0800 (PST) Received: from eleanor.innosoft.com ("port 44052"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQS6J24OWW9TCV2L@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 4 Dec 1997 16:28:42 PST Date: Thu, 04 Dec 1997 16:30:58 -0800 (PST) From: Chris Newman Subject: Re: POP extension mechanism (Re: mailing list last call: pop and..) In-reply-to: <31063.881274424@dale.uninett.no> To: Harald.T.Alvestrand@uninett.no Cc: John Myers , 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 Thu, 4 Dec 1997 Harald.T.Alvestrand@uninett.no wrote: > POP's lack of an extension mechanism has been an advantage in > keeping the hounds at bay and POP reasonably simple. > A POP extension tool will be a strange attractor, precisely > because POP is so widely deployed. I think the current draft addresses this point by stating more than once that extending POP is usually not desirable. > IF we do this: > Can I draft you as part of the POP Extensions Review Team, > with License To Kill (and expect a fairly high kill percentage)? Fair enough. > One of the first ones to be resurrected will probably be the one > that wants to gzip the mail (AND bag it) before fetching it.... Easy enough to kill -- it's only useful for non-compressing slow modems which are almost non-existent these days. Besides, compression belongs in the same layer that supplies encryption -- doing it twice is counter-productive. - Chris From owner-ietf-sasl Thu Dec 4 16:36:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA02544 for ietf-sasl-bks; Thu, 4 Dec 1997 16:36:32 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA02540 for ; Thu, 4 Dec 1997 16:36:28 -0800 (PST) Received: from eleanor.innosoft.com ("port 44053"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQS6TM23QO9TCV2L@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 4 Dec 1997 16:37:12 PST Date: Thu, 04 Dec 1997 16:39:29 -0800 (PST) From: Chris Newman Subject: Re: POP extension mechanism (Re: mailing list last call: pop and..) In-reply-to: To: Randall Gellens Cc: Harald.T.Alvestrand@uninett.no, John Myers , 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 Thu, 4 Dec 1997, Randall Gellens wrote: > >POP's lack of an extension mechanism has been an advantage in > >keeping the hounds at bay and POP reasonably simple. > >A POP extension tool will be a strange attractor, precisely > >because POP is so widely deployed. > > I'd suggest that the extensions mechanism specify that extensions MUST > be published in standards-track or IESG-approved experimental RFCs. It's pretty close now: Capabilities beginning with the letter "X" are reserved for experimental non-standard extensions and their use is discouraged. All other capabilities MUST be defined in a standards track or IESG approved experimental RFC. I'd be willing to drop that first sentence, but I'm not sure your company would like it, given you support an experimental non-standard (and poorly designed/architected) XTND XMIT command, at least in your client. I left it in with the premise that it's better to have the servers which offer bad experimental non-standard features announce it to the world. - Chris From owner-ietf-sasl Thu Dec 4 17:02:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA02904 for ietf-sasl-bks; Thu, 4 Dec 1997 17:02:57 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA02900 for ; Thu, 4 Dec 1997 17:02:53 -0800 (PST) Received: from eleanor.innosoft.com ("port 44059"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQS7QD320A9TCV2L@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 4 Dec 1997 17:03:36 PST Date: Thu, 04 Dec 1997 17:05:55 -0800 (PST) From: Chris Newman Subject: Re: mailing list last call: pop and smtp sasl In-reply-to: To: Laurence Lundblade Cc: 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 Thu, 4 Dec 1997, Laurence Lundblade wrote: > So do we have consensus.....? At this point I support: Some form of capability command. New clients MAY use AUTH listing only if capability command not present. Servers MUST implement AUTH listing (I can't think of a good reason not to, given backwards compatibility issue). This is easy for servers to implement (the SASL API I'm working on makes it almost trivial). This is fully backwards compatible with old clients, and will attain the one round trip and no probing goal with newer client/server combinations. This also permits the POP AUTH command to move forward in its current state with only the addition of a reference to a future capabilities command. The alternative of turning AUTH with no arguments into a capability command is acceptable to me as long as there is a systematic way to distinguish SASL mechanisms from capability items (e.g., by requring extension items to contain or end with an "=", or have all capabilities occur after a "CAPABILITIES:" item and all SASL mechanisms occur before it). - Chris From owner-ietf-sasl Thu Dec 4 17:42:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA03329 for ietf-sasl-bks; Thu, 4 Dec 1997 17:42:19 -0800 (PST) Received: from happy.qualcomm.com (happy.qualcomm.com [129.46.50.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA03325 for ; Thu, 4 Dec 1997 17:42:13 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by happy.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id RAA07986; Thu, 4 Dec 1997 17:43:02 -0800 (PST) Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Thu, 4 Dec 1997 17:32:17 -0800 To: Chris Newman From: Randall Gellens Subject: Re: POP extension mechanism (Re: mailing list last call: pop and..) Cc: Harald.T.Alvestrand@uninett.no, John Myers , ietf-sasl@imc.org, lgl@qualcomm.com Sender: owner-ietf-sasl@imc.org Precedence: bulk At 4:39 PM -0800 12/4/97, Chris Newman wrote: >I'd be willing to drop that first sentence, but I'm not sure your company >would like it, given you support an experimental non-standard (and poorly >designed/architected) XTND XMIT command, at least in your client. I left >it in with the premise that it's better to have the servers which offer >bad experimental non-standard features announce it to the world. I forgot about XTND XMIT. The funny thing is, I hear that some ISPs now require it in lieu of SMTP authentication and a submission protocol. Let's keep the text as you have written it. From owner-ietf-sasl Thu Dec 4 18:46:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA04184 for ietf-sasl-bks; Thu, 4 Dec 1997 18:46:37 -0800 (PST) Received: from fantasia.qualcomm.com (fantasia.qualcomm.com [129.46.52.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA04179 for ; Thu, 4 Dec 1997 18:46:33 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by fantasia.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id SAA29680; Thu, 4 Dec 1997 18:47:18 -0800 (PST) Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Thu, 4 Dec 1997 18:28:16 -0800 To: Chris Newman From: Randall Gellens Subject: Re: mailing list last call: pop and smtp sasl Cc: Laurence Lundblade , ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 5:05 PM -0800 12/4/97, Chris Newman wrote: >At this point I support: > >Some form of capability command. New clients MAY use AUTH listing only if >capability command not present. Servers MUST implement AUTH listing (I >can't think of a good reason not to, given backwards compatibility issue). I agree with this. >The alternative of turning AUTH with no arguments into a capability >command is acceptable to me as long as there is a systematic way to >distinguish SASL mechanisms from capability items (e.g., by requring >extension items to contain or end with an "=", or have all capabilities >occur after a "CAPABILITIES:" item and all SASL mechanisms occur before >it). I really don't like this. From owner-ietf-sasl Thu Dec 4 18:49:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA04218 for ietf-sasl-bks; Thu, 4 Dec 1997 18:49:26 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA04214 for ; Thu, 4 Dec 1997 18:49:22 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id SAA21845 for ; Thu, 4 Dec 1997 18:48:09 -0800 (PST) Message-Id: <3.0.5.32.19971204185104.007b5d70@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Dec 1997 18:51:04 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Re: POP extension mechanism (Re: mailing list last call: pop and..) In-Reply-To: References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 05:32 PM 12/4/97 -0800, Randall Gellens wrote: >I forgot about XTND XMIT. The funny thing is, I hear that some ISPs >now require it in lieu of SMTP authentication and a submission protocol. That's true. It's being touted as The Solution To Spam. Of course, only if you use Eudora and qpopper... >Let's keep the text as you have written it. Er, and Randy or Laurence: let's have an Internet Draft for XMIT. I'll create a mailing list for it (or other POP extensions) if you'd like. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Fri Dec 5 07:30:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA15737 for ietf-sasl-bks; Fri, 5 Dec 1997 07:30:25 -0800 (PST) Received: from MUSICM.MCGILL.CA (MusicM.McGill.CA [132.206.120.4]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA15732 for ; Fri, 5 Dec 1997 07:30:21 -0800 (PST) Received: from MUSICM.MCGILL.CA by MUSICM.MCGILL.CA (IBM VM SMTP V2R2) with BSMTP id 5763; Fri, 05 Dec 97 10:32:50 LCL Message-Id: <05DEC97.11390486.0022.MUSIC@MUSICM.MCGILL.CA> Date: Fri, 05 Dec 1997 10:32:48 EST From: Earl Lindberg To: Subject: Re[2]: POP extension mechanism (Re: mailing list last call: popand..) X-Mailer: MUSIC/SP V5.1.0 In-Reply-To: In reply to your message of Thu, 04 Dec 1997 21:51:04 EST Sender: owner-ietf-sasl@imc.org Precedence: bulk >At 05:32 PM 12/4/97 -0800, Randall Gellens wrote: >>I forgot about XTND XMIT. The funny thing is, I hear that some ISPs >>now require it in lieu of SMTP authentication and a submission protocol. > >That's true. It's being touted as The Solution To Spam. Of course, only if >you use Eudora and qpopper... We also have a written-from-spec POP3 server that implements XTND XMIT. Clients use Eudora. Said server runs on MUSIC/SP, a mainframe operating system running under the IBM VM/SP product. > >>Let's keep the text as you have written it. > >Er, and Randy or Laurence: let's have an Internet Draft for XMIT. I'll >create a mailing list for it (or other POP extensions) if you'd like. > > >--Paul Hoffman, Director >--Internet Mail Consortium Earl Lindberg-MUSIC Product Group From owner-ietf-sasl Fri Dec 5 07:52:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA16096 for ietf-sasl-bks; Fri, 5 Dec 1997 07:52:14 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA16090 for ; Fri, 5 Dec 1997 07:52:10 -0800 (PST) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id HAA25924; Fri, 5 Dec 1997 07:52:21 -0800 (PST) X-Sender: llundbla@mrw.qualcomm.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Dec 1997 07:46:14 -0800 To: Chris Newman From: Laurence Lundblade Subject: Re: mailing list last call: pop and smtp sasl Cc: ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 5:05 PM -0800 12/4/97, Chris Newman wrote: >On Thu, 4 Dec 1997, Laurence Lundblade wrote: >> So do we have consensus.....? > >At this point I support: > >Some form of capability command. New clients MAY use AUTH listing only if >capability command not present. Servers MUST implement AUTH listing (I >can't think of a good reason not to, given backwards compatibility issue). I'm happy requiring servers to support AUTH listing. >This also permits the POP AUTH command to move forward in its current >state with only the addition of a reference to a future capabilities >command. I'd actaully prefer we pull back on it and rewrite it to use the POP extensions mechanism. That will make the POP standards significantly cleaner in the long run. As things are going now, there are going to be over half a dozen drafts/standards that an implementor will have to read to get the POP authorization stuff working well. I would hope we could reduce that to two or three, perhaps just the POP extention standard, and the POP authentication standard. (It would still be a SASL mechanism, but SASL is more directed at designers or AUTH mechanisms, than implementors, so they probably don't need it to write code). >The alternative of turning AUTH with no arguments into a capability >command is acceptable to me as long as there is a systematic way to >distinguish SASL mechanisms from capability items (e.g., by requring >extension items to contain or end with an "=", or have all capabilities >occur after a "CAPABILITIES:" item and all SASL mechanisms occur before >it). You don't really want to allow overloading AUTH with such wonderful extensions as removing QP encoding, translation to Russian, grammar checking and gziping before downloading...? :-) I would prefer to keep the AUTH verb separate from the extensions verb. On the XTND XMIT, I don't know it's all that critical, and would probably rather see SASL based SMTP and Randy's submit draft go forward. The salient characteristics are authorization and batch submission. LL From owner-ietf-sasl Fri Dec 5 12:03:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA20459 for ietf-sasl-bks; Fri, 5 Dec 1997 12:03:30 -0800 (PST) Received: from happy.qualcomm.com (happy.qualcomm.com [129.46.50.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA20455 for ; Fri, 5 Dec 1997 12:03:22 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by happy.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA20465; Fri, 5 Dec 1997 12:04:08 -0800 (PST) Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro for Macintosh Date: Fri, 5 Dec 1997 12:01:11 -0800 To: Laurence Lundblade From: Randall Gellens Subject: Re: mailing list last call: pop and smtp sasl Cc: Chris Newman , ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk At 7:46 AM -0800 12/5/97, Laurence Lundblade wrote: >On the XTND XMIT, I don't know it's all that critical, and would probably >rather see SASL based SMTP and Randy's submit draft go forward. The salient >characteristics are authorization and batch submission. I agree. Authenticated SMTP and the submission protocol are the way to go, not XTND XMIT. From owner-ietf-sasl Mon Dec 29 16:10:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA16416 for ietf-sasl-bks; Mon, 29 Dec 1997 16:10:41 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA16412 for ; Mon, 29 Dec 1997 16:10:36 -0800 (PST) Received: from elwood.innosoft.com ("port 33522"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IRR3A9EOZ69TD96A@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 29 Dec 1997 16:13:49 PST Date: Mon, 29 Dec 1997 16:15:59 -0800 (PST) From: Chris Newman Subject: re: Expiring Passwords In-reply-to: To: John Haxby Cc: IMAP Discusson List , ietf-sasl@imc.org Reply-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 [Moving discussion from IMAP list to SASL list] On Wed, 24 Dec 1997, John Haxby wrote: > However, you mention service-specific passwords. This is what I have > difficulty with. In particular, with IMAP servers, I'm having trouble with > the concept that an IMAP server must use some central authentication to > allow password changing. Other services, whether Internet or not, allow > password changing on a service-by-service basis. Most Internet protocols do not include a password changing service. However, I do see an interesting architectural decision underneath this that would seem to merit discussion: Should "password change" be part of the authentication service provided by every protocol (e.g., a SASL-like beast which is slotted into every protocol) or should it be an independent service which can change the user's one password (99% case) or service-specific password (1% case)? There are good reasons for both architectures. A SASL-enabled protocol will already have the machinary to access an authentication database at least to the extent of verifying the password. Including the password change service as part of that service will simplify the issue of locating the correct backend authentication database. On the flip side, password changing is a very sensitive operation which needs a higher level of mandatory security than most protocols. Splitting it into a separate protocol will allow that protocol to be much more carefully analyzed for correctness and thus reduce the security risk to sites where it is deployed. But with the 1% (or less, but not ignorable) case of service-specific passwords, this becomes a rather ugly architecture. I'm inclined towards a separate password change protocol as I tend to prefer modular protocol design and prefer to cater to the 99% case. The set of cookie-cutter features that app protocols need is growing: * protocol structure and data types * basic commands: logout, noop * error messages: basic errors, detailed errors * I18n: UTF-8, language control for error messages, etc. * SASL * Referrals [* STARTTLS command] [* command/response interleaving] I'd prefer to avoid growing this list more than necessary as it can have a multiplicative effect on Internet complexity. But I will admit that this decision is not a slam-dunk decision. What do other people think? - Chris From owner-ietf-sasl Mon Dec 29 16:41:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA16660 for ietf-sasl-bks; Mon, 29 Dec 1997 16:41:12 -0800 (PST) Received: from om.proper.com (om.proper.com [165.227.249.115]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA16656; Mon, 29 Dec 1997 16:41:07 -0800 (PST) Message-Id: <3.0.5.32.19971229164407.008567b0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Dec 1997 16:44:07 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: re: Expiring Passwords Cc: IMAP Discusson List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk I would tend to want to define this in SASL rather than outside for the simple reason that it would be easier for someone who had already implemented SASL to implement this extension. On the political front, it would help nudge (shove?) client and server implementors who haven't to implement SASL for this one feature, if for no other reason. And, if we like Chris' list of "what an application protocol should have", SASL is already there, so we don't have to add "password changing" to that list, which should be available to any password-based protocol. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Mon Dec 29 17:02:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA16801 for ietf-sasl-bks; Mon, 29 Dec 1997 17:02:34 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA16797 for ; Mon, 29 Dec 1997 17:02:28 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id UAA31218; Mon, 29 Dec 1997 20:05:44 -0500 Received: from n3bl.watson.ibm.com (lig32-225-9-14.us.lig-dial.ibm.com [32.225.9.14]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id UAA15192; Mon, 29 Dec 1997 20:05:35 -0500 From: Barry Leiba To: IMAP Discusson List , ietf-sasl Subject: Re: Expiring Passwords In-Reply-To: <3.0.5.32.19971229164407.008567b0@mail.imc.org> Message-ID: Date: Mon, 29 Dec 1997 20:06:08 -0500 (Eastern Standard Time) X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk On Mon, 29 Dec 97 16:44:07 -0800 Paul Hoffman / IMC wrote: > I would tend to want to define this in SASL rather than outside for the > simple reason that it would be easier for someone who had already Absolutely - in SASL. To my mind, changing the authentication credentials is *part* of the authentication process; it's not peripheral to it. A mechanism for making that change should be part of the authentication layer. As I study my company's own Lotus Notes product, which has a very strong authentication system, I see the weakness in its not providing a way for the user to change her own authentication certificates. Barry Leiba, Multimedia Messaging (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba From owner-ietf-sasl Mon Dec 29 17:35:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA17097 for ietf-sasl-bks; Mon, 29 Dec 1997 17:35:52 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA17092 for ; Mon, 29 Dec 1997 17:35:48 -0800 (PST) Received: (qmail 22298 invoked from network); 30 Dec 1997 01:33:26 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 30 Dec 1997 01:33:26 -0000 From: Mark Wahl To: ietf-sasl@imc.org Subject: Re: Expiring Passwords Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Dec 1997 19:33:26 -0600 Message-ID: <22296.883445606@folder.critical-angle.com> Sender: owner-ietf-sasl@imc.org Precedence: bulk Paul Hoffman writes: > I would tend to want to define this in SASL rather than outside for the > simple reason that it would be easier for someone who had already > implemented SASL to implement this extension. On the political front, it I do not think that password changing should be part of SASL. Some applications which make use of the SASL framework may not have a need for password changing, as most of the SASL mechanisms currently registered with IANA are not based on password negotiation. Besides a user changing the password for their own account, there are a number of similar services which may found to be requirements in particular deployments or applications. These would include: - changing credentials which are not passwords - changing information about a user other than credentials (e.g. name) - allowing the support staff to change a user's credentials - users creating accounts for themselves (registration) It is likely there will be devices which support SASL but do not contain any user account information internally. Instead, they will rely on an external server which they access through LDAP, RADIUS, NIS or other appropriate protocol to support their authentication and access control decisions. Rather than require any device to be able to tunnel password changing and other account services from their client to their authentication service, I think there would be cleaner architecture if the client would ask the device for a "referral" to the set-of-URLs of the authentication service used by the device. If there is a protocol defined for password changing, then the server could return URLs of this form. In the case of a server which maintains its own credentials database, then the referral for a password change protocol could be to the same host as the server itself. This would require an additional connection setup and negotiation phase, but would clearly separate the use of authentication in application protocols and the maintenance of authentication credentials, which could be more independent of the application protocols. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-sasl Mon Dec 29 17:47:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA17164 for ietf-sasl-bks; Mon, 29 Dec 1997 17:47:21 -0800 (PST) Received: from junior.apk.net (root@junior.apk.net [207.54.158.15]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA17160 for ; Mon, 29 Dec 1997 17:47:18 -0800 (PST) Received: from daddy (pm2-1.mentor.apk.net [207.54.151.10]) by junior.apk.net (8.8.8/8.8.8) with SMTP id UAA02013; Mon, 29 Dec 1997 20:50:30 -0500 (EST) Message-Id: <3.0.1.32.19971229210451.00e17438@pop.apk.net> X-Sender: rjd@pop.apk.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 29 Dec 1997 21:04:51 -0500 To: ietf-sasl@imc.org From: "Robert J. DuWors" Subject: re: Expiring Passwords Cc: John Haxby , IMAP Discusson List , ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk I see two distinct issues: 1) Should one-password-fit-all across all authentication mechanisms and across all services? [which is actually two closely related questions]. It is argued this is the 99% case [following the single-sign-on philosophy as applied to passwords]. 2) Should password changing be in-band or out-of-band in regards to the authentication protocol [and perhaps altogether on the Internet]? Ironically, many "application protocols" such as chat services [even financial services] use [insecure] e-mail as an out-of band protocol for this purpose. :-) 1) seems 99% plausible as operationally desirable [although more stringent policy must be possible if not particularly easy]. Also of concern is the relative risk a stored verifier belonging to one mechanism/service revealing another mechanisms's verifier which uses the same root pass[word/phrase], e.g. APOP versus CRAM-MD5 versus SCRAM-MD5 -if this is not an issue then storing plain text passwords is ok [maybe that is the answer; after all, if they steal your authentication database, of course your authentication scheme is blown]. 2) raises serious design tradeoffs between architectural cleanliness and [enterprise/user community specific] security policy. Perhaps the compromise answer has to be that a pass[word/phrase] changing protocol MAY be bundled with SASL authentication much like the EXTERNAL/TLS hooks but SHOULD not be required. --Rob DuWors At 04:15 PM 12/29/97 -0800, Chris Newman wrote: >[Moving discussion from IMAP list to SASL list] > >On Wed, 24 Dec 1997, John Haxby wrote: >> However, you mention service-specific passwords. This is what I have >> difficulty with. In particular, with IMAP servers, I'm having trouble with >> the concept that an IMAP server must use some central authentication to >> allow password changing. Other services, whether Internet or not, allow >> password changing on a service-by-service basis. > >Most Internet protocols do not include a password changing service. >However, I do see an interesting architectural decision underneath this >that would seem to merit discussion: > >Should "password change" be part of the authentication service provided by >every protocol (e.g., a SASL-like beast which is slotted into every >protocol) or should it be an independent service which can change the >user's one password (99% case) or service-specific password (1% case)? -------------------------------------------------------------- Robert J. DuWors tel:+1.440.255.2869 Connected Systems Group 7638 Aster Drive, Mentor, Ohio 44060 From owner-ietf-sasl Tue Dec 30 00:33:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA19919 for ietf-sasl-bks; Tue, 30 Dec 1997 00:33:20 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA19915 for ; Tue, 30 Dec 1997 00:33:17 -0800 (PST) Received: from elwood.innosoft.com ("port 33577"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IRRKTBHMXK9TD96A@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 30 Dec 1997 00:35:33 PST Date: Tue, 30 Dec 1997 00:37:43 -0800 (PST) From: Chris Newman Subject: re: Expiring Passwords In-reply-to: <3.0.5.32.19971229164407.008567b0@mail.imc.org> 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 The choices on the table as I see them: * A password-change SASL mechanism Pros: fits easily into existing SASL-profiled protocols handles 1% service-specific password case elegantly Doesn't require new "service" Neutral: Would make SASL implementation model significantly more complex but might also make it more attractive to vendors Cons: Every service would have to support proxied password changing in a large installation Wouldn't support bulk administrative changing of user passwords Adds complexity to core service * A credential/password-change framework that could be added to protocols independent of SASL Pros: handles 1% service-specific password case elegantly Doesn't require new "service" Cons: Every service would have to support proxied password changing in a large installation Wouldn't support bulk administrative changing of user passwords Adds complexity to many protocols * A separate password change protocol Pros: Doesn't require proxying password change in large installations Doesn't require adding security sensitive service to complex protocols (making the service less secure and protocol more complex) Allows functional (or even vendor) separation of services Can support bulk administrative changing of user credentials Cons: handles 1% service-specific password case poorly unless Mark's referral proposal is adopted hard for some vendors to create/market a new "service" From owner-ietf-sasl Tue Dec 30 12:48:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA28852 for ietf-sasl-bks; Tue, 30 Dec 1997 12:48:35 -0800 (PST) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA28848 for ; Tue, 30 Dec 1997 12:48:31 -0800 (PST) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id PAA01400 for ietf-sasl@imc.org; Tue, 30 Dec 1997 15:51:53 -0500 (EST) Received: via switchmail; Tue, 30 Dec 1997 15:51:53 -0500 (EST) Received: from loiosh.andrew.cmu.edu via qmail ID ; Tue, 30 Dec 1997 15:50:10 -0500 (EST) Received: from loiosh.andrew.cmu.edu via qmail ID ; Tue, 30 Dec 1997 15:50:07 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Tue, 30 Dec 1997 15:49:57 -0500 (EST) Message-ID: <0oeJtp200WC71QxDs0@andrew.cmu.edu> Date: Tue, 30 Dec 1997 15:49:57 -0500 (EST) From: Rob Earhart To: ietf-sasl@imc.org Subject: Re: Expiring Passwords In-Reply-To: References: X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Not Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris Newman writes: > The set of cookie-cutter features that app protocols need is growing: > * protocol structure and data types > * basic commands: logout, noop > * error messages: basic errors, detailed errors > * I18n: UTF-8, language control for error messages, etc. > * SASL > * Referrals > [* STARTTLS command] > [* command/response interleaving] > I'd prefer to avoid growing this list more than necessary as it > can have a multiplicative effect on Internet complexity. That's actually why I proposed draft-earhart-ap-spec-00.txt last summer; it had the potential to wrap up a lot of the infrastructure that application protocols need. Think it'd be worth updating and resubmitting? (As a bonus, password-change could easily be treated as an extension to AP, so it could either coexist with another protocol on the same connection or be an independant service, as desired.) )Rob From owner-ietf-sasl Tue Dec 30 13:39:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA29371 for ietf-sasl-bks; Tue, 30 Dec 1997 13:39:12 -0800 (PST) Received: from strange.qualcomm.com (strange.qualcomm.com [129.46.2.27]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA29367 for ; Tue, 30 Dec 1997 13:39:08 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by strange.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id NAA01337; Tue, 30 Dec 1997 13:41:27 -0800 (PST) Message-Id: In-Reply-To: References: <3.0.5.32.19971229164407.008567b0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro 4.0 for Macintosh Date: Tue, 30 Dec 1997 13:40:50 -0800 To: Chris Newman From: Randall Gellens Subject: re: Expiring Passwords Cc: ietf-sasl@imc.org Sender: owner-ietf-sasl@imc.org Precedence: bulk I've been thinking about this, and now feel that a separate password change protocol is needed. Password changing, unlike authentication, is really not an intrinsic part of most application protocols; it is a separate service, with its own needs. Of course, applications are free to offer password changing as part of their UI. What we need, as Chris noted, is a replacement for poppassd. This isn't to say that a SASL mechanism or set of mechanisms might not be a good choice. -- Randall Gellens || Opinions are personal; facts are suspect; randy@qualcomm.com || I speak for myself alone Excellent day to have a rotten day. From owner-ietf-sasl Wed Dec 31 21:49:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA16062 for ietf-sasl-bks; Wed, 31 Dec 1997 21:49:21 -0800 (PST) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA16058 for ; Wed, 31 Dec 1997 21:49:16 -0800 (PST) Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id AAA13114 for ; Thu, 1 Jan 1998 00:52:43 -0500 (EST) Date: Thu, 1 Jan 1998 00:52:42 -0500 (EST) From: Rob Earhart To: ietf-sasl@imc.org Subject: re: Expiring Passwords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2147343199-1774835377-883633962=:19086" Sender: owner-ietf-sasl@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2147343199-1774835377-883633962=:19086 Content-Type: TEXT/PLAIN; charset=US-ASCII I think that a seperate password changing protocol is the way to go. The only serious con is that it doesn't elegantly handle service-specific passwords for existing protocols; I'm tempted to just say that existing applications which want this will need to be do something special anyway (either a small code rewrite, or an auxiliary client, as password changing doesn't really seem like something that fits into a plugin SASL architecture), so why not make it a seperate protocol at the same time? Just for fun, I threw together and attached a definition of a password change protocol. I didn't include a "service" parameter; it seems like one could use a seperate password-change service for each service-specific password, and trying to include it made things a bit complicated. Any comments? )Rob ---2147343199-1774835377-883633962=:19086 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-earhart-pcp-spec-00.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBFYXJoYXJ0DQpJbnRl cm5ldCBEcmFmdDogUENQICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDYXJuZWdpZSBNZWxsb24NCkRvY3VtZW50OiBkcmFmdC1lYXJo YXJ0LXBjcC1zcGVjLTAwLnR4dCAgICAgICAgICAgICAgICAgICAgIEphbnVh cnkgMTk5OA0KRXhwaXJlcyBKdWx5IDE5OTgNCg0KDQogICAgICAgICAgICAg ICAgICAgICAgICBQYXNzd29yZCBDaGFuZ2UgUHJvdG9jb2wNCg0KU3RhdHVz IG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVy bmV0LURyYWZ0LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nDQogICBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9y Y2UgKElFVEYpLCBpdHMgYXJlYXMsDQogICBhbmQgaXRzIHdvcmtpbmcgZ3Jv dXBzLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu DQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4DQogICBtb250aHMuICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIN CiAgIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIG5vdCBhcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzDQogICBhcyByZWZlcmVuY2Ug bWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsg aW4NCiAgIHByb2dyZXNzIi4NCg0KICAgVG8gbGVhcm4gdGhlIGN1cnJlbnQg c3RhdHVzIG9mIGFueSBJbnRlcm5ldC1EcmFmdCwgcGxlYXNlIGNoZWNrIHRo ZQ0KICAgMWlkLWFic3RyYWN0cy50eHQgbGlzdGluZyBjb250YWluZWQgaW4g dGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAgIERpcmVjdG9yaWVzIG9u IGZ0cC5pcy5jby56YSAoQWZyaWNhKSwgZnRwLm5vcmR1Lm5ldCAoRXVyb3Bl KSwNCiAgIG11bm5hcmkub3ouYXUgKFBhY2lmaWMgUmltKSwgZHMuaW50ZXJu aWMubmV0IChVUyBFYXN0IENvYXN0KSwgb3INCiAgIGZ0cC5pc2kuZWR1IChV UyBXZXN0IENvYXN0KS4NCg0KICAgVGhpcyBkb2N1bWVudCBzdWdnZXN0cyBh IHByb3Bvc2VkIHByb3RvY29sIGZvciB0aGUgSW50ZXJuZXQNCiAgIGNvbW11 bml0eSwgYW5kIHJlcXVlc3RzIGRpc2N1c3Npb24gYW5kIHN1Z2dlc3Rpb25z IGZvciBpbXByb3ZlbWVudHMuDQogICBEaXN0cmlidXRpb24gb2YgdGhpcyBk cmFmdCBpcyB1bmxpbWl0ZWQuDQoNCiAgIFRoZSBwcm90b2NvbCBkaXNjdXNz ZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBleHBlcmltZW50YWwgYW5kIHN1Ympl Y3QNCiAgIHRvIGNoYW5nZS4gIFBlcnNvbnMgcGxhbm5pbmcgb24gZWl0aGVy IGltcGxlbWVudGluZyBvciB1c2luZyB0aGlzDQogICBwcm90b2NvbCBhcmUg U1RST05HTFkgVVJHRUQgdG8gZ2V0IGluIHRvdWNoIHdpdGggdGhlIGF1dGhv ciBiZWZvcmUNCiAgIGVtYmFya2luZyBvbiBzdWNoIGEgcHJvamVjdC4NCg0K DQpBYnN0cmFjdA0KDQogICBTaGFyZWQgc2VjcmV0cyBhcmUgYSBjb21tb24g cGFydCBvZiBtYW55IGF1dGhlbnRpY2F0aW9uIHN5c3RlbXMuICBJdA0KICAg aXMgd2lkZWx5IGJlbGlldmVkIHRoYXQgb2NjYXNpb25hbGx5IGNoYW5naW5n IHRoZSBzaGFyZWQgc2VjcmV0DQogICBpbmNyZWFzZXMgc3lzdGVtIHNlY3Vy aXR5LiAgUENQIHByb3ZpZGVzIGEgZ2VuZXJhbCBtZWNoYW5pc20gYnkgd2hp Y2gNCiAgIGNsaWVudHMgbWF5IGNoYW5nZSBhIHNoYXJlZCBzZWNyZXQgYXNz b2NpYXRlZCB3aXRoIGFuIGF1dGhlbnRpY2F0aW9uDQogICBtZWNoYW5pc20u DQoNCg0KDQoNCg0KDQoNCkVhcmhhcnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0K DA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAgUGFzc3dvcmQgQ2hhbmdlIFBy b3RvY29sICAgICAgICAgICAgSmFudWFyeSAxOTk4DQoNCg0KMS4gICBJbnRy b2R1Y3Rpb24NCg0KICAgUENQIGlzIHVzZWQgdG8gY2hhbmdlIGEgdXNlcidz IHBhc3N3b3JkIGZvciBhIGdpdmVuIGF1dGhlbnRpY2F0aW9uDQogICBtZWNo YW5pc20gaW4gYSBzZWN1cmUgZmFzaGlvbiwgYXMgZWl0aGVyIGFuIGluZGVw ZW5kZW50IHByb3RvY29sIG9yDQogICBjb21wb3NlZCB3aXRoIGFub3RoZXIg cHJvdG9jb2wgdXNpbmcgQVAuDQoNCiAgIFBDUCB1c2VzIHRoZSBBUCBmcmFt ZXdvcmsgZm9yIHN5bnRheCBhbmQgYmFzaWMgcHJvdG9jb2wgc2VtYW50aWNz LCBhcw0KICAgdGhpcyBpcyBzaW1wbGVyLCBjbGVhbmVyLCBhbmQgY2xlYXJl ciB0aGFuIHdyaXRpbmcgdGhlIHByb3RvY29sIGZyb20NCiAgIHNjcmF0Y2gu DQoNCg0KMi4gICBDb252ZW50aW9ucyBVc2VkIGluIHRoaXMgRG9jdW1lbnQN Cg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJT SE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9O QUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRl ZCBhcyBkZXNjcmliZWQgaW4gIktleSB3b3JkcyBmb3IgdXNlIGluDQogICBS RkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscyIgW0tFWVdPUkRT XS4NCg0KDQozLiAgIFByb3RvY29sIE92ZXJ2aWV3DQoNCiAgIEF0IHNlc3Np b24gc3RhcnR1cCwgdGhlIHNlcnZlciBpbmRpY2F0ZXMgaXRzIHdpbGxpbmdu ZXNzIHRvIG9mZmVyDQogICBwYXNzd29yZC1jaGFuZ2luZyBjYXBhYmlsaXR5 IGJ5IHNlbmRpbmcgdGhlIFBDUCBjYXBhYmlsaXR5IGluIHRoZQ0KICAgaW5p dGlhbCBBUCBncmVldGluZy4NCg0KICAgSWYgYSBTQVNMIFtTQVNMXSBzZWN1 cml0eSBtZWNoYW5pc20gaXMgbmVnb3RpYXRlZCB2aWEgdGhlDQogICBBVVRI RU5USUNBVEUgd2hpY2ggaXMgb2YgYWNjZXB0YWJsZSBzdHJlbmd0aCB0byB0 aGUgc2VydmVyLCBhbmQNCiAgIHNlc3Npb24gaW50ZWdyaXR5IGFuZCBwcml2 YWN5IGhhdmUgYmVlbiBlbmFibGVkLCB0aGUgc2VydmVyIE1VU1Qgc2VuZA0K ICAgYW4gdW50YWdnZWQgUENQIHJlc3BvbnNlIGp1c3QgYmVmb3JlIHRoZSBj b21wbGV0aW9uIG9mIHRoZQ0KICAgQVVUSEVOVElDQVRFIGNvbW1hbmQsIGlu ZGljYXRpbmcgaXRzIHdpbGxpbmduZXNzIHRvIHBlcmZvcm0gcGFzc3dvcmQN CiAgIGNoYW5nZSBvcGVyYXRpb25zLg0KDQogICBPbmNlIHRoZSBzZXNzaW9u IGlzIGluIHRoZSBhdXRoZW50aWNhdGVkIHN0YXRlLCB0aGUgY2xpZW50IE1B WQ0KICAgcHJvY2VlZCB0byBpc3N1ZSBDSEFOR0VQVyBjb21tYW5kcyB0byBz ZXQgdXNlcnMnIHBhc3N3b3JkcywgYXQgYW55DQogICB0aW1lIHVudGlsIHRo ZSBzZXNzaW9uIGlzIGNsb3NlZC4gIENsaWVudHMgYXJlIHJlc3BvbnNpYmxl IGZvcg0KICAgaW5kZXBlbmRlbnRseSBkZWNpZGluZyB3aGV0aGVyIG9yIG5v dCB0aGUgbmVnb3RpYXRlZCBtZWNoYW5pc20sDQogICBpbnRlZ3JpdHksIGFu ZCBwcml2YWN5IGFyZSBzdWl0YWJsZSwgYnV0IE1VU1QgTk9UIGlzc3VlIENI QU5HRVBXDQogICBjb21tYW5kcyB1bmxlc3MgdGhlIHNlcnZlciBoYXMgaXNz dWVkIGFuIHVudGFnZ2VkIFBDUCByZXNwb25zZS4NCg0KDQo0LiAgIExpbmsg TGV2ZWwNCg0KICAgVGhlIEFQIGZyYW1ld29yayBhc3N1bWVzIGEgcmVsaWFi bGUgZGF0YSBzdHJlYW0gc3VjaCBhcyBwcm92aWRlZCBieQ0KICAgVENQLiAg V2hlbiBUQ1AgaXMgdXNlZCBhbmQgUENQIGlzIG5vdCB1c2VkIHdpdGggYW5v dGhlciBzZXJ2aWNlLCBhDQogICBQQ1Agc2VydmVyIGxpc3RlbnMgb24gcG9y dCA8eHh4Pi4NCg0KDQo1LiAgIENhcGFiaWxpdGllcywgQ29tbWFuZHMsIGFu ZCBSZXNwb25zZXMNCg0KDQoNCkVhcmhhcnQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAgUGFzc3dvcmQgQ2hhbmdl IFByb3RvY29sICAgICAgICAgICAgSmFudWFyeSAxOTk4DQoNCg0KICAgUENQ IGRlZmluZXMgYSBzaW5nbGUgY2FwYWJpbGl0eSwgIlBDUCIgKHdoaWNoIE1V U1QgYmUgc2VudCBieSBhDQogICBzZXJ2ZXIgaW1wbGVtZW50aW5nIFBDUCBp biB0aGUgaW5pdGlhbCBBUCBzZXNzaW9uIGdyZWV0aW5nKSwgdGhlIFBDUA0K ICAgdW50YWdnZWQgcmVzcG9uc2UgKHRvIGJlIHNlbnQgYXMgcGFydCBvZiB0 aGUgQVVUSEVOVElDQVRFIGNvbW1hbmQpLA0KICAgYW5kIHRoZSBDSEFOR0VQ VyBjb21tYW5kLCB3aGljaCBpcyB1c2VkIGZvciBjaGFuZ2luZyB0aGUgdXNl cidzDQogICBwYXNzd29yZC4NCg0KDQo1LjEuIFBDUCBSZXNwb25zZQ0KDQog ICBEYXRhOiAgICAgICBub25lDQoNCiAgICAgIFRoZSBQQ1AgdW50YWdnZWQg cmVzcG9uc2UgaXMgc2VudCBpbiByZXNwb25zZSB0byBhIHN1Y2Nlc3NmdWwg QVANCiAgICAgIEFVVEhFTlRJQ0FURSBjb21tYW5kLCBiZWZvcmUgdGhlIEFV VEhFTlRJQ0FURSBjb21wbGV0ZXMsIHRvDQogICAgICBpbmRpY2F0ZSB0aGF0 IHRoZSBzZXJ2ZXIgYWNjZXB0cyB0aGUgbmVnb3RpYXRlZCBhdXRoZW50aWNh dGlvbg0KICAgICAgbWVjaGFuaXNtIGFuZCBzZXNzaW9uIGludGVncml0eSBh bmQgcHJpdmFjeSBsYXllcnMgZm9yIHRoZSBwdXJwb3NlDQogICAgICBvZiBw YXNzd29yZCBjaGFuZ2UuDQoNCiAgICAgIFNlcnZlcnMgYWR2ZXJ0aXNpbmcg dGhlIFBDUCBjYXBhYmlsaXR5IE1VU1Qgc2VuZCBhIFBDUCB1bnRhZ2dlZA0K ICAgICAgcmVzcG9uc2UgdG8gYW4gYXV0aGVudGljYXRlIGNvbW1hbmQgaWYg YW5kIG9ubHkgaWYgdGhlIG5lZ290aWF0ZWQNCiAgICAgIG1lY2hhbmlzbSBh bmQgc2Vzc2lvbiBzZWN1cml0eSBhbmQgcHJpdmFjeSBsYXllcnMgYXJlIHN1 aXRhYmxlIHRvDQogICAgICB0aGUgc2VydmVyIGZvciBzZW5kaW5nIHBhc3N3 b3Jkcy4NCg0KICAgICAgQ2xpZW50cyBNVVNUIE5PVCBhdHRlbXB0IHRvIGNo YW5nZSBhIHVzZXIncyBwYXNzd29yZCB1bmxlc3MgdGhleQ0KICAgICAgaGF2 ZSByZWNlaXZlZCBhIFBDUCB1bnRhZ2dlZCByZXNwb25zZSBmcm9tIHRoZSBz ZXJ2ZXIuDQoNCg0KNS4yLiBDSEFOR0VQVyBDb21tYW5kDQoNCiAgIEFyZ3Vt ZW50czogIHVzZXJpZCBvciBOSUwNCiAgICAgICAgICAgICAgIGF1dGgtdHlw ZQ0KICAgICAgICAgICAgICAgbmV3LXBhc3N3b3JkDQoNCiAgIERhdGE6ICAg ICAgIG5vbmUNCg0KICAgUmVzdWx0OiAgICAgT0sgLSBwYXNzd29yZCBjaGFu Z2VkDQogICAgICAgICAgICAgICBOTyAtIHBhc3N3b3JkIHVuYWNjZXB0YWJs ZSBvciBpbnN1ZmZpY2llbnQgYXV0aG9yaXphdGlvbg0KICAgICAgICAgICAg ICAgQkFEIC0gY29tbWFuZCB1bmtub3duLCBhcmd1bWVudHMgaW52YWxpZCwg bmVnb3RpYXRlZA0KICAgICAgICAgICAgICAgc2VjdXJpdHkgbGF5ZXIgdW5h Y2NlcHRhYmxlIGZvciBwYXNzd29yZCBjaGFuZ2VzDQogICAgICAgICAgICAg ICAoYWNjb21wYW5pZWQgYnkgYW4gQVVUSC1UT08tV0VBSyByZXNwb25zZSBj b2RlKSwgb3INCiAgICAgICAgICAgICAgIGVuY3J5cHRpb24gaXMgbm90IGVu YWJsZWQgZm9yIHRoZSBjb25uZWN0aW9uIChhY2NvbXBhbmllZA0KICAgICAg ICAgICAgICAgYnkgYW4gRU5DUllQVC1ORUVERUQgcmVzcG9uc2UgY29kZSkN Cg0KICAgICAgVGhlIENIQU5HRVBXIGNvbW1hbmQgY2hhbmdlcyB0aGUgcGFz c3dvcmQgZm9yIHRoZSBpbmRpY2F0ZWQgdXNlcg0KICAgICAgKG9yLCBpZiBO SUwsIGZvciB0aGUgdXNlcmlkIHVzZWQgaW4gYXV0aGVudGljYXRpb24pIG9u IHRoZQ0KICAgICAgc2VydmVyJ3Mgc3lzdGVtIGZvciBhIGdpdmVuIGF1dGhl bnRpY2F0aW9uIG1lY2hhbmlzbSB0byB0aGUgbmV3DQogICAgICBwYXNzd29y ZC4gIFRoaXMgTUFZIGNoYW5nZSB0aGUgdXNlcidzIHBhc3N3b3JkIGZvciBv dGhlcg0KICAgICAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBvbiB0aGUg c2FtZSBzeXN0ZW0gd2hpY2ggdXNlIHRoZSBzYW1lDQogICAgICBkYXRhYmFz ZS4NCg0KDQoNCkVhcmhhcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50 ZXJuZXQgRFJBRlQgICAgICAgICAgUGFzc3dvcmQgQ2hhbmdlIFByb3RvY29s ICAgICAgICAgICAgSmFudWFyeSAxOTk4DQoNCg0KICAgICAgVGhlIHNlcnZl ciBNQVkgcGVyZm9ybSBhcmJpdHJhcnkgdmFsaWRhdGlvbiBvZiB0aGUgcGFz c3dvcmQ7IGlmDQogICAgICB0aGUgcGFzc3dvcmQgaXMgdW5hY2NlcHRhYmxl IGZvciBhbnkgcmVhc29uLCB0aGUgc2VydmVyIE1BWQ0KICAgICAgcmVzcG9u ZCB3aXRoIGEgTk8uDQoNCiAgICAgIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qg ZmVlbCB0aGUgbmVnb3RpYXRlZCBzZWN1cml0eSBsYXllciBpcw0KICAgICAg c3Ryb25nIGVub3VnaCBmb3IgcGFzc3dvcmQgY2hhbmdlcywgaXQgTUFZIHJl amVjdCB0aGUgcmVxdWVzdCB3aXRoDQogICAgICBhbiBBVVRILVRPTy1XRUFL IHJlc3BvbnNlIGNvZGUgKHRoaXMgbWF5IG9jY3VyIHdoZW4gUENQIGlzIGNv dXBsZWQNCiAgICAgIHdpdGggYW5vdGhlciBzZXJ2aWNlIG9uIHRoZSBzYW1l IGNvbm5lY3Rpb24pLiAgSWYgdGhlIHNlY3VyaXR5DQogICAgICBsYXllciBp cyBzdHJvbmcgZW5vdWdoIGJ1dCBzZXNzaW9uIGludGVncml0eSBvciBwcml2 YWN5IGlzDQogICAgICBkaXNhYmxlZCwgaXQgTVVTVCByZWplY3QgdGhlIHJl cXVlc3Qgd2l0aCBhbiBFTkNSWVBULU5FRURFRA0KICAgICAgcmVzcG9uc2Ug Y29kZS4NCg0KICAgICAgICAgTm90ZSB0aGF0IGJvdGggb2YgdGhlc2UgYXJl IGNvbnNpZGVyZWQgQkFEIGNvbmRpdGlvbnM7IHRoZXkNCiAgICAgICAgIHNo b3VsZCBuZXZlciBhcmlzZSBpbiBwcmFjdGljZS4gIEEgc2VydmVyIE1VU1Qg Tk9UIHNlbmQgYSBQQ1ANCiAgICAgICAgIHVudGFnZ2VkIHJlc3BvbnNlIHVu bGVzcyB0aGUgc2VjdXJpdHkgbGF5ZXIgaXMgY29uc2lkZXJlZA0KICAgICAg ICAgc3Ryb25nIGFuZCBzZXNzaW9uIGludGVncml0eSBhbmQgcHJpdmFjeSBh cmUgZW5hYmxlZCwgYW5kIGENCiAgICAgICAgIGNsaWVudCBNVVNUIE5PVCBh dHRlbXB0IHRvIGNoYW5nZSBhIHBhc3N3b3JkIHVubGVzcyBpdCBoYXMNCiAg ICAgICAgIHJlY2VpdmVkIGEgUENQIHVudGFnZ2VkIHJlc3BvbnNlLCBzbyBp ZiBlaXRoZXIgb2YgdGhlIGFib3ZlIHR3bw0KICAgICAgICAgY29uZGl0aW9u cyBpcyBub3QgbWV0LCBzb21ldGhpbmcgaGFzIGdvbmUgZHJhc3RpY2FsbHkg d3JvbmcuDQoNCiAgICAgIFdoZW4gUENQIGlzIGJlaW5nIHVzZWQgYnkgaXRz ZWxmLCB0aGUgc2VydmVyIE1VU1QgTk9UIGFsbG93IGFueQ0KICAgICAgYXV0 aGVudGljYXRpb24gbWVjaGFuaXNtcyBvciBpbnRlZ3JpdHkvcHJpdmFjeSBs YXllcnMgdG8gYmUNCiAgICAgIG5lZ290aWF0ZWQgd2hpY2ggYXJlIG5vdCBh Y2NlcHRhYmxlIGZvciBwYXNzd29yZCB0cmFuc21pc3Npb24uDQoNCiAgICAg IFRoZSBDSEFOR0VQVyBjb21tYW5kIE1VU1Qgb25seSBiZSB1c2VkIGluIHRo ZSBhdXRoZW50aWNhdGVkIHN0YXRlLA0KICAgICAgYW5kIE1VU1QgT05MWSBC RSBVU0VEIElGIEEgUENQIFVOVEFHR0VEIFJFU1BPTlNFIEhBUyBCRUVODQog ICAgICBSRUNFSVZFRC4NCg0KICAgICAgVGhlIHN0cmluZyBzZW50IGFzIHRo ZSBuZXcgcGFzc3dvcmQgaXMgdGhlIHVzZXIncyBwbGFpbnRleHQNCiAgICAg IHBhc3N3b3JkLg0KDQogICAgICAgICBOb3RlOiBUaGlzIGNvdWxkLCBpbnN0 ZWFkLCBiZSBkZWZpbmVkIG9uIGEgcGVyLW1lY2hhbmlzbSBiYXNpcywNCiAg ICAgICAgIGFzIHNvbWV0aGluZyBhcHByb3ByaWF0ZSB0byB0aGUgbWVjaGFu aXNtOyBmb3IgaW5zdGFuY2UsIHdpdGgNCiAgICAgICAgIENSQU0tTUQ1LCB0 aGUgMTYtb2N0ZXQgc2hhcmVkIHNlY3JldCB0aGF0IHRoZSBzZXJ2ZXIgaGFz IHRvDQogICAgICAgICBzdG9yZSBjb3VsZCBiZSBzZW50IGFjcm9zcywgaW5z dGVhZCBvZiB0aGUgdXNlcidzIHBsYWludGV4dA0KICAgICAgICAgcGFzc3dv cmQuICBJIHRoaW5rIGl0J3MgYmV0dGVyIHRvIHNlbmQgdGhlIHBhc3N3b3Jk IGl0c2VsZg0KICAgICAgICAgYWNyb3NzLCB0aG91Z2gsIGFzIHNvbWUgc2l0 ZSBhZG1pbmlzdHJhdG9ycyB3aWxsIHdhbnQgdG8NCiAgICAgICAgIHZhbGlk YXRlIHRoZWlyIHVzZXJzJyBwYXNzd29yZCBjaG9pY2VzLCBhbmQgZG9pbmcg c28gd2l0aG91dA0KICAgICAgICAgdGhlIHBsYWludGV4dCBwYXNzd29yZCBp cyBkaWZmaWN1bHQuDQoNCiAgICAgIEV4YW1wbGU6ICBDOiBhMDAxIENIQU5H RVBXIE5JTCAiQ1JBTS1NRDUiICJibHVyZHlibG9vcCINCiAgICAgICAgICAg ICAgICBTOiBhMDAxIE9LICJQYXNzd29yZCBjaGFuZ2VkIg0KDQoNCjYuICAg Rm9ybWFsIFN5bnRheA0KDQogICBUaGUgZm9sbG93aW5nIHN5bnRheCBzcGVj aWZpY2F0aW9uIHVzZXMgdGhlIGF1Z21lbnRlZCBCYWNrdXMtTmF1cg0KICAg Rm9ybSAoQk5GKSBub3RhdGlvbiBhcyBzcGVjaWZpZWQgaW4gW0FCTkZdLiAg VGhpcyB1c2VzIHRoZSBBQk5GIGNvcmUNCg0KDQoNCkVhcmhhcnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAgUGFz c3dvcmQgQ2hhbmdlIFByb3RvY29sICAgICAgICAgICAgSmFudWFyeSAxOTk4 DQoNCg0KICAgcnVsZXMgYXMgc3BlY2lmaWVkIGluIEFwcGVuZGl4IEEgb2Yg dGhlIEFCTkYgc3BlY2lmaWNhdGlvbiBbQUJORl0sDQogICBhbmQgYXVnbWVu dHMgdGhlIGNvcmUgQVAgZ3JhbW1hciBzcGVjaWZpZWQgaW4gW0FQXS4NCg0K ICAgRXhjZXB0IGFzIG5vdGVkIG90aGVyd2lzZSwgYWxsIGFscGhhYmV0aWMg Y2hhcmFjdGVycyBhcmUgY2FzZS0NCiAgIGluc2Vuc2l0aXZlLiAgVGhlIHVz ZSBvZiB1cHBlciBvciBsb3dlciBjYXNlIGNoYXJhY3RlcnMgdG8gZGVmaW5l DQogICB0b2tlbiBzdHJpbmdzIGlzIGZvciBlZGl0b3JpYWwgY2xhcml0eSBv bmx5LiAgSW1wbGVtZW50YXRpb25zIE1VU1QNCiAgIGFjY2VwdCB0aGVzZSBz dHJpbmdzIGluIGEgY2FzZS1pbnNlbnNpdGl2ZSBmYXNoaW9uLg0KDQoNCiAg IGNhcGFiaWxpdHkgICAgICA9LyAiUENQIg0KDQogICBjb21tYW5kICAgICAg ICAgPS8gIkNIQU5HRVBXIiBTUCB1c2VyaWQgU1AgYXV0aC10eXBlIFNQIG5l dy1wYXNzd29yZA0KDQogICBuZXctcGFzc3dvcmQgICAgPSBzdHJpbmcNCg0K ICAgc3RhdHVzLXJlc3BvbnNlID0vICJQQ1AiIHJlc3AtYm9keQ0KICAgICAg ICAgICAgICAgICAgICAgIDsgbXVzdCBiZSB1bnRhZ2dlZA0KDQogICB1c2Vy aWQgICAgICAgICAgPSBzdHJpbmcgLyBOSUwNCg0KDQoNCjcuICAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgU2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgYXJlIGRpc2N1c3NlZCB0aHJvdWdob3V0IHRoaXMgbWVtby4NCg0KICAg Q2hhbmdpbmcgYSB1c2VyJ3MgcGFzc3dvcmQgaXMgYSB2ZXJ5IGRlbGljYXRl IG9wZXJhdGlvbi4gIFNlcnZlcnMgYW5kDQogICBjbGllbnRzIE1VU1QgaW5z aXN0IG9uIGFwcHJvcHJpYXRlIGF1dGhlbnRpY2F0aW9uLCBzZXNzaW9uIGlu dGVncml0eQ0KICAgYW5kIHByaXZhY3kgZm9yIHBhc3N3b3JkIGNoYW5nZXMu DQoNCiAgIEluIHBhcnRpY3VsYXI6DQoNCiAgICAgIENsaWVudHMgTVVTVCBO T1Qgc2VuZCBhIHVzZXIncyBwYXNzd29yZCBpbiB0aGUgY2xlYXIuDQoNCiAg ICAgIENsaWVudHMgTVVTVCBOT1QgYXR0ZW1wdCB0byBjaGFuZ2UgYSB1c2Vy J3MgcGFzc3dvcmQgdW5sZXNzIHRoZQ0KICAgICAgUENQIHVudGFnZ2VkIHJl c3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkICh0aGlzIGlzIGludGVuZGVkIHRv DQogICAgICBwcmV2ZW50IGFuIG9sZCBjbGllbnQgZnJvbSBhdHRlbXB0aW5n IHRvIHVzZSBhIG1lY2hhbmlzbSB0aGF0IHRoZQ0KICAgICAgc2VydmVyIGtu b3dzIGlzIHdlYWspLg0KDQogICAgICBTZXJ2ZXJzIE1VU1QgTk9UIHNlbmQg dGhlIFBDUCB1bnRhZ2dlZCByZXNwb25zZSB1bmxlc3MgdGhleSBhcmUNCiAg ICAgIHdpbGxpbmcgdG8gZW50cnVzdCB0aGVpciB1c2VyJ3MgcGFzc3dvcmRz IHRvIHRoZSBuZWdvdGlhdGVkDQogICAgICBhdXRoZW50aWNhdGlvbiwgaW50 ZWdyaXR5LCBhbmQgcHJpdmFjeSBtZWNoYW5pc21zLg0KDQogICAgICBDbGll bnRzIGFuZCBzZXJ2ZXJzIE1VU1QgdGFrZSBhY3RpdmUgYXR0YWNrcyBpbnRv IGFjY291bnQsIGFuZCBub3QNCiAgICAgIGFsbG93IHRoZSB1c2Ugb2YgYSB3 ZWFrIHNlY3VyaXR5IG1lY2hhbmlzbSwgb3IgdGhlIGRpc2FibGluZyBvZg0K ICAgICAgc2Vzc2lvbiBpbnRlZ3JpdHkgb3IgcHJpdmFjeSBsYXllcnMgKHRo aXMgaGFzIGJlZW4gc3RhdGVkIG51bWVyb3VzDQogICAgICB0aW1lcywgYnV0 IGlzIGNvbnNpZGVyZWQgd2VsbCB3b3J0aCByZXBlYXRpbmcpLg0KDQoNCg0K DQpFYXJoYXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0IERS QUZUICAgICAgICAgIFBhc3N3b3JkIENoYW5nZSBQcm90b2NvbCAgICAgICAg ICAgIEphbnVhcnkgMTk5OA0KDQoNCjguICAgQ29weXJpZ2h0DQoNCiAgIENv cHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgMTk5OC4gQWxsIFJp Z2h0cyBSZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNs YXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0bw0K ICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQg b24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQNCiAgIG9yIGFzc2lzdCBpbiBp dHMgaW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1 Ymxpc2hlZA0KICAgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBw YXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueQ0KICAga2luZCwgcHJv dmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhp cyBwYXJhZ3JhcGggYXJlDQogICBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3Bp ZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0aGlzDQogICBk b2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5 LCBzdWNoIGFzIGJ5IHJlbW92aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGlj ZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90 aGVyDQogICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVl ZGVkIGZvciB0aGUgcHVycG9zZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5l dCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IN CiAgIGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRh cmRzIHByb2Nlc3MgbXVzdCBiZQ0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVp cmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFu DQogICBFbmdsaXNoLg0KDQogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBn cmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQog ICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNj ZXNzb3JzIG9yIGFzc2lnbnMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9u IGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVU WSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZPUkNF IERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVE LCBJTkNMVURJTkcNCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFO VFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0KICAgSEVSRUlO IFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQg V0FSUkFOVElFUyBPRg0KICAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCjkuICAgUmVmZXJlbmNl cw0KDQogICBbQVBdIEVhcmhhcnQsIFIuLCAiQWNjZXNzIFByb3RvY29sIiwg V29yayBpbiBQcm9ncmVzcy4NCg0KICAgW0FCTkZdIENyb2NrZXIsIEQuLCBh bmQgT3ZlcmVsbCwgUC4sICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAg IFNwZWNpZmljYXRpb25zOiBBQk5GIiwgUkZDIDIyMzQsIE5vdmVtYmVyIDE5 OTcuDQoNCiAgICAgIDx1cmw6ZnRwOi8vZHMuaW50ZXJuaWMubmV0L3JmYy9y ZmMyMjM0LnR4dD4NCg0KICAgW0NSQU0tTUQ1XSBLbGVuc2luLCBKLiwgQ2F0 b2UsIFIuLCBhbmQgS3J1bXZpZWRlLCBQLiwgIklNQVAvUE9QDQogICBBVVRI b3JpemUgRXh0ZW5zaW9uIGZvciBTaW1wbGUgQ2hhbGxlbmdlL1Jlc3BvbnNl IiwgUkZDIDIxOTUsDQogICBTZXB0ZW1iZXIgMTk5Ny4NCg0KICAgICAgPHVy bDpmdHA6Ly9kcy5pbnRlcm5pYy5uZXQvcmZjL3JmYzIxOTUudHh0Pg0KDQog ICBbS0VZV09SRFNdIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2Ug aW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwg QkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KDQoNCg0KDQpFYXJo YXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0IERSQUZUICAg ICAgICAgIFBhc3N3b3JkIENoYW5nZSBQcm90b2NvbCAgICAgICAgICAgIEph bnVhcnkgMTk5OA0KDQoNCiAgICAgIDx1cmw6ZnRwOi8vZHMuaW50ZXJuaWMu bmV0L3JmYy9yZmMyMTE5LnR4dD4NCg0KICAgW1NBU0xdIE15ZXJzLCBKLiwg IlNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNB U0wpIiwNCiAgIFJGQyAyMjIyLCBPY3RvYmVyIDE5OTcuDQoNCiAgICAgIDx1 cmw6ZnRwOi8vZHMuaW50ZXJuaWMubmV0L3JmYy9yZmMyMTE5LnR4dD4NCg0K DQoxMC4gIEF1dGhvcidzIEFkZHJlc3MNCg0KICAgUm9iZXJ0IEguIEVhcmhh cnQNCiAgIENhcm5lZ2llIE1lbGxvbg0KICAgNTAwMCBGb3JiZXMgQXZlLg0K ICAgUGl0dHNidXJnaCBQQSwgMTUyMTMtMzg5MA0KDQogICBFbWFpbDogZWFy aGFydCtAY211LmVkdQ0KDQoNCkV4cGlyZXMgSnVseSAxOTk4DQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KRWFyaGFydCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoM ---2147343199-1774835377-883633962=:19086-- From owner-ietf-sasl Thu Jan 1 16:57:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA23357 for ietf-sasl-bks; Thu, 1 Jan 1998 16:57:28 -0800 (PST) Received: from junior.apk.net (root@junior.apk.net [207.54.158.15]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA23353 for ; Thu, 1 Jan 1998 16:57:23 -0800 (PST) Received: from daddy (pm2-17.mentor.apk.net [207.54.151.26]) by junior.apk.net (8.8.8/8.8.8) with SMTP id UAA07861; Thu, 1 Jan 1998 20:00:43 -0500 (EST) Message-Id: <3.0.1.32.19980101201518.00de1818@pop.apk.net> X-Sender: rjd@pop.apk.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 01 Jan 1998 20:15:18 -0500 To: Rob Earhart From: "Robert J. DuWors" Subject: re: Expiring Passwords Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 12:52 AM 1/1/98 -0500, Rob Earhart wrote: > > > The string sent as the new password is the user's plaintext > password. > > Note: This could, instead, be defined on a per-mechanism basis, > as something appropriate to the mechanism; for instance, with > CRAM-MD5, the 16-octet shared secret that the server has to > store could be sent across, instead of the user's plaintext > password. I think it's better to send the password itself > across, though, as some site administrators will want to > validate their users' password choices, and doing so without > the plaintext password is difficult. > > Example: C: a001 CHANGEPW NIL "CRAM-MD5" "blurdybloop" > S: a001 OK "Password changed" > This could be even worse than USER/PASS over light weight un-encrypted links where SASL has great appeal. OTH, verification of pass phrase constraints by the server is highly desirable. It would seem reasonable that the passing of the passphrase itself should be make subject to a password protection mechanism, e.g. C: CHANGEPW CRAM-MD5 S: C: XOR *This would have to modified CRAM: the authentication-id which is already known need not be resent and the passphrase could be longer than the length of the CRAM proof; it also implicitly reuses the old password one last time as part of the cram response computation. --Rob DuWors -------------------------------------------------------------- Robert J. DuWors tel:+1.440.255.2869 Connected Systems Group 7638 Aster Drive, Mentor, Ohio 44060 From owner-ietf-sasl Mon Jan 5 03:17:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA21638 for ietf-sasl-bks; Mon, 5 Jan 1998 03:17:06 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA21631 for ; Mon, 5 Jan 1998 03:16:58 -0800 (PST) Received: from hpopd.pwd.hp.com (hpopd.pwd.hp.com [15.145.205.59]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id DAA04209; Mon, 5 Jan 1998 03:20:39 -0800 (PST) Received: from localhost by hpopd.pwd.hp.com with SMTP (1.40.112.8/16.2) id AA219629237; Mon, 5 Jan 1998 11:20:37 GMT From: John Haxby X-Openmail-Hops: 1 Date: Mon, 5 Jan 1998 11:20:25 +0000 Message-Id: In-Reply-To: Subject: Re: Expiring Passwords Mime-Version: 1.0 To: leiba@watson.ibm.com Cc: ietf-sasl@imc.org, IMAP@cac.washington.edu Content-Type: text/plain; charset=US-ASCII; name="T.TXT" Content-Disposition: inline; filename="T.TXT" Sender: owner-ietf-sasl@imc.org Precedence: bulk Barry Leiba wrote: > On Mon, 29 Dec 97 16:44:07 -0800 Paul Hoffman / IMC wrote: > > I would tend to want to define this in SASL rather than outside > > for the simple reason that it would be easier for someone who had > > already > > Absolutely - in SASL. To my mind, changing the authentication > credentials is *part* of the authentication process; it's not > peripheral to it. A mechanism for making that change should be part > of the authentication layer. Yup. As we've already seen, if the credential changing mechanism isn't part of the authentication layer then people will develop their own ad hoc solutions in response to customer demand. Sometimes these mechanisms are good and provide good protection for the new credentials. Sometimes the mechanisms are rather weaker than the authentication mechanism and open up unpleasant new loopholes. This is self-evident. What I, personally, would really really like to see is a secure credential changing mechanism that does not use algorithms that are subject to export licensing controls. Everything I've thought of requires use of encryption which automatically makes it subject to export licensing controls, either US or UK ones. -- John Haxby OpenMail R&D From owner-ietf-sasl Mon Jan 5 12:05:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA01194 for ietf-sasl-bks; Mon, 5 Jan 1998 12:05:03 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA01187 for ; Mon, 5 Jan 1998 12:04:59 -0800 (PST) Received: from elwood.innosoft.com ("port 33018"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IS0MQJVNNC9TDVGJ@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 5 Jan 1998 12:07:43 PST Date: Mon, 05 Jan 1998 12:09:50 -0800 (PST) From: Chris Newman Subject: re: Expiring Passwords In-reply-to: <3.0.1.32.19980101201518.00de1818@pop.apk.net> To: "Robert J. DuWors" Cc: 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 Thu, 1 Jan 1998, Robert J. DuWors wrote: > C: XOR I've been thinking about this sort of model for password changing for a while. The problem with this is that hash-function-based encryption algorithms (which this is) have not been carefully analysed and thus aren't trusted by the cryptography community. They also have the same problems with export regulations as better encryption algorithms. If you're going to encrypt the new passphrase you may as well use a safer cryptographic algorithm such as triple-DES. There is some speculation that if the security is restricted to only the old and new passphrase then the binary form of the program would be exportable. The government generally doesn't care about restricting authentication -- it just doesn't want to permit export of programs which can hide data from them. After conversations with John Myers, I actually like the idea of a password change protocol with a mandatory to implement real crypto algorithm. I think it's simpler than a bunch of mechanism specific password change methods. - Chris From owner-ietf-sasl Tue Jan 6 13:47:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA21683 for ietf-sasl-bks; Tue, 6 Jan 1998 13:47:19 -0800 (PST) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA21679 for ; Tue, 6 Jan 1998 13:47:14 -0800 (PST) Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id QAA14149 for ; Tue, 6 Jan 1998 16:51:02 -0500 (EST) Date: Tue, 6 Jan 1998 16:51:03 -0500 (EST) From: Rob Earhart To: ietf-sasl@imc.org Subject: re: Expiring Passwords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2147343199-1678144658-884123463=:26325" Sender: owner-ietf-sasl@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2147343199-1678144658-884123463=:26325 Content-Type: TEXT/PLAIN; charset=US-ASCII After some comments (thanks, Jack!), I've revised the proposal for PCP, and attached a new copy. The biggest change is that it no longer deals with specific mechanisms (CRAM-MD5, Kerberos, etc), and instead does things with services (IMAP, ACAP, all, mail-related, etc...), which I think is probably easier for users to comprehend, and allows for site definitions of service-specific passphrases to be dealt with quite cleanly. I think I'd rather just require that the entire session be encrypted with something strong, rather than trying to use some sort of mechanism-specific thing to transfer the passphrase, which quickly becomes complicated. )Rob ---2147343199-1678144658-884123463=:26325 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-earhart-pcp-spec-00.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBFYXJoYXJ0DQpJbnRl cm5ldCBEcmFmdDogUENQICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDYXJuZWdpZSBNZWxsb24NCkRvY3VtZW50OiBkcmFmdC1lYXJo YXJ0LXBjcC1zcGVjLTAwLnR4dCAgICAgICAgICAgICAgICAgICAgIEphbnVh cnkgMTk5OA0KRXhwaXJlcyBKdWx5IDE5OTgNCg0KDQogICAgICAgICAgICAg ICAgICAgICAgIFBhc3NwaHJhc2UgQ2hhbmdlIFByb3RvY29sDQoNClN0YXR1 cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRl cm5ldC1EcmFmdC4gIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZw0KICAg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZv cmNlIChJRVRGKSwgaXRzIGFyZWFzLA0KICAgYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeA0KICAgbW9udGhzLiAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy DQogICBkb2N1bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBub3QgYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cw0KICAgYXMgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr IGluDQogICBwcm9ncmVzcyIuDQoNCiAgIFRvIGxlYXJuIHRoZSBjdXJyZW50 IHN0YXR1cyBvZiBhbnkgSW50ZXJuZXQtRHJhZnQsIHBsZWFzZSBjaGVjayB0 aGUNCiAgIDFpZC1hYnN0cmFjdHMudHh0IGxpc3RpbmcgY29udGFpbmVkIGlu IHRoZSBJbnRlcm5ldC1EcmFmdHMgU2hhZG93DQogICBEaXJlY3RvcmllcyBv biBmdHAuaXMuY28uemEgKEFmcmljYSksIGZ0cC5ub3JkdS5uZXQgKEV1cm9w ZSksDQogICBtdW5uYXJpLm96LmF1IChQYWNpZmljIFJpbSksIGRzLmludGVy bmljLm5ldCAoVVMgRWFzdCBDb2FzdCksIG9yDQogICBmdHAuaXNpLmVkdSAo VVMgV2VzdCBDb2FzdCkuDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3VnZ2VzdHMg YSBwcm9wb3NlZCBwcm90b2NvbCBmb3IgdGhlIEludGVybmV0DQogICBjb21t dW5pdHksIGFuZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZCBzdWdnZXN0aW9u cyBmb3IgaW1wcm92ZW1lbnRzLg0KICAgRGlzdHJpYnV0aW9uIG9mIHRoaXMg ZHJhZnQgaXMgdW5saW1pdGVkLg0KDQogICBUaGUgcHJvdG9jb2wgZGlzY3Vz c2VkIGluIHRoaXMgZG9jdW1lbnQgaXMgZXhwZXJpbWVudGFsIGFuZCBzdWJq ZWN0DQogICB0byBjaGFuZ2UuICBQZXJzb25zIHBsYW5uaW5nIG9uIGVpdGhl ciBpbXBsZW1lbnRpbmcgb3IgdXNpbmcgdGhpcw0KICAgcHJvdG9jb2wgYXJl IFNUUk9OR0xZIFVSR0VEIHRvIGdldCBpbiB0b3VjaCB3aXRoIHRoZSBhdXRo b3IgYmVmb3JlDQogICBlbWJhcmtpbmcgb24gc3VjaCBhIHByb2plY3QuDQoN Cg0KQWJzdHJhY3QNCg0KICAgUGFzc3BocmFzZXMgYXJlIGEgY29tbW9uIHBh cnQgb2YgbWFueSBhdXRoZW50aWNhdGlvbiBzeXN0ZW1zLiAgSXQgaXMNCiAg IHdpZGVseSBiZWxpZXZlZCB0aGF0IG9jY2FzaW9uYWxseSBjaGFuZ2luZyBv bmUncyBwYXNzcGhyYXNlIGluY3JlYXNlcw0KICAgc3lzdGVtIHNlY3VyaXR5 LiAgUENQIHByb3ZpZGVzIGEgZ2VuZXJhbCBtZWNoYW5pc20gYnkgd2hpY2gg Y2xpZW50cw0KICAgbWF5IGNoYW5nZSB0aGUgcGFzc3BocmFzZSBhc3NvY2lh dGVkIHdpdGggc29tZSBzZXQgb2Ygc2VydmljZXMuDQoNCg0KDQoNCg0KDQoN Cg0KRWFyaGFydCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldCBE UkFGVCAgICAgICAgIFBhc3NwaHJhc2UgQ2hhbmdlIFByb3RvY29sICAgICAg ICAgICBKYW51YXJ5IDE5OTgNCg0KDQoxLiAgIEludHJvZHVjdGlvbg0KDQog ICBQQ1AgaXMgdXNlZCB0byBjaGFuZ2UgYSB1c2VyJ3MgcGFzc3BocmFzZSBm b3Igc29tZSBzZXQgb2Ygc2VydmljZXMgaW4NCiAgIGEgc2VjdXJlIGZhc2hp b24sIGFzIGVpdGhlciBhbiBpbmRlcGVuZGVudCBwcm90b2NvbCBvciBjb21w b3NlZCB3aXRoDQogICBhbm90aGVyIHByb3RvY29sIHVzaW5nIEFQLg0KDQog ICBQQ1AgdXNlcyB0aGUgQVAgZnJhbWV3b3JrIGZvciBzeW50YXggYW5kIGJh c2ljIHByb3RvY29sIHNlbWFudGljcywgYXMNCiAgIHRoaXMgaXMgc2ltcGxl ciwgY2xlYW5lciwgYW5kIGNsZWFyZXIgdGhhbiB3cml0aW5nIHRoZSBwcm90 b2NvbCBmcm9tDQogICBzY3JhdGNoLg0KDQoNCjIuICAgQ29udmVudGlvbnMg VXNlZCBpbiB0aGlzIERvY3VtZW50DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg Tk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluICJLZXkg d29yZHMgZm9yIHVzZSBpbg0KICAgUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJl bWVudCBMZXZlbHMiIFtLRVlXT1JEU10uDQoNCg0KMy4gICBQcm90b2NvbCBP dmVydmlldw0KDQogICBBdCBzZXNzaW9uIHN0YXJ0dXAsIHRoZSBzZXJ2ZXIg aW5kaWNhdGVzIGl0cyB3aWxsaW5nbmVzcyB0byBvZmZlcg0KICAgcGFzc3Bo cmFzZS1jaGFuZ2luZyBjYXBhYmlsaXR5IGJ5IHNlbmRpbmcgdGhlIFBDUCBj YXBhYmlsaXR5IGluIHRoZQ0KICAgaW5pdGlhbCBBUCBncmVldGluZy4NCg0K ICAgSWYgYSBTQVNMIFtTQVNMXSBzZWN1cml0eSBtZWNoYW5pc20gaXMgbmVn b3RpYXRlZCB2aWEgdGhlDQogICBBVVRIRU5USUNBVEUgd2hpY2ggaXMgb2Yg YWNjZXB0YWJsZSBzdHJlbmd0aCB0byB0aGUgc2VydmVyLCBhbmQNCiAgIHNl c3Npb24gaW50ZWdyaXR5IGFuZCBwcml2YWN5IGhhdmUgYmVlbiBlbmFibGVk LCB0aGUgc2VydmVyIE1VU1Qgc2VuZA0KICAgYW4gdW50YWdnZWQgUENQIHJl c3BvbnNlIGp1c3QgYmVmb3JlIHRoZSBjb21wbGV0aW9uIG9mIHRoZQ0KICAg QVVUSEVOVElDQVRFIGNvbW1hbmQsIGluZGljYXRpbmcgaXRzIHdpbGxpbmdu ZXNzIHRvIHBlcmZvcm0NCiAgIHBhc3NwaHJhc2UgY2hhbmdlIG9wZXJhdGlv bnMuDQoNCiAgIE9uY2UgdGhlIHNlc3Npb24gaXMgaW4gdGhlIGF1dGhlbnRp Y2F0ZWQgc3RhdGUsIHRoZSBjbGllbnQgTUFZDQogICBwcm9jZWVkIHRvIGxp c3QgdGhlIGF2YWlsYWJsZSBzZXJ2aWNlLXRhZ3MgdXNpbmcgdGhlIExJU1RQ V1NFUlZJQ0VTDQogICBjb21tYW5kLCBhbmQgaXNzdWUgQ0hBTkdFUFcgY29t bWFuZHMgdG8gc2V0IGEgdXNlcidzIHBhc3NwaHJhc2UgZm9yIGENCiAgIHNl dCBvZiBzZXJ2aWNlcyBhc3NvY2lhdGVkIHdpdGggdGhvc2Ugc2VydmljZS10 YWdzLCBhdCBhbnkgdGltZSB1bnRpbA0KICAgdGhlIHNlc3Npb24gaXMgY2xv c2VkLiAgQ2xpZW50cyBhcmUgcmVzcG9uc2libGUgZm9yIGluZGVwZW5kZW50 bHkNCiAgIGRlY2lkaW5nIHdoZXRoZXIgb3Igbm90IHRoZSBuZWdvdGlhdGVk IG1lY2hhbmlzbSwgaW50ZWdyaXR5LCBhbmQNCiAgIHByaXZhY3kgYXJlIHN1 aXRhYmxlLCBidXQgTVVTVCBOT1QgaXNzdWUgQ0hBTkdFUFcgY29tbWFuZHMg dW5sZXNzIHRoZQ0KICAgc2VydmVyIGhhcyBpc3N1ZWQgYW4gdW50YWdnZWQg UENQIHJlc3BvbnNlLg0KDQogICBBIHNlcnZpY2UtdGFnIGlzIGFuIG9wYXF1 ZSBzdHJpbmcsIGRlZmluZWQgYnkgdGhlIHNlcnZlciB3aXRoaW4gdGhlDQog ICBjb250ZXh0IG9mIHRoZSBjb25uZWN0aW9uLCB3aGljaCBjb3JyZXNwb25k cyB0byBzb21lIHNldCBvZiBzZXJ2aWNlcw0KICAgZm9yIHdoaWNoIHRoZSB1 c2VyJ3MgcGFzc3BocmFzZSBtYXkgYmUgY2hhbmdlZC4NCg0KDQoNCg0KDQoN Cg0KRWFyaGFydCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldCBE UkFGVCAgICAgICAgIFBhc3NwaHJhc2UgQ2hhbmdlIFByb3RvY29sICAgICAg ICAgICBKYW51YXJ5IDE5OTgNCg0KDQo0LiAgIExpbmsgTGV2ZWwNCg0KICAg VGhlIEFQIGZyYW1ld29yayBhc3N1bWVzIGEgcmVsaWFibGUgZGF0YSBzdHJl YW0gc3VjaCBhcyBwcm92aWRlZCBieQ0KICAgVENQLiAgV2hlbiBUQ1AgaXMg dXNlZCBhbmQgUENQIGlzIG5vdCB1c2VkIHdpdGggYW5vdGhlciBzZXJ2aWNl LCBhDQogICBQQ1Agc2VydmVyIGxpc3RlbnMgb24gcG9ydCA8eHh4Pi4NCg0K DQo1LiAgIENhcGFiaWxpdGllcywgQ29tbWFuZHMsIGFuZCBSZXNwb25zZXMN Cg0KICAgUENQIGRlZmluZXMgYSBzaW5nbGUgY2FwYWJpbGl0eSwgIlBDUCIg KHdoaWNoIE1VU1QgYmUgc2VudCBieSBhDQogICBzZXJ2ZXIgaW1wbGVtZW50 aW5nIFBDUCBpbiB0aGUgaW5pdGlhbCBBUCBzZXNzaW9uIGdyZWV0aW5nKSwg dGhlIFBDUA0KICAgdW50YWdnZWQgcmVzcG9uc2UgKHRvIGJlIHNlbnQgYXMg cGFydCBvZiB0aGUgQVVUSEVOVElDQVRFIGNvbW1hbmQpLA0KICAgdGhlIExJ U1RQV1NFUlZJQ0VTIGNvbW1hbmQgYW5kIFBXU0VSVklDRSByZXNwb25zZSB1 c2VkIGZvciBvYnRhaW5pbmcNCiAgIHRoZSBsaXN0IG9mIHNlcnZpY2UtdGFn cywgYW5kIHRoZSBDSEFOR0VQVyBjb21tYW5kLCB3aGljaCBpcyB1c2VkIGZv cg0KICAgY2hhbmdpbmcgdGhlIHVzZXIncyBwYXNzcGhyYXNlIGZvciBhIGdp dmVuIHNldCBvZiBzZXJ2aWNlcy4NCg0KDQo1LjEuIFBDUCBSZXNwb25zZQ0K DQogICBEYXRhOiAgICAgICBub25lDQoNCiAgICAgIFRoZSBQQ1AgdW50YWdn ZWQgcmVzcG9uc2UgaXMgc2VudCBpbiByZXNwb25zZSB0byBhIHN1Y2Nlc3Nm dWwgQVANCiAgICAgIEFVVEhFTlRJQ0FURSBjb21tYW5kLCBiZWZvcmUgdGhl IEFVVEhFTlRJQ0FURSBjb21wbGV0ZXMsIHRvDQogICAgICBpbmRpY2F0ZSB0 aGF0IHRoZSBzZXJ2ZXIgYWNjZXB0cyB0aGUgbmVnb3RpYXRlZCBhdXRoZW50 aWNhdGlvbg0KICAgICAgbWVjaGFuaXNtIGFuZCBzZXNzaW9uIGludGVncml0 eSBhbmQgcHJpdmFjeSBsYXllcnMgZm9yIHRoZSBwdXJwb3NlDQogICAgICBv ZiBwYXNzcGhyYXNlIGNoYW5nZS4NCg0KICAgICAgU2VydmVycyBhZHZlcnRp c2luZyB0aGUgUENQIGNhcGFiaWxpdHkgTVVTVCBzZW5kIGEgUENQIHVudGFn Z2VkDQogICAgICByZXNwb25zZSB0byBhbiBhdXRoZW50aWNhdGUgY29tbWFu ZCBpZiBhbmQgb25seSBpZiB0aGUgbmVnb3RpYXRlZA0KICAgICAgbWVjaGFu aXNtIGFuZCBzZXNzaW9uIHNlY3VyaXR5IGFuZCBwcml2YWN5IGxheWVycyBh cmUgc3VpdGFibGUgdG8NCiAgICAgIHRoZSBzZXJ2ZXIgZm9yIHNlbmRpbmcg cGFzc3BocmFzZXMuDQoNCiAgICAgIENsaWVudHMgTVVTVCBOT1QgYXR0ZW1w dCB0byBjaGFuZ2UgYSB1c2VyJ3MgcGFzc3BocmFzZSB1bmxlc3MgdGhleQ0K ICAgICAgaGF2ZSByZWNlaXZlZCBhIFBDUCB1bnRhZ2dlZCByZXNwb25zZSBm cm9tIHRoZSBzZXJ2ZXIuDQoNCg0KNS4yLiBMSVNUUFdTRVJWSUNFUyBDb21t YW5kDQoNCiAgIEFyZ3VtZW50czogIG5vbmUNCg0KICAgRGF0YTogICAgICAg aW50ZXJtZWRpYXRlIHJlc3BvbnNlOiBQV1NFUlZJQ0UNCg0KICAgUmVzdWx0 OiAgICAgT0sgLSBsaXN0cHdzZXJ2aWNlcyBjb21wbGV0ZWQNCiAgICAgICAg ICAgICAgIEJBRCAtIGNvbW1hbmQgdW5rbm93biBvciBhcmd1bWVudHMgaW52 YWxpZA0KDQoNCg0KDQoNCg0KDQpFYXJoYXJ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug M10NCgwNCkludGVybmV0IERSQUZUICAgICAgICAgUGFzc3BocmFzZSBDaGFu Z2UgUHJvdG9jb2wgICAgICAgICAgIEphbnVhcnkgMTk5OA0KDQoNCiAgICAg IFRoZSBMSVNUUFdTRVJWSUNFUyBjb21tYW5kIGdlbmVyYXRlcyBQV1NFUlZJ Q0UgcmVzcG9uc2VzIHRvDQogICAgICBlbnVtZXJhdGUgdGhlIHNlcnZpY2Ut dGFncyBhdmFpbGFibGUgZm9yIHVzZSB3aXRoIHRoZSBDSEFOR0VQVw0KICAg ICAgY29tbWFuZCwgYXMgd2VsbCBhcyBwcm92aWRpbmcgaHVtYW4tcmVhZGFi bGUgZGVzY3JpcHRpb25zIGZvciBlYWNoDQogICAgICBzZXJ2aWNlLXRhZy4N Cg0KDQogICAgICBFeGFtcGxlOiAgQzogYTAwMiBMSVNUUFdTRVJWSUNFUw0K ICAgICAgICAgICAgICAgIFM6IGEwMDIgUFdTRVJWSUNFICJhbGwiICJQYXNz cGhyYXNlIHVzZWQgZm9yIGFsbA0KICAgICAgICAgICAgICAgIHNlcnZpY2Vz Ig0KICAgICAgICAgICAgICAgIFM6IGEwMDIgUFdTRVJWSUNFICJtYWlsIiAi UGFzc3BocmFzZSB1c2VkIGZvciBhbGwgbWFpbC0NCiAgICAgICAgICAgICAg ICByZWxhdGVkIHNlcnZpY2VzIg0KICAgICAgICAgICAgICAgIFM6IGEwMDIg UFdTRVJWSUNFICJJTUFQIiAiSU1BUC1zcGVjaWZpYyBwYXNzcGhyYXNlIg0K ICAgICAgICAgICAgICAgIFM6IGEwMDIgUFdTRVJWSUNFICJQT1AzIiAiUE9Q My1zcGVjaWZpYyBwYXNzcGhyYXNlIg0KICAgICAgICAgICAgICAgIFM6IGEw MDIgT0sgIkxpc3RQV1NlcnZpY2VzIENvbXBsZXRlIg0KDQoNCjUuMy4gUFdT RVJWSUNFIEludGVybWVkaWF0ZSBSZXNwb25zZQ0KDQogICBEYXRhOiAgICAg ICBzZXJ2aWNlLXRhZw0KICAgICAgICAgICAgICAgaHVtYW4tcmVhZGFibGUg c2VydmljZSBkZXNjcmlwdGlvbg0KDQogICAgICBUaGUgUFdTRVJWSUNFIHJl c3BvbnNlIGlkZW50aWZpZXMgYSBzZXJ2aWNlLXRhZyBhbmQgYXNzb2NpYXRl cyBhDQogICAgICBodW1hbi1yZWFkYWJsZSBzdHJpbmcgd2l0aCB0aGUgc2Vy dmljZS10YWcuICBUaGUgaHVtYW4tcmVhZGFibGUNCiAgICAgIGRlc2NyaXB0 aW9uIE1BWSBiZSBwcmVzZW50ZWQgdG8gdGhlIHVzZXIuICBUaGUgc2Vydmlj ZS10YWcgTVVTVCBiZQ0KICAgICAgdHJlYXRlZCBhcyBhbiBvcGFxdWUgc3Ry aW5nLCB1c2VmdWwgb25seSB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlDQog ICAgICBjdXJyZW50IHNlc3Npb24sIHRvIGJlIGhhbmRlZCBiYWNrIHRvIHRo ZSBzZXJ2ZXIgaW4gYSBDSEFOR0VQVw0KICAgICAgY29tbWFuZC4NCg0KICAg ICAgVGhlIGh1bWFuLXJlYWRhYmxlIGRlc2NyaXB0aW9uIE1VU1QgYmUgaW4g dGhlIGN1cnJlbnQgc2Vzc2lvbg0KICAgICAgbGFuZ3VhZ2UsIGFzIHNldCB2 aWEgdGhlIEFQIExBTkcgY29tbWFuZC4gIElmIG5vIGxhbmd1YWdlIGhhcyBi ZWVuDQogICAgICBzZXQsIHRoZSBkZXNjcmlwdGlvbnMgTVVTVCBiZSBpbiB0 aGUgcmVnaXN0ZXJlZCBsYW5ndWFnZQ0KICAgICAgImktZGVmYXVsdCIgW0NI QVJTRVQtTEFORy1QT0xJQ1ldLCBpbnRlbmRlZCBmb3IgYW4gaW50ZXJuYXRp b25hbA0KICAgICAgYXVkaWVuY2UuDQoNCg0KNS40LiBDSEFOR0VQVyBDb21t YW5kDQoNCiAgIEFyZ3VtZW50czogIHVzZXJpZCBvciBOSUwNCiAgICAgICAg ICAgICAgIHNlcnZpY2UgbGlzdA0KICAgICAgICAgICAgICAgbmV3LXBhc3Nw aHJhc2UNCg0KICAgRGF0YTogICAgICAgbm9uZQ0KDQogICBSZXN1bHQ6ICAg ICBPSyAtIHBhc3NwaHJhc2UgY2hhbmdlZA0KICAgICAgICAgICAgICAgTk8g LSBwYXNzcGhyYXNlIHVuYWNjZXB0YWJsZSBvciBpbnN1ZmZpY2llbnQNCiAg ICAgICAgICAgICAgIGF1dGhvcml6YXRpb24NCiAgICAgICAgICAgICAgIEJB RCAtIGNvbW1hbmQgdW5rbm93biwgYXJndW1lbnRzIGludmFsaWQsIG5lZ290 aWF0ZWQNCiAgICAgICAgICAgICAgIHNlY3VyaXR5IGxheWVyIHVuYWNjZXB0 YWJsZSBmb3IgcGFzc3BocmFzZSBjaGFuZ2VzDQoNCg0KDQpFYXJoYXJ0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0IERSQUZUICAgICAgICAg UGFzc3BocmFzZSBDaGFuZ2UgUHJvdG9jb2wgICAgICAgICAgIEphbnVhcnkg MTk5OA0KDQoNCiAgICAgICAgICAgICAgIChhY2NvbXBhbmllZCBieSBhbiBB VVRILVRPTy1XRUFLIHJlc3BvbnNlIGNvZGUpLCBvcg0KICAgICAgICAgICAg ICAgZW5jcnlwdGlvbiBpcyBub3QgZW5hYmxlZCBmb3IgdGhlIGNvbm5lY3Rp b24gKGFjY29tcGFuaWVkDQogICAgICAgICAgICAgICBieSBhbiBFTkNSWVBU LU5FRURFRCByZXNwb25zZSBjb2RlKQ0KDQogICAgICBUaGUgQ0hBTkdFUFcg Y29tbWFuZCBjaGFuZ2VzIHRoZSBwYXNzcGhyYXNlIGZvciB0aGUgaW5kaWNh dGVkIHVzZXINCiAgICAgIChvciwgaWYgTklMLCBmb3IgdGhlIHVzZXJpZCB1 c2VkIGluIGF1dGhlbnRpY2F0aW9uKSBmb3IgdGhlDQogICAgICBzdXBwbGll ZCBzZXJ2aWNlcyB0byB0aGUgbmV3IHBhc3NwaHJhc2UuDQoNCiAgICAgIFRo aXMgTVVTVCBOT1QgY2hhbmdlIHRoZSB1c2VyJ3MgcGFzc3BocmFzZSBmb3Ig YW55IG90aGVyIHNlcnZpY2VzDQogICAgICBub3QgYXNzb2NpYXRlZCB3aXRo IHRoZSBzZXJ2aWNlLXRhZ3Mgc3VwcGxpZWQgaW4gdGhlIHNlcnZpY2UgbGlz dC4NCiAgICAgIFVzZXJzIFNIT1VMRCBiZSBhYmxlIHRvIGZpZ3VyZSBvdXQg ZXhhY3RseSB3aGljaCBwYXNzcGhyYXNlcyBhcmUNCiAgICAgIGJlaW5nIGNo YW5nZWQgZnJvbSB0aGUgdGV4dHVhbCBkZXNjcmlwdGlvbiBzdXBwbGllZCB3 aXRoIGVhY2gNCiAgICAgIHNlcnZpY2UtdGFnLg0KDQogICAgICBUaGUgc2Vy dmVyIE1BWSBwZXJmb3JtIGFyYml0cmFyeSB2YWxpZGF0aW9uIG9mIHRoZSBw YXNzcGhyYXNlOyBpZg0KICAgICAgdGhlIHBhc3NwaHJhc2UgaXMgdW5hY2Nl cHRhYmxlIGZvciBhbnkgcmVhc29uLCB0aGUgc2VydmVyIE1BWQ0KICAgICAg cmVzcG9uZCB3aXRoIGEgTk8uDQoNCiAgICAgIElmIHRoZSBzZXJ2ZXIgZG9l cyBub3QgZmVlbCB0aGUgbmVnb3RpYXRlZCBzZWN1cml0eSBsYXllciBpcw0K ICAgICAgc3Ryb25nIGVub3VnaCBmb3IgcGFzc3BocmFzZSBjaGFuZ2VzLCBp dCBNQVkgcmVqZWN0IHRoZSByZXF1ZXN0DQogICAgICB3aXRoIGFuIEFVVEgt VE9PLVdFQUsgcmVzcG9uc2UgY29kZSAodGhpcyBtYXkgb2NjdXIgd2hlbiBQ Q1AgaXMNCiAgICAgIGNvdXBsZWQgd2l0aCBhbm90aGVyIHNlcnZpY2Ugb24g dGhlIHNhbWUgY29ubmVjdGlvbikuICBJZiB0aGUNCiAgICAgIHNlY3VyaXR5 IGxheWVyIGlzIHN0cm9uZyBlbm91Z2ggYnV0IHNlc3Npb24gaW50ZWdyaXR5 IG9yIHByaXZhY3kNCiAgICAgIGlzIGRpc2FibGVkLCBpdCBNVVNUIHJlamVj dCB0aGUgcmVxdWVzdCB3aXRoIGFuIEVOQ1JZUFQtTkVFREVEDQogICAgICBy ZXNwb25zZSBjb2RlLg0KDQogICAgICAgICBOb3RlIHRoYXQgYm90aCBvZiB0 aGVzZSBhcmUgY29uc2lkZXJlZCBCQUQgY29uZGl0aW9uczsgdGhleQ0KICAg ICAgICAgc2hvdWxkIG5ldmVyIGFyaXNlIGluIHByYWN0aWNlLiAgQSBzZXJ2 ZXIgTVVTVCBOT1Qgc2VuZCBhIFBDUA0KICAgICAgICAgdW50YWdnZWQgcmVz cG9uc2UgdW5sZXNzIHRoZSBzZWN1cml0eSBsYXllciBpcyBjb25zaWRlcmVk DQogICAgICAgICBzdHJvbmcgYW5kIHNlc3Npb24gaW50ZWdyaXR5IGFuZCBw cml2YWN5IGFyZSBlbmFibGVkLCBhbmQgYQ0KICAgICAgICAgY2xpZW50IE1V U1QgTk9UIGF0dGVtcHQgdG8gY2hhbmdlIGEgcGFzc3BocmFzZSB1bmxlc3Mg aXQgaGFzDQogICAgICAgICByZWNlaXZlZCBhIFBDUCB1bnRhZ2dlZCByZXNw b25zZSwgc28gaWYgZWl0aGVyIG9mIHRoZSBhYm92ZSB0d28NCiAgICAgICAg IGNvbmRpdGlvbnMgaXMgbm90IG1ldCwgc29tZXRoaW5nIGhhcyBnb25lIGRy YXN0aWNhbGx5IHdyb25nLg0KDQogICAgICBXaGVuIFBDUCBpcyBiZWluZyB1 c2VkIGJ5IGl0c2VsZiwgdGhlIHNlcnZlciBNVVNUIE5PVCBhbGxvdyBhbnkN CiAgICAgIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgb3IgaW50ZWdyaXR5 L3ByaXZhY3kgbGF5ZXJzIHRvIGJlDQogICAgICBuZWdvdGlhdGVkIHdoaWNo IGFyZSBub3QgYWNjZXB0YWJsZSBmb3IgcGFzc3BocmFzZSB0cmFuc21pc3Np b24uDQoNCiAgICAgIFRoZSBDSEFOR0VQVyBjb21tYW5kIE1VU1Qgb25seSBi ZSB1c2VkIGluIHRoZSBhdXRoZW50aWNhdGVkIHN0YXRlLA0KICAgICAgYW5k IE1VU1QgT05MWSBCRSBVU0VEIElGIEEgUENQIFVOVEFHR0VEIFJFU1BPTlNF IEhBUyBCRUVODQogICAgICBSRUNFSVZFRC4NCg0KICAgICAgVGhlIHN0cmlu ZyBzZW50IGFzIHRoZSBuZXcgcGFzc3BocmFzZSBpcyB0aGUgdXNlcidzIHBs YWludGV4dA0KICAgICAgcGFzc3BocmFzZS4NCg0KDQogICAgICBFeGFtcGxl OiAgQzogYTAwMyBDSEFOR0VQVyBOSUwgKCJJTUFQIiAiUE9QMyIpICJibHVy ZHlibG9vcCINCiAgICAgICAgICAgICAgICBTOiBhMDAzIE9LICJQYXNzcGhy YXNlIGNoYW5nZWQiDQoNCg0KDQpFYXJoYXJ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug NV0NCgwNCkludGVybmV0IERSQUZUICAgICAgICAgUGFzc3BocmFzZSBDaGFu Z2UgUHJvdG9jb2wgICAgICAgICAgIEphbnVhcnkgMTk5OA0KDQoNCjYuICAg Rm9ybWFsIFN5bnRheA0KDQogICBUaGUgZm9sbG93aW5nIHN5bnRheCBzcGVj aWZpY2F0aW9uIHVzZXMgdGhlIGF1Z21lbnRlZCBCYWNrdXMtTmF1cg0KICAg Rm9ybSAoQk5GKSBub3RhdGlvbiBhcyBzcGVjaWZpZWQgaW4gW0FCTkZdLiAg VGhpcyB1c2VzIHRoZSBBQk5GIGNvcmUNCiAgIHJ1bGVzIGFzIHNwZWNpZmll ZCBpbiBBcHBlbmRpeCBBIG9mIHRoZSBBQk5GIHNwZWNpZmljYXRpb24gW0FC TkZdLA0KICAgYW5kIGF1Z21lbnRzIHRoZSBjb3JlIEFQIGdyYW1tYXIgc3Bl Y2lmaWVkIGluIFtBUF0uDQoNCiAgIEV4Y2VwdCBhcyBub3RlZCBvdGhlcndp c2UsIGFsbCBhbHBoYWJldGljIGNoYXJhY3RlcnMgYXJlIGNhc2UtDQogICBp bnNlbnNpdGl2ZS4gIFRoZSB1c2Ugb2YgdXBwZXIgb3IgbG93ZXIgY2FzZSBj aGFyYWN0ZXJzIHRvIGRlZmluZQ0KICAgdG9rZW4gc3RyaW5ncyBpcyBmb3Ig ZWRpdG9yaWFsIGNsYXJpdHkgb25seS4gIEltcGxlbWVudGF0aW9ucyBNVVNU DQogICBhY2NlcHQgdGhlc2Ugc3RyaW5ncyBpbiBhIGNhc2UtaW5zZW5zaXRp dmUgZmFzaGlvbi4NCg0KDQogICBjYXBhYmlsaXR5ICAgICAgPS8gIlBDUCIN Cg0KICAgY29tbWFuZCAgICAgICAgID0vICJDSEFOR0VQVyIgU1AgdXNlcmlk IFNQIHNlcnZpY2UtbGlzdCBTUCBuZXctcGFzc3BocmFzZQ0KDQogICBjb21t YW5kICAgICAgICAgPS8gIkxJU1RQV1NFUlZJQ0VTIg0KDQogICBuZXctcGFz c3BocmFzZSAgPSBzdHJpbmcNCg0KICAgcmVzcG9uc2UgICAgICAgID0vICJQ V1NFUlZJQ0UiIFNQIHNlcnZpY2UtdGFnIFNQIHNlcnZpY2UtZGVzY3JpcA0K DQogICBzZXJ2aWNlLWRlc2NyaXAgPSBzdHJpbmctdXRmOA0KICAgICAgICAg ICAgICAgICAgIDsgbXVzdCBiZSBpbiB0aGUgY3VycmVudCBsYW5ndWFnZQ0K DQogICBzZXJ2aWNlLWxpc3QgICAgPSAnKCcgc2VydmljZS10YWcgKihTUCBz ZXJ2aWNlLXRhZykgJyknDQoNCiAgIHNlcnZpY2UtdGFnICAgICA9IHN0cmlu Zw0KDQogICBzdGF0dXMtcmVzcG9uc2UgPS8gIlBDUCIgcmVzcC1ib2R5DQog ICAgICAgICAgICAgICAgICAgICAgOyBtdXN0IGJlIHVudGFnZ2VkDQoNCiAg IHVzZXJpZCAgICAgICAgICA9IHN0cmluZyAvIE5JTA0KDQoNCg0KNy4gICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBTZWN1cml0eSBjb25zaWRl cmF0aW9ucyBhcmUgZGlzY3Vzc2VkIHRocm91Z2hvdXQgdGhpcyBtZW1vLg0K DQogICBDaGFuZ2luZyBhIHVzZXIncyBwYXNzcGhyYXNlIGlzIGEgdmVyeSBk ZWxpY2F0ZSBvcGVyYXRpb24uICBTZXJ2ZXJzDQogICBhbmQgY2xpZW50cyBN VVNUIGluc2lzdCBvbiBhcHByb3ByaWF0ZSBhdXRoZW50aWNhdGlvbiwgc2Vz c2lvbg0KICAgaW50ZWdyaXR5IGFuZCBwcml2YWN5IGZvciBwYXNzcGhyYXNl IGNoYW5nZXMuDQoNCiAgIEluIHBhcnRpY3VsYXI6DQoNCiAgICAgIENsaWVu dHMgTVVTVCBOT1Qgc2VuZCBhIHVzZXIncyBwYXNzcGhyYXNlIGluIHRoZSBj bGVhci4NCg0KDQoNCkVhcmhhcnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0K SW50ZXJuZXQgRFJBRlQgICAgICAgICBQYXNzcGhyYXNlIENoYW5nZSBQcm90 b2NvbCAgICAgICAgICAgSmFudWFyeSAxOTk4DQoNCg0KICAgICAgQ2xpZW50 cyBNVVNUIE5PVCBhdHRlbXB0IHRvIGNoYW5nZSBhIHVzZXIncyBwYXNzcGhy YXNlIHVubGVzcyB0aGUNCiAgICAgIFBDUCB1bnRhZ2dlZCByZXNwb25zZSBo YXMgYmVlbiByZWNlaXZlZCAodGhpcyBpcyBpbnRlbmRlZCB0bw0KICAgICAg cHJldmVudCBhbiBvbGQgY2xpZW50IGZyb20gYXR0ZW1wdGluZyB0byB1c2Ug YSBtZWNoYW5pc20gdGhhdCB0aGUNCiAgICAgIHNlcnZlciBrbm93cyBpcyB3 ZWFrKS4NCg0KICAgICAgU2VydmVycyBNVVNUIE5PVCBzZW5kIHRoZSBQQ1Ag dW50YWdnZWQgcmVzcG9uc2UgdW5sZXNzIHRoZXkgYXJlDQogICAgICB3aWxs aW5nIHRvIGVudHJ1c3QgdGhlaXIgdXNlcidzIHBhc3NwaHJhc2VzIHRvIHRo ZSBuZWdvdGlhdGVkDQogICAgICBhdXRoZW50aWNhdGlvbiwgaW50ZWdyaXR5 LCBhbmQgcHJpdmFjeSBtZWNoYW5pc21zLg0KDQogICAgICBDbGllbnRzIGFu ZCBzZXJ2ZXJzIE1VU1QgdGFrZSBhY3RpdmUgYXR0YWNrcyBpbnRvIGFjY291 bnQsIGFuZCBub3QNCiAgICAgIGFsbG93IHRoZSB1c2Ugb2YgYSB3ZWFrIHNl Y3VyaXR5IG1lY2hhbmlzbSwgb3IgdGhlIGRpc2FibGluZyBvZg0KICAgICAg c2Vzc2lvbiBpbnRlZ3JpdHkgb3IgcHJpdmFjeSBsYXllcnMgKHRoaXMgaGFz IGJlZW4gc3RhdGVkIG51bWVyb3VzDQogICAgICB0aW1lcywgYnV0IGlzIGNv bnNpZGVyZWQgd2VsbCB3b3J0aCByZXBlYXRpbmcpLg0KDQoNCjguICAgQ29w eXJpZ2h0DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2ll dHkgMTk5OC4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1 bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5k IGZ1cm5pc2hlZCB0bw0KICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3Jr cyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQNCiAg IG9yIGFzc2lzdCBpbiBpdHMgaW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBh cmVkLCBjb3BpZWQsIHB1Ymxpc2hlZA0KICAgYW5kIGRpc3RyaWJ1dGVkLCBp biB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFu eQ0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0 IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlDQogICBpbmNsdWRlZCBv biBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuICBIb3dl dmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2Rp ZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nDQogICB0aGUg Y29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5l dCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdhbml6YXRpb25z LCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZg0KICAgZGV2 ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUg cHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUg SW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQ0KICAgZm9sbG93 ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1 YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQogICBUaGUgbGltaXRl ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5k IHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2Np ZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuDQoNCiAgIFRoaXMg ZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGlzIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg SU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5H DQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQ UkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJVVCBOT1QgTElNSVRF RCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1B VElPTg0KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMg T1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRg0KICAgTUVSQ0hBTlRBQklM SVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoN CjkuICAgUmVmZXJlbmNlcw0KDQogICBbQVBdIEVhcmhhcnQsIFIuLCAiQWNj ZXNzIFByb3RvY29sIiwgV29yayBpbiBQcm9ncmVzcy4NCg0KDQoNCg0KRWFy aGFydCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldCBEUkFGVCAg ICAgICAgIFBhc3NwaHJhc2UgQ2hhbmdlIFByb3RvY29sICAgICAgICAgICBK YW51YXJ5IDE5OTgNCg0KDQogICBbQUJORl0gQ3JvY2tlciwgRC4sIGFuZCBP dmVyZWxsLCBQLiwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAgU3Bl Y2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgMjIzNCwgTm92ZW1iZXIgMTk5Ny4N Cg0KICAgICAgPHVybDpmdHA6Ly9kcy5pbnRlcm5pYy5uZXQvcmZjL3JmYzIy MzQudHh0Pg0KDQogICBbQ0hBUlNFVC1MQU5HLVBPTElDWV0gQWx2ZXN0cmFu ZCwgSC4sICJJRVRGIFBvbGljeSBvbiBDaGFyYWN0ZXIgU2V0cw0KICAgYW5k IExhbmd1YWdlcyIsIHdvcmsgaW4gcHJvZ3Jlc3MuDQoNCiAgIFtDUkFNLU1E NV0gS2xlbnNpbiwgSi4sIENhdG9lLCBSLiwgYW5kIEtydW12aWVkZSwgUC4s ICJJTUFQL1BPUA0KICAgQVVUSG9yaXplIEV4dGVuc2lvbiBmb3IgU2ltcGxl IENoYWxsZW5nZS9SZXNwb25zZSIsIFJGQyAyMTk1LA0KICAgU2VwdGVtYmVy IDE5OTcuDQoNCiAgICAgIDx1cmw6ZnRwOi8vZHMuaW50ZXJuaWMubmV0L3Jm Yy9yZmMyMTk1LnR4dD4NCg0KICAgW0tFWVdPUkRTXSBCcmFkbmVyLCBTLiwg IktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgIFJl cXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5 OTcuDQoNCiAgICAgIDx1cmw6ZnRwOi8vZHMuaW50ZXJuaWMubmV0L3JmYy9y ZmMyMTE5LnR4dD4NCg0KICAgW1NBU0xdIE15ZXJzLCBKLiwgIlNpbXBsZSBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNBU0wpIiwNCiAg IFJGQyAyMjIyLCBPY3RvYmVyIDE5OTcuDQoNCiAgICAgIDx1cmw6ZnRwOi8v ZHMuaW50ZXJuaWMubmV0L3JmYy9yZmMyMjIyLnR4dD4NCg0KDQoxMC4gIEF1 dGhvcidzIEFkZHJlc3MNCg0KICAgUm9iZXJ0IEguIEVhcmhhcnQNCiAgIENh cm5lZ2llIE1lbGxvbg0KICAgNTAwMCBGb3JiZXMgQXZlLg0KICAgUGl0dHNi dXJnaCBQQSwgMTUyMTMtMzg5MA0KDQogICBFbWFpbDogZWFyaGFydCtAY211 LmVkdQ0KDQoNCkV4cGlyZXMgSnVseSAxOTk4DQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpFYXJoYXJ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgw= ---2147343199-1678144658-884123463=:26325-- From owner-ietf-sasl Wed Jan 7 15:18:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13567 for ietf-sasl-bks; Wed, 7 Jan 1998 15:18:26 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13562 for ; Wed, 7 Jan 1998 15:18:23 -0800 (PST) Received: from elwood.innosoft.com ("port 33429"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IS3M1QV60Q9TDOH2@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 7 Jan 1998 15:20:06 PST Date: Wed, 07 Jan 1998 15:22:12 -0800 (PST) From: Chris Newman Subject: re: Expiring Passwords In-reply-to: To: Rob Earhart Cc: 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 Tue, 6 Jan 1998, Rob Earhart wrote: > After some comments (thanks, Jack!), I've revised the proposal for PCP, > and attached a new copy. The biggest change is that it no longer deals > with specific mechanisms (CRAM-MD5, Kerberos, etc), and instead does > things with services (IMAP, ACAP, all, mail-related, etc...), which I > think is probably easier for users to comprehend, and allows for site > definitions of service-specific passphrases to be dealt with quite > cleanly. > > I think I'd rather just require that the entire session be encrypted > with something strong, rather than trying to use some sort of > mechanism-specific thing to transfer the passphrase, which quickly becomes > complicated. A few comments: (1) You are duplicating earlier work. See draft-newman-pwchange-00.txt. It's far from done, but there's a lot of work behind it. (2) I'm not sure a password change protocol should be based on AP -- it needs to be as simple as possible so it can be given a complete security analysis. (3) Encrypting the whole session is not the right option, because it either can't be exported or is worthless for protecting a passphrase. If you encrypt *just* the old & new passphrase then it should be exportable even with real encryption. (4) Unless you mandate TLS or a SASL mechanism with a security layer, there's no way this can get standardized when it passes the new passphrase in the clear. (5) You haven't defined any error codes. There are a number of important ones. - Chris From owner-ietf-sasl Thu Jan 8 08:47:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA29136 for ietf-sasl-bks; Thu, 8 Jan 1998 08:47:34 -0800 (PST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA29132 for ; Thu, 8 Jan 1998 08:47:27 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Thu, 8 Jan 1998 11:51:30 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Thu, 8 Jan 1998 11:51:29 -0500 Message-Id: <3.0.1.32.19980108115412.00a0a450@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 08 Jan 1998 11:54:12 -0500 To: ietf-sasl@imc.org From: "Jack De Winter" Subject: regarding authentication trace information Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk howdy, I just looked for an example of an additional trace header for authentication information in messages. I think it was in Memphis where someone had mentioned that the Received header was inflexable and any trace information for authentication would have to be added in a new header. Does anyone have any recollection of this or of anything that has been done in this area? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Thu Jan 8 09:02:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA29345 for ietf-sasl-bks; Thu, 8 Jan 1998 09:02:41 -0800 (PST) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA29340 for ; Thu, 8 Jan 1998 09:02:37 -0800 (PST) Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id MAA17466; Thu, 8 Jan 1998 12:06:27 -0500 (EST) Date: Thu, 8 Jan 1998 12:06:25 -0500 (EST) From: Rob Earhart To: Chris Newman cc: ietf-sasl@imc.org Subject: re: Expiring Passwords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk On Wed, 7 Jan 1998, Chris Newman wrote: > (1) You are duplicating earlier work. See draft-newman-pwchange-00.txt. > It's far from done, but there's a lot of work behind it. Ah - okay. (Sorry...) > (2) I'm not sure a password change protocol should be based on AP -- it > needs to be as simple as possible so it can be given a complete security > analysis. All AP does is provide a framing mechanism; there really aren't any security issues other than those associated with using SASL over TCP, which I believe are reasonably well understood. Furthermore, I think that by seperating the command syntax from the protocol semantics, the protocol is clearer and easier to understand (I'm amused that, even with all the redundency, the draft I proposed is half the length of draft-newman-pwchange-00.txt). > (3) Encrypting the whole session is not the right option, because it > either can't be exported or is worthless for protecting a passphrase. If > you encrypt *just* the old & new passphrase then it should be exportable > even with real encryption. I find this argument specious, unless you've got a statement from the US government that such a scheme would be exportable (which wouldn't make any sense, but that hasn't exactly stopped the government before). I fail to see the distinction between encrypting just the passphrase, and encrypting the entire session, when the connection only provides the ability to change one's passphrase. Furthermore, I fail to see (from the government's angle) the safety in allowing the export of software which only encrypts the passphrase; there's little reason why the passphrase, being an essentially arbitrary blob of data determined by the user, couldn't be used to communicate information which the government would like to see. If one's permitted, the other ought to be permitted. (And again - it wouldn't surprise me to discover otherwise, but I'd like to see an official statement to that effect...) In addition, I think it's probably best to keep the OK/NO response private; I'm not certain that it matters, but as an attacker, I'd like to know when my target's passphrase has changed. > (4) Unless you mandate TLS or a SASL mechanism with a security layer, > there's no way this can get standardized when it passes the new passphrase > in the clear. The proposal I made specifies several times that session privacy MUST be used; therefore, a conforming implementation must not send the passphrase in the clear. Mandating TLS or a SASL mechanism will greatly increase interoperability, but I didn't see that as being as important in this draft; the important part is that session privacy MUST be used. > (5) You haven't defined any error codes. There are a number of important > ones. Reasonable; specific error codes for the different failure modes wouldn't be hard to add... )Rob From owner-ietf-sasl Thu Jan 8 10:53:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA01144 for ietf-sasl-bks; Thu, 8 Jan 1998 10:53:27 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA01138 for ; Thu, 8 Jan 1998 10:53:23 -0800 (PST) Received: from elwood.innosoft.com ("port 33658"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IS4R3YVKS49TDOH2@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 8 Jan 1998 10:56:14 PST Date: Thu, 08 Jan 1998 10:58:21 -0800 (PST) From: Chris Newman Subject: re: Expiring Passwords In-reply-to: To: Rob Earhart Cc: 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 Thu, 8 Jan 1998, Rob Earhart wrote: > All AP does is provide a framing mechanism; there really aren't any > security issues other than those associated with using SASL over TCP, > which I believe are reasonably well understood. Furthermore, I think that > by seperating the command syntax from the protocol semantics, the protocol > is clearer and easier to understand (I'm amused that, even with all the > redundency, the draft I proposed is half the length of > draft-newman-pwchange-00.txt). AP includes the ability to have multiple commands in progress and unsolicited notifications. While this is useful in things like IMAP or ACAP, it's unnecessary complexity when changing passphrases. I will note that draft-newman-pwchange-00.txt is shorter than your AP spec, let alone the combination of your AP spec and your pwchange spec. In addition, your pwchange spec is missing the error codes which are a significant part of the length of draft-newman-pwchange-00.txt. > I find this argument specious, unless you've got a statement from the US > government that such a scheme would be exportable (which wouldn't make any > sense, but that hasn't exactly stopped the government before). The government doesn't care about authentication -- only encryption of data. Therefore encryption which can't be used for anything but authentication is exportable in binary form. > I fail to see the distinction between encrypting just the passphrase, > and encrypting the entire session, when the connection only provides the > ability to change one's passphrase. Protocols need to be extensible. Passphrases don't. There's also lots of arbitrary text communicated from the server to the client (error messages) which has to be configurable on the server. If you went to a protocol with no configurable messages, then encrypting the entire protocol work (but it wouldn't be AP-based). > The proposal I made specifies several times that session privacy MUST be > used; therefore, a conforming implementation must not send the passphrase > in the clear. Mandating TLS or a SASL mechanism will greatly increase > interoperability, but I didn't see that as being as important in this > draft; the important part is that session privacy MUST be used. Not good enough -- if you mandate privacy, you have to mandate at least one way of providing it. If you mandate TLS, then the protocol is rather over-complicated and can't be deployed for a while (until the SSL toolkits are upgraded). If you mandate a SASL security layer, that means it will only work with a very limited set of mechanisms. - Chris From owner-ietf-sasl Thu Jan 8 12:04:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA02249 for ietf-sasl-bks; Thu, 8 Jan 1998 12:04:50 -0800 (PST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA02245 for ; Thu, 8 Jan 1998 12:04:41 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Thu, 8 Jan 1998 15:09:07 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Thu, 8 Jan 1998 15:09:06 -0500 Message-Id: <3.0.1.32.19980108151149.011a7480@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 08 Jan 1998 15:11:49 -0500 To: ietf-sasl@imc.org From: "Jack De Winter" Subject: regarding draft-myers-smtp-auth-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk a quick question regarding the inclusion of the AUTH=addr-spec to the Mail From line. My question centres around how to translate any characters that are in the "not allowed list" (space, '=', and any of the control characters) to something that can be placed in that line. If you examine the definition for addr-spec, it boils down mainly to atoms and words. With an atom, the '=' is not covered in the specs, and with the words, it devolves into atoms and quoted strings. Given an example authentication id such as: "name=\"Fred Flintstone\""@mynode.com how would we encode that so that it could be passed as an authentication token, seeing as it is perfectly valid according to the RFC822 construction rules for addr-spec? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Thu Jan 8 12:24:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA02537 for ietf-sasl-bks; Thu, 8 Jan 1998 12:24:53 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA02533 for ; Thu, 8 Jan 1998 12:24:49 -0800 (PST) Received: from elwood.innosoft.com ("port 33693"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IS4UCFEGXQ9TDOH2@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 8 Jan 1998 12:28:34 PST Date: Thu, 08 Jan 1998 12:30:40 -0800 (PST) From: Chris Newman Subject: Re: regarding draft-myers-smtp-auth-08.txt In-reply-to: <3.0.1.32.19980108151149.011a7480@lacroix.wildbear.on.ca> To: Jack De Winter Cc: 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 Thu, 8 Jan 1998, Jack De Winter wrote: > how would we encode that so that it could be passed as an authentication > token, seeing as it is perfectly valid according to the RFC822 > construction rules for addr-spec? Good question. I believe the SMTP AUTH spec should be revised to use the encoding described in section 5 of RFC 1891. - Chris From owner-ietf-sasl Thu Jan 8 12:46:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA02867 for ietf-sasl-bks; Thu, 8 Jan 1998 12:46:34 -0800 (PST) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA02862 for ; Thu, 8 Jan 1998 12:46:29 -0800 (PST) Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA27888; Thu, 8 Jan 1998 15:50:24 -0500 (EST) Date: Thu, 8 Jan 1998 15:50:24 -0500 (EST) From: Rob Earhart To: Chris Newman cc: ietf-sasl@imc.org Subject: re: Expiring Passwords In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk On Thu, 8 Jan 1998, Chris Newman wrote: > AP includes the ability to have multiple commands in progress and > unsolicited notifications. While this is useful in things like IMAP or > ACAP, it's unnecessary complexity when changing passphrases. ... and TCP includes features like two sides simultaneously initiating active connections to each other and urgent bytes, which're probably overboard for the simple task of changing passphrases. Nevertheless, I think we can agree that TCP is a useful protocol layer (and note that there's no reason why either side in an AP session needs to support multiple commands in progress, and unsolicited notifications can be ignored.) AP just sweeps all the syntax nonsense under the rug, providing a fairly clean way of encapsulating commands which seems to work in the real world. I don't mind not using it - especially since you've already got a draft out - but I disagree with your reasoning, and honestly think it's a superior technical solution. > In addition, your pwchange spec is missing the error codes which are a > significant part of the length of draft-newman-pwchange-00.txt. I honestly think you've gone overboard with error codes; the level of detail brought to mind the infamous "Recipient has died" code. In my opinion (reinforced from earlier conversations with you and John G. Myers), response codes should be minimal, dealing with things which the client can actually do something about (REFER is a great example of this), and anything else should be encapsulated in text returned to the user. > The government doesn't care about authentication -- only encryption of > data. Therefore encryption which can't be used for anything but > authentication is exportable in binary form. Yes... but in this case, you're encrypting data. True, the data will be used (theoretically) for authentication, but the passphrase could also be used for secrets ("meet in the old hideout at midnight"). > > I fail to see the distinction between encrypting just the passphrase, > > and encrypting the entire session, when the connection only provides the > > ability to change one's passphrase. > > Protocols need to be extensible. Passphrases don't. There's also lots of > arbitrary text communicated from the server to the client (error > messages) which has to be configurable on the server. If you went to a > protocol with no configurable messages, then encrypting the entire > protocol work (but it wouldn't be AP-based). You've definitely lost me, here. The protocol needs to be extensible; I'm not sure why this prevents the protocol from being encrypted. If you're allowed to ship a product that encrypts the passphrase (which could be used to transmit sensitive data, but is only supposed to be used for transmission of authentication information), why aren't you allowed to ship a product that encrypts the entire protocol session, as long as you don't allow any other functionality to be used with encryption? In both cases, that encryption's only used for the transmission of authentication information; either both are exportable, or neither is. (I'd bet that neither is.) > Not good enough -- if you mandate privacy, you have to mandate at least > one way of providing it. No. Unfortunately, this is a situation in which compatibility can not be maintained. Any mechanism we mandate may be broken in the future. We can not require servers to accept some mechanism for the sake of older clients; all we can do is have the server advertise what it's willing to use, and have clients attempt to do the best they can. We can have short-term interoperability; we can not get long-term interoperability. Clients have to be able to say, "Sorry, the server doesn't permit the use of any mechanisms we know about; please upgrade." It's futile to mandate a security layer that servers must accept, but I don't think it's futile to mandate that, whatever mechanism a server *does* accept, that it must support session privacy. )Rob From owner-ietf-sasl Thu Jan 8 14:05:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA04122 for ietf-sasl-bks; Thu, 8 Jan 1998 14:05:52 -0800 (PST) Received: from rembrandt.esys.ca (0@rembrandt.esys.ca [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA04118 for ; Thu, 8 Jan 1998 14:05:48 -0800 (PST) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id PAA16872 for ; Thu, 8 Jan 1998 15:09:45 -0700 From: Steve Hole Date: Thu, 8 Jan 1998 15:06:12 -0700 To: ietf-sasl@imc.org Subject: Re: re: Expiring Passwords In-Reply-To: References: Message-ID: X-Mailer: Simeon for Win32 Version Mercury a6 Build (6) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk On Thu, 8 Jan 1998 12:06:25 -0500 (EST) Rob Earhart wrote: > > (3) Encrypting the whole session is not the right option, because it > > either can't be exported or is worthless for protecting a passphrase. If > > you encrypt *just* the old & new passphrase then it should be exportable > > even with real encryption. > > I find this argument specious, unless you've got a statement from the US > government that such a scheme would be exportable (which wouldn't make any > sense, but that hasn't exactly stopped the government before). > > I fail to see the distinction between encrypting just the passphrase, > and encrypting the entire session, when the connection only provides the > ability to change one's passphrase. If you are encrypting the entire session, then you are free to pass whatever data you would like over the connection with no way for big brother to verify that it at least pretends to be protocol X. The entire protocol will have variable, non-verifiable data lengths that could very easily hold relatively large encoded messages containing the floorplan of the Pentagon. While you could decide to use 1000 character passwords, any encrypted item of this size in a password change protocol that exposed all but the passwords would be suspect. In other words, it is possible to pass data rather than legitimate passwords, it is much easier to detect that someone is doing so and much harder to mask. This has always been the jist of the "authentication OK, channel protection BAD" argument used by the US Government spooks. It is reasonable -- hardly. It is what it is though. --- Steve From owner-ietf-sasl Thu Jan 8 13:59:17 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA04048 for ietf-sasl-bks; Thu, 8 Jan 1998 13:59:17 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA04044 for ; Thu, 8 Jan 1998 13:59:13 -0800 (PST) Received: from elwood.innosoft.com ("port 33707"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IS4XLGJDXG9TDI2U@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 8 Jan 1998 14:02:08 PST Date: Thu, 08 Jan 1998 14:04:13 -0800 (PST) From: Chris Newman Subject: re: Expiring Passwords In-reply-to: To: Rob Earhart Cc: 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 Thu, 8 Jan 1998, Rob Earhart wrote: > No. Unfortunately, this is a situation in which compatibility can not > be maintained. Any mechanism we mandate may be broken in the future. We > can not require servers to accept some mechanism for the sake of older > clients; all we can do is have the server advertise what it's willing to > use, and have clients attempt to do the best they can. > > We can have short-term interoperability; we can not get long-term > interoperability. Clients have to be able to say, "Sorry, the server > doesn't permit the use of any mechanisms we know about; please upgrade." > > It's futile to mandate a security layer that servers must accept, but I > don't think it's futile to mandate that, whatever mechanism a server > *does* accept, that it must support session privacy. The IESG has made a clear statement on this issue with respect to the TLS standardization. The TLS WG was told they had to require implementation of a particular cipher suite. It works like this: the mandatory to implement mechanism is the minimum level of protection you can expect to work. If you have no mandatory to implement mechanism, then the minimum level is none (poppassd in this instance). In the future, it may not be desirable to use the mandatory to implement mechanism, but it will be the best available that works. - Chris From owner-ietf-sasl Tue Jan 13 09:22:56 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08494 for ietf-sasl-bks; Tue, 13 Jan 1998 09:22:56 -0800 (PST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08485 for ; Tue, 13 Jan 1998 09:22:45 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 13 Jan 1998 12:26:45 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 13 Jan 1998 12:26:44 -0500 Message-Id: <3.0.1.32.19980113123008.007a9650@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 13 Jan 1998 12:30:08 -0500 To: Chris Newman From: "Jack De Winter" Subject: Re: regarding draft-myers-smtp-auth-08.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <3.0.1.32.19980108151149.011a7480@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 12:30 PM 1/8/98 -0800, Chris Newman wrote: >On Thu, 8 Jan 1998, Jack De Winter wrote: >> how would we encode that so that it could be passed as an authentication >> token, seeing as it is perfectly valid according to the RFC822 >> construction rules for addr-spec? > >Good question. I believe the SMTP AUTH spec should be revised to use the >encoding described in section 5 of RFC 1891. To be more specific: 5. Additional parameters for RCPT and MAIL commands The extended RCPT and MAIL commands are issued by a client when it wishes to request a DSN from the server, under certain conditions, for a particular recipient. The extended RCPT and MAIL commands are identical to the RCPT and MAIL commands defined in [1], except that one or more of the following parameters appear after the sender or recipient address, respectively. The general syntax for extended SMTP commands is defined in [4]. NOTE: Although RFC 822 ABNF is used to describe the syntax of these parameters, they are not, in the language of that document, "structured field bodies". Therefore, while parentheses MAY appear within an emstp-value, they are not recognized as comment delimiters. The syntax for "esmtp-value" in [4] does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1- 127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". "xtext" is formally defined as follows: xtext = *( xchar / hexchar ) xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, except for "+" and "=". ; "hexchar"s are intended to encode octets that cannot appear ; as ASCII characters within an esmtp-value. hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits When encoding an octet sequence as xtext: + Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", MAY be encoded as itself. (A CHAR in this range MAY instead be encoded as a "hexchar", at the implementor's discretion.) + ASCII CHARs that fall outside the range above must be encoded as "hexchar". Is there any reason why we should use this approach instead of the Quoted-Printable approach? I know its a difference of whether or not the character is a % or a +, but just curious. Also, the 129 character limit, is that 129 characters after or before any translation to hexchars are applied? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Wed Jan 14 10:16:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23203 for ietf-sasl-bks; Wed, 14 Jan 1998 10:16:59 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23197 for ; Wed, 14 Jan 1998 10:16:54 -0800 (PST) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id KAA07475 for ; Wed, 14 Jan 1998 10:20:45 -0800 (PST) X-Sender: llundbla@mrw.qualcomm.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Jan 1998 10:13:10 -0800 To: ietf-sasl@imc.org From: Laurence Lundblade Subject: SASL & UTF8 Sender: owner-ietf-sasl@imc.org Precedence: bulk It seems to me there a transition problem using UTF8 in SASL. For example if I set my password to something in greek using an app that supports UTF8, and then try to login from an app that doesn't support UTF8 (most today) I will never be able to login. In addition adding UTF8 support for SASL on platforms that don't support it will be rather difficult. I believe there's also an issue with fonts and input methods for particular characters, which probably can never be solved universally. About the best solution I can think of for this is to recommend that the user be given a warning when they change their password to something that is beyond US-ASCII to the effect that they will only be able to login from clients that support Unicode. Anyone thought further about this issue (or is my incomplete understanding of Unicode showing)? LL From owner-ietf-sasl Wed Jan 14 11:49:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA24991 for ietf-sasl-bks; Wed, 14 Jan 1998 11:49:21 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA24987 for ; Wed, 14 Jan 1998 11:49:18 -0800 (PST) Received: from elwood.innosoft.com ("port 34858"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISD6UR1CRM91VT0H@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 14 Jan 1998 11:53:16 PST Date: Wed, 14 Jan 1998 11:55:21 -0800 (PST) From: Chris Newman Subject: Re: SASL & UTF8 In-reply-to: To: Laurence Lundblade Cc: 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 Wed, 14 Jan 1998, Laurence Lundblade wrote: > About the best solution I can think of for this is to recommend that the > user be given a warning when they change their password to something that > is beyond US-ASCII to the effect that they will only be able to login from > clients that support Unicode. > > Anyone thought further about this issue (or is my incomplete understanding > of Unicode showing)? Yup, your conclusion sounds right. If characters with the high bit set are present, they are interpreted in UTF-8. But use of characters outside the printable US-ASCII range is discouraged. It's important to state how characters with the high bit set are interpreted, otherwise there will never be interoperable i18n in user names and passphrases. The server code I write will explicitly reject 8-bit user/passphrase strings which fail to meet UTF-8 syntax requirements. Otherwise, clients might be sloppy and use localized character sets. - Chris From owner-ietf-sasl Wed Jan 14 12:48:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA26098 for ietf-sasl-bks; Wed, 14 Jan 1998 12:48:59 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA26091 for ; Wed, 14 Jan 1998 12:48:54 -0800 (PST) Received: (qmail 12779 invoked from network); 14 Jan 1998 20:46:33 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 14 Jan 1998 20:46:33 -0000 X-Mailer: exmh version 2.0.1 12/23/97 From: Mark Wahl To: Chris Newman cc: Laurence Lundblade Cc: ietf-sasl@imc.org Cc: Mark Wahl Subject: Re: SASL & UTF8 In-reply-to: Your message of "Wed, 14 Jan 1998 11:55:21 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jan 1998 14:46:32 -0600 Message-ID: <12777.884810792@folder.critical-angle.com> Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris Newman responds to Laurence Lundblade: > Yup, your conclusion sounds right. If characters with the high bit set > are present, they are interpreted in UTF-8. But use of characters outside > the printable US-ASCII range is discouraged. > > It's important to state how characters with the high bit set are > interpreted, otherwise there will never be interoperable i18n in user > names and passphrases. > > The server code I write will explicitly reject 8-bit > user/passphrase strings which fail to meet UTF-8 syntax requirements. > Otherwise, clients might be sloppy and use localized character sets. As LDAPv3 (RFC 2251-2256) is derived from X.500, there is currently no requirement that a password value be in UTF-8. The octetStringMatch used for comparing passwords does a byte-by-byte matching. Passwords may be assigned to system services and devices which are not human-readable strings, but simply blobs of data. The token "UTF" did not appear in RFC 2195 or RFC 2222. If these documents were not updated to REQUIRE that passwords be UTF-8 encoded, then I would be concerned that implementations of SASL mechanisms such as CRAM-MD5 and sucessors which restricted passwords this way would not be interoperable in the application of SASL in LDAPv3. If an RFC updating 2222 were to mandate the UTF-8 encodings of passphrases, then this would likely require minor changes to protocols being based on SASL. I am not averse to requring UTF-8 in the documents, but would wish to ensure that protocol designers are kept informed on the planned evolution of SASL. (Hopefully soon there will be a new draft update to 2195 which also addresses the space in username problem.) LDAPv3 Distinguished names, BTW, are written in UTF-8 when the components are strings. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-sasl Thu Jan 15 09:27:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA13726 for ietf-sasl-bks; Thu, 15 Jan 1998 09:27:53 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA13720 for ; Thu, 15 Jan 1998 09:27:49 -0800 (PST) Received: from elwood.innosoft.com ("port 35874"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISEG85LGPO94DNOG@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 15 Jan 1998 09:32:11 PST Date: Thu, 15 Jan 1998 09:34:15 -0800 (PST) From: Chris Newman Subject: Re: SASL & UTF8 In-reply-to: <12777.884810792@folder.critical-angle.com> To: Mark Wahl Cc: 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 Wed, 14 Jan 1998, Mark Wahl wrote: > The token "UTF" did not appear in RFC 2195 or RFC 2222. If these documents > were not updated to REQUIRE that passwords be UTF-8 encoded, then I would be > concerned that implementations of SASL mechanisms such as CRAM-MD5 and > sucessors which restricted passwords this way would not be interoperable in > the application of SASL in LDAPv3. In addition, I wouldn't want to make a non-backwards compatible change to RFC 2222 which would require a recycle at proposed status. This is a bit of a mess, becuase right now if you use non-ASCII characters in usernames/passphrases, they simply won't work unless both ends happen to have the same localized character set. I will note that all the SASL mechanisms I'm working on will require UTF-8 for user identities and passphrases. Anyone have ideas of how to deal with this on the standards front? Perhaps the draft standard revision can simply encourage profiles and mechanisms to require UTF-8 for human readable strings associated with SASL? CRAM-MD5 currently doesn't specify the charset used. That needs to be fixed. > If an RFC updating 2222 were to mandate the UTF-8 encodings of passphrases, > then this would likely require minor changes to protocols being based on SASL. > I am not averse to requring UTF-8 in the documents, but would wish to ensure > that protocol designers are kept informed on the planned evolution of SASL. > (Hopefully soon there will be a new draft update to 2195 which also addresses > the space in username problem.) While I'm sure we could easily document a bunch of interoperable 2195 implementations (we have two independent interoperable implementations in-house -- one in C and one in Pascal :-), it can't really be moved to draft status until SASL moves to draft status. I've sent proposed text for the space in username problem to the document editors for 2195, but it's probably not worth a new RFC until SASL can move forward to draft status. - Chris From owner-ietf-sasl Thu Jan 15 10:24:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA14839 for ietf-sasl-bks; Thu, 15 Jan 1998 10:24:26 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA14834 for ; Thu, 15 Jan 1998 10:24:18 -0800 (PST) Received: from elwood.innosoft.com ("port 35878"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISEI6B60VA94DNOG@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 15 Jan 1998 10:27:57 PST Date: Thu, 15 Jan 1998 10:30:01 -0800 (PST) From: Chris Newman Subject: Call for volunteers: Moving SASL to draft status 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 By IETF procedure, it will be possible to move SASL to draft status in April. In order to make it that soon, we need to complete some work in the next 3 months to identify interoperable implementations. (Personally, I'd like to see SASL become the first IETF standard security protocol other than APOP). IETF procedure gives the WG chair responsibility to document interoperable implementations. As SASL was an individual submission by John Myers, I'll volunteer to document interoperable implementations. So what does it mean to have two independent interoperable implementations of SASL? Here's my concept: We need to demonstrate interoperability of SASL profiles (including optional portions), SASL mechanisms, SASL authorization identity and SASL security layers. So we need to identify at least two clients and two servers for each of the following which provide interoperable authentication via SASL (send me email to volunteer for any of these or for any other protocols): * IMAP -> _____ server [chris.newman@innosoft.com] -> CMU Cyrus server -> CMU Cyrus imtest client -> ESYS Simeon client * LDAPv3 -> _____ server -> _____ server -> _____ client -> _____ client * ACAP -> CMU Cyrus server -> _____ server [chris.newman@innosoft.com] -> _____ client [chris.newman@innosoft.com] -> _____ client * KERBEROS_V4 mechanism (including security layer) -> _____ server -> CMU Cyrus server -> CMU Cyrus imtest client -> _____ client * CRAM-MD5 mechanism -> _____ server -> _____ server [chris.newman@innosoft.com] -> _____ client [chris.newman@innosoft.com] -> _____ client * EXTERNAL mechanism -> _____ server -> _____ server -> _____ client -> _____ client Names in [] are people who intend to participate in an interoperability demonstration. Please volunteer for any of these, including ones which already have volunteers! I propose we drop the SKEY mechanism from the draft status revision -- it should be obsoleted by an OTP mechanism anyway. I propose we split the GSSAPI mechanism into a separate spec, as I think it will be much harder to demonstrate interoperable implementations of it due to its complexity. - Chris From owner-ietf-sasl Thu Jan 15 17:06:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA20497 for ietf-sasl-bks; Thu, 15 Jan 1998 17:06:27 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA20493 for ; Thu, 15 Jan 1998 17:06:23 -0800 (PST) Received: from elwood.innosoft.com ("port 38057"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISEW7FOA2Q94DOQ8@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 15 Jan 1998 17:09:44 PST Date: Thu, 15 Jan 1998 17:11:48 -0800 (PST) From: Chris Newman Subject: re: Call for volunteers: Moving SASL to draft status (fwd) In-reply-to: To: Mark Crispin Cc: IMAP Discusson List , 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 the IMAP list Thu, 15 Jan 1998, Mark Crispin wrote: > I am debugging a GSSAPI SASL mechanism in c-client now. It will probably be > in Pine 4.00. Kerberos 5 is important to us. So, I have a problem with > GSSAPI not being in the base specification. I'd actually like to keep GSSAPI in the base spec, but I don't see that happening. The GSSAPI specs themselves are so huge and complex that I doubt they'll move past proposed anytime in the near future. Holding SASL (and by reference IMAP/ACAP/LDAPv3) at proposed status waiting for GSSAPI to move to draft status is just not reasonable, IMHO. Would it be OK with you if we got the draft standard version of SASL and a recycle at proposed of the GSSAPI mechanism in consecutive RFCs? That would allow us to fix any bugs in the GSSAPI mechanism. > The main problem with the GSSAPI mechanism is that it is inadequately > specified. I don't want to say too much yet, since I'm not sure that my > understanding is 100% correct. I believe the problem is the basic GSSAPI assumption that the client and server have the same mechanism "active." This assumption fails in practice and thus breaks interoperability. I can see two ways to fix this: (1) wait for SNEGO to go proposed and make that part of the GSSAPI mechanism. (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms which are specific interoperable profiles of GSSAPI mechanisms. Does this match your understanding? - Chris From owner-ietf-sasl Thu Jan 15 17:10:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA20566 for ietf-sasl-bks; Thu, 15 Jan 1998 17:10:09 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA20560 for ; Thu, 15 Jan 1998 17:10:04 -0800 (PST) Received: (qmail 17499 invoked from network); 16 Jan 1998 01:07:42 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 16 Jan 1998 01:07:42 -0000 X-Mailer: exmh version 2.0.1 12/23/97 From: Mark Wahl To: Chris Newman cc: Mark Wahl , ietf-sasl@imc.org Subject: Re: SASL & UTF8 In-reply-to: Your message of "Thu, 15 Jan 1998 09:34:15 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jan 1998 19:07:41 -0600 Message-ID: <17497.884912861@folder.critical-angle.com> Sender: owner-ietf-sasl@imc.org Precedence: bulk I am not sure that requiring UTF-8 for passphrases would necessarily belong in the SASL definition itself, given that not all mechanisms use passphrases. However, I think its document might suggest the use of UTF-8 when passphrases are used, w/o requiring it to recycle to PS, since this suggestion does not affect existing deployed/documented mechanisms. Were the CRAM-MD5 and other documents to require UTF-8 for name and password, then they would need to recycle. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-sasl Thu Jan 15 17:11:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA20584 for ietf-sasl-bks; Thu, 15 Jan 1998 17:11:41 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA20580 for ; Thu, 15 Jan 1998 17:11:37 -0800 (PST) Received: (qmail 17508 invoked from network); 16 Jan 1998 01:09:21 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 16 Jan 1998 01:09:21 -0000 X-Mailer: exmh version 2.0.1 12/23/97 From: Mark Wahl To: Chris Newman cc: ietf-sasl@imc.org Subject: Re: Call for volunteers: Moving SASL to draft status In-reply-to: Your message of "Thu, 15 Jan 1998 10:30:01 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jan 1998 19:09:20 -0600 Message-ID: <17506.884912960@folder.critical-angle.com> Sender: owner-ietf-sasl@imc.org Precedence: bulk > So we need to identify at least two clients and two > servers for each of the following which provide interoperable > authentication via SASL (send me email to volunteer for any of these or > for any other protocols): The Critical Angle LDAPv3 Client Library and Standalone Directory Server support negotiation via SASL of the CRAM-MD5 mechanism as described for use in LDAPv3. They also support negotiation via SASL of the EXTERNAL mechanism when Start TLS has been used to negotiate SSL 3.0 with client authentication. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-sasl Thu Jan 15 17:14:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA20619 for ietf-sasl-bks; Thu, 15 Jan 1998 17:14:05 -0800 (PST) Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA20615 for ; Thu, 15 Jan 1998 17:14:01 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (john@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.cac.washington.edu (8.8.4+UW97.07/8.8.4+UW97.11) with SMTP id RAA01542; Thu, 15 Jan 1998 17:18:21 -0800 Date: Thu, 15 Jan 1998 17:15:01 -0800 (PST) From: Mark Crispin Subject: re: Call for volunteers: Moving SASL to draft status (fwd) To: Chris Newman cc: IMAP Discusson List , 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 Chris - > (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms > which are specific interoperable profiles of GSSAPI mechanisms. It would be quite acceptable -- and probably extremely desirable -- to do this. I am assuming two things: it allows Kerberos 5 to remain part of the base SASL specification, and it blesses implementations that implement GSSAPI only for Kerberos 5. If you decide to do this, please do so immediately, because I plan to release an imap-4.1 toolkit with GSSAPI to the world imminently. From owner-ietf-sasl Fri Jan 16 06:53:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA19577 for ietf-sasl-bks; Fri, 16 Jan 1998 06:53:53 -0800 (PST) Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA19571 for ; Fri, 16 Jan 1998 06:53:49 -0800 (PST) Received: from localhost (ses@localhost) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id JAA09685; Fri, 16 Jan 1998 09:58:08 -0500 Date: Fri, 16 Jan 1998 09:58:08 -0500 (EST) From: Simon Spero To: Chris Newman cc: Mark Crispin , IMAP Discusson List , ietf-sasl@imc.org Subject: re: Call for volunteers: Moving SASL to draft status (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk I've actually heard requests for a raw K5 profile cloned as much as possible from the K4 one. BTW, I've done a K4 IMAP-> Cyrus in C; authentication only though for legal reasons I'm supposed to do one in java but that may not be done before the IETF. Simon Now available - The Freddy Hayek Kayak | "Pass me another elf Paddle Your Own Canoe! Be Rowed To Surfdom! | Sergeant- this one's >From The Taco Institute for Dyslexic Libertarians | split" Moments ago I had everything. Now, there's a cow in my nose - La Salla From owner-ietf-sasl Fri Jan 16 09:19:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA22969 for ietf-sasl-bks; Fri, 16 Jan 1998 09:19:57 -0800 (PST) Received: from rembrandt.esys.ca (0@rembrandt.esys.ca [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA22965 for ; Fri, 16 Jan 1998 09:19:53 -0800 (PST) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id KAA32008; Fri, 16 Jan 1998 10:24:16 -0700 From: Steve Hole Date: Fri, 16 Jan 1998 10:24:07 -0700 To: Chris Newman Subject: Re: Call for volunteers: Moving SASL to draft status Cc: ietf-sasl@imc.org In-Reply-To: References: Message-ID: X-Mailer: Simeon for Win32 Version Mercury a6 Build (6) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk On Thu, 15 Jan 1998 10:30:01 -0800 (PST) Chris Newman wrote: > By IETF procedure, it will be possible to move SASL to draft status in > April. In order to make it that soon, we need to complete some work in > the next 3 months to identify interoperable implementations. (Personally, > I'd like to see SASL become the first IETF standard security protocol > other than APOP). > > IETF procedure gives the WG chair responsibility to document interoperable > implementations. As SASL was an individual submission by John Myers, I'll > volunteer to document interoperable implementations. > > So what does it mean to have two independent interoperable implementations > of SASL? > > Here's my concept: > > We need to demonstrate interoperability of SASL profiles (including > optional portions), SASL mechanisms, SASL authorization identity and SASL > security layers. So we need to identify at least two clients and two > servers for each of the following which provide interoperable > authentication via SASL (send me email to volunteer for any of these or > for any other protocols): > * IMAP > -> _____ server [chris.newman@innosoft.com] > -> CMU Cyrus server > -> CMU Cyrus imtest client > -> ESYS Simeon client [steve.hole@esys.ca] > * LDAPv3 > -> _____ server > -> _____ server > -> _____ client > -> _____ client > * ACAP > -> CMU Cyrus server > -> _____ server [chris.newman@innosoft.com] > -> _____ client [chris.newman@innosoft.com] > -> ESYS Simeon client [steve.hole@esys.ca] (IMSP now, ACAP in development) * SMTP -> _____ server -> _____ server -> Esys Simeon Client [steve.hole@esys.ca] -> _____ client Hmm ... something to think about Chris. We implement all of the above protocols with the same SASL infrastructure. I'm sure that most multiprotocol clients will do it that way. I'm not sure how this "qualifies". > * KERBEROS_V4 mechanism (including security layer) > -> _____ server > -> CMU Cyrus server > -> CMU Cyrus imtest client > -> Esys Simeon client [steve.hole@esys.ca] > * CRAM-MD5 mechanism > -> _____ server > -> _____ server [chris.newman@innosoft.com] > -> _____ client [chris.newman@innosoft.com] > -> Esys Simeon client [steve.hole@esys.ca] > * EXTERNAL mechanism > -> _____ server > -> _____ server > -> _____ client > -> _____ client Not sure what you mean by EXTERNAL mechanism Chris. Is this for the "plugin" stuff that we talked about in relationship to the API? The Simeon clients and servers support 3 more mechanisms not listed here, with a couple of others in experimental development. How do they fit? > Names in [] are people who intend to participate in an interoperability > demonstration. Please volunteer for any of these, including ones which > already have volunteers! > > I propose we drop the SKEY mechanism from the draft status revision -- it > should be obsoleted by an OTP mechanism anyway. I propose we split the > GSSAPI mechanism into a separate spec, as I think it will be much harder > to demonstrate interoperable implementations of it due to its complexity. I mostly concur. SKEY should be replaced with an OTP version. GSSAPI is the most difficult to implement, but not by order of magnitudes or anything. The biggest problem is the differences between GSSAPI v1 and v2, and implementors playing fast and loose with mandatory GSSAPI "extensions". These are interoperability problems in GSSAPI, not in SASL though. I would recommend splitting each of the mechanism definitions into separate documents, all subsidiary to a framework and mechanism registration document. --- Steve From owner-ietf-sasl Fri Jan 16 10:02:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23791 for ietf-sasl-bks; Fri, 16 Jan 1998 10:02:19 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23787 for ; Fri, 16 Jan 1998 10:02:14 -0800 (PST) Received: from elwood.innosoft.com ("port 38086"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISFVOIOGPS94DOQ8@INNOSOFT.COM> for ietf-sasl@imc.org; Fri, 16 Jan 1998 10:06:03 PST Date: Fri, 16 Jan 1998 10:08:05 -0800 (PST) From: Chris Newman Subject: Re: Call for volunteers: Moving SASL to draft status In-reply-to: To: Steve Hole Cc: 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 Fri, 16 Jan 1998, Steve Hole wrote: > Hmm ... something to think about Chris. We implement all of the above > protocols with the same SASL infrastructure. I'm sure that most > multiprotocol clients will do it that way. I'm not sure how this > "qualifies". I don't see that as a problem. The point of testing SASL profiles is to make sure that if a profile follows the rules it will interoperate. > Not sure what you mean by EXTERNAL mechanism Chris. Is this for the > "plugin" stuff that we talked about in relationship to the API? The > Simeon clients and servers support 3 more mechanisms not listed here, > with a couple of others in experimental development. How do they fit? Nope. The "EXTERNAL" mechanism in section 7.4 of RFC 2222. > I would recommend splitting each of the mechanism definitions into separate > documents, all subsidiary to a framework and mechanism registration document. I'd like to see KERBEROS_V4 and EXTERNAL remain in the SASL base spec, if possible. I don't see how we can keep GSSAPI in the SASL base spec at draft status since GSSAPI has interoperability problems so it's stuck at proposed status. - Chris From owner-ietf-sasl Fri Jan 16 10:15:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA24078 for ietf-sasl-bks; Fri, 16 Jan 1998 10:15:50 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA24072 for ; Fri, 16 Jan 1998 10:15:43 -0800 (PST) Received: from elwood.innosoft.com ("port 38094"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISFW6A2RVK94DOQ8@INNOSOFT.COM> for ietf-sasl@imc.org; Fri, 16 Jan 1998 10:19:35 PST Date: Fri, 16 Jan 1998 10:21:39 -0800 (PST) From: Chris Newman Subject: re: Call for volunteers: Moving SASL to draft status (fwd) In-reply-to: To: Simon Spero Cc: 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 [recipient list trimmed] On Fri, 16 Jan 1998, Simon Spero wrote: > I've actually heard requests for a raw K5 profile cloned as much as > possible from the K4 one. Since we already have a defined way to do K5 in SASL, it would require a *strong* justification to create a new one. If you can convince Jeff Schiller that it's a good idea to remove GSSAPI from the K5 picture, then I'll go along. > BTW, I've done a K4 IMAP-> Cyrus in C; authentication only though for > legal reasons I'm supposed to do one in java but that may not be done > before the IETF. So you did an independent implementation of the SASL KERBEROS_V4 mechanism in an IMAP client and are willing to interoperability test? (using the Cyrus lib for SASL in the a client wouldn't be independent). Well it'd be nice to do testing in the IETF terminal room, we may have to do some over the net later. - Chris From owner-ietf-sasl Mon Jan 26 11:07:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA08775 for ietf-sasl-bks; Mon, 26 Jan 1998 11:07:34 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA08771 for ; Mon, 26 Jan 1998 11:07:30 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA03062 for ; Mon, 26 Jan 1998 11:11:56 -0800 (PST) Received: from netscape.com ([205.217.229.208]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA29077 for ; Mon, 26 Jan 1998 11:11:54 -0800 Message-ID: <34CCDFFC.E8472473@netscape.com> Date: Mon, 26 Jan 1998 11:11:56 -0800 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: SASL & UTF8 References: <12777.884810792@folder.critical-angle.com> <3.0.5.32.19980125103618.00b79dc0@dokka.kvatro.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk Harald Tveit Alvestrand wrote: > > At 14:03 23.01.98 -0800, John Gardiner Myers wrote: > >We should crib from the charset policy. How about: > > > >All mechanisms MUST identify, for all character data, which charset > >is in use. Any field containing an authorization id MUST encode that > >field using the UTF-8 charset [UTF-8]. Other fields containing text > >SHOULD encode that text using the UTF-8 charset. > > > >This standard does not itself require mechanism implementations to be > >able to generate or accept arbitrary UTF-8 characters. > > > > seems OK with me - except that I want to clarify that this is for the > case where an "authorization ID" is text. The intent is that when the "authorization ID" exists, it is always text. The main SASL document does need more clarification about the authorization ID and its use. > And: we DO have a requirement to ACCEPT arbitrary UTF-8 characters, at > least to the point where you can say authoritatively that this authid > does NOT match any valid authid; "blowing up is not acceptable". This standard does not itself require mechanism implementations to be able to generate or grant access to identities containing arbitrary UTF-8 characters. From owner-ietf-sasl Mon Jan 26 11:28:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA09042 for ietf-sasl-bks; Mon, 26 Jan 1998 11:28:05 -0800 (PST) Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA09038 for ; Mon, 26 Jan 1998 11:28:02 -0800 (PST) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id LAA20029 for <@starfish.mcom.com:ietf-sasl@imc.org>; Mon, 26 Jan 1998 11:32:28 -0800 (PST) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA18552 for ; Mon, 26 Jan 1998 11:35:41 -0800 To: ietf-sasl@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-sasl Subject: Re: Call for volunteers: Moving SASL to draft status (fwd) Date: Mon, 26 Jan 1998 11:32:27 -0800 Organization: Netscape Communications Corporation Lines: 27 Message-ID: <34CCE4CB.F63C2E6C@netscape.com> References: <34C931C4.55BCF8FD@netscape.com> <199801261715.KAA01953@rembrandt.esys.ca> NNTP-Posting-Host: 205.217.229.208 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.03 [en] (WinNT; U) Sender: owner-ietf-sasl@imc.org Precedence: bulk Steve Hole wrote: > > Hang on a minute. The issue is that a client and server GSSAPI will > not interoperate if they implement different underlying mechanisms. If > so then: (1) this will probably not happen often in practise because > the authentication infrastructure an organization uses is usually controlled > by the organization and I'm not sure this is entirely true. Organizations may control their infrastructure, but they don't necessarily control what is included in the deployed software. > (2) if it does happen, then authentication fails for a > valid reason. Let's take an example: the client supports both Kerberos v5 under GSSAPI and Kerberos v5 under SNEGO under GSSAPI. The server is older and supports Kerberos v5 under GSSAPI, but doesn't support SNEGO. If the organization has a Kerberos V5 infrastructure set up, the client can still send either Kerberos v5 under GSSAPI or Kerberos v5 under SNEGO under GSSAPI. If it sends the latter, authentication fails, but this is not due to any policy reason. The client can always fall back, but this was true before we put in server advertisement of SASL mechanisms anyway. We've simply gotten rid of the benefit of having servers advertise available mechanisms. From owner-ietf-sasl Wed Jan 28 06:55:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA29452 for ietf-sasl-bks; Wed, 28 Jan 1998 06:55:52 -0800 (PST) Received: from dokka.kvatro.no (dokka.kvatro.no [193.216.2.164]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA29446 for ; Wed, 28 Jan 1998 06:55:45 -0800 (PST) Received: from alden (alvestrand.kvatro.no [193.216.167.143]) by dokka.kvatro.no (8.8.5/8.8.5) with SMTP id QAA08617 for ; Wed, 28 Jan 1998 16:00:24 +0100 Message-Id: <3.0.5.32.19980128154652.00995280@dokka.kvatro.no> X-Sender: hta@dokka.kvatro.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 28 Jan 1998 15:46:52 +0100 To: ietf-sasl@imc.org From: Harald Tveit Alvestrand Subject: key generation from passphrase, UTF-8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk I stumbled across the enclosed text in RFC 1890. Is this something we need to take into consideration in SASL (as in "bless, curse or negotiate")? Harald The pass phrase typed by the user is transformed to a canonical form before applying the hash algorithm. For that purpose, we define return, tab, or vertical tab as well as all characters contained in the Unicode space characters table. The transformation consists of the following steps: (1) convert the input string to the ISO 10646 character set, using the UTF-8 encoding as specified in Annex P to ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO 8859-1 characters do); (2) remove leading and trailing white space characters; (3) replace one or more contiguous white space characters by a single space (ASCII or UTF-8 0x20); (4) convert all letters to lower case and replace sequences of characters and non-spacing accents with a single character, where possible. A minimum length of 16 key characters (after applying the transformation) should be enforced by the application, while applications must allow up to 256 characters of input. NOTE: New Email address: Harald.Alvestrand@maxware.no I am working for Maxware (www.maxware.no) as of Dec 1, 1997 From owner-ietf-sasl Wed Jan 28 09:44:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA00975 for ietf-sasl-bks; Wed, 28 Jan 1998 09:44:40 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA00971 for ; Wed, 28 Jan 1998 09:44:37 -0800 (PST) Received: from elwood.innosoft.com ("port 50665"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ISWMKRX8NC9AMG6B@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 28 Jan 1998 09:48:25 PST Date: Wed, 28 Jan 1998 09:50:25 -0800 (PST) From: Chris Newman Subject: Re: key generation from passphrase, UTF-8 In-reply-to: <3.0.5.32.19980128154652.00995280@dokka.kvatro.no> To: Harald Tveit Alvestrand Cc: 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 Wed, 28 Jan 1998, Harald Tveit Alvestrand wrote: > the Unicode space characters table. The transformation consists of > the following steps: (1) convert the input string to the ISO 10646 > character set, using the UTF-8 encoding as specified in Annex P to > ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO > 8859-1 characters do); This is the only part I agree with. I'd also add that use of NUL is forbidden and use of non-printing characters is discouraged. > (2) remove leading and trailing white space > characters; (3) replace one or more contiguous white space characters > by a single space (ASCII or UTF-8 0x20); (4) convert all letters to > lower case and replace sequences of characters and non-spacing > accents with a single character, where possible. A minimum length of > 16 key characters (after applying the transformation) should be > enforced by the application, while applications must allow up to 256 > characters of input. These are all bad ideas, IMHO. When you go to 10646, it's very hard to determine if something is a spacing character or a lower/upper case letter. What happens when a new character is added with a critical property you don't know about? In addition, multiple spaces and mixed case are good techniques to make a pass phrase harder to guess and to defeat dictionary attacks. Finally, this may not be implementable without using Unicode in addition to 10646 -- I'm not sure 10646 lists spacing and case properties of characters. - Chris From owner-ietf-sasl Wed Jan 28 10:05:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA01138 for ietf-sasl-bks; Wed, 28 Jan 1998 10:05:37 -0800 (PST) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA01134 for ; Wed, 28 Jan 1998 10:05:33 -0800 (PST) Received: by DOGGATE with Internet Mail Service (5.5.1960.3) id ; Wed, 28 Jan 1998 10:10:40 -0800 Message-ID: <2FBF98FC7852CF11912A00000000000106DD52DC@DINO> From: "Larry Osterman (Exchange)" To: "'Chris Newman'" , Harald Tveit Alvestrand Cc: ietf-sasl@imc.org Subject: RE: key generation from passphrase, UTF-8 Date: Wed, 28 Jan 1998 10:10:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-sasl@imc.org Precedence: bulk Doesn't this canonicalization also mean that dictionary attacks are significantly easier? After all this removes multiple spaces and upper case letters from the keyspace. Yes there is a 16 character recommended minimum key length, but since the new key space only has lower case characters and punctuation characters in it, it's significantly smaller than the original keyspace Larry Osterman Via Exchange 5.5 on Larryo-Laptop.dns.microsoft.com. Please notify the sender of any difficulties. -----Original Message----- From: Chris Newman [mailto:Chris.Newman@INNOSOFT.COM] Sent: Wednesday, January 28, 1998 9:50 AM To: Harald Tveit Alvestrand Cc: ietf-sasl@imc.org Subject: Re: key generation from passphrase, UTF-8 On Wed, 28 Jan 1998, Harald Tveit Alvestrand wrote: > the Unicode space characters table. The transformation consists of > the following steps: (1) convert the input string to the ISO 10646 > character set, using the UTF-8 encoding as specified in Annex P to > ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO > 8859-1 characters do); This is the only part I agree with. I'd also add that use of NUL is forbidden and use of non-printing characters is discouraged. > (2) remove leading and trailing white space > characters; (3) replace one or more contiguous white space characters > by a single space (ASCII or UTF-8 0x20); (4) convert all letters to > lower case and replace sequences of characters and non-spacing > accents with a single character, where possible. A minimum length of > 16 key characters (after applying the transformation) should be > enforced by the application, while applications must allow up to 256 > characters of input. These are all bad ideas, IMHO. When you go to 10646, it's very hard to determine if something is a spacing character or a lower/upper case letter. What happens when a new character is added with a critical property you don't know about? In addition, multiple spaces and mixed case are good techniques to make a pass phrase harder to guess and to defeat dictionary attacks. Finally, this may not be implementable without using Unicode in addition to 10646 -- I'm not sure 10646 lists spacing and case properties of characters. - Chris From owner-ietf-sasl Wed Jan 28 12:30:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA02377 for ietf-sasl-bks; Wed, 28 Jan 1998 12:30:12 -0800 (PST) Received: from rembrandt.esys.ca (0@rembrandt.esys.ca [198.161.92.18]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA02373 for ; Wed, 28 Jan 1998 12:30:08 -0800 (PST) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id NAA04888; Wed, 28 Jan 1998 13:34:55 -0700 From: Steve Hole Date: Wed, 28 Jan 1998 13:34:33 -0700 To: Harald Tveit Alvestrand Subject: Re: key generation from passphrase, UTF-8 Cc: ietf-sasl@imc.org In-Reply-To: <3.0.5.32.19980128154652.00995280@dokka.kvatro.no> References: <3.0.5.32.19980128154652.00995280@dokka.kvatro.no> Message-ID: X-Mailer: Simeon for Win32 Version Mercury a6 Build (7) MIME-Version: 1.0 Content-Type: Text/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-sasl@imc.org Precedence: bulk On Wed, 28 Jan 1998 15:46:52 +0100 Harald Tveit Alvestrand wrote: > (2) remove leading and trailing white space > characters; (3) replace one or more contiguous white space characters > by a single space (ASCII or UTF-8 0x20); (4) convert all letters to > lower case and replace sequences of characters and non-spacing > accents with a single character, where possible. A minimum length of > 16 key characters (after applying the transformation) should be > enforced by the application, while applications must allow up to 256 > characters of input. I don't know about anyone else, but this seems like a horribly bad idea to me. Because you have translated into 10646, how do you determine what is uppercase and whitespace? Also removing this information will make the space easier to search in a dictionary attack -- a little counter productive I would think. In fact, if I found out that and algorithm was mangling my carefully selected password in such a way that it made it easier to brute force, I would be quite upset. Cheers. --- Steve From owner-ietf-sasl Sat Jan 31 04:32:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA22861 for ietf-sasl-bks; Sat, 31 Jan 1998 04:32:48 -0800 (PST) Received: from ns.owlseye.com (owl@ns.owlseye.com [199.173.193.212]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id EAA22838 for ; Sat, 31 Jan 1998 04:32:40 -0800 (PST) Received: (from owl@localhost) by ns.owlseye.com (8.8.8/8.7.3) id HAA14181; Sat, 31 Jan 1998 07:20:07 -0500 (EST) Date: Sat, 31 Jan 1998 07:20:07 -0500 (EST) Message-Id: <199801311220.HAA14181@ns.owlseye.com> From: owl@owlseye.com To: ietf-sasl@imc.org Reply-To: owl@owlseye.com Subject: OK to send e-mail? Sender: owner-ietf-sasl@imc.org Precedence: bulk OK to send an e-mail to ietf-sasl@imc.org? From owner-ietf-sasl Mon Feb 2 10:23:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA19620 for ietf-sasl-bks; Mon, 2 Feb 1998 10:23:40 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA19616 for ; Mon, 2 Feb 1998 10:23:27 -0800 (PST) Received: from elwood.innosoft.com ("port 56081"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IT3NEAJF369AMM6N@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 2 Feb 1998 10:27:45 PST Date: Mon, 02 Feb 1998 10:29:45 -0800 (PST) From: Chris Newman Subject: Re: Call for volunteers: Moving SASL to draft status (fwd) In-reply-to: <199801261715.KAA01953@rembrandt.esys.ca> To: Steve Hole Cc: ietf-acap+@andrew.cmu.edu, 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, 26 Jan 1998, Steve Hole wrote: > On Fri, 23 Jan 1998 16:11:48 -0800 John Gardiner Myers > wrote: > > (2) sounds like a very good idea. GSSAPI mechanism implementations > > which use different underlying GSSAPI mechanisms won't interoperate. > > Defining a separate SASL mechanism for each underlying GSSAPI mechanism > > will allow this to be negotiated at the SASL layer. > > > > When SNEGO finally arrives, we can have GSSAPI-SNEGO. I don't think > > GSSAPI-using-Kerb5 interoperates with GSSAPI-using-SNEGO-using-Kerb5 > > anyway, so having a GSSAPI-SNEGO which can negotiate Kerb5 be separate > > from GSSAPI-Kerb5 is a good thing. > > > > We can either define a new GSS-KERB5 only if we act quickly, otherwise > > we'd have to declare that the name GSSAPI refers to GSSAPI using > > Kerberos V5. > > > > Do we have a quick consensus to change this? > > Hang on a minute. The issue is that a client and server GSSAPI will > not interoperate if they implement different underlying mechanisms. If > so then: (1) this will probably not happen often in practise because > the authentication infrastructure an organization uses is usually controlled > by the organization and (2) if it does happen, then authentication fails for a > valid reason. The reason I proposed this change initially is that I dislike multi-level negotiations. Suppose you have a GSSAPI client which supports both Kerberos-5 and public key? When you try Kerberos-5 and it fails with invalid messages for the Kerberos-5 GSSAPI mechanism, do you retry GSSAPI to see if the server is using the public key or do you fall back to a different SASL mechanism since GSSAPI failed? It makes the code more complicated to deal with cases like this. > I am not totally set in this position. The GSSAPI thing is messy. I just > wish that we had some more experience with it before we start mucking about > this way. At this time I don't really see all that big a win in doing this, > but that could very well change in the near future as we try to deploy our > implementation. If we wait, I suspect GSSAPI will mean "Kerberos 5 GSSAPI mechanism." That will only cause problems for GSSAPI mechanisms other than Kerb5. - Chris From owner-ietf-sasl Mon Feb 2 10:35:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA19738 for ietf-sasl-bks; Mon, 2 Feb 1998 10:35:04 -0800 (PST) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.8/8.7.3) with SMTP id KAA19731 for ; Mon, 2 Feb 1998 10:35:01 -0800 (PST) Received: by DOGGATE with Internet Mail Service (5.5.1960.3) id <1FG7K2SA>; Mon, 2 Feb 1998 10:40:42 -0800 Message-ID: <2FBF98FC7852CF11912A00000000000106DD5316@DINO> From: "Larry Osterman (Exchange)" To: ietf-sasl@imc.org Subject: RE: OK to send e-mail? Date: Mon, 2 Feb 1998 10:20:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-sasl@imc.org Precedence: bulk Oh great - spamboy is hitting SASL now.... Larry Osterman Via Exchange 5.5 on Larryo-Laptop.dns.microsoft.com. Please notify the sender of any difficulties. -----Original Message----- From: owl@owlseye.com [mailto:owl@owlseye.com] Sent: Saturday, January 31, 1998 4:20 AM To: ietf-sasl@imc.org Subject: OK to send e-mail? OK to send an e-mail to ietf-sasl@imc.org? From owner-ietf-sasl Mon Feb 2 12:14:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA20668 for ietf-sasl-bks; Mon, 2 Feb 1998 12:14:27 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (alan@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA20664 for ; Mon, 2 Feb 1998 12:14:21 -0800 (PST) Date: Mon, 2 Feb 1998 12:06:30 -0800 (PST) From: Mark Crispin Subject: Re: Call for volunteers: Moving SASL to draft status (fwd) To: Chris Newman cc: Steve Hole , ietf-acap+@andrew.cmu.edu, 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 On Mon, 02 Feb 1998 10:29:45 -0800 (PST), Chris Newman wrote: > On Mon, 26 Jan 1998, Steve Hole wrote: > > Hang on a minute. The issue is that a client and server GSSAPI will > > not interoperate if they implement different underlying mechanisms. If > > so then: (1) this will probably not happen often in practise because > > the authentication infrastructure an organization uses is usually > > controlled by the organization and (2) if it does happen, then > > authentication fails for a valid reason. This seems to be based on the notion that this can be configured in the application (client and server) by the organization. I don't think that this is a valid assumption. GSSAPI is not like c-client, which carefully keeps the application at a distance from its drivers. GSSAPI only takes you so far, then you start having to have knowledge about the actual authentication infrastructure. Think in terms of a world where most people do not build their own binaries. Both my client and (especially!) server code have K5 knowledge. The client code may function with something other than K5, although you would definitely have to rebuild and the error handling won't be right without source code changes. The server code will definitely not function without source code changes. My code isn't the only offender, either. > If we wait, I suspect GSSAPI will mean "Kerberos 5 GSSAPI mechanism." > That will only cause problems for GSSAPI mechanisms other than Kerb5. This has already happened. It's too late to prevent it. It isn't too late to get the responsible parties to transition to a different name for "Kerberos 5 GSSAPI mechanism" but time is rapidly running out. From owner-ietf-sasl Thu Feb 12 15:27:01 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA21601 for ietf-sasl-bks; Thu, 12 Feb 1998 15:27:01 -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 PAA21596 for ; Thu, 12 Feb 1998 15:26:56 -0800 (PST) Received: from elwood.innosoft.com ("port 60973"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01ITHWYGHIA49AN1ZX@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 12 Feb 1998 15:32:24 PST Date: Thu, 12 Feb 1998 15:34:21 -0800 (PST) From: Chris Newman Subject: LDAP service name To: IETF LDAP Extensions WG Cc: ietf-sasl@imc.org Reply-to: IETF LDAP Extensions WG 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 Profiling requirement 1 of the SASL specification (RFC 2222, section 4) does not seem to be met by the current LDAP SASL profile. In particular, you need to specify a service name for use with ldap and register it with IANA at the GSSAPI service registry: The concept of a "service name" is used by GSSAPI, SASL, Kerberos and SCRAM-MD5. When different services have different security risks, it's important that the server-side credentials are managed on a per-service basis. In addition, users occasionally want different passwords for different services and the service name creates the distinction. You might also want to use "host" as a fallback service name if the ldap service name isn't available. This what ftp security does (RFC 2228, appendix I). - Chris From owner-ietf-sasl Tue Feb 17 20:08:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA08546 for ietf-sasl-bks; Tue, 17 Feb 1998 20:08:26 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA08542 for ; Tue, 17 Feb 1998 20:08:22 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id UAA01372 for ; Tue, 17 Feb 1998 20:06:17 -0800 (PST) Received: from netscape.com ([205.217.229.78]) by dredd.mcom.com (Netscape Messaging Server 3.5) with ESMTP id AAA40EC; Tue, 17 Feb 1998 20:06:17 -0800 Message-ID: <34EA5E39.35FFBB3F@netscape.com> Date: Tue, 17 Feb 1998 20:06:17 -0800 From: "John Myers" X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: IETF LDAP Extensions WG , ietf-sasl@imc.org Subject: Re: LDAP service name References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris Newman wrote: > You might also want to use "host" as a fallback service name if the ldap > service name isn't available. This what ftp security does (RFC 2228, > appendix I). No other SASL profile specifies a fallback service name, and I would strenuously recommend against LDAP doing so. FTP security does not use SASL, and it is thus not a relevant example. A protocol's profile of SASL is too high a layer to specify "host" service fallback. Specifying service name fallback at this layer will cause SASL mechanisms which ignore the profile's service name to be attempted twice, possibly with repeated user interaction, whenever authentication using that mechanism fails. The correct place to put this fallback is in the Kerberos KDC and the part of the Kerberos library that obtains the servers private key. Given that Kerberos implementations have botched this and the next layer up (GSSAPI) has ignored this issue, the next best layer to address this is with a SASL mechanism. Define a new SASL mechanism with a new name which is identical to the current GSSAPI mechanism except in that it ignores the protocol profile's service name and passes the fixed string "host" down to GSSAPI. From owner-ietf-sasl Sun Mar 29 22:45:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA06097 for ietf-sasl-bks; Sun, 29 Mar 1998 22:45:11 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA06088 for ; Sun, 29 Mar 1998 22:45:10 -0800 (PST) Received: from elwood.innosoft.com ("port 59942"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IV975P2QIU984K19@INNOSOFT.COM> for ietf-sasl@imc.org; Sun, 29 Mar 1998 22:44:29 PST Date: Sun, 29 Mar 1998 22:46:14 -0800 (PST) From: Chris Newman Subject: Interoperability testing 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 I've set up an IMAP and POP server for SASL testing. Hostname: elwood.innosoft.com POP port #: 1100 IMAP port #: 1430 User name password tim tanstaaftanstaaf full name secret stuff Mechanisms: PLAIN CRAM-MD5 SCRAM-MD5 PASSDSS-3DES-1 I plan to leave this running during the week of the IETF. Please send me email if you interoperability test against it. - Chris From owner-ietf-sasl Wed Apr 29 18:08:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA20503 for ietf-sasl-bks; Wed, 29 Apr 1998 18:08:39 -0700 (PDT) Received: from planet-zorp.MIT.EDU (PLANET-ZORP.MIT.EDU [18.70.0.60]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA20499 for ; Wed, 29 Apr 1998 18:08:38 -0700 (PDT) Received: (from marc@localhost) by planet-zorp.MIT.EDU (8.7.5/8.6.12) id VAA19804; Wed, 29 Apr 1998 21:10:33 -0400 (EDT) Message-Id: <199804300110.VAA19804@planet-zorp.MIT.EDU> To: ietf-sasl@imc.org Subject: GSSAPI and SASL Date: Wed, 29 Apr 1998 21:10:33 EDT From: Marc Horowitz Sender: owner-ietf-sasl@imc.org Precedence: bulk I've recently become aware of a possible change to SASL which I think would be a serious mistake. I'm going to base my arguments on rfc2222 (since I don't see a more recent draft), and on the archives I downloaded from imc.org. From: Chris Newman Date: Thu, 15 Jan 1998 17:11:48 -0800 (PST) >> I believe the problem is the basic GSSAPI assumption that the client and >> server have the same mechanism "active." This assumption fails in >> practice and thus breaks interoperability. I can see two ways to fix >> this: (1) wait for SNEGO to go proposed and make that part of the GSSAPI >> mechanism. (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms >> which are specific interoperable profiles of GSSAPI mechanisms. From: Mark Crispin Date: Thu, 15 Jan 1998 17:15:01 -0800 (PST) >> > (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms >> > which are specific interoperable profiles of GSSAPI mechanisms. >> >> It would be quite acceptable -- and probably extremely desirable -- to >> do this. I am assuming two things: it allows Kerberos 5 to remain >> part of the base SASL specification, and it blesses implementations >> that implement GSSAPI only for Kerberos 5. I think it would be a tremendous mistake to separate out the GSSAPI mechanisms this way. One of the ideas behind the GSSAPI is that applications which use it do not need to have any understanding of the underlying security mechanism which is being used. The SPNEGO mechanism allows peers to negotiate a common mechanism without requiring that this process be exposed to the caller. At least wrt authentication, there is no reason for any specific knowledge to be exposed. John Meyers makes a good point later: From: John Gardiner Myers Date: Mon, 26 Jan 1998 11:32:27 -0800 >> Let's take an example: the client supports both Kerberos v5 under GSSAPI >> and Kerberos v5 under SNEGO under GSSAPI. The server is older and >> supports Kerberos v5 under GSSAPI, but doesn't support SNEGO. >> >> If the organization has a Kerberos V5 infrastructure set up, the client >> can still send either Kerberos v5 under GSSAPI or Kerberos v5 under >> SNEGO under GSSAPI. If it sends the latter, authentication fails, but >> this is not due to any policy reason. Looking at the IMAP and SASL specifications, there's no single mandatory required authentication mechanism, so there's no guarantee of interoperability, there, either. (Where are {S,}CRAM-MD5 defined, anyway?) However, this problem can be solved. IMAP could require that a particular SASL mech be implemented, and it could also require certain behavior of the GSSAPI mech if it exists. Given the unlikelyhood of a server which supports multiple mechanisms but not SPNEGO, IMAP (and other protocols) could require this: request SPNEGO, and if the acceptor doesn't recognize the mechanism, then fall back to a "real" mechanism. It is reasonable to expect SPNEGO will get deployed widely, so this won't be necessary except for new clients talking to older servers, which will also get upgraded relatively quickly, one would think. In any case, a client should be prepared to fall back, because regardless of how cleverly the server constructs the list of mechanisms it supports, the actual process can still fail. Another mechanism might succeed, and it would be nice if the client tried it. This does require a bit of extra work now, but in the long run, it will be worth it. People may want krb5 now, but in a year, they'll be asking for SPKI, or whatever, and it would be nice to have a clean migration path. I also think that putting GSSAPI in a separate document would be a good idea. Otherwise, it cannot progress to Draft Standard, since GSSAPI isn't there yet, and this gives us some time to come to consensus on the GSSAPI issues. From: Mark Crispin Date: Mon, 2 Feb 1998 12:06:30 -0800 (PST) >> GSSAPI is not like c-client, which carefully keeps the application at >> a distance from its drivers. GSSAPI only takes you so far, then you >> start having to have knowledge about the actual authentication >> infrastructure. >> >> Think in terms of a world where most people do not build their own >> binaries. >> >> Both my client and (especially!) server code have K5 knowledge. The >> client code may function with something other than K5, although you >> would definitely have to rebuild and the error handling won't be right >> without source code changes. The server code will definitely not >> function without source code changes. This is simply not true. SAP has a server/client infrastructure which is *completely* independent of the particulars of the underlying mechanism. In fact, they don't plan on shipping the GSSAPI mechanism at all, for export reasons. All they require is a proper mechanism in a shared lib (unix) or DLL (windows). SASL can do this, too, you just need to decide you want to. If you have questions (which is entirely understandable, given the state of the documentation), please ask for help; you'll get it. Marc From owner-ietf-sasl Wed Apr 29 18:33:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA20668 for ietf-sasl-bks; Wed, 29 Apr 1998 18:33:05 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA20664 for ; Wed, 29 Apr 1998 18:33:04 -0700 (PDT) Received: from elwood.innosoft.com ("port 48298"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWG9FTHA3098535O@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 29 Apr 1998 18:33:58 PDT Date: Wed, 29 Apr 1998 18:35:35 -0700 (PDT) From: Chris Newman Subject: Re: GSSAPI and SASL In-reply-to: <199804300110.VAA19804@planet-zorp.MIT.EDU> To: Marc Horowitz Cc: 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 Wed, 29 Apr 1998, Marc Horowitz wrote: > Looking at the IMAP and SASL specifications, there's no single > mandatory required authentication mechanism, so there's no guarantee > of interoperability, there, either. The mandatory-to-implement mechanism for IMAP is the plaintext LOGIN command. I suspect this will have to change before IMAP can move to draft status. SASL is silent on mandatory-to-implement mechanisms. But each SASL mechanism has to interoperate, and the GSSAPI one doesn't as written. > (Where are {S,}CRAM-MD5 defined, > anyway?) However, this problem can be solved. CRAM-MD5 is RFC 2195. SCRAM-MD5 is draft-newman-auth-scram-03.txt. > IMAP could require that a particular SASL mech be implemented, and it > could also require certain behavior of the GSSAPI mech if it exists. The former will likely be necessary (as the LOGIN command is now insufficient by IETF rules), the latter would be a layering violation. The SASL library I've written is shared by our POP and IMAP servers and will be shared by the SMTP server as well. > Given the unlikelyhood of a server which supports multiple mechanisms > but not SPNEGO, IMAP (and other protocols) could require this: request > SPNEGO, and if the acceptor doesn't recognize the mechanism, then fall > back to a "real" mechanism. It is reasonable to expect SPNEGO will > get deployed widely, so this won't be necessary except for new clients > talking to older servers, which will also get upgraded relatively > quickly, one would think. If an IMAP client tries the GSSAPI mechanism and it fails, then it will fall back to another SASL mechanism or plaintext LOGIN. If you want to change the definition of the GSSAPI mechanism itself so it includes such a fallback, that'd be fine, but it'd be a change. > In any case, a client should be prepared to fall back, because > regardless of how cleverly the server constructs the list of > mechanisms it supports, the actual process can still fail. Another > mechanism might succeed, and it would be nice if the client tried it. Yes. But the SASL GSSAPI mechanism is defined in such a way that there is no fallback at that layer. There is only fallback to other SASL mechanisms. > I also think that putting GSSAPI in a separate document would be a > good idea. Otherwise, it cannot progress to Draft Standard, since > GSSAPI isn't there yet, and this gives us some time to come to > consensus on the GSSAPI issues. I concur. - Chris From owner-ietf-sasl Wed Apr 29 18:51:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA20781 for ietf-sasl-bks; Wed, 29 Apr 1998 18:51:11 -0700 (PDT) Received: from rover.cygnus.com (rover.cygnus.com [192.80.44.65]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA20777 for ; Wed, 29 Apr 1998 18:51:10 -0700 (PDT) Received: (from marc@localhost) by rover.cygnus.com (8.8.8/8.6.12) id VAA27222; Wed, 29 Apr 1998 21:53:05 -0400 (EDT) To: Chris Newman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and SASL References: From: Marc Horowitz Date: 29 Apr 1998 21:53:04 -0400 In-Reply-To: Chris Newman's message of Wed, 29 Apr 1998 18:35:35 -0700 (PDT) Message-ID: Lines: 63 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris Newman writes: >> The mandatory-to-implement mechanism for IMAP is the plaintext LOGIN >> command. I suspect this will have to change before IMAP can move to draft >> status. SASL is silent on mandatory-to-implement mechanisms. But each >> SASL mechanism has to interoperate, and the GSSAPI one doesn't as written. I didn't see this in rfc20260. What section is this? In any case, you're right, the IESG will likely require that this be changed. >> > (Where are {S,}CRAM-MD5 defined, >> > anyway?) However, this problem can be solved. >> >> CRAM-MD5 is RFC 2195. SCRAM-MD5 is draft-newman-auth-scram-03.txt. I guess that's what I get for just downloading *sasl* :-) >> > IMAP could require that a particular SASL mech be implemented, and it >> > could also require certain behavior of the GSSAPI mech if it exists. >> >> The former will likely be necessary (as the LOGIN command is now >> insufficient by IETF rules), the latter would be a layering violation. >> The SASL library I've written is shared by our POP and IMAP servers and >> will be shared by the SMTP server as well. I don't believe the latter is a layering violation. All it really does is restrict what parameters you specify to the SASL layer. >> > Given the unlikelyhood of a server which supports multiple mechanisms >> > but not SPNEGO, IMAP (and other protocols) could require this: request >> > SPNEGO, and if the acceptor doesn't recognize the mechanism, then fall >> > back to a "real" mechanism. It is reasonable to expect SPNEGO will >> > get deployed widely, so this won't be necessary except for new clients >> > talking to older servers, which will also get upgraded relatively >> > quickly, one would think. >> >> If an IMAP client tries the GSSAPI mechanism and it fails, then it will >> fall back to another SASL mechanism or plaintext LOGIN. If you want to >> change the definition of the GSSAPI mechanism itself so it includes such >> a fallback, that'd be fine, but it'd be a change. This sounds like an API issue, not a protocol issue. A simpler example is the CRAM-MD5 mechanism. If it fails, you would probably want the client to try again, since people are notoriously bad at typing passwords. GSSAPI can behave the same way, except that it can quietly switch mechanisms. Even if this isn't required behavior, it's still intelligent behavior. >> > In any case, a client should be prepared to fall back, because >> > regardless of how cleverly the server constructs the list of >> > mechanisms it supports, the actual process can still fail. Another >> > mechanism might succeed, and it would be nice if the client tried it. >> >> Yes. But the SASL GSSAPI mechanism is defined in such a way that there is >> no fallback at that layer. There is only fallback to other SASL >> mechanisms. Is this specific to the GSSAPI mechanism, or does it reply to all SASL mechanisms? I don't see where it's specified that a client can't try the same mechanism again if it has some reason to believe it might succeed this time. Marc From owner-ietf-sasl Wed Apr 29 19:39:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA21069 for ietf-sasl-bks; Wed, 29 Apr 1998 19:39:54 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA21065 for ; Wed, 29 Apr 1998 19:39:54 -0700 (PDT) Received: from elwood.innosoft.com ("port 48337"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWGBRP1JKG9857S5@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 29 Apr 1998 19:40:49 PDT Date: Wed, 29 Apr 1998 19:42:25 -0700 (PDT) From: Chris Newman Subject: Re: GSSAPI and SASL In-reply-to: To: Marc Horowitz Cc: 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 Wed, 29 Apr 1998, Marc Horowitz wrote: > Chris Newman writes: > >> The mandatory-to-implement mechanism for IMAP is the plaintext LOGIN > >> command. > > I didn't see this in rfc20260. What section is this? In any case, > you're right, the IESG will likely require that this be changed. Section 6.2.2 combined with the fact everything in RFC 2060 is mandatory-to-implement unless it explicitly states otherwise. > I guess that's what I get for just downloading *sasl* :-) The GSSAPI spec doesn't include the SPKM or K5 mechanisms. :-) > I don't believe the latter is a layering violation. All it really > does is restrict what parameters you specify to the SASL layer. I guess we disagree. I think mechanisms should be independent of the protocol which calls them (with the possible exception of the GSSAPI/SASL service name and the meaning of the authorization identity). > >> If an IMAP client tries the GSSAPI mechanism and it fails, then it will > >> fall back to another SASL mechanism or plaintext LOGIN. If you want to > >> change the definition of the GSSAPI mechanism itself so it includes such > >> a fallback, that'd be fine, but it'd be a change. > > This sounds like an API issue, not a protocol issue. ... > GSSAPI can behave the same way, except that it can > quietly switch mechanisms. Even if this isn't required behavior, it's > still intelligent behavior. You're right, I looked at the SASL API I'm working on and noticed I already have an error code (SASL_TRYAGAIN) suitable for this condition. So there is a cumbersome way to implement SASL+GSSAPI that interoperates, but it's not required and failure to do so results in interoperability problems. - Chris From owner-ietf-sasl Thu Apr 30 00:15:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA22438 for ietf-sasl-bks; Thu, 30 Apr 1998 00:15:54 -0700 (PDT) Received: from rover.cygnus.com (rover.cygnus.com [192.80.44.65]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id AAA22434 for ; Thu, 30 Apr 1998 00:15:52 -0700 (PDT) Received: (from marc@localhost) by rover.cygnus.com (8.8.8/8.6.12) id DAA05519; Thu, 30 Apr 1998 03:17:48 -0400 (EDT) To: Chris Newman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and SASL References: From: Marc Horowitz Date: 30 Apr 1998 03:17:48 -0400 In-Reply-To: Chris Newman's message of Wed, 29 Apr 1998 19:42:25 -0700 (PDT) Message-ID: Lines: 17 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-sasl@imc.org Precedence: bulk Chris Newman writes: >> > This sounds like an API issue, not a protocol issue. ... >> > GSSAPI can behave the same way, except that it can >> > quietly switch mechanisms. Even if this isn't required behavior, it's >> > still intelligent behavior. >> >> You're right, I looked at the SASL API I'm working on and noticed I >> already have an error code (SASL_TRYAGAIN) suitable for this condition. >> So there is a cumbersome way to implement SASL+GSSAPI that interoperates, >> but it's not required and failure to do so results in interoperability >> problems. Well, I think that the (separate :-) SASL+GSSAPI document could specify this, and then we'd have interoperability. Marc From owner-ietf-sasl Thu Apr 30 11:10:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA09625 for ietf-sasl-bks; Thu, 30 Apr 1998 11:10:21 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [198.161.92.131]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA09621 for ; Thu, 30 Apr 1998 11:10:20 -0700 (PDT) Received: from gallileo.esys.ca (irv-ca53-25.ix.netcom.com [207.94.87.153]) by demo.esys.ca (8.8.5/8.8.5) with ESMTP id MAA15043 for ; Thu, 30 Apr 1998 12:12:01 -0600 (MDT) Message-Id: <199804301812.MAA15043@demo.esys.ca> From: Steve Hole Date: Thu, 30 Apr 1998 12:11:41 -0600 To: IETF SASL Discussion List Subject: Re: GSSAPI and SASL In-Reply-To: References: Sender: owner-ietf-sasl@imc.org Precedence: bulk Message-ID: Priority: NORMAL X-Mailer: Simeon for Win32 Version 5.0 Preview Build (9) MIME-Version: 1.0 Content-Type: Multipart/signed; BOUNDARY=Part9804301211.D; protocol="application/pgp-signature"; micalg=pgp-sha1 --Part9804301211.D Content-Type: Text/PLAIN; CHARSET=US-ASCII On 29 Apr 1998 21:53:04 -0400 Marc Horowitz wrote: > This sounds like an API issue, not a protocol issue. A simpler > example is the CRAM-MD5 mechanism. If it fails, you would probably > want the client to try again, since people are notoriously bad at > typing passwords. GSSAPI can behave the same way, except that it can > quietly switch mechanisms. Even if this isn't required behavior, it's > still intelligent behavior. I agree. I have explicitly added a SASL_Continue state code to my API that allows the SASL consumer to try that mechanism again. You really must be able to do this for CRAM-MD5, PLAIN, and I believe, GSSAPI. All of my implementations of the above do this. > >> > In any case, a client should be prepared to fall back, because > >> > regardless of how cleverly the server constructs the list of > >> > mechanisms it supports, the actual process can still fail. Another > >> > mechanism might succeed, and it would be nice if the client tried it. > >> > >> Yes. But the SASL GSSAPI mechanism is defined in such a way that there is > >> no fallback at that layer. There is only fallback to other SASL > >> mechanisms. > > Is this specific to the GSSAPI mechanism, or does it reply to all SASL > mechanisms? I don't see where it's specified that a client can't try > the same mechanism again if it has some reason to believe it might > succeed this time. The behaviour is purely implementation defined -- there is no definition at all in SASL on trying again. You really must be able to try certain mechanisms again, the policy of which is defined by the mechanism itself. On a side note, operational experience with fallback between SASL mechanisms has shown me that client fallback really should occur only with explicit server permission. In most cases, if you offer a GSSAPI level authentication service, and authentication fails, you probably failed for a good reason and you really shouldn't try anything weaker. You should fix configuration issue that prevents you from authenticating. Cheers. --- Steve Hole The Esys Corporation Mailto:Steve.Hole@esys.ca Phone:403-424-4922 --Part9804301211.D Content-Type: Application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version) iQA/AwUBNUi+3di5Jj9Fn5KMEQK67ACdEjNLw4FUm8rhPljrBcoJdWKqPQ8An2FW O44g96z0eUNkmgccgbYvInMW =R36Z -----END PGP SIGNATURE----- --Part9804301211.D-- From owner-ietf-sasl Thu Apr 30 12:19:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA10086 for ietf-sasl-bks; Thu, 30 Apr 1998 12:19:20 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA10082 for ; Thu, 30 Apr 1998 12:19:17 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WbMailNT V3.0 beta 1 build 106); Thu, 30 Apr 1998 15:21:29 -0400 Message-Id: <3.0.1.32.19980430152132.007ba3c0@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 30 Apr 1998 15:21:32 -0400 To: Steve Hole , IETF SASL Discussion List From: "Jack De Winter" Subject: Re: GSSAPI and SASL In-Reply-To: <199804301812.MAA15043@demo.esys.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk >The behaviour is purely implementation defined -- there is no definition at >all in SASL on trying again. You really must be able to try certain >mechanisms again, the policy of which is defined by the mechanism itself. > >On a side note, operational experience with fallback between SASL mechanisms >has shown me that client fallback really should occur only with explicit >server permission. In most cases, if you offer a GSSAPI level >authentication service, and authentication fails, you probably failed for >a good reason and you really shouldn't try anything weaker. You should fix >configuration issue that prevents you from authenticating. While I agree with most of this thread so far, I would disagree in part with the above statement. I would agree that if you try and authenticate, and fail, you should try again. However, seeing as it is very hard to determine empircally "if something is weaker", I would problably add the caveat that once an authentication mechanism is used to attempt authentication, it might be a good idea to only allow that authentication from that point in. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Fri May 1 11:17:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA03455 for ietf-sasl-bks; Fri, 1 May 1998 11:17:51 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA03451 for ; Fri, 1 May 1998 11:17:49 -0700 (PDT) Received: from elwood.innosoft.com ("port 49245"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWIMUYZXU49858CD@INNOSOFT.COM> for ietf-sasl@imc.org; Fri, 1 May 1998 11:19:37 PDT Date: Fri, 01 May 1998 11:21:14 -0700 (PDT) From: Chris Newman Subject: New OTP SASL draft To: IETF One-Time-Password WG Cc: ietf-sasl@imc.org Reply-to: IETF One-Time-Password WG 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 I just submitted a new OTP SASL draft to the internet-drafts editor. A preview copy is available on the web at: or in heuristicly generated html: This now defines only one OTP SASL mechanism (rather than OTP-MD5 and OTP-SHA1 as the old version did). Two other things of note: Support for alternate dictionaries is mandatory for the server. This is only a small burden for the server, and it permits the six-word format to be non-English. Multinational support is important for applications and making alternate dictionaries mandatory on the server reduces interoperability issues. I added an IANA considerations section which explicitly amends the "intended usage" of the SKEY SASL mechanism to OBSOLETE. Final review of this specification would be appreciated. I'm hoping only editorial changes will be necessary prior to IETF last call. - Chris From owner-ietf-sasl Fri May 1 12:27:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA04158 for ietf-sasl-bks; Fri, 1 May 1998 12:27:25 -0700 (PDT) Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA04154 for ; Fri, 1 May 1998 12:27:23 -0700 (PDT) Received: from kr-pc.cygnus.com (kr-pc.cygnus.com [192.80.44.193]) by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id PAA14378 for ; Fri, 1 May 1998 15:28:51 -0400 (EDT) Received: (from raeburn@localhost) by kr-pc.cygnus.com (8.8.8/8.6.9) id PAA01670; Fri, 1 May 1998 15:28:11 -0400 (EDT) To: IETF SASL Discussion List Subject: Re: GSSAPI and SASL References: <199804301812.MAA15043@demo.esys.ca> From: Ken Raeburn Date: 01 May 1998 15:28:10 -0400 In-Reply-To: Steve Hole's message of "Thu, 30 Apr 1998 12:11:41 -0600" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.2/Emacs 19.34 Sender: owner-ietf-sasl@imc.org Precedence: bulk Steve Hole writes: > On a side note, operational experience with fallback between SASL mechanisms > has shown me that client fallback really should occur only with explicit > server permission. In most cases, if you offer a GSSAPI level > authentication service, and authentication fails, you probably failed for > a good reason and you really shouldn't try anything weaker. You should fix > configuration issue that prevents you from authenticating. I must be missing something. I read this as implying that the first SASL auth mechanism you try should be the only one, at least without "explicit server permission". E.g., if my krb5 tickets don't exist or have expired, thus causing GSSAPI authentication to fail, are you suggesting the client shouldn't even try using krb4 tickets? Working in an environment that mixes krb5 and krb4, I like having applications fall back, myself. If krb4 (for example) is considered too weak, why does your SASL configuration ever allow it? And what would constitute "explicit server permission"? From owner-ietf-sasl Fri May 1 12:54:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA04364 for ietf-sasl-bks; Fri, 1 May 1998 12:54:22 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA04360 for ; Fri, 1 May 1998 12:54:21 -0700 (PDT) Received: from elwood.innosoft.com ("port 49251"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWIQ7PJOWO985A43@INNOSOFT.COM> for ietf-sasl@imc.org; Fri, 1 May 1998 12:55:23 PDT Date: Fri, 01 May 1998 12:57:00 -0700 (PDT) From: Chris Newman Subject: Re: GSSAPI and SASL In-reply-to: To: Ken Raeburn Cc: IETF SASL Discussion List 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 Fri, 1 May 1998, Ken Raeburn wrote: > And what would constitute "explicit server permission"? The "TRANSITION-NEEDED" response code as documented in: draft-newman-sasl-plaintrans-04.txt It has some serious security considerations, but it does allow a site to gracefully deploy something more secure than plaintext passwords without resetting the passwords for all users. All in all a net gain for site security. Of course, that particular draft is dead for political reasons, but half of it has moved to draft-newman-tls-imappop-04.txt, and I plan to eventually do a draft on protocol authentication response codes (after SMTP AUTH and POP3 extensions have moved through the standards pipeline). - Chris From owner-ietf-sasl Fri May 1 13:39:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA04786 for ietf-sasl-bks; Fri, 1 May 1998 13:39:50 -0700 (PDT) Received: from inner.net (avarice.inner.net [198.82.204.99]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA04782 for ; Fri, 1 May 1998 13:39:39 -0700 (PDT) Received: from inner.net (lust.inner.net [199.33.248.1.1084]) by inner.net (8.8.8/8.8.5) with ESMTP id UAA08518; Fri, 1 May 1998 20:41:25 GMT Message-Id: <199805012041.UAA08518@inner.net> To: IETF One-Time-Password WG cc: ietf-sasl@imc.org Subject: Re: New OTP SASL draft In-reply-to: Your message of "Fri, 01 May 1998 11:21:14 PDT." X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 01 May 1998 16:41:02 -0300 From: Craig Metz Sender: owner-ietf-sasl@imc.org Precedence: bulk In message , you write: >Support for alternate dictionaries is mandatory for the server. This is >only a small burden for the server, and it permits the six-word format to >be non-English. Multinational support is important for applications and >making alternate dictionaries mandatory on the server reduces >interoperability issues. ... >Final review of this specification would be appreciated. I'm hoping only >editorial changes will be necessary prior to IETF last call. Operational experience with alternate dictionaries has what I consider to be crystal clear results. All that making them mandatory does is make it that much less likely that people will implement this specification. Many existing OTP implementations have not implemented alternate dictionaries and are not likely to do so any time soon. -Craig From owner-ietf-sasl Mon May 4 09:50:00 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA06420 for ietf-sasl-bks; Mon, 4 May 1998 09:50:00 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [198.161.92.131]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA06416 for ; Mon, 4 May 1998 09:49:59 -0700 (PDT) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by demo.esys.ca (8.8.5/8.8.5) with ESMTP id KAA08619 for ; Mon, 4 May 1998 10:52:06 -0600 (MDT) Message-Id: <199805041652.KAA08619@demo.esys.ca> From: Steve Hole Date: Mon, 4 May 1998 10:51:09 -0600 To: IETF SASL Discussion List Subject: Re: GSSAPI and SASL In-Reply-To: References: <199804301812.MAA15043@demo.esys.ca> Sender: owner-ietf-sasl@imc.org Precedence: bulk Message-ID: Priority: NORMAL X-Mailer: Simeon for Win32 Version 5.0 Preview Build (9) MIME-Version: 1.0 Content-Type: Multipart/signed; BOUNDARY=Part9805041051.B; protocol="application/pgp-signature"; micalg=pgp-sha1 --Part9805041051.B Content-Type: Text/PLAIN; CHARSET=US-ASCII On 01 May 1998 15:28:10 -0400 Ken Raeburn wrote: > Steve Hole writes: > > > On a side note, operational experience with fallback between SASL mechanisms > > has shown me that client fallback really should occur only with explicit > > server permission. In most cases, if you offer a GSSAPI level > > authentication service, and authentication fails, you probably failed for > > a good reason and you really shouldn't try anything weaker. You should fix > > configuration issue that prevents you from authenticating. > > I must be missing something. I read this as implying that the first > SASL auth mechanism you try should be the only one, at least without > "explicit server permission". E.g., if my krb5 tickets don't exist or > have expired, thus causing GSSAPI authentication to fail, are you > suggesting the client shouldn't even try using krb4 tickets? Working > in an environment that mixes krb5 and krb4, I like having applications > fall back, myself. In this example, the krb5 SASL mechanism would not even be started because your krb5 SASL driver (actually GSSAPI) would detect the fact that you do not have proper credentials and would not enter into a GSSAPI negotiation. Therefore no fallback occurs to go to krb4 -- you would start with krb4. If you have valid krb5 credentials and you fail to authenticate, then you failed to authenticate. If a server only supports krb4 tickets then it will advertise only the krb4 mechanism and once again, the client will never attempt the krb5 mechanism. Let me restate the point. If your client believes that it has correct and sufficient information to initiate a particular SASL mechanism, AND that mechanism is supported by the server, AND you initiate the mechanism using the appropriate protocol "AUTHENTICATE" command, then failure to authenticate using that mechanism should be final unless: 1. the server explicitly allows you to "fallback" to another mechanism -- presumably less desirable. And, by the way, it is reasonably easy to decide, as a developer, which is stronger and which is weaker. As a site administrator, you will be informed by your vendor which is stronger and which is weaker so that you can establish clear security policies. 2. the "failed" mechanism allows the application to "try again" with the same mechanism. This is very useful for CRAM-MD5 and PLAIN where credentials are user supplied and prone to typing errors. > If krb4 (for example) is considered too weak, why does your SASL > configuration ever allow it? It's not weak at all. Simeon does preferential listing of GSSAPI and krb4 at the same level. It will try GSSAPI first simply because GSSAPI security modules are likely to be OS or site provided and (probably) best expresses the site security policy. Operational experience shows that they are rarely jointly installed, and even when they are, they don't collide. There are definitely better and worse implementations of GSSAPI however which can get mixed up between the krb5 and krb4 thing -- but that is well before it gets to the SASL support inside any application like Simeon. > And what would constitute "explicit server permission"? Chris answered this in his followup. What he said. Cheers. --- Steve Hole The Esys Corporation Mailto:Steve.Hole@esys.ca Phone:403-424-4922 --Part9805041051.B Content-Type: Application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version) iQA/AwUBNU3yAdi5Jj9Fn5KMEQLJEwCgwANyLMO5zo1QszsOmD7n+Vyn+BgAnRNA ckft+u+047rn0Am3v4Uc1Quv =7Tp1 -----END PGP SIGNATURE----- --Part9805041051.B-- From owner-ietf-sasl Thu May 7 09:11:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA20404 for ietf-sasl-bks; Thu, 7 May 1998 09:11:58 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA20400 for ; Thu, 7 May 1998 09:11:55 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WbMailNT V3.0 beta 1 build 106); Thu, 7 May 1998 12:14:53 -0400 Message-Id: <3.0.1.32.19980507121452.00a144e0@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 07 May 1998 12:14:52 -0400 To: IETF SASL Discussion List From: "Jack De Winter" Subject: regarding the mention of NIS Authentication... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk well, was browsing through comp.mail.imap in my "spare" time, and someone was asking about IMAP supporting NIS authentication. Seeing as IMAP supports SASL, I thought the best place to pass the questions on was here. 1) Anyone know what NIS authentication is? 2) Is it relevant/needed under SASL? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Sat May 9 13:30:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA12550 for ietf-sasl-bks; Sat, 9 May 1998 13:30:12 -0700 (PDT) Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA12546 for ; Sat, 9 May 1998 13:30:11 -0700 (PDT) Received: from kr-pc.cygnus.com (kr-pc.cygnus.com [192.80.44.193]) by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id QAA02019 for ; Sat, 9 May 1998 16:32:40 -0400 (EDT) Received: (from raeburn@localhost) by kr-pc.cygnus.com (8.8.8/8.6.9) id QAA14501; Sat, 9 May 1998 16:32:02 -0400 (EDT) To: IETF SASL Discussion List Subject: Re: GSSAPI and SASL References: <199804301812.MAA15043@demo.esys.ca> <199805041652.KAA08619@demo.esys.ca> From: Ken Raeburn Date: 09 May 1998 16:32:02 -0400 In-Reply-To: Steve Hole's message of "Mon, 4 May 1998 10:51:09 -0600" Message-ID: Lines: 62 X-Mailer: Gnus v5.6.2/Emacs 19.34 Sender: owner-ietf-sasl@imc.org Precedence: bulk Steve Hole writes: > > I must be missing something. I read this as implying that the first > > SASL auth mechanism you try should be the only one, at least without > > "explicit server permission". E.g., if my krb5 tickets don't exist or > > have expired, thus causing GSSAPI authentication to fail, are you > > suggesting the client shouldn't even try using krb4 tickets? Working > > in an environment that mixes krb5 and krb4, I like having applications > > fall back, myself. > > In this example, the krb5 SASL mechanism would not even be started because > your krb5 SASL driver (actually GSSAPI) would detect the fact that you > do not have proper credentials and would not enter into a GSSAPI negotiation. > Therefore no fallback occurs to go to krb4 -- you would start with krb4. > If you have valid krb5 credentials and you fail to authenticate, then you > failed to authenticate. If a server only supports krb4 tickets then it > will advertise only the krb4 mechanism and once again, the client will never > attempt the krb5 mechanism. Ah, I see. You're thinking of fallback in terms of the authentication attempts sent to the server; I was thinking of what SASL mechanisms the SASL library (if there is one) or application code invokes. So I would call the above a fallback (since GSSAPI was attempted and failed, and it just happened to be a locally detected problem of a particular kind), but you would not. Sorry for the confusion. I've got to go back to the GSSAPI spec to see for sure, but I assume the error codes returned are sufficient to decide whether or not to try another SASL mechanism (without getting server permission etc)? > Let me restate the point. If your client believes that it has correct and > sufficient information to initiate a particular SASL mechanism, AND that > mechanism is supported by the server, AND you initiate the mechanism using > the appropriate protocol "AUTHENTICATE" command, then failure to authenticate > using that mechanism should be final unless: > > 1. the server explicitly allows you to "fallback" to another mechanism -- > presumably less desirable. And, by the way, it is reasonably easy to decide, > as a developer, which is stronger and which is weaker. As a site > administrator, you will be informed by your vendor which is stronger and > which is weaker so that you can establish clear security policies. Since different sites, or even different machines at a site, may have different admins and different vendors, there'll probably be some disagreement as to which is better and which is worse, and the decision will probably be more political than technical in some cases. But the client and server should still be able to find one or more mechanisms acceptable to both of them. I still need to go look at the stuff Chris mentioned.... > > If krb4 (for example) is considered too weak, why does your SASL > > configuration ever allow it? > > It's not weak at all. Your message said "[if GSSAPI fails, you] shouldn't try anything weaker." And you were talking about not falling back at all without permission. I guess I read in more to that combination that you meant. I don't consider krb4 to be especially weak either, though I'd prefer triple-DES or something else better than plain DES, if I weren't stuck in this mixed environment. From owner-ietf-sasl Tue May 12 11:50:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA21108 for ietf-sasl-bks; Tue, 12 May 1998 11:50:31 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA21104 for ; Tue, 12 May 1998 11:50:30 -0700 (PDT) Received: from elwood.innosoft.com ("port 41936"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWY17INWOQ985HES@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 12 May 1998 11:52:28 PDT Date: Tue, 12 May 1998 11:54:02 -0700 (PDT) From: Chris Newman Subject: Re: regarding the mention of NIS Authentication... In-reply-to: <3.0.1.32.19980507121452.00a144e0@lacroix.wildbear.on.ca> To: Jack De Winter Cc: IETF SASL Discussion List 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 Thu, 7 May 1998, Jack De Winter wrote: > well, was browsing through comp.mail.imap in my "spare" > time, and someone was asking about IMAP supporting NIS > authentication. Seeing as IMAP supports SASL, I thought > the best place to pass the questions on was here. > > 1) Anyone know what NIS authentication is? > 2) Is it relevant/needed under SASL? NIS is a system designed by Sun to centrally manage passwords at small sites. It is full of security holes. NIS basically requires plaintext passwords, so the SASL PLAIN mechanism suffices. - Chris From owner-ietf-sasl Tue May 12 14:03:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA21930 for ietf-sasl-bks; Tue, 12 May 1998 14:03:09 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA21926 for ; Tue, 12 May 1998 14:03:07 -0700 (PDT) Received: from asdfjkl (ASDFJKL.ANDREW.CMU.EDU [128.2.36.189]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id RAA02259 for ; Tue, 12 May 1998 17:06:06 -0400 (EDT) Reply-To: From: "Rob Earhart" To: Subject: SASL ABI? Date: Tue, 12 May 1998 17:06:24 -0400 Message-ID: <000201bd7de9$d25e9db0$bd240280@asdfjkl.andrew.cmu.educmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-sasl@imc.org Precedence: bulk We're looking into implementing a SASL API, and realized that it'd be good to have some sort of SASL configuration/ABI definition to answer questions like Where do modules live? How do we access them on a given system? Where does site-configuration live? What's the format of the site-configuration? Configuration's useful because we'd like to be able to have sites be able to say things like "Use Kerberos for IMAP connections on-site, and anything but plaintext off-site," - that is, we think it's useful for sites to be able to define their own security policies on a per-protocol basis (and to be able to write/purchase additional security plugins for existing applications). So has anyone looked into this? Any thoughts/comments? It doesn't seem like this'd be too hard to define, but I think it'd be a good idea to define it in a standard way if we're going to do it at all, and if someone's done it already I'd rather reuse existing work, if possible. :-) )Rob From owner-ietf-sasl Wed May 13 08:06:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA14863 for ietf-sasl-bks; Wed, 13 May 1998 08:06:48 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA14859 for ; Wed, 13 May 1998 08:06:45 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Wed, 13 May 1998 11:06:44 -0400 Message-Id: <3.0.1.32.19980513110649.009aeda0@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 13 May 1998 11:06:49 -0400 To: Harald Alvestrand , kaih@khms.westfalen.de (Kai Henningsen), ietf-sasl@imc.org From: "Jack De Winter" Subject: Re: Huffman coding? In-Reply-To: <3.0.2.32.19980512115411.009ed100@127.0.0.1> References: <3.0.1.32.19980511104406.0097e100@lacroix.wildbear.on.ca> <6tcrCTr1w-B@khms.westfalen.de> <199805042042.NAA02434@rostam.neda.com> <199804270523.WAA09797@rostam.neda.com> <199805042042.NAA02434@rostam.neda.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 11:54 AM 5/12/98 +0200, Harald Alvestrand wrote: >At 10:44 11.05.98 -0400, Jack De Winter wrote: >>Just as a side note, I am preparing a document on AHUFFMAN-CRAM-MD5, >>and would appreciate anyone who would like to look over it with me >>and give it a good first pass. It supports Adaptive Huffman encoding >>with a CRAM-MD5 authenticator. > >Interesting....how did you end up with Huffman, and not zlib, deflate, >lz77 or one of the other compression algorithms? >It's been a long time since I've seen Huffman seriously mentioned.... well, huffman is considered a "base" type in most computing circles, and I thought it would be a good place to start, and then to progress on to the other types. This is kind of like CRAM-MD5 for authentication. CRAM-MD5 is simple and easy to implement. we have plans to put out docs for the others as well, just wanted to gauge if using SASL was a generally accepted good method for compression first, or if we need to go to a different access mechanism. the one downfall of compression under SASL is the need for authentication, unless we come up with a "NULL" authentication type. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Wed May 13 14:42:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA18542 for ietf-sasl-bks; Wed, 13 May 1998 14:42:44 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA18538 for ; Wed, 13 May 1998 14:42:40 -0700 (PDT) Received: from elwood.innosoft.com ("port 62154"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWZLIEMJZY985HVJ@INNOSOFT.COM> for ietf-sasl@imc.org; Wed, 13 May 1998 14:44:42 PDT Date: Wed, 13 May 1998 14:46:16 -0700 (PDT) From: Chris Newman Subject: Re: SASL ABI? In-reply-to: <000201bd7de9$d25e9db0$bd240280@asdfjkl.andrew.cmu.educmu.edu> To: Rob Earhart Cc: 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 Tue, 12 May 1998, Rob Earhart wrote: > We're looking into implementing a SASL API, and realized that it'd be good > to have some sort of SASL configuration/ABI definition to answer questions > like > > Where do modules live? > How do we access them on a given system? > Where does site-configuration live? > What's the format of the site-configuration? > > Configuration's useful because we'd like to be able to have sites be able > to say things like "Use Kerberos for IMAP connections on-site, and anything > but plaintext off-site," - that is, we think it's useful for sites to be > able to define their own security policies on a per-protocol basis (and to > be able to write/purchase additional security plugins for existing > applications). > > So has anyone looked into this? Any thoughts/comments? It doesn't seem > like this'd be too hard to define, but I think it'd be a good idea to define > it in a standard way if we're going to do it at all, and if someone's done > it already I'd rather reuse existing work, if possible. :-) I've been working on all these issues, at least for our product. The important thing for the ABI is to have the exact API with parameter sizes, and the shared library compiliation options. As for config files, I'm not sure it's worth the work to document a common format. Different products have different configuration models. I'd be glad to share what we're doing as the design of config files for this is quite tricky (I had to go through a couple cycles of implement & re-design). Our current model for the server side is as follows: There's a mapping table and security config file. The mapping table has the following structure: TCP|local-ip|local-port|remote-ip|remote-port $Y| TCP|local-ip|local-port|remote-ip|remote-port $N $N means refuse connections, dumping the refusal string down the port before closing it. $Y means accept connections with "ruleset" as the name of the security ruleset to use and "user-domain" as the user namespace to use (for support of multiple domains on the same host). The security config we're using is broken into sections by security ruleset and authentication source: [RULESET=default] ENABLE=/,... ... [AUTH_SOURCE=plugin-name] IMAGE= FUNCTION= ... Each plugin serves an authentication source, and provides one or more SASL mechanisms. Authentication sources can be built-in or dynamically loaded as specified by the [AUTH_SOURCE=...] section of the config file. I believe this is sufficiently flexible and extensible, but I'm not sure others will want to use the same syntax and certainly won't want the same locations for the config file. - Chris From owner-ietf-sasl Thu May 14 00:11:01 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA05462 for ietf-sasl-bks; Thu, 14 May 1998 00:11:01 -0700 (PDT) Received: from dokka.kvatro.no (dokka.kvatro.no [193.216.2.164]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id AAA05458 for ; Thu, 14 May 1998 00:10:58 -0700 (PDT) Received: from alden (hosts.maxware.no [195.139.236.139]) by dokka.kvatro.no (8.8.5/8.8.5) with SMTP id JAA07078; Thu, 14 May 1998 09:13:30 +0200 Message-Id: <3.0.2.32.19980514084832.0186d290@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 14 May 1998 08:48:32 +0200 To: "Jack De Winter" , kaih@khms.westfalen.de (Kai Henningsen), ietf-sasl@imc.org From: Harald Alvestrand Subject: Re: Huffman coding? In-Reply-To: <3.0.1.32.19980513110649.009aeda0@lacroix.wildbear.on.ca> References: <3.0.2.32.19980512115411.009ed100@127.0.0.1> <3.0.1.32.19980511104406.0097e100@lacroix.wildbear.on.ca> <6tcrCTr1w-B@khms.westfalen.de> <199805042042.NAA02434@rostam.neda.com> <199804270523.WAA09797@rostam.neda.com> <199805042042.NAA02434@rostam.neda.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 11:06 13.05.98 -0400, Jack De Winter wrote: >At 11:54 AM 5/12/98 +0200, Harald Alvestrand wrote: >>At 10:44 11.05.98 -0400, Jack De Winter wrote: >>>Just as a side note, I am preparing a document on AHUFFMAN-CRAM-MD5, >>>and would appreciate anyone who would like to look over it with me >>>and give it a good first pass. It supports Adaptive Huffman encoding >>>with a CRAM-MD5 authenticator. >> >>Interesting....how did you end up with Huffman, and not zlib, deflate, >>lz77 or one of the other compression algorithms? >>It's been a long time since I've seen Huffman seriously mentioned.... > >well, huffman is considered a "base" type in most computing circles, and >I thought it would be a good place to start, and then to progress on to >the other types. This is kind of like CRAM-MD5 for authentication. >CRAM-MD5 is simple and easy to implement. I don't think you have seriously thought about the deployment issue. If we have 15 different compression algorithms being defined through SASL schemes, and 15 implementations choose 4 at random, the chances of any two of these parties being able to communicate in compressed mode become microscopic. There's also a combinatorial explosion with authentication schemes; do you really, really want to do KERBEROS-HUFFMAN, KERBEROS-ZLIB, GSSAPI-HUFFMANN, GSSAPI-ZLIB, SKEY-HUFFMAN, SKEY-ZLIB et cetera ad nauseam ad infinitum? >we have plans to put out docs for the others as well, just wanted >to gauge if using SASL was a generally accepted good method for >compression first, or if we need to go to a different access mechanism. >the one downfall of compression under SASL is the need for authentication, >unless we come up with a "NULL" authentication type. > You already have a "null" authentication, it's called "anonymous". But I think this approach has serious problems. I'd rather see if you could make it an orthogonal attribute of the connection. And remember - when doing encryption, compression must be applied *before* encryption. Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-ietf-sasl Thu May 14 09:50:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA10685 for ietf-sasl-bks; Thu, 14 May 1998 09:50:27 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA10680 for ; Thu, 14 May 1998 09:50:24 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Thu, 14 May 1998 12:53:24 -0400 Message-Id: <3.0.1.32.19980514125326.009af100@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 14 May 1998 12:53:26 -0400 To: Harald Alvestrand , kaih@khms.westfalen.de (Kai Henningsen), ietf-sasl@imc.org From: "Jack De Winter" Subject: Compression under SASL was Re: Huffman coding? In-Reply-To: <3.0.2.32.19980514084832.0186d290@127.0.0.1> References: <3.0.1.32.19980513110649.009aeda0@lacroix.wildbear.on.ca> <3.0.2.32.19980512115411.009ed100@127.0.0.1> <3.0.1.32.19980511104406.0097e100@lacroix.wildbear.on.ca> <6tcrCTr1w-B@khms.westfalen.de> <199805042042.NAA02434@rostam.neda.com> <199804270523.WAA09797@rostam.neda.com> <199805042042.NAA02434@rostam.neda.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 08:48 AM 5/14/98 +0200, Harald Alvestrand wrote: >I don't think you have seriously thought about the deployment issue. >If we have 15 different compression algorithms being defined through >SASL schemes, and 15 implementations choose 4 at random, the chances >of any two of these parties being able to communicate in compressed mode >become microscopic. > >There's also a combinatorial explosion with authentication schemes; >do you really, really want to do KERBEROS-HUFFMAN, KERBEROS-ZLIB, >GSSAPI-HUFFMANN, GSSAPI-ZLIB, SKEY-HUFFMAN, SKEY-ZLIB et cetera ad >nauseam ad infinitum? Very important point, and one that I have not overlooked, but was hoping to get input from the community on. Right now, it looks like SASL is being adopted throughout the IETF community in the various specs (ACAP, SMTP, POP3, IMAP to name a few). From what John Meyers mentioned one time, that road of getting authentication (and compression) to be distributed in such a fashion has been a long and painful road. Compression is something that a lot of people are asking for. If we have to go through the same thing again, I fear it would never get done. As such, I asked John about compression one time, and he thought it was a good idea. >You already have a "null" authentication, it's called "anonymous". >But I think this approach has serious problems. I'd rather see if you >could make it an orthogonal attribute of the connection. >And remember - when doing encryption, compression must be applied >*before* encryption. You know... I had totally missed that one. Personally, I would prefer to see compression stay within SASL's scope. A good way to do this might be to extend SASL to allow for an optional compression type. A possibility might be: A01 AUTHENTICATE-COMP I would prefer to see "AUTHENTICATE" by itself, but then there would be no way of knowing that the second parameter is a compression mechanism versus the authentication mechanism's start data. Pros 1) Uses deployed architecture, with minor changes to the authentication invocation mechanism and capabilities mechanism (if supported). 2) The SASL mechanism handler would be able to enforce Harald's "rule" that compression should be done before encryption. 3) Would use existing deployment to deliver compression to the protocols that support it with little change. Cons ??? Well, seeing as this has got the ball rolling, could people voice their opinions regarding compression under SASL, pros and cons, and whether or not they believe that compression types should be placed under SASL (along with reasons why and why not)? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Thu May 14 11:28:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA11555 for ietf-sasl-bks; Thu, 14 May 1998 11:28:28 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA11551 for ; Thu, 14 May 1998 11:28:28 -0700 (PDT) Received: from elwood.innosoft.com ("port 63138"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IX0T0YYS4Y985F14@INNOSOFT.COM> for ietf-sasl@imc.org; Thu, 14 May 1998 11:30:30 PDT Date: Thu, 14 May 1998 11:32:04 -0700 (PDT) From: Chris Newman Subject: Re: Compression under SASL was Re: Huffman coding? In-reply-to: <3.0.1.32.19980514125326.009af100@lacroix.wildbear.on.ca> To: Jack De Winter Cc: 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 Thu, 14 May 1998, Jack De Winter wrote: > Well, seeing as this has got the ball rolling, could people voice > their opinions regarding compression under SASL, pros and cons, and > whether or not they believe that compression types should be placed > under SASL (along with reasons why and why not)? In general, I think a compression layer should be done in combination with a security layer (integrity/privacy protection). Adding a new layer is fairly expensive and making multiple layers above the TCP level work well is hard. This follows the "avoid unnecessary layers" design goal. I'll point out that you may be better off using TLS for compression since the feature is already built in and the TLS layer is more popular than the SASL security layer (SASL is more popular for client authentication than TLS). If you do compression under SASL, pick only one good algorithm. Compression has diminishing returns, so if you start with a good-enough algorithm, then it's not worth suffering the interoperability problems necessary to upgrade. I recommend zlib-deflate because it's good-enough, already documented in RFC 1950/1951 and it's patent-free. Security layers are currently negotiated by asking for "integrity" or "privacy" protection. Add one more bit to negotiate "zlib-deflate" compression. This is a backwards compatible change to the KERBEROS_V4, GSSAPI and SCRAM-MD5 mechanisms. Mechanisms without a security layer will either have to be revised to add one, or left alone. Since SCRAM-MD5 is backwards compatible with CRAM-MD5 and supports a security layer, I'd say that doing just CRAM-MD5 plus compression would be a waste of time. - Chris From owner-ietf-sasl Fri May 15 01:06:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id BAA29933 for ietf-sasl-bks; Fri, 15 May 1998 01:06:15 -0700 (PDT) Received: from dokka.kvatro.no (dokka.kvatro.no [193.216.2.164]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id BAA29929 for ; Fri, 15 May 1998 01:06:12 -0700 (PDT) Received: from alden (hosts.maxware.no [195.139.236.139]) by dokka.kvatro.no (8.8.5/8.8.5) with SMTP id KAA18949; Fri, 15 May 1998 10:08:45 +0200 Message-Id: <3.0.2.32.19980515100406.00b3c2e0@127.0.0.1> X-Sender: hta@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 15 May 1998 10:04:06 +0200 To: "Jack De Winter" , kaih@khms.westfalen.de (Kai Henningsen), ietf-sasl@imc.org From: Harald Alvestrand Subject: Re: Compression under SASL was Re: Huffman coding? In-Reply-To: <3.0.1.32.19980514125326.009af100@lacroix.wildbear.on.ca> References: <3.0.2.32.19980514084832.0186d290@127.0.0.1> <3.0.1.32.19980513110649.009aeda0@lacroix.wildbear.on.ca> <3.0.2.32.19980512115411.009ed100@127.0.0.1> <3.0.1.32.19980511104406.0097e100@lacroix.wildbear.on.ca> <6tcrCTr1w-B@khms.westfalen.de> <199805042042.NAA02434@rostam.neda.com> <199804270523.WAA09797@rostam.neda.com> <199805042042.NAA02434@rostam.neda.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 12:53 14.05.98 -0400, Jack De Winter wrote: >2) The SASL mechanism handler would be able to enforce Harald's > "rule" that compression should be done before encryption. It's not my rule, just an observation that compression after encryption is 100% useless - an encrypted bitstream is, almost by definition, indistinguishable in statistical properties from random noise, and random noise does not compress very well. Count me as one of those *not* happy with defining compression as a part of the SASL layer; it's the kitchen sink/hammer analogy again: burdening a layer with things that do not fit there damages that layer. (If you want to change the scope of SASL, I think it makes much more sense to define TLS as a SASL mechanism; the special treatment it gets now may make sense at a microscopic level, but at the 10.000 foot level it seems sillier every time I look at it.) Harald Harald Tveit Alvestrand IETF Area Director, Operations and Management NOTE: No longer Area Director for Applications. From owner-ietf-sasl Fri May 15 07:26:00 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA03504 for ietf-sasl-bks; Fri, 15 May 1998 07:26:00 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA03500 for ; Fri, 15 May 1998 07:25:57 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Fri, 15 May 1998 10:28:56 -0400 Message-Id: <3.0.1.32.19980515102911.009b1b10@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 15 May 1998 10:29:11 -0400 To: Harald Alvestrand , kaih@khms.westfalen.de (Kai Henningsen), ietf-sasl@imc.org From: "Jack De Winter" Subject: Re: Compression under SASL was Re: Huffman coding? In-Reply-To: <3.0.2.32.19980515100406.00b3c2e0@127.0.0.1> References: <3.0.1.32.19980514125326.009af100@lacroix.wildbear.on.ca> <3.0.2.32.19980514084832.0186d290@127.0.0.1> <3.0.1.32.19980513110649.009aeda0@lacroix.wildbear.on.ca> <3.0.2.32.19980512115411.009ed100@127.0.0.1> <3.0.1.32.19980511104406.0097e100@lacroix.wildbear.on.ca> <6tcrCTr1w-B@khms.westfalen.de> <199805042042.NAA02434@rostam.neda.com> <199804270523.WAA09797@rostam.neda.com> <199805042042.NAA02434@rostam.neda.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 10:04 AM 5/15/98 +0200, Harald Alvestrand wrote: >Count me as one of those *not* happy with defining compression as >a part of the SASL layer; it's the kitchen sink/hammer analogy again: >burdening a layer with things that do not fit there damages that layer. > >(If you want to change the scope of SASL, I think it makes much more >sense to define TLS as a SASL mechanism; the special treatment it >gets now may make sense at a microscopic level, but at the 10.000 foot >level it seems sillier every time I look at it.) Well, I do remember John trying to do this and getting tonnes of problems, mainly stemming from the double framing that would go on. I had a look over TLS specs the past couple of days, and I seem to have made the following observations: 1) Compression seems to be a sideline. From page 29 of the TLS main draft, it says that "a client and server will always be able to agree on a compression method". My problem with this is that it does not allow me to set a policy of "anything from [a.b.c.d] must use on of the following compression methods. 1a) Because of this, it does not seem to have any way to indicate that compression negotiation failed. 2) Unless I am severely misreading this, there is no way to specify NULL/NULL/NULL for the connection. That is no key exchange, no cipher and no hash. For the anonymous example, this is a serious impediment. This means that using TLS between two SMTP servers, where those servers did not "know" each other would prevent the use of TLS, and hence, any compression that may have been gained is lost. 2a) There are several places in the TLS docs that state that NULL/NULL/NULL is a starting state and is not permitted for the connection, as it does not add any extra security. Because of these "facts" (more like "because of my understanding of the facts presented in the TLS draft"), I would say that mandatory compression is not well suited to TLS due to the above points. As such, I would still like to see extra comments about compression using SASL, be it combining it with existing types or using an extra parameter. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Mon May 18 12:12:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA09429 for ietf-sasl-bks; Mon, 18 May 1998 12:12:22 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA09425 for ; Mon, 18 May 1998 12:12:21 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IX6FQ8HX5M8WVZNL@INNOSOFT.COM> for ietf-sasl@imc.org; Mon, 18 May 1998 12:14:46 PST Date: Mon, 18 May 1998 12:14:46 -0800 (PST) From: Chris Newman Subject: Re: Compression under SASL was Re: Huffman coding? In-reply-to: <3.0.2.32.19980515100406.00b3c2e0@127.0.0.1> To: Harald Alvestrand Cc: 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 On Fri, 15 May 1998, Harald Alvestrand wrote: > Count me as one of those *not* happy with defining compression as > a part of the SASL layer; it's the kitchen sink/hammer analogy again: > burdening a layer with things that do not fit there damages that layer. I'm of the opinion that there should be *at most* one layer between TCP and an application protocol. I prefer putting integrity protection, encryption and compression in the same layer since it saves framing overhead and implementation complexity which would otherwise be necessary. > (If you want to change the scope of SASL, I think it makes much more > sense to define TLS as a SASL mechanism; the special treatment it > gets now may make sense at a microscopic level, but at the 10.000 foot > level it seems sillier every time I look at it.) TLS and SASL have different framing mechanisms for their security layers. So you can't combine them without breaking one or the other security layer. Personally, I think it's convenient they're separate given current usage. SSL/TLS is normally used for server authentication and privacy, while SASL is normally used for client authentication. So it often makes sense to use both at the same time, which would not be possible if they were combined. Now you wouldn't want to use TLS and SASL's security layer at the same time, because that's an unnecessary (and redundant) layer. Finally, I think a compression-only layer is counter-productive. Let's use the desire for compression as a hook to get integrity protection (at least) deployed. - Chris From owner-ietf-sasl Mon May 18 23:05:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA20538 for ietf-sasl-bks; Mon, 18 May 1998 23:05:39 -0700 (PDT) Received: from dokka.kvatro.no (dokka.kvatro.no [193.216.2.164]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA20527 for ; Mon, 18 May 1998 23:05:35 -0700 (PDT) Received: from alden (hosts.maxware.no [195.139.236.139]) by dokka.kvatro.no (8.8.5/8.8.5) with SMTP id IAA25805; Tue, 19 May 1998 08:08:39 +0200 Message-Id: <3.0.2.32.19980518230624.023c71f0@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 18 May 1998 23:06:24 +0200 To: Chris Newman From: Harald Alvestrand Subject: Re: Compression under SASL was Re: Huffman coding? Cc: ietf-sasl@imc.org In-Reply-To: References: <3.0.2.32.19980515100406.00b3c2e0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 12:14 18.05.98 -0800, Chris Newman wrote: >On Fri, 15 May 1998, Harald Alvestrand wrote: >> Count me as one of those *not* happy with defining compression as >> a part of the SASL layer; it's the kitchen sink/hammer analogy again: >> burdening a layer with things that do not fit there damages that layer. > >I'm of the opinion that there should be *at most* one layer between TCP >and an application protocol. I prefer putting integrity protection, >encryption and compression in the same layer since it saves framing >overhead and implementation complexity which would otherwise be necessary. > This reminds me of the "application layer framing" approach that I've seen bandied about around MMUSIC/AVT. It's a good argument. But in that case, we may need to turn SASL into Simple Anything Session Layer, with slots for authentication, encryption, integrity protection and "we haven't thought of it yet". Because combinatorial explosion is still a Bad Thing for deployment. >> (If you want to change the scope of SASL, I think it makes much more >> sense to define TLS as a SASL mechanism; the special treatment it >> gets now may make sense at a microscopic level, but at the 10.000 foot >> level it seems sillier every time I look at it.) > >TLS and SASL have different framing mechanisms for their security layers. >So you can't combine them without breaking one or the other security >layer. SASL as I read it is a way to negotiate into a security layer. >From my 10.000 foot level, I don't see the great difference between the exchanges -> STARTTLS -> AUTHENTICATE TLS <- OK <- OK ...first byte of TLS negotiation starts here in both cases..... >Personally, I think it's convenient they're separate given current usage. >SSL/TLS is normally used for server authentication and privacy, while SASL >is normally used for client authentication. So it often makes sense to >use both at the same time, which would not be possible if they were >combined. ..............actually, why not? the blocking factor I can see is the text in RFC 2222 section 5.3, and we change protocols, don't we? The requirement would be that there at any time be only one of: - client authentication identity - client authorization identity - server authentication identity - server authorization identity (if there is such a thing) - protection mechanism - compression mechanism - integrity mechanism and some renegotiations of one should nullify some others. But I do NOT think adding compression as a property of a SASL mechanism is going to cut it. Unfortunately. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-ietf-sasl Tue May 19 08:44:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA02886 for ietf-sasl-bks; Tue, 19 May 1998 08:44:31 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA02882 for ; Tue, 19 May 1998 08:44:28 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Tue, 19 May 1998 11:48:18 -0400 Message-Id: <3.0.1.32.19980519114829.009932e0@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 19 May 1998 11:48:29 -0400 To: Chris Newman , Harald Alvestrand From: "Jack De Winter" Subject: Re: Compression under SASL was Re: Huffman coding? Cc: ietf-sasl@imc.org In-Reply-To: References: <3.0.2.32.19980515100406.00b3c2e0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@imc.org Precedence: bulk At 12:14 PM 5/18/98 -0800, Chris Newman wrote: >Finally, I think a compression-only layer is counter-productive. Let's >use the desire for compression as a hook to get integrity protection (at >least) deployed. Hrm... how about the case where you would like to provide compresses SMTP access? Now I know that anonymous logins are possible, but unless we frame the compression within something like GSSAPI or SCRAM, we would have to provide -ANON and -CRAM-MD5 as Harald mentioned earlier. However, as Chris has pointed out to me in private, there are probably not going to be that many compression types, so this may not be that bad. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-sasl Tue May 19 14:21:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA05565 for ietf-sasl-bks; Tue, 19 May 1998 14:21:30 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA05561 for ; Tue, 19 May 1998 14:21:30 -0700 (PDT) Received: from elwood.innosoft.com ("port 33031"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IX7YJ6BG8U8WW1OV@INNOSOFT.COM> for ietf-sasl@imc.org; Tue, 19 May 1998 14:23:30 PDT Date: Tue, 19 May 1998 14:25:00 -0700 (PDT) From: Chris Newman Subject: Re: Compression under SASL was Re: Huffman coding? In-reply-to: <3.0.2.32.19980518230624.023c71f0@127.0.0.1> To: Harald Alvestrand Cc: ietf-sasl@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Origin