From owner-ietf-sasl Fri Sep 3 02:56:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839uuDa088212; Fri, 3 Sep 2004 02:56:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i839uuNE088210; Fri, 3 Sep 2004 02:56:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839utwr088198 for ; Fri, 3 Sep 2004 02:56:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 3 Sep 2004 11:02:46 +0100 Message-ID: <41383FE6.7000905@isode.com> Date: Fri, 03 Sep 2004 10:56:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: 2222bis: use of "authentication protocol exchange" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. Kurt wrote: >The problem here is this usage causes the term 'protocol' >to be overloaded, making this and other uses of the term >ambiguous. We need to consistently use the term 'protocol' >to refer to the application-level protocol making use of >SASL. Other protocols, in particular that of mechanisms, >should be referred to by other terms, such as an >'authentication exchange'. The term "authentication protocol exchange" comes from RFC 2222. It tries to say that an "authentication exchange" produced by a SASL mechanism is carried by a SASL aware protocol. (I personally find the original term unambiguous, although it is cumbersome.) So I am a bit worried about changing "authentication protocol exchange" to "authentication exchange" at this stage, as this seems to be a [significant] terminology change from RFC 2222. It is probably Ok to say in the Introduction that "authentication protocol exchange" and "authentication exchange" are synonyms and that the document will use the latter term everywhere. I would like to hear opinions of other WG members. Thanks, Alexey From owner-ietf-sasl Fri Sep 3 06:24:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83DO38a020306; Fri, 3 Sep 2004 06:24:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83DO35u020305; Fri, 3 Sep 2004 06:24:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83DO2lj020292 for ; Fri, 3 Sep 2004 06:24:02 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i83DNuWA024805 for ; Fri, 3 Sep 2004 09:23:56 -0400 (EDT) Message-ID: <41387091.5060509@oceana.com> Date: Fri, 03 Sep 2004 09:24:33 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> In-Reply-To: <41383FE6.7000905@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > Hi, > > The issue discussed below was raised by Kurt. He suggested to replace > "authentication protocol exchange" to "authentication exchange" > everywhere in the document. This change wouldn't bother me. > > Kurt wrote: > >> The problem here is this usage causes the term 'protocol' >> to be overloaded, making this and other uses of the term >> ambiguous. We need to consistently use the term 'protocol' >> to refer to the application-level protocol making use of >> SASL. Other protocols, in particular that of mechanisms, >> should be referred to by other terms, such as an >> 'authentication exchange'. > > > > The term "authentication protocol exchange" comes from RFC 2222. It > tries to say that an "authentication exchange" produced by a SASL > mechanism is carried by a SASL aware protocol. (I personally find the > original term unambiguous, although it is cumbersome.) So I am a bit > worried about changing "authentication protocol exchange" to > "authentication exchange" at this stage, as this seems to be a > [significant] terminology change from RFC 2222. > > It is probably Ok to say in the Introduction that "authentication > protocol exchange" and "authentication exchange" are synonyms and that > the document will use the latter term everywhere. > > I would like to hear opinions of other WG members. > > Thanks, > Alexey > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Sep 3 07:21:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ELXhn024271; Fri, 3 Sep 2004 07:21:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83ELX4w024270; Fri, 3 Sep 2004 07:21:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ELVh3024261 for ; Fri, 3 Sep 2004 07:21:32 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 3 Sep 2004 15:27:15 +0100 Message-ID: <41387DE1.60100@isode.com> Date: Fri, 03 Sep 2004 15:21:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> In-Reply-To: <41387091.5060509@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> The issue discussed below was raised by Kurt. He suggested to replace >> "authentication protocol exchange" to "authentication exchange" >> everywhere in the document. > > This change wouldn't bother me. Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: 1). I don't care either way. 2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. 3). Must change "authentication protocol exchange" to "authentication exchange". Having said that, are you #1 or #2? Alexey From owner-ietf-sasl Fri Sep 3 07:40:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Eehnc025630; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83EehBt025629; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Eeg3k025623 for ; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i83Eeeu8031205; Fri, 3 Sep 2004 10:40:40 -0400 (EDT) Message-ID: <4138828C.5070203@oceana.com> Date: Fri, 03 Sep 2004 10:41:16 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> In-Reply-To: <41387DE1.60100@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > >>> The issue discussed below was raised by Kurt. He suggested to replace >>> "authentication protocol exchange" to "authentication exchange" >>> everywhere in the document. >> >> >> This change wouldn't bother me. > > > Let me clarify what kind of answers I was expecting to my question. I > would like to hear something like: > 1). I don't care either way. > 2). I prefer that all occurrences of "authentication protocol exchange" > are changed to "authentication exchange", but I am Ok if this is not done. > 3). Must change "authentication protocol exchange" to "authentication > exchange". > > Having said that, are you #1 or #2? #2 -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Sep 3 08:01:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83F1RPV028115; Fri, 3 Sep 2004 08:01:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83F1RJQ028114; Fri, 3 Sep 2004 08:01:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83F1Qq6028105 for ; Fri, 3 Sep 2004 08:01:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i83F1RMw098436; Fri, 3 Sep 2004 15:01:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 03 Sep 2004 08:02:06 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: 2222bis: use of "authentication protocol exchange" Cc: Ken Murchison , SASL WG In-Reply-To: <41387DE1.60100@isode.com> References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let me re-iterate my basic concern. The specification uses the term 'protocol' in general to refer to the application-level protocol which is profiling SASL. Using the term in other contexts is confusing. For instance, the statement that "A SASL mechanism is responsible for conducting an authentication protocol exchange" is unnecessarily confusing. By dropping the word "protocol" from this sentence, it is more clear that the mechanism is responsible for the authentication exchange (which is defined in the next sentence as a series of challenges and responses) and not the actual protocol for carrying the exchange. I note that the current I-D already uses the terms "authentication exchange" instead of "authentication protocol exchange" in numerous places. My suggestion is to always use the term "authentication exchange" in place of "authentication protocol exchange". I view this as an editorial change that will improve specification clarity. With chair hat off, Kurt At 07:21 AM 9/3/2004, Alexey Melnikov wrote: >>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. >> >>This change wouldn't bother me. > >Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: >1). I don't care either way. >2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. >3). Must change "authentication protocol exchange" to "authentication exchange". > >Having said that, are you #1 or #2? > >Alexey > From owner-ietf-sasl Fri Sep 3 12:02:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J2qSo047735; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83J2qho047734; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from infoblox.com (daneel.infoblox.com [128.242.99.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J2q3b047709 for ; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) (envelope-from morteza@infoblox.com) Received: from [192.129.1.150] (adsl-67-112-201-44.dsl.sntc01.pacbell.net [67.112.201.44]) by infoblox.com (Postfix) with ESMTP id DF2E02A33F; Fri, 3 Sep 2004 12:03:01 -0700 (PDT) Message-ID: <4138BFDA.4090609@infoblox.com> Date: Fri, 03 Sep 2004 12:02:50 -0700 From: Morteza Ansari User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , Ken Murchison , SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: #2. Cheers, Morteza Kurt D. Zeilenga wrote: > Let me re-iterate my basic concern. The specification uses the > term 'protocol' in general to refer to the application-level > protocol which is profiling SASL. Using the term in other > contexts is confusing. > > For instance, the statement that "A SASL mechanism is responsible > for conducting an authentication protocol exchange" is unnecessarily > confusing. By dropping the word "protocol" from this sentence, > it is more clear that the mechanism is responsible for the > authentication exchange (which is defined in the next sentence > as a series of challenges and responses) and not the actual > protocol for carrying the exchange. > > I note that the current I-D already uses the terms "authentication > exchange" instead of "authentication protocol exchange" in numerous > places. My suggestion is to always use the term "authentication > exchange" in place of "authentication protocol exchange". I view > this as an editorial change that will improve specification > clarity. > > With chair hat off, Kurt > > At 07:21 AM 9/3/2004, Alexey Melnikov wrote: > > > >>>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. >>> >>>This change wouldn't bother me. >> >>Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: >>1). I don't care either way. >>2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. >>3). Must change "authentication protocol exchange" to "authentication exchange". >> >>Having said that, are you #1 or #2? >> >>Alexey >> From owner-ietf-sasl Mon Sep 6 20:22:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873MFgd045276; Mon, 6 Sep 2004 20:22:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i873MFDH045275; Mon, 6 Sep 2004 20:22:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873ME2Z045257 for ; Mon, 6 Sep 2004 20:22:14 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i873M9XD012172 for ; Mon, 6 Sep 2004 22:22:09 -0500 Received: from [135.210.112.45] (unknown[135.210.112.45](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040907032243gw1002eunte> (Authid: tony); Tue, 7 Sep 2004 03:22:43 +0000 Message-ID: <413D2963.2000408@att.com> Date: Mon, 06 Sep 2004 23:22:11 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> In-Reply-To: <41387DE1.60100@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Let me clarify what kind of answers I was expecting to my question. I > would like to hear something like: > 1). I don't care either way. > 2). I prefer that all occurrences of "authentication protocol exchange" > are changed to "authentication exchange", but I am Ok if this is not done. > 3). Must change "authentication protocol exchange" to "authentication > exchange". #1 Tony Hansen tony@att.com From owner-ietf-sasl Wed Sep 8 12:36:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JaueT092807; Wed, 8 Sep 2004 12:36:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88JauJS092806; Wed, 8 Sep 2004 12:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Jasbu092799 for ; Wed, 8 Sep 2004 12:36:54 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09900; Wed, 8 Sep 2004 15:36:56 -0400 (EDT) Message-Id: <200409081936.PAA09900@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-04.txt Date: Wed, 08 Sep 2004 15:36:55 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, et al. Filename : draft-ietf-sasl-rfc2831bis-04.txt Pages : 45 Date : 2004-9-8 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-8154411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154411.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Sep 10 03:00:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AA0Z3I057992; Fri, 10 Sep 2004 03:00:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AA0ZqG057991; Fri, 10 Sep 2004 03:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AA0XHX057978 for ; Fri, 10 Sep 2004 03:00:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 11:06:39 +0100 Message-ID: <4140C7D6.5060206@isode.com> Date: Thu, 09 Sep 2004 22:15:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry about the delay, I've integrated all other comments received so far.] Kurt D. Zeilenga wrote: >>Would you mind explaining the problem you had with this section in >>better detail? I thought it flowed fairly well and is a significant >>improvement on our previous attempts to describe this issue. However >>I might well miss problems because as someone who has been following >>SASL I'm familiar with the issue. I am not always good at reading a >>document as someone new to a technology. >> >> > >Sure. The following 3.2 text: > > >> The processing model is as follows. A server, upon completion of the >> authentication mechanism, uses the results produced by the >> authentication mechanism, the client-provided authorization identity >> value (which may be the empty string), and local policy information >> to derive an authorization identity. >> >> > >clearly shows the document is using the term 'authorization identity' >to refer, at times, to the client-provided authorization identity >and, at times, to a derived authorization identity. However, in >other portions of the document, the term 'authorization identity' >is mostly used unqualified. > Right. I agree this is an issue. > >While qualification of the term would likely resolve this >issue, that solution would likely be cumbersome. As the >'authorization identity' more properly refers to the identity >directly used in authorization, it seems more appropriate >to call the value referred to here as the 'client-provided >authorization identity' as the 'proxied identity'. > > [...] >I've been trying to come with a new term to call the derived >identity to allow us unambiguously use the term 'authorization >identity' to refer to the client provided value, as the WG >seems to have some attachment to this usage. The best I >have come with here is 'subject identity' (the identity which >is the subject in access control decisions). > >I do not recommend this approach myself as I believe it >would be more proper to use the term 'authorization identity' >to refer to the subject of access control decisions. > I would actually strongly prefer not to do that, as this will make everybody very confused. At least I am pretty sure I will be. "Subject identity" might be a bit ugly, but it is not so bad ;-) >However, I am far more concerned about ambiguous use of >the term (using the term to refer to two different values) >than I am about which of the two uses continues to this >term. That is, I can live with calling the client provided >value an 'authorization identity' if we don't also use that >term to refer to the derived identity. > > Ok, I will do the change. Alexey From owner-ietf-sasl Fri Sep 10 03:33:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AAXxVn071680; Fri, 10 Sep 2004 03:33:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AAXx4g071679; Fri, 10 Sep 2004 03:33:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from inf.puc-rio.br (exu.inf.puc-rio.br [139.82.16.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AAXtdr071634 for ; Fri, 10 Sep 2004 03:33:58 -0700 (PDT) (envelope-from silvana@inf.puc-rio.br) Received: (from apache@localhost) by inf.puc-rio.br (8.11.6/8.11.6) id i8AAXrq09366; Fri, 10 Sep 2004 07:33:53 -0300 X-Authentication-Warning: exu.inf.puc-rio.br: apache set sender to silvana@inf.puc-rio.br using -f Received: from 131.175.124.56 (SquirrelMail authenticated user silvana); by webmail.inf.puc-rio.br with HTTP; Fri, 10 Sep 2004 07:33:53 -0300 (EST) Message-ID: <32873.131.175.124.56.1094812433.squirrel@131.175.124.56> Date: Fri, 10 Sep 2004 07:33:53 -0300 (EST) Subject: From: "Silvana Rossetto" To: ietf-sasl@imc.org User-Agent: SquirrelMail/1.4.3a-0.1.7.x X-Mailer: SquirrelMail/1.4.3a-0.1.7.x MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-sasl Fri Sep 10 09:57:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGv9Hf009070; Fri, 10 Sep 2004 09:57:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AGv9fh009069; Fri, 10 Sep 2004 09:57:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGv8ge009063 for ; Fri, 10 Sep 2004 09:57:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 18:03:16 +0100 Message-ID: <4141DCCB.5080309@isode.com> Date: Fri, 10 Sep 2004 17:56:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > When a client requests a specific identity, do we consider it > desirable for the server to be able to use some arbitrary other > identity instead? No. The server should either "obey" or fail authentication. From owner-ietf-sasl Fri Sep 10 09:45:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGjMpq008229; Fri, 10 Sep 2004 09:45:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AGjM7N008228; Fri, 10 Sep 2004 09:45:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AGjLUg008221 for ; Fri, 10 Sep 2004 09:45:21 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03697; 10 Sep 2004 12:45 EDT Date: Fri, 10 Sep 2004 12:45:19 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <4140C7D6.5060206@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, September 09, 2004 22:15:02 +0100 Alexey Melnikov wrote: > Kurt D. Zeilenga wrote: > >> While qualification of the term would likely resolve this >> issue, that solution would likely be cumbersome. As the >> 'authorization identity' more properly refers to the identity >> directly used in authorization, it seems more appropriate >> to call the value referred to here as the 'client-provided >> authorization identity' as the 'proxied identity'. Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. Sure, if I connect to one of the cyrus.andrew IMAP backends using a requested authorization ID of 'jhutz' and provide credentials proving I am a front end, then there is a proxy relationship. However, if I make the same request with credentials belonging to the Kerberos principal jhutz@CS.CMU.EDU, there is _no_ proxy relationship. And in either case, the client is not _authenticating_ as 'jhutz' at all -- the only authentication is of the authentication ID provided by the mechanism, and all the client is doing here is asking the server to allow it to _act- as the user 'jhutz'. It's bad enough that people use the confusing phrase "proxy authentication" to refer to this situation when it is neither authentication nor necessarily involves any proxy relationship. Let's not compound the problem by introducing additional confusing uses of the word 'proxy'. Instead, let's refer to the identity provided by the client and transported by SASL over the wire as the 'requested' identity. Then the server derives the authorization identity based on the authentication identity, the requested identity, and local policy. In case it is not clear, I fully agree here that the phrase "authorization identity" should be used to refer to the identity actually used in making authorization decisions, and not that requested by the client. While some of us may need to get used to the new usage, I don't think that's as big a problem as will be caused by implementors and protocol designers being confused into thinking they should used the requested identity rather than the derived one for authorization decisions. Incidentally, this whole discussion reminds me of an issue that occurred to me while re-reading the document earlier this week. It is not at all clear to me that the requested and derived identities are permitted to be different, except in the case where the requested identity is the empty string. Operationally, my expectation has always been that you have two choices - either allow the server to derive an identity from the authentication ID, or ask for a specific one which the server can either accept or reject. When a client requests a specific identity, do we consider it desirable for the server to be able to use some arbitrary other identity instead? -- Jeff From owner-ietf-sasl Fri Sep 10 10:08:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH8WLJ010112; Fri, 10 Sep 2004 10:08:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AH8WgB010111; Fri, 10 Sep 2004 10:08:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH8UMX010104 for ; Fri, 10 Sep 2004 10:08:31 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 18:14:45 +0100 Message-ID: <4141DF7F.2070301@isode.com> Date: Fri, 10 Sep 2004 18:08:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > Instead, let's refer to the identity provided by the client and > transported by SASL over the wire as the 'requested' identity. Then > the server derives the authorization identity based on the > authentication identity, the requested identity, and local policy. The document is mostly talking about the requested identity. The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. > In case it is not clear, I fully agree here that the phrase > "authorization identity" should be used to refer to the identity > actually used in making authorization decisions, and not that > requested by the client. > While some of us may need to get used to the new usage, I don't > think that's as big a problem as will be caused by implementors and > protocol designers being confused into thinking they should used the > requested identity rather than the derived one for authorization > decisions. > > > > Incidentally, this whole discussion reminds me of an issue that > occurred to me while re-reading the document earlier this week. It is > not at all clear to me that the requested and derived identities are > permitted to be different, except in the case where the requested > identity is the empty string. If you are talking about semantics of the two - you are right, they are referring to the same entity. But of course the syntax of the derived identity is implementation specific and out of scope for SASL and doesn't have to be the same as the protocol specific syntax for authorization (requested) identities. From owner-ietf-sasl Fri Sep 10 10:04:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH4iY9009873; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AH4i7T009872; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AH4hMj009866 for ; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03769; 10 Sep 2004 13:04 EDT Date: Fri, 10 Sep 2004 13:04:17 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <106830000.1094835857@minbar.fac.cs.cmu.edu> In-Reply-To: <4141DCCB.5080309@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DCCB.5080309@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, September 10, 2004 17:56:43 +0100 Alexey Melnikov wrote: > > Jeffrey Hutzelman wrote: > >> When a client requests a specific identity, do we consider it >> desirable for the server to be able to use some arbitrary other >> identity instead? > > No. The server should either "obey" or fail authentication. OK. I'm inclined to agree, and I think the document should state this more explicitly. Further, if that is the case, then I think the distinction between the requested and derived identities is much less significant -- if there is a requested ID, they will be the same or the exchange will fail. From owner-ietf-sasl Fri Sep 10 10:32:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHWXG5011867; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AHWXGZ011866; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHWWpl011856 for ; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AHWWMw056764; Fri, 10 Sep 2004 17:32:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 10:33:09 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote: >Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. I wouldn't object to use of another term, such as 'asserted identity' or something. My concern is that the document uses confusing terminology to refer to the three distinct identities (the identity associated with credentials, a client provide identity, the identity the server uses to make authorization decisions) it discusses. The document should use three distinct terms for refer to each distinct identities it discusses. (Note that in my use of distinct above, I do not intend to imply that each of these identities could not refer the same user (or application entity). I intend to imply that they each has distinct characteristics (as discussed in the I-D) within the SASL identity model). Kurt From owner-ietf-sasl Fri Sep 10 10:54:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHsSrK013581; Fri, 10 Sep 2004 10:54:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AHsS3i013580; Fri, 10 Sep 2004 10:54:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHsRIN013574 for ; Fri, 10 Sep 2004 10:54:27 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AHsUMw056926; Fri, 10 Sep 2004 17:54:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 10:55:06 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Jeffrey Hutzelman , ietf-sasl@imc.org In-Reply-To: <4141DF7F.2070301@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:08 AM 9/10/2004, Alexey Melnikov wrote: >The document is mostly talking about the requested identity. Expecting the document explicitly says the identity used in making authorization decisions is derived from the credentials and the requested identity. (Note that I have suggested that even this statement be clarified as being 'conceptional' in nature.) >The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. Yes, as are the particulars of the derivation. Note that LDAP is a protocol where, in most implementations (LDAP doesn't have standardized schema for representing authorization policy), the identity form used in making authorization decisions (generally a DN) is not the same form of the SASL requested identity (a LDAP authzId [RFC2829]). (Below I am going to refer to the identity used in making authorization decisions as the subject identity.) I also note that derivation also allows a level of indication which some implementations may take advantage of. For instance, consider a server which has two groups of users. Though each user authenticates as themselves, and requests implicitly or explicitly to assume their own identity, the server is free to map all users in one group to an identity associated with the group. That is, there may be a many-to-1 relationship between requested and subject identities. Also, it is allowed that the server base the mapping of requested to subject identities on other factors. This implies that there is also a 1-to-many relationship between requested and subject identities. I think it best for the particulars of identity mappings to be left out-of-scope. Kurt From owner-ietf-sasl Fri Sep 10 11:09:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI91MQ014582; Fri, 10 Sep 2004 11:09:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AI91Bv014581; Fri, 10 Sep 2004 11:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AI90MF014571 for ; Fri, 10 Sep 2004 11:09:00 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03832; 10 Sep 2004 14:08 EDT Date: Fri, 10 Sep 2004 14:08:44 -0400 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <118020000.1094839724@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" wrote: > (Below I am going to refer to the identity used in making > authorization decisions as the subject identity.) Maybe it would be best if we avoided the term "authorization identity" at all. Or maybe not. Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not.... From owner-ietf-sasl Fri Sep 10 11:06:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI6Q6E014418; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AI6Qvm014417; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI6QCa014409 for ; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AI6TMw056989; Fri, 10 Sep 2004 18:06:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910110349.040ccee8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 11:07:05 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:33 AM 9/10/2004, Kurt D. Zeilenga wrote: >At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote: >>Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. > >I wouldn't object to use of another term, such as 'asserted identity' >or something. or 'requested identity'. I'm fine with your terminology suggestion. Kurt From owner-ietf-sasl Fri Sep 10 11:46:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AIkgt4017041; Fri, 10 Sep 2004 11:46:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AIkg5c017040; Fri, 10 Sep 2004 11:46:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AIkf8I017022 for ; Fri, 10 Sep 2004 11:46:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AIkcMw057163; Fri, 10 Sep 2004 18:46:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910112813.041667c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 11:47:15 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <118020000.1094839724@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> <118020000.1094839724@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:08 AM 9/10/2004, Jeffrey Hutzelman wrote: >On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" wrote: > >>(Below I am going to refer to the identity used in making >>authorization decisions as the subject identity.) > >Maybe it would be best if we avoided the term "authorization identity" at all. Or maybe not. I prefer to use the term "authorization identity" to refer to the subject of authorization decisions in the I-D. For the client-provided identity, I prefer "requested identity". (I only used the term "subject identity" in my email to avoid ambiguity of the I-D terms, and didn't intend to suggest that this term be used in the I-D.) >Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not.... I think it appropriate to outlining the identity concepts while being clear that the described relationship between the identities is only conceptual. Protocol specifications and their implementation have a lot of freedom (and that freedom, I would argue, is necessary to make things work). Kurt From owner-ietf-sasl Fri Sep 24 09:13:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGDSJa001179; Fri, 24 Sep 2004 09:13:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OGDScc001178; Fri, 24 Sep 2004 09:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGDRJ4001172 for ; Fri, 24 Sep 2004 09:13:27 -0700 (PDT) (envelope-from apache@megatron.ietf.org) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CAsT9-00029B-BN; Fri, 24 Sep 2004 11:58:47 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , sasl mailing list , sasl chair , sasl chair Subject: Protocol Action: 'SASLprep: Stringprep profile for user names and passwords' to Proposed Standard Message-Id: Date: Fri, 24 Sep 2004 11:58:47 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'SASLprep: Stringprep profile for user names and passwords ' as a Proposed Standard This document is the product of the Simple Authentication and Security Layer Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document describes the preparation of Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names or passwords. Working Group Summary The SASL Working Group came to rough consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. From owner-ietf-sasl Fri Sep 24 12:40:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJeJrL017972; Fri, 24 Sep 2004 12:40:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OJeJWa017971; Fri, 24 Sep 2004 12:40:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJeImt017955 for ; Fri, 24 Sep 2004 12:40:18 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8OJeKZv014103 for ; Fri, 24 Sep 2004 19:40:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 24 Sep 2004 12:40:30 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Summary of 2222bis WGLC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The chairs initiated a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt on 21 July 2004. The last call period, though originally scheduled to close 13 August 2004, was extended to allow additional review and discussion. All comments received prior to the posting of this summary were considered. The last call period is now closed. ISSUE SUMMARY Below is a summary of the issues of substance raised. For each, the chairs provide a statement of regarding the actions it believes are/aren't supported by WG consensus. Additionally, a number of editorial issues were raised and referred to the Editor for appropriate action. 1) Re-keying of security layers Nico indicated that the I-D did not discuss Re-keying of security layers and suggested text in this area be added. The WG discussed a number of specific suggestions in this area, with the following text being the last version submitted for WG consideration: SASL mechanisms that support re-keying SHOULD: - indicate that re-keying is or will be needed immediately; - provide re-keying messages or transparently include re-keying messages in the security layers; the latter can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. The chairs believes the WG supports addition of this text. 2) Detail Hiding Sam indicated the I-D claims that the layer does not generally hide the details of mechanisms from protocols and suggested this was an accurate reflection of what the WG intended to state. He suggested the I-D to be revised to state that while the layer hides the details of protocols from mechanisms and the details of mechanisms from protocols, it does not hide the details of mechanisms from protocol implementations. The chairs conclude the WG supports revising the I-D as Sam suggests here. 3) Confidentiality and Integrity Sam indicated that the I-D states "confidentiality protection usually implies integrity protection" and that this was less than ideal from a security standard point. He suggested that the word 'usually' be deleted. Nico suggested revising the specification to explicitly require future mechanisms which provide a confidentiality protection service to provide include integrity protection with that service. The chairs conclude the WG supports revising the I-D as Sam suggests here. The chairs conclude that the WG supports allowing mechanisms to "offer other kinds of security services" and hence does not adding the requirement upon future mechanisms suggested by Nico. 4) Channel Binding Nico asked whether the I-D should include text regarding channel binding issues. He suggest security consideration text that clients using SASL over TLS should verify the server's TLS identity to prevent MITM attacks. He also suggested adding text encouraging future mechanisms support channel bindings. The chairs conclude that the WG supports the former suggestion but not the latter. 5) Identities and Authorization Kurt indicated that the I-D use of term "authorization identity" is confusing and suggested use of different terms for each distinct use of this term. Jeffery suggested using the terms: "authentication identity" to refer to the identity associated with the users creditials, "requested identity" to refer to identity which the user requests to act as, and "authorization identity" to refer to identity used by the server in making authorization decisions. (The latter being derived from by former two.) The chairs conclude the WG supports use of this suggested terminology. 6) Empty initial response I Ken suggested that the SHOULD in "the protocol profile SHOULD also describe how an empty initial response is encoded" ought to be a MUST. The chairs conclude the WG supports this change. 7) Empty initial response II Ken asked whether the I-D should explicitly state that the profile also needs to describe how *empty* server challenges and client responses as encoded. Alexey respond as to why he believes the I-D is sufficiently clear here. The chairs that the WG supports making no change here. 8) EXTERNAL use of external information Ken suggested replacing "authenticate as" in the I-D text: The server uses information, external to SASL, to determine whether the client is permitted to authenticate as the authorization identity. with "have the access privileges of". Alexey suggested it be replaced with "to act as". The chairs conclude the WG supports this the change suggested by Alexey. GENERAL CONCLUSION and NEXT STEPS The chairs believe that WG consensus supports a recommendation of this I-D, once the above issues are appropriate addressed, to the IESG for publication as a Proposed Standard replacing RFC 2222. The chairs believes its above conclusions regarding supported actions accurately reflect WG consensus and hence direct the Editor to prepare a revision making the changes for which chairs have indicated are supported by the WG. The chairs believes its above conclusions regarding supported actions accurately reflect WG consensus. If you believe the chairs have misread consensus, please indicate so by email as soon as possible. If you believe the above summary is incomplete, please indicate by email as soon as possible. After giving the WG sufficient time (1 week) to verify that the actually changes made are consistent with WG consensus, the chairs intend to recommend the revised I-D to the IESG for consideration as a Proposed Standard. The chairs do not foresee the need to subject this I-D to another WG Last Call. Kurt & Sam, SASL co-chairs From owner-ietf-sasl Mon Sep 27 07:48:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8REm0Kh093464; Mon, 27 Sep 2004 07:48:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8REm0Rf093463; Mon, 27 Sep 2004 07:48:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RElxXc093455 for ; Mon, 27 Sep 2004 07:47:59 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CBwnG-0002c5-Pg for ietf-sasl@imc.org; Mon, 27 Sep 2004 16:47:58 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CBwmx-0008GU-1F; Mon, 27 Sep 2004 16:47:39 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CBwmw-0004VQ-00; Mon, 27 Sep 2004 16:47:38 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: authentication identity Date: Mon, 27 Sep 2004 16:47:38 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I sent this message in April, but received no reply and forgot about it. And now I discovered that I was no longer subscribed to ietf-sasl:-( rfc2222bis has added the concept of an authentication identity since rfc2222. Is this identity only a parameter to the SASL authentication process, and can be discarded after SASL authentication is complete? Or is it also part of the connecton's authorization state after SASL authentication? If so, what for? Could you clarify that in the draft? Is this too late now? If so, can someone explain anyway? (I'm wondering if I should suggest that the LDAP authmeth draft removes the authentication ID from the association (session state), or if it should mention what it can be used for.) -- Hallvard From owner-ietf-sasl Tue Sep 28 03:59:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SAxqdx090987; Tue, 28 Sep 2004 03:59:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SAxqau090986; Tue, 28 Sep 2004 03:59:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SAxpDE090953 for ; Tue, 28 Sep 2004 03:59:51 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CCFi1-0001aA-8q for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:49 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CCFhx-0006Kf-Bi for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:45 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CCFhw-0007Ye-00 for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:44 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: rfc2222bis: authentication identity In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 28 Sep 2004 12:59:44 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth writes: > I sent this message in April, but received no reply and forgot about it. > (...) Never mind - I was mixing up which concepts belong in SASL and which ones belong in protocols using SASL. Alexey set me straight. -- Hallvard From owner-ietf-sasl Fri Sep 3 02:56:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839uuDa088212; Fri, 3 Sep 2004 02:56:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i839uuNE088210; Fri, 3 Sep 2004 02:56:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839utwr088198 for ; Fri, 3 Sep 2004 02:56:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 3 Sep 2004 11:02:46 +0100 Message-ID: <41383FE6.7000905@isode.com> Date: Fri, 03 Sep 2004 10:56:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: 2222bis: use of "authentication protocol exchange" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. Kurt wrote: >The problem here is this usage causes the term 'protocol' >to be overloaded, making this and other uses of the term >ambiguous. We need to consistently use the term 'protocol' >to refer to the application-level protocol making use of >SASL. Other protocols, in particular that of mechanisms, >should be referred to by other terms, such as an >'authentication exchange'. The term "authentication protocol exchange" comes from RFC 2222. It tries to say that an "authentication exchange" produced by a SASL mechanism is carried by a SASL aware protocol. (I personally find the original term unambiguous, although it is cumbersome.) So I am a bit worried about changing "authentication protocol exchange" to "authentication exchange" at this stage, as this seems to be a [significant] terminology change from RFC 2222. It is probably Ok to say in the Introduction that "authentication protocol exchange" and "authentication exchange" are synonyms and that the document will use the latter term everywhere. I would like to hear opinions of other WG members. Thanks, Alexey From owner-ietf-sasl Fri Sep 3 06:24:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83DO38a020306; Fri, 3 Sep 2004 06:24:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83DO35u020305; Fri, 3 Sep 2004 06:24:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83DO2lj020292 for ; Fri, 3 Sep 2004 06:24:02 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i83DNuWA024805 for ; Fri, 3 Sep 2004 09:23:56 -0400 (EDT) Message-ID: <41387091.5060509@oceana.com> Date: Fri, 03 Sep 2004 09:24:33 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> In-Reply-To: <41383FE6.7000905@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > Hi, > > The issue discussed below was raised by Kurt. He suggested to replace > "authentication protocol exchange" to "authentication exchange" > everywhere in the document. This change wouldn't bother me. > > Kurt wrote: > >> The problem here is this usage causes the term 'protocol' >> to be overloaded, making this and other uses of the term >> ambiguous. We need to consistently use the term 'protocol' >> to refer to the application-level protocol making use of >> SASL. Other protocols, in particular that of mechanisms, >> should be referred to by other terms, such as an >> 'authentication exchange'. > > > > The term "authentication protocol exchange" comes from RFC 2222. It > tries to say that an "authentication exchange" produced by a SASL > mechanism is carried by a SASL aware protocol. (I personally find the > original term unambiguous, although it is cumbersome.) So I am a bit > worried about changing "authentication protocol exchange" to > "authentication exchange" at this stage, as this seems to be a > [significant] terminology change from RFC 2222. > > It is probably Ok to say in the Introduction that "authentication > protocol exchange" and "authentication exchange" are synonyms and that > the document will use the latter term everywhere. > > I would like to hear opinions of other WG members. > > Thanks, > Alexey > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Sep 3 07:21:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ELXhn024271; Fri, 3 Sep 2004 07:21:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83ELX4w024270; Fri, 3 Sep 2004 07:21:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ELVh3024261 for ; Fri, 3 Sep 2004 07:21:32 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 3 Sep 2004 15:27:15 +0100 Message-ID: <41387DE1.60100@isode.com> Date: Fri, 03 Sep 2004 15:21:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> In-Reply-To: <41387091.5060509@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> The issue discussed below was raised by Kurt. He suggested to replace >> "authentication protocol exchange" to "authentication exchange" >> everywhere in the document. > > This change wouldn't bother me. Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: 1). I don't care either way. 2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. 3). Must change "authentication protocol exchange" to "authentication exchange". Having said that, are you #1 or #2? Alexey From owner-ietf-sasl Fri Sep 3 07:40:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Eehnc025630; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83EehBt025629; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Eeg3k025623 for ; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i83Eeeu8031205; Fri, 3 Sep 2004 10:40:40 -0400 (EDT) Message-ID: <4138828C.5070203@oceana.com> Date: Fri, 03 Sep 2004 10:41:16 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> In-Reply-To: <41387DE1.60100@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > >>> The issue discussed below was raised by Kurt. He suggested to replace >>> "authentication protocol exchange" to "authentication exchange" >>> everywhere in the document. >> >> >> This change wouldn't bother me. > > > Let me clarify what kind of answers I was expecting to my question. I > would like to hear something like: > 1). I don't care either way. > 2). I prefer that all occurrences of "authentication protocol exchange" > are changed to "authentication exchange", but I am Ok if this is not done. > 3). Must change "authentication protocol exchange" to "authentication > exchange". > > Having said that, are you #1 or #2? #2 -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Sep 3 08:01:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83F1RPV028115; Fri, 3 Sep 2004 08:01:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83F1RJQ028114; Fri, 3 Sep 2004 08:01:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83F1Qq6028105 for ; Fri, 3 Sep 2004 08:01:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i83F1RMw098436; Fri, 3 Sep 2004 15:01:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 03 Sep 2004 08:02:06 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: 2222bis: use of "authentication protocol exchange" Cc: Ken Murchison , SASL WG In-Reply-To: <41387DE1.60100@isode.com> References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let me re-iterate my basic concern. The specification uses the term 'protocol' in general to refer to the application-level protocol which is profiling SASL. Using the term in other contexts is confusing. For instance, the statement that "A SASL mechanism is responsible for conducting an authentication protocol exchange" is unnecessarily confusing. By dropping the word "protocol" from this sentence, it is more clear that the mechanism is responsible for the authentication exchange (which is defined in the next sentence as a series of challenges and responses) and not the actual protocol for carrying the exchange. I note that the current I-D already uses the terms "authentication exchange" instead of "authentication protocol exchange" in numerous places. My suggestion is to always use the term "authentication exchange" in place of "authentication protocol exchange". I view this as an editorial change that will improve specification clarity. With chair hat off, Kurt At 07:21 AM 9/3/2004, Alexey Melnikov wrote: >>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. >> >>This change wouldn't bother me. > >Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: >1). I don't care either way. >2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. >3). Must change "authentication protocol exchange" to "authentication exchange". > >Having said that, are you #1 or #2? > >Alexey > From owner-ietf-sasl Fri Sep 3 12:02:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J2qSo047735; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83J2qho047734; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from infoblox.com (daneel.infoblox.com [128.242.99.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J2q3b047709 for ; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) (envelope-from morteza@infoblox.com) Received: from [192.129.1.150] (adsl-67-112-201-44.dsl.sntc01.pacbell.net [67.112.201.44]) by infoblox.com (Postfix) with ESMTP id DF2E02A33F; Fri, 3 Sep 2004 12:03:01 -0700 (PDT) Message-ID: <4138BFDA.4090609@infoblox.com> Date: Fri, 03 Sep 2004 12:02:50 -0700 From: Morteza Ansari User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , Ken Murchison , SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: #2. Cheers, Morteza Kurt D. Zeilenga wrote: > Let me re-iterate my basic concern. The specification uses the > term 'protocol' in general to refer to the application-level > protocol which is profiling SASL. Using the term in other > contexts is confusing. > > For instance, the statement that "A SASL mechanism is responsible > for conducting an authentication protocol exchange" is unnecessarily > confusing. By dropping the word "protocol" from this sentence, > it is more clear that the mechanism is responsible for the > authentication exchange (which is defined in the next sentence > as a series of challenges and responses) and not the actual > protocol for carrying the exchange. > > I note that the current I-D already uses the terms "authentication > exchange" instead of "authentication protocol exchange" in numerous > places. My suggestion is to always use the term "authentication > exchange" in place of "authentication protocol exchange". I view > this as an editorial change that will improve specification > clarity. > > With chair hat off, Kurt > > At 07:21 AM 9/3/2004, Alexey Melnikov wrote: > > > >>>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. >>> >>>This change wouldn't bother me. >> >>Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: >>1). I don't care either way. >>2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. >>3). Must change "authentication protocol exchange" to "authentication exchange". >> >>Having said that, are you #1 or #2? >> >>Alexey >> From owner-ietf-sasl Mon Sep 6 20:22:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873MFgd045276; Mon, 6 Sep 2004 20:22:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i873MFDH045275; Mon, 6 Sep 2004 20:22:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873ME2Z045257 for ; Mon, 6 Sep 2004 20:22:14 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i873M9XD012172 for ; Mon, 6 Sep 2004 22:22:09 -0500 Received: from [135.210.112.45] (unknown[135.210.112.45](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040907032243gw1002eunte> (Authid: tony); Tue, 7 Sep 2004 03:22:43 +0000 Message-ID: <413D2963.2000408@att.com> Date: Mon, 06 Sep 2004 23:22:11 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> In-Reply-To: <41387DE1.60100@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Let me clarify what kind of answers I was expecting to my question. I > would like to hear something like: > 1). I don't care either way. > 2). I prefer that all occurrences of "authentication protocol exchange" > are changed to "authentication exchange", but I am Ok if this is not done. > 3). Must change "authentication protocol exchange" to "authentication > exchange". #1 Tony Hansen tony@att.com From owner-ietf-sasl Wed Sep 8 12:36:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JaueT092807; Wed, 8 Sep 2004 12:36:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88JauJS092806; Wed, 8 Sep 2004 12:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Jasbu092799 for ; Wed, 8 Sep 2004 12:36:54 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09900; Wed, 8 Sep 2004 15:36:56 -0400 (EDT) Message-Id: <200409081936.PAA09900@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-04.txt Date: Wed, 08 Sep 2004 15:36:55 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, et al. Filename : draft-ietf-sasl-rfc2831bis-04.txt Pages : 45 Date : 2004-9-8 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-8154411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154411.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Sep 10 03:00:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AA0Z3I057992; Fri, 10 Sep 2004 03:00:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AA0ZqG057991; Fri, 10 Sep 2004 03:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AA0XHX057978 for ; Fri, 10 Sep 2004 03:00:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 11:06:39 +0100 Message-ID: <4140C7D6.5060206@isode.com> Date: Thu, 09 Sep 2004 22:15:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry about the delay, I've integrated all other comments received so far.] Kurt D. Zeilenga wrote: >>Would you mind explaining the problem you had with this section in >>better detail? I thought it flowed fairly well and is a significant >>improvement on our previous attempts to describe this issue. However >>I might well miss problems because as someone who has been following >>SASL I'm familiar with the issue. I am not always good at reading a >>document as someone new to a technology. >> >> > >Sure. The following 3.2 text: > > >> The processing model is as follows. A server, upon completion of the >> authentication mechanism, uses the results produced by the >> authentication mechanism, the client-provided authorization identity >> value (which may be the empty string), and local policy information >> to derive an authorization identity. >> >> > >clearly shows the document is using the term 'authorization identity' >to refer, at times, to the client-provided authorization identity >and, at times, to a derived authorization identity. However, in >other portions of the document, the term 'authorization identity' >is mostly used unqualified. > Right. I agree this is an issue. > >While qualification of the term would likely resolve this >issue, that solution would likely be cumbersome. As the >'authorization identity' more properly refers to the identity >directly used in authorization, it seems more appropriate >to call the value referred to here as the 'client-provided >authorization identity' as the 'proxied identity'. > > [...] >I've been trying to come with a new term to call the derived >identity to allow us unambiguously use the term 'authorization >identity' to refer to the client provided value, as the WG >seems to have some attachment to this usage. The best I >have come with here is 'subject identity' (the identity which >is the subject in access control decisions). > >I do not recommend this approach myself as I believe it >would be more proper to use the term 'authorization identity' >to refer to the subject of access control decisions. > I would actually strongly prefer not to do that, as this will make everybody very confused. At least I am pretty sure I will be. "Subject identity" might be a bit ugly, but it is not so bad ;-) >However, I am far more concerned about ambiguous use of >the term (using the term to refer to two different values) >than I am about which of the two uses continues to this >term. That is, I can live with calling the client provided >value an 'authorization identity' if we don't also use that >term to refer to the derived identity. > > Ok, I will do the change. Alexey From owner-ietf-sasl Fri Sep 10 03:33:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AAXxVn071680; Fri, 10 Sep 2004 03:33:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AAXx4g071679; Fri, 10 Sep 2004 03:33:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from inf.puc-rio.br (exu.inf.puc-rio.br [139.82.16.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AAXtdr071634 for ; Fri, 10 Sep 2004 03:33:58 -0700 (PDT) (envelope-from silvana@inf.puc-rio.br) Received: (from apache@localhost) by inf.puc-rio.br (8.11.6/8.11.6) id i8AAXrq09366; Fri, 10 Sep 2004 07:33:53 -0300 X-Authentication-Warning: exu.inf.puc-rio.br: apache set sender to silvana@inf.puc-rio.br using -f Received: from 131.175.124.56 (SquirrelMail authenticated user silvana); by webmail.inf.puc-rio.br with HTTP; Fri, 10 Sep 2004 07:33:53 -0300 (EST) Message-ID: <32873.131.175.124.56.1094812433.squirrel@131.175.124.56> Date: Fri, 10 Sep 2004 07:33:53 -0300 (EST) Subject: From: "Silvana Rossetto" To: ietf-sasl@imc.org User-Agent: SquirrelMail/1.4.3a-0.1.7.x X-Mailer: SquirrelMail/1.4.3a-0.1.7.x MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-sasl Fri Sep 10 09:57:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGv9Hf009070; Fri, 10 Sep 2004 09:57:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AGv9fh009069; Fri, 10 Sep 2004 09:57:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGv8ge009063 for ; Fri, 10 Sep 2004 09:57:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 18:03:16 +0100 Message-ID: <4141DCCB.5080309@isode.com> Date: Fri, 10 Sep 2004 17:56:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > When a client requests a specific identity, do we consider it > desirable for the server to be able to use some arbitrary other > identity instead? No. The server should either "obey" or fail authentication. From owner-ietf-sasl Fri Sep 10 09:45:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGjMpq008229; Fri, 10 Sep 2004 09:45:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AGjM7N008228; Fri, 10 Sep 2004 09:45:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AGjLUg008221 for ; Fri, 10 Sep 2004 09:45:21 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03697; 10 Sep 2004 12:45 EDT Date: Fri, 10 Sep 2004 12:45:19 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <4140C7D6.5060206@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, September 09, 2004 22:15:02 +0100 Alexey Melnikov wrote: > Kurt D. Zeilenga wrote: > >> While qualification of the term would likely resolve this >> issue, that solution would likely be cumbersome. As the >> 'authorization identity' more properly refers to the identity >> directly used in authorization, it seems more appropriate >> to call the value referred to here as the 'client-provided >> authorization identity' as the 'proxied identity'. Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. Sure, if I connect to one of the cyrus.andrew IMAP backends using a requested authorization ID of 'jhutz' and provide credentials proving I am a front end, then there is a proxy relationship. However, if I make the same request with credentials belonging to the Kerberos principal jhutz@CS.CMU.EDU, there is _no_ proxy relationship. And in either case, the client is not _authenticating_ as 'jhutz' at all -- the only authentication is of the authentication ID provided by the mechanism, and all the client is doing here is asking the server to allow it to _act- as the user 'jhutz'. It's bad enough that people use the confusing phrase "proxy authentication" to refer to this situation when it is neither authentication nor necessarily involves any proxy relationship. Let's not compound the problem by introducing additional confusing uses of the word 'proxy'. Instead, let's refer to the identity provided by the client and transported by SASL over the wire as the 'requested' identity. Then the server derives the authorization identity based on the authentication identity, the requested identity, and local policy. In case it is not clear, I fully agree here that the phrase "authorization identity" should be used to refer to the identity actually used in making authorization decisions, and not that requested by the client. While some of us may need to get used to the new usage, I don't think that's as big a problem as will be caused by implementors and protocol designers being confused into thinking they should used the requested identity rather than the derived one for authorization decisions. Incidentally, this whole discussion reminds me of an issue that occurred to me while re-reading the document earlier this week. It is not at all clear to me that the requested and derived identities are permitted to be different, except in the case where the requested identity is the empty string. Operationally, my expectation has always been that you have two choices - either allow the server to derive an identity from the authentication ID, or ask for a specific one which the server can either accept or reject. When a client requests a specific identity, do we consider it desirable for the server to be able to use some arbitrary other identity instead? -- Jeff From owner-ietf-sasl Fri Sep 10 10:08:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH8WLJ010112; Fri, 10 Sep 2004 10:08:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AH8WgB010111; Fri, 10 Sep 2004 10:08:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH8UMX010104 for ; Fri, 10 Sep 2004 10:08:31 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 18:14:45 +0100 Message-ID: <4141DF7F.2070301@isode.com> Date: Fri, 10 Sep 2004 18:08:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > Instead, let's refer to the identity provided by the client and > transported by SASL over the wire as the 'requested' identity. Then > the server derives the authorization identity based on the > authentication identity, the requested identity, and local policy. The document is mostly talking about the requested identity. The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. > In case it is not clear, I fully agree here that the phrase > "authorization identity" should be used to refer to the identity > actually used in making authorization decisions, and not that > requested by the client. > While some of us may need to get used to the new usage, I don't > think that's as big a problem as will be caused by implementors and > protocol designers being confused into thinking they should used the > requested identity rather than the derived one for authorization > decisions. > > > > Incidentally, this whole discussion reminds me of an issue that > occurred to me while re-reading the document earlier this week. It is > not at all clear to me that the requested and derived identities are > permitted to be different, except in the case where the requested > identity is the empty string. If you are talking about semantics of the two - you are right, they are referring to the same entity. But of course the syntax of the derived identity is implementation specific and out of scope for SASL and doesn't have to be the same as the protocol specific syntax for authorization (requested) identities. From owner-ietf-sasl Fri Sep 10 10:04:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH4iY9009873; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AH4i7T009872; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AH4hMj009866 for ; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03769; 10 Sep 2004 13:04 EDT Date: Fri, 10 Sep 2004 13:04:17 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <106830000.1094835857@minbar.fac.cs.cmu.edu> In-Reply-To: <4141DCCB.5080309@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DCCB.5080309@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, September 10, 2004 17:56:43 +0100 Alexey Melnikov wrote: > > Jeffrey Hutzelman wrote: > >> When a client requests a specific identity, do we consider it >> desirable for the server to be able to use some arbitrary other >> identity instead? > > No. The server should either "obey" or fail authentication. OK. I'm inclined to agree, and I think the document should state this more explicitly. Further, if that is the case, then I think the distinction between the requested and derived identities is much less significant -- if there is a requested ID, they will be the same or the exchange will fail. From owner-ietf-sasl Fri Sep 10 10:32:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHWXG5011867; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AHWXGZ011866; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHWWpl011856 for ; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AHWWMw056764; Fri, 10 Sep 2004 17:32:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 10:33:09 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote: >Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. I wouldn't object to use of another term, such as 'asserted identity' or something. My concern is that the document uses confusing terminology to refer to the three distinct identities (the identity associated with credentials, a client provide identity, the identity the server uses to make authorization decisions) it discusses. The document should use three distinct terms for refer to each distinct identities it discusses. (Note that in my use of distinct above, I do not intend to imply that each of these identities could not refer the same user (or application entity). I intend to imply that they each has distinct characteristics (as discussed in the I-D) within the SASL identity model). Kurt From owner-ietf-sasl Fri Sep 10 10:54:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHsSrK013581; Fri, 10 Sep 2004 10:54:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AHsS3i013580; Fri, 10 Sep 2004 10:54:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHsRIN013574 for ; Fri, 10 Sep 2004 10:54:27 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AHsUMw056926; Fri, 10 Sep 2004 17:54:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 10:55:06 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Jeffrey Hutzelman , ietf-sasl@imc.org In-Reply-To: <4141DF7F.2070301@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:08 AM 9/10/2004, Alexey Melnikov wrote: >The document is mostly talking about the requested identity. Expecting the document explicitly says the identity used in making authorization decisions is derived from the credentials and the requested identity. (Note that I have suggested that even this statement be clarified as being 'conceptional' in nature.) >The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. Yes, as are the particulars of the derivation. Note that LDAP is a protocol where, in most implementations (LDAP doesn't have standardized schema for representing authorization policy), the identity form used in making authorization decisions (generally a DN) is not the same form of the SASL requested identity (a LDAP authzId [RFC2829]). (Below I am going to refer to the identity used in making authorization decisions as the subject identity.) I also note that derivation also allows a level of indication which some implementations may take advantage of. For instance, consider a server which has two groups of users. Though each user authenticates as themselves, and requests implicitly or explicitly to assume their own identity, the server is free to map all users in one group to an identity associated with the group. That is, there may be a many-to-1 relationship between requested and subject identities. Also, it is allowed that the server base the mapping of requested to subject identities on other factors. This implies that there is also a 1-to-many relationship between requested and subject identities. I think it best for the particulars of identity mappings to be left out-of-scope. Kurt From owner-ietf-sasl Fri Sep 10 11:09:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI91MQ014582; Fri, 10 Sep 2004 11:09:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AI91Bv014581; Fri, 10 Sep 2004 11:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AI90MF014571 for ; Fri, 10 Sep 2004 11:09:00 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03832; 10 Sep 2004 14:08 EDT Date: Fri, 10 Sep 2004 14:08:44 -0400 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <118020000.1094839724@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" wrote: > (Below I am going to refer to the identity used in making > authorization decisions as the subject identity.) Maybe it would be best if we avoided the term "authorization identity" at all. Or maybe not. Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not.... From owner-ietf-sasl Fri Sep 10 11:06:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI6Q6E014418; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AI6Qvm014417; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI6QCa014409 for ; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AI6TMw056989; Fri, 10 Sep 2004 18:06:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910110349.040ccee8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 11:07:05 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:33 AM 9/10/2004, Kurt D. Zeilenga wrote: >At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote: >>Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. > >I wouldn't object to use of another term, such as 'asserted identity' >or something. or 'requested identity'. I'm fine with your terminology suggestion. Kurt From owner-ietf-sasl Fri Sep 10 11:46:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AIkgt4017041; Fri, 10 Sep 2004 11:46:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AIkg5c017040; Fri, 10 Sep 2004 11:46:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AIkf8I017022 for ; Fri, 10 Sep 2004 11:46:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AIkcMw057163; Fri, 10 Sep 2004 18:46:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910112813.041667c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 11:47:15 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <118020000.1094839724@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> <118020000.1094839724@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:08 AM 9/10/2004, Jeffrey Hutzelman wrote: >On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" wrote: > >>(Below I am going to refer to the identity used in making >>authorization decisions as the subject identity.) > >Maybe it would be best if we avoided the term "authorization identity" at all. Or maybe not. I prefer to use the term "authorization identity" to refer to the subject of authorization decisions in the I-D. For the client-provided identity, I prefer "requested identity". (I only used the term "subject identity" in my email to avoid ambiguity of the I-D terms, and didn't intend to suggest that this term be used in the I-D.) >Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not.... I think it appropriate to outlining the identity concepts while being clear that the described relationship between the identities is only conceptual. Protocol specifications and their implementation have a lot of freedom (and that freedom, I would argue, is necessary to make things work). Kurt From owner-ietf-sasl Fri Sep 24 09:13:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGDSJa001179; Fri, 24 Sep 2004 09:13:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OGDScc001178; Fri, 24 Sep 2004 09:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGDRJ4001172 for ; Fri, 24 Sep 2004 09:13:27 -0700 (PDT) (envelope-from apache@megatron.ietf.org) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CAsT9-00029B-BN; Fri, 24 Sep 2004 11:58:47 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , sasl mailing list , sasl chair , sasl chair Subject: Protocol Action: 'SASLprep: Stringprep profile for user names and passwords' to Proposed Standard Message-Id: Date: Fri, 24 Sep 2004 11:58:47 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'SASLprep: Stringprep profile for user names and passwords ' as a Proposed Standard This document is the product of the Simple Authentication and Security Layer Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document describes the preparation of Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names or passwords. Working Group Summary The SASL Working Group came to rough consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. From owner-ietf-sasl Fri Sep 24 12:40:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJeJrL017972; Fri, 24 Sep 2004 12:40:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OJeJWa017971; Fri, 24 Sep 2004 12:40:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJeImt017955 for ; Fri, 24 Sep 2004 12:40:18 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8OJeKZv014103 for ; Fri, 24 Sep 2004 19:40:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 24 Sep 2004 12:40:30 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Summary of 2222bis WGLC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The chairs initiated a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt on 21 July 2004. The last call period, though originally scheduled to close 13 August 2004, was extended to allow additional review and discussion. All comments received prior to the posting of this summary were considered. The last call period is now closed. ISSUE SUMMARY Below is a summary of the issues of substance raised. For each, the chairs provide a statement of regarding the actions it believes are/aren't supported by WG consensus. Additionally, a number of editorial issues were raised and referred to the Editor for appropriate action. 1) Re-keying of security layers Nico indicated that the I-D did not discuss Re-keying of security layers and suggested text in this area be added. The WG discussed a number of specific suggestions in this area, with the following text being the last version submitted for WG consideration: SASL mechanisms that support re-keying SHOULD: - indicate that re-keying is or will be needed immediately; - provide re-keying messages or transparently include re-keying messages in the security layers; the latter can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. The chairs believes the WG supports addition of this text. 2) Detail Hiding Sam indicated the I-D claims that the layer does not generally hide the details of mechanisms from protocols and suggested this was an accurate reflection of what the WG intended to state. He suggested the I-D to be revised to state that while the layer hides the details of protocols from mechanisms and the details of mechanisms from protocols, it does not hide the details of mechanisms from protocol implementations. The chairs conclude the WG supports revising the I-D as Sam suggests here. 3) Confidentiality and Integrity Sam indicated that the I-D states "confidentiality protection usually implies integrity protection" and that this was less than ideal from a security standard point. He suggested that the word 'usually' be deleted. Nico suggested revising the specification to explicitly require future mechanisms which provide a confidentiality protection service to provide include integrity protection with that service. The chairs conclude the WG supports revising the I-D as Sam suggests here. The chairs conclude that the WG supports allowing mechanisms to "offer other kinds of security services" and hence does not adding the requirement upon future mechanisms suggested by Nico. 4) Channel Binding Nico asked whether the I-D should include text regarding channel binding issues. He suggest security consideration text that clients using SASL over TLS should verify the server's TLS identity to prevent MITM attacks. He also suggested adding text encouraging future mechanisms support channel bindings. The chairs conclude that the WG supports the former suggestion but not the latter. 5) Identities and Authorization Kurt indicated that the I-D use of term "authorization identity" is confusing and suggested use of different terms for each distinct use of this term. Jeffery suggested using the terms: "authentication identity" to refer to the identity associated with the users creditials, "requested identity" to refer to identity which the user requests to act as, and "authorization identity" to refer to identity used by the server in making authorization decisions. (The latter being derived from by former two.) The chairs conclude the WG supports use of this suggested terminology. 6) Empty initial response I Ken suggested that the SHOULD in "the protocol profile SHOULD also describe how an empty initial response is encoded" ought to be a MUST. The chairs conclude the WG supports this change. 7) Empty initial response II Ken asked whether the I-D should explicitly state that the profile also needs to describe how *empty* server challenges and client responses as encoded. Alexey respond as to why he believes the I-D is sufficiently clear here. The chairs that the WG supports making no change here. 8) EXTERNAL use of external information Ken suggested replacing "authenticate as" in the I-D text: The server uses information, external to SASL, to determine whether the client is permitted to authenticate as the authorization identity. with "have the access privileges of". Alexey suggested it be replaced with "to act as". The chairs conclude the WG supports this the change suggested by Alexey. GENERAL CONCLUSION and NEXT STEPS The chairs believe that WG consensus supports a recommendation of this I-D, once the above issues are appropriate addressed, to the IESG for publication as a Proposed Standard replacing RFC 2222. The chairs believes its above conclusions regarding supported actions accurately reflect WG consensus and hence direct the Editor to prepare a revision making the changes for which chairs have indicated are supported by the WG. The chairs believes its above conclusions regarding supported actions accurately reflect WG consensus. If you believe the chairs have misread consensus, please indicate so by email as soon as possible. If you believe the above summary is incomplete, please indicate by email as soon as possible. After giving the WG sufficient time (1 week) to verify that the actually changes made are consistent with WG consensus, the chairs intend to recommend the revised I-D to the IESG for consideration as a Proposed Standard. The chairs do not foresee the need to subject this I-D to another WG Last Call. Kurt & Sam, SASL co-chairs From owner-ietf-sasl Mon Sep 27 07:48:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8REm0Kh093464; Mon, 27 Sep 2004 07:48:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8REm0Rf093463; Mon, 27 Sep 2004 07:48:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RElxXc093455 for ; Mon, 27 Sep 2004 07:47:59 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CBwnG-0002c5-Pg for ietf-sasl@imc.org; Mon, 27 Sep 2004 16:47:58 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CBwmx-0008GU-1F; Mon, 27 Sep 2004 16:47:39 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CBwmw-0004VQ-00; Mon, 27 Sep 2004 16:47:38 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: authentication identity Date: Mon, 27 Sep 2004 16:47:38 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I sent this message in April, but received no reply and forgot about it. And now I discovered that I was no longer subscribed to ietf-sasl:-( rfc2222bis has added the concept of an authentication identity since rfc2222. Is this identity only a parameter to the SASL authentication process, and can be discarded after SASL authentication is complete? Or is it also part of the connecton's authorization state after SASL authentication? If so, what for? Could you clarify that in the draft? Is this too late now? If so, can someone explain anyway? (I'm wondering if I should suggest that the LDAP authmeth draft removes the authentication ID from the association (session state), or if it should mention what it can be used for.) -- Hallvard From owner-ietf-sasl Tue Sep 28 03:59:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SAxqdx090987; Tue, 28 Sep 2004 03:59:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SAxqau090986; Tue, 28 Sep 2004 03:59:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SAxpDE090953 for ; Tue, 28 Sep 2004 03:59:51 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CCFi1-0001aA-8q for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:49 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CCFhx-0006Kf-Bi for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:45 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CCFhw-0007Ye-00 for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:44 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: rfc2222bis: authentication identity In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 28 Sep 2004 12:59:44 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth writes: > I sent this message in April, but received no reply and forgot about it. > (...) Never mind - I was mixing up which concepts belong in SASL and which ones belong in protocols using SASL. Alexey set me straight. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SAxqdx090987; Tue, 28 Sep 2004 03:59:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SAxqau090986; Tue, 28 Sep 2004 03:59:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SAxpDE090953 for ; Tue, 28 Sep 2004 03:59:51 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CCFi1-0001aA-8q for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:49 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CCFhx-0006Kf-Bi for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:45 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CCFhw-0007Ye-00 for ietf-sasl@imc.org; Tue, 28 Sep 2004 12:59:44 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: rfc2222bis: authentication identity In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 28 Sep 2004 12:59:44 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth writes: > I sent this message in April, but received no reply and forgot about it. > (...) Never mind - I was mixing up which concepts belong in SASL and which ones belong in protocols using SASL. Alexey set me straight. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8REm0Kh093464; Mon, 27 Sep 2004 07:48:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8REm0Rf093463; Mon, 27 Sep 2004 07:48:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RElxXc093455 for ; Mon, 27 Sep 2004 07:47:59 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CBwnG-0002c5-Pg for ietf-sasl@imc.org; Mon, 27 Sep 2004 16:47:58 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CBwmx-0008GU-1F; Mon, 27 Sep 2004 16:47:39 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CBwmw-0004VQ-00; Mon, 27 Sep 2004 16:47:38 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: authentication identity Date: Mon, 27 Sep 2004 16:47:38 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I sent this message in April, but received no reply and forgot about it. And now I discovered that I was no longer subscribed to ietf-sasl:-( rfc2222bis has added the concept of an authentication identity since rfc2222. Is this identity only a parameter to the SASL authentication process, and can be discarded after SASL authentication is complete? Or is it also part of the connecton's authorization state after SASL authentication? If so, what for? Could you clarify that in the draft? Is this too late now? If so, can someone explain anyway? (I'm wondering if I should suggest that the LDAP authmeth draft removes the authentication ID from the association (session state), or if it should mention what it can be used for.) -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJeJrL017972; Fri, 24 Sep 2004 12:40:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OJeJWa017971; Fri, 24 Sep 2004 12:40:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJeImt017955 for ; Fri, 24 Sep 2004 12:40:18 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8OJeKZv014103 for ; Fri, 24 Sep 2004 19:40:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 24 Sep 2004 12:40:30 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Summary of 2222bis WGLC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The chairs initiated a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt on 21 July 2004. The last call period, though originally scheduled to close 13 August 2004, was extended to allow additional review and discussion. All comments received prior to the posting of this summary were considered. The last call period is now closed. ISSUE SUMMARY Below is a summary of the issues of substance raised. For each, the chairs provide a statement of regarding the actions it believes are/aren't supported by WG consensus. Additionally, a number of editorial issues were raised and referred to the Editor for appropriate action. 1) Re-keying of security layers Nico indicated that the I-D did not discuss Re-keying of security layers and suggested text in this area be added. The WG discussed a number of specific suggestions in this area, with the following text being the last version submitted for WG consideration: SASL mechanisms that support re-keying SHOULD: - indicate that re-keying is or will be needed immediately; - provide re-keying messages or transparently include re-keying messages in the security layers; the latter can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. The chairs believes the WG supports addition of this text. 2) Detail Hiding Sam indicated the I-D claims that the layer does not generally hide the details of mechanisms from protocols and suggested this was an accurate reflection of what the WG intended to state. He suggested the I-D to be revised to state that while the layer hides the details of protocols from mechanisms and the details of mechanisms from protocols, it does not hide the details of mechanisms from protocol implementations. The chairs conclude the WG supports revising the I-D as Sam suggests here. 3) Confidentiality and Integrity Sam indicated that the I-D states "confidentiality protection usually implies integrity protection" and that this was less than ideal from a security standard point. He suggested that the word 'usually' be deleted. Nico suggested revising the specification to explicitly require future mechanisms which provide a confidentiality protection service to provide include integrity protection with that service. The chairs conclude the WG supports revising the I-D as Sam suggests here. The chairs conclude that the WG supports allowing mechanisms to "offer other kinds of security services" and hence does not adding the requirement upon future mechanisms suggested by Nico. 4) Channel Binding Nico asked whether the I-D should include text regarding channel binding issues. He suggest security consideration text that clients using SASL over TLS should verify the server's TLS identity to prevent MITM attacks. He also suggested adding text encouraging future mechanisms support channel bindings. The chairs conclude that the WG supports the former suggestion but not the latter. 5) Identities and Authorization Kurt indicated that the I-D use of term "authorization identity" is confusing and suggested use of different terms for each distinct use of this term. Jeffery suggested using the terms: "authentication identity" to refer to the identity associated with the users creditials, "requested identity" to refer to identity which the user requests to act as, and "authorization identity" to refer to identity used by the server in making authorization decisions. (The latter being derived from by former two.) The chairs conclude the WG supports use of this suggested terminology. 6) Empty initial response I Ken suggested that the SHOULD in "the protocol profile SHOULD also describe how an empty initial response is encoded" ought to be a MUST. The chairs conclude the WG supports this change. 7) Empty initial response II Ken asked whether the I-D should explicitly state that the profile also needs to describe how *empty* server challenges and client responses as encoded. Alexey respond as to why he believes the I-D is sufficiently clear here. The chairs that the WG supports making no change here. 8) EXTERNAL use of external information Ken suggested replacing "authenticate as" in the I-D text: The server uses information, external to SASL, to determine whether the client is permitted to authenticate as the authorization identity. with "have the access privileges of". Alexey suggested it be replaced with "to act as". The chairs conclude the WG supports this the change suggested by Alexey. GENERAL CONCLUSION and NEXT STEPS The chairs believe that WG consensus supports a recommendation of this I-D, once the above issues are appropriate addressed, to the IESG for publication as a Proposed Standard replacing RFC 2222. The chairs believes its above conclusions regarding supported actions accurately reflect WG consensus and hence direct the Editor to prepare a revision making the changes for which chairs have indicated are supported by the WG. The chairs believes its above conclusions regarding supported actions accurately reflect WG consensus. If you believe the chairs have misread consensus, please indicate so by email as soon as possible. If you believe the above summary is incomplete, please indicate by email as soon as possible. After giving the WG sufficient time (1 week) to verify that the actually changes made are consistent with WG consensus, the chairs intend to recommend the revised I-D to the IESG for consideration as a Proposed Standard. The chairs do not foresee the need to subject this I-D to another WG Last Call. Kurt & Sam, SASL co-chairs Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGDSJa001179; Fri, 24 Sep 2004 09:13:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OGDScc001178; Fri, 24 Sep 2004 09:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGDRJ4001172 for ; Fri, 24 Sep 2004 09:13:27 -0700 (PDT) (envelope-from apache@megatron.ietf.org) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CAsT9-00029B-BN; Fri, 24 Sep 2004 11:58:47 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , sasl mailing list , sasl chair , sasl chair Subject: Protocol Action: 'SASLprep: Stringprep profile for user names and passwords' to Proposed Standard Message-Id: Date: Fri, 24 Sep 2004 11:58:47 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'SASLprep: Stringprep profile for user names and passwords ' as a Proposed Standard This document is the product of the Simple Authentication and Security Layer Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document describes the preparation of Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names or passwords. Working Group Summary The SASL Working Group came to rough consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AIkgt4017041; Fri, 10 Sep 2004 11:46:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AIkg5c017040; Fri, 10 Sep 2004 11:46:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AIkf8I017022 for ; Fri, 10 Sep 2004 11:46:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AIkcMw057163; Fri, 10 Sep 2004 18:46:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910112813.041667c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 11:47:15 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <118020000.1094839724@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> <118020000.1094839724@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:08 AM 9/10/2004, Jeffrey Hutzelman wrote: >On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" wrote: > >>(Below I am going to refer to the identity used in making >>authorization decisions as the subject identity.) > >Maybe it would be best if we avoided the term "authorization identity" at all. Or maybe not. I prefer to use the term "authorization identity" to refer to the subject of authorization decisions in the I-D. For the client-provided identity, I prefer "requested identity". (I only used the term "subject identity" in my email to avoid ambiguity of the I-D terms, and didn't intend to suggest that this term be used in the I-D.) >Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not.... I think it appropriate to outlining the identity concepts while being clear that the described relationship between the identities is only conceptual. Protocol specifications and their implementation have a lot of freedom (and that freedom, I would argue, is necessary to make things work). Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI91MQ014582; Fri, 10 Sep 2004 11:09:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AI91Bv014581; Fri, 10 Sep 2004 11:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AI90MF014571 for ; Fri, 10 Sep 2004 11:09:00 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03832; 10 Sep 2004 14:08 EDT Date: Fri, 10 Sep 2004 14:08:44 -0400 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <118020000.1094839724@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" wrote: > (Below I am going to refer to the identity used in making > authorization decisions as the subject identity.) Maybe it would be best if we avoided the term "authorization identity" at all. Or maybe not. Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not.... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI6Q6E014418; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AI6Qvm014417; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI6QCa014409 for ; Fri, 10 Sep 2004 11:06:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AI6TMw056989; Fri, 10 Sep 2004 18:06:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910110349.040ccee8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 11:07:05 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:33 AM 9/10/2004, Kurt D. Zeilenga wrote: >At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote: >>Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. > >I wouldn't object to use of another term, such as 'asserted identity' >or something. or 'requested identity'. I'm fine with your terminology suggestion. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHsSrK013581; Fri, 10 Sep 2004 10:54:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AHsS3i013580; Fri, 10 Sep 2004 10:54:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHsRIN013574 for ; Fri, 10 Sep 2004 10:54:27 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AHsUMw056926; Fri, 10 Sep 2004 17:54:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910103742.043dd388@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 10:55:06 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Jeffrey Hutzelman , ietf-sasl@imc.org In-Reply-To: <4141DF7F.2070301@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DF7F.2070301@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:08 AM 9/10/2004, Alexey Melnikov wrote: >The document is mostly talking about the requested identity. Expecting the document explicitly says the identity used in making authorization decisions is derived from the credentials and the requested identity. (Note that I have suggested that even this statement be clarified as being 'conceptional' in nature.) >The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. Yes, as are the particulars of the derivation. Note that LDAP is a protocol where, in most implementations (LDAP doesn't have standardized schema for representing authorization policy), the identity form used in making authorization decisions (generally a DN) is not the same form of the SASL requested identity (a LDAP authzId [RFC2829]). (Below I am going to refer to the identity used in making authorization decisions as the subject identity.) I also note that derivation also allows a level of indication which some implementations may take advantage of. For instance, consider a server which has two groups of users. Though each user authenticates as themselves, and requests implicitly or explicitly to assume their own identity, the server is free to map all users in one group to an identity associated with the group. That is, there may be a many-to-1 relationship between requested and subject identities. Also, it is allowed that the server base the mapping of requested to subject identities on other factors. This implies that there is also a 1-to-many relationship between requested and subject identities. I think it best for the particulars of identity mappings to be left out-of-scope. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHWXG5011867; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AHWXGZ011866; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHWWpl011856 for ; Fri, 10 Sep 2004 10:32:33 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8AHWWMw056764; Fri, 10 Sep 2004 17:32:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040910102222.043d0078@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 10:33:09 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote: >Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. I wouldn't object to use of another term, such as 'asserted identity' or something. My concern is that the document uses confusing terminology to refer to the three distinct identities (the identity associated with credentials, a client provide identity, the identity the server uses to make authorization decisions) it discusses. The document should use three distinct terms for refer to each distinct identities it discusses. (Note that in my use of distinct above, I do not intend to imply that each of these identities could not refer the same user (or application entity). I intend to imply that they each has distinct characteristics (as discussed in the I-D) within the SASL identity model). Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH8WLJ010112; Fri, 10 Sep 2004 10:08:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AH8WgB010111; Fri, 10 Sep 2004 10:08:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH8UMX010104 for ; Fri, 10 Sep 2004 10:08:31 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 18:14:45 +0100 Message-ID: <4141DF7F.2070301@isode.com> Date: Fri, 10 Sep 2004 18:08:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > Instead, let's refer to the identity provided by the client and > transported by SASL over the wire as the 'requested' identity. Then > the server derives the authorization identity based on the > authentication identity, the requested identity, and local policy. The document is mostly talking about the requested identity. The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. > In case it is not clear, I fully agree here that the phrase > "authorization identity" should be used to refer to the identity > actually used in making authorization decisions, and not that > requested by the client. > While some of us may need to get used to the new usage, I don't > think that's as big a problem as will be caused by implementors and > protocol designers being confused into thinking they should used the > requested identity rather than the derived one for authorization > decisions. > > > > Incidentally, this whole discussion reminds me of an issue that > occurred to me while re-reading the document earlier this week. It is > not at all clear to me that the requested and derived identities are > permitted to be different, except in the case where the requested > identity is the empty string. If you are talking about semantics of the two - you are right, they are referring to the same entity. But of course the syntax of the derived identity is implementation specific and out of scope for SASL and doesn't have to be the same as the protocol specific syntax for authorization (requested) identities. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AH4iY9009873; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AH4i7T009872; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AH4hMj009866 for ; Fri, 10 Sep 2004 10:04:44 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03769; 10 Sep 2004 13:04 EDT Date: Fri, 10 Sep 2004 13:04:17 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <106830000.1094835857@minbar.fac.cs.cmu.edu> In-Reply-To: <4141DCCB.5080309@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> <4141DCCB.5080309@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, September 10, 2004 17:56:43 +0100 Alexey Melnikov wrote: > > Jeffrey Hutzelman wrote: > >> When a client requests a specific identity, do we consider it >> desirable for the server to be able to use some arbitrary other >> identity instead? > > No. The server should either "obey" or fail authentication. OK. I'm inclined to agree, and I think the document should state this more explicitly. Further, if that is the case, then I think the distinction between the requested and derived identities is much less significant -- if there is a requested ID, they will be the same or the exchange will fail. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGv9Hf009070; Fri, 10 Sep 2004 09:57:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AGv9fh009069; Fri, 10 Sep 2004 09:57:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGv8ge009063 for ; Fri, 10 Sep 2004 09:57:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 18:03:16 +0100 Message-ID: <4141DCCB.5080309@isode.com> Date: Fri, 10 Sep 2004 17:56:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <98580000.1094834719@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > When a client requests a specific identity, do we consider it > desirable for the server to be able to use some arbitrary other > identity instead? No. The server should either "obey" or fail authentication. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGjMpq008229; Fri, 10 Sep 2004 09:45:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AGjM7N008228; Fri, 10 Sep 2004 09:45:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AGjLUg008221 for ; Fri, 10 Sep 2004 09:45:21 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03697; 10 Sep 2004 12:45 EDT Date: Fri, 10 Sep 2004 12:45:19 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization Message-ID: <98580000.1094834719@minbar.fac.cs.cmu.edu> In-Reply-To: <4140C7D6.5060206@isode.com> References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> <4140C7D6.5060206@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, September 09, 2004 22:15:02 +0100 Alexey Melnikov wrote: > Kurt D. Zeilenga wrote: > >> While qualification of the term would likely resolve this >> issue, that solution would likely be cumbersome. As the >> 'authorization identity' more properly refers to the identity >> directly used in authorization, it seems more appropriate >> to call the value referred to here as the 'client-provided >> authorization identity' as the 'proxied identity'. Ugh. Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. Sure, if I connect to one of the cyrus.andrew IMAP backends using a requested authorization ID of 'jhutz' and provide credentials proving I am a front end, then there is a proxy relationship. However, if I make the same request with credentials belonging to the Kerberos principal jhutz@CS.CMU.EDU, there is _no_ proxy relationship. And in either case, the client is not _authenticating_ as 'jhutz' at all -- the only authentication is of the authentication ID provided by the mechanism, and all the client is doing here is asking the server to allow it to _act- as the user 'jhutz'. It's bad enough that people use the confusing phrase "proxy authentication" to refer to this situation when it is neither authentication nor necessarily involves any proxy relationship. Let's not compound the problem by introducing additional confusing uses of the word 'proxy'. Instead, let's refer to the identity provided by the client and transported by SASL over the wire as the 'requested' identity. Then the server derives the authorization identity based on the authentication identity, the requested identity, and local policy. In case it is not clear, I fully agree here that the phrase "authorization identity" should be used to refer to the identity actually used in making authorization decisions, and not that requested by the client. While some of us may need to get used to the new usage, I don't think that's as big a problem as will be caused by implementors and protocol designers being confused into thinking they should used the requested identity rather than the derived one for authorization decisions. Incidentally, this whole discussion reminds me of an issue that occurred to me while re-reading the document earlier this week. It is not at all clear to me that the requested and derived identities are permitted to be different, except in the case where the requested identity is the empty string. Operationally, my expectation has always been that you have two choices - either allow the server to derive an identity from the authentication ID, or ask for a specific one which the server can either accept or reject. When a client requests a specific identity, do we consider it desirable for the server to be able to use some arbitrary other identity instead? -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AAXxVn071680; Fri, 10 Sep 2004 03:33:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AAXx4g071679; Fri, 10 Sep 2004 03:33:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from inf.puc-rio.br (exu.inf.puc-rio.br [139.82.16.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AAXtdr071634 for ; Fri, 10 Sep 2004 03:33:58 -0700 (PDT) (envelope-from silvana@inf.puc-rio.br) Received: (from apache@localhost) by inf.puc-rio.br (8.11.6/8.11.6) id i8AAXrq09366; Fri, 10 Sep 2004 07:33:53 -0300 X-Authentication-Warning: exu.inf.puc-rio.br: apache set sender to silvana@inf.puc-rio.br using -f Received: from 131.175.124.56 (SquirrelMail authenticated user silvana); by webmail.inf.puc-rio.br with HTTP; Fri, 10 Sep 2004 07:33:53 -0300 (EST) Message-ID: <32873.131.175.124.56.1094812433.squirrel@131.175.124.56> Date: Fri, 10 Sep 2004 07:33:53 -0300 (EST) Subject: From: "Silvana Rossetto" To: ietf-sasl@imc.org User-Agent: SquirrelMail/1.4.3a-0.1.7.x X-Mailer: SquirrelMail/1.4.3a-0.1.7.x MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AA0Z3I057992; Fri, 10 Sep 2004 03:00:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AA0ZqG057991; Fri, 10 Sep 2004 03:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AA0XHX057978 for ; Fri, 10 Sep 2004 03:00:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 10 Sep 2004 11:06:39 +0100 Message-ID: <4140C7D6.5060206@isode.com> Date: Thu, 09 Sep 2004 22:15:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry about the delay, I've integrated all other comments received so far.] Kurt D. Zeilenga wrote: >>Would you mind explaining the problem you had with this section in >>better detail? I thought it flowed fairly well and is a significant >>improvement on our previous attempts to describe this issue. However >>I might well miss problems because as someone who has been following >>SASL I'm familiar with the issue. I am not always good at reading a >>document as someone new to a technology. >> >> > >Sure. The following 3.2 text: > > >> The processing model is as follows. A server, upon completion of the >> authentication mechanism, uses the results produced by the >> authentication mechanism, the client-provided authorization identity >> value (which may be the empty string), and local policy information >> to derive an authorization identity. >> >> > >clearly shows the document is using the term 'authorization identity' >to refer, at times, to the client-provided authorization identity >and, at times, to a derived authorization identity. However, in >other portions of the document, the term 'authorization identity' >is mostly used unqualified. > Right. I agree this is an issue. > >While qualification of the term would likely resolve this >issue, that solution would likely be cumbersome. As the >'authorization identity' more properly refers to the identity >directly used in authorization, it seems more appropriate >to call the value referred to here as the 'client-provided >authorization identity' as the 'proxied identity'. > > [...] >I've been trying to come with a new term to call the derived >identity to allow us unambiguously use the term 'authorization >identity' to refer to the client provided value, as the WG >seems to have some attachment to this usage. The best I >have come with here is 'subject identity' (the identity which >is the subject in access control decisions). > >I do not recommend this approach myself as I believe it >would be more proper to use the term 'authorization identity' >to refer to the subject of access control decisions. > I would actually strongly prefer not to do that, as this will make everybody very confused. At least I am pretty sure I will be. "Subject identity" might be a bit ugly, but it is not so bad ;-) >However, I am far more concerned about ambiguous use of >the term (using the term to refer to two different values) >than I am about which of the two uses continues to this >term. That is, I can live with calling the client provided >value an 'authorization identity' if we don't also use that >term to refer to the derived identity. > > Ok, I will do the change. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JaueT092807; Wed, 8 Sep 2004 12:36:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88JauJS092806; Wed, 8 Sep 2004 12:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Jasbu092799 for ; Wed, 8 Sep 2004 12:36:54 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09900; Wed, 8 Sep 2004 15:36:56 -0400 (EDT) Message-Id: <200409081936.PAA09900@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-04.txt Date: Wed, 08 Sep 2004 15:36:55 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, et al. Filename : draft-ietf-sasl-rfc2831bis-04.txt Pages : 45 Date : 2004-9-8 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-8154411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154411.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873MFgd045276; Mon, 6 Sep 2004 20:22:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i873MFDH045275; Mon, 6 Sep 2004 20:22:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873ME2Z045257 for ; Mon, 6 Sep 2004 20:22:14 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i873M9XD012172 for ; Mon, 6 Sep 2004 22:22:09 -0500 Received: from [135.210.112.45] (unknown[135.210.112.45](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040907032243gw1002eunte> (Authid: tony); Tue, 7 Sep 2004 03:22:43 +0000 Message-ID: <413D2963.2000408@att.com> Date: Mon, 06 Sep 2004 23:22:11 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> In-Reply-To: <41387DE1.60100@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Let me clarify what kind of answers I was expecting to my question. I > would like to hear something like: > 1). I don't care either way. > 2). I prefer that all occurrences of "authentication protocol exchange" > are changed to "authentication exchange", but I am Ok if this is not done. > 3). Must change "authentication protocol exchange" to "authentication > exchange". #1 Tony Hansen tony@att.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J2qSo047735; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83J2qho047734; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from infoblox.com (daneel.infoblox.com [128.242.99.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J2q3b047709 for ; Fri, 3 Sep 2004 12:02:52 -0700 (PDT) (envelope-from morteza@infoblox.com) Received: from [192.129.1.150] (adsl-67-112-201-44.dsl.sntc01.pacbell.net [67.112.201.44]) by infoblox.com (Postfix) with ESMTP id DF2E02A33F; Fri, 3 Sep 2004 12:03:01 -0700 (PDT) Message-ID: <4138BFDA.4090609@infoblox.com> Date: Fri, 03 Sep 2004 12:02:50 -0700 From: Morteza Ansari User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , Ken Murchison , SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: #2. Cheers, Morteza Kurt D. Zeilenga wrote: > Let me re-iterate my basic concern. The specification uses the > term 'protocol' in general to refer to the application-level > protocol which is profiling SASL. Using the term in other > contexts is confusing. > > For instance, the statement that "A SASL mechanism is responsible > for conducting an authentication protocol exchange" is unnecessarily > confusing. By dropping the word "protocol" from this sentence, > it is more clear that the mechanism is responsible for the > authentication exchange (which is defined in the next sentence > as a series of challenges and responses) and not the actual > protocol for carrying the exchange. > > I note that the current I-D already uses the terms "authentication > exchange" instead of "authentication protocol exchange" in numerous > places. My suggestion is to always use the term "authentication > exchange" in place of "authentication protocol exchange". I view > this as an editorial change that will improve specification > clarity. > > With chair hat off, Kurt > > At 07:21 AM 9/3/2004, Alexey Melnikov wrote: > > > >>>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. >>> >>>This change wouldn't bother me. >> >>Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: >>1). I don't care either way. >>2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. >>3). Must change "authentication protocol exchange" to "authentication exchange". >> >>Having said that, are you #1 or #2? >> >>Alexey >> Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83F1RPV028115; Fri, 3 Sep 2004 08:01:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83F1RJQ028114; Fri, 3 Sep 2004 08:01:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83F1Qq6028105 for ; Fri, 3 Sep 2004 08:01:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i83F1RMw098436; Fri, 3 Sep 2004 15:01:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040903074459.04355f80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 03 Sep 2004 08:02:06 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: 2222bis: use of "authentication protocol exchange" Cc: Ken Murchison , SASL WG In-Reply-To: <41387DE1.60100@isode.com> References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let me re-iterate my basic concern. The specification uses the term 'protocol' in general to refer to the application-level protocol which is profiling SASL. Using the term in other contexts is confusing. For instance, the statement that "A SASL mechanism is responsible for conducting an authentication protocol exchange" is unnecessarily confusing. By dropping the word "protocol" from this sentence, it is more clear that the mechanism is responsible for the authentication exchange (which is defined in the next sentence as a series of challenges and responses) and not the actual protocol for carrying the exchange. I note that the current I-D already uses the terms "authentication exchange" instead of "authentication protocol exchange" in numerous places. My suggestion is to always use the term "authentication exchange" in place of "authentication protocol exchange". I view this as an editorial change that will improve specification clarity. With chair hat off, Kurt At 07:21 AM 9/3/2004, Alexey Melnikov wrote: >>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. >> >>This change wouldn't bother me. > >Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: >1). I don't care either way. >2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. >3). Must change "authentication protocol exchange" to "authentication exchange". > >Having said that, are you #1 or #2? > >Alexey > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Eehnc025630; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83EehBt025629; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Eeg3k025623 for ; Fri, 3 Sep 2004 07:40:43 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i83Eeeu8031205; Fri, 3 Sep 2004 10:40:40 -0400 (EDT) Message-ID: <4138828C.5070203@oceana.com> Date: Fri, 03 Sep 2004 10:41:16 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> <41387DE1.60100@isode.com> In-Reply-To: <41387DE1.60100@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > >>> The issue discussed below was raised by Kurt. He suggested to replace >>> "authentication protocol exchange" to "authentication exchange" >>> everywhere in the document. >> >> >> This change wouldn't bother me. > > > Let me clarify what kind of answers I was expecting to my question. I > would like to hear something like: > 1). I don't care either way. > 2). I prefer that all occurrences of "authentication protocol exchange" > are changed to "authentication exchange", but I am Ok if this is not done. > 3). Must change "authentication protocol exchange" to "authentication > exchange". > > Having said that, are you #1 or #2? #2 -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ELXhn024271; Fri, 3 Sep 2004 07:21:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83ELX4w024270; Fri, 3 Sep 2004 07:21:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ELVh3024261 for ; Fri, 3 Sep 2004 07:21:32 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 3 Sep 2004 15:27:15 +0100 Message-ID: <41387DE1.60100@isode.com> Date: Fri, 03 Sep 2004 15:21:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> <41387091.5060509@oceana.com> In-Reply-To: <41387091.5060509@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> The issue discussed below was raised by Kurt. He suggested to replace >> "authentication protocol exchange" to "authentication exchange" >> everywhere in the document. > > This change wouldn't bother me. Let me clarify what kind of answers I was expecting to my question. I would like to hear something like: 1). I don't care either way. 2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done. 3). Must change "authentication protocol exchange" to "authentication exchange". Having said that, are you #1 or #2? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83DO38a020306; Fri, 3 Sep 2004 06:24:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83DO35u020305; Fri, 3 Sep 2004 06:24:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83DO2lj020292 for ; Fri, 3 Sep 2004 06:24:02 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i83DNuWA024805 for ; Fri, 3 Sep 2004 09:23:56 -0400 (EDT) Message-ID: <41387091.5060509@oceana.com> Date: Fri, 03 Sep 2004 09:24:33 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL WG Subject: Re: 2222bis: use of "authentication protocol exchange" References: <41383FE6.7000905@isode.com> In-Reply-To: <41383FE6.7000905@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > Hi, > > The issue discussed below was raised by Kurt. He suggested to replace > "authentication protocol exchange" to "authentication exchange" > everywhere in the document. This change wouldn't bother me. > > Kurt wrote: > >> The problem here is this usage causes the term 'protocol' >> to be overloaded, making this and other uses of the term >> ambiguous. We need to consistently use the term 'protocol' >> to refer to the application-level protocol making use of >> SASL. Other protocols, in particular that of mechanisms, >> should be referred to by other terms, such as an >> 'authentication exchange'. > > > > The term "authentication protocol exchange" comes from RFC 2222. It > tries to say that an "authentication exchange" produced by a SASL > mechanism is carried by a SASL aware protocol. (I personally find the > original term unambiguous, although it is cumbersome.) So I am a bit > worried about changing "authentication protocol exchange" to > "authentication exchange" at this stage, as this seems to be a > [significant] terminology change from RFC 2222. > > It is probably Ok to say in the Introduction that "authentication > protocol exchange" and "authentication exchange" are synonyms and that > the document will use the latter term everywhere. > > I would like to hear opinions of other WG members. > > Thanks, > Alexey > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839uuDa088212; Fri, 3 Sep 2004 02:56:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i839uuNE088210; Fri, 3 Sep 2004 02:56:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839utwr088198 for ; Fri, 3 Sep 2004 02:56:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 3 Sep 2004 11:02:46 +0100 Message-ID: <41383FE6.7000905@isode.com> Date: Fri, 03 Sep 2004 10:56:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: 2222bis: use of "authentication protocol exchange" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document. Kurt wrote: >The problem here is this usage causes the term 'protocol' >to be overloaded, making this and other uses of the term >ambiguous. We need to consistently use the term 'protocol' >to refer to the application-level protocol making use of >SASL. Other protocols, in particular that of mechanisms, >should be referred to by other terms, such as an >'authentication exchange'. The term "authentication protocol exchange" comes from RFC 2222. It tries to say that an "authentication exchange" produced by a SASL mechanism is carried by a SASL aware protocol. (I personally find the original term unambiguous, although it is cumbersome.) So I am a bit worried about changing "authentication protocol exchange" to "authentication exchange" at this stage, as this seems to be a [significant] terminology change from RFC 2222. It is probably Ok to say in the Introduction that "authentication protocol exchange" and "authentication exchange" are synonyms and that the document will use the latter term everywhere. I would like to hear opinions of other WG members. Thanks, Alexey