From owner-ietf-sasl Sat Nov 1 05:34:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DYkkT010491 for ; Sat, 1 Nov 2003 05:34:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1DYkXi010490 for ietf-sasl-bks; Sat, 1 Nov 2003 05:34:46 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1DYjkT010484 for ; Sat, 1 Nov 2003 05:34:45 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 13:35:23 +0000 Message-ID: <3FA3B671.10104@isode.com> Date: Sat, 01 Nov 2003 13:34:41 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.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: Sam Hartman wrote: >There has been a lot of discussion on the list since the last IETF and >I'm curious which issues actually need meeting time. I'd appreciate >it if people could suggest issues that still seem to be open. > >Thing I think may be open or need discussion are: > >* Initial server challenges especially as they interact with SMTP > I think there is nothing to discuss here. There are bugs in existing implementation and this need to be clarified with additional examples. >* Security layer replacement in the base SASL spec >* Authorization ID text (data vs blob, confusion about restriction, etc) >* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want >to develop guidance for protocol designers on this issue? > >I think most of the other changes that have been brought forward have >been resolved; please correct me if I'm wrong. I think Greg's >comments on implementing SASL have not suggested any specific changes >to documents that need discussion. > > >There's also been a lot of IDN related discussion in the Kerberos >working group. So far, I don't think any of that discussion affects >saslprep. If any of those issues do end up affecting saslprep, we may >at least want to be aware of them. I'll review those discussion >within the next week. > > > Cheers, Alexey Melnikov __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 05:39:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DdwkT010701 for ; Sat, 1 Nov 2003 05:39:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1DdwF2010698 for ietf-sasl-bks; Sat, 1 Nov 2003 05:39:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1DdvkT010693 for ; Sat, 1 Nov 2003 05:39:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 13:40:39 +0000 Message-ID: <3FA3B7AD.4010309@isode.com> Date: Sat, 01 Nov 2003 13:39:57 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Alexey Melnikov writes: >>> >>> >>>>Hallvard B Furuseth wrote: >>>> >>>> >>>>>>4.1. Authentication protocol exchange >>>>>> >>>>>> >>>Anyway, I think I found the answer in section 6.1. The initial auth >>>command from the client is not part of the exchange, but the optional >>>"response" in the auth command is. >>> >>> >>Sorry, this makes little sense to me. >>Semantically the initial response *is* part of an authentication >>exchange. >> >> > >That's what I wrote. > Ok, but I think arguing whether the initial auth command is part of an exchange or not is not worth the time. >>>>>>4.2. Authorization identities and proxy authentication >>>>>> >>>>>> (...) >>>>>> The character encoding scheme used for transmitting an authorization >>>>>> identity over protocol is specified in each authentication mechanism >>>>>> (with the authentication mechanism's blob being further >>>>>> >>>>>> >>>>> ^^^^ >>>>> >>>>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>>>like the dictionary says:-) >>>>> >>>>> >>>>> >>>>I've changed this to "data". >>>> >>>> >>>I still don't know _which_ data you are talking about. >>> >>> >>> >>Data is defined (and specific to) by each SASL mechanism. >> >> > >Is the text in the ()'s just saying that the SASL mechanism restricts >the data sent between client and server to more than just being random >strings in the character encoding scheme? > No, it talks about encoding data. The data itself is arbitrary binary data as far as the protocol is concerned. > Well, of course. Why mention >that at all? If not, I still don't understand what this () is saying. > > > >>>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>>>top. >>>>> >>>>> >>>>> >>>>I've added a sentence about this in the introduction section. >>>> >>>> >>>I'm pretty sure you will still need to insert the words "Obsoletes: rfc >>>2222" in the header sometime, though I don't remember where this is >>>stated. >>> >>> >>> >>I think this is going to be added by a RFC editor. >> >> >I couldn't find anything saying so. I did find rfc2223 (Instructions >to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks >you to insert. rfc2223 does say that the RFC Editor may make some >changes, but preferably as few as possible, and it doesn't mention >that one. > Ok, I will make sure that Obsoletes: will be inserted. Alexey From owner-ietf-sasl Sat Nov 1 06:06:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1E6dkT012090 for ; Sat, 1 Nov 2003 06:06:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1E6dIE012089 for ietf-sasl-bks; Sat, 1 Nov 2003 06:06:39 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1E6ckT012077 for ; Sat, 1 Nov 2003 06:06:38 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:07:19 +0000 Message-ID: <3FA3BDED.6010804@isode.com> Date: Sat, 01 Nov 2003 14:06:37 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Consensus call: changing examples from ACAP to SMTP References: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> In-Reply-To: <20031031195205.60C6F1515E8@konishi-polis.mit.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: Sam Hartman wrote: >Hi. The discussion seems to have died down on the issue of replacing >the ACAP example with an SMTP example in the plain draft. > >The rough consensus of this working group is that we will not change >to an SMTP-based example. We seem to believe that the examples in the >plain document should illustrate that mechanisms, not illustrate common >implementation errors in other related protocols. > >I think that we have something approaching a consensus that we will be >better served by encouraging implementers to read all the appropriate >documents than to include information designed to make sure that >implementers will not make mistakes even if they do not read the >appropriate documents. That's not as clear as the consensus against >changing the example to SMTP; there may be more room for discussion on >this issue. > >Personally I believe that we may want to consider ways in which we can >make it clear to implementers what documents they want to read. > I suggest the following: 1). Don't change examples in PLAIN 2). Implementation consideration section is added to the base SASL document. It will list commonly misimplemented features and will give some protocol examples. I will make sure that SMTP PLAIN example is one of the examples. Reference to PLAIN will be informative. (Or this can be a separate document as discussed recently). 3). I am thinking about [co-]authoring a document that is "protocol profile designer guide". It will compare existing protocols and how different features are implemented in them. This can be the same document as in 2, or a separate document. Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Sat Nov 1 06:22:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EM7kT013069 for ; Sat, 1 Nov 2003 06:22:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1EM7i6013068 for ietf-sasl-bks; Sat, 1 Nov 2003 06:22:07 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1EM6kT013063 for ; Sat, 1 Nov 2003 06:22:06 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:22:48 +0000 Message-ID: <3FA3C18E.8010101@isode.com> Date: Sat, 01 Nov 2003 14:22:06 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> In-Reply-To: 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: > > >>>rfc2222bis section 6.3 "Multiple authentications" says: >>> >>> If a security layer is in effect >>> and a subsequent SASL negotiation selects a second security layer, >>> then the second security layer replaces the first. If a security >>> layer is in effect and a subsequent SASL negotiation selects no >>> security layer, the original security layer must be removed. >>> >>>Exactly when is the old layer canceled? >>> >>>If an old layer is active and the client starts to negotiate a new >>>layer, it may not know when to expect the response from the server. >>>So the layer can't be canceled by starting a new negotiation. >>> >>> >>No, the layer can only be canceled/replaced after a subsequent >>authentication completes successfully. >> > >OK. Please mention that explicitly. > After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads: If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer MUST be removed. The rest of this section explain why this is important. Also note, that if a subsequent authentication fails, the protocol profile MAY allow the connection state to return to non-authenticated, however the previously negotiated security layer MUST NOT be removed. Only a successful reauthentication is able replace/remove the previously negotiated security layer. >>Each profile document must document exactly when this takes place. >> > >'this' = 'it completed successfully', I take it. > > Yes. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 06:44:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EiwkT013730 for ; Sat, 1 Nov 2003 06:44:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1Eiw78013729 for ietf-sasl-bks; Sat, 1 Nov 2003 06:44:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1EiukT013716 for ; Sat, 1 Nov 2003 06:44:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:42:13 +0000 Message-ID: <3FA3C61A.3040307@isode.com> Date: Sat, 01 Nov 2003 14:41:30 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token References: <3F8D308B.5050208@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >>>rfc2831bis 2.1.1 "Step One" says: >>> >>> qop-options = "qop" "=" <"> qop-list <"> >>> qop-list = 1#qop-value >>> qop-value = "auth" | "auth-int" | "auth-conf" | >>> token >>> >>>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >>>"auth", "auth-int" and "auth-conf", but not when it is . >>> >>> >>Token is specifically for future extensions, if you see a qop value you >>don't recognize - you have to ignore it. >>If you recognize nothing, you have to fail the authentication exchange. >> >>Do you want any clarifications on this to be added to the document. >> >> > >Not sure. I think it would be good to mention that 'token is for future >extensions' somewhere. And perhaps that these extensions must define >A2, since rfc2831bis does not. > Ok, I've clarified this. Alexey From owner-ietf-sasl Sat Nov 1 07:09:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1F9LkT014548 for ; Sat, 1 Nov 2003 07:09:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1F9Lgu014547 for ietf-sasl-bks; Sat, 1 Nov 2003 07:09:21 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1F9KkT014542 for ; Sat, 1 Nov 2003 07:09:20 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 15:10:02 +0000 Message-ID: <3FA3CCA0.9040909@isode.com> Date: Sat, 01 Nov 2003 15:09:20 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: <3F9C2F32.1060004@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>>>2.1.1 Step One >>>> >>>> The server starts by sending a challenge. >>>> >>>> >>>How does it know that it should do that? >>> >>The client always starts first (according to SASL). If the client >>doesn't includes an initial response, the server will know. >> >>Can you suggest any clarification text here? >> >> > >'The server starts by sending a challenge after the client indicates >that SASL negotiatin should start'? > > SASL framework doesn't support the case when the server initiate authentication exchange. The only way to do that is for the server to return some kind of "authentication required" error code when the client tries to issue other commands. > ... > >>>>2.2 Subsequent Authentication >>>> >>>> If the client has previously authenticated to the server, and >>>> remembers the values of username, realm, nonce, nonce-count, cnonce, >>>> >>>> >>> ^^^^^^^^ >>> >>> >>>> and qop that it used in that authentication, and the SASL profile for >>>> a protocol permits an initial client response, then it MAY perform >>>> "subsequent authentication", as defined in this section. >>>> >>>> >>>What's the point of authenticating again with the same username? Auth >>>with a _different_ username would be more interesting. >>> >>> >>This is a case of fast reauthentication using a different TCP >>connection. This is similar to resuming a TLS session. >> > >Oh. Could you add 'even after closing the connection and reopening a >new one' in section 2.2? > > Actually, this can be done on the same connection, if the protocol supports reauthentication. I've added the following: Note, that a subsequent authentication can be done on a different connection, or on the same connection, if the protocol profile also permits multiple authentications. I've also added some clarification text at the beginning of section 2. Alexey From owner-ietf-sasl Sat Nov 1 07:33:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1FXokT015378 for ; Sat, 1 Nov 2003 07:33:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1FXoAl015377 for ietf-sasl-bks; Sat, 1 Nov 2003 07:33:50 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1FXnkT015372 for ; Sat, 1 Nov 2003 07:33:49 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 15:34:23 +0000 Message-ID: <3FA3D254.9030809@isode.com> Date: Sat, 01 Nov 2003 15:33:40 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >>>>We should not suggest that mechanisms should do both (1) and >>>>(2). (1) and (3) OR (2) or (3) are sufficient to ensure >>>>proper matching. >>>> >>>> >>>IMHO, this is a responsibility of the client, >>> >>> > >Disagree. It's the responsibility of the mechanism definition to say >where it should happen. > Ok. But in all SASL mechanisms I know the client end sends username or retrieves-hashes-sends something derived from a password. So, so far this is the same thing ;-). Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 08:18:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1GIUkT017160 for ; Sat, 1 Nov 2003 08:18:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1GIUik017159 for ietf-sasl-bks; Sat, 1 Nov 2003 08:18:30 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1GITkT017153 for ; Sat, 1 Nov 2003 08:18:29 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1GIUlg032178; Sat, 1 Nov 2003 16:18:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101080111.057ff8d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 08:17:41 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Fwd: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: ietf-sasl@imc.org 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: >Date: Sat, 01 Nov 2003 15:33:40 +0000 >From: Alexey Melnikov >To: Hallvard B Furuseth >CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org >Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments >List-Archive: > > >Hallvard B Furuseth wrote: >>>>>We should not suggest that mechanisms should do both (1) and >>>>>(2). (1) and (3) OR (2) or (3) are sufficient to ensure >>>>>proper matching. >>>>> >>>>IMHO, this is a responsibility of the client, >>>> >> >>Disagree. It's the responsibility of the mechanism definition to say >>where it should happen. >Ok. >But in all SASL mechanisms I know the client end sends username or retrieves-hashes-sends something derived from a password. >So, so far this is the same thing ;-). There are certainly mechanisms which don't transfer a username (authentication identity in simple form) and/or don't transfer a value derived from a simple password. (For example, EXTERNAL.) And for those which do, it should be left up to the mechanism to state where preparation of those strings is to be done. The framework specification should avoid getting details which are mechanism-specific. Kurt From owner-ietf-sasl Sat Nov 1 09:35:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1HZpkT020002 for ; Sat, 1 Nov 2003 09:35:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1HZpkU020001 for ietf-sasl-bks; Sat, 1 Nov 2003 09:35:51 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1HZmkT019995 for ; Sat, 1 Nov 2003 09:35:48 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1HZilg032752; Sat, 1 Nov 2003 17:35:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101082402.057ffb60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 09:34:54 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Consensus call: changing examples from ACAP to SMTP Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <3FA3BDED.6010804@isode.com> References: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> <3FA3BDED.6010804@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 06:06 AM 11/1/2003, Alexey Melnikov wrote: >Sam Hartman wrote: > >>Hi. The discussion seems to have died down on the issue of replacing >>the ACAP example with an SMTP example in the plain draft. >> >>The rough consensus of this working group is that we will not change >>to an SMTP-based example. We seem to believe that the examples in the >>plain document should illustrate that mechanisms, not illustrate common >>implementation errors in other related protocols. >> >>I think that we have something approaching a consensus that we will be >>better served by encouraging implementers to read all the appropriate >>documents than to include information designed to make sure that >>implementers will not make mistakes even if they do not read the >>appropriate documents. That's not as clear as the consensus against >>changing the example to SMTP; there may be more room for discussion on >>this issue. >> >>Personally I believe that we may want to consider ways in which we can >>make it clear to implementers what documents they want to read. >I suggest the following: >1). Don't change examples in PLAIN As I previously noted, I intend to offer another example illustrating another aspect of the PLAIN feature for WG consideration. But I am going to be very careful to avoid getting into the details more appropriately discussed in referencing documents. >2). Implementation consideration section is added to the base SASL document. I am a bit leery of adding another section to the base SASL document (especially at this late stage). It may be better, as was suggested by someone else, to instead write an "SASL Implementation Guide" as a separate document. I think, however, most of the problems and their solutions are application protocol specific and, hence, should be addressed in documents specific to application protocol. >It will list commonly misimplemented features and will give some protocol examples. >I will make sure that SMTP PLAIN example is one of the examples. Depending on what you intend to illustrate, SMTP may not be the best protocol for the example. (See prior discussion.) >Reference to PLAIN will be informative. (Or this can be a separate document as discussed recently). Again, we need to avoid trumping application profile documents in documents they reference. We need to ensure that any example (and as well as prose) is properly placed in the right document. Now, depending on example what kind of examples you had in mind, they may or may not be appropriate. For instance, examples showing the initial response (without challenge) and final challenge (without response) would likely be useful. But we need to be careful not to specify how exchanges are to be implemented in any particular application-level protocol. I suggest you offer specific text to the list for WG consideration. >3). I am thinking about [co-]authoring a document that is "protocol profile designer guide". It will compare existing protocols and how different features are implemented in them. This can be the same document as in 2, or a separate document. As a separate document, I think this is a good idea. Kurt From owner-ietf-sasl Sat Nov 1 10:16:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1IGWkT021484 for ; Sat, 1 Nov 2003 10:16:32 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1IGW4T021483 for ietf-sasl-bks; Sat, 1 Nov 2003 10:16:32 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1IGUkT021478 for ; Sat, 1 Nov 2003 10:16:31 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1IGWlg033000; Sat, 1 Nov 2003 18:16:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 10:15:42 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: re-negotiating SASL security layer Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FA3C18E.8010101@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@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: Alexey, RFC 2222 said: If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect. I think changing this is bad. The primary reason posted on the list for the change was: "Applications should be allowed to remove layers." I argue that this is, effective, adding a new feature to SASL. Adding new features is beyond our scope. The primary reason given in the draft is to address a security concern. I would suspect that there are numerous other cases, including where re-authentication is not involved, where another party may have direct knowledge of information being encrypted. For example, the same concern arises when an LDAP server provides results obtained through chaining. Or by an LDAP client is chasing a referral. This concerns, I think, would be better addressed by stating security consideration. The primary reason why this is better is because the change will cause significant interoperability problems. Existing implementations expect those layers to remain in effect. Kurt At 06:22 AM 11/1/2003, Alexey Melnikov wrote: >>>>rfc2222bis section 6.3 "Multiple authentications" says: >>>> >>>> If a security layer is in effect >>>> and a subsequent SASL negotiation selects a second security layer, >>>> then the second security layer replaces the first. If a security >>>> layer is in effect and a subsequent SASL negotiation selects no >>>> security layer, the original security layer must be removed. >>>> >>>>Exactly when is the old layer canceled? >>>> >>>>If an old layer is active and the client starts to negotiate a new >>>>layer, it may not know when to expect the response from the server. >>>>So the layer can't be canceled by starting a new negotiation. >>>> >>>No, the layer can only be canceled/replaced after a subsequent authentication completes successfully. >> >>OK. Please mention that explicitly. >After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads: > >If a profile explicitly permits multiple successful SASL >negotiations to occur, then in no case may multiple security layers be >simultaneously in effect. If a security layer is in effect >and a subsequent SASL negotiation selects a second security layer, >then the second security layer replaces the first. If a security layer >is in effect and a subsequent SASL negotiation selects no security layer, >the original security layer MUST be removed. The rest of this section explain >why this is important. Also note, that if a subsequent authentication fails, >the protocol profile MAY allow the connection state to return to non-authenticated, >however the previously negotiated security layer MUST NOT be removed. Only >a successful reauthentication is able replace/remove the previously negotiated >security layer. > >>>Each profile document must document exactly when this takes place. >> >>'this' = 'it completed successfully', I take it. >> >Yes. > >Alexey >__________________________________________ >Isode Limited, http://www.isode.com > >IETF standard related pages: >http://orthanc.ab.ca/mel/devel/Links.html >__________________________________________ > From owner-ietf-sasl Sat Nov 1 10:55:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1ItwkT022528 for ; Sat, 1 Nov 2003 10:55:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1ItwGf022527 for ietf-sasl-bks; Sat, 1 Nov 2003 10:55:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1ItukT022522 for ; Sat, 1 Nov 2003 10:55:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 18:56:36 +0000 Message-ID: <3FA401B2.50607@isode.com> Date: Sat, 01 Nov 2003 18:55:46 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031101093553.0585dce8@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: Kurt D. Zeilenga wrote: >Alexey, > >RFC 2222 said: > If a security layer is in effect and a subsequent SASL negotiation > selects no security layer, the original security layer remains in effect. > >I think changing this is bad. > >The primary reason posted on the list for the change was: "Applications >should be allowed to remove layers." I argue that this is, effective, >adding a new feature to SASL. Adding new features is beyond our scope. > I never said that and I don't believe this is an important feature. >The primary reason given in the draft is to address a security concern. >I would suspect that there are numerous other cases, including where >re-authentication is not involved, where another party may have direct >knowledge of information being encrypted. For example, the same concern >arises when an LDAP server provides results obtained through chaining. >Or by an LDAP client is chasing a referral. This concerns, I think, >would be better addressed by stating security consideration. > Kurt, I think you are missing the point. You are describing authorized disclosure (or something similar to a situation when one end of the connection is broadcasting decrypted data over the network in the clear). The draft describes a potential security vulnerability. I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication), but there is no point of propagating something which is known to be broken to new protocols. >The primary reason why this is better is because the change will cause >significant interoperability problems. Existing implementations expect >those layers to remain in effect. > How about changing MUST to SHOULD to allow for backward compatibility for LDAP? Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Sat Nov 1 11:41:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1JfbkT023697 for ; Sat, 1 Nov 2003 11:41:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1JfbAx023696 for ietf-sasl-bks; Sat, 1 Nov 2003 11:41:37 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1JfakT023691 for ; Sat, 1 Nov 2003 11:41:36 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 19:42:18 +0000 Message-ID: <3FA40C6F.3030004@isode.com> Date: Sat, 01 Nov 2003 19:41:35 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>>>>>>In >>>>>>>order to avoid noninteroperability due to differing normalizations, >>>>>>>when a mechanism specifies that a string authentication identity or >>>>>>>password used as input to a cryptographic function (or used for >>>>>>>comparison) it SHOULD specify that the string first be prepared using >>>>>>>the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>>>>>[StringPrep]. >>>>>>> >>>>>>> >>The new text after that reads: >> >>There are three entities that has to deal with this issue: a client >>(upon getting user input or retrieving a value from configuration), a server >>(upon receiving the value from the client) and a utility that is able to >>store >>passwords/hashes in a database that can be later used by the server. >>The preparation must be done by the client and the utility and may be >>done by the >>server. If preparation fails or results in an empty string, the entity doing >>the preparation SHALL fail the authentication exchange. >> > >I like Kurt's suggestion better: The mechanism must define where >preparation is done. That way clients using mechanisms like PLAIN can >leave as much work as possible to the server. > I've updated the draft to say that each mechanism must describe where preparation takes place. Alexey From owner-ietf-sasl Sat Nov 1 12:35:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KZxkT025335 for ; Sat, 1 Nov 2003 12:35:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KZxTG025334 for ietf-sasl-bks; Sat, 1 Nov 2003 12:35:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1KZrkT025328 for ; Sat, 1 Nov 2003 12:35:54 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1KZtlg034106; Sat, 1 Nov 2003 20:35:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101114709.02b854d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 12:35:06 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: re-negotiating SASL security layer Cc: ietf-sasl@imc.org In-Reply-To: <3FA401B2.50607@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@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:55 AM 11/1/2003, Alexey Melnikov wrote: >The draft describes a potential security vulnerability. I don't disagree that there is a potential security vulnerability. I disagree that we should address it by changing the protocol. The issue can be (and, in my opinion, should be) addressed through statement of appropriate security considerations. I think we're talking about the same class of attacks. There are numerous cases where a third party (such as BB in your discussion) have limited knowledge of protected content and could use that knowledge to mount an attack. Note that your solution doesn't complete eliminate this particular case as the old layers are in-effect during the reauthentication. Server BB could still use its knowledge of the reauthentication process to attack the encryption of previously sent information. I think the risk of this class of attack is not sufficient to warrant changing the protocol especially considering the interoperability (and security?) problems the change would cause. I say "and security?" as now traffic which an old client expected to be protected by old layers would not be protected. We have to consider that as well. >I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication), but there is no point of propagating something which is known to be broken to new protocols. I don't consider SASL broken in this respect. It just that there are security concerns to be considered. >>The primary reason why this is better is because the change will cause >>significant interoperability problems. Existing implementations expect >>those layers to remain in effect. >How about changing MUST to SHOULD to allow for backward compatibility for LDAP? A SHOULD would be inappropriate as interoperability mandates that either all implementations keep the layer or all implementations drop the layer. Kurt From owner-ietf-sasl Sat Nov 1 12:42:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KgekT025610 for ; Sat, 1 Nov 2003 12:42:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KgetU025609 for ietf-sasl-bks; Sat, 1 Nov 2003 12:42:40 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1KgdkT025604 for ; Sat, 1 Nov 2003 12:42:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 20:43:23 +0000 Message-ID: <3FA41ABF.1080602@isode.com> Date: Sat, 01 Nov 2003 20:42:39 +0000 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: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <6.0.0.22.0.20031101114709.02b854d0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031101114709.02b854d0@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: >>>The primary reason why this is better is because the change will cause >>>significant interoperability problems. Existing implementations expect >>>those layers to remain in effect. >>> >>> >>How about changing MUST to SHOULD to allow for backward compatibility for LDAP? >> >> >A SHOULD would be inappropriate as interoperability mandates that either all >implementations keep the layer or all implementations drop the layer. > > SHOULD in protocol profile, not "SHOULD keep/drop the old layer". Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 12:43:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KhAkT025624 for ; Sat, 1 Nov 2003 12:43:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KhAR9025623 for ietf-sasl-bks; Sat, 1 Nov 2003 12:43:10 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1Kh9kT025618 for ; Sat, 1 Nov 2003 12:43:09 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 20:43:52 +0000 Message-ID: <3FA41ADD.2000308@isode.com> Date: Sat, 01 Nov 2003 20:43:09 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> In-Reply-To: <3FA401B2.50607@isode.com> 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: Alexey Melnikov wrote: >> The primary reason why this is better is because the change will cause >> significant interoperability problems. Existing implementations expect >> those layers to remain in effect. >> > How about changing MUST to SHOULD to allow for backward compatibility > for LDAP? Thinking more about this. What I didn't like about the original text is that it was kind of MUST. What if I rephrase to allow a protocol profile to have a choice: either keep the original layer if none was negotiated during reauthentication (and have a security consideration about the issue) or remove the original layer. If the protocol profile chooses to do the former, it should recommend to always negotiate a new security layer during reauthentication. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sun Nov 2 19:03:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA333vkT045942 for ; Sun, 2 Nov 2003 19:03:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA333v3Q045941 for ietf-sasl-bks; Sun, 2 Nov 2003 19:03:57 -0800 (PST) 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.10/8.12.8) with ESMTP id hA333tkT045935 for ; Sun, 2 Nov 2003 19:03:56 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AGV0V-00037v-8J; Mon, 03 Nov 2003 04:03:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AGV0P-0008W2-No; Mon, 03 Nov 2003 04:03:49 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AGV0O-0004P6-00; Mon, 3 Nov 2003 04:03:48 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 3 Nov 2003 04:03:48 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > I note that this issue is likely not unique to ANONYMOUS. So, maybe > it should be dealt with in base SASL specification. > > I'm thinking a malformed message should be treated as a protocol > error in the application protocol. How detailed should the checking for malformed messages be? For example, is it a protocol error to send a latin-1 string when the protocol requires UTF-8? How about sending an invalid UTF-8-like sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid? -- Hallvard From owner-ietf-sasl Sun Nov 2 20:10:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA34ATkT047807 for ; Sun, 2 Nov 2003 20:10:29 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA34ATBr047806 for ietf-sasl-bks; Sun, 2 Nov 2003 20:10:29 -0800 (PST) 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.10/8.12.8) with ESMTP id hA34ARkT047801 for ; Sun, 2 Nov 2003 20:10:28 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA34AUlg047138; Mon, 3 Nov 2003 04:10:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031102194648.02ba7af8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sun, 02 Nov 2003 20:09:39 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031003061141.040ed080@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 07:03 PM 11/2/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> I note that this issue is likely not unique to ANONYMOUS. So, maybe >> it should be dealt with in base SASL specification. >> >> I'm thinking a malformed message should be treated as a protocol >> error in the application protocol. Note that application protocols generally give great freedom in how protocol errors are treated. And, the principle of "be liberal in what you accept but strict in what your send" applies as well. >How detailed should the checking for malformed messages be? I think, in general, protocol peers should check each component of the PDU which they make use of and then some. For ANONYMOUS, a server which uses the message should check that it is properly encoded UTF-8 but a server which didn't make use of the message could simply ignore the message. >For example, is it a protocol error to send a latin-1 string when the >protocol requires UTF-8? Yes. >How about sending an invalid UTF-8-like >sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid? Yes. Kurt From owner-ietf-sasl Mon Nov 3 11:51:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JpvkT048391 for ; Mon, 3 Nov 2003 11:51:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3Jpvkb048390 for ietf-sasl-bks; Mon, 3 Nov 2003 11:51:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JpukT048383 for ; Mon, 3 Nov 2003 11:51:56 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3JpuPh001286; Mon, 3 Nov 2003 12:51:56 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA3Jpuru024629; Mon, 3 Nov 2003 11:51:56 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNS00INSKIJNJ@mpkmail.eng.sun.com>; Mon, 03 Nov 2003 11:51:56 -0800 (PST) Date: Mon, 03 Nov 2003 11:51:56 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=UTF-8 Content-MD5: SfGydn3QK25i2FE+TDdj5Q== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA3JpukT048385 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree that the SASLprep is more suitable and applicable for simple user names and passwords and if the additional mappings such as the full stops are needed, they are more suitable and correct to be done at the outside of any Stringprep/Stringprep profiles and most preferrably before the application of the Stringprep profile(s). <-- These are also my points all along. The reasons are like the following that the U+002E (full stop and dot/decimal point) isn't the same or equivalent to the ideographic/Asian full stops all the time; if they were, the Unicode itself would define them as equivalent forms/characters and show canonical/compatiblity decomposition(s) at each characters so that the Unicode normalizations would normalize those characters into a (normalized) character. Also, if everyone would agree on the fact that the ideopgraphic/Asian full stops are not equivalent to the U+002E and yet we still need to support the mappings described in the IDNA for the compatibility/interoperability on the Internet domain style names (only), then, I'm also thinking that everyone would agree this conditional mappings should be done outside of the Stringprep and any of the Stringprep profiles (since the Stringprep itself doesn't really allow conditional mappings at the mapping step as of today even though a profile *possibly and maybe* could define such conditional mappings). Re user provided strings, I have the following example that shouldn't match as the same thing: 3.14 ３。１４ 3。14 The first one is the pi, three point one four, in ASCII and the second is three, ideographic full-stop, and fourteen in Asian full-width digit characters and with ideographic full stop in UTF-8. (The third one is a variation of the second one, three, ideographic full-stop, and fourteen in ASCII digits and with ideographic full stop in UTF-8; and the second and the third can be seen as equivalent.) With regards, Ienup ] Date: Fri, 31 Oct 2003 20:52:15 -0800 ] From: "Kurt D. Zeilenga" ] Subject: Re: SASLPrep vs Full Stop code points ] X-Sender: kurt@127.0.0.1 ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] ] At 05:42 PM 10/31/2003, Ienup Sung wrote: ] >Regarding the full stops, while I do understand the point of display vs. ] >storage/query string in my opinion, I think the issue boils down onto ] >the followign two things in my view: ] >1. Should/can we treat ideographic/Asian full stops as equivalent characters ] > of the ASCII full stop (U+002E) in 100% of the possible cases/usages? ] ] SASLprep is only applicable to two use cases: simple user names and password. ] ] > The answer is no since the U+002E is not only a full stop character but ] > it is also a period and dot/decimal point character; CJK speakers do not use ] > the ideographic/Asian full stops as the dot/decimal point character and ] > hence some use of the ideographic/Asian full stops rather be preserved as ] > they are to be distingushed. And in that cases, can we distinguish what to ] > preserve and what not to preserve and map? ] ] SASLprep scope is limited to preparation of user input strings for matching. ] Issues such as how to preserving the (unprepared) user input is simply beyond ] our scope as matching and hence SASLprep. ] ] >2. Should/can we keep the compatiblity with the IDNA's additional and ] > pre-processing on the label separators, i.e., mappings of all full stops to ] > the U+002E, for the domain style (IDN) names before they are used? ] > I think the answer should be yes. ] ] SASLprep can define one preparation algorithm for simple user names and ] passwords. Simple here implies the input has no structure. That is, ] names have no particular style in respect to the algorithm. ] ] It is possible that specification using SASLprep could apply additional ] transformations be done. However, such transforms are beyond the scope ] of SASLprep. ] ] >I know the above two sound conflicting and the example shown at the argument ] >#1 could be considered as a case that may not need to be really supported. ] >But I thought presenting them might be a valuable thing to do. ] ] I would be interested in hearing whether you think the additional suggested ] mapping is appropriate or not for matching of simple user names or passwords, ] and why. ] ] I think this issue boils down to whether the user provided strings: ] ] ] ] ] ] should match or not. Because user names are often constructed from domain ] names, and IDNA says these stops are to be treated as equivalent, I believe ] they should match. ] ] Kurt ] From owner-ietf-sasl Tue Nov 4 13:16:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LGOkT072941 for ; Tue, 4 Nov 2003 13:16:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4LGO74072940 for ietf-sasl-bks; Tue, 4 Nov 2003 13:16:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hA4LGHkT072933 for ; Tue, 4 Nov 2003 13:16:18 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AH8XA-0007QQ-SV; Tue, 04 Nov 2003 22:16:16 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AH8X6-0005gb-Fu; Tue, 04 Nov 2003 22:16:12 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AH8X5-0002i1-00; Tue, 4 Nov 2003 22:16:11 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis issues In-Reply-To: <3F9C2F32.1060004@isode.com> References: <3F9C2F32.1060004@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 4 Nov 2003 22:16:11 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>draft-ietf-sasl-rfc2831bis-02.txt: >>> >>> ( *LWS element *( *LWS "," *LWS element )) >> >>Should this really be asymmetric, or should it be >> ( element *( *LWS "," *LWS element )) >>or >> ( *LWS element *( *LWS "," *LWS element ) *LWS ) >> >I can go for the last proposal. At least it seems to be the original intent. I just realized that this was copied from rfc2616. So it's probably better to leave it alone for compatibility's sake, or ask rfc2616's author. -- Hallvard From owner-ietf-sasl Wed Nov 5 02:30:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5AUdkT068698 for ; Wed, 5 Nov 2003 02:30:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5AUd6w068697 for ietf-sasl-bks; Wed, 5 Nov 2003 02:30:39 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5AUUkT068677 for ; Wed, 5 Nov 2003 02:30:37 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 10:31:29 +0000 Message-ID: <3FA8D140.1060507@isode.com> Date: Wed, 05 Nov 2003 10:30:24 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: <3F9C2F32.1060004@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>draft-ietf-sasl-rfc2831bis-02.txt: >>> >>> >>>> ( *LWS element *( *LWS "," *LWS element )) >>>> >>>> >>>Should this really be asymmetric, or should it be >>> ( element *( *LWS "," *LWS element )) >>>or >>> ( *LWS element *( *LWS "," *LWS element ) *LWS ) >>> >>> >>> >>I can go for the last proposal. At least it seems to be the original intent. >> >> > >I just realized that this was copied from rfc2616. > Correct. >So it's probably >better to leave it alone for compatibility's sake, or ask rfc2616's >author. > I've already fixed several minor ABNF bugs. But it would be a good idea to keep DIGEST-MD5 and RFC 2616 in sync. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Nov 5 08:34:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GY5kT088094 for ; Wed, 5 Nov 2003 08:34:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5GY5fL088093 for ietf-sasl-bks; Wed, 5 Nov 2003 08:34:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GY4kT088086 for ; Wed, 5 Nov 2003 08:34:04 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 4572D7661E; Wed, 5 Nov 2003 11:33:11 -0500 (EST) To: agenda@ietf.org Cc: ietf-sasl@imc.org Subject: SASL Working group agenda for IETF 58 From: Sam Hartman Date: Wed, 05 Nov 2003 11:33:11 -0500 Message-ID: <87ptg6g4hk.fsf@luminous.mit.edu> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux) 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: Simple Authentication and Security Layer Tuesday 1545-1645 0) Preliminaries - chairs - 10 min Agenda / WG Status / etc. 1) Removing security layers on re-authentication discussion - editor - 10 min (draft-ietf-sasl-rfc2222bis) 2) SASLprep "Full Stop" discussion - editor - 15 min (draft-ietf-sasl-saslprep) 3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes (draft-siemborski-rfc2554bis) 4) Next steps / Milestones - chairs - 10 minutes 5) Open Mic - floor - remaining time From owner-ietf-sasl Wed Nov 5 11:32:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JWbkT096402 for ; Wed, 5 Nov 2003 11:32:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5JWaH0096400 for ietf-sasl-bks; Wed, 5 Nov 2003 11:32:36 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5JWUkT096395 for ; Wed, 5 Nov 2003 11:32:35 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 19:33:24 +0000 Message-ID: <3FA95041.6090001@isode.com> Date: Wed, 05 Nov 2003 19:32:17 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> In-Reply-To: <3FA41ADD.2000308@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: > Alexey Melnikov wrote: > >>> The primary reason why this is better is because the change will cause >>> significant interoperability problems. Existing implementations expect >>> those layers to remain in effect. >> >> How about changing MUST to SHOULD to allow for backward compatibility >> for LDAP? > > Thinking more about this. What I didn't like about the original text > is that it was kind of MUST. > What if I rephrase to allow a protocol profile to have a choice: > either keep the original layer if none was negotiated during > reauthentication (and have a security consideration about the issue) > or remove the original layer. > If the protocol profile chooses to do the former, it should recommend > to always negotiate a new security layer during reauthentication. Ok, the new text reads: If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the protocol profile has to specify a choice between: 1) keeping the original security layer. 2) removing the original security layer (replacing with no layer). RFC 2222 only allowed for the first choice, however it was later discovered that the choice is vulnerable to a security attack described later in this section. Thus, new protocol profiles should use the second choice. The protocol profiles that depend on RFC 2222 behaviour should recommend to always negotiate another security layer, once a security layer was installed. Also note, that if a subsequent authentication fails, the protocol profile MAY allow the connection state to return to non-authenticated, however the previously negotiated security layer MUST NOT be removed. Only a successful reauthentication is able replace/remove the previously negotiated security layer. Hopefully this will make everybody happy. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Nov 5 11:39:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JdOkT096779 for ; Wed, 5 Nov 2003 11:39:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5JdOAT096778 for ietf-sasl-bks; Wed, 5 Nov 2003 11:39:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5JdNkT096767 for ; Wed, 5 Nov 2003 11:39:23 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 19:40:26 +0000 Message-ID: <3FA951E7.7090208@isode.com> Date: Wed, 05 Nov 2003 19:39:19 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: SASL Working group agenda for IETF 58 References: <87ptg6g4hk.fsf@luminous.mit.edu> In-Reply-To: <87ptg6g4hk.fsf@luminous.mit.edu> 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: Sam Hartman wrote: > Simple Authentication and Security Layer > Tuesday 1545-1645 > > > 0) Preliminaries - chairs - 10 min > Agenda / WG Status / etc. > 1) Removing security layers on re-authentication discussion - editor - 10 min > (draft-ietf-sasl-rfc2222bis) > I think I've addressed the issue to satisfy both sides (see the message I've just sent to the mailing list). Buf feel free to discuss this and let me know the outcome. Rob Siemborski is my "designed proxy" :-). > 2) SASLprep "Full Stop" discussion - editor - 15 min > (draft-ietf-sasl-saslprep) > 3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes > (draft-siemborski-rfc2554bis) > 4) Next steps / Milestones - chairs - 10 minutes > 5) Open Mic - floor - remaining time > > Is it worth sending updated versions of SASL-base and DIGEST-MD5 documents for the people to review during the meeting? Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Nov 5 11:50:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Jo2kT097476 for ; Wed, 5 Nov 2003 11:50:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Jo29T097475 for ietf-sasl-bks; Wed, 5 Nov 2003 11:50:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5Jo1kT097467 for ; Wed, 5 Nov 2003 11:50:01 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AHTfA-00013d-Rm; Wed, 05 Nov 2003 20:49:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AHTf7-0007fz-Su; Wed, 05 Nov 2003 20:49:53 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHTf7-00060Q-00; Wed, 5 Nov 2003 20:49:53 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 5 Nov 2003 20:49:53 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > (...) Only a successful reauthentication is able replace/remove the > previously negotiated security layer. Just to make sure it has been mentioned: This also means that non-SASL authentication must keep any old SASL layer. I expect that's intended, including for LDAPv4? -- Hallvard From owner-ietf-sasl Wed Nov 5 13:32:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5LWjkT001489 for ; Wed, 5 Nov 2003 13:32:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5LWjDp001488 for ietf-sasl-bks; Wed, 5 Nov 2003 13:32:45 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5LWikT001478 for ; Wed, 5 Nov 2003 13:32:44 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHVGZ-0002fI-Nz; Wed, 05 Nov 2003 22:32:39 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHVGS-0007qm-44; Wed, 05 Nov 2003 22:32:32 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHVGQ-0006FJ-00; Wed, 5 Nov 2003 22:32:30 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 5 Nov 2003 22:32:30 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > Ok, the new text reads: > (...) > If a security layer > is in effect and a subsequent SASL negotiation selects no security layer, > the protocol profile has to specify a choice between: > > 1) keeping the original security layer. > 2) removing the original security layer (replacing with no layer). This belongs in section 5 (Protocol Profile Requirements). I suggest to indent (1) and (2), BTW. > Also note, that if a subsequent authentication fails, > the protocol profile MAY allow the connection state to return to > non-authenticated, I can't find anything about that in section 5. Is it this text? "A protocol profile MAY further refine the definition of an authorization identity by adding additional syntactic restrictions and protocol-specific semantics." If so, maybe that sentence should be clarified to explicitly allow the protocol profile to say something about the effect of authentication on authentication/authorization IDs. -- Hallvard From owner-ietf-sasl Wed Nov 5 15:46:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5NkekT006253 for ; Wed, 5 Nov 2003 15:46:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5NkeYC006252 for ietf-sasl-bks; Wed, 5 Nov 2003 15:46:40 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5NkZkT006245 for ; Wed, 5 Nov 2003 15:46:35 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AHXMA-0006qx-JG; Thu, 06 Nov 2003 00:46:34 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AHXM6-000062-7T; Thu, 06 Nov 2003 00:46:30 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHXM6-0006YO-00; Thu, 6 Nov 2003 00:46:30 +0100 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov cc: SASL WG Subject: Re: Replacing a SASL security layer Date: Thu, 6 Nov 2003 00:46:30 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Ignore for a moment any relationship of realm to DIGEST-MD5, > GSSAPI or any other SASL mechanism. Let's use the definition I > have in the document: > > Conceptually, realm is the name of a collection of user's accounts. > Realms allow the protected resources on a server to be partitioned into > a set of protection spaces, each with its own authentication mechanisms > and/or authorization database. For example, a proxy/frontend can use > different realms for different servers/backends it represents. > > So, each "realm" ("a protection space") is served by a separate > server (proxy example above) or a separate process/plugin > (frontend-backend example). Does it make more sense now? Not to me. The client authenticates to server AA with realm A, and to server BB with realm B. So why does server BB see the traffic to server AA? Or if it doesn't, why does it know the realm A traffic, since that belongs on server AA? And why does the client send the same text to server AA as to server BB, sans realm differences, so that server BB can compare them? -- Hallvard From owner-ietf-sasl Wed Nov 5 16:46:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA60k4kT008149 for ; Wed, 5 Nov 2003 16:46:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA60k4HJ008148 for ietf-sasl-bks; Wed, 5 Nov 2003 16:46:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hA60k2kT008143 for ; Wed, 5 Nov 2003 16:46:03 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHYHi-00052t-D0 for ietf-sasl@imc.org; Thu, 06 Nov 2003 01:46:02 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHYHe-00044U-Ct; Thu, 06 Nov 2003 01:45:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHYHe-0006gY-00; Thu, 6 Nov 2003 01:45:58 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: unauthenticated access without SASL layer Date: Thu, 6 Nov 2003 01:45:58 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looking over the various SASL drafts, I miss one piece of functionality: To authenticate anonymously, removing any SASL layer, but still providing an unauthenticated ID (e.g. for logging purposes). LDAP provides this with the 'simple' non-SASL authentication choice, except for the part about removing the SASL layer. The ANONYMOUS mechanism (draft-ietf-sasl-anon-02.txt) can be used for this - except if the desired ID contains '@', which means the ID is an e-mail address. The PLAIN mechanism (draft-ietf-sasl-plain-03.txt) could be used if an empty password was allowed, but it isn't. Am I missing something? Should one of the mechanisms above be changed to allow this? -- Hallvard From owner-ietf-sasl Wed Nov 5 17:00:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA610bkT008908 for ; Wed, 5 Nov 2003 17:00:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA610bf6008907 for ietf-sasl-bks; Wed, 5 Nov 2003 17:00:37 -0800 (PST) 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.10/8.12.8) with ESMTP id hA610akT008901 for ; Wed, 5 Nov 2003 17:00:36 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AHYVn-0006LC-Ot for ietf-sasl@imc.org; Thu, 06 Nov 2003 02:00:35 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AHYVm-0006jF-5T; Thu, 06 Nov 2003 02:00:34 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHYVl-0006iV-00; Thu, 6 Nov 2003 02:00:33 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-sasl@imc.org Subject: rfc2222bis: 'selects no security layer' In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 02:00:33 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis says: > If a security layer is in effect and a subsequent SASL negotiation > selects no security layer, (...) Please rephrase as either 'does not select a security layer' (like PLAIN) or '(explicitly) selects that there should be no security layer' (which PLAIN does _not_ do). I presume it's the former. -- Hallvard From owner-ietf-sasl Wed Nov 5 17:41:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA61f2kT010737 for ; Wed, 5 Nov 2003 17:41:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA61f28Q010736 for ietf-sasl-bks; Wed, 5 Nov 2003 17:41:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA61f0kT010727 for ; Wed, 5 Nov 2003 17:41:00 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA61f3lg035207; Thu, 6 Nov 2003 01:41:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 05 Nov 2003 17:40:07 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: unauthenticated access without SASL layer Cc: ietf-sasl@imc.org In-Reply-To: References: 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 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >Looking over the various SASL drafts, I miss one piece of functionality: >To authenticate anonymously, removing any SASL layer, but still >providing an unauthenticated ID (e.g. for logging purposes). >Am I missing something? Should one of the mechanisms above be changed to allow this? No. If someone really wants this, they should define a new mechanism which allowed for an unauthenticated identity and a layer with a null cipher. Kurt From owner-ietf-sasl Thu Nov 6 02:35:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AZNkT001283 for ; Thu, 6 Nov 2003 02:35:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AZN5K001282 for ietf-sasl-bks; Thu, 6 Nov 2003 02:35:23 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AZJkT001150 for ; Thu, 6 Nov 2003 02:35:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:36:20 +0000 Message-ID: <3FAA23DE.7000508@isode.com> Date: Thu, 06 Nov 2003 10:35:10 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Ok, the new text reads: >> >> >>(...) >>If a security layer >>is in effect and a subsequent SASL negotiation selects no security layer, >>the protocol profile has to specify a choice between: >> >>1) keeping the original security layer. >>2) removing the original security layer (replacing with no layer). >> >> > >This belongs in section 5 (Protocol Profile Requirements). > Yes, this is also mentioned in section 5 [in my copy]. >I suggest to indent (1) and (2), BTW. > > >>Also note, that if a subsequent authentication fails, >>the protocol profile MAY allow the connection state to return to >>non-authenticated, >> >> > >I can't find anything about that in section 5. Is it this text? > > "A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics." > No. This is a new text added to allow for LDAP behaviour. >If so, maybe that sentence should be clarified to explicitly allow the >protocol profile to say something about the effect of authentication on >authentication/authorization IDs. > > Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 02:52:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AqZkT002322 for ; Thu, 6 Nov 2003 02:52:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AqZof002321 for ietf-sasl-bks; Thu, 6 Nov 2003 02:52:35 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AqYkT002316 for ; Thu, 6 Nov 2003 02:52:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:53:41 +0000 Message-ID: <3FAA27EE.50808@isode.com> Date: Thu, 06 Nov 2003 10:52:30 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >rfc2222bis says: > > >>If a security layer is in effect and a subsequent SASL negotiation >>selects no security layer, (...) >> >> > >Please rephrase as either 'does not select a security layer' (like >PLAIN) or '(explicitly) selects that there should be no security layer' >(which PLAIN does _not_ do). I presume it's the former. > > No, I actually mean both. DIGEST-MD5 has a mode when you can explicitly negotiate no security layer. I would welcome any suggestions to make this clearer. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.ht ___________________________________________ From owner-ietf-sasl Thu Nov 6 02:58:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AwCkT002584 for ; Thu, 6 Nov 2003 02:58:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AwCAQ002583 for ietf-sasl-bks; Thu, 6 Nov 2003 02:58:12 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AwBkT002576 for ; Thu, 6 Nov 2003 02:58:11 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:59:15 +0000 Message-ID: <3FAA293C.1000206@isode.com> Date: Thu, 06 Nov 2003 10:58:04 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031105173306.048bc888@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: Kurt D. Zeilenga wrote: >At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: > > >>Looking over the various SASL drafts, I miss one piece of functionality: >>To authenticate anonymously, removing any SASL layer, but still >>providing an unauthenticated ID (e.g. for logging purposes). >> How is this different from ANONYMOUS (except for >>Am I missing something? Should one of the mechanisms above be changed to allow this? >> >> > >No. If someone really wants this, they should define a new >mechanism which allowed for an unauthenticated identity and >a layer with a null cipher. > IMHO, there is no point in a layer with a null cipher, it just adds unnecessary SASL framing. Unless of course the layer does something else. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 03:14:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6BESkT004018 for ; Thu, 6 Nov 2003 03:14:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6BESxx004017 for ietf-sasl-bks; Thu, 6 Nov 2003 03:14:28 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6BERkT004012 for ; Thu, 6 Nov 2003 03:14:27 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 11:15:28 +0000 Message-ID: <3FAA2D0A.9040305@isode.com> Date: Thu, 06 Nov 2003 11:14:18 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> In-Reply-To: <3FAA293C.1000206@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: > > >>> Looking over the various SASL drafts, I miss one piece of >>> functionality: >>> To authenticate anonymously, removing any SASL layer, but still >>> providing an unauthenticated ID (e.g. for logging purposes). >>> > How is this different from ANONYMOUS (except for ... @ sign requirement). Alexey From owner-ietf-sasl Thu Nov 6 07:18:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FIxkT013907 for ; Thu, 6 Nov 2003 07:18:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FIx8i013906 for ietf-sasl-bks; Thu, 6 Nov 2003 07:18:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FIvkT013899 for ; Thu, 6 Nov 2003 07:18:58 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AHluR-00034q-MJ; Thu, 06 Nov 2003 16:18:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AHluQ-0007Zn-2E; Thu, 06 Nov 2003 16:18:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHluM-000172-00; Thu, 6 Nov 2003 16:18:50 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <3FAA27EE.50808@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:18:50 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>rfc2222bis says: >> >>>If a security layer is in effect and a subsequent SASL negotiation >>>selects no security layer, (...) >> >>Please rephrase as either 'does not select a security layer' (like >>PLAIN) or '(explicitly) selects that there should be no security layer' >>(which PLAIN does _not_ do). I presume it's the former. >> > No, I actually mean both. Now I'm confused. If a SASL security layer is active and I authenticate with PLAIN, is the layer removed or not? If it is removed, my first suggested text above clarifies that. If it is not, my second text. Are there other alternatives? > DIGEST-MD5 has a mode when you can explicitly > negotiate no security layer. Where? A search for 'layer' in rfc2831bis-02 only turns up the reference [RFC 2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. -- Hallvard From owner-ietf-sasl Thu Nov 6 07:15:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FFLkT013754 for ; Thu, 6 Nov 2003 07:15:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FFLV9013753 for ietf-sasl-bks; Thu, 6 Nov 2003 07:15:21 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FFKkT013748 for ; Thu, 6 Nov 2003 07:15:20 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6FFLlg042692; Thu, 6 Nov 2003 15:15:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 07:14:25 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: 'selects no security layer' Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FAA27EE.50808@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@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 02:52 AM 11/6/2003, Alexey Melnikov wrote: >I would welcome any suggestions to make this clearer. I think one of the problems we have adding this profile option is that the specification is now much more complex and framework implementations, especially those which support both options, will need to be much more complex. We need to keep SASL and the specification of SASL simple. I don't see the risk from the described threat being so high to warrant the insertion of this option ESPECIALLY given that the option doesn't not fully address the vulnerability. The information sent under the subsequent layers is still contains information known by those involved in the reauthentication. Kurt From owner-ietf-sasl Thu Nov 6 07:10:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FAwkT013591 for ; Thu, 6 Nov 2003 07:10:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FAwaq013590 for ietf-sasl-bks; Thu, 6 Nov 2003 07:10:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FAqkT013571 for ; Thu, 6 Nov 2003 07:10:52 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6FArlg042616; Thu, 6 Nov 2003 15:10:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 07:09:57 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: unauthenticated access without SASL layer Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FAA293C.1000206@isode.com> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@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 02:58 AM 11/6/2003, Alexey Melnikov wrote: >>No. If someone really wants this, they should define a new >>mechanism which allowed for an unauthenticated identity and >>a layer with a null cipher. >IMHO, there is no point in a layer with a null cipher, it just adds unnecessary SASL framing. Unless of course the layer does something else. It replaces the previous layers. Hallvard wanted a way to do that, I assume for application protocols which only replace layers (don't deinstall them). This points out a serious problem with your suggestion that some protocols can deinstall layers will others can leave them installed, the applicability of the mechanism may be highly dependent on whether all layers can be removed once established or not. The more I think about adding the option to remove layers on reauthentication, the more I think it is a bad idea. Kurt From owner-ietf-sasl Thu Nov 6 07:22:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FMVkT014087 for ; Thu, 6 Nov 2003 07:22:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FMV9p014086 for ietf-sasl-bks; Thu, 6 Nov 2003 07:22:31 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FMUkT014080 for ; Thu, 6 Nov 2003 07:22:30 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AHlxq-0003Rb-4X; Thu, 06 Nov 2003 16:22:26 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AHlxk-0007zM-W1; Thu, 06 Nov 2003 16:22:20 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHlxk-00017M-00; Thu, 6 Nov 2003 16:22:20 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FAA23DE.7000508@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA23DE.7000508@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:22:20 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>Alexey Melnikov writes: >> >>>Also note, that if a subsequent authentication fails, >>>the protocol profile MAY allow the connection state to return to >>>non-authenticated, >> >>I can't find anything about that in section 5. Is it this text? >> >> "A protocol profile MAY further refine the definition of an >> authorization identity by adding additional syntactic restrictions >> and protocol-specific semantics." >> > No. > This is a new text added to allow for LDAP behaviour. That it allows for LDAP is fine, but I'm wondering about the text 'the protocol profile MAY allow the connection state to return to non-authenticated'. If it's not the text I quoted, allowing the connection state to return to non-authenticated has nothing to do with the protocol profile at all. -- Hallvard From owner-ietf-sasl Thu Nov 6 07:36:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Fa7kT014707 for ; Thu, 6 Nov 2003 07:36:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Fa7a5014706 for ietf-sasl-bks; Thu, 6 Nov 2003 07:36:07 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6Fa6kT014699 for ; Thu, 6 Nov 2003 07:36:06 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHmAz-00058I-0D; Thu, 06 Nov 2003 16:36:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHmAw-0001k0-24; Thu, 06 Nov 2003 16:35:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHmAs-00019i-00; Thu, 6 Nov 2003 16:35:54 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer In-Reply-To: <3FAA293C.1000206@isode.com> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:35:54 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Kurt D. Zeilenga wrote: >>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >> >>> Looking over the various SASL drafts, I miss one piece of functionality: >>> To authenticate anonymously, removing any SASL layer, but still >>> providing an unauthenticated ID (e.g. for logging purposes). >>> > How is this different from ANONYMOUS (except for @ sign requirement). That's the difference. If there is nothing special about the '@' character in the underlying auth IDs, then the exclusion of names with '@' in them is unnatural. Though one could of course introduce a private hack like using \ for a quote character and type @ as \40, or something. -- Hallvard From owner-ietf-sasl Thu Nov 6 07:38:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Fc0kT014810 for ; Thu, 6 Nov 2003 07:38:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Fc0xf014809 for ietf-sasl-bks; Thu, 6 Nov 2003 07:38:00 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FbxkT014802 for ; Thu, 6 Nov 2003 07:37:59 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHmCq-0005Ka-1x; Thu, 06 Nov 2003 16:37:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHmCn-0001y8-S5; Thu, 06 Nov 2003 16:37:53 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHmCn-00019w-00; Thu, 6 Nov 2003 16:37:53 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer In-Reply-To: <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:37:53 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 02:58 AM 11/6/2003, Alexey Melnikov wrote: > >> IMHO, there is no point in a layer with a null cipher, it just adds >> unnecessary SASL framing. Unless of course the layer does something >> else. > > It replaces the previous layers. Hallvard wanted a way to do that, > I assume for application protocols which only replace layers (don't > deinstall them). Yes. It was a mistake to mention this in relation to an ANONYMOUS-like auth, though. It belongs in the 'selects no security layer' thread. -- Hallvard From owner-ietf-sasl Thu Nov 6 08:07:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6G7tkT016432 for ; Thu, 6 Nov 2003 08:07:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6G7toF016431 for ietf-sasl-bks; Thu, 6 Nov 2003 08:07:55 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6G7skT016425 for ; Thu, 6 Nov 2003 08:07:54 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 16:09:02 +0000 Message-ID: <3FAA71D7.3090908@isode.com> Date: Thu, 06 Nov 2003 16:07:51 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>rfc2222bis says: >>> >>> >>>>If a security layer is in effect and a subsequent SASL negotiation >>>>selects no security layer, (...) >>>> >>>> >>>Please rephrase as either 'does not select a security layer' (like >>>PLAIN) or '(explicitly) selects that there should be no security layer' >>>(which PLAIN does _not_ do). I presume it's the former. >>> >>> >>No, I actually mean both. >> >> > >Now I'm confused. If a SASL security layer is active and I authenticate >with PLAIN, is the layer removed or not? If it is removed, my first >suggested text above clarifies that. If it is not, my second text. Are >there other alternatives? > Using your own words: PLAIN (implicitly) selects that there should be no security layer, as it is unable to negotiate any. >>DIGEST-MD5 has a mode when you can explicitly >>negotiate no security layer. >> >> > >Where? A search for 'layer' in rfc2831bis-02 only turns up the >reference > > [RFC 2222] Myers, J., "Simple Authentication and Security Layer > (SASL)", RFC 2222, October 1997. > Sections 2.3 and 2.4. Also search for "qop-options" Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 09:01:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6H1lkT019060 for ; Thu, 6 Nov 2003 09:01:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6H1lQx019059 for ietf-sasl-bks; Thu, 6 Nov 2003 09:01:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6H1jkT019051 for ; Thu, 6 Nov 2003 09:01:45 -0800 (PST) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hA6H1fmW031162 for ; Thu, 6 Nov 2003 12:01:41 -0500 Received: from att.com (tony-ob.mt.att.com[135.91.110.124](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031106165844gw100lr6g3e> (Authid: tony); Thu, 6 Nov 2003 16:58:44 +0000 Message-ID: <3FAA7E9E.3080704@att.com> Date: Thu, 06 Nov 2003 12:02:22 -0500 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 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: Section "4.2. Authorization identities and proxy authentication", appears to be mixing two totally different discussions together in a slightly confusing mess. The first discussion is about there being two IDs being passed through the mechanism (the authorization identity and the authentication identity) and how they are used, including what it means for the authorization identity to be empty and non-empty. The second discussion that's intermingled with the first discussion is about the format of the two identities. For example, consider this sentence: While some legacy mechanisms are incapable of transmitting an authorization identity other than the empty string, newly defined mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character). This sentence starts by saying that some legacy mechanisms don't provide an authorization identity, but newly defined mechanisms are expected to. But it never finishes saying that. Instead, it diverts the sentence into discussing what the authorization identity should look like. May I suggest that this section be rewritten so that it focusses on the two topics separately. For example, something like the following below might be considered. Tony Hansen tony@att.com 4.2. Authorization and authentication identities, and proxy authentication SASL authentication deals with two identities: the authorization identity and the authentication identity. The transmitted authorization identity may be an empty string (zero length), but the transmitted authentication identity may not be an empty string. (While some legacy mechanisms are incapable of transmitting an authorization identity other than the empty string, newly defined mechanisms SHOULD be capable of transmiting a non-empty authorization identity.) The authorization identity is used by the server as the primary identity for making access policy decisions. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive the authorization identity from the client's authentication identity. If the authorization identity transmitted during the authentication protocol exchange is not the empty string, this is typically referred to as "proxy authentication". This feature permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. The server makes an implementation defined policy decision as to whether the authentication identity is permitted to have the access privileges of the authorization identity and whether the authorization identity is permitted to receive service. If it is not, the server indicates failure of the authentication protocol exchange. As a client might not have the same information as the server, clients SHOULD NOT themselves try to derive authorization identities from authentication identities when clients could instead transmit an authorization identity of the empty string. The server SHOULD verify the correctness of a received authorization identity. Profiles whose authorization identities are simple user names (e.g. IMAP [RFC 3501]) are encouraged to employ [SASLPrep] profile [SASLPrep] of the "stringprep" algorithm [StringPrep] to prepare these names for matching. If the preparation of the authorization identity fails or results in an empty string, the server MUST fail the authentication exchange. The only exception to this rule is when the received authorization identity is already the empty string. 4.x Authorization Identity and Authentication Identity Formats An authorization identity and an authentication identity are strings of ISO 10646 [ISO-10646] coded characters. The NUL (U+0000) character is not permitted in authorization or authentication identities. The character encoding scheme used for transmitting an authorization identity over a protocol is specified in each authentication mechanism (with the authentication mechanism's blob being further restricted/encoded by the protocol profile). Per IETF character set policy [CHARSET-POLICY], authentication mechanisms SHOULD encode these and other strings in UTF-8 [UTF-8]. Mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character). An authorization identity of the empty string and and an absent authorization identity MUST be treated as equivalent. However, mechanisms SHOULD NOT allow both (i.e. if an authorization identity is allowed to be absent, but one is transferred, it SHOULD NOT be an empty string). From owner-ietf-sasl Thu Nov 6 10:57:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IvKkT024542 for ; Thu, 6 Nov 2003 10:57:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6IvK48024541 for ietf-sasl-bks; Thu, 6 Nov 2003 10:57:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IvDkT024534 for ; Thu, 6 Nov 2003 10:57:14 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA6IvDWj005150; Thu, 6 Nov 2003 13:57:13 -0500 Date: Thu, 6 Nov 2003 13:57:14 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@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: On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > At 02:52 AM 11/6/2003, Alexey Melnikov wrote: > >I would welcome any suggestions to make this clearer. > > I think one of the problems we have adding this profile option > is that the specification is now much more complex and > framework implementations, especially those which support both > options, will need to be much more complex. We need to keep > SASL and the specification of SASL simple. I have to agree with Kurt here. One of the major benefits of SASL is that the framework layer has been historically simple. Allowing both modes (dropping the layer or continuing under the old layer) needlessly complicates the implementation and breaks backwards compatibility for minimal gain. > I don't see the risk from the described threat being so high > to warrant the insertion of this option ESPECIALLY given that > the option doesn't not fully address the vulnerability. The > information sent under the subsequent layers is still contains > information known by those involved in the reauthentication. I tend to agree with this assessment. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 6 13:14:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LEXkT030402 for ; Thu, 6 Nov 2003 13:14:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LEXMT030401 for ietf-sasl-bks; Thu, 6 Nov 2003 13:14:33 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6LEVkT030395 for ; Thu, 6 Nov 2003 13:14:32 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 21:15:38 +0000 Message-ID: <3FAAB9B2.2000206@isode.com> Date: Thu, 06 Nov 2003 21:14:26 +0000 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: Rob Siemborski CC: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> In-Reply-To: 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: Rob Siemborski wrote: >On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > > >>At 02:52 AM 11/6/2003, Alexey Melnikov wrote: >> >> >>>I would welcome any suggestions to make this clearer. >>> >>> >>I think one of the problems we have adding this profile option >>is that the specification is now much more complex and >>framework implementations, especially those which support both >>options, will need to be much more complex. We need to keep >>SASL and the specification of SASL simple. >> >> > >I have to agree with Kurt here. One of the major benefits of SASL is that >the framework layer has been historically simple. Allowing both modes >(dropping the layer or continuing under the old layer) needlessly >complicates the implementation > Which implementation are you talking about? > and breaks backwards compatibility for >minimal gain. > A protocol profile is not allowed to do both. It has to document a choice. This is a checkbox. There is only a single protocol that currently allows for reauthentication. >>I don't see the risk from the described threat being so high >>to warrant the insertion of this option ESPECIALLY given that >>the option doesn't not fully address the vulnerability. >> True. But it is more difficult to implement an attack during reauthentication. And servers should drop connection after some number of failed authentications. >> The >>information sent under the subsequent layers is still contains >>information known by those involved in the reauthentication. >> Actually, I am not sure I understand what are you saying here Kurt. >I tend to agree with this assessment. > > Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 13:35:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LZbkT031268 for ; Thu, 6 Nov 2003 13:35:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LZbcl031267 for ietf-sasl-bks; Thu, 6 Nov 2003 13:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-FOURTEEN.MIT.EDU [18.187.5.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LZakT031262 for ; Thu, 6 Nov 2003 13:35:36 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 20FFF15159E; Thu, 6 Nov 2003 16:35:13 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> From: Sam Hartman Date: Thu, 06 Nov 2003 16:35:13 -0500 In-Reply-To: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> (Ienup Sung's message of "Mon, 03 Nov 2003 11:51:56 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Ienup" == Ienup Sung writes: Ienup> I agree that the SASLprep is more suitable and applicable Ienup> for simple user names and passwords and if the additional Ienup> mappings such as the full stops are needed, they are more Ienup> suitable and correct to be done at the outside of any Ienup> Stringprep/Stringprep profiles and most preferrably before Ienup> the application of the Stringprep profile(s). <-- These are Ienup> also my points all along. I think Kurt's point was that since saslprep was for usernames and passwords, it is more appropriate to do full-stop mappings there than in some more general context. Do we expect people to need decimal points in their usernames? Do we think it a problem if someone uses a decimal point in a password, but can later use one of the other full-stop characters and have it work? --Sam From owner-ietf-sasl Thu Nov 6 14:37:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MbnkT033566 for ; Thu, 6 Nov 2003 14:37:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Mbn0H033565 for ietf-sasl-bks; Thu, 6 Nov 2003 14:37:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MbmkT033559 for ; Thu, 6 Nov 2003 14:37:48 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hA6Mbbdo011266; Thu, 6 Nov 2003 15:37:39 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 06 Nov 2003 15:37:32 -0700 From: Lyndon Nerenberg To: Sam Hartman , Ienup Sung cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <2147483647.1068133052@[192.168.42.6]> In-Reply-To: References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: > I think Kurt's point was that since saslprep was for usernames and > passwords, it is more appropriate to do full-stop mappings there than > in some more general context. Do we expect people to need decimal > points in their usernames? firstname.lastname is a very common scheme for forming identifiers, so yes we do need to support decimal points (and their equivalent mappings) in usernames. --lyndon From owner-ietf-sasl Thu Nov 6 14:29:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MTtkT033049 for ; Thu, 6 Nov 2003 14:29:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6MTsuL033048 for ietf-sasl-bks; Thu, 6 Nov 2003 14:29:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MTrkT033042 for ; Thu, 6 Nov 2003 14:29:53 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA6MTsWj009655; Thu, 6 Nov 2003 17:29:54 -0500 Date: Thu, 6 Nov 2003 17:29:54 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <3FAAB9B2.2000206@isode.com> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@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: On Thu, 6 Nov 2003, Alexey Melnikov wrote: > >>I think one of the problems we have adding this profile option > >>is that the specification is now much more complex and > >>framework implementations, especially those which support both > >>options, will need to be much more complex. We need to keep > >>SASL and the specification of SASL simple. > > > >I have to agree with Kurt here. One of the major benefits of SASL is that > >the framework layer has been historically simple. Allowing both modes > >(dropping the layer or continuing under the old layer) needlessly > >complicates the implementation > > Which implementation are you talking about? I'll use the CMU SASL implementation as an example, but I don't think it really matters. Using RFC2222, if you had a re-authentication and the new session didn't have a security layer, you would need to keep the old SASL context around and continue to use it for security layer purposes (from an API standpoint, this sucks, granted). In 2222bis-03, you no longer have to do this, but it breaks LDAP as deployed (which is bad). In your suggested text, there's no longer a set way of handling this -- it varies from protocol to protocol (as long as they allow reauthentication). And its yet another thing that can be gotten wrong in an implementation. In any case though, I suppose this is application layer not framework layer. Due to the related nature of many of the protocols that implement SASL, we often see one product using SASL for many protocols at once (a mail client can implement POP3, IMAP, SMTP, LDAP and IMSP/ACAP without breaking a sweat, and a mail server can come close to twice that). Subtle differences between these protocols can be a nightmare for implementors (just look at how similar the new POP3 and SMTP profiles are, yet how they both have subtle differences). I fear what will happen when we have another protocol that allows reauthentication but does it in a different way from LDAP. Then again, maybe you're right and the benefits of allowing it both ways outweigh the implementation complexity -- especially given the (somewhat inevitable, I think) upcoming "SASL Implementation Recommendations" document. > True. But it is more difficult to implement an attack during > reauthentication. And servers should drop connection after some number > of failed authentications. Are we both talking about the vulnerability discussed at the bottom of section 6.3? I may be misunderstanding the problem -- as I read it, we don't want the initial realm to be able to read traffic going to the newly-authenticated realm. But if the new authentication doesn't have a security layer, how is dropping the old security layer any benefit? We're moving from a tunneled layer (which, granted, can be read/modified by the initial realm) to one that can be read/modified by anyone! I definitely see a win with forcing a change when the new authentication creates a new security layer, but in the absence of a new security layer, I'm not seeing the benefit. > >> The > >>information sent under the subsequent layers is still contains > >>information known by those involved in the reauthentication. > >> > Actually, I am not sure I understand what are you saying here Kurt. Now that I re-read this, I'm not sure it applies to the vulnerability discussed in 6.3. However, it is true that if I know a good deal of the plaintext that you are sending encrypted (e.g. I am a backend server and you are a proxy), I have a huge advantage in trying to break your session key with a client. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 6 14:57:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MvQkT034362 for ; Thu, 6 Nov 2003 14:57:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6MvQCI034361 for ietf-sasl-bks; Thu, 6 Nov 2003 14:57:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-FOURTEEN.MIT.EDU [18.187.5.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MvPkT034356 for ; Thu, 6 Nov 2003 14:57:25 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 3F2C215159E; Thu, 6 Nov 2003 17:56:57 -0500 (EST) To: Lyndon Nerenberg Cc: Ienup Sung , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> <2147483647.1068133052@[192.168.42.6]> From: Sam Hartman Date: Thu, 06 Nov 2003 17:56:57 -0500 In-Reply-To: <2147483647.1068133052@[192.168.42.6]> (Lyndon Nerenberg's message of "Thu, 06 Nov 2003 15:37:32 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> firstname.lastname is a very common scheme for forming Lyndon> identifiers, so yes we do need to support decimal points Lyndon> (and their equivalent mappings) in usernames. But it seems like in this case mapping all the full stops together would be desirable. From owner-ietf-sasl Thu Nov 6 15:34:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6NY3kT035593 for ; Thu, 6 Nov 2003 15:34:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6NY34i035592 for ietf-sasl-bks; Thu, 6 Nov 2003 15:34:03 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6NXwkT035587 for ; Thu, 6 Nov 2003 15:33:58 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6NY0lg048275; Thu, 6 Nov 2003 23:34:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106141242.04a26900@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 15:33:03 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: 'selects no security layer' Cc: ietf-sasl@imc.org In-Reply-To: <3FAAB9B2.2000206@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@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 01:14 PM 11/6/2003, Alexey Melnikov wrote: >Actually, I am not sure I understand what are you saying here Kurt. Part of the problem here is that I am (and maybe others are) having trouble making sense of your scenario. After further examination, I think your text and picture don't match up. The text implies the layers are active between the client and the Realm A server called AA, but your picture implies the layers are active between the client and the middlebox ("proxy/frontend"). If the layers are active between the client and server AA, then the middlebox could not normally insert a re-authenication to server BB without coordination from AA. That is, the middle box would need to know how to decrypt/encrypt the exchanges (before, during, after reauthentication). If AA doesn't trust the middlebox (and its relations with the likes of BB), then AA simply need not provide the secrets to the middlebox necessary to support reauthentication with others. If AA does trust the middlebox, then it implicitly accepts the risk of that trust. If the layers are active between the client and middlebox, the middlebox likely would need cooperation from AA to support reauthentication to BB. (In this case, it would be better to call the middlebox the SASL server and AA and BB "external systems" (not servers).) If AA doesn't trust the middlebox, then it should not cooperate with it. But if it does, even if layers are dropped, it (AA) would be vulnerable to attack from BB because the subsequent exchange (which BB has knowledge of) is protected by those layers. In either case, this risk is quite limited and can be managed as part of the trust relationship between AA and the middlebox. I think these scenarios are part of a larger class of vulnerabilities: attacks from 3rd parties which have limited knowledge of information protected by the SASL. I think this class of vulnerabilities is best addressed by stating a broad security consideration (possibly supported by one or two specific examples). Kurt From owner-ietf-sasl Thu Nov 6 16:28:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA70SdkT037271 for ; Thu, 6 Nov 2003 16:28:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA70Sdfr037270 for ietf-sasl-bks; Thu, 6 Nov 2003 16:28:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA70SckT037265 for ; Thu, 6 Nov 2003 16:28:38 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA70Sc5u016065; Thu, 6 Nov 2003 17:28:39 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA70SUDS005048; Thu, 6 Nov 2003 16:28:30 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNY0013XHBQT5@mpkmail.eng.sun.com>; Thu, 06 Nov 2003 16:28:38 -0800 (PST) Date: Thu, 06 Nov 2003 16:28:38 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNY0013YHBQT5@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: rzDg7/uVrejlQtuahVpKbg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, the POSIX/SUS/XPG specifies that the poratble user names be in the portable file name character set and it includes [A-Za-z._-] with some additional rules. I also have seen many people using the 0x2e in their user names and passwords. And, while I believe I do understand that the SASLprep is intended for simple user names and passowrds at the moment, I believe I'm seeing the full stops vs decimal point issue a bit differently... (and maybe in that way, I'm wrong about it...) I think there will be problems if we treat the Asian full stops as equivalents to the ASCII decimal point/dot/full stop character simply because the Asian full stops are not equivalent to the ASCII decimal points all the time. In other words, Asian people are and will distinguish (almost implicitly) when to use the Asian/ASCII full stops and when to use the decimal point character; if coerced at the protocol level that the Asian full stops are all mapped to the U+002E for all the cases, people will be, sometimes, confused. I do see the pros of convenience but that will, in my opinion, come in with the price of denying the fact that the Asian full stops are only and conditionally equivalent to the U+002E (when the U+002E means the full stop). In other words, by having the general full stop mappings, we are denying the possibility of Asian people using the full stops and decimal points differently in their user names and passwords. I personally can live with such general mappings and so thus many other Asians in my opinion but when we do know about the fact that the characters are different and virtually and practically we are not capable of distinguishing when the two groups of characters can be treated equal or not with the Stringprep and SALSprep, it seems to me that it is not really a good idea to have a generic, simple table-driven mappings at the SASLprep (even for the simple user names and passwords)... Should more opinions needed and if the WG folks agree and assign to me, I can bring this exactly the same question of whether we can treat the Asian full stops as the decimal point to the Unicode Technical Committee and get the opinion of the UTC back to the WGs. With regards, Ienup PS. By the way, on a bit different topic, reading the SALSprep and also the PLAIN mechanism drafts, it appears there is no AllowUnassigned flag setting or mentioning of it in the drafts. Has this issue been discussed and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? If not, it seems either explicitly defining that the unassigned Unicode characters are not allowed in the drafts, or, allow setting of the AllowUnassigned flag as either True or False at the PLAIN draft appears necesary so that the versioning issue is clearly stated... If this question has been asked and answered, sorry, please let me know and I'll scan more of the archived emails. ] Date: Thu, 06 Nov 2003 16:35:13 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> I agree that the SASLprep is more suitable and applicable ] Ienup> for simple user names and passwords and if the additional ] Ienup> mappings such as the full stops are needed, they are more ] Ienup> suitable and correct to be done at the outside of any ] Ienup> Stringprep/Stringprep profiles and most preferrably before ] Ienup> the application of the Stringprep profile(s). <-- These are ] Ienup> also my points all along. ] ] I think Kurt's point was that since saslprep was for usernames and ] passwords, it is more appropriate to do full-stop mappings there than ] in some more general context. Do we expect people to need decimal ] points in their usernames? Do we think it a problem if someone uses a ] decimal point in a password, but can later use one of the other ] full-stop characters and have it work? ] ] --Sam ] From owner-ietf-sasl Thu Nov 6 17:47:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71l9kT039951 for ; Thu, 6 Nov 2003 17:47:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA71l9VM039949 for ietf-sasl-bks; Thu, 6 Nov 2003 17:47:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71l7kT039944 for ; Thu, 6 Nov 2003 17:47:07 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA71l8Wj031547; Thu, 6 Nov 2003 20:47:08 -0500 Date: Thu, 6 Nov 2003 20:47:08 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <6.0.0.22.0.20031106141242.04a26900@127.0.0.1> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@isode.com> <6.0.0.22.0.20031106141242.04a26900@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: On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > If the layers are active between the client and server AA, > then the middlebox could not normally insert a re-authenication to > server BB without coordination from AA. That is, the middle > box would need to know how to decrypt/encrypt the exchanges > (before, during, after reauthentication). If AA doesn't trust > the middlebox (and its relations with the likes of BB), then AA > simply need not provide the secrets to the middlebox necessary > to support reauthentication with others. If AA does trust > the middlebox, then it implicitly accepts the risk of that trust. > > If the layers are active between the client and middlebox, > the middlebox likely would need cooperation from AA to > support reauthentication to BB. (In this case, it would be > better to call the middlebox the SASL server and AA and BB > "external systems" (not servers).) If AA doesn't trust the > middlebox, then it should not cooperate with it. But if it > does, even if layers are dropped, it (AA) would be vulnerable > to attack from BB because the subsequent exchange (which > BB has knowledge of) is protected by those layers. Ah, I think I misunderstood the example slightly [didn't understand how the middlebox was playing with the rest of the system]. However, I still agree with Kurt -- this is a minimal case that can be dismissed with a Security Consideration about the trust relationships involved. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 6 18:21:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA72LLkT041479 for ; Thu, 6 Nov 2003 18:21:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA72LLUc041478 for ietf-sasl-bks; Thu, 6 Nov 2003 18:21:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA72LJkT041473 for ; Thu, 6 Nov 2003 18:21:20 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA72LIBU008619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Nov 2003 21:21:20 -0500 (EST) Message-ID: <3FAB0194.2090808@columbia.edu> Date: Thu, 06 Nov 2003 21:21:08 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNY0013YHBQT5@mpkmail.eng.sun.com> In-Reply-To: <0HNY0013YHBQT5@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020500020203020202030107" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020500020203020202030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The question is not whether or not the different full stops are used by different people in different ways at the user interface level. The transformations we are discussing for use with SASLPrep are specific to the use of the strings as Storage and Query strings; not as Display strings. When a string is to be used as a username or a password is there a reason why we should be concerned with distinguishing the differences? If there is not a good reason to preserve the differences then there is a reasonable argument to fold them similar to the arguments for folding spacing characters. Users will always be free to choose one representation over another. It is only on the wire that there should be a distinction. Jeffrey Altman Ienup Sung wrote: >I think there will be problems if we treat the Asian full stops as equivalents >to the ASCII decimal point/dot/full stop character simply because the Asian >full stops are not equivalent to the ASCII decimal points all the time. >In other words, Asian people are and will distinguish (almost implicitly) when >to use the Asian/ASCII full stops and when to use the decimal point character; >if coerced at the protocol level that the Asian full stops are all >mapped to the U+002E for all the cases, people will be, sometimes, confused. > >I do see the pros of convenience but that will, in my opinion, come in with >the price of denying the fact that the Asian full stops are only and >conditionally equivalent to the U+002E (when the U+002E means the full stop). >In other words, by having the general full stop mappings, we are denying >the possibility of Asian people using the full stops and decimal points >differently in their user names and passwords. > > > --------------ms020500020203020202030107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwNzAyMjEwOFowIwYJKoZIhvcNAQkEMRYEFLTXMmqjlhNl 7TvuiG+w5WeSE8pbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAACslROIT5rqbi2N+JiyjJe7cMXdq FntX0j08ngYKjBwyv0b3OlQBFWcK84uM8+lbJf89qpVRAYElPcZL5/DhGqG8KxR6smuOw6m0 flp60/oOoi68ndqTKHh8meKPhsRJ/3OeHXsFc3j//DR8JOVdDOFwKv0KCesdRxeDNewJ82sF tG9bLkhEk3zPY0vnae5q9lRfmMvte0sRa/XyTj+LoZHBAlRRXIaO3DeRwzpp88gevgff3bG1 MuWGk4L0yr3SQQdfBuupryHTGU0F3+AQH04wVbWl584LUGrK06cCgR9JcaME1bH5/LVBBjYr 0LeVUuGVfrUP3rH1tW35vUXtewAAAAAAAA== --------------ms020500020203020202030107-- From owner-ietf-sasl Fri Nov 7 11:35:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7JZlkT050089 for ; Fri, 7 Nov 2003 11:35:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7JZlBd050088 for ietf-sasl-bks; Fri, 7 Nov 2003 11:35:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7JZkkT050083 for ; Fri, 7 Nov 2003 11:35:46 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA7JZk5u011478; Fri, 7 Nov 2003 12:35:46 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA7JZbDS009564; Fri, 7 Nov 2003 11:35:37 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNZ00IWCYFLIA@mpkmail.eng.sun.com>; Fri, 07 Nov 2003 11:35:46 -0800 (PST) Date: Fri, 07 Nov 2003 11:35:46 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=UTF-8 Content-MD5: cvDLdFlktZQJJSr4KNqsHw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA7JZkkT050084 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually that's exactly the problem that I was also talking about since people will treat the Asian full stops and U+002E differently at Asian countries and when people tried to register a new user account with let say 3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user account system could say, sorry, we already have 3.14 (that is three point one four) which is totally different user account name and would deny the new user account name which will be quite confusing for Asian people. With regards, Ienup ] Date: Thu, 06 Nov 2003 21:21:08 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] The question is not whether or not the different full stops are used by ] different people in different ways at the user interface level. The ] transformations ] we are discussing for use with SASLPrep are specific to the use of the ] strings ] as Storage and Query strings; not as Display strings. When a string is ] to be used ] as a username or a password is there a reason why we should be concerned ] with ] distinguishing the differences? If there is not a good reason to ] preserve the ] differences then there is a reasonable argument to fold them similar to ] the arguments ] for folding spacing characters. ] ] Users will always be free to choose one representation over another. It ] is only ] on the wire that there should be a distinction. ] ] Jeffrey Altman ] ] ] Ienup Sung wrote: ] ] >I think there will be problems if we treat the Asian full stops as equivalents ] >to the ASCII decimal point/dot/full stop character simply because the Asian ] >full stops are not equivalent to the ASCII decimal points all the time. ] >In other words, Asian people are and will distinguish (almost implicitly) when ] >to use the Asian/ASCII full stops and when to use the decimal point character; ] >if coerced at the protocol level that the Asian full stops are all ] >mapped to the U+002E for all the cases, people will be, sometimes, confused. ] > ] >I do see the pros of convenience but that will, in my opinion, come in with ] >the price of denying the fact that the Asian full stops are only and ] >conditionally equivalent to the U+002E (when the U+002E means the full stop). ] >In other words, by having the general full stop mappings, we are denying ] >the possibility of Asian people using the full stops and decimal points ] >differently in their user names and passwords. ] > ] > ] > From owner-ietf-sasl Fri Nov 7 12:16:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KGnkT051434 for ; Fri, 7 Nov 2003 12:16:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7KGniX051433 for ietf-sasl-bks; Fri, 7 Nov 2003 12:16:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KGlkT051427 for ; Fri, 7 Nov 2003 12:16:47 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7KGbB9020077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Nov 2003 15:16:45 -0500 (EST) Message-ID: <3FABFD99.8010107@columbia.edu> Date: Fri, 07 Nov 2003 15:16:25 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> In-Reply-To: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060403050102060802000005" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060403050102060802000005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit It is absolutely a trade off. Avoidance of end user confusion because they could not tell the difference between the full stops and the ability to specify them as different strings. By choosing to fold the full stops we are saying that we believe that there will be more confusion by users who try to use one form of full stop when they should be using another than the confusion which will be caused for system administrators who desire to create accounts which only differ by the type of full stop used. Jeffrey Altman Ienup Sung wrote: >Actually that's exactly the problem that I was also talking about since >people will treat the Asian full stops and U+002E differently at Asian >countries and when people tried to register a new user account with let say >3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user >account system could say, sorry, we already have 3.14 (that is three point >one four) which is totally different user account name and would deny >the new user account name which will be quite confusing for Asian people. > >With regards, > >Ienup > > > --------------ms060403050102060802000005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwNzIwMTYyNVowIwYJKoZIhvcNAQkEMRYEFDu7NOJQKEDW EZbQ0eF75sbu1x+QMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAtV0OcgT6ZT6hqTqs4GWeurOp3c8B BkxBB4DijlFg1gopxa8bCywF8+ZRk0/PuIuXtNkhDVRYhFaZvVfXvEaoD+ByEm4ujhFlpuk3 J3clZTya6lF20bO/4zerMkkm6Kuu0wLc41TySbrf6TZAfhQN4dnqce+xhZHpJp4gigvB8+Cf q8QHohmdwstU0PUHfTpeOoZWrSpk752/JgVFIGg2//p6h8z4vrHumrMnYPICXf4x/RsXsWZ7 XWA0sfw/OERNA9QM757CCBG8HeFS1KvzfSxg6Y98bo19NKKd4QqDFbxbryK7++hI5+73PP/L QD5LcCNP/V1+JPEnpRKYUul3PgAAAAAAAA== --------------ms060403050102060802000005-- From owner-ietf-sasl Fri Nov 7 13:07:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7L79kT052972 for ; Fri, 7 Nov 2003 13:07:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7L78Dp052971 for ietf-sasl-bks; Fri, 7 Nov 2003 13:07:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7L78kT052959 for ; Fri, 7 Nov 2003 13:07:08 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA7L74xA011550; Fri, 7 Nov 2003 13:07:04 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA7L6tDS029035; Fri, 7 Nov 2003 13:06:55 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO000I9V2NRIA@mpkmail.eng.sun.com>; Fri, 07 Nov 2003 13:07:04 -0800 (PST) Date: Fri, 07 Nov 2003 13:07:04 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO000I9W2NSIA@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: multipart/mixed; boundary="Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ) Content-type: TEXT/plain; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE Content-MD5: xiCw1QO9AzRAFXH/mDmrFA== I believe the question is whether to (incorrectly) generalize/map or not in= my opinion. Actually the confusion will also and sure to occur if you map the all full stops to the U+002E since Asian people distinguish the U+002E and the U+300= 2 even without any thinking if you wrongly use the full stops in the place of decimal point. The point that I can make further is that people have been using various Asian codesets/codepages that have different code point values and differen= t input mechanisms for each of those Asian full stops and the ASCII decimal points many years; they see them and use them differently. The NFKC used in SASLprep will map the U+FF0E to the U+002E since they are equivalent and should be normalized. On the other hands, the U+3002 and the U+FF61 are not equivalent to the U+002E but only to themselves, i.e., the U+FF61 will map to the U+3002 after the NFKC. Here is also another practical example: the ATOK is, arguably, the most pop= ular Japanese input system in my understanding. When you use ATOK to input Japanese, what happens is that when you type with numbers, you will get '.' automatically if you press dot key from your keyboard. When a sentense is ending, used by itself alone, or surrounded with non-gidits, the dot key will be interpreted as the ideographic/Asian full-stop of U+3002. In other words, to input ideographic/Asian full stop (U+3002) with number isn't that easy and when that happened, i.e., a user typed in the U+3002 among numbers= , that means it is most definitely not the full stop. Furthermore, you can as= k any Asian people around you if you can use full stop in a number/numeric notation; most likely almost 100% of them will say, No Way. (Also and at the same time, just as for info, Asian people will absolutely accept and tolerate '.' being used in the place of U+3002 iff it is used as the full stop. Usually, formal documents don't use '.' by the way a= s you know.) I also attached a sample screen shot in JPEG showing the ATOK12 based Japanese input with numbers and would like to demonstrate how Asian input system works in the SASL WG meeting at Tuesday. And so once again my suggestion is that the mappings of all full stops shou= ld be done as similary as defined in the IDNA for Internet style domain names but outside and before the SASLprep if such mappings are needed for Interne= t domain style names. With regards, Ienup ] Date: Fri, 07 Nov 2003 15:16:25 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ]=20 ] It is absolutely a trade off. Avoidance of end user confusion because th= ey ] could not tell the difference between the full stops and the ability to ] specify them as different strings. ]=20 ] By choosing to fold the full stops we are saying that we believe that the= re ] will be more confusion by users who try to use one form of full stop when ] they should be using another than the confusion which will be caused for ] system administrators who desire to create accounts which only differ by ] the type of full stop used. ]=20 ] Jeffrey Altman ]=20 ]=20 ] Ienup Sung wrote: ]=20 ] >Actually that's exactly the problem that I was also talking about since ] >people will treat the Asian full stops and U+002E differently at Asian ] >countries and when people tried to register a new user account with let = say ] >3=E3=80=8214 (where it is three, Asian full-stop, and fourteen), the PLA= IN based user ] >account system could say, sorry, we already have 3.14 (that is three poi= nt ] >one four) which is totally different user account name and would deny ] >the new user account name which will be quite confusing for Asian people= . ] > ] >With regards, ] > ] >Ienup ] > ] > =20 ] > --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ) Content-type: IMAGE/jpeg; name=ATOK12-Japanese.jpg; x-unix-mode=0644 Content-transfer-encoding: BASE64 Content-disposition: attachment; filename=ATOK12-Japanese.jpg Content-description: ATOK12-Japanese.jpg Content-MD5: 35UO0f6/F0u2PYtWXN9K+w== /9j/4AAQSkZJRgABAQAAAQABAAD/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFla Y2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/ xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGh scEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4 +fr/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxO QERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhC Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj Y2NjY2P/wAARCABwAUYDABEAAREBAhEB/9oADAMAAAERAhEAPwBn8v8AP+f8 8QcYfy/z/n/PAAfy/wA/5/zwAbU3/IXi/wB5v/RbVK+Iin/GLNh/yFJP+uZ/ 9lprdm8f4kvka1M1CgCOaaOBA8rbVLKgOM8swUD8yKAJKACgCsuoWhklTzlU xAs7MCq4H3iGPBweDjoeDigCzQBC1wi3kdsQ2+SN5Ae2FKg/+hD9aAHTzR21 vJPM22OJS7tjOABkmgCSgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKAOH/wA/5/z/APWDmD/P+f8AP/1gA/z/AJ/z/wDW ANmb/kLxf7zf+i2qV8RFP+MWbD/kKSf9cz/7LTW7N4/xJfIqafYQzfabYQZj mgaJ7o2jQTYOB8zOP3jNySQAMryORVGw9Ee80+5vbttrTLHGPIjaRXVD12jJ ZGZn6dUI6c0CGNZRz6IUOnQCOO6jl2pa+WJFDKXbyj8wO3cuOSQOOoFAw1G3 idLI21qiWCrKDFJp7yKHLLg+UMEHh/mx3P8AeoApanY3g2MsVxLOljGnm7CX LLHOeoJ53iM8E/NtOc4NAF2+tp4r9bqGyyu5ikRDSB3BBGQDhN553fdBUM2W I2gHQ0hHMWNs8ckTR6dL9pXT5UuJNvlGab93keZ1JJB+fpySCcHDGNjsnnst VtY7ZDHPa4hjSya2jMo3ZO1+jcx/NxnAx904ALV7BBJp8I060WG2W53TxtYP tYbCMmLCl/mKdO4B/hoA0tHieHTY0csTliMx+XhSxKgLk7QAQADyBgHHSkIu 0AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAcP 0/z/AJ/z+gcodP8AP+f8/oAHT/P+f8/oAbM3/IXi/wB5v/RbVK+Imn/GLNh/ yFJP+uZ/9lprdm8f4kvkakiJLG0ciq6OCrKwyCD1BFM1CNEijWONVREAVVUY AA6ACgB1AEc00cCB5W2qWVAcZ5ZgoH5kUASUAFABQBSk1jTIpGjk1G0R0JVl adQQR1BGaAJ7a6t7uMyWs8U6A7S0bhgD6ZFAE1AENzdW9pGJLqeKBCdoaRwo J9MmgCCPWNMlkWOPUbR3chVVZ1JJPQAZoAu0AFAEM11BBJFHLIqNKcID37fh yQM+pA6kUATUAFABQAUAQRX1pPcPbw3UEk0ed8aSAsuDg5HUc0APjmjleVEb LQtscY6HaGx+TD86AJKACgCD7bb+T53mfu/N8nOD9/fsx/31xQBPQAUAVk1G zkuTbRXMUk4JDRxsGZcddwHT0ye+B1IoAljmjleVEbLQtscY6HaGx+TD86AJ KACgAoAKACgAoAKACgDh+n+f8/5/QOUOn+f8/wCf0ADp/n/P+f0ANmb/AJC8 X+83/otqlfETT/jFmw/5Ckn/AFzP/stNbs3j/El8ivctNaW+oXFlcTukFrL5 ksrlw0wGQVB4G3DZCgLkgY4IWjULkvaTXNpDNP5R+yfflZ2HmTMj4ZiWGVAH B46jB5oAsQRNJHf2xkunitp8IiTESMPKRtu8nd95ifvDsM44oApOr3NtYrPD FehrmSKOC4bARl83l2w24qq7e4zk5bggGR6fpaPe3qyaJpRRblVb5s+WPLjJ Cjy+eue3JP1oA1mM6+IIQ07GF7aUiIDCjDRcn1PJ59O3UkEFqZxrd6ks7SL5 MTomMKmWlGAPoBk9z6DAABl2n27bP5P9qeX9qnx5H2bZ/rX6b/m/OgY63edL PUN7XCSPqEMbmUoJNrCFTzHwPlJwRyOO9AFn90ltqMdxJdNDaTgRKk7iQ5jQ hQ24MxLOcAnqQPSgQ2eOewi0lXWW6lW7dtiybm5jlO0M5GdoOMkjIH4UAO1K 8nlghR9NuoVN1b5d2iIH75P7rk/pQBtUgM2KP7VqN9MQnnWzCG3Z13CP92GL Adckvg4IyFA7UwMie9mimVQ/mi8by5TPpM5ONjHAGRleCAoHAJJydxIM19Pi F3ZPDdt9qt+FC3Fq6HI5OQ/LDOMHGeOSxyaBEukO76equzOYpJId7HLMEdkB J7khQSfXNICPWTOsNu8U7RKLmEOqjl8yoMZ7DBOR345xkFgJq0bPgQzzi8ZS LZEkKqrD+NgOqjK53ZHAAGWwQDHi85bli7xNEwvlVPsry4BuUDBlVsvn2Ax3 zQMj0+OO01yJYYbcGcmTeNHljaPGxNqkn5QQSSegJOetAGxFE0eqm1Ml15cs Dl2lmJMxynzJg/JjcQcbeWGAccAiO0guWiuJ9OlcRzYSL7RO8mAu7Milt33s jHUYAbn7tAEEtzcxaTfWzaZam0sojDJGLx8lBGGwD5efusB1HP50DLN5ZajN JB86zJEHU4upLcyZ27WOwdRhgR05yMZwARUkvUlkSUC/FnHYw3CSRzYMIbfl nBb5+FHBD9Dwc8gyOKS7uPEGoi2uLhQ0axxSlUZBhpAcgJkbWD4z1Kct8woA sWlvFDdvDAksDC7C27bDkRJFGH64JQ7NueRkqeuDQBpa07xaJfyRsyOltIys pwQQpwQaQjO23T216NNF00W2MxrcvIjuwY+YoaT5lym0A9ATxg5NMBlyIJdA 1CWA6hbzWiy5WW5lDpIEzydxDDG0jkjn3NAzbtrZLWMpG0rAnP7yVpD+bEn8 KQiagAoAKACgDhz36f5/z/nsHKB79P8AP+f89gAPfp/n/P8AnsAbM3/IXi/3 m/8ARbVK+Imn/GLNh/yFJP8Armf/AGWmt2bx/iS+RZttKtLWMxxrK0Rj8vyp J3kTb6bWJHt0pmo5NNtUikj2O4kxuaSVnfjkYYkkYPIweDyOaAD+zbX7P5Ox 8bt+/wA1vM3YxnfndnHGc9OOnFADW0jTXVBLY28pQYDSxh26k8k5J5JJPckm gCCHw9pkctw7WFo4lkDqpt1+QbVGB+IJ/GncLl5bWBJInSNVMMZjj28BVOMg Dp/Cv5UgBoAJJZotq3EkYTewLDjJXIyOhY+n1oALS3S0to4ELMEGNzcsx7sT 3JOST3JNAFa305hFdLeyJO1zKJGMaGMKQqqMfMSCNgOc5z0pgTJp9skHkhGK +YshLOzMzKQQSxOTjaOp6ADpSAbf2s1ybZ7eZIpIJfMBeMuD8jLjAI/vevag CCay1G5EaXF7amNZY5CEtWUna4bGTIcdPSmBpUgK0toTcm5gmaKYx7DwGR8Z 27h14LE8EZzyaAKB0u/82KRby0QxzGcBbV8FirKePM4zuJ4xzz3OWBZtbK5h tGt2u0QcbHt4drKc5JO9n3E9yeeSepoAtwQx21vHBCu2OJQiLnOABgCkATQx zoElXcoZXAzjlWDA/mBQBBcabb3NwZ389ZCoQtFcSR5AJIB2kZ6n86AJIrG0 guHuIbWCOaTO+RIwGbJycnqeaAK8GnNDfpMsiC3hieOKFUOVDFSfmLHgbeAA AAcdqYE1tp9tayF4UYHG1dzswRf7qgnCjgcDA4HoKQDhbtBZJb2RSHy1VI96 lwoGBjGQTx70AV5tN36Y1jFLtjl3CZ3Xczh8lyMEAMSxOcYHpTAsXVnDd7TK HDJna8cjRsAeo3KQccDjpwPSkBHLplnNsDQ7VRQmxGKKyjorKCAy9eDkcn1N ABJazC6nubeZEklijjG+MsF2sxzgEZzv9R0oAktbVbfcxkeaZ8b5ZMbmA6Dg AADPQADknqSSAPnhjubeSCZd0cqlHXOMgjBFABPCs8TROXCt1KOyH81IIoAi XT7YWctrsZopgRJudmZ8jByxOTxxnPQD0oAs0AFABQAUAFAHEfXt/n/P+cBy h9e3+f8AP+cAB9e3+f8AP+cAGxN/yF4v95v/AEW1SviJp/xizYf8hST/AK5n /wBlprdm8f4kvkWV1W0aOWQNL5UUZkaUwOEKjqQ2MN6jBOe1M1Jpb23haVZJ MNEquwwScMSFx6klSABzn6igCrc6vDBZrciG4ZTMkW1oJFb5mAzgrnofTk8d TTAmfUrdIo5G8/8AeZ2oLeQyEDqdmNwHTnGOR6ikA2XVrGKRUe4X5o1kDAEq VOcHcBjsx69FJ6AmgCBdaT7ZLbtC25SVREbMjMDjDLxt3csvOCoLHABphY1K QFa21C2upCkLsTjcu5GUOv8AeUkYYcjkZHI9RQBWutYhSza4hb92ksStJLGy xlWcKWDHAYYJOQSOhpgT/wBpWv2fzt743bNnlN5m7GcbMbs45xjpz05pATwT R3ESyxNuRvbBBHBBB5BB4IPINAEF5JepPCLWFHjP+sLHkfOg45H8JkP1A+hA JLpLttv2SeCLGd3mwmTPpjDLj9aAC1S7Xd9rnglzjb5UJjx65yzZ/SgDJ069 1G4vNRjRYGZZwud7PHDhFBAbA3HPOwBcENkjIywL1vc3ckV1HsglubaUR5yY kfKq2f4ivDY79O2eACjo2oX9zZu0UKXJM8pErSlYgu9sKr4JftghQuOOoxQB pRXUl3aO1vH5U6sY2jn6xkH+IKTnj5gM8gjkZzSAqWN2Hu0jtdS/tONs+acx nyRjhsoAOTxg8nOR905YGtSAKAKV7NPFe6cscirFLMySLtyW/duw57cr/Ln1 ALtAGXcX87arYxWxX7KZnincj7zCNyFU+xU5PrgZ4YBgT6g1xFG8y3cVvbRx lpSYC7gDJJB3Y6dMqfx6UgM+Gz1wos0+pTjftBtkWEtHlgCTJsw2Bk4Cj0BP UsC4s076nYiVWhMlpK8kO/cFbdFxxwcZIz9aANGkBhxXOotf3lxMYoYLcxwv DGslyWONxK4C4yJFGdp6egpga1tcpdRl41lUA4/eRNGfyYA/jSAmoAKACgAo AKACgDiDx/np/n/PsHKB4/z0/wA/59gAPH+en+f8+wBsTf8AIXi/3m/9FtUr 4iaf8Ys2H/IUk/65n/2Wmt2bx/iS+QWllLB5zXMKR2nlMrW0cr3CsPZWUbQB kbVGDu6cCqNRtnZSNpLNJG09xOFIFzIUcKuNgLAEqwA3HHRyxGM0ASLYXTaa 0Mjr5gmSaNGlaQLsZWCmRhuOSp5I43YwQBQA2+sbq8a2uWjQTRK6NEl3JGMM VOfMVQT90cYxz7cgFS+8PzzRiOB4FRbVYFBLAZEUye5xmVe5OAfxLjuW77TL ue4W4iuv3vzKDuKCIEjaQBndjHKnhyeSAqgAjWpAYVjoBjt3trj/AFYtWtRI LiSRmVgASFb5Y/ujgA9ueOXcLlyaC+urfyp1t1KTQuro7HeFkVmJUj5eF4GT 1696AGS6fcC5kuYvKZxdi4jRmKhh5IiIJwcdz0PQevABb0+3e1tdkhUu0kkj beQC7liAe+N2M8Zx0FICzQBi3uqm0vzIttqF1GF8vyobWT5Gzy3ICsDwM54x xnccMAi19bnfG2n6vaZU4lezY4PtgNz35GOKLBYZpd3bWUl8q296kck4eP8A 0OYlh5aAknbnJYNknknnvQBDbXx3z28sN/HE8kjvOtpMHk3OCgUhcjCfKcgE YG08ZoGOsdTi0zTvKTTdQfE8u2KGycbUMjFTyAMYI49+lAEltqDQ29xKYpxe Ty+ayCzuDHwAoUHYD91RzjqScEcUCGrq63l5bzNYalaC3LEtLZuWkBUjYNoP GcMcnqq8HqAZZh1dvtdx50U/2b5fI2WNxv6fNuymOvTFAif+17b/AJ5Xv/gD N/8AEUAVL3UYpbqwdIL0rDOXc/YpuB5Trn7vqw/OgCzJqtu8bKq36EggMtjN lfcZQj86AMaRBE9ilveayY4pizE2BymUcFv9TySW5znO4nrzQM1ru/s7uznt pI78JNG0bFbKbIBGDj5KBFe08QSFo4bzTb9ZMfPNFaSGLOO2QG/8d6+o5osF gvNTjS8gvYra/nMUbxtEtlKGIYqcglQOCg4JHBPPGCAOt9WE9wLmaDULdFUo kBs5STkjLNhSM8cYPAzzzgAFaHU5LXS7YpbX5mMnnXMSWUm7LEuypldv3jjk /dzg5waBk/8AwkLSwSeVpmpQygqq+fZuRycFvlznaOcZGegosKxYtdZVoB9p t7tJQSp22U2GwSAw+U4yMHGTjOKAsXra5S6jLxrKoBx+8iaM/kwB/GkBNQAU AFABQBxPT/8AX0oOUOn/AOvpQAdP/wBfSgDXm/5C8X+83/otqlfETT/jE1tN HBqLvK21dmM4J549KLpM054wqS5n2ND+0bT/AJ7D/vlv8KfMivb0+4f2jaf8 9h/3y3+FHMg9vT7h/aNp/wA9h/3y3+FHMg9vT7h/aNp/z2H/AHy3+FHMg9vT 7h/aNp/z2H/fLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf8APYf98t/h RzIPb0+4f2jaf89h/wB8t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/z2 H/fLf4UcyD29PuH9o2n/AD2H/fLf4UcyD29PuH9o2n/PYf8AfLf4UcyD29Pu H9o2n/PYf98t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/wA9h/3y3+FH Mg9vT7h/aNp/z2H/AHy3+FHMg9vT7h/aNp/z2H/fLf4UcyD29PuH9o2n/PYf 98t/hRzIPb0+4f2jaf8APYf98t/hRzIPb0+4f2jaf89h/wB8t/hRzIPb0+4f 2jaf89h/3y3+FHMg9vT7h/aNp/z2H/fLf4UcyD29PuH9o2n/AD2H/fLf4Ucy D29PuH9o2n/PYf8AfLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf89h/3 y3+FHMg9vT7h/aNp/wA9h/3y3+FHMg9vT7h/aNp/z2H/AHy3+FHMg9vT7h/a Np/z2H/fLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf8APYf98t/hRzIP b0+4f2jaf89h/wB8t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/z2H/fL f4UcyD29PuH9o2n/AD2H/fLf4UcyD29PuH9o2n/PYf8AfLf4UcyD29Pucl+X 50zMPy/OgA/L86ANV48asixIpldmAaSRyASjHOM4/SpW4qb/AHti0LW/MhjE 9kXUBivzZAOcHH4H8jVnZcGtb9GRWnslLnaoO4bjgnA9eAT+FAXA2t+JBGZ7 IOwLBfmyQMZOPxH5igLi/YtR/wCelp+TUBcPsWo/89LT8moC4zybzZv+02Gz ds3ZbG7dtx9c8Y9eKAHLa37s6rPZMUO1gNx2nAOD6cEH8aAuL9i1H/npafk1 AXD7FqP/AD0tPyagLh9i1H/npafk1AXD7FqP/PS0/JqAuH2LUf8Anpafk1AX D7FqP/PS0/JqAuH2LUf+elp+TUBcPsWo/wDPS0/JqAuH2LUf+elp+TUBcPsW o/8APS0/JqAuH2LUf+elp+TUBcPsWo/89LT8moC4fYtR/wCelp+TUBcPsWo/ 89LT8moC4fYtR/56Wn5NQFw+xaj/AM9LT8moC4fYtR/56Wn5NQFw+xaj/wA9 LT8moC4fYtR/56Wn5NQFw+xaj/z0tPyagLh9i1H/AJ6Wn5NQFw+xaj/z0tPy agLh9i1H/npafk1AXD7FqP8Az0tPyagLh9i1H/npafk1AXD7FqP/AD0tPyag Lh9i1H/npafk1AXD7FqP/PS0/JqAuH2LUf8Anpafk1AXD7FqP/PS0/JqAuc/ /P6/Wkcgfz+v1oAP5/X60AbDukWtQySMqIjMzMxwABG2STUr4iaf8UzZ45hq sq2kE+6eKJIBPqE6NkmUhmA5xhWbaSCAOzMRVnabD37pFHC9ip8maKKVJptz DcyhJFODvGTwx2nKnuDgEctcWRGsMhsVUAzhEW0AG0SKFIAt2zxjn5uvVc4L GbSxWiLoqahYK4+wyM0K2ZfbITESdiqdvJPYdaQGjpotxfsNOh+zWyxfvYjE YdzkjawQgEcBwWwM8DJ2/KCMzxB5MX2eKddPuW3MZZZ0j37xsK5BkTkrt3Y6 4HABxQNDPCVxFPe74rXT4jLB5kn2dEV1PyDaAJGO31yF5A7mhgzrKQgoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KAOJz/nP1oOUM/5z9aADP+c/WgDUu7dLvUltpCwSbfGxXqAYmBxUr4iaf8U0 YrCeO8a+eWKa6MLRkeXsU8gqAfmKgfNnrktnsALOwZNp1xcHfJJEs0hR3YAs E8tt0aKOMgMSSTgnnpkbQCkdEzcJL/YOkDarLsEvynJByR5PUY4+poHc0rSx 8qW2m8mC28mKSPyIOUG9lOQcD+76d/zBFgW22/e6V/8AWRLG6kf3SSpB7feb Prx0xygMptGuZVQNO0Mkg33E8VzKCXJOQqggcZAVmzgKAQQKYE1jpD6fdp5M jyWq5CK9zLmIY4G3JVxzgcLgAdTzQBrUgCgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA4r/AD/P3oOUP8/z96AD /P8AP3oAs3epRpqBeJJWaNvldF4zjBx+tTZ3ujNxlzc0WH9vz+lz/wB8Cj3g /e9w/t+f0uf++BR7wfve4q69OWYkzgBDgbOS2R/TdRqUnUs9RP7fn9Ln/vgU e8T+97h/b8/pc/8AfAo94P3vcP7fn9Ln/vgUe8H73uH9vz+lz/3wKPeD973D +35/S5/74FHvB+97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP8A 3wKPeD973D+35/S5/wC+BR7wfve4f2/P6XP/AHwKPeD973D+35/S5/74FHvB +97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP/fAo94P3vcP7fn9 Ln/vgUe8H73uH9vz+lz/AN8Cj3g/e9w/t+f0uf8AvgUe8H73uH9vz+lz/wB8 Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP/fAo94P3vcP7fn9Ln/vgUe8H73uH 9vz+lz/3wKPeD973D+35/S5/74FHvB+97h/b8/pc/wDfAo94P3vcP7fn9Ln/ AL4FHvB+97h/b8/pc/8AfAo94P3vcP7fn9Ln/vgUe8H73uH9vz+lz/3wKPeD 973D+35/S5/74FHvB+97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6 XP8A3wKPeD973D+35/S5/wC+BR7wfve4f2/OOouP++BR7w/3vcrH/PNUWB/z zQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8A PNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/z zQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8A PNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNACMePx9f8A 69AC/n+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dA B+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/ nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB +f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dACMePx9f/r0 Af/Z --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)-- From owner-ietf-sasl Sat Nov 8 15:49:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8NnwkT003457 for ; Sat, 8 Nov 2003 15:49:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA8NnwBL003456 for ietf-sasl-bks; Sat, 8 Nov 2003 15:49:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (m15185e42.tmodns.net [66.94.24.21]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8NnfkT003434 for ; Sat, 8 Nov 2003 15:49:51 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id DD5161515A2; Sat, 8 Nov 2003 18:45:11 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> From: Sam Hartman Date: Sat, 08 Nov 2003 17:11:47 -0500 In-Reply-To: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> (Ienup Sung's message of "Fri, 07 Nov 2003 11:35:46 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Ienup" == Ienup Sung writes: Ienup> Actually that's exactly the problem that I was also talking Ienup> about since people will treat the Asian full stops and Ienup> U+002E differently at Asian countries and when people tried Ienup> to register a new user account with let say 3。14 Ienup> (where it is three, Asian full-stop, and fourteen), the Ienup> PLAIN based user account system could say, sorry, we Ienup> already have 3.14 (that is three point one four) which is Ienup> totally different user account name and would deny the new Ienup> user account name which will be quite confusing for Asian Ienup> people. OK, then why would people use the Asian full stop in domain names? What's different about the world of DNS and the world of user names? Yours in confusion, --Sam From owner-ietf-sasl Sat Nov 8 17:48:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA91mLkT007342 for ; Sat, 8 Nov 2003 17:48:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA91mLkP007341 for ietf-sasl-bks; Sat, 8 Nov 2003 17:48:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA91mKkT007336 for ; Sat, 8 Nov 2003 17:48:20 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA91mMPh020191; Sat, 8 Nov 2003 18:48:22 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA91mLru028547; Sat, 8 Nov 2003 17:48:21 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO200028ACLJP@mpkmail.eng.sun.com>; Sat, 08 Nov 2003 17:48:21 -0800 (PST) Date: Sat, 08 Nov 2003 17:48:21 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO200029ACLJP@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=ISO-8859-1 Content-MD5: RC9tYTcDM4zCLW+l5msq/w== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA91mLkT007337 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As U+002E is used as full stop as label separator (not as decimal point for number representations), the Asian full stops are used as full stop as label separator in the IDNA. The IDNA's full stop mappings on the Internet domain style names are possible and rather desireable for convenience since we know that the full stops in that case are used as label separators and thus safely map the Asian full stops to the U+002E as the full stop. With regards, Ienup ] Date: Sat, 08 Nov 2003 17:11:47 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 8BIT ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> Actually that's exactly the problem that I was also talking ] Ienup> about since people will treat the Asian full stops and ] Ienup> U+002E differently at Asian countries and when people tried ] Ienup> to register a new user account with let say 3。14 ] Ienup> (where it is three, Asian full-stop, and fourteen), the ] Ienup> PLAIN based user account system could say, sorry, we ] Ienup> already have 3.14 (that is three point one four) which is ] Ienup> totally different user account name and would deny the new ] Ienup> user account name which will be quite confusing for Asian ] Ienup> people. ] ] OK, then why would people use the Asian full stop in domain names? ] What's different about the world of DNS and the world of user names? ] ] Yours in confusion, ] ] --Sam ] ] From owner-ietf-sasl Sun Nov 9 10:33:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9IX0kT034093 for ; Sun, 9 Nov 2003 10:33:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9IX0H5034092 for ietf-sasl-bks; Sun, 9 Nov 2003 10:33:00 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9IWwkT034081 for ; Sun, 9 Nov 2003 10:32:59 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AIuMp-00077C-5e for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:32:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AIuMm-0002DF-JT for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:32:52 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIuMm-0004HT-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 19:32:52 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 9 Nov 2003 19:32:52 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: >Alexey Melnikov writes: >> (...) Only a successful reauthentication is able replace/remove the >> previously negotiated security layer. > > Just to make sure it has been mentioned: > > This also means that non-SASL authentication must keep any old SASL > layer. I expect that's intended, including for LDAPv4? Perhaps I should clarify a bit: The current text does not allow protocols - e.g. LDAP - to say that non-SASL authentication (in LDAP, that's "Simple Bind") should remove the layer. If we want protocols to be allowed to specify that, rfc2222bis must say instead something like the protocol profile may specify that authentication by other means than SASL may remove the SASL security layer or if we don't want SASL to 'know about' non-SASL auth at all, that ... the protocol may at any time decide by other means than SASL to remove the security layer BTW, I'm not saying that we should do this. Nor that we shouldn't. I simply want the issue to be deliberately decided rather than defaulted. -- Hallvard From owner-ietf-sasl Sun Nov 9 10:48:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9ImBkT034777 for ; Sun, 9 Nov 2003 10:48:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9ImB6e034776 for ietf-sasl-bks; Sun, 9 Nov 2003 10:48:11 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9ImAkT034771 for ; Sun, 9 Nov 2003 10:48:10 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AIubZ-0000Nf-9u for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:48:09 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AIubX-0007i3-NM for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:48:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIubX-0004Jp-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 19:48:07 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: protocol profile? Date: Sun, 9 Nov 2003 19:48:07 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What is the purpose of the protocol profile? If a protocol spec has something to say about its SASL entities that are not mentioned in section 5 (Protocol profile requirements), should it go in the profile or elsewhere? Could you say something about that in section 5? For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says: 3.3.5. Rules for using SASL security layers If a SASL security layer is negotiated, the client SHOULD discard information about the server fetched prior to the initiation of the SASL negotiation and not obtained through secure mechanisms. If the client is configured to support multiple SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both before and after the SASL security layer is negotiated. (...) Does that belong in the protocol profile? -- Hallvard From owner-ietf-sasl Sun Nov 9 11:32:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9JW4kT036332 for ; Sun, 9 Nov 2003 11:32:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9JW4sr036331 for ietf-sasl-bks; Sun, 9 Nov 2003 11:32:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9JW3kT036326 for ; Sun, 9 Nov 2003 11:32:03 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AIvI1-0003hW-UO for ietf-sasl@imc.org; Sun, 09 Nov 2003 20:32:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AIvHw-0002kj-So for ietf-sasl@imc.org; Sun, 09 Nov 2003 20:31:56 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIvHw-0004Pz-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 20:31:56 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: suggested text about multiple SASL mechanisms Date: Sun, 9 Nov 2003 20:31:56 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I suggest this text is added to rfc2222bis, probably in the Security Considerations. I stole it from draft-ietf-ldapbis-authmeth-08.txt and de-LDAPified it. If the client fetches a list of supported SASL mechanisms from the server and bases its choice of SASL mechanism on the result, it SHOULD fetch that list both before and after the SASL security layer is negotiated. This allows the client to detect active attacks that remove mechanisms from the server's list of supported mechanisms, and allows the client to ensure that it is using the best mechanism supported by both client and server. -- Hallvard From owner-ietf-sasl Sun Nov 9 13:21:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LLGkT039472 for ; Sun, 9 Nov 2003 13:21:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9LLGEN039471 for ietf-sasl-bks; Sun, 9 Nov 2003 13:21:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LLFkT039465 for ; Sun, 9 Nov 2003 13:21:15 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (dyn136-204.ietf58.ietf.org [130.129.136.204]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA9LLEB9018768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 9 Nov 2003 16:21:15 -0500 (EST) Message-ID: <3FAE91C4.8060507@columbia.edu> Date: Sun, 09 Nov 2003 14:13:08 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNY0013YHBQT5@mpkmail.eng.sun.com> In-Reply-To: <0HNY0013YHBQT5@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803040500090503080500" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050803040500090503080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ienup Sung wrote: >PS. By the way, on a bit different topic, reading the SALSprep and also the >PLAIN mechanism drafts, it appears there is no AllowUnassigned flag >setting or mentioning of it in the drafts. Has this issue been discussed >and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? >If not, it seems either explicitly defining that the unassigned Unicode >characters are not allowed in the drafts, or, allow setting of the >AllowUnassigned flag as either True or False at the PLAIN draft appears >necesary so that the versioning issue is clearly stated... If this question >has been asked and answered, sorry, please let me know and I'll scan more of >the archived emails. > > > Whether or not Unassigned Code Points are to be allowed or not is dependent upon how the string being prepared is to be used. As described in RFC 3454 section 7, if the use of the string is for storage in a database then Unassigned Code Points are to be excluded. However, if the string is to be used for the purposed of querying a database, then the string may contain Unassigned Code Points. I do not believe it is required for SASLprep to highlight this distinction. It should however be specified in the protocol documents which utilize string preparation methods constructed within the framework of RFC 3454. Jeffrey Altman --------------ms050803040500090503080500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwOTE5MTMwOFowIwYJKoZIhvcNAQkEMRYEFI9NOnix9ysq hUqqXrZin7LNtgEIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAuAHEn3TM1/ArmrmkyUsgSQ9HWjrN ALmDiwe9M5A5ZbGWFVqNoMyngv7e0r3JQErf/Cv4WHgafjlpeQopEJczvEZQ1OxgBPI9zKcY TJW55/wQgcG9+MhjIIc7yaoMXMmHBoyJJ3YMrD0V9jOH7QrH+YR2r63ai++Oo/OWtVdbnAVj P08sZG2BZOkuMtxN794Nxj6rZOpps4EVnnkaQvQ2sY3N3iG3pU+2U/z52WrjYGfe0p3x6goB ZMxcz4o/eHc/nT+PTWubZ9eum0Z8Y77/Zi+LRiS6CLMNZGJTcyWp5zacQ74SdKR02aAwSIKe crnYFSsKDPNcv31dOxzDFn11egAAAAAAAA== --------------ms050803040500090503080500-- From owner-ietf-sasl Sun Nov 9 13:33:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LXgkT039697 for ; Sun, 9 Nov 2003 13:33:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9LXghF039696 for ietf-sasl-bks; Sun, 9 Nov 2003 13:33:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LXekT039679 for ; Sun, 9 Nov 2003 13:33:41 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA9LXfWj010566; Sun, 9 Nov 2003 16:33:41 -0500 Date: Sun, 9 Nov 2003 16:33:41 -0500 (EST) From: Rob Siemborski To: Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: > If the client fetches a list of supported SASL mechanisms from the > server and bases its choice of SASL mechanism on the result, it > SHOULD fetch that list both before and after the SASL security layer > is negotiated. This allows the client to detect active attacks that > remove mechanisms from the server's list of supported mechanisms, and > allows the client to ensure that it is using the best mechanism > supported by both client and server. Isn't this attack defeated simply by requiring the clients to not pick a mechanism that does not meet their minimum requirements for authentication? There are also currently deployed servers that do not continue to advertise their sasl mechanisms after authentication, since in almost all current protocols it is not valid to issue a second sasl authentication command. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Sun Nov 9 15:42:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NgEkT042962 for ; Sun, 9 Nov 2003 15:42:14 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NgE5F042961 for ietf-sasl-bks; Sun, 9 Nov 2003 15:42:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NgDkT042956 for ; Sun, 9 Nov 2003 15:42:13 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E92B015159D; Sun, 9 Nov 2003 18:42:14 -0500 (EST) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? References: From: Sam Hartman Date: Sun, 09 Nov 2003 18:42:14 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Sun, 9 Nov 2003 19:48:07 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> What is the purpose of the protocol profile? If a Hallvard> protocol spec has something to say about its SASL Hallvard> entities that are not mentioned in section 5 (Protocol Hallvard> profile requirements), should it go in the profile or Hallvard> elsewhere? Could you say something about that in Hallvard> section 5? I believe section 5 is a set of minimum requirements for protocol profiles; you should be able to specify additional details in the profile document. From owner-ietf-sasl Sun Nov 9 15:46:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NkBkT043040 for ; Sun, 9 Nov 2003 15:46:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NkB8t043039 for ietf-sasl-bks; Sun, 9 Nov 2003 15:46:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NkAkT043034 for ; Sun, 9 Nov 2003 15:46:10 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A61E915159D; Sun, 9 Nov 2003 18:46:12 -0500 (EST) To: Tony Hansen Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 References: <3FAA7E9E.3080704@att.com> From: Sam Hartman Date: Sun, 09 Nov 2003 18:46:12 -0500 In-Reply-To: <3FAA7E9E.3080704@att.com> (Tony Hansen's message of "Thu, 06 Nov 2003 12:02:22 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Tony" == Tony Hansen writes: Tony> May I suggest that this section be rewritten so that it Tony> focusses on the two topics separately. For example, Tony> something like the following below might be considered. This section certainly has been a subject of much discussion about clarity here. From owner-ietf-sasl Sun Nov 9 15:44:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NiCkT043002 for ; Sun, 9 Nov 2003 15:44:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NiCKl043001 for ietf-sasl-bks; Sun, 9 Nov 2003 15:44:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NiBkT042996 for ; Sun, 9 Nov 2003 15:44:11 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id EDA7415159D; Sun, 9 Nov 2003 18:44:13 -0500 (EST) To: Rob Siemborski Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: From: Sam Hartman Date: Sun, 09 Nov 2003 18:44:13 -0500 In-Reply-To: (Rob Siemborski's message of "Sun, 9 Nov 2003 16:33:41 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: >> If the client fetches a list of supported SASL mechanisms from >> the server and bases its choice of SASL mechanism on the >> result, it SHOULD fetch that list both before and after the >> SASL security layer is negotiated. This allows the client to >> detect active attacks that remove mechanisms from the server's >> list of supported mechanisms, and allows the client to ensure >> that it is using the best mechanism supported by both client >> and server. Rob> Isn't this attack defeated simply by requiring the clients to Rob> not pick a mechanism that does not meet their minimum Rob> requirements for authentication? No, I wouldn't call that defeated. You get better protection by checking after the fact. Rob> There are also currently deployed servers that do not Rob> continue to advertise their sasl mechanisms after Rob> authentication, since in almost all current protocols it is Rob> not valid to issue a second sasl authentication command. That's why he said SHOULD not MUST;) From owner-ietf-sasl Sun Nov 9 17:36:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA1aekT046275 for ; Sun, 9 Nov 2003 17:36:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA1aelv046274 for ietf-sasl-bks; Sun, 9 Nov 2003 17:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA1adkT046269 for ; Sun, 9 Nov 2003 17:36:39 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id CF5D415159D; Sun, 9 Nov 2003 20:36:37 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HO200029ACLJP@mpkmail.eng.sun.com> From: Sam Hartman Date: Sun, 09 Nov 2003 20:36:37 -0500 In-Reply-To: <0HO200029ACLJP@mpkmail.eng.sun.com> (Ienup Sung's message of "Sat, 08 Nov 2003 17:48:21 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Ienup" == Ienup Sung writes: Ienup> As U+002E is used as full stop as label separator (not as Ienup> decimal point for number representations), the Asian full Ienup> stops are used as full stop as label separator in the IDNA. Ienup> The IDNA's full stop mappings on the Internet domain style Ienup> names are possible and rather desireable for convenience Ienup> since we know that the full stops in that case are used as Ienup> label separators and thus safely map the Asian full stops Ienup> to the U+002E as the full stop. Ienup> With regards, You believe there is not a similar convenience issue in usernames? From owner-ietf-sasl Sun Nov 9 22:26:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA6QikT058099 for ; Sun, 9 Nov 2003 22:26:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA6Qiwi058098 for ietf-sasl-bks; Sun, 9 Nov 2003 22:26:44 -0800 (PST) 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.10/8.12.8) with ESMTP id hAA6QhkT058093 for ; Sun, 9 Nov 2003 22:26:43 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AJ5Va-0006ZF-LL; Mon, 10 Nov 2003 07:26:42 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AJ5VY-0003y8-4g; Mon, 10 Nov 2003 07:26:40 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJ5VX-00069p-00; Mon, 10 Nov 2003 07:26:39 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sam Hartman Cc: Rob Siemborski , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Nov 2003 07:26:39 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Rob" == Rob Siemborski writes: > > Rob> There are also currently deployed servers that do not > Rob> continue to advertise their sasl mechanisms after > Rob> authentication, since in almost all current protocols it is > Rob> not valid to issue a second sasl authentication command. > > That's why he said SHOULD not MUST;) Well, it would have been if I had thought of it... I guess I should have put an 'if possible' in there somewhere. -- Hallvard From owner-ietf-sasl Sun Nov 9 23:10:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA7AUkT059886 for ; Sun, 9 Nov 2003 23:10:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA7AU8m059885 for ietf-sasl-bks; Sun, 9 Nov 2003 23:10:30 -0800 (PST) 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.10/8.12.8) with ESMTP id hAA7ATkT059880 for ; Sun, 9 Nov 2003 23:10:29 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AJ6Bx-0002tt-LJ; Mon, 10 Nov 2003 08:10:29 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AJ6Br-0001gQ-2m; Mon, 10 Nov 2003 08:10:23 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJ6Bq-0006HE-00; Mon, 10 Nov 2003 08:10:22 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Nov 2003 08:10:22 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I believe section 5 is a set of minimum requirements for protocol > profiles; you should be able to specify additional details in the > profile document. OK, but why would I - or why would I not? What belongs in the protocol profile? -- Hallvard From owner-ietf-sasl Mon Nov 10 08:51:42 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGpgkT081328 for ; Mon, 10 Nov 2003 08:51:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAGpgEV081327 for ietf-sasl-bks; Mon, 10 Nov 2003 08:51:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGpfkT081322 for ; Mon, 10 Nov 2003 08:51:41 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAGpe5u026011; Mon, 10 Nov 2003 09:51:41 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAAGpVDS018921; Mon, 10 Nov 2003 08:51:31 -0800 (PST) Received: from unknown (vpn-129-150-20-204.SFBay.Sun.COM [129.150.20.204]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO50089KAU3KX@mpkmail.eng.sun.com>; Mon, 10 Nov 2003 08:51:40 -0800 (PST) Date: Mon, 10 Nov 2003 07:54:51 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO50089LAU4KX@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: BYCz81EfVfXsql4UdlhwOg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In my opinion, yes,that's correct and especially for user names and passwords. With regards, Ienup ] Date: Sun, 09 Nov 2003 20:36:37 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on frigga.ctd.anl.gov ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> As U+002E is used as full stop as label separator (not as ] Ienup> decimal point for number representations), the Asian full ] Ienup> stops are used as full stop as label separator in the IDNA. ] ] Ienup> The IDNA's full stop mappings on the Internet domain style ] Ienup> names are possible and rather desireable for convenience ] Ienup> since we know that the full stops in that case are used as ] Ienup> label separators and thus safely map the Asian full stops ] Ienup> to the U+002E as the full stop. ] ] Ienup> With regards, ] ] You believe there is not a similar convenience issue in usernames? ] ] ] From owner-ietf-sasl Mon Nov 10 09:09:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH9XkT082275 for ; Mon, 10 Nov 2003 09:09:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAH9X45082274 for ietf-sasl-bks; Mon, 10 Nov 2003 09:09:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH9WkT082268 for ; Mon, 10 Nov 2003 09:09:32 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAH9V5u005289; Mon, 10 Nov 2003 10:09:31 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAAH9Vru017221; Mon, 10 Nov 2003 09:09:31 -0800 (PST) Received: from unknown (vpn-129-150-20-204.SFBay.Sun.COM [129.150.20.204]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO50080TBNUKX@mpkmail.eng.sun.com>; Mon, 10 Nov 2003 09:09:31 -0800 (PST) Date: Mon, 10 Nov 2003 08:12:42 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO50080UBNUKX@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: pV+zF7NBQ4144jebQniLiQ== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is an explicit flag value that need to be given to the SASLprep and any other Stringprep profile to be more specific. Otherwise, people will be confused and wondering what to do with it on the Unicode version issues and also whether and how to use query string vs. storage string (for simple user names and passwords). Especially, having some version related remarks or at least explicitly giving the flag and also mark the flag with a reference would greatly help people, e.g., "SASLprep(authcid, AllowUnassigned)" or "SASLprep(passwd, AllowUnassigned)" since the flag processing would/better need to be done at the Stringprep protocol processing. With regards, Ienup ] Date: Sun, 09 Nov 2003 14:13:08 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on frigga.ctd.anl.gov ] ] Ienup Sung wrote: ] ] >PS. By the way, on a bit different topic, reading the SALSprep and also the ] >PLAIN mechanism drafts, it appears there is no AllowUnassigned flag ] >setting or mentioning of it in the drafts. Has this issue been discussed ] >and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? ] >If not, it seems either explicitly defining that the unassigned Unicode ] >characters are not allowed in the drafts, or, allow setting of the ] >AllowUnassigned flag as either True or False at the PLAIN draft appears ] >necesary so that the versioning issue is clearly stated... If this question ] >has been asked and answered, sorry, please let me know and I'll scan more of ] >the archived emails. ] > ] > ] > ] Whether or not Unassigned Code Points are to be allowed or not is ] dependent upon ] how the string being prepared is to be used. As described in RFC 3454 ] section 7, ] if the use of the string is for storage in a database then Unassigned ] Code Points ] are to be excluded. However, if the string is to be used for the ] purposed of ] querying a database, then the string may contain Unassigned Code Points. ] ] I do not believe it is required for SASLprep to highlight this ] distinction. ] It should however be specified in the protocol documents which utilize ] string ] preparation methods constructed within the framework of RFC 3454. ] ] Jeffrey Altman ] ] From owner-ietf-sasl Tue Nov 11 03:05:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABB5PkT094235 for ; Tue, 11 Nov 2003 03:05:25 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABB5ON6094234 for ietf-sasl-bks; Tue, 11 Nov 2003 03:05:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hABB5HkT094226 for ; Tue, 11 Nov 2003 03:05:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 11:06:35 +0000 Message-ID: <3FB0C25E.6000501@isode.com> Date: Tue, 11 Nov 2003 11:05:02 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? References: In-Reply-To: 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: Hallvard B Furuseth wrote: >What is the purpose of the protocol profile? If a protocol spec has >something to say about its SASL entities that are not mentioned in >section 5 (Protocol profile requirements), should it go in the profile >or elsewhere? Could you say something about that in section 5? > >For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says: > > 3.3.5. Rules for using SASL security layers > > If a SASL security layer is negotiated, the client SHOULD discard > information about the server fetched prior to the initiation of the > SASL negotiation and not obtained through secure mechanisms. > > If the client is configured to support multiple SASL mechanisms, it > SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both > before and after the SASL security layer is negotiated. (...) > >Does that belong in the protocol profile? > IMHO, this kind of information does belong to a protocol profile document. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Tue Nov 11 11:23:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJN5kT016658 for ; Tue, 11 Nov 2003 11:23:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABJN5n0016657 for ietf-sasl-bks; Tue, 11 Nov 2003 11:23:05 -0800 (PST) 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.10/8.12.8) with ESMTP id hABJN3kT016651 for ; Tue, 11 Nov 2003 11:23:04 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 19:24:35 +0000 Message-ID: <3FB13714.7020602@isode.com> Date: Tue, 11 Nov 2003 19:23:00 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Alexey Melnikov writes: >>> >>>>Whether Simple bind removes or keep a previous security layer has >>>>nothing to do with SASL, this is very LDAP specific. >>>> >>>> >>>If SASL allowed LDAP to do so, it would be LDAP specific. >>> >>> >>SASL can't (and must not) document something it is not aware of. SASL >>doesn't have no be aware about Simple bind. >> >> > >Your text does document that anything else than SASL authentication - >and therefore also Simple Bind - may not remove the SASL security layer. > I am not sure that I wrote this anywhere in the document. Anyway, even if I did, that wasn't the intent. >Even though it's not aware of Simple Bind. All it is aware of is that >whatever Simple Bind is, it's not SASL. > > >>Simple bind is NOT SASL PLAIN, >> >> > >I know. That's why I brought it up. > > > >>>It doesn't, so it isn't. >>> >>> >>Why? >> >> > >Maybe I should start over. > >I did not say that SASL should say whether or not LDAP Simple Bind >should remove the layer. I said that the current text does not allow >_LDAP_ to say that Simple Bind should remove the layer. If we want LDAP >- or other protocols - to be _allowed_ to specify that something like >non-SASL Simple Bind should remove the layer, rfc2222bis must say >instead something like > > the protocol profile may specify that authentication by other means > than SASL may remove the SASL security layer > >or if you don't want SASL to 'know about' non-SASL auth, that > > ... the protocol may at any time decide by other means than SASL to > remove the security layer > >BTW, I'm not saying that we should do this. Nor that we shouldn't. >I simply wanted the issue to be deliberately decided rather than >defaulted. That's all. > > IMHO, something that is not explicitly prohibited is allowed. If the WG feels that this issue should be addressed, I will add some clarifying text. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Tue Nov 11 12:07:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABK73kT018762 for ; Tue, 11 Nov 2003 12:07:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABK73eV018761 for ietf-sasl-bks; Tue, 11 Nov 2003 12:07:03 -0800 (PST) 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.10/8.12.8) with ESMTP id hABK71kT018747 for ; Tue, 11 Nov 2003 12:07:02 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AJemu-000556-6a; Tue, 11 Nov 2003 21:06:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AJems-0002Qx-MU; Tue, 11 Nov 2003 21:06:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJems-0003sl-00; Tue, 11 Nov 2003 21:06:54 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FB13714.7020602@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 11 Nov 2003 21:06:54 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >> Your text does document that anything else than SASL authentication - >> and therefore also Simple Bind - may not remove the SASL security layer. > > I am not sure that I wrote this anywhere in the document. > Anyway, even if I did, that wasn't the intent. You are right, it's not in the document. It's in two explanatory messages from you in this thread: Date: Wed, 15 Oct 2003 12:52:04 +0100 Message-ID: <3F8D34E4.4020607@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html "No, the layer can only be cancelled/replaced after a subsequent authentication completes successfully." and Date: Sat, 01 Nov 2003 14:22:06 +0000 Message-ID: <3FA3C18E.8010101@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html "Only a successful reauthentication is able replace/remove the previously negotiated security layer." > If the WG feels that this issue should be addressed, I will add some > clarifying text. Well, I at least think it should be clarified. -- Hallvard From owner-ietf-sasl Tue Nov 11 12:23:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKNrkT019588 for ; Tue, 11 Nov 2003 12:23:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKNrAY019587 for ietf-sasl-bks; Tue, 11 Nov 2003 12:23:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (Ketorin.ietf58.ietf.org [130.129.134.235] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKNqkT019582 for ; Tue, 11 Nov 2003 12:23:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id CBA0415159D; Tue, 11 Nov 2003 15:23:52 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , SASL WG Subject: Re: Replacing a SASL security layer References: From: Sam Hartman Date: Tue, 11 Nov 2003 15:23:52 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Thu, 6 Nov 2003 00:46:30 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd like to second the lack of understanding here. I have asked several people to explain this attack to me and so far have failed to understand it. Hopefully we'll be able to clarify during the meeting today. From owner-ietf-sasl Tue Nov 11 12:39:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKdJkT020214 for ; Tue, 11 Nov 2003 12:39:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKdJM7020213 for ietf-sasl-bks; Tue, 11 Nov 2003 12:39:19 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKdHkT020203 for ; Tue, 11 Nov 2003 12:39:18 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 20:40:51 +0000 Message-ID: <3FB148F3.60307@isode.com> Date: Tue, 11 Nov 2003 20:39:15 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Your text does document that anything else than SASL authentication - >>>and therefore also Simple Bind - may not remove the SASL security layer. >>> >>> >>I am not sure that I wrote this anywhere in the document. >>Anyway, even if I did, that wasn't the intent. >> >> > >You are right, it's not in the document. It's in two explanatory >messages from you in this thread: > > Date: Wed, 15 Oct 2003 12:52:04 +0100 > Message-ID: <3F8D34E4.4020607@isode.com> > URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html > > "No, the layer can only be cancelled/replaced after a subsequent > authentication completes successfully." > >and > > Date: Sat, 01 Nov 2003 14:22:06 +0000 > Message-ID: <3FA3C18E.8010101@isode.com> > URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html > > "Only a successful reauthentication is able replace/remove the > previously negotiated security layer." > I was thinking specifically about SASL [re]authentication when writing this. My point was that a failed reauthentication didn't remove a previously negotiated security layer. This should apply to non-SASL reauthentications as well. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Tue Nov 11 12:35:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKZ2kT020066 for ; Tue, 11 Nov 2003 12:35:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKZ2XS020065 for ietf-sasl-bks; Tue, 11 Nov 2003 12:35:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKZ0kT020060 for ; Tue, 11 Nov 2003 12:35:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 20:36:37 +0000 Message-ID: <3FB147F5.3070902@isode.com> Date: Tue, 11 Nov 2003 20:35:01 +0000 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: [Fwd: Keeping/dropping existing SASL security layer] 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: Hopefully this clarifies things. -------- Original Message -------- Subject: Keeping/dropping existing SASL security layer Date: Tue, 11 Nov 2003 11:52:48 +0000 From: Alexey Melnikov To: Rob Siemborski The order of events is as follows (I will reference "Encryption endpoint box" as CC server): 1) The client connects to CC in order to request a resource FOO. 2) CC looks up its database to figure which server is managing FOO. It turns out to be server AA. 3). The client authenticates to AA (traffic is passing through CC). The client and AA negotiate a security layer. Upon successful negotiation both ends have pointers to two function (encode/decode) and associated keys. After that there might be 2 variations: a). AA does encoding/decoding itself or b). AA passes encode/decode functions and associated state to CC. (CC is trusted) 4). The client exchanges some information with AA (regarding resource FOO), the exchange is recorded by BB (but at this stage BB can't decode it) Than in case a): 5). The client requests access to resource BAR. Server AA decodes request and notifies CC about request to BAR. 6). CC looks up its database and determines that resource BAR is managed by BB. 7). The client reauthenticates to BB (encrypted traffic is going to AA through CC, than cleartext traffic is going from AA to BB through CC), it negotiates no security layer. When the reauthentication is complete, the old layer is used. 8). The client requests access to resource BAR on the server BB (traffic flow is the same as in 7). 9). Evil server BB instead of responding to request BAR returns specially crafted response in order to verify some guesses about previously recorded data exchange between the client and AA. The response is traveling in clear from BB to AA (through CC), server AA encrypts the response and sends it to the client (through CC). The evil BB records the encrypted version of its response and by analyzing it, BB can try to break the previously recorded exchange between the client and AA. or in case b): 5). The client requests access to resource BAR. Server CC decodes request. 6). CC looks up its database and determines that resource BAR is managed by BB. 7). The client reauthenticates to BB (encrypted traffic is going to CC, than cleartext traffic is going from CC to BB), it negotiates no security layer. When the reauthentication is complete, the old layer is used. 8). The client requests access to resource BAR on the server BB (traffic flow is the same as in 7). 9). Evil server BB instead of responding to request BAR returns specially crafted response in order to verify some guesses about previously recorded data exchange between the client and AA. The response is traveling in clear from BB to CC, server CC encrypts the response and sends it to the client. The evil BB records the encrypted version of its response and by analyzing it, BB can try to break the previously recorded exchange between the client and AA. (I think both cases are equivalent). I am not a security export, but I think this attack allows for "CBC mode attack". TLS is being revised (TLS 1.1) to deal with this issue. Alexey -- Alexey Melnikov __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Tue Nov 11 13:24:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABLOwkT022035 for ; Tue, 11 Nov 2003 13:24:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABLOwrC022033 for ietf-sasl-bks; Tue, 11 Nov 2003 13:24:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hABLOukT022020 for ; Tue, 11 Nov 2003 13:24:57 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AJg0I-0003yW-GR; Tue, 11 Nov 2003 22:24:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AJg0E-0001mt-G1; Tue, 11 Nov 2003 22:24:46 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJg0D-00043k-00; Tue, 11 Nov 2003 22:24:45 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FB148F3.60307@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> <3FB148F3.60307@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 11 Nov 2003 22:24:45 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >> "Only a successful reauthentication is able replace/remove the >> previously negotiated security layer." > > I was thinking specifically about SASL [re]authentication when writing > this. My point was that a failed reauthentication didn't remove a > previously negotiated security layer. Oh. So... server and client may at any time agree to remove the security layer, _except_ after failed reauthentication? > This should apply to non-SASL reauthentications as well. Except that in the message you quoted a few messages ago, you didn't want SASL to know about non-SASL reauthentications, so it shouldn't say anything about them. -- Hallvard From owner-ietf-sasl Wed Nov 12 07:17:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFHPkT029460 for ; Wed, 12 Nov 2003 07:17:25 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACFHPft029459 for ietf-sasl-bks; Wed, 12 Nov 2003 07:17:25 -0800 (PST) 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.10/8.12.8) with ESMTP id hACFHOkT029453 for ; Wed, 12 Nov 2003 07:17:24 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AJwkD-0002G8-AQ; Wed, 12 Nov 2003 16:17:21 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AJwk8-000846-BG; Wed, 12 Nov 2003 16:17:16 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJwk7-0006l9-00; Wed, 12 Nov 2003 16:17:15 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Siemborski Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Nov 2003 16:17:15 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > I'd be much happier either not adding this, or adding it as a "clients MAY > want to do this to detect MITM attacks" Fine by me. I don't feel strongly about it, I just saw it in LDAP and thought it might be a good idea. -- Hallvard From owner-ietf-sasl Wed Nov 12 07:36:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFafkT030212 for ; Wed, 12 Nov 2003 07:36:41 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACFafkR030211 for ietf-sasl-bks; Wed, 12 Nov 2003 07:36:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFadkT030204 for ; Wed, 12 Nov 2003 07:36:39 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hACF2DWj011542; Wed, 12 Nov 2003 10:02:13 -0500 Date: Wed, 12 Nov 2003 10:02:13 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 9 Nov 2003, Sam Hartman wrote: > Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: > > >> If the client fetches a list of supported SASL mechanisms from > >> the server and bases its choice of SASL mechanism on the > >> result, it SHOULD fetch that list both before and after the > >> SASL security layer is negotiated. This allows the client to > >> detect active attacks that remove mechanisms from the server's > >> list of supported mechanisms, and allows the client to ensure > >> that it is using the best mechanism supported by both client > >> and server. > > Rob> Isn't this attack defeated simply by requiring the clients to > Rob> not pick a mechanism that does not meet their minimum > Rob> requirements for authentication? > > No, I wouldn't call that defeated. You get better protection by > checking after the fact. I know we briefly discussed this in the meeting yesterday and we left it as "probably ok, with some modifications to the text"... I think for me to be happy with the addition of the text, it would need to both have the "if possible" fix, and a clarification that if a server advertises NO mechanisms after authentication, or the protocol does not support fetching capabilities after authentication -- as is the case with MUPDATE (though granted, it isn't standards track), then it MUST NOT act as if a MITM attack was detected. But I'm still unclear why this is necessary when: a) it most likely adds an extra round trip to the authentication process b) it may not even work with all protocols/implementations -- so that round trip will be wasted What are we trying to prevent here, exactly? The scenario where it applies seems to be something along the lines of: The server advertises GSSAPI and DIGEST-MD5. The client, for whatever reason, decides only GSSAPI (with privacy layer) is secure enough for it. The attacker edits the advertised capabilites and removes GSSAPI, the client sees that the server only supports DIGEST-MD5. I argue that the client should fail the authentication here and not even try to authenticate -- the MITM attack has been defeated. If instead it authenticates, then that implies that it is okay with using DIGEST-MD5. Even if it later discovers that GSSAPI was available, it should be ok with using DIGEST for the session -- what is it going to tell the user "uh, I sent your credentials with a mechanism you didn't want to use, and guess what -- there's an attack in progress!". Sure, the protection may be "better" (as in, you can detect that an attack is in progress), but the costs are high (additional round trip, it might not work anyway) for what seems to me to be a very small gain. I'd be much happier either not adding this, or adding it as a "clients MAY want to do this to detect MITM attacks" -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 13 12:45:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKjNkT077303 for ; Thu, 13 Nov 2003 12:45:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKjNRs077302 for ietf-sasl-bks; Thu, 13 Nov 2003 12:45:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn131-176.ietf58.ietf.org [130.129.131.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKjLkT077297 for ; Thu, 13 Nov 2003 12:45:22 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A183215159D; Thu, 13 Nov 2003 15:45:03 -0500 (EST) To: Russ Housley Cc: smb@research.att.com, kurt@openldap.org, hartmans@mit.edu, ietf-sasl@imc.org Subject: Summary for SASL References: <5.2.0.9.2.20031110115446.043e7508@mail.binhost.com> From: Sam Hartman In-Reply-To: <5.2.0.9.2.20031110115446.043e7508@mail.binhost.com> (Russ Housley's message of "Mon, 10 Nov 2003 11:54:54 -0500") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) Date: Thu, 13 Nov 2003 15:45:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SASL working group met for one hour Tuesday. As part of successful SASL authentication, you can set up a channel security layer. If you later have another successful authentication, the security layer remains in place even if the new SASL mechanism does not negotiate a security layer. The There was some concern that this might create problems for distributed server implementations where two components trust each other, but do not trust a third component. The rough consensus of the working group was not to make this change. we had significant discussion of issues surrounding our stringprep profile saslprep. First, we discussed whether we wanted to map all full stop characters to the ASCII full stop character. We also discussed whether we would allow private use characters. The working group failed to reach consensus on these issues at the session. We had a presentation on implementation problems with SMTP authentication. We expect to be making various changes in our specifications to make them more clear. The incorrect behavior is already a violation of the existing specs but there is a desire to add better examples. Alexey Melnikov has agreed to edit the GSSAPI mechanism draft because the previous editor has not had time to edit the document. We expect an initial submission shortly after this meeting. The chairs will get new milestones to the ADs shortly after the meeting. We hope to be done with base, saslprep, plain and anonymous by the end of the year. From owner-ietf-sasl Thu Nov 13 12:54:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKs9kT077769 for ; Thu, 13 Nov 2003 12:54:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKs9DD077768 for ietf-sasl-bks; Thu, 13 Nov 2003 12:54:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn131-176.ietf58.ietf.org [130.129.131.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKs8kT077763 for ; Thu, 13 Nov 2003 12:54:09 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1E50C15159D; Thu, 13 Nov 2003 15:53:49 -0500 (EST) To: ietf-sasl@imc.org Subject: ID Nit: Internet drafts cannot expire in six monthse Message-Id: <20031113205349.1E50C15159D@konishi-polis.mit.edu> Date: Thu, 13 Nov 2003 15:53:49 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. Just a reminder that Internet draft formatting requirements do not allow you to say that the draft you are submitting expires in six months; instead you are requested to include an explicit date. I believe that this is a useful requirement even though it is not enforced. IT makes it more clear whether a draft is expired if it escapes from the ID repository and is used in another context. If it is easy for you to have a real expiration date, please do so. From owner-ietf-sasl Thu Nov 13 12:56:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKuRkT077926 for ; Thu, 13 Nov 2003 12:56:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKuRZa077925 for ietf-sasl-bks; Thu, 13 Nov 2003 12:56:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKuMkT077907 for ; Thu, 13 Nov 2003 12:56:24 -0800 (PST) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id hADKuJcm015615 for ; Thu, 13 Nov 2003 13:56:24 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HOB0045A65UCO@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Thu, 13 Nov 2003 13:56:19 -0700 (MST) Received: from dyn132-212.ietf58.ietf.org ([130.129.132.212]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HOB00F4365SJG@mail.sun.net> for ietf-sasl@imc.org; Thu, 13 Nov 2003 13:56:18 -0700 (MST) Date: Thu, 13 Nov 2003 14:56:16 -0600 From: Chris Newman Subject: CRAM-MD5 missing security consideration To: lyndon@orthanc.ab.ca Cc: ietf-sasl@imc.org Message-id: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b9 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: CRAM-MD5 does not authenticate the server and does not include a client-supplied nonce. As a result, it is possible to construct a server with a fixed challenge string that has pre-computed the hashes for all possible passwords up to a certain length (or from a dictionary). Such a server could then immediately determine the user's password if it is sufficiently short. - Chris From owner-ietf-sasl Fri Nov 14 16:00:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF00BkT046359 for ; Fri, 14 Nov 2003 16:00:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF00Buk046358 for ietf-sasl-bks; Fri, 14 Nov 2003 16:00:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF007kT046349 for ; Fri, 14 Nov 2003 16:00:10 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hAF006NN011142; Fri, 14 Nov 2003 17:00:07 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 14 Nov 2003 17:00:01 -0700 From: Lyndon Nerenberg To: Chris Newman cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 missing security consideration Message-ID: <2147483647.1068829201@[192.168.42.6]> In-Reply-To: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> References: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Thanks Chris, I've added the text. I will push a new (and final I hope) draft next week. --lyndon From owner-ietf-sasl Fri Nov 14 20:25:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4PHkT060609 for ; Fri, 14 Nov 2003 20:25:17 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4PH9C060608 for ietf-sasl-bks; Fri, 14 Nov 2003 20:25:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (mcb185e42.tmodns.net [66.94.24.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4OxkT060567 for ; Fri, 14 Nov 2003 20:25:08 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2AB8415159D; Fri, 14 Nov 2003 23:24:50 -0500 (EST) To: ietf-sasl@imc.org Subject: consensus call on full stop and private use for saslprep From: Sam Hartman Date: Fri, 14 Nov 2003 22:00:57 -0500 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It was fairly obvious at Tuesday's meeting that we did not have a rough consensus to change the saslprep document either to map full stops to ASCII full stop or to allow private use characters. The saslprep document has already passed working group last call. AS such, there is a relatively high bar to propose changes to the document from within the working group. Since there is no consensus to change the document, the document will remain as is for now. I realize several people are still actively thinking about these issues and people are still looking at what actual input methods do in various situations. If this ongoing discussion reaches a consensus before the documents are sent to the IESG, then we can act on that consensus. Thanks, --Sam From owner-ietf-sasl Fri Nov 14 20:25:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4PLkT060627 for ; Fri, 14 Nov 2003 20:25:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4PL8s060626 for ietf-sasl-bks; Fri, 14 Nov 2003 20:25:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (mcb185e42.tmodns.net [66.94.24.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4P1kT060568 for ; Fri, 14 Nov 2003 20:25:08 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6231015159F; Fri, 14 Nov 2003 23:24:50 -0500 (EST) To: Rob Siemborski Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: From: Sam Hartman Date: Fri, 14 Nov 2003 22:16:15 -0500 In-Reply-To: (Rob Siemborski's message of "Wed, 12 Nov 2003 10:02:13 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Rob" == Rob Siemborski writes: >> No, I wouldn't call that defeated. You get better protection >> by checking after the fact. Rob> I know we briefly discussed this in the meeting yesterday and Rob> we left it as "probably ok, with some modifications to the Rob> text"... Rob> I think for me to be happy with the addition of the text, it Rob> would need to both have the "if possible" fix, and a Rob> clarification that if a server advertises NO mechanisms after Rob> authentication, or the protocol does not support fetching Rob> capabilities after authentication -- as is the case with Rob> MUPDATE (though granted, it isn't standards track), then it Rob> MUST NOT act as if a MITM attack was detected. One thing we need to keep in mind is that over time, we get a better idea of what best practices for using SASL are. Some of our older protocols may not support these best practices. I'd rather encourage new protocols to implement the best practices. So, rather than saying that if the server returns no mechanisms the client should not treat it as a MITM attack, I'd like to say something like the following. New protocol profiles SHOULd require servers to make the list of SASL mechanisms available for the initial authentication available to the client after security layers are established. Some older protocols do not require this; for these protocols clients MUST NOT treat an empty list of SASL mechanisms after authentication as a MITM attack. Rob> But I'm still unclear why this is necessary when: Rob> a) it most likely adds an extra round trip to the Rob> authentication process b) it may not even work with all Rob> protocols/implementations -- so that round trip will be Rob> wasted Rob> What are we trying to prevent here, exactly? The scenario Rob> where it applies seems to be something along the lines of: This is valuable because people tend to have fairly lax security configurations on their clients and servers in the interest of interoperability. If there are things we can do to make an attacker's life harder--like protecting negotiations--then we should do so unless doing so has sufficiently negative consequences. From owner-ietf-sasl Fri Nov 14 20:31:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4VYkT061144 for ; Fri, 14 Nov 2003 20:31:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4VYrM061142 for ietf-sasl-bks; Fri, 14 Nov 2003 20:31:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4VXkT061136 for ; Fri, 14 Nov 2003 20:31:33 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hAF4VY5G023232; Fri, 14 Nov 2003 23:31:34 -0500 Date: Fri, 14 Nov 2003 23:31:35 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 14 Nov 2003, Sam Hartman wrote: > New protocol profiles SHOULd require servers to make the list of SASL > mechanisms available for the initial authentication available to the > client after security layers are established. Some older protocols do > not require this; for these protocols clients MUST NOT treat an empty > list of SASL mechanisms after authentication as a MITM attack. This sort of warning seems better to me. > This is valuable because people tend to have fairly lax security > configurations on their clients and servers in the interest of > interoperability. If there are things we can do to make an attacker's > life harder--like protecting negotiations--then we should do so unless > doing so has sufficiently negative consequences. I'm not really convinced there are truly strong benefits here, but since it will mostly be a recommendation for new protocols (which can be designed to negate any negative costs such as the extra round trip), I won't oppose it either (given text along the lines of what you suggest above). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Nov 17 15:12:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHNCCkT054604 for ; Mon, 17 Nov 2003 15:12:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHNCC28054603 for ietf-sasl-bks; Mon, 17 Nov 2003 15:12:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHNC9kU054596; Mon, 17 Nov 2003 15:12:09 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 17 Nov 2003 15:13:32 -0800 To: Sam Hartman , ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Re: consensus call on full stop and private use for saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:00 PM -0500 11/14/03, Sam Hartman wrote: >It was fairly obvious at Tuesday's meeting that we did not have a >rough consensus to change the saslprep document either to map full >stops to ASCII full stop or to allow private use characters. > >The saslprep document has already passed working group last call. AS >such, there is a relatively high bar to propose changes to the >document from within the working group. > >Since there is no consensus to change the document, the document will >remain as is for now. > >I realize several people are still actively thinking about these >issues and people are still looking at what actual input methods do in >various situations. If this ongoing discussion reaches a consensus >before the documents are sent to the IESG, then we can act on that >consensus. Echoing my comments in Minneapolis, I'm fine with leaving the document as it stands now. - The ideographic full stop situation is somewhat of a no-win situation. If we map them to periods, some Asian users will be surprised when they try to type the right thing. If we don't map them, other users will be surprised. We mapped them to periods in IDNA because domain names consistently use periods as separators, but that is not the case in SASL or Kerberos names. - Allowing private use characters in names requires specifying many things about them that is way, way out of scope for IETF activities (such as their normalization, their right-to-left properties, and so on). Organizations that use private-use characters often later regret that they did so, particularly when they try to communicate with other organizations who use the same characters for something else. The saslprep document works fine as it is. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Sat Nov 1 05:34:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DYkkT010491 for ; Sat, 1 Nov 2003 05:34:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1DYkXi010490 for ietf-sasl-bks; Sat, 1 Nov 2003 05:34:46 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1DYjkT010484 for ; Sat, 1 Nov 2003 05:34:45 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 13:35:23 +0000 Message-ID: <3FA3B671.10104@isode.com> Date: Sat, 01 Nov 2003 13:34:41 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.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: Sam Hartman wrote: >There has been a lot of discussion on the list since the last IETF and >I'm curious which issues actually need meeting time. I'd appreciate >it if people could suggest issues that still seem to be open. > >Thing I think may be open or need discussion are: > >* Initial server challenges especially as they interact with SMTP > I think there is nothing to discuss here. There are bugs in existing implementation and this need to be clarified with additional examples. >* Security layer replacement in the base SASL spec >* Authorization ID text (data vs blob, confusion about restriction, etc) >* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want >to develop guidance for protocol designers on this issue? > >I think most of the other changes that have been brought forward have >been resolved; please correct me if I'm wrong. I think Greg's >comments on implementing SASL have not suggested any specific changes >to documents that need discussion. > > >There's also been a lot of IDN related discussion in the Kerberos >working group. So far, I don't think any of that discussion affects >saslprep. If any of those issues do end up affecting saslprep, we may >at least want to be aware of them. I'll review those discussion >within the next week. > > > Cheers, Alexey Melnikov __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 05:39:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DdwkT010701 for ; Sat, 1 Nov 2003 05:39:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1DdwF2010698 for ietf-sasl-bks; Sat, 1 Nov 2003 05:39:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1DdvkT010693 for ; Sat, 1 Nov 2003 05:39:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 13:40:39 +0000 Message-ID: <3FA3B7AD.4010309@isode.com> Date: Sat, 01 Nov 2003 13:39:57 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Alexey Melnikov writes: >>> >>> >>>>Hallvard B Furuseth wrote: >>>> >>>> >>>>>>4.1. Authentication protocol exchange >>>>>> >>>>>> >>>Anyway, I think I found the answer in section 6.1. The initial auth >>>command from the client is not part of the exchange, but the optional >>>"response" in the auth command is. >>> >>> >>Sorry, this makes little sense to me. >>Semantically the initial response *is* part of an authentication >>exchange. >> >> > >That's what I wrote. > Ok, but I think arguing whether the initial auth command is part of an exchange or not is not worth the time. >>>>>>4.2. Authorization identities and proxy authentication >>>>>> >>>>>> (...) >>>>>> The character encoding scheme used for transmitting an authorization >>>>>> identity over protocol is specified in each authentication mechanism >>>>>> (with the authentication mechanism's blob being further >>>>>> >>>>>> >>>>> ^^^^ >>>>> >>>>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>>>like the dictionary says:-) >>>>> >>>>> >>>>> >>>>I've changed this to "data". >>>> >>>> >>>I still don't know _which_ data you are talking about. >>> >>> >>> >>Data is defined (and specific to) by each SASL mechanism. >> >> > >Is the text in the ()'s just saying that the SASL mechanism restricts >the data sent between client and server to more than just being random >strings in the character encoding scheme? > No, it talks about encoding data. The data itself is arbitrary binary data as far as the protocol is concerned. > Well, of course. Why mention >that at all? If not, I still don't understand what this () is saying. > > > >>>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>>>top. >>>>> >>>>> >>>>> >>>>I've added a sentence about this in the introduction section. >>>> >>>> >>>I'm pretty sure you will still need to insert the words "Obsoletes: rfc >>>2222" in the header sometime, though I don't remember where this is >>>stated. >>> >>> >>> >>I think this is going to be added by a RFC editor. >> >> >I couldn't find anything saying so. I did find rfc2223 (Instructions >to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks >you to insert. rfc2223 does say that the RFC Editor may make some >changes, but preferably as few as possible, and it doesn't mention >that one. > Ok, I will make sure that Obsoletes: will be inserted. Alexey From owner-ietf-sasl Sat Nov 1 06:06:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1E6dkT012090 for ; Sat, 1 Nov 2003 06:06:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1E6dIE012089 for ietf-sasl-bks; Sat, 1 Nov 2003 06:06:39 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1E6ckT012077 for ; Sat, 1 Nov 2003 06:06:38 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:07:19 +0000 Message-ID: <3FA3BDED.6010804@isode.com> Date: Sat, 01 Nov 2003 14:06:37 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Consensus call: changing examples from ACAP to SMTP References: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> In-Reply-To: <20031031195205.60C6F1515E8@konishi-polis.mit.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: Sam Hartman wrote: >Hi. The discussion seems to have died down on the issue of replacing >the ACAP example with an SMTP example in the plain draft. > >The rough consensus of this working group is that we will not change >to an SMTP-based example. We seem to believe that the examples in the >plain document should illustrate that mechanisms, not illustrate common >implementation errors in other related protocols. > >I think that we have something approaching a consensus that we will be >better served by encouraging implementers to read all the appropriate >documents than to include information designed to make sure that >implementers will not make mistakes even if they do not read the >appropriate documents. That's not as clear as the consensus against >changing the example to SMTP; there may be more room for discussion on >this issue. > >Personally I believe that we may want to consider ways in which we can >make it clear to implementers what documents they want to read. > I suggest the following: 1). Don't change examples in PLAIN 2). Implementation consideration section is added to the base SASL document. It will list commonly misimplemented features and will give some protocol examples. I will make sure that SMTP PLAIN example is one of the examples. Reference to PLAIN will be informative. (Or this can be a separate document as discussed recently). 3). I am thinking about [co-]authoring a document that is "protocol profile designer guide". It will compare existing protocols and how different features are implemented in them. This can be the same document as in 2, or a separate document. Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Sat Nov 1 06:22:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EM7kT013069 for ; Sat, 1 Nov 2003 06:22:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1EM7i6013068 for ietf-sasl-bks; Sat, 1 Nov 2003 06:22:07 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1EM6kT013063 for ; Sat, 1 Nov 2003 06:22:06 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:22:48 +0000 Message-ID: <3FA3C18E.8010101@isode.com> Date: Sat, 01 Nov 2003 14:22:06 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> In-Reply-To: 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: > > >>>rfc2222bis section 6.3 "Multiple authentications" says: >>> >>> If a security layer is in effect >>> and a subsequent SASL negotiation selects a second security layer, >>> then the second security layer replaces the first. If a security >>> layer is in effect and a subsequent SASL negotiation selects no >>> security layer, the original security layer must be removed. >>> >>>Exactly when is the old layer canceled? >>> >>>If an old layer is active and the client starts to negotiate a new >>>layer, it may not know when to expect the response from the server. >>>So the layer can't be canceled by starting a new negotiation. >>> >>> >>No, the layer can only be canceled/replaced after a subsequent >>authentication completes successfully. >> > >OK. Please mention that explicitly. > After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads: If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer MUST be removed. The rest of this section explain why this is important. Also note, that if a subsequent authentication fails, the protocol profile MAY allow the connection state to return to non-authenticated, however the previously negotiated security layer MUST NOT be removed. Only a successful reauthentication is able replace/remove the previously negotiated security layer. >>Each profile document must document exactly when this takes place. >> > >'this' = 'it completed successfully', I take it. > > Yes. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 06:44:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EiwkT013730 for ; Sat, 1 Nov 2003 06:44:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1Eiw78013729 for ietf-sasl-bks; Sat, 1 Nov 2003 06:44:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1EiukT013716 for ; Sat, 1 Nov 2003 06:44:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:42:13 +0000 Message-ID: <3FA3C61A.3040307@isode.com> Date: Sat, 01 Nov 2003 14:41:30 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token References: <3F8D308B.5050208@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >>>rfc2831bis 2.1.1 "Step One" says: >>> >>> qop-options = "qop" "=" <"> qop-list <"> >>> qop-list = 1#qop-value >>> qop-value = "auth" | "auth-int" | "auth-conf" | >>> token >>> >>>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >>>"auth", "auth-int" and "auth-conf", but not when it is . >>> >>> >>Token is specifically for future extensions, if you see a qop value you >>don't recognize - you have to ignore it. >>If you recognize nothing, you have to fail the authentication exchange. >> >>Do you want any clarifications on this to be added to the document. >> >> > >Not sure. I think it would be good to mention that 'token is for future >extensions' somewhere. And perhaps that these extensions must define >A2, since rfc2831bis does not. > Ok, I've clarified this. Alexey From owner-ietf-sasl Sat Nov 1 07:09:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1F9LkT014548 for ; Sat, 1 Nov 2003 07:09:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1F9Lgu014547 for ietf-sasl-bks; Sat, 1 Nov 2003 07:09:21 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1F9KkT014542 for ; Sat, 1 Nov 2003 07:09:20 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 15:10:02 +0000 Message-ID: <3FA3CCA0.9040909@isode.com> Date: Sat, 01 Nov 2003 15:09:20 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: <3F9C2F32.1060004@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>>>2.1.1 Step One >>>> >>>> The server starts by sending a challenge. >>>> >>>> >>>How does it know that it should do that? >>> >>The client always starts first (according to SASL). If the client >>doesn't includes an initial response, the server will know. >> >>Can you suggest any clarification text here? >> >> > >'The server starts by sending a challenge after the client indicates >that SASL negotiatin should start'? > > SASL framework doesn't support the case when the server initiate authentication exchange. The only way to do that is for the server to return some kind of "authentication required" error code when the client tries to issue other commands. > ... > >>>>2.2 Subsequent Authentication >>>> >>>> If the client has previously authenticated to the server, and >>>> remembers the values of username, realm, nonce, nonce-count, cnonce, >>>> >>>> >>> ^^^^^^^^ >>> >>> >>>> and qop that it used in that authentication, and the SASL profile for >>>> a protocol permits an initial client response, then it MAY perform >>>> "subsequent authentication", as defined in this section. >>>> >>>> >>>What's the point of authenticating again with the same username? Auth >>>with a _different_ username would be more interesting. >>> >>> >>This is a case of fast reauthentication using a different TCP >>connection. This is similar to resuming a TLS session. >> > >Oh. Could you add 'even after closing the connection and reopening a >new one' in section 2.2? > > Actually, this can be done on the same connection, if the protocol supports reauthentication. I've added the following: Note, that a subsequent authentication can be done on a different connection, or on the same connection, if the protocol profile also permits multiple authentications. I've also added some clarification text at the beginning of section 2. Alexey From owner-ietf-sasl Sat Nov 1 07:33:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1FXokT015378 for ; Sat, 1 Nov 2003 07:33:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1FXoAl015377 for ietf-sasl-bks; Sat, 1 Nov 2003 07:33:50 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1FXnkT015372 for ; Sat, 1 Nov 2003 07:33:49 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 15:34:23 +0000 Message-ID: <3FA3D254.9030809@isode.com> Date: Sat, 01 Nov 2003 15:33:40 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >>>>We should not suggest that mechanisms should do both (1) and >>>>(2). (1) and (3) OR (2) or (3) are sufficient to ensure >>>>proper matching. >>>> >>>> >>>IMHO, this is a responsibility of the client, >>> >>> > >Disagree. It's the responsibility of the mechanism definition to say >where it should happen. > Ok. But in all SASL mechanisms I know the client end sends username or retrieves-hashes-sends something derived from a password. So, so far this is the same thing ;-). Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 08:18:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1GIUkT017160 for ; Sat, 1 Nov 2003 08:18:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1GIUik017159 for ietf-sasl-bks; Sat, 1 Nov 2003 08:18:30 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1GITkT017153 for ; Sat, 1 Nov 2003 08:18:29 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1GIUlg032178; Sat, 1 Nov 2003 16:18:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101080111.057ff8d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 08:17:41 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Fwd: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: ietf-sasl@imc.org 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: >Date: Sat, 01 Nov 2003 15:33:40 +0000 >From: Alexey Melnikov >To: Hallvard B Furuseth >CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org >Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments >List-Archive: > > >Hallvard B Furuseth wrote: >>>>>We should not suggest that mechanisms should do both (1) and >>>>>(2). (1) and (3) OR (2) or (3) are sufficient to ensure >>>>>proper matching. >>>>> >>>>IMHO, this is a responsibility of the client, >>>> >> >>Disagree. It's the responsibility of the mechanism definition to say >>where it should happen. >Ok. >But in all SASL mechanisms I know the client end sends username or retrieves-hashes-sends something derived from a password. >So, so far this is the same thing ;-). There are certainly mechanisms which don't transfer a username (authentication identity in simple form) and/or don't transfer a value derived from a simple password. (For example, EXTERNAL.) And for those which do, it should be left up to the mechanism to state where preparation of those strings is to be done. The framework specification should avoid getting details which are mechanism-specific. Kurt From owner-ietf-sasl Sat Nov 1 09:35:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1HZpkT020002 for ; Sat, 1 Nov 2003 09:35:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1HZpkU020001 for ietf-sasl-bks; Sat, 1 Nov 2003 09:35:51 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1HZmkT019995 for ; Sat, 1 Nov 2003 09:35:48 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1HZilg032752; Sat, 1 Nov 2003 17:35:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101082402.057ffb60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 09:34:54 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Consensus call: changing examples from ACAP to SMTP Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <3FA3BDED.6010804@isode.com> References: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> <3FA3BDED.6010804@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 06:06 AM 11/1/2003, Alexey Melnikov wrote: >Sam Hartman wrote: > >>Hi. The discussion seems to have died down on the issue of replacing >>the ACAP example with an SMTP example in the plain draft. >> >>The rough consensus of this working group is that we will not change >>to an SMTP-based example. We seem to believe that the examples in the >>plain document should illustrate that mechanisms, not illustrate common >>implementation errors in other related protocols. >> >>I think that we have something approaching a consensus that we will be >>better served by encouraging implementers to read all the appropriate >>documents than to include information designed to make sure that >>implementers will not make mistakes even if they do not read the >>appropriate documents. That's not as clear as the consensus against >>changing the example to SMTP; there may be more room for discussion on >>this issue. >> >>Personally I believe that we may want to consider ways in which we can >>make it clear to implementers what documents they want to read. >I suggest the following: >1). Don't change examples in PLAIN As I previously noted, I intend to offer another example illustrating another aspect of the PLAIN feature for WG consideration. But I am going to be very careful to avoid getting into the details more appropriately discussed in referencing documents. >2). Implementation consideration section is added to the base SASL document. I am a bit leery of adding another section to the base SASL document (especially at this late stage). It may be better, as was suggested by someone else, to instead write an "SASL Implementation Guide" as a separate document. I think, however, most of the problems and their solutions are application protocol specific and, hence, should be addressed in documents specific to application protocol. >It will list commonly misimplemented features and will give some protocol examples. >I will make sure that SMTP PLAIN example is one of the examples. Depending on what you intend to illustrate, SMTP may not be the best protocol for the example. (See prior discussion.) >Reference to PLAIN will be informative. (Or this can be a separate document as discussed recently). Again, we need to avoid trumping application profile documents in documents they reference. We need to ensure that any example (and as well as prose) is properly placed in the right document. Now, depending on example what kind of examples you had in mind, they may or may not be appropriate. For instance, examples showing the initial response (without challenge) and final challenge (without response) would likely be useful. But we need to be careful not to specify how exchanges are to be implemented in any particular application-level protocol. I suggest you offer specific text to the list for WG consideration. >3). I am thinking about [co-]authoring a document that is "protocol profile designer guide". It will compare existing protocols and how different features are implemented in them. This can be the same document as in 2, or a separate document. As a separate document, I think this is a good idea. Kurt From owner-ietf-sasl Sat Nov 1 10:16:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1IGWkT021484 for ; Sat, 1 Nov 2003 10:16:32 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1IGW4T021483 for ietf-sasl-bks; Sat, 1 Nov 2003 10:16:32 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1IGUkT021478 for ; Sat, 1 Nov 2003 10:16:31 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1IGWlg033000; Sat, 1 Nov 2003 18:16:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 10:15:42 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: re-negotiating SASL security layer Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FA3C18E.8010101@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@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: Alexey, RFC 2222 said: If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect. I think changing this is bad. The primary reason posted on the list for the change was: "Applications should be allowed to remove layers." I argue that this is, effective, adding a new feature to SASL. Adding new features is beyond our scope. The primary reason given in the draft is to address a security concern. I would suspect that there are numerous other cases, including where re-authentication is not involved, where another party may have direct knowledge of information being encrypted. For example, the same concern arises when an LDAP server provides results obtained through chaining. Or by an LDAP client is chasing a referral. This concerns, I think, would be better addressed by stating security consideration. The primary reason why this is better is because the change will cause significant interoperability problems. Existing implementations expect those layers to remain in effect. Kurt At 06:22 AM 11/1/2003, Alexey Melnikov wrote: >>>>rfc2222bis section 6.3 "Multiple authentications" says: >>>> >>>> If a security layer is in effect >>>> and a subsequent SASL negotiation selects a second security layer, >>>> then the second security layer replaces the first. If a security >>>> layer is in effect and a subsequent SASL negotiation selects no >>>> security layer, the original security layer must be removed. >>>> >>>>Exactly when is the old layer canceled? >>>> >>>>If an old layer is active and the client starts to negotiate a new >>>>layer, it may not know when to expect the response from the server. >>>>So the layer can't be canceled by starting a new negotiation. >>>> >>>No, the layer can only be canceled/replaced after a subsequent authentication completes successfully. >> >>OK. Please mention that explicitly. >After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads: > >If a profile explicitly permits multiple successful SASL >negotiations to occur, then in no case may multiple security layers be >simultaneously in effect. If a security layer is in effect >and a subsequent SASL negotiation selects a second security layer, >then the second security layer replaces the first. If a security layer >is in effect and a subsequent SASL negotiation selects no security layer, >the original security layer MUST be removed. The rest of this section explain >why this is important. Also note, that if a subsequent authentication fails, >the protocol profile MAY allow the connection state to return to non-authenticated, >however the previously negotiated security layer MUST NOT be removed. Only >a successful reauthentication is able replace/remove the previously negotiated >security layer. > >>>Each profile document must document exactly when this takes place. >> >>'this' = 'it completed successfully', I take it. >> >Yes. > >Alexey >__________________________________________ >Isode Limited, http://www.isode.com > >IETF standard related pages: >http://orthanc.ab.ca/mel/devel/Links.html >__________________________________________ > From owner-ietf-sasl Sat Nov 1 10:55:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1ItwkT022528 for ; Sat, 1 Nov 2003 10:55:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1ItwGf022527 for ietf-sasl-bks; Sat, 1 Nov 2003 10:55:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1ItukT022522 for ; Sat, 1 Nov 2003 10:55:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 18:56:36 +0000 Message-ID: <3FA401B2.50607@isode.com> Date: Sat, 01 Nov 2003 18:55:46 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031101093553.0585dce8@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: Kurt D. Zeilenga wrote: >Alexey, > >RFC 2222 said: > If a security layer is in effect and a subsequent SASL negotiation > selects no security layer, the original security layer remains in effect. > >I think changing this is bad. > >The primary reason posted on the list for the change was: "Applications >should be allowed to remove layers." I argue that this is, effective, >adding a new feature to SASL. Adding new features is beyond our scope. > I never said that and I don't believe this is an important feature. >The primary reason given in the draft is to address a security concern. >I would suspect that there are numerous other cases, including where >re-authentication is not involved, where another party may have direct >knowledge of information being encrypted. For example, the same concern >arises when an LDAP server provides results obtained through chaining. >Or by an LDAP client is chasing a referral. This concerns, I think, >would be better addressed by stating security consideration. > Kurt, I think you are missing the point. You are describing authorized disclosure (or something similar to a situation when one end of the connection is broadcasting decrypted data over the network in the clear). The draft describes a potential security vulnerability. I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication), but there is no point of propagating something which is known to be broken to new protocols. >The primary reason why this is better is because the change will cause >significant interoperability problems. Existing implementations expect >those layers to remain in effect. > How about changing MUST to SHOULD to allow for backward compatibility for LDAP? Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Sat Nov 1 11:41:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1JfbkT023697 for ; Sat, 1 Nov 2003 11:41:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1JfbAx023696 for ietf-sasl-bks; Sat, 1 Nov 2003 11:41:37 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1JfakT023691 for ; Sat, 1 Nov 2003 11:41:36 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 19:42:18 +0000 Message-ID: <3FA40C6F.3030004@isode.com> Date: Sat, 01 Nov 2003 19:41:35 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>>>>>>In >>>>>>>order to avoid noninteroperability due to differing normalizations, >>>>>>>when a mechanism specifies that a string authentication identity or >>>>>>>password used as input to a cryptographic function (or used for >>>>>>>comparison) it SHOULD specify that the string first be prepared using >>>>>>>the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>>>>>[StringPrep]. >>>>>>> >>>>>>> >>The new text after that reads: >> >>There are three entities that has to deal with this issue: a client >>(upon getting user input or retrieving a value from configuration), a server >>(upon receiving the value from the client) and a utility that is able to >>store >>passwords/hashes in a database that can be later used by the server. >>The preparation must be done by the client and the utility and may be >>done by the >>server. If preparation fails or results in an empty string, the entity doing >>the preparation SHALL fail the authentication exchange. >> > >I like Kurt's suggestion better: The mechanism must define where >preparation is done. That way clients using mechanisms like PLAIN can >leave as much work as possible to the server. > I've updated the draft to say that each mechanism must describe where preparation takes place. Alexey From owner-ietf-sasl Sat Nov 1 12:35:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KZxkT025335 for ; Sat, 1 Nov 2003 12:35:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KZxTG025334 for ietf-sasl-bks; Sat, 1 Nov 2003 12:35:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1KZrkT025328 for ; Sat, 1 Nov 2003 12:35:54 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1KZtlg034106; Sat, 1 Nov 2003 20:35:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101114709.02b854d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 12:35:06 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: re-negotiating SASL security layer Cc: ietf-sasl@imc.org In-Reply-To: <3FA401B2.50607@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@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:55 AM 11/1/2003, Alexey Melnikov wrote: >The draft describes a potential security vulnerability. I don't disagree that there is a potential security vulnerability. I disagree that we should address it by changing the protocol. The issue can be (and, in my opinion, should be) addressed through statement of appropriate security considerations. I think we're talking about the same class of attacks. There are numerous cases where a third party (such as BB in your discussion) have limited knowledge of protected content and could use that knowledge to mount an attack. Note that your solution doesn't complete eliminate this particular case as the old layers are in-effect during the reauthentication. Server BB could still use its knowledge of the reauthentication process to attack the encryption of previously sent information. I think the risk of this class of attack is not sufficient to warrant changing the protocol especially considering the interoperability (and security?) problems the change would cause. I say "and security?" as now traffic which an old client expected to be protected by old layers would not be protected. We have to consider that as well. >I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication), but there is no point of propagating something which is known to be broken to new protocols. I don't consider SASL broken in this respect. It just that there are security concerns to be considered. >>The primary reason why this is better is because the change will cause >>significant interoperability problems. Existing implementations expect >>those layers to remain in effect. >How about changing MUST to SHOULD to allow for backward compatibility for LDAP? A SHOULD would be inappropriate as interoperability mandates that either all implementations keep the layer or all implementations drop the layer. Kurt From owner-ietf-sasl Sat Nov 1 12:42:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KgekT025610 for ; Sat, 1 Nov 2003 12:42:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KgetU025609 for ietf-sasl-bks; Sat, 1 Nov 2003 12:42:40 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1KgdkT025604 for ; Sat, 1 Nov 2003 12:42:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 20:43:23 +0000 Message-ID: <3FA41ABF.1080602@isode.com> Date: Sat, 01 Nov 2003 20:42:39 +0000 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: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <6.0.0.22.0.20031101114709.02b854d0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031101114709.02b854d0@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: >>>The primary reason why this is better is because the change will cause >>>significant interoperability problems. Existing implementations expect >>>those layers to remain in effect. >>> >>> >>How about changing MUST to SHOULD to allow for backward compatibility for LDAP? >> >> >A SHOULD would be inappropriate as interoperability mandates that either all >implementations keep the layer or all implementations drop the layer. > > SHOULD in protocol profile, not "SHOULD keep/drop the old layer". Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sat Nov 1 12:43:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KhAkT025624 for ; Sat, 1 Nov 2003 12:43:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KhAR9025623 for ietf-sasl-bks; Sat, 1 Nov 2003 12:43:10 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1Kh9kT025618 for ; Sat, 1 Nov 2003 12:43:09 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 20:43:52 +0000 Message-ID: <3FA41ADD.2000308@isode.com> Date: Sat, 01 Nov 2003 20:43:09 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> In-Reply-To: <3FA401B2.50607@isode.com> 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: Alexey Melnikov wrote: >> The primary reason why this is better is because the change will cause >> significant interoperability problems. Existing implementations expect >> those layers to remain in effect. >> > How about changing MUST to SHOULD to allow for backward compatibility > for LDAP? Thinking more about this. What I didn't like about the original text is that it was kind of MUST. What if I rephrase to allow a protocol profile to have a choice: either keep the original layer if none was negotiated during reauthentication (and have a security consideration about the issue) or remove the original layer. If the protocol profile chooses to do the former, it should recommend to always negotiate a new security layer during reauthentication. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Sun Nov 2 19:03:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA333vkT045942 for ; Sun, 2 Nov 2003 19:03:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA333v3Q045941 for ietf-sasl-bks; Sun, 2 Nov 2003 19:03:57 -0800 (PST) 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.10/8.12.8) with ESMTP id hA333tkT045935 for ; Sun, 2 Nov 2003 19:03:56 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AGV0V-00037v-8J; Mon, 03 Nov 2003 04:03:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AGV0P-0008W2-No; Mon, 03 Nov 2003 04:03:49 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AGV0O-0004P6-00; Mon, 3 Nov 2003 04:03:48 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 3 Nov 2003 04:03:48 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > I note that this issue is likely not unique to ANONYMOUS. So, maybe > it should be dealt with in base SASL specification. > > I'm thinking a malformed message should be treated as a protocol > error in the application protocol. How detailed should the checking for malformed messages be? For example, is it a protocol error to send a latin-1 string when the protocol requires UTF-8? How about sending an invalid UTF-8-like sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid? -- Hallvard From owner-ietf-sasl Sun Nov 2 20:10:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA34ATkT047807 for ; Sun, 2 Nov 2003 20:10:29 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA34ATBr047806 for ietf-sasl-bks; Sun, 2 Nov 2003 20:10:29 -0800 (PST) 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.10/8.12.8) with ESMTP id hA34ARkT047801 for ; Sun, 2 Nov 2003 20:10:28 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA34AUlg047138; Mon, 3 Nov 2003 04:10:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031102194648.02ba7af8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sun, 02 Nov 2003 20:09:39 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031003061141.040ed080@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 07:03 PM 11/2/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> I note that this issue is likely not unique to ANONYMOUS. So, maybe >> it should be dealt with in base SASL specification. >> >> I'm thinking a malformed message should be treated as a protocol >> error in the application protocol. Note that application protocols generally give great freedom in how protocol errors are treated. And, the principle of "be liberal in what you accept but strict in what your send" applies as well. >How detailed should the checking for malformed messages be? I think, in general, protocol peers should check each component of the PDU which they make use of and then some. For ANONYMOUS, a server which uses the message should check that it is properly encoded UTF-8 but a server which didn't make use of the message could simply ignore the message. >For example, is it a protocol error to send a latin-1 string when the >protocol requires UTF-8? Yes. >How about sending an invalid UTF-8-like >sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid? Yes. Kurt From owner-ietf-sasl Mon Nov 3 11:51:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JpvkT048391 for ; Mon, 3 Nov 2003 11:51:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3Jpvkb048390 for ietf-sasl-bks; Mon, 3 Nov 2003 11:51:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JpukT048383 for ; Mon, 3 Nov 2003 11:51:56 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3JpuPh001286; Mon, 3 Nov 2003 12:51:56 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA3Jpuru024629; Mon, 3 Nov 2003 11:51:56 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNS00INSKIJNJ@mpkmail.eng.sun.com>; Mon, 03 Nov 2003 11:51:56 -0800 (PST) Date: Mon, 03 Nov 2003 11:51:56 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=UTF-8 Content-MD5: SfGydn3QK25i2FE+TDdj5Q== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA3JpukT048385 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree that the SASLprep is more suitable and applicable for simple user names and passwords and if the additional mappings such as the full stops are needed, they are more suitable and correct to be done at the outside of any Stringprep/Stringprep profiles and most preferrably before the application of the Stringprep profile(s). <-- These are also my points all along. The reasons are like the following that the U+002E (full stop and dot/decimal point) isn't the same or equivalent to the ideographic/Asian full stops all the time; if they were, the Unicode itself would define them as equivalent forms/characters and show canonical/compatiblity decomposition(s) at each characters so that the Unicode normalizations would normalize those characters into a (normalized) character. Also, if everyone would agree on the fact that the ideopgraphic/Asian full stops are not equivalent to the U+002E and yet we still need to support the mappings described in the IDNA for the compatibility/interoperability on the Internet domain style names (only), then, I'm also thinking that everyone would agree this conditional mappings should be done outside of the Stringprep and any of the Stringprep profiles (since the Stringprep itself doesn't really allow conditional mappings at the mapping step as of today even though a profile *possibly and maybe* could define such conditional mappings). Re user provided strings, I have the following example that shouldn't match as the same thing: 3.14 ３。１４ 3。14 The first one is the pi, three point one four, in ASCII and the second is three, ideographic full-stop, and fourteen in Asian full-width digit characters and with ideographic full stop in UTF-8. (The third one is a variation of the second one, three, ideographic full-stop, and fourteen in ASCII digits and with ideographic full stop in UTF-8; and the second and the third can be seen as equivalent.) With regards, Ienup ] Date: Fri, 31 Oct 2003 20:52:15 -0800 ] From: "Kurt D. Zeilenga" ] Subject: Re: SASLPrep vs Full Stop code points ] X-Sender: kurt@127.0.0.1 ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] ] At 05:42 PM 10/31/2003, Ienup Sung wrote: ] >Regarding the full stops, while I do understand the point of display vs. ] >storage/query string in my opinion, I think the issue boils down onto ] >the followign two things in my view: ] >1. Should/can we treat ideographic/Asian full stops as equivalent characters ] > of the ASCII full stop (U+002E) in 100% of the possible cases/usages? ] ] SASLprep is only applicable to two use cases: simple user names and password. ] ] > The answer is no since the U+002E is not only a full stop character but ] > it is also a period and dot/decimal point character; CJK speakers do not use ] > the ideographic/Asian full stops as the dot/decimal point character and ] > hence some use of the ideographic/Asian full stops rather be preserved as ] > they are to be distingushed. And in that cases, can we distinguish what to ] > preserve and what not to preserve and map? ] ] SASLprep scope is limited to preparation of user input strings for matching. ] Issues such as how to preserving the (unprepared) user input is simply beyond ] our scope as matching and hence SASLprep. ] ] >2. Should/can we keep the compatiblity with the IDNA's additional and ] > pre-processing on the label separators, i.e., mappings of all full stops to ] > the U+002E, for the domain style (IDN) names before they are used? ] > I think the answer should be yes. ] ] SASLprep can define one preparation algorithm for simple user names and ] passwords. Simple here implies the input has no structure. That is, ] names have no particular style in respect to the algorithm. ] ] It is possible that specification using SASLprep could apply additional ] transformations be done. However, such transforms are beyond the scope ] of SASLprep. ] ] >I know the above two sound conflicting and the example shown at the argument ] >#1 could be considered as a case that may not need to be really supported. ] >But I thought presenting them might be a valuable thing to do. ] ] I would be interested in hearing whether you think the additional suggested ] mapping is appropriate or not for matching of simple user names or passwords, ] and why. ] ] I think this issue boils down to whether the user provided strings: ] ] ] ] ] ] should match or not. Because user names are often constructed from domain ] names, and IDNA says these stops are to be treated as equivalent, I believe ] they should match. ] ] Kurt ] From owner-ietf-sasl Tue Nov 4 13:16:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LGOkT072941 for ; Tue, 4 Nov 2003 13:16:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4LGO74072940 for ietf-sasl-bks; Tue, 4 Nov 2003 13:16:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hA4LGHkT072933 for ; Tue, 4 Nov 2003 13:16:18 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AH8XA-0007QQ-SV; Tue, 04 Nov 2003 22:16:16 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AH8X6-0005gb-Fu; Tue, 04 Nov 2003 22:16:12 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AH8X5-0002i1-00; Tue, 4 Nov 2003 22:16:11 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis issues In-Reply-To: <3F9C2F32.1060004@isode.com> References: <3F9C2F32.1060004@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 4 Nov 2003 22:16:11 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>draft-ietf-sasl-rfc2831bis-02.txt: >>> >>> ( *LWS element *( *LWS "," *LWS element )) >> >>Should this really be asymmetric, or should it be >> ( element *( *LWS "," *LWS element )) >>or >> ( *LWS element *( *LWS "," *LWS element ) *LWS ) >> >I can go for the last proposal. At least it seems to be the original intent. I just realized that this was copied from rfc2616. So it's probably better to leave it alone for compatibility's sake, or ask rfc2616's author. -- Hallvard From owner-ietf-sasl Wed Nov 5 02:30:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5AUdkT068698 for ; Wed, 5 Nov 2003 02:30:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5AUd6w068697 for ietf-sasl-bks; Wed, 5 Nov 2003 02:30:39 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5AUUkT068677 for ; Wed, 5 Nov 2003 02:30:37 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 10:31:29 +0000 Message-ID: <3FA8D140.1060507@isode.com> Date: Wed, 05 Nov 2003 10:30:24 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: <3F9C2F32.1060004@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>draft-ietf-sasl-rfc2831bis-02.txt: >>> >>> >>>> ( *LWS element *( *LWS "," *LWS element )) >>>> >>>> >>>Should this really be asymmetric, or should it be >>> ( element *( *LWS "," *LWS element )) >>>or >>> ( *LWS element *( *LWS "," *LWS element ) *LWS ) >>> >>> >>> >>I can go for the last proposal. At least it seems to be the original intent. >> >> > >I just realized that this was copied from rfc2616. > Correct. >So it's probably >better to leave it alone for compatibility's sake, or ask rfc2616's >author. > I've already fixed several minor ABNF bugs. But it would be a good idea to keep DIGEST-MD5 and RFC 2616 in sync. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Nov 5 08:34:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GY5kT088094 for ; Wed, 5 Nov 2003 08:34:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5GY5fL088093 for ietf-sasl-bks; Wed, 5 Nov 2003 08:34:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GY4kT088086 for ; Wed, 5 Nov 2003 08:34:04 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 4572D7661E; Wed, 5 Nov 2003 11:33:11 -0500 (EST) To: agenda@ietf.org Cc: ietf-sasl@imc.org Subject: SASL Working group agenda for IETF 58 From: Sam Hartman Date: Wed, 05 Nov 2003 11:33:11 -0500 Message-ID: <87ptg6g4hk.fsf@luminous.mit.edu> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux) 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: Simple Authentication and Security Layer Tuesday 1545-1645 0) Preliminaries - chairs - 10 min Agenda / WG Status / etc. 1) Removing security layers on re-authentication discussion - editor - 10 min (draft-ietf-sasl-rfc2222bis) 2) SASLprep "Full Stop" discussion - editor - 15 min (draft-ietf-sasl-saslprep) 3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes (draft-siemborski-rfc2554bis) 4) Next steps / Milestones - chairs - 10 minutes 5) Open Mic - floor - remaining time From owner-ietf-sasl Wed Nov 5 11:32:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JWbkT096402 for ; Wed, 5 Nov 2003 11:32:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5JWaH0096400 for ietf-sasl-bks; Wed, 5 Nov 2003 11:32:36 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5JWUkT096395 for ; Wed, 5 Nov 2003 11:32:35 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 19:33:24 +0000 Message-ID: <3FA95041.6090001@isode.com> Date: Wed, 05 Nov 2003 19:32:17 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> In-Reply-To: <3FA41ADD.2000308@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: > Alexey Melnikov wrote: > >>> The primary reason why this is better is because the change will cause >>> significant interoperability problems. Existing implementations expect >>> those layers to remain in effect. >> >> How about changing MUST to SHOULD to allow for backward compatibility >> for LDAP? > > Thinking more about this. What I didn't like about the original text > is that it was kind of MUST. > What if I rephrase to allow a protocol profile to have a choice: > either keep the original layer if none was negotiated during > reauthentication (and have a security consideration about the issue) > or remove the original layer. > If the protocol profile chooses to do the former, it should recommend > to always negotiate a new security layer during reauthentication. Ok, the new text reads: If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the protocol profile has to specify a choice between: 1) keeping the original security layer. 2) removing the original security layer (replacing with no layer). RFC 2222 only allowed for the first choice, however it was later discovered that the choice is vulnerable to a security attack described later in this section. Thus, new protocol profiles should use the second choice. The protocol profiles that depend on RFC 2222 behaviour should recommend to always negotiate another security layer, once a security layer was installed. Also note, that if a subsequent authentication fails, the protocol profile MAY allow the connection state to return to non-authenticated, however the previously negotiated security layer MUST NOT be removed. Only a successful reauthentication is able replace/remove the previously negotiated security layer. Hopefully this will make everybody happy. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Nov 5 11:39:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JdOkT096779 for ; Wed, 5 Nov 2003 11:39:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5JdOAT096778 for ietf-sasl-bks; Wed, 5 Nov 2003 11:39:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5JdNkT096767 for ; Wed, 5 Nov 2003 11:39:23 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 19:40:26 +0000 Message-ID: <3FA951E7.7090208@isode.com> Date: Wed, 05 Nov 2003 19:39:19 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: SASL Working group agenda for IETF 58 References: <87ptg6g4hk.fsf@luminous.mit.edu> In-Reply-To: <87ptg6g4hk.fsf@luminous.mit.edu> 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: Sam Hartman wrote: > Simple Authentication and Security Layer > Tuesday 1545-1645 > > > 0) Preliminaries - chairs - 10 min > Agenda / WG Status / etc. > 1) Removing security layers on re-authentication discussion - editor - 10 min > (draft-ietf-sasl-rfc2222bis) > I think I've addressed the issue to satisfy both sides (see the message I've just sent to the mailing list). Buf feel free to discuss this and let me know the outcome. Rob Siemborski is my "designed proxy" :-). > 2) SASLprep "Full Stop" discussion - editor - 15 min > (draft-ietf-sasl-saslprep) > 3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes > (draft-siemborski-rfc2554bis) > 4) Next steps / Milestones - chairs - 10 minutes > 5) Open Mic - floor - remaining time > > Is it worth sending updated versions of SASL-base and DIGEST-MD5 documents for the people to review during the meeting? Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Nov 5 11:50:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Jo2kT097476 for ; Wed, 5 Nov 2003 11:50:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Jo29T097475 for ietf-sasl-bks; Wed, 5 Nov 2003 11:50:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5Jo1kT097467 for ; Wed, 5 Nov 2003 11:50:01 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AHTfA-00013d-Rm; Wed, 05 Nov 2003 20:49:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AHTf7-0007fz-Su; Wed, 05 Nov 2003 20:49:53 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHTf7-00060Q-00; Wed, 5 Nov 2003 20:49:53 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 5 Nov 2003 20:49:53 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > (...) Only a successful reauthentication is able replace/remove the > previously negotiated security layer. Just to make sure it has been mentioned: This also means that non-SASL authentication must keep any old SASL layer. I expect that's intended, including for LDAPv4? -- Hallvard From owner-ietf-sasl Wed Nov 5 13:32:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5LWjkT001489 for ; Wed, 5 Nov 2003 13:32:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5LWjDp001488 for ietf-sasl-bks; Wed, 5 Nov 2003 13:32:45 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5LWikT001478 for ; Wed, 5 Nov 2003 13:32:44 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHVGZ-0002fI-Nz; Wed, 05 Nov 2003 22:32:39 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHVGS-0007qm-44; Wed, 05 Nov 2003 22:32:32 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHVGQ-0006FJ-00; Wed, 5 Nov 2003 22:32:30 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 5 Nov 2003 22:32:30 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > Ok, the new text reads: > (...) > If a security layer > is in effect and a subsequent SASL negotiation selects no security layer, > the protocol profile has to specify a choice between: > > 1) keeping the original security layer. > 2) removing the original security layer (replacing with no layer). This belongs in section 5 (Protocol Profile Requirements). I suggest to indent (1) and (2), BTW. > Also note, that if a subsequent authentication fails, > the protocol profile MAY allow the connection state to return to > non-authenticated, I can't find anything about that in section 5. Is it this text? "A protocol profile MAY further refine the definition of an authorization identity by adding additional syntactic restrictions and protocol-specific semantics." If so, maybe that sentence should be clarified to explicitly allow the protocol profile to say something about the effect of authentication on authentication/authorization IDs. -- Hallvard From owner-ietf-sasl Wed Nov 5 15:46:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5NkekT006253 for ; Wed, 5 Nov 2003 15:46:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5NkeYC006252 for ietf-sasl-bks; Wed, 5 Nov 2003 15:46:40 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5NkZkT006245 for ; Wed, 5 Nov 2003 15:46:35 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AHXMA-0006qx-JG; Thu, 06 Nov 2003 00:46:34 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AHXM6-000062-7T; Thu, 06 Nov 2003 00:46:30 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHXM6-0006YO-00; Thu, 6 Nov 2003 00:46:30 +0100 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov cc: SASL WG Subject: Re: Replacing a SASL security layer Date: Thu, 6 Nov 2003 00:46:30 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Ignore for a moment any relationship of realm to DIGEST-MD5, > GSSAPI or any other SASL mechanism. Let's use the definition I > have in the document: > > Conceptually, realm is the name of a collection of user's accounts. > Realms allow the protected resources on a server to be partitioned into > a set of protection spaces, each with its own authentication mechanisms > and/or authorization database. For example, a proxy/frontend can use > different realms for different servers/backends it represents. > > So, each "realm" ("a protection space") is served by a separate > server (proxy example above) or a separate process/plugin > (frontend-backend example). Does it make more sense now? Not to me. The client authenticates to server AA with realm A, and to server BB with realm B. So why does server BB see the traffic to server AA? Or if it doesn't, why does it know the realm A traffic, since that belongs on server AA? And why does the client send the same text to server AA as to server BB, sans realm differences, so that server BB can compare them? -- Hallvard From owner-ietf-sasl Wed Nov 5 16:46:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA60k4kT008149 for ; Wed, 5 Nov 2003 16:46:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA60k4HJ008148 for ietf-sasl-bks; Wed, 5 Nov 2003 16:46:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hA60k2kT008143 for ; Wed, 5 Nov 2003 16:46:03 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHYHi-00052t-D0 for ietf-sasl@imc.org; Thu, 06 Nov 2003 01:46:02 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHYHe-00044U-Ct; Thu, 06 Nov 2003 01:45:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHYHe-0006gY-00; Thu, 6 Nov 2003 01:45:58 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: unauthenticated access without SASL layer Date: Thu, 6 Nov 2003 01:45:58 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looking over the various SASL drafts, I miss one piece of functionality: To authenticate anonymously, removing any SASL layer, but still providing an unauthenticated ID (e.g. for logging purposes). LDAP provides this with the 'simple' non-SASL authentication choice, except for the part about removing the SASL layer. The ANONYMOUS mechanism (draft-ietf-sasl-anon-02.txt) can be used for this - except if the desired ID contains '@', which means the ID is an e-mail address. The PLAIN mechanism (draft-ietf-sasl-plain-03.txt) could be used if an empty password was allowed, but it isn't. Am I missing something? Should one of the mechanisms above be changed to allow this? -- Hallvard From owner-ietf-sasl Wed Nov 5 17:00:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA610bkT008908 for ; Wed, 5 Nov 2003 17:00:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA610bf6008907 for ietf-sasl-bks; Wed, 5 Nov 2003 17:00:37 -0800 (PST) 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.10/8.12.8) with ESMTP id hA610akT008901 for ; Wed, 5 Nov 2003 17:00:36 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AHYVn-0006LC-Ot for ietf-sasl@imc.org; Thu, 06 Nov 2003 02:00:35 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AHYVm-0006jF-5T; Thu, 06 Nov 2003 02:00:34 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHYVl-0006iV-00; Thu, 6 Nov 2003 02:00:33 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-sasl@imc.org Subject: rfc2222bis: 'selects no security layer' In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 02:00:33 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis says: > If a security layer is in effect and a subsequent SASL negotiation > selects no security layer, (...) Please rephrase as either 'does not select a security layer' (like PLAIN) or '(explicitly) selects that there should be no security layer' (which PLAIN does _not_ do). I presume it's the former. -- Hallvard From owner-ietf-sasl Wed Nov 5 17:41:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA61f2kT010737 for ; Wed, 5 Nov 2003 17:41:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA61f28Q010736 for ietf-sasl-bks; Wed, 5 Nov 2003 17:41:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA61f0kT010727 for ; Wed, 5 Nov 2003 17:41:00 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA61f3lg035207; Thu, 6 Nov 2003 01:41:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 05 Nov 2003 17:40:07 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: unauthenticated access without SASL layer Cc: ietf-sasl@imc.org In-Reply-To: References: 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 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >Looking over the various SASL drafts, I miss one piece of functionality: >To authenticate anonymously, removing any SASL layer, but still >providing an unauthenticated ID (e.g. for logging purposes). >Am I missing something? Should one of the mechanisms above be changed to allow this? No. If someone really wants this, they should define a new mechanism which allowed for an unauthenticated identity and a layer with a null cipher. Kurt From owner-ietf-sasl Thu Nov 6 02:35:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AZNkT001283 for ; Thu, 6 Nov 2003 02:35:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AZN5K001282 for ietf-sasl-bks; Thu, 6 Nov 2003 02:35:23 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AZJkT001150 for ; Thu, 6 Nov 2003 02:35:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:36:20 +0000 Message-ID: <3FAA23DE.7000508@isode.com> Date: Thu, 06 Nov 2003 10:35:10 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Ok, the new text reads: >> >> >>(...) >>If a security layer >>is in effect and a subsequent SASL negotiation selects no security layer, >>the protocol profile has to specify a choice between: >> >>1) keeping the original security layer. >>2) removing the original security layer (replacing with no layer). >> >> > >This belongs in section 5 (Protocol Profile Requirements). > Yes, this is also mentioned in section 5 [in my copy]. >I suggest to indent (1) and (2), BTW. > > >>Also note, that if a subsequent authentication fails, >>the protocol profile MAY allow the connection state to return to >>non-authenticated, >> >> > >I can't find anything about that in section 5. Is it this text? > > "A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics." > No. This is a new text added to allow for LDAP behaviour. >If so, maybe that sentence should be clarified to explicitly allow the >protocol profile to say something about the effect of authentication on >authentication/authorization IDs. > > Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 02:52:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AqZkT002322 for ; Thu, 6 Nov 2003 02:52:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AqZof002321 for ietf-sasl-bks; Thu, 6 Nov 2003 02:52:35 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AqYkT002316 for ; Thu, 6 Nov 2003 02:52:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:53:41 +0000 Message-ID: <3FAA27EE.50808@isode.com> Date: Thu, 06 Nov 2003 10:52:30 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >rfc2222bis says: > > >>If a security layer is in effect and a subsequent SASL negotiation >>selects no security layer, (...) >> >> > >Please rephrase as either 'does not select a security layer' (like >PLAIN) or '(explicitly) selects that there should be no security layer' >(which PLAIN does _not_ do). I presume it's the former. > > No, I actually mean both. DIGEST-MD5 has a mode when you can explicitly negotiate no security layer. I would welcome any suggestions to make this clearer. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.ht ___________________________________________ From owner-ietf-sasl Thu Nov 6 02:58:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AwCkT002584 for ; Thu, 6 Nov 2003 02:58:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AwCAQ002583 for ietf-sasl-bks; Thu, 6 Nov 2003 02:58:12 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AwBkT002576 for ; Thu, 6 Nov 2003 02:58:11 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:59:15 +0000 Message-ID: <3FAA293C.1000206@isode.com> Date: Thu, 06 Nov 2003 10:58:04 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031105173306.048bc888@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: Kurt D. Zeilenga wrote: >At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: > > >>Looking over the various SASL drafts, I miss one piece of functionality: >>To authenticate anonymously, removing any SASL layer, but still >>providing an unauthenticated ID (e.g. for logging purposes). >> How is this different from ANONYMOUS (except for >>Am I missing something? Should one of the mechanisms above be changed to allow this? >> >> > >No. If someone really wants this, they should define a new >mechanism which allowed for an unauthenticated identity and >a layer with a null cipher. > IMHO, there is no point in a layer with a null cipher, it just adds unnecessary SASL framing. Unless of course the layer does something else. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 03:14:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6BESkT004018 for ; Thu, 6 Nov 2003 03:14:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6BESxx004017 for ietf-sasl-bks; Thu, 6 Nov 2003 03:14:28 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6BERkT004012 for ; Thu, 6 Nov 2003 03:14:27 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 11:15:28 +0000 Message-ID: <3FAA2D0A.9040305@isode.com> Date: Thu, 06 Nov 2003 11:14:18 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> In-Reply-To: <3FAA293C.1000206@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: > > >>> Looking over the various SASL drafts, I miss one piece of >>> functionality: >>> To authenticate anonymously, removing any SASL layer, but still >>> providing an unauthenticated ID (e.g. for logging purposes). >>> > How is this different from ANONYMOUS (except for ... @ sign requirement). Alexey From owner-ietf-sasl Thu Nov 6 07:18:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FIxkT013907 for ; Thu, 6 Nov 2003 07:18:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FIx8i013906 for ietf-sasl-bks; Thu, 6 Nov 2003 07:18:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FIvkT013899 for ; Thu, 6 Nov 2003 07:18:58 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AHluR-00034q-MJ; Thu, 06 Nov 2003 16:18:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AHluQ-0007Zn-2E; Thu, 06 Nov 2003 16:18:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHluM-000172-00; Thu, 6 Nov 2003 16:18:50 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <3FAA27EE.50808@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:18:50 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>rfc2222bis says: >> >>>If a security layer is in effect and a subsequent SASL negotiation >>>selects no security layer, (...) >> >>Please rephrase as either 'does not select a security layer' (like >>PLAIN) or '(explicitly) selects that there should be no security layer' >>(which PLAIN does _not_ do). I presume it's the former. >> > No, I actually mean both. Now I'm confused. If a SASL security layer is active and I authenticate with PLAIN, is the layer removed or not? If it is removed, my first suggested text above clarifies that. If it is not, my second text. Are there other alternatives? > DIGEST-MD5 has a mode when you can explicitly > negotiate no security layer. Where? A search for 'layer' in rfc2831bis-02 only turns up the reference [RFC 2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. -- Hallvard From owner-ietf-sasl Thu Nov 6 07:15:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FFLkT013754 for ; Thu, 6 Nov 2003 07:15:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FFLV9013753 for ietf-sasl-bks; Thu, 6 Nov 2003 07:15:21 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FFKkT013748 for ; Thu, 6 Nov 2003 07:15:20 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6FFLlg042692; Thu, 6 Nov 2003 15:15:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 07:14:25 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: 'selects no security layer' Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FAA27EE.50808@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@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 02:52 AM 11/6/2003, Alexey Melnikov wrote: >I would welcome any suggestions to make this clearer. I think one of the problems we have adding this profile option is that the specification is now much more complex and framework implementations, especially those which support both options, will need to be much more complex. We need to keep SASL and the specification of SASL simple. I don't see the risk from the described threat being so high to warrant the insertion of this option ESPECIALLY given that the option doesn't not fully address the vulnerability. The information sent under the subsequent layers is still contains information known by those involved in the reauthentication. Kurt From owner-ietf-sasl Thu Nov 6 07:10:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FAwkT013591 for ; Thu, 6 Nov 2003 07:10:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FAwaq013590 for ietf-sasl-bks; Thu, 6 Nov 2003 07:10:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FAqkT013571 for ; Thu, 6 Nov 2003 07:10:52 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6FArlg042616; Thu, 6 Nov 2003 15:10:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 07:09:57 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: unauthenticated access without SASL layer Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FAA293C.1000206@isode.com> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@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 02:58 AM 11/6/2003, Alexey Melnikov wrote: >>No. If someone really wants this, they should define a new >>mechanism which allowed for an unauthenticated identity and >>a layer with a null cipher. >IMHO, there is no point in a layer with a null cipher, it just adds unnecessary SASL framing. Unless of course the layer does something else. It replaces the previous layers. Hallvard wanted a way to do that, I assume for application protocols which only replace layers (don't deinstall them). This points out a serious problem with your suggestion that some protocols can deinstall layers will others can leave them installed, the applicability of the mechanism may be highly dependent on whether all layers can be removed once established or not. The more I think about adding the option to remove layers on reauthentication, the more I think it is a bad idea. Kurt From owner-ietf-sasl Thu Nov 6 07:22:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FMVkT014087 for ; Thu, 6 Nov 2003 07:22:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FMV9p014086 for ietf-sasl-bks; Thu, 6 Nov 2003 07:22:31 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FMUkT014080 for ; Thu, 6 Nov 2003 07:22:30 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AHlxq-0003Rb-4X; Thu, 06 Nov 2003 16:22:26 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AHlxk-0007zM-W1; Thu, 06 Nov 2003 16:22:20 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHlxk-00017M-00; Thu, 6 Nov 2003 16:22:20 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FAA23DE.7000508@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA23DE.7000508@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:22:20 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>Alexey Melnikov writes: >> >>>Also note, that if a subsequent authentication fails, >>>the protocol profile MAY allow the connection state to return to >>>non-authenticated, >> >>I can't find anything about that in section 5. Is it this text? >> >> "A protocol profile MAY further refine the definition of an >> authorization identity by adding additional syntactic restrictions >> and protocol-specific semantics." >> > No. > This is a new text added to allow for LDAP behaviour. That it allows for LDAP is fine, but I'm wondering about the text 'the protocol profile MAY allow the connection state to return to non-authenticated'. If it's not the text I quoted, allowing the connection state to return to non-authenticated has nothing to do with the protocol profile at all. -- Hallvard From owner-ietf-sasl Thu Nov 6 07:36:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Fa7kT014707 for ; Thu, 6 Nov 2003 07:36:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Fa7a5014706 for ietf-sasl-bks; Thu, 6 Nov 2003 07:36:07 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6Fa6kT014699 for ; Thu, 6 Nov 2003 07:36:06 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHmAz-00058I-0D; Thu, 06 Nov 2003 16:36:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHmAw-0001k0-24; Thu, 06 Nov 2003 16:35:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHmAs-00019i-00; Thu, 6 Nov 2003 16:35:54 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer In-Reply-To: <3FAA293C.1000206@isode.com> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:35:54 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Kurt D. Zeilenga wrote: >>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >> >>> Looking over the various SASL drafts, I miss one piece of functionality: >>> To authenticate anonymously, removing any SASL layer, but still >>> providing an unauthenticated ID (e.g. for logging purposes). >>> > How is this different from ANONYMOUS (except for @ sign requirement). That's the difference. If there is nothing special about the '@' character in the underlying auth IDs, then the exclusion of names with '@' in them is unnatural. Though one could of course introduce a private hack like using \ for a quote character and type @ as \40, or something. -- Hallvard From owner-ietf-sasl Thu Nov 6 07:38:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Fc0kT014810 for ; Thu, 6 Nov 2003 07:38:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Fc0xf014809 for ietf-sasl-bks; Thu, 6 Nov 2003 07:38:00 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FbxkT014802 for ; Thu, 6 Nov 2003 07:37:59 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHmCq-0005Ka-1x; Thu, 06 Nov 2003 16:37:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHmCn-0001y8-S5; Thu, 06 Nov 2003 16:37:53 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHmCn-00019w-00; Thu, 6 Nov 2003 16:37:53 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer In-Reply-To: <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:37:53 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 02:58 AM 11/6/2003, Alexey Melnikov wrote: > >> IMHO, there is no point in a layer with a null cipher, it just adds >> unnecessary SASL framing. Unless of course the layer does something >> else. > > It replaces the previous layers. Hallvard wanted a way to do that, > I assume for application protocols which only replace layers (don't > deinstall them). Yes. It was a mistake to mention this in relation to an ANONYMOUS-like auth, though. It belongs in the 'selects no security layer' thread. -- Hallvard From owner-ietf-sasl Thu Nov 6 08:07:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6G7tkT016432 for ; Thu, 6 Nov 2003 08:07:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6G7toF016431 for ietf-sasl-bks; Thu, 6 Nov 2003 08:07:55 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6G7skT016425 for ; Thu, 6 Nov 2003 08:07:54 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 16:09:02 +0000 Message-ID: <3FAA71D7.3090908@isode.com> Date: Thu, 06 Nov 2003 16:07:51 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>rfc2222bis says: >>> >>> >>>>If a security layer is in effect and a subsequent SASL negotiation >>>>selects no security layer, (...) >>>> >>>> >>>Please rephrase as either 'does not select a security layer' (like >>>PLAIN) or '(explicitly) selects that there should be no security layer' >>>(which PLAIN does _not_ do). I presume it's the former. >>> >>> >>No, I actually mean both. >> >> > >Now I'm confused. If a SASL security layer is active and I authenticate >with PLAIN, is the layer removed or not? If it is removed, my first >suggested text above clarifies that. If it is not, my second text. Are >there other alternatives? > Using your own words: PLAIN (implicitly) selects that there should be no security layer, as it is unable to negotiate any. >>DIGEST-MD5 has a mode when you can explicitly >>negotiate no security layer. >> >> > >Where? A search for 'layer' in rfc2831bis-02 only turns up the >reference > > [RFC 2222] Myers, J., "Simple Authentication and Security Layer > (SASL)", RFC 2222, October 1997. > Sections 2.3 and 2.4. Also search for "qop-options" Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 09:01:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6H1lkT019060 for ; Thu, 6 Nov 2003 09:01:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6H1lQx019059 for ietf-sasl-bks; Thu, 6 Nov 2003 09:01:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6H1jkT019051 for ; Thu, 6 Nov 2003 09:01:45 -0800 (PST) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hA6H1fmW031162 for ; Thu, 6 Nov 2003 12:01:41 -0500 Received: from att.com (tony-ob.mt.att.com[135.91.110.124](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031106165844gw100lr6g3e> (Authid: tony); Thu, 6 Nov 2003 16:58:44 +0000 Message-ID: <3FAA7E9E.3080704@att.com> Date: Thu, 06 Nov 2003 12:02:22 -0500 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 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: Section "4.2. Authorization identities and proxy authentication", appears to be mixing two totally different discussions together in a slightly confusing mess. The first discussion is about there being two IDs being passed through the mechanism (the authorization identity and the authentication identity) and how they are used, including what it means for the authorization identity to be empty and non-empty. The second discussion that's intermingled with the first discussion is about the format of the two identities. For example, consider this sentence: While some legacy mechanisms are incapable of transmitting an authorization identity other than the empty string, newly defined mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character). This sentence starts by saying that some legacy mechanisms don't provide an authorization identity, but newly defined mechanisms are expected to. But it never finishes saying that. Instead, it diverts the sentence into discussing what the authorization identity should look like. May I suggest that this section be rewritten so that it focusses on the two topics separately. For example, something like the following below might be considered. Tony Hansen tony@att.com 4.2. Authorization and authentication identities, and proxy authentication SASL authentication deals with two identities: the authorization identity and the authentication identity. The transmitted authorization identity may be an empty string (zero length), but the transmitted authentication identity may not be an empty string. (While some legacy mechanisms are incapable of transmitting an authorization identity other than the empty string, newly defined mechanisms SHOULD be capable of transmiting a non-empty authorization identity.) The authorization identity is used by the server as the primary identity for making access policy decisions. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive the authorization identity from the client's authentication identity. If the authorization identity transmitted during the authentication protocol exchange is not the empty string, this is typically referred to as "proxy authentication". This feature permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. The server makes an implementation defined policy decision as to whether the authentication identity is permitted to have the access privileges of the authorization identity and whether the authorization identity is permitted to receive service. If it is not, the server indicates failure of the authentication protocol exchange. As a client might not have the same information as the server, clients SHOULD NOT themselves try to derive authorization identities from authentication identities when clients could instead transmit an authorization identity of the empty string. The server SHOULD verify the correctness of a received authorization identity. Profiles whose authorization identities are simple user names (e.g. IMAP [RFC 3501]) are encouraged to employ [SASLPrep] profile [SASLPrep] of the "stringprep" algorithm [StringPrep] to prepare these names for matching. If the preparation of the authorization identity fails or results in an empty string, the server MUST fail the authentication exchange. The only exception to this rule is when the received authorization identity is already the empty string. 4.x Authorization Identity and Authentication Identity Formats An authorization identity and an authentication identity are strings of ISO 10646 [ISO-10646] coded characters. The NUL (U+0000) character is not permitted in authorization or authentication identities. The character encoding scheme used for transmitting an authorization identity over a protocol is specified in each authentication mechanism (with the authentication mechanism's blob being further restricted/encoded by the protocol profile). Per IETF character set policy [CHARSET-POLICY], authentication mechanisms SHOULD encode these and other strings in UTF-8 [UTF-8]. Mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character). An authorization identity of the empty string and and an absent authorization identity MUST be treated as equivalent. However, mechanisms SHOULD NOT allow both (i.e. if an authorization identity is allowed to be absent, but one is transferred, it SHOULD NOT be an empty string). From owner-ietf-sasl Thu Nov 6 10:57:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IvKkT024542 for ; Thu, 6 Nov 2003 10:57:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6IvK48024541 for ietf-sasl-bks; Thu, 6 Nov 2003 10:57:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IvDkT024534 for ; Thu, 6 Nov 2003 10:57:14 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA6IvDWj005150; Thu, 6 Nov 2003 13:57:13 -0500 Date: Thu, 6 Nov 2003 13:57:14 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@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: On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > At 02:52 AM 11/6/2003, Alexey Melnikov wrote: > >I would welcome any suggestions to make this clearer. > > I think one of the problems we have adding this profile option > is that the specification is now much more complex and > framework implementations, especially those which support both > options, will need to be much more complex. We need to keep > SASL and the specification of SASL simple. I have to agree with Kurt here. One of the major benefits of SASL is that the framework layer has been historically simple. Allowing both modes (dropping the layer or continuing under the old layer) needlessly complicates the implementation and breaks backwards compatibility for minimal gain. > I don't see the risk from the described threat being so high > to warrant the insertion of this option ESPECIALLY given that > the option doesn't not fully address the vulnerability. The > information sent under the subsequent layers is still contains > information known by those involved in the reauthentication. I tend to agree with this assessment. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 6 13:14:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LEXkT030402 for ; Thu, 6 Nov 2003 13:14:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LEXMT030401 for ietf-sasl-bks; Thu, 6 Nov 2003 13:14:33 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6LEVkT030395 for ; Thu, 6 Nov 2003 13:14:32 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 21:15:38 +0000 Message-ID: <3FAAB9B2.2000206@isode.com> Date: Thu, 06 Nov 2003 21:14:26 +0000 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: Rob Siemborski CC: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> In-Reply-To: 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: Rob Siemborski wrote: >On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > > >>At 02:52 AM 11/6/2003, Alexey Melnikov wrote: >> >> >>>I would welcome any suggestions to make this clearer. >>> >>> >>I think one of the problems we have adding this profile option >>is that the specification is now much more complex and >>framework implementations, especially those which support both >>options, will need to be much more complex. We need to keep >>SASL and the specification of SASL simple. >> >> > >I have to agree with Kurt here. One of the major benefits of SASL is that >the framework layer has been historically simple. Allowing both modes >(dropping the layer or continuing under the old layer) needlessly >complicates the implementation > Which implementation are you talking about? > and breaks backwards compatibility for >minimal gain. > A protocol profile is not allowed to do both. It has to document a choice. This is a checkbox. There is only a single protocol that currently allows for reauthentication. >>I don't see the risk from the described threat being so high >>to warrant the insertion of this option ESPECIALLY given that >>the option doesn't not fully address the vulnerability. >> True. But it is more difficult to implement an attack during reauthentication. And servers should drop connection after some number of failed authentications. >> The >>information sent under the subsequent layers is still contains >>information known by those involved in the reauthentication. >> Actually, I am not sure I understand what are you saying here Kurt. >I tend to agree with this assessment. > > Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Nov 6 13:35:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LZbkT031268 for ; Thu, 6 Nov 2003 13:35:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LZbcl031267 for ietf-sasl-bks; Thu, 6 Nov 2003 13:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-FOURTEEN.MIT.EDU [18.187.5.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LZakT031262 for ; Thu, 6 Nov 2003 13:35:36 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 20FFF15159E; Thu, 6 Nov 2003 16:35:13 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> From: Sam Hartman Date: Thu, 06 Nov 2003 16:35:13 -0500 In-Reply-To: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> (Ienup Sung's message of "Mon, 03 Nov 2003 11:51:56 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Ienup" == Ienup Sung writes: Ienup> I agree that the SASLprep is more suitable and applicable Ienup> for simple user names and passwords and if the additional Ienup> mappings such as the full stops are needed, they are more Ienup> suitable and correct to be done at the outside of any Ienup> Stringprep/Stringprep profiles and most preferrably before Ienup> the application of the Stringprep profile(s). <-- These are Ienup> also my points all along. I think Kurt's point was that since saslprep was for usernames and passwords, it is more appropriate to do full-stop mappings there than in some more general context. Do we expect people to need decimal points in their usernames? Do we think it a problem if someone uses a decimal point in a password, but can later use one of the other full-stop characters and have it work? --Sam From owner-ietf-sasl Thu Nov 6 14:37:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MbnkT033566 for ; Thu, 6 Nov 2003 14:37:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Mbn0H033565 for ietf-sasl-bks; Thu, 6 Nov 2003 14:37:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MbmkT033559 for ; Thu, 6 Nov 2003 14:37:48 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hA6Mbbdo011266; Thu, 6 Nov 2003 15:37:39 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 06 Nov 2003 15:37:32 -0700 From: Lyndon Nerenberg To: Sam Hartman , Ienup Sung cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <2147483647.1068133052@[192.168.42.6]> In-Reply-To: References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: > I think Kurt's point was that since saslprep was for usernames and > passwords, it is more appropriate to do full-stop mappings there than > in some more general context. Do we expect people to need decimal > points in their usernames? firstname.lastname is a very common scheme for forming identifiers, so yes we do need to support decimal points (and their equivalent mappings) in usernames. --lyndon From owner-ietf-sasl Thu Nov 6 14:29:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MTtkT033049 for ; Thu, 6 Nov 2003 14:29:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6MTsuL033048 for ietf-sasl-bks; Thu, 6 Nov 2003 14:29:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MTrkT033042 for ; Thu, 6 Nov 2003 14:29:53 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA6MTsWj009655; Thu, 6 Nov 2003 17:29:54 -0500 Date: Thu, 6 Nov 2003 17:29:54 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <3FAAB9B2.2000206@isode.com> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@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: On Thu, 6 Nov 2003, Alexey Melnikov wrote: > >>I think one of the problems we have adding this profile option > >>is that the specification is now much more complex and > >>framework implementations, especially those which support both > >>options, will need to be much more complex. We need to keep > >>SASL and the specification of SASL simple. > > > >I have to agree with Kurt here. One of the major benefits of SASL is that > >the framework layer has been historically simple. Allowing both modes > >(dropping the layer or continuing under the old layer) needlessly > >complicates the implementation > > Which implementation are you talking about? I'll use the CMU SASL implementation as an example, but I don't think it really matters. Using RFC2222, if you had a re-authentication and the new session didn't have a security layer, you would need to keep the old SASL context around and continue to use it for security layer purposes (from an API standpoint, this sucks, granted). In 2222bis-03, you no longer have to do this, but it breaks LDAP as deployed (which is bad). In your suggested text, there's no longer a set way of handling this -- it varies from protocol to protocol (as long as they allow reauthentication). And its yet another thing that can be gotten wrong in an implementation. In any case though, I suppose this is application layer not framework layer. Due to the related nature of many of the protocols that implement SASL, we often see one product using SASL for many protocols at once (a mail client can implement POP3, IMAP, SMTP, LDAP and IMSP/ACAP without breaking a sweat, and a mail server can come close to twice that). Subtle differences between these protocols can be a nightmare for implementors (just look at how similar the new POP3 and SMTP profiles are, yet how they both have subtle differences). I fear what will happen when we have another protocol that allows reauthentication but does it in a different way from LDAP. Then again, maybe you're right and the benefits of allowing it both ways outweigh the implementation complexity -- especially given the (somewhat inevitable, I think) upcoming "SASL Implementation Recommendations" document. > True. But it is more difficult to implement an attack during > reauthentication. And servers should drop connection after some number > of failed authentications. Are we both talking about the vulnerability discussed at the bottom of section 6.3? I may be misunderstanding the problem -- as I read it, we don't want the initial realm to be able to read traffic going to the newly-authenticated realm. But if the new authentication doesn't have a security layer, how is dropping the old security layer any benefit? We're moving from a tunneled layer (which, granted, can be read/modified by the initial realm) to one that can be read/modified by anyone! I definitely see a win with forcing a change when the new authentication creates a new security layer, but in the absence of a new security layer, I'm not seeing the benefit. > >> The > >>information sent under the subsequent layers is still contains > >>information known by those involved in the reauthentication. > >> > Actually, I am not sure I understand what are you saying here Kurt. Now that I re-read this, I'm not sure it applies to the vulnerability discussed in 6.3. However, it is true that if I know a good deal of the plaintext that you are sending encrypted (e.g. I am a backend server and you are a proxy), I have a huge advantage in trying to break your session key with a client. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 6 14:57:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MvQkT034362 for ; Thu, 6 Nov 2003 14:57:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6MvQCI034361 for ietf-sasl-bks; Thu, 6 Nov 2003 14:57:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-FOURTEEN.MIT.EDU [18.187.5.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MvPkT034356 for ; Thu, 6 Nov 2003 14:57:25 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 3F2C215159E; Thu, 6 Nov 2003 17:56:57 -0500 (EST) To: Lyndon Nerenberg Cc: Ienup Sung , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> <2147483647.1068133052@[192.168.42.6]> From: Sam Hartman Date: Thu, 06 Nov 2003 17:56:57 -0500 In-Reply-To: <2147483647.1068133052@[192.168.42.6]> (Lyndon Nerenberg's message of "Thu, 06 Nov 2003 15:37:32 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> firstname.lastname is a very common scheme for forming Lyndon> identifiers, so yes we do need to support decimal points Lyndon> (and their equivalent mappings) in usernames. But it seems like in this case mapping all the full stops together would be desirable. From owner-ietf-sasl Thu Nov 6 15:34:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6NY3kT035593 for ; Thu, 6 Nov 2003 15:34:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6NY34i035592 for ietf-sasl-bks; Thu, 6 Nov 2003 15:34:03 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6NXwkT035587 for ; Thu, 6 Nov 2003 15:33:58 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6NY0lg048275; Thu, 6 Nov 2003 23:34:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106141242.04a26900@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 15:33:03 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: 'selects no security layer' Cc: ietf-sasl@imc.org In-Reply-To: <3FAAB9B2.2000206@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@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 01:14 PM 11/6/2003, Alexey Melnikov wrote: >Actually, I am not sure I understand what are you saying here Kurt. Part of the problem here is that I am (and maybe others are) having trouble making sense of your scenario. After further examination, I think your text and picture don't match up. The text implies the layers are active between the client and the Realm A server called AA, but your picture implies the layers are active between the client and the middlebox ("proxy/frontend"). If the layers are active between the client and server AA, then the middlebox could not normally insert a re-authenication to server BB without coordination from AA. That is, the middle box would need to know how to decrypt/encrypt the exchanges (before, during, after reauthentication). If AA doesn't trust the middlebox (and its relations with the likes of BB), then AA simply need not provide the secrets to the middlebox necessary to support reauthentication with others. If AA does trust the middlebox, then it implicitly accepts the risk of that trust. If the layers are active between the client and middlebox, the middlebox likely would need cooperation from AA to support reauthentication to BB. (In this case, it would be better to call the middlebox the SASL server and AA and BB "external systems" (not servers).) If AA doesn't trust the middlebox, then it should not cooperate with it. But if it does, even if layers are dropped, it (AA) would be vulnerable to attack from BB because the subsequent exchange (which BB has knowledge of) is protected by those layers. In either case, this risk is quite limited and can be managed as part of the trust relationship between AA and the middlebox. I think these scenarios are part of a larger class of vulnerabilities: attacks from 3rd parties which have limited knowledge of information protected by the SASL. I think this class of vulnerabilities is best addressed by stating a broad security consideration (possibly supported by one or two specific examples). Kurt From owner-ietf-sasl Thu Nov 6 16:28:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA70SdkT037271 for ; Thu, 6 Nov 2003 16:28:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA70Sdfr037270 for ietf-sasl-bks; Thu, 6 Nov 2003 16:28:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA70SckT037265 for ; Thu, 6 Nov 2003 16:28:38 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA70Sc5u016065; Thu, 6 Nov 2003 17:28:39 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA70SUDS005048; Thu, 6 Nov 2003 16:28:30 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNY0013XHBQT5@mpkmail.eng.sun.com>; Thu, 06 Nov 2003 16:28:38 -0800 (PST) Date: Thu, 06 Nov 2003 16:28:38 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNY0013YHBQT5@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: rzDg7/uVrejlQtuahVpKbg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, the POSIX/SUS/XPG specifies that the poratble user names be in the portable file name character set and it includes [A-Za-z._-] with some additional rules. I also have seen many people using the 0x2e in their user names and passwords. And, while I believe I do understand that the SASLprep is intended for simple user names and passowrds at the moment, I believe I'm seeing the full stops vs decimal point issue a bit differently... (and maybe in that way, I'm wrong about it...) I think there will be problems if we treat the Asian full stops as equivalents to the ASCII decimal point/dot/full stop character simply because the Asian full stops are not equivalent to the ASCII decimal points all the time. In other words, Asian people are and will distinguish (almost implicitly) when to use the Asian/ASCII full stops and when to use the decimal point character; if coerced at the protocol level that the Asian full stops are all mapped to the U+002E for all the cases, people will be, sometimes, confused. I do see the pros of convenience but that will, in my opinion, come in with the price of denying the fact that the Asian full stops are only and conditionally equivalent to the U+002E (when the U+002E means the full stop). In other words, by having the general full stop mappings, we are denying the possibility of Asian people using the full stops and decimal points differently in their user names and passwords. I personally can live with such general mappings and so thus many other Asians in my opinion but when we do know about the fact that the characters are different and virtually and practically we are not capable of distinguishing when the two groups of characters can be treated equal or not with the Stringprep and SALSprep, it seems to me that it is not really a good idea to have a generic, simple table-driven mappings at the SASLprep (even for the simple user names and passwords)... Should more opinions needed and if the WG folks agree and assign to me, I can bring this exactly the same question of whether we can treat the Asian full stops as the decimal point to the Unicode Technical Committee and get the opinion of the UTC back to the WGs. With regards, Ienup PS. By the way, on a bit different topic, reading the SALSprep and also the PLAIN mechanism drafts, it appears there is no AllowUnassigned flag setting or mentioning of it in the drafts. Has this issue been discussed and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? If not, it seems either explicitly defining that the unassigned Unicode characters are not allowed in the drafts, or, allow setting of the AllowUnassigned flag as either True or False at the PLAIN draft appears necesary so that the versioning issue is clearly stated... If this question has been asked and answered, sorry, please let me know and I'll scan more of the archived emails. ] Date: Thu, 06 Nov 2003 16:35:13 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> I agree that the SASLprep is more suitable and applicable ] Ienup> for simple user names and passwords and if the additional ] Ienup> mappings such as the full stops are needed, they are more ] Ienup> suitable and correct to be done at the outside of any ] Ienup> Stringprep/Stringprep profiles and most preferrably before ] Ienup> the application of the Stringprep profile(s). <-- These are ] Ienup> also my points all along. ] ] I think Kurt's point was that since saslprep was for usernames and ] passwords, it is more appropriate to do full-stop mappings there than ] in some more general context. Do we expect people to need decimal ] points in their usernames? Do we think it a problem if someone uses a ] decimal point in a password, but can later use one of the other ] full-stop characters and have it work? ] ] --Sam ] From owner-ietf-sasl Thu Nov 6 17:47:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71l9kT039951 for ; Thu, 6 Nov 2003 17:47:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA71l9VM039949 for ietf-sasl-bks; Thu, 6 Nov 2003 17:47:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71l7kT039944 for ; Thu, 6 Nov 2003 17:47:07 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA71l8Wj031547; Thu, 6 Nov 2003 20:47:08 -0500 Date: Thu, 6 Nov 2003 20:47:08 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <6.0.0.22.0.20031106141242.04a26900@127.0.0.1> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@isode.com> <6.0.0.22.0.20031106141242.04a26900@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: On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > If the layers are active between the client and server AA, > then the middlebox could not normally insert a re-authenication to > server BB without coordination from AA. That is, the middle > box would need to know how to decrypt/encrypt the exchanges > (before, during, after reauthentication). If AA doesn't trust > the middlebox (and its relations with the likes of BB), then AA > simply need not provide the secrets to the middlebox necessary > to support reauthentication with others. If AA does trust > the middlebox, then it implicitly accepts the risk of that trust. > > If the layers are active between the client and middlebox, > the middlebox likely would need cooperation from AA to > support reauthentication to BB. (In this case, it would be > better to call the middlebox the SASL server and AA and BB > "external systems" (not servers).) If AA doesn't trust the > middlebox, then it should not cooperate with it. But if it > does, even if layers are dropped, it (AA) would be vulnerable > to attack from BB because the subsequent exchange (which > BB has knowledge of) is protected by those layers. Ah, I think I misunderstood the example slightly [didn't understand how the middlebox was playing with the rest of the system]. However, I still agree with Kurt -- this is a minimal case that can be dismissed with a Security Consideration about the trust relationships involved. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 6 18:21:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA72LLkT041479 for ; Thu, 6 Nov 2003 18:21:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA72LLUc041478 for ietf-sasl-bks; Thu, 6 Nov 2003 18:21:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA72LJkT041473 for ; Thu, 6 Nov 2003 18:21:20 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA72LIBU008619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Nov 2003 21:21:20 -0500 (EST) Message-ID: <3FAB0194.2090808@columbia.edu> Date: Thu, 06 Nov 2003 21:21:08 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNY0013YHBQT5@mpkmail.eng.sun.com> In-Reply-To: <0HNY0013YHBQT5@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020500020203020202030107" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020500020203020202030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The question is not whether or not the different full stops are used by different people in different ways at the user interface level. The transformations we are discussing for use with SASLPrep are specific to the use of the strings as Storage and Query strings; not as Display strings. When a string is to be used as a username or a password is there a reason why we should be concerned with distinguishing the differences? If there is not a good reason to preserve the differences then there is a reasonable argument to fold them similar to the arguments for folding spacing characters. Users will always be free to choose one representation over another. It is only on the wire that there should be a distinction. Jeffrey Altman Ienup Sung wrote: >I think there will be problems if we treat the Asian full stops as equivalents >to the ASCII decimal point/dot/full stop character simply because the Asian >full stops are not equivalent to the ASCII decimal points all the time. >In other words, Asian people are and will distinguish (almost implicitly) when >to use the Asian/ASCII full stops and when to use the decimal point character; >if coerced at the protocol level that the Asian full stops are all >mapped to the U+002E for all the cases, people will be, sometimes, confused. > >I do see the pros of convenience but that will, in my opinion, come in with >the price of denying the fact that the Asian full stops are only and >conditionally equivalent to the U+002E (when the U+002E means the full stop). >In other words, by having the general full stop mappings, we are denying >the possibility of Asian people using the full stops and decimal points >differently in their user names and passwords. > > > --------------ms020500020203020202030107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwNzAyMjEwOFowIwYJKoZIhvcNAQkEMRYEFLTXMmqjlhNl 7TvuiG+w5WeSE8pbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAACslROIT5rqbi2N+JiyjJe7cMXdq FntX0j08ngYKjBwyv0b3OlQBFWcK84uM8+lbJf89qpVRAYElPcZL5/DhGqG8KxR6smuOw6m0 flp60/oOoi68ndqTKHh8meKPhsRJ/3OeHXsFc3j//DR8JOVdDOFwKv0KCesdRxeDNewJ82sF tG9bLkhEk3zPY0vnae5q9lRfmMvte0sRa/XyTj+LoZHBAlRRXIaO3DeRwzpp88gevgff3bG1 MuWGk4L0yr3SQQdfBuupryHTGU0F3+AQH04wVbWl584LUGrK06cCgR9JcaME1bH5/LVBBjYr 0LeVUuGVfrUP3rH1tW35vUXtewAAAAAAAA== --------------ms020500020203020202030107-- From owner-ietf-sasl Fri Nov 7 11:35:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7JZlkT050089 for ; Fri, 7 Nov 2003 11:35:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7JZlBd050088 for ietf-sasl-bks; Fri, 7 Nov 2003 11:35:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7JZkkT050083 for ; Fri, 7 Nov 2003 11:35:46 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA7JZk5u011478; Fri, 7 Nov 2003 12:35:46 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA7JZbDS009564; Fri, 7 Nov 2003 11:35:37 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNZ00IWCYFLIA@mpkmail.eng.sun.com>; Fri, 07 Nov 2003 11:35:46 -0800 (PST) Date: Fri, 07 Nov 2003 11:35:46 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=UTF-8 Content-MD5: cvDLdFlktZQJJSr4KNqsHw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA7JZkkT050084 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually that's exactly the problem that I was also talking about since people will treat the Asian full stops and U+002E differently at Asian countries and when people tried to register a new user account with let say 3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user account system could say, sorry, we already have 3.14 (that is three point one four) which is totally different user account name and would deny the new user account name which will be quite confusing for Asian people. With regards, Ienup ] Date: Thu, 06 Nov 2003 21:21:08 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] The question is not whether or not the different full stops are used by ] different people in different ways at the user interface level. The ] transformations ] we are discussing for use with SASLPrep are specific to the use of the ] strings ] as Storage and Query strings; not as Display strings. When a string is ] to be used ] as a username or a password is there a reason why we should be concerned ] with ] distinguishing the differences? If there is not a good reason to ] preserve the ] differences then there is a reasonable argument to fold them similar to ] the arguments ] for folding spacing characters. ] ] Users will always be free to choose one representation over another. It ] is only ] on the wire that there should be a distinction. ] ] Jeffrey Altman ] ] ] Ienup Sung wrote: ] ] >I think there will be problems if we treat the Asian full stops as equivalents ] >to the ASCII decimal point/dot/full stop character simply because the Asian ] >full stops are not equivalent to the ASCII decimal points all the time. ] >In other words, Asian people are and will distinguish (almost implicitly) when ] >to use the Asian/ASCII full stops and when to use the decimal point character; ] >if coerced at the protocol level that the Asian full stops are all ] >mapped to the U+002E for all the cases, people will be, sometimes, confused. ] > ] >I do see the pros of convenience but that will, in my opinion, come in with ] >the price of denying the fact that the Asian full stops are only and ] >conditionally equivalent to the U+002E (when the U+002E means the full stop). ] >In other words, by having the general full stop mappings, we are denying ] >the possibility of Asian people using the full stops and decimal points ] >differently in their user names and passwords. ] > ] > ] > From owner-ietf-sasl Fri Nov 7 12:16:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KGnkT051434 for ; Fri, 7 Nov 2003 12:16:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7KGniX051433 for ietf-sasl-bks; Fri, 7 Nov 2003 12:16:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KGlkT051427 for ; Fri, 7 Nov 2003 12:16:47 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7KGbB9020077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Nov 2003 15:16:45 -0500 (EST) Message-ID: <3FABFD99.8010107@columbia.edu> Date: Fri, 07 Nov 2003 15:16:25 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> In-Reply-To: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060403050102060802000005" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060403050102060802000005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit It is absolutely a trade off. Avoidance of end user confusion because they could not tell the difference between the full stops and the ability to specify them as different strings. By choosing to fold the full stops we are saying that we believe that there will be more confusion by users who try to use one form of full stop when they should be using another than the confusion which will be caused for system administrators who desire to create accounts which only differ by the type of full stop used. Jeffrey Altman Ienup Sung wrote: >Actually that's exactly the problem that I was also talking about since >people will treat the Asian full stops and U+002E differently at Asian >countries and when people tried to register a new user account with let say >3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user >account system could say, sorry, we already have 3.14 (that is three point >one four) which is totally different user account name and would deny >the new user account name which will be quite confusing for Asian people. > >With regards, > >Ienup > > > --------------ms060403050102060802000005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwNzIwMTYyNVowIwYJKoZIhvcNAQkEMRYEFDu7NOJQKEDW EZbQ0eF75sbu1x+QMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAtV0OcgT6ZT6hqTqs4GWeurOp3c8B BkxBB4DijlFg1gopxa8bCywF8+ZRk0/PuIuXtNkhDVRYhFaZvVfXvEaoD+ByEm4ujhFlpuk3 J3clZTya6lF20bO/4zerMkkm6Kuu0wLc41TySbrf6TZAfhQN4dnqce+xhZHpJp4gigvB8+Cf q8QHohmdwstU0PUHfTpeOoZWrSpk752/JgVFIGg2//p6h8z4vrHumrMnYPICXf4x/RsXsWZ7 XWA0sfw/OERNA9QM757CCBG8HeFS1KvzfSxg6Y98bo19NKKd4QqDFbxbryK7++hI5+73PP/L QD5LcCNP/V1+JPEnpRKYUul3PgAAAAAAAA== --------------ms060403050102060802000005-- From owner-ietf-sasl Fri Nov 7 13:07:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7L79kT052972 for ; Fri, 7 Nov 2003 13:07:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7L78Dp052971 for ietf-sasl-bks; Fri, 7 Nov 2003 13:07:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7L78kT052959 for ; Fri, 7 Nov 2003 13:07:08 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA7L74xA011550; Fri, 7 Nov 2003 13:07:04 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA7L6tDS029035; Fri, 7 Nov 2003 13:06:55 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO000I9V2NRIA@mpkmail.eng.sun.com>; Fri, 07 Nov 2003 13:07:04 -0800 (PST) Date: Fri, 07 Nov 2003 13:07:04 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO000I9W2NSIA@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: multipart/mixed; boundary="Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ) Content-type: TEXT/plain; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE Content-MD5: xiCw1QO9AzRAFXH/mDmrFA== I believe the question is whether to (incorrectly) generalize/map or not in= my opinion. Actually the confusion will also and sure to occur if you map the all full stops to the U+002E since Asian people distinguish the U+002E and the U+300= 2 even without any thinking if you wrongly use the full stops in the place of decimal point. The point that I can make further is that people have been using various Asian codesets/codepages that have different code point values and differen= t input mechanisms for each of those Asian full stops and the ASCII decimal points many years; they see them and use them differently. The NFKC used in SASLprep will map the U+FF0E to the U+002E since they are equivalent and should be normalized. On the other hands, the U+3002 and the U+FF61 are not equivalent to the U+002E but only to themselves, i.e., the U+FF61 will map to the U+3002 after the NFKC. Here is also another practical example: the ATOK is, arguably, the most pop= ular Japanese input system in my understanding. When you use ATOK to input Japanese, what happens is that when you type with numbers, you will get '.' automatically if you press dot key from your keyboard. When a sentense is ending, used by itself alone, or surrounded with non-gidits, the dot key will be interpreted as the ideographic/Asian full-stop of U+3002. In other words, to input ideographic/Asian full stop (U+3002) with number isn't that easy and when that happened, i.e., a user typed in the U+3002 among numbers= , that means it is most definitely not the full stop. Furthermore, you can as= k any Asian people around you if you can use full stop in a number/numeric notation; most likely almost 100% of them will say, No Way. (Also and at the same time, just as for info, Asian people will absolutely accept and tolerate '.' being used in the place of U+3002 iff it is used as the full stop. Usually, formal documents don't use '.' by the way a= s you know.) I also attached a sample screen shot in JPEG showing the ATOK12 based Japanese input with numbers and would like to demonstrate how Asian input system works in the SASL WG meeting at Tuesday. And so once again my suggestion is that the mappings of all full stops shou= ld be done as similary as defined in the IDNA for Internet style domain names but outside and before the SASLprep if such mappings are needed for Interne= t domain style names. With regards, Ienup ] Date: Fri, 07 Nov 2003 15:16:25 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ]=20 ] It is absolutely a trade off. Avoidance of end user confusion because th= ey ] could not tell the difference between the full stops and the ability to ] specify them as different strings. ]=20 ] By choosing to fold the full stops we are saying that we believe that the= re ] will be more confusion by users who try to use one form of full stop when ] they should be using another than the confusion which will be caused for ] system administrators who desire to create accounts which only differ by ] the type of full stop used. ]=20 ] Jeffrey Altman ]=20 ]=20 ] Ienup Sung wrote: ]=20 ] >Actually that's exactly the problem that I was also talking about since ] >people will treat the Asian full stops and U+002E differently at Asian ] >countries and when people tried to register a new user account with let = say ] >3=E3=80=8214 (where it is three, Asian full-stop, and fourteen), the PLA= IN based user ] >account system could say, sorry, we already have 3.14 (that is three poi= nt ] >one four) which is totally different user account name and would deny ] >the new user account name which will be quite confusing for Asian people= . ] > ] >With regards, ] > ] >Ienup ] > ] > =20 ] > --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ) Content-type: IMAGE/jpeg; name=ATOK12-Japanese.jpg; x-unix-mode=0644 Content-transfer-encoding: BASE64 Content-disposition: attachment; filename=ATOK12-Japanese.jpg Content-description: ATOK12-Japanese.jpg Content-MD5: 35UO0f6/F0u2PYtWXN9K+w== /9j/4AAQSkZJRgABAQAAAQABAAD/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFla Y2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/ xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGh scEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4 +fr/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxO QERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhC Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj Y2NjY2P/wAARCABwAUYDABEAAREBAhEB/9oADAMAAAERAhEAPwBn8v8AP+f8 8QcYfy/z/n/PAAfy/wA/5/zwAbU3/IXi/wB5v/RbVK+Iin/GLNh/yFJP+uZ/ 9lprdm8f4kvka1M1CgCOaaOBA8rbVLKgOM8swUD8yKAJKACgCsuoWhklTzlU xAs7MCq4H3iGPBweDjoeDigCzQBC1wi3kdsQ2+SN5Ae2FKg/+hD9aAHTzR21 vJPM22OJS7tjOABkmgCSgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKAOH/wA/5/z/APWDmD/P+f8AP/1gA/z/AJ/z/wDW ANmb/kLxf7zf+i2qV8RFP+MWbD/kKSf9cz/7LTW7N4/xJfIqafYQzfabYQZj mgaJ7o2jQTYOB8zOP3jNySQAMryORVGw9Ee80+5vbttrTLHGPIjaRXVD12jJ ZGZn6dUI6c0CGNZRz6IUOnQCOO6jl2pa+WJFDKXbyj8wO3cuOSQOOoFAw1G3 idLI21qiWCrKDFJp7yKHLLg+UMEHh/mx3P8AeoApanY3g2MsVxLOljGnm7CX LLHOeoJ53iM8E/NtOc4NAF2+tp4r9bqGyyu5ikRDSB3BBGQDhN553fdBUM2W I2gHQ0hHMWNs8ckTR6dL9pXT5UuJNvlGab93keZ1JJB+fpySCcHDGNjsnnst VtY7ZDHPa4hjSya2jMo3ZO1+jcx/NxnAx904ALV7BBJp8I060WG2W53TxtYP tYbCMmLCl/mKdO4B/hoA0tHieHTY0csTliMx+XhSxKgLk7QAQADyBgHHSkIu 0AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAcP 0/z/AJ/z+gcodP8AP+f8/oAHT/P+f8/oAbM3/IXi/wB5v/RbVK+Imn/GLNh/ yFJP+uZ/9lprdm8f4kvkakiJLG0ciq6OCrKwyCD1BFM1CNEijWONVREAVVUY AA6ACgB1AEc00cCB5W2qWVAcZ5ZgoH5kUASUAFABQBSk1jTIpGjk1G0R0JVl adQQR1BGaAJ7a6t7uMyWs8U6A7S0bhgD6ZFAE1AENzdW9pGJLqeKBCdoaRwo J9MmgCCPWNMlkWOPUbR3chVVZ1JJPQAZoAu0AFAEM11BBJFHLIqNKcID37fh yQM+pA6kUATUAFABQAUAQRX1pPcPbw3UEk0ed8aSAsuDg5HUc0APjmjleVEb LQtscY6HaGx+TD86AJKACgCD7bb+T53mfu/N8nOD9/fsx/31xQBPQAUAVk1G zkuTbRXMUk4JDRxsGZcddwHT0ye+B1IoAljmjleVEbLQtscY6HaGx+TD86AJ KACgAoAKACgAoAKACgDh+n+f8/5/QOUOn+f8/wCf0ADp/n/P+f0ANmb/AJC8 X+83/otqlfETT/jFmw/5Ckn/AFzP/stNbs3j/El8ivctNaW+oXFlcTukFrL5 ksrlw0wGQVB4G3DZCgLkgY4IWjULkvaTXNpDNP5R+yfflZ2HmTMj4ZiWGVAH B46jB5oAsQRNJHf2xkunitp8IiTESMPKRtu8nd95ifvDsM44oApOr3NtYrPD FehrmSKOC4bARl83l2w24qq7e4zk5bggGR6fpaPe3qyaJpRRblVb5s+WPLjJ Cjy+eue3JP1oA1mM6+IIQ07GF7aUiIDCjDRcn1PJ59O3UkEFqZxrd6ks7SL5 MTomMKmWlGAPoBk9z6DAABl2n27bP5P9qeX9qnx5H2bZ/rX6b/m/OgY63edL PUN7XCSPqEMbmUoJNrCFTzHwPlJwRyOO9AFn90ltqMdxJdNDaTgRKk7iQ5jQ hQ24MxLOcAnqQPSgQ2eOewi0lXWW6lW7dtiybm5jlO0M5GdoOMkjIH4UAO1K 8nlghR9NuoVN1b5d2iIH75P7rk/pQBtUgM2KP7VqN9MQnnWzCG3Z13CP92GL Adckvg4IyFA7UwMie9mimVQ/mi8by5TPpM5ONjHAGRleCAoHAJJydxIM19Pi F3ZPDdt9qt+FC3Fq6HI5OQ/LDOMHGeOSxyaBEukO76equzOYpJId7HLMEdkB J7khQSfXNICPWTOsNu8U7RKLmEOqjl8yoMZ7DBOR345xkFgJq0bPgQzzi8ZS LZEkKqrD+NgOqjK53ZHAAGWwQDHi85bli7xNEwvlVPsry4BuUDBlVsvn2Ax3 zQMj0+OO01yJYYbcGcmTeNHljaPGxNqkn5QQSSegJOetAGxFE0eqm1Ml15cs Dl2lmJMxynzJg/JjcQcbeWGAccAiO0guWiuJ9OlcRzYSL7RO8mAu7Milt33s jHUYAbn7tAEEtzcxaTfWzaZam0sojDJGLx8lBGGwD5efusB1HP50DLN5ZajN JB86zJEHU4upLcyZ27WOwdRhgR05yMZwARUkvUlkSUC/FnHYw3CSRzYMIbfl nBb5+FHBD9Dwc8gyOKS7uPEGoi2uLhQ0axxSlUZBhpAcgJkbWD4z1Kct8woA sWlvFDdvDAksDC7C27bDkRJFGH64JQ7NueRkqeuDQBpa07xaJfyRsyOltIys pwQQpwQaQjO23T216NNF00W2MxrcvIjuwY+YoaT5lym0A9ATxg5NMBlyIJdA 1CWA6hbzWiy5WW5lDpIEzydxDDG0jkjn3NAzbtrZLWMpG0rAnP7yVpD+bEn8 KQiagAoAKACgDhz36f5/z/nsHKB79P8AP+f89gAPfp/n/P8AnsAbM3/IXi/3 m/8ARbVK+Imn/GLNh/yFJP8Armf/AGWmt2bx/iS+RZttKtLWMxxrK0Rj8vyp J3kTb6bWJHt0pmo5NNtUikj2O4kxuaSVnfjkYYkkYPIweDyOaAD+zbX7P5Ox 8bt+/wA1vM3YxnfndnHGc9OOnFADW0jTXVBLY28pQYDSxh26k8k5J5JJPckm gCCHw9pkctw7WFo4lkDqpt1+QbVGB+IJ/GncLl5bWBJInSNVMMZjj28BVOMg Dp/Cv5UgBoAJJZotq3EkYTewLDjJXIyOhY+n1oALS3S0to4ELMEGNzcsx7sT 3JOST3JNAFa305hFdLeyJO1zKJGMaGMKQqqMfMSCNgOc5z0pgTJp9skHkhGK +YshLOzMzKQQSxOTjaOp6ADpSAbf2s1ybZ7eZIpIJfMBeMuD8jLjAI/vevag CCay1G5EaXF7amNZY5CEtWUna4bGTIcdPSmBpUgK0toTcm5gmaKYx7DwGR8Z 27h14LE8EZzyaAKB0u/82KRby0QxzGcBbV8FirKePM4zuJ4xzz3OWBZtbK5h tGt2u0QcbHt4drKc5JO9n3E9yeeSepoAtwQx21vHBCu2OJQiLnOABgCkATQx zoElXcoZXAzjlWDA/mBQBBcabb3NwZ389ZCoQtFcSR5AJIB2kZ6n86AJIrG0 guHuIbWCOaTO+RIwGbJycnqeaAK8GnNDfpMsiC3hieOKFUOVDFSfmLHgbeAA AAcdqYE1tp9tayF4UYHG1dzswRf7qgnCjgcDA4HoKQDhbtBZJb2RSHy1VI96 lwoGBjGQTx70AV5tN36Y1jFLtjl3CZ3Xczh8lyMEAMSxOcYHpTAsXVnDd7TK HDJna8cjRsAeo3KQccDjpwPSkBHLplnNsDQ7VRQmxGKKyjorKCAy9eDkcn1N ABJazC6nubeZEklijjG+MsF2sxzgEZzv9R0oAktbVbfcxkeaZ8b5ZMbmA6Dg AADPQADknqSSAPnhjubeSCZd0cqlHXOMgjBFABPCs8TROXCt1KOyH81IIoAi XT7YWctrsZopgRJudmZ8jByxOTxxnPQD0oAs0AFABQAUAFAHEfXt/n/P+cBy h9e3+f8AP+cAB9e3+f8AP+cAGxN/yF4v95v/AEW1SviJp/xizYf8hST/AK5n /wBlprdm8f4kvkWV1W0aOWQNL5UUZkaUwOEKjqQ2MN6jBOe1M1Jpb23haVZJ MNEquwwScMSFx6klSABzn6igCrc6vDBZrciG4ZTMkW1oJFb5mAzgrnofTk8d TTAmfUrdIo5G8/8AeZ2oLeQyEDqdmNwHTnGOR6ikA2XVrGKRUe4X5o1kDAEq VOcHcBjsx69FJ6AmgCBdaT7ZLbtC25SVREbMjMDjDLxt3csvOCoLHABphY1K QFa21C2upCkLsTjcu5GUOv8AeUkYYcjkZHI9RQBWutYhSza4hb92ksStJLGy xlWcKWDHAYYJOQSOhpgT/wBpWv2fzt743bNnlN5m7GcbMbs45xjpz05pATwT R3ESyxNuRvbBBHBBB5BB4IPINAEF5JepPCLWFHjP+sLHkfOg45H8JkP1A+hA JLpLttv2SeCLGd3mwmTPpjDLj9aAC1S7Xd9rnglzjb5UJjx65yzZ/SgDJ069 1G4vNRjRYGZZwud7PHDhFBAbA3HPOwBcENkjIywL1vc3ckV1HsglubaUR5yY kfKq2f4ivDY79O2eACjo2oX9zZu0UKXJM8pErSlYgu9sKr4JftghQuOOoxQB pRXUl3aO1vH5U6sY2jn6xkH+IKTnj5gM8gjkZzSAqWN2Hu0jtdS/tONs+acx nyRjhsoAOTxg8nOR905YGtSAKAKV7NPFe6cscirFLMySLtyW/duw57cr/Ln1 ALtAGXcX87arYxWxX7KZnincj7zCNyFU+xU5PrgZ4YBgT6g1xFG8y3cVvbRx lpSYC7gDJJB3Y6dMqfx6UgM+Gz1wos0+pTjftBtkWEtHlgCTJsw2Bk4Cj0BP UsC4s076nYiVWhMlpK8kO/cFbdFxxwcZIz9aANGkBhxXOotf3lxMYoYLcxwv DGslyWONxK4C4yJFGdp6egpga1tcpdRl41lUA4/eRNGfyYA/jSAmoAKACgAo AKACgDiDx/np/n/PsHKB4/z0/wA/59gAPH+en+f8+wBsTf8AIXi/3m/9FtUr 4iaf8Ys2H/IUk/65n/2Wmt2bx/iS+QWllLB5zXMKR2nlMrW0cr3CsPZWUbQB kbVGDu6cCqNRtnZSNpLNJG09xOFIFzIUcKuNgLAEqwA3HHRyxGM0ASLYXTaa 0Mjr5gmSaNGlaQLsZWCmRhuOSp5I43YwQBQA2+sbq8a2uWjQTRK6NEl3JGMM VOfMVQT90cYxz7cgFS+8PzzRiOB4FRbVYFBLAZEUye5xmVe5OAfxLjuW77TL ue4W4iuv3vzKDuKCIEjaQBndjHKnhyeSAqgAjWpAYVjoBjt3trj/AFYtWtRI LiSRmVgASFb5Y/ujgA9ueOXcLlyaC+urfyp1t1KTQuro7HeFkVmJUj5eF4GT 1696AGS6fcC5kuYvKZxdi4jRmKhh5IiIJwcdz0PQevABb0+3e1tdkhUu0kkj beQC7liAe+N2M8Zx0FICzQBi3uqm0vzIttqF1GF8vyobWT5Gzy3ICsDwM54x xnccMAi19bnfG2n6vaZU4lezY4PtgNz35GOKLBYZpd3bWUl8q296kck4eP8A 0OYlh5aAknbnJYNknknnvQBDbXx3z28sN/HE8kjvOtpMHk3OCgUhcjCfKcgE YG08ZoGOsdTi0zTvKTTdQfE8u2KGycbUMjFTyAMYI49+lAEltqDQ29xKYpxe Ty+ayCzuDHwAoUHYD91RzjqScEcUCGrq63l5bzNYalaC3LEtLZuWkBUjYNoP GcMcnqq8HqAZZh1dvtdx50U/2b5fI2WNxv6fNuymOvTFAif+17b/AJ5Xv/gD N/8AEUAVL3UYpbqwdIL0rDOXc/YpuB5Trn7vqw/OgCzJqtu8bKq36EggMtjN lfcZQj86AMaRBE9ilveayY4pizE2BymUcFv9TySW5znO4nrzQM1ru/s7uznt pI78JNG0bFbKbIBGDj5KBFe08QSFo4bzTb9ZMfPNFaSGLOO2QG/8d6+o5osF gvNTjS8gvYra/nMUbxtEtlKGIYqcglQOCg4JHBPPGCAOt9WE9wLmaDULdFUo kBs5STkjLNhSM8cYPAzzzgAFaHU5LXS7YpbX5mMnnXMSWUm7LEuypldv3jjk /dzg5waBk/8AwkLSwSeVpmpQygqq+fZuRycFvlznaOcZGegosKxYtdZVoB9p t7tJQSp22U2GwSAw+U4yMHGTjOKAsXra5S6jLxrKoBx+8iaM/kwB/GkBNQAU AFABQBxPT/8AX0oOUOn/AOvpQAdP/wBfSgDXm/5C8X+83/otqlfETT/jE1tN HBqLvK21dmM4J549KLpM054wqS5n2ND+0bT/AJ7D/vlv8KfMivb0+4f2jaf8 9h/3y3+FHMg9vT7h/aNp/wA9h/3y3+FHMg9vT7h/aNp/z2H/AHy3+FHMg9vT 7h/aNp/z2H/fLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf8APYf98t/h RzIPb0+4f2jaf89h/wB8t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/z2 H/fLf4UcyD29PuH9o2n/AD2H/fLf4UcyD29PuH9o2n/PYf8AfLf4UcyD29Pu H9o2n/PYf98t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/wA9h/3y3+FH Mg9vT7h/aNp/z2H/AHy3+FHMg9vT7h/aNp/z2H/fLf4UcyD29PuH9o2n/PYf 98t/hRzIPb0+4f2jaf8APYf98t/hRzIPb0+4f2jaf89h/wB8t/hRzIPb0+4f 2jaf89h/3y3+FHMg9vT7h/aNp/z2H/fLf4UcyD29PuH9o2n/AD2H/fLf4Ucy D29PuH9o2n/PYf8AfLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf89h/3 y3+FHMg9vT7h/aNp/wA9h/3y3+FHMg9vT7h/aNp/z2H/AHy3+FHMg9vT7h/a Np/z2H/fLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf8APYf98t/hRzIP b0+4f2jaf89h/wB8t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/z2H/fL f4UcyD29PuH9o2n/AD2H/fLf4UcyD29PuH9o2n/PYf8AfLf4UcyD29Pucl+X 50zMPy/OgA/L86ANV48asixIpldmAaSRyASjHOM4/SpW4qb/AHti0LW/MhjE 9kXUBivzZAOcHH4H8jVnZcGtb9GRWnslLnaoO4bjgnA9eAT+FAXA2t+JBGZ7 IOwLBfmyQMZOPxH5igLi/YtR/wCelp+TUBcPsWo/89LT8moC4zybzZv+02Gz ds3ZbG7dtx9c8Y9eKAHLa37s6rPZMUO1gNx2nAOD6cEH8aAuL9i1H/npafk1 AXD7FqP/AD0tPyagLh9i1H/npafk1AXD7FqP/PS0/JqAuH2LUf8Anpafk1AX D7FqP/PS0/JqAuH2LUf+elp+TUBcPsWo/wDPS0/JqAuH2LUf+elp+TUBcPsW o/8APS0/JqAuH2LUf+elp+TUBcPsWo/89LT8moC4fYtR/wCelp+TUBcPsWo/ 89LT8moC4fYtR/56Wn5NQFw+xaj/AM9LT8moC4fYtR/56Wn5NQFw+xaj/wA9 LT8moC4fYtR/56Wn5NQFw+xaj/z0tPyagLh9i1H/AJ6Wn5NQFw+xaj/z0tPy agLh9i1H/npafk1AXD7FqP8Az0tPyagLh9i1H/npafk1AXD7FqP/AD0tPyag Lh9i1H/npafk1AXD7FqP/PS0/JqAuH2LUf8Anpafk1AXD7FqP/PS0/JqAuc/ /P6/Wkcgfz+v1oAP5/X60AbDukWtQySMqIjMzMxwABG2STUr4iaf8UzZ45hq sq2kE+6eKJIBPqE6NkmUhmA5xhWbaSCAOzMRVnabD37pFHC9ip8maKKVJptz DcyhJFODvGTwx2nKnuDgEctcWRGsMhsVUAzhEW0AG0SKFIAt2zxjn5uvVc4L GbSxWiLoqahYK4+wyM0K2ZfbITESdiqdvJPYdaQGjpotxfsNOh+zWyxfvYjE YdzkjawQgEcBwWwM8DJ2/KCMzxB5MX2eKddPuW3MZZZ0j37xsK5BkTkrt3Y6 4HABxQNDPCVxFPe74rXT4jLB5kn2dEV1PyDaAJGO31yF5A7mhgzrKQgoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KAOJz/nP1oOUM/5z9aADP+c/WgDUu7dLvUltpCwSbfGxXqAYmBxUr4iaf8U0 YrCeO8a+eWKa6MLRkeXsU8gqAfmKgfNnrktnsALOwZNp1xcHfJJEs0hR3YAs E8tt0aKOMgMSSTgnnpkbQCkdEzcJL/YOkDarLsEvynJByR5PUY4+poHc0rSx 8qW2m8mC28mKSPyIOUG9lOQcD+76d/zBFgW22/e6V/8AWRLG6kf3SSpB7feb Prx0xygMptGuZVQNO0Mkg33E8VzKCXJOQqggcZAVmzgKAQQKYE1jpD6fdp5M jyWq5CK9zLmIY4G3JVxzgcLgAdTzQBrUgCgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA4r/AD/P3oOUP8/z96AD /P8AP3oAs3epRpqBeJJWaNvldF4zjBx+tTZ3ujNxlzc0WH9vz+lz/wB8Cj3g /e9w/t+f0uf++BR7wfve4q69OWYkzgBDgbOS2R/TdRqUnUs9RP7fn9Ln/vgU e8T+97h/b8/pc/8AfAo94P3vcP7fn9Ln/vgUe8H73uH9vz+lz/3wKPeD973D +35/S5/74FHvB+97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP8A 3wKPeD973D+35/S5/wC+BR7wfve4f2/P6XP/AHwKPeD973D+35/S5/74FHvB +97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP/fAo94P3vcP7fn9 Ln/vgUe8H73uH9vz+lz/AN8Cj3g/e9w/t+f0uf8AvgUe8H73uH9vz+lz/wB8 Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP/fAo94P3vcP7fn9Ln/vgUe8H73uH 9vz+lz/3wKPeD973D+35/S5/74FHvB+97h/b8/pc/wDfAo94P3vcP7fn9Ln/ AL4FHvB+97h/b8/pc/8AfAo94P3vcP7fn9Ln/vgUe8H73uH9vz+lz/3wKPeD 973D+35/S5/74FHvB+97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6 XP8A3wKPeD973D+35/S5/wC+BR7wfve4f2/OOouP++BR7w/3vcrH/PNUWB/z zQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8A PNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/z zQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8A PNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNACMePx9f8A 69AC/n+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dA B+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/ nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB +f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dACMePx9f/r0 Af/Z --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)-- From owner-ietf-sasl Sat Nov 8 15:49:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8NnwkT003457 for ; Sat, 8 Nov 2003 15:49:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA8NnwBL003456 for ietf-sasl-bks; Sat, 8 Nov 2003 15:49:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (m15185e42.tmodns.net [66.94.24.21]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8NnfkT003434 for ; Sat, 8 Nov 2003 15:49:51 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id DD5161515A2; Sat, 8 Nov 2003 18:45:11 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> From: Sam Hartman Date: Sat, 08 Nov 2003 17:11:47 -0500 In-Reply-To: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> (Ienup Sung's message of "Fri, 07 Nov 2003 11:35:46 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Ienup" == Ienup Sung writes: Ienup> Actually that's exactly the problem that I was also talking Ienup> about since people will treat the Asian full stops and Ienup> U+002E differently at Asian countries and when people tried Ienup> to register a new user account with let say 3。14 Ienup> (where it is three, Asian full-stop, and fourteen), the Ienup> PLAIN based user account system could say, sorry, we Ienup> already have 3.14 (that is three point one four) which is Ienup> totally different user account name and would deny the new Ienup> user account name which will be quite confusing for Asian Ienup> people. OK, then why would people use the Asian full stop in domain names? What's different about the world of DNS and the world of user names? Yours in confusion, --Sam From owner-ietf-sasl Sat Nov 8 17:48:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA91mLkT007342 for ; Sat, 8 Nov 2003 17:48:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA91mLkP007341 for ietf-sasl-bks; Sat, 8 Nov 2003 17:48:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA91mKkT007336 for ; Sat, 8 Nov 2003 17:48:20 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA91mMPh020191; Sat, 8 Nov 2003 18:48:22 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA91mLru028547; Sat, 8 Nov 2003 17:48:21 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO200028ACLJP@mpkmail.eng.sun.com>; Sat, 08 Nov 2003 17:48:21 -0800 (PST) Date: Sat, 08 Nov 2003 17:48:21 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO200029ACLJP@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=ISO-8859-1 Content-MD5: RC9tYTcDM4zCLW+l5msq/w== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA91mLkT007337 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As U+002E is used as full stop as label separator (not as decimal point for number representations), the Asian full stops are used as full stop as label separator in the IDNA. The IDNA's full stop mappings on the Internet domain style names are possible and rather desireable for convenience since we know that the full stops in that case are used as label separators and thus safely map the Asian full stops to the U+002E as the full stop. With regards, Ienup ] Date: Sat, 08 Nov 2003 17:11:47 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 8BIT ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> Actually that's exactly the problem that I was also talking ] Ienup> about since people will treat the Asian full stops and ] Ienup> U+002E differently at Asian countries and when people tried ] Ienup> to register a new user account with let say 3。14 ] Ienup> (where it is three, Asian full-stop, and fourteen), the ] Ienup> PLAIN based user account system could say, sorry, we ] Ienup> already have 3.14 (that is three point one four) which is ] Ienup> totally different user account name and would deny the new ] Ienup> user account name which will be quite confusing for Asian ] Ienup> people. ] ] OK, then why would people use the Asian full stop in domain names? ] What's different about the world of DNS and the world of user names? ] ] Yours in confusion, ] ] --Sam ] ] From owner-ietf-sasl Sun Nov 9 10:33:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9IX0kT034093 for ; Sun, 9 Nov 2003 10:33:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9IX0H5034092 for ietf-sasl-bks; Sun, 9 Nov 2003 10:33:00 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9IWwkT034081 for ; Sun, 9 Nov 2003 10:32:59 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AIuMp-00077C-5e for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:32:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AIuMm-0002DF-JT for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:32:52 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIuMm-0004HT-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 19:32:52 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 9 Nov 2003 19:32:52 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: >Alexey Melnikov writes: >> (...) Only a successful reauthentication is able replace/remove the >> previously negotiated security layer. > > Just to make sure it has been mentioned: > > This also means that non-SASL authentication must keep any old SASL > layer. I expect that's intended, including for LDAPv4? Perhaps I should clarify a bit: The current text does not allow protocols - e.g. LDAP - to say that non-SASL authentication (in LDAP, that's "Simple Bind") should remove the layer. If we want protocols to be allowed to specify that, rfc2222bis must say instead something like the protocol profile may specify that authentication by other means than SASL may remove the SASL security layer or if we don't want SASL to 'know about' non-SASL auth at all, that ... the protocol may at any time decide by other means than SASL to remove the security layer BTW, I'm not saying that we should do this. Nor that we shouldn't. I simply want the issue to be deliberately decided rather than defaulted. -- Hallvard From owner-ietf-sasl Sun Nov 9 10:48:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9ImBkT034777 for ; Sun, 9 Nov 2003 10:48:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9ImB6e034776 for ietf-sasl-bks; Sun, 9 Nov 2003 10:48:11 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9ImAkT034771 for ; Sun, 9 Nov 2003 10:48:10 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AIubZ-0000Nf-9u for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:48:09 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AIubX-0007i3-NM for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:48:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIubX-0004Jp-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 19:48:07 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: protocol profile? Date: Sun, 9 Nov 2003 19:48:07 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What is the purpose of the protocol profile? If a protocol spec has something to say about its SASL entities that are not mentioned in section 5 (Protocol profile requirements), should it go in the profile or elsewhere? Could you say something about that in section 5? For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says: 3.3.5. Rules for using SASL security layers If a SASL security layer is negotiated, the client SHOULD discard information about the server fetched prior to the initiation of the SASL negotiation and not obtained through secure mechanisms. If the client is configured to support multiple SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both before and after the SASL security layer is negotiated. (...) Does that belong in the protocol profile? -- Hallvard From owner-ietf-sasl Sun Nov 9 11:32:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9JW4kT036332 for ; Sun, 9 Nov 2003 11:32:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9JW4sr036331 for ietf-sasl-bks; Sun, 9 Nov 2003 11:32:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9JW3kT036326 for ; Sun, 9 Nov 2003 11:32:03 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AIvI1-0003hW-UO for ietf-sasl@imc.org; Sun, 09 Nov 2003 20:32:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AIvHw-0002kj-So for ietf-sasl@imc.org; Sun, 09 Nov 2003 20:31:56 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIvHw-0004Pz-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 20:31:56 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: suggested text about multiple SASL mechanisms Date: Sun, 9 Nov 2003 20:31:56 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I suggest this text is added to rfc2222bis, probably in the Security Considerations. I stole it from draft-ietf-ldapbis-authmeth-08.txt and de-LDAPified it. If the client fetches a list of supported SASL mechanisms from the server and bases its choice of SASL mechanism on the result, it SHOULD fetch that list both before and after the SASL security layer is negotiated. This allows the client to detect active attacks that remove mechanisms from the server's list of supported mechanisms, and allows the client to ensure that it is using the best mechanism supported by both client and server. -- Hallvard From owner-ietf-sasl Sun Nov 9 13:21:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LLGkT039472 for ; Sun, 9 Nov 2003 13:21:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9LLGEN039471 for ietf-sasl-bks; Sun, 9 Nov 2003 13:21:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LLFkT039465 for ; Sun, 9 Nov 2003 13:21:15 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (dyn136-204.ietf58.ietf.org [130.129.136.204]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA9LLEB9018768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 9 Nov 2003 16:21:15 -0500 (EST) Message-ID: <3FAE91C4.8060507@columbia.edu> Date: Sun, 09 Nov 2003 14:13:08 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNY0013YHBQT5@mpkmail.eng.sun.com> In-Reply-To: <0HNY0013YHBQT5@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803040500090503080500" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050803040500090503080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ienup Sung wrote: >PS. By the way, on a bit different topic, reading the SALSprep and also the >PLAIN mechanism drafts, it appears there is no AllowUnassigned flag >setting or mentioning of it in the drafts. Has this issue been discussed >and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? >If not, it seems either explicitly defining that the unassigned Unicode >characters are not allowed in the drafts, or, allow setting of the >AllowUnassigned flag as either True or False at the PLAIN draft appears >necesary so that the versioning issue is clearly stated... If this question >has been asked and answered, sorry, please let me know and I'll scan more of >the archived emails. > > > Whether or not Unassigned Code Points are to be allowed or not is dependent upon how the string being prepared is to be used. As described in RFC 3454 section 7, if the use of the string is for storage in a database then Unassigned Code Points are to be excluded. However, if the string is to be used for the purposed of querying a database, then the string may contain Unassigned Code Points. I do not believe it is required for SASLprep to highlight this distinction. It should however be specified in the protocol documents which utilize string preparation methods constructed within the framework of RFC 3454. Jeffrey Altman --------------ms050803040500090503080500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwOTE5MTMwOFowIwYJKoZIhvcNAQkEMRYEFI9NOnix9ysq hUqqXrZin7LNtgEIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAuAHEn3TM1/ArmrmkyUsgSQ9HWjrN ALmDiwe9M5A5ZbGWFVqNoMyngv7e0r3JQErf/Cv4WHgafjlpeQopEJczvEZQ1OxgBPI9zKcY TJW55/wQgcG9+MhjIIc7yaoMXMmHBoyJJ3YMrD0V9jOH7QrH+YR2r63ai++Oo/OWtVdbnAVj P08sZG2BZOkuMtxN794Nxj6rZOpps4EVnnkaQvQ2sY3N3iG3pU+2U/z52WrjYGfe0p3x6goB ZMxcz4o/eHc/nT+PTWubZ9eum0Z8Y77/Zi+LRiS6CLMNZGJTcyWp5zacQ74SdKR02aAwSIKe crnYFSsKDPNcv31dOxzDFn11egAAAAAAAA== --------------ms050803040500090503080500-- From owner-ietf-sasl Sun Nov 9 13:33:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LXgkT039697 for ; Sun, 9 Nov 2003 13:33:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9LXghF039696 for ietf-sasl-bks; Sun, 9 Nov 2003 13:33:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LXekT039679 for ; Sun, 9 Nov 2003 13:33:41 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA9LXfWj010566; Sun, 9 Nov 2003 16:33:41 -0500 Date: Sun, 9 Nov 2003 16:33:41 -0500 (EST) From: Rob Siemborski To: Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: > If the client fetches a list of supported SASL mechanisms from the > server and bases its choice of SASL mechanism on the result, it > SHOULD fetch that list both before and after the SASL security layer > is negotiated. This allows the client to detect active attacks that > remove mechanisms from the server's list of supported mechanisms, and > allows the client to ensure that it is using the best mechanism > supported by both client and server. Isn't this attack defeated simply by requiring the clients to not pick a mechanism that does not meet their minimum requirements for authentication? There are also currently deployed servers that do not continue to advertise their sasl mechanisms after authentication, since in almost all current protocols it is not valid to issue a second sasl authentication command. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Sun Nov 9 15:42:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NgEkT042962 for ; Sun, 9 Nov 2003 15:42:14 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NgE5F042961 for ietf-sasl-bks; Sun, 9 Nov 2003 15:42:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NgDkT042956 for ; Sun, 9 Nov 2003 15:42:13 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E92B015159D; Sun, 9 Nov 2003 18:42:14 -0500 (EST) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? References: From: Sam Hartman Date: Sun, 09 Nov 2003 18:42:14 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Sun, 9 Nov 2003 19:48:07 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> What is the purpose of the protocol profile? If a Hallvard> protocol spec has something to say about its SASL Hallvard> entities that are not mentioned in section 5 (Protocol Hallvard> profile requirements), should it go in the profile or Hallvard> elsewhere? Could you say something about that in Hallvard> section 5? I believe section 5 is a set of minimum requirements for protocol profiles; you should be able to specify additional details in the profile document. From owner-ietf-sasl Sun Nov 9 15:46:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NkBkT043040 for ; Sun, 9 Nov 2003 15:46:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NkB8t043039 for ietf-sasl-bks; Sun, 9 Nov 2003 15:46:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NkAkT043034 for ; Sun, 9 Nov 2003 15:46:10 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A61E915159D; Sun, 9 Nov 2003 18:46:12 -0500 (EST) To: Tony Hansen Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 References: <3FAA7E9E.3080704@att.com> From: Sam Hartman Date: Sun, 09 Nov 2003 18:46:12 -0500 In-Reply-To: <3FAA7E9E.3080704@att.com> (Tony Hansen's message of "Thu, 06 Nov 2003 12:02:22 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Tony" == Tony Hansen writes: Tony> May I suggest that this section be rewritten so that it Tony> focusses on the two topics separately. For example, Tony> something like the following below might be considered. This section certainly has been a subject of much discussion about clarity here. From owner-ietf-sasl Sun Nov 9 15:44:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NiCkT043002 for ; Sun, 9 Nov 2003 15:44:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NiCKl043001 for ietf-sasl-bks; Sun, 9 Nov 2003 15:44:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NiBkT042996 for ; Sun, 9 Nov 2003 15:44:11 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id EDA7415159D; Sun, 9 Nov 2003 18:44:13 -0500 (EST) To: Rob Siemborski Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: From: Sam Hartman Date: Sun, 09 Nov 2003 18:44:13 -0500 In-Reply-To: (Rob Siemborski's message of "Sun, 9 Nov 2003 16:33:41 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: >> If the client fetches a list of supported SASL mechanisms from >> the server and bases its choice of SASL mechanism on the >> result, it SHOULD fetch that list both before and after the >> SASL security layer is negotiated. This allows the client to >> detect active attacks that remove mechanisms from the server's >> list of supported mechanisms, and allows the client to ensure >> that it is using the best mechanism supported by both client >> and server. Rob> Isn't this attack defeated simply by requiring the clients to Rob> not pick a mechanism that does not meet their minimum Rob> requirements for authentication? No, I wouldn't call that defeated. You get better protection by checking after the fact. Rob> There are also currently deployed servers that do not Rob> continue to advertise their sasl mechanisms after Rob> authentication, since in almost all current protocols it is Rob> not valid to issue a second sasl authentication command. That's why he said SHOULD not MUST;) From owner-ietf-sasl Sun Nov 9 17:36:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA1aekT046275 for ; Sun, 9 Nov 2003 17:36:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA1aelv046274 for ietf-sasl-bks; Sun, 9 Nov 2003 17:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA1adkT046269 for ; Sun, 9 Nov 2003 17:36:39 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id CF5D415159D; Sun, 9 Nov 2003 20:36:37 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HO200029ACLJP@mpkmail.eng.sun.com> From: Sam Hartman Date: Sun, 09 Nov 2003 20:36:37 -0500 In-Reply-To: <0HO200029ACLJP@mpkmail.eng.sun.com> (Ienup Sung's message of "Sat, 08 Nov 2003 17:48:21 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Ienup" == Ienup Sung writes: Ienup> As U+002E is used as full stop as label separator (not as Ienup> decimal point for number representations), the Asian full Ienup> stops are used as full stop as label separator in the IDNA. Ienup> The IDNA's full stop mappings on the Internet domain style Ienup> names are possible and rather desireable for convenience Ienup> since we know that the full stops in that case are used as Ienup> label separators and thus safely map the Asian full stops Ienup> to the U+002E as the full stop. Ienup> With regards, You believe there is not a similar convenience issue in usernames? From owner-ietf-sasl Sun Nov 9 22:26:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA6QikT058099 for ; Sun, 9 Nov 2003 22:26:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA6Qiwi058098 for ietf-sasl-bks; Sun, 9 Nov 2003 22:26:44 -0800 (PST) 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.10/8.12.8) with ESMTP id hAA6QhkT058093 for ; Sun, 9 Nov 2003 22:26:43 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AJ5Va-0006ZF-LL; Mon, 10 Nov 2003 07:26:42 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AJ5VY-0003y8-4g; Mon, 10 Nov 2003 07:26:40 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJ5VX-00069p-00; Mon, 10 Nov 2003 07:26:39 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sam Hartman Cc: Rob Siemborski , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Nov 2003 07:26:39 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Rob" == Rob Siemborski writes: > > Rob> There are also currently deployed servers that do not > Rob> continue to advertise their sasl mechanisms after > Rob> authentication, since in almost all current protocols it is > Rob> not valid to issue a second sasl authentication command. > > That's why he said SHOULD not MUST;) Well, it would have been if I had thought of it... I guess I should have put an 'if possible' in there somewhere. -- Hallvard From owner-ietf-sasl Sun Nov 9 23:10:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA7AUkT059886 for ; Sun, 9 Nov 2003 23:10:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA7AU8m059885 for ietf-sasl-bks; Sun, 9 Nov 2003 23:10:30 -0800 (PST) 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.10/8.12.8) with ESMTP id hAA7ATkT059880 for ; Sun, 9 Nov 2003 23:10:29 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AJ6Bx-0002tt-LJ; Mon, 10 Nov 2003 08:10:29 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AJ6Br-0001gQ-2m; Mon, 10 Nov 2003 08:10:23 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJ6Bq-0006HE-00; Mon, 10 Nov 2003 08:10:22 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Nov 2003 08:10:22 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I believe section 5 is a set of minimum requirements for protocol > profiles; you should be able to specify additional details in the > profile document. OK, but why would I - or why would I not? What belongs in the protocol profile? -- Hallvard From owner-ietf-sasl Mon Nov 10 08:51:42 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGpgkT081328 for ; Mon, 10 Nov 2003 08:51:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAGpgEV081327 for ietf-sasl-bks; Mon, 10 Nov 2003 08:51:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGpfkT081322 for ; Mon, 10 Nov 2003 08:51:41 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAGpe5u026011; Mon, 10 Nov 2003 09:51:41 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAAGpVDS018921; Mon, 10 Nov 2003 08:51:31 -0800 (PST) Received: from unknown (vpn-129-150-20-204.SFBay.Sun.COM [129.150.20.204]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO50089KAU3KX@mpkmail.eng.sun.com>; Mon, 10 Nov 2003 08:51:40 -0800 (PST) Date: Mon, 10 Nov 2003 07:54:51 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO50089LAU4KX@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: BYCz81EfVfXsql4UdlhwOg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In my opinion, yes,that's correct and especially for user names and passwords. With regards, Ienup ] Date: Sun, 09 Nov 2003 20:36:37 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on frigga.ctd.anl.gov ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> As U+002E is used as full stop as label separator (not as ] Ienup> decimal point for number representations), the Asian full ] Ienup> stops are used as full stop as label separator in the IDNA. ] ] Ienup> The IDNA's full stop mappings on the Internet domain style ] Ienup> names are possible and rather desireable for convenience ] Ienup> since we know that the full stops in that case are used as ] Ienup> label separators and thus safely map the Asian full stops ] Ienup> to the U+002E as the full stop. ] ] Ienup> With regards, ] ] You believe there is not a similar convenience issue in usernames? ] ] ] From owner-ietf-sasl Mon Nov 10 09:09:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH9XkT082275 for ; Mon, 10 Nov 2003 09:09:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAH9X45082274 for ietf-sasl-bks; Mon, 10 Nov 2003 09:09:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH9WkT082268 for ; Mon, 10 Nov 2003 09:09:32 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAH9V5u005289; Mon, 10 Nov 2003 10:09:31 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAAH9Vru017221; Mon, 10 Nov 2003 09:09:31 -0800 (PST) Received: from unknown (vpn-129-150-20-204.SFBay.Sun.COM [129.150.20.204]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO50080TBNUKX@mpkmail.eng.sun.com>; Mon, 10 Nov 2003 09:09:31 -0800 (PST) Date: Mon, 10 Nov 2003 08:12:42 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO50080UBNUKX@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: pV+zF7NBQ4144jebQniLiQ== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is an explicit flag value that need to be given to the SASLprep and any other Stringprep profile to be more specific. Otherwise, people will be confused and wondering what to do with it on the Unicode version issues and also whether and how to use query string vs. storage string (for simple user names and passwords). Especially, having some version related remarks or at least explicitly giving the flag and also mark the flag with a reference would greatly help people, e.g., "SASLprep(authcid, AllowUnassigned)" or "SASLprep(passwd, AllowUnassigned)" since the flag processing would/better need to be done at the Stringprep protocol processing. With regards, Ienup ] Date: Sun, 09 Nov 2003 14:13:08 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on frigga.ctd.anl.gov ] ] Ienup Sung wrote: ] ] >PS. By the way, on a bit different topic, reading the SALSprep and also the ] >PLAIN mechanism drafts, it appears there is no AllowUnassigned flag ] >setting or mentioning of it in the drafts. Has this issue been discussed ] >and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? ] >If not, it seems either explicitly defining that the unassigned Unicode ] >characters are not allowed in the drafts, or, allow setting of the ] >AllowUnassigned flag as either True or False at the PLAIN draft appears ] >necesary so that the versioning issue is clearly stated... If this question ] >has been asked and answered, sorry, please let me know and I'll scan more of ] >the archived emails. ] > ] > ] > ] Whether or not Unassigned Code Points are to be allowed or not is ] dependent upon ] how the string being prepared is to be used. As described in RFC 3454 ] section 7, ] if the use of the string is for storage in a database then Unassigned ] Code Points ] are to be excluded. However, if the string is to be used for the ] purposed of ] querying a database, then the string may contain Unassigned Code Points. ] ] I do not believe it is required for SASLprep to highlight this ] distinction. ] It should however be specified in the protocol documents which utilize ] string ] preparation methods constructed within the framework of RFC 3454. ] ] Jeffrey Altman ] ] From owner-ietf-sasl Tue Nov 11 03:05:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABB5PkT094235 for ; Tue, 11 Nov 2003 03:05:25 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABB5ON6094234 for ietf-sasl-bks; Tue, 11 Nov 2003 03:05:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hABB5HkT094226 for ; Tue, 11 Nov 2003 03:05:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 11:06:35 +0000 Message-ID: <3FB0C25E.6000501@isode.com> Date: Tue, 11 Nov 2003 11:05:02 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? References: In-Reply-To: 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: Hallvard B Furuseth wrote: >What is the purpose of the protocol profile? If a protocol spec has >something to say about its SASL entities that are not mentioned in >section 5 (Protocol profile requirements), should it go in the profile >or elsewhere? Could you say something about that in section 5? > >For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says: > > 3.3.5. Rules for using SASL security layers > > If a SASL security layer is negotiated, the client SHOULD discard > information about the server fetched prior to the initiation of the > SASL negotiation and not obtained through secure mechanisms. > > If the client is configured to support multiple SASL mechanisms, it > SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both > before and after the SASL security layer is negotiated. (...) > >Does that belong in the protocol profile? > IMHO, this kind of information does belong to a protocol profile document. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Tue Nov 11 11:23:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJN5kT016658 for ; Tue, 11 Nov 2003 11:23:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABJN5n0016657 for ietf-sasl-bks; Tue, 11 Nov 2003 11:23:05 -0800 (PST) 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.10/8.12.8) with ESMTP id hABJN3kT016651 for ; Tue, 11 Nov 2003 11:23:04 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 19:24:35 +0000 Message-ID: <3FB13714.7020602@isode.com> Date: Tue, 11 Nov 2003 19:23:00 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Alexey Melnikov writes: >>> >>>>Whether Simple bind removes or keep a previous security layer has >>>>nothing to do with SASL, this is very LDAP specific. >>>> >>>> >>>If SASL allowed LDAP to do so, it would be LDAP specific. >>> >>> >>SASL can't (and must not) document something it is not aware of. SASL >>doesn't have no be aware about Simple bind. >> >> > >Your text does document that anything else than SASL authentication - >and therefore also Simple Bind - may not remove the SASL security layer. > I am not sure that I wrote this anywhere in the document. Anyway, even if I did, that wasn't the intent. >Even though it's not aware of Simple Bind. All it is aware of is that >whatever Simple Bind is, it's not SASL. > > >>Simple bind is NOT SASL PLAIN, >> >> > >I know. That's why I brought it up. > > > >>>It doesn't, so it isn't. >>> >>> >>Why? >> >> > >Maybe I should start over. > >I did not say that SASL should say whether or not LDAP Simple Bind >should remove the layer. I said that the current text does not allow >_LDAP_ to say that Simple Bind should remove the layer. If we want LDAP >- or other protocols - to be _allowed_ to specify that something like >non-SASL Simple Bind should remove the layer, rfc2222bis must say >instead something like > > the protocol profile may specify that authentication by other means > than SASL may remove the SASL security layer > >or if you don't want SASL to 'know about' non-SASL auth, that > > ... the protocol may at any time decide by other means than SASL to > remove the security layer > >BTW, I'm not saying that we should do this. Nor that we shouldn't. >I simply wanted the issue to be deliberately decided rather than >defaulted. That's all. > > IMHO, something that is not explicitly prohibited is allowed. If the WG feels that this issue should be addressed, I will add some clarifying text. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Tue Nov 11 12:07:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABK73kT018762 for ; Tue, 11 Nov 2003 12:07:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABK73eV018761 for ietf-sasl-bks; Tue, 11 Nov 2003 12:07:03 -0800 (PST) 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.10/8.12.8) with ESMTP id hABK71kT018747 for ; Tue, 11 Nov 2003 12:07:02 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AJemu-000556-6a; Tue, 11 Nov 2003 21:06:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AJems-0002Qx-MU; Tue, 11 Nov 2003 21:06:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJems-0003sl-00; Tue, 11 Nov 2003 21:06:54 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FB13714.7020602@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 11 Nov 2003 21:06:54 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >> Your text does document that anything else than SASL authentication - >> and therefore also Simple Bind - may not remove the SASL security layer. > > I am not sure that I wrote this anywhere in the document. > Anyway, even if I did, that wasn't the intent. You are right, it's not in the document. It's in two explanatory messages from you in this thread: Date: Wed, 15 Oct 2003 12:52:04 +0100 Message-ID: <3F8D34E4.4020607@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html "No, the layer can only be cancelled/replaced after a subsequent authentication completes successfully." and Date: Sat, 01 Nov 2003 14:22:06 +0000 Message-ID: <3FA3C18E.8010101@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html "Only a successful reauthentication is able replace/remove the previously negotiated security layer." > If the WG feels that this issue should be addressed, I will add some > clarifying text. Well, I at least think it should be clarified. -- Hallvard From owner-ietf-sasl Tue Nov 11 12:23:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKNrkT019588 for ; Tue, 11 Nov 2003 12:23:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKNrAY019587 for ietf-sasl-bks; Tue, 11 Nov 2003 12:23:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (Ketorin.ietf58.ietf.org [130.129.134.235] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKNqkT019582 for ; Tue, 11 Nov 2003 12:23:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id CBA0415159D; Tue, 11 Nov 2003 15:23:52 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , SASL WG Subject: Re: Replacing a SASL security layer References: From: Sam Hartman Date: Tue, 11 Nov 2003 15:23:52 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Thu, 6 Nov 2003 00:46:30 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd like to second the lack of understanding here. I have asked several people to explain this attack to me and so far have failed to understand it. Hopefully we'll be able to clarify during the meeting today. From owner-ietf-sasl Tue Nov 11 12:39:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKdJkT020214 for ; Tue, 11 Nov 2003 12:39:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKdJM7020213 for ietf-sasl-bks; Tue, 11 Nov 2003 12:39:19 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKdHkT020203 for ; Tue, 11 Nov 2003 12:39:18 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 20:40:51 +0000 Message-ID: <3FB148F3.60307@isode.com> Date: Tue, 11 Nov 2003 20:39:15 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Your text does document that anything else than SASL authentication - >>>and therefore also Simple Bind - may not remove the SASL security layer. >>> >>> >>I am not sure that I wrote this anywhere in the document. >>Anyway, even if I did, that wasn't the intent. >> >> > >You are right, it's not in the document. It's in two explanatory >messages from you in this thread: > > Date: Wed, 15 Oct 2003 12:52:04 +0100 > Message-ID: <3F8D34E4.4020607@isode.com> > URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html > > "No, the layer can only be cancelled/replaced after a subsequent > authentication completes successfully." > >and > > Date: Sat, 01 Nov 2003 14:22:06 +0000 > Message-ID: <3FA3C18E.8010101@isode.com> > URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html > > "Only a successful reauthentication is able replace/remove the > previously negotiated security layer." > I was thinking specifically about SASL [re]authentication when writing this. My point was that a failed reauthentication didn't remove a previously negotiated security layer. This should apply to non-SASL reauthentications as well. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Tue Nov 11 12:35:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKZ2kT020066 for ; Tue, 11 Nov 2003 12:35:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKZ2XS020065 for ietf-sasl-bks; Tue, 11 Nov 2003 12:35:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKZ0kT020060 for ; Tue, 11 Nov 2003 12:35:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 20:36:37 +0000 Message-ID: <3FB147F5.3070902@isode.com> Date: Tue, 11 Nov 2003 20:35:01 +0000 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: [Fwd: Keeping/dropping existing SASL security layer] 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: Hopefully this clarifies things. -------- Original Message -------- Subject: Keeping/dropping existing SASL security layer Date: Tue, 11 Nov 2003 11:52:48 +0000 From: Alexey Melnikov To: Rob Siemborski The order of events is as follows (I will reference "Encryption endpoint box" as CC server): 1) The client connects to CC in order to request a resource FOO. 2) CC looks up its database to figure which server is managing FOO. It turns out to be server AA. 3). The client authenticates to AA (traffic is passing through CC). The client and AA negotiate a security layer. Upon successful negotiation both ends have pointers to two function (encode/decode) and associated keys. After that there might be 2 variations: a). AA does encoding/decoding itself or b). AA passes encode/decode functions and associated state to CC. (CC is trusted) 4). The client exchanges some information with AA (regarding resource FOO), the exchange is recorded by BB (but at this stage BB can't decode it) Than in case a): 5). The client requests access to resource BAR. Server AA decodes request and notifies CC about request to BAR. 6). CC looks up its database and determines that resource BAR is managed by BB. 7). The client reauthenticates to BB (encrypted traffic is going to AA through CC, than cleartext traffic is going from AA to BB through CC), it negotiates no security layer. When the reauthentication is complete, the old layer is used. 8). The client requests access to resource BAR on the server BB (traffic flow is the same as in 7). 9). Evil server BB instead of responding to request BAR returns specially crafted response in order to verify some guesses about previously recorded data exchange between the client and AA. The response is traveling in clear from BB to AA (through CC), server AA encrypts the response and sends it to the client (through CC). The evil BB records the encrypted version of its response and by analyzing it, BB can try to break the previously recorded exchange between the client and AA. or in case b): 5). The client requests access to resource BAR. Server CC decodes request. 6). CC looks up its database and determines that resource BAR is managed by BB. 7). The client reauthenticates to BB (encrypted traffic is going to CC, than cleartext traffic is going from CC to BB), it negotiates no security layer. When the reauthentication is complete, the old layer is used. 8). The client requests access to resource BAR on the server BB (traffic flow is the same as in 7). 9). Evil server BB instead of responding to request BAR returns specially crafted response in order to verify some guesses about previously recorded data exchange between the client and AA. The response is traveling in clear from BB to CC, server CC encrypts the response and sends it to the client. The evil BB records the encrypted version of its response and by analyzing it, BB can try to break the previously recorded exchange between the client and AA. (I think both cases are equivalent). I am not a security export, but I think this attack allows for "CBC mode attack". TLS is being revised (TLS 1.1) to deal with this issue. Alexey -- Alexey Melnikov __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Tue Nov 11 13:24:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABLOwkT022035 for ; Tue, 11 Nov 2003 13:24:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABLOwrC022033 for ietf-sasl-bks; Tue, 11 Nov 2003 13:24:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hABLOukT022020 for ; Tue, 11 Nov 2003 13:24:57 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AJg0I-0003yW-GR; Tue, 11 Nov 2003 22:24:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AJg0E-0001mt-G1; Tue, 11 Nov 2003 22:24:46 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJg0D-00043k-00; Tue, 11 Nov 2003 22:24:45 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FB148F3.60307@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> <3FB148F3.60307@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 11 Nov 2003 22:24:45 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >> "Only a successful reauthentication is able replace/remove the >> previously negotiated security layer." > > I was thinking specifically about SASL [re]authentication when writing > this. My point was that a failed reauthentication didn't remove a > previously negotiated security layer. Oh. So... server and client may at any time agree to remove the security layer, _except_ after failed reauthentication? > This should apply to non-SASL reauthentications as well. Except that in the message you quoted a few messages ago, you didn't want SASL to know about non-SASL reauthentications, so it shouldn't say anything about them. -- Hallvard From owner-ietf-sasl Wed Nov 12 07:17:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFHPkT029460 for ; Wed, 12 Nov 2003 07:17:25 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACFHPft029459 for ietf-sasl-bks; Wed, 12 Nov 2003 07:17:25 -0800 (PST) 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.10/8.12.8) with ESMTP id hACFHOkT029453 for ; Wed, 12 Nov 2003 07:17:24 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AJwkD-0002G8-AQ; Wed, 12 Nov 2003 16:17:21 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AJwk8-000846-BG; Wed, 12 Nov 2003 16:17:16 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJwk7-0006l9-00; Wed, 12 Nov 2003 16:17:15 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Siemborski Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Nov 2003 16:17:15 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > I'd be much happier either not adding this, or adding it as a "clients MAY > want to do this to detect MITM attacks" Fine by me. I don't feel strongly about it, I just saw it in LDAP and thought it might be a good idea. -- Hallvard From owner-ietf-sasl Wed Nov 12 07:36:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFafkT030212 for ; Wed, 12 Nov 2003 07:36:41 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACFafkR030211 for ietf-sasl-bks; Wed, 12 Nov 2003 07:36:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFadkT030204 for ; Wed, 12 Nov 2003 07:36:39 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hACF2DWj011542; Wed, 12 Nov 2003 10:02:13 -0500 Date: Wed, 12 Nov 2003 10:02:13 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 9 Nov 2003, Sam Hartman wrote: > Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: > > >> If the client fetches a list of supported SASL mechanisms from > >> the server and bases its choice of SASL mechanism on the > >> result, it SHOULD fetch that list both before and after the > >> SASL security layer is negotiated. This allows the client to > >> detect active attacks that remove mechanisms from the server's > >> list of supported mechanisms, and allows the client to ensure > >> that it is using the best mechanism supported by both client > >> and server. > > Rob> Isn't this attack defeated simply by requiring the clients to > Rob> not pick a mechanism that does not meet their minimum > Rob> requirements for authentication? > > No, I wouldn't call that defeated. You get better protection by > checking after the fact. I know we briefly discussed this in the meeting yesterday and we left it as "probably ok, with some modifications to the text"... I think for me to be happy with the addition of the text, it would need to both have the "if possible" fix, and a clarification that if a server advertises NO mechanisms after authentication, or the protocol does not support fetching capabilities after authentication -- as is the case with MUPDATE (though granted, it isn't standards track), then it MUST NOT act as if a MITM attack was detected. But I'm still unclear why this is necessary when: a) it most likely adds an extra round trip to the authentication process b) it may not even work with all protocols/implementations -- so that round trip will be wasted What are we trying to prevent here, exactly? The scenario where it applies seems to be something along the lines of: The server advertises GSSAPI and DIGEST-MD5. The client, for whatever reason, decides only GSSAPI (with privacy layer) is secure enough for it. The attacker edits the advertised capabilites and removes GSSAPI, the client sees that the server only supports DIGEST-MD5. I argue that the client should fail the authentication here and not even try to authenticate -- the MITM attack has been defeated. If instead it authenticates, then that implies that it is okay with using DIGEST-MD5. Even if it later discovers that GSSAPI was available, it should be ok with using DIGEST for the session -- what is it going to tell the user "uh, I sent your credentials with a mechanism you didn't want to use, and guess what -- there's an attack in progress!". Sure, the protection may be "better" (as in, you can detect that an attack is in progress), but the costs are high (additional round trip, it might not work anyway) for what seems to me to be a very small gain. I'd be much happier either not adding this, or adding it as a "clients MAY want to do this to detect MITM attacks" -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Nov 13 12:45:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKjNkT077303 for ; Thu, 13 Nov 2003 12:45:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKjNRs077302 for ietf-sasl-bks; Thu, 13 Nov 2003 12:45:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn131-176.ietf58.ietf.org [130.129.131.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKjLkT077297 for ; Thu, 13 Nov 2003 12:45:22 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A183215159D; Thu, 13 Nov 2003 15:45:03 -0500 (EST) To: Russ Housley Cc: smb@research.att.com, kurt@openldap.org, hartmans@mit.edu, ietf-sasl@imc.org Subject: Summary for SASL References: <5.2.0.9.2.20031110115446.043e7508@mail.binhost.com> From: Sam Hartman In-Reply-To: <5.2.0.9.2.20031110115446.043e7508@mail.binhost.com> (Russ Housley's message of "Mon, 10 Nov 2003 11:54:54 -0500") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) Date: Thu, 13 Nov 2003 15:45:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SASL working group met for one hour Tuesday. As part of successful SASL authentication, you can set up a channel security layer. If you later have another successful authentication, the security layer remains in place even if the new SASL mechanism does not negotiate a security layer. The There was some concern that this might create problems for distributed server implementations where two components trust each other, but do not trust a third component. The rough consensus of the working group was not to make this change. we had significant discussion of issues surrounding our stringprep profile saslprep. First, we discussed whether we wanted to map all full stop characters to the ASCII full stop character. We also discussed whether we would allow private use characters. The working group failed to reach consensus on these issues at the session. We had a presentation on implementation problems with SMTP authentication. We expect to be making various changes in our specifications to make them more clear. The incorrect behavior is already a violation of the existing specs but there is a desire to add better examples. Alexey Melnikov has agreed to edit the GSSAPI mechanism draft because the previous editor has not had time to edit the document. We expect an initial submission shortly after this meeting. The chairs will get new milestones to the ADs shortly after the meeting. We hope to be done with base, saslprep, plain and anonymous by the end of the year. From owner-ietf-sasl Thu Nov 13 12:54:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKs9kT077769 for ; Thu, 13 Nov 2003 12:54:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKs9DD077768 for ietf-sasl-bks; Thu, 13 Nov 2003 12:54:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn131-176.ietf58.ietf.org [130.129.131.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKs8kT077763 for ; Thu, 13 Nov 2003 12:54:09 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1E50C15159D; Thu, 13 Nov 2003 15:53:49 -0500 (EST) To: ietf-sasl@imc.org Subject: ID Nit: Internet drafts cannot expire in six monthse Message-Id: <20031113205349.1E50C15159D@konishi-polis.mit.edu> Date: Thu, 13 Nov 2003 15:53:49 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. Just a reminder that Internet draft formatting requirements do not allow you to say that the draft you are submitting expires in six months; instead you are requested to include an explicit date. I believe that this is a useful requirement even though it is not enforced. IT makes it more clear whether a draft is expired if it escapes from the ID repository and is used in another context. If it is easy for you to have a real expiration date, please do so. From owner-ietf-sasl Thu Nov 13 12:56:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKuRkT077926 for ; Thu, 13 Nov 2003 12:56:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKuRZa077925 for ietf-sasl-bks; Thu, 13 Nov 2003 12:56:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKuMkT077907 for ; Thu, 13 Nov 2003 12:56:24 -0800 (PST) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id hADKuJcm015615 for ; Thu, 13 Nov 2003 13:56:24 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HOB0045A65UCO@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Thu, 13 Nov 2003 13:56:19 -0700 (MST) Received: from dyn132-212.ietf58.ietf.org ([130.129.132.212]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HOB00F4365SJG@mail.sun.net> for ietf-sasl@imc.org; Thu, 13 Nov 2003 13:56:18 -0700 (MST) Date: Thu, 13 Nov 2003 14:56:16 -0600 From: Chris Newman Subject: CRAM-MD5 missing security consideration To: lyndon@orthanc.ab.ca Cc: ietf-sasl@imc.org Message-id: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b9 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: CRAM-MD5 does not authenticate the server and does not include a client-supplied nonce. As a result, it is possible to construct a server with a fixed challenge string that has pre-computed the hashes for all possible passwords up to a certain length (or from a dictionary). Such a server could then immediately determine the user's password if it is sufficiently short. - Chris From owner-ietf-sasl Fri Nov 14 16:00:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF00BkT046359 for ; Fri, 14 Nov 2003 16:00:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF00Buk046358 for ietf-sasl-bks; Fri, 14 Nov 2003 16:00:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF007kT046349 for ; Fri, 14 Nov 2003 16:00:10 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hAF006NN011142; Fri, 14 Nov 2003 17:00:07 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 14 Nov 2003 17:00:01 -0700 From: Lyndon Nerenberg To: Chris Newman cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 missing security consideration Message-ID: <2147483647.1068829201@[192.168.42.6]> In-Reply-To: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> References: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Thanks Chris, I've added the text. I will push a new (and final I hope) draft next week. --lyndon From owner-ietf-sasl Fri Nov 14 20:25:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4PHkT060609 for ; Fri, 14 Nov 2003 20:25:17 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4PH9C060608 for ietf-sasl-bks; Fri, 14 Nov 2003 20:25:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (mcb185e42.tmodns.net [66.94.24.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4OxkT060567 for ; Fri, 14 Nov 2003 20:25:08 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2AB8415159D; Fri, 14 Nov 2003 23:24:50 -0500 (EST) To: ietf-sasl@imc.org Subject: consensus call on full stop and private use for saslprep From: Sam Hartman Date: Fri, 14 Nov 2003 22:00:57 -0500 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It was fairly obvious at Tuesday's meeting that we did not have a rough consensus to change the saslprep document either to map full stops to ASCII full stop or to allow private use characters. The saslprep document has already passed working group last call. AS such, there is a relatively high bar to propose changes to the document from within the working group. Since there is no consensus to change the document, the document will remain as is for now. I realize several people are still actively thinking about these issues and people are still looking at what actual input methods do in various situations. If this ongoing discussion reaches a consensus before the documents are sent to the IESG, then we can act on that consensus. Thanks, --Sam From owner-ietf-sasl Fri Nov 14 20:25:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4PLkT060627 for ; Fri, 14 Nov 2003 20:25:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4PL8s060626 for ietf-sasl-bks; Fri, 14 Nov 2003 20:25:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (mcb185e42.tmodns.net [66.94.24.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4P1kT060568 for ; Fri, 14 Nov 2003 20:25:08 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6231015159F; Fri, 14 Nov 2003 23:24:50 -0500 (EST) To: Rob Siemborski Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: From: Sam Hartman Date: Fri, 14 Nov 2003 22:16:15 -0500 In-Reply-To: (Rob Siemborski's message of "Wed, 12 Nov 2003 10:02:13 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Rob" == Rob Siemborski writes: >> No, I wouldn't call that defeated. You get better protection >> by checking after the fact. Rob> I know we briefly discussed this in the meeting yesterday and Rob> we left it as "probably ok, with some modifications to the Rob> text"... Rob> I think for me to be happy with the addition of the text, it Rob> would need to both have the "if possible" fix, and a Rob> clarification that if a server advertises NO mechanisms after Rob> authentication, or the protocol does not support fetching Rob> capabilities after authentication -- as is the case with Rob> MUPDATE (though granted, it isn't standards track), then it Rob> MUST NOT act as if a MITM attack was detected. One thing we need to keep in mind is that over time, we get a better idea of what best practices for using SASL are. Some of our older protocols may not support these best practices. I'd rather encourage new protocols to implement the best practices. So, rather than saying that if the server returns no mechanisms the client should not treat it as a MITM attack, I'd like to say something like the following. New protocol profiles SHOULd require servers to make the list of SASL mechanisms available for the initial authentication available to the client after security layers are established. Some older protocols do not require this; for these protocols clients MUST NOT treat an empty list of SASL mechanisms after authentication as a MITM attack. Rob> But I'm still unclear why this is necessary when: Rob> a) it most likely adds an extra round trip to the Rob> authentication process b) it may not even work with all Rob> protocols/implementations -- so that round trip will be Rob> wasted Rob> What are we trying to prevent here, exactly? The scenario Rob> where it applies seems to be something along the lines of: This is valuable because people tend to have fairly lax security configurations on their clients and servers in the interest of interoperability. If there are things we can do to make an attacker's life harder--like protecting negotiations--then we should do so unless doing so has sufficiently negative consequences. From owner-ietf-sasl Fri Nov 14 20:31:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4VYkT061144 for ; Fri, 14 Nov 2003 20:31:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4VYrM061142 for ietf-sasl-bks; Fri, 14 Nov 2003 20:31:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4VXkT061136 for ; Fri, 14 Nov 2003 20:31:33 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hAF4VY5G023232; Fri, 14 Nov 2003 23:31:34 -0500 Date: Fri, 14 Nov 2003 23:31:35 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 14 Nov 2003, Sam Hartman wrote: > New protocol profiles SHOULd require servers to make the list of SASL > mechanisms available for the initial authentication available to the > client after security layers are established. Some older protocols do > not require this; for these protocols clients MUST NOT treat an empty > list of SASL mechanisms after authentication as a MITM attack. This sort of warning seems better to me. > This is valuable because people tend to have fairly lax security > configurations on their clients and servers in the interest of > interoperability. If there are things we can do to make an attacker's > life harder--like protecting negotiations--then we should do so unless > doing so has sufficiently negative consequences. I'm not really convinced there are truly strong benefits here, but since it will mostly be a recommendation for new protocols (which can be designed to negate any negative costs such as the extra round trip), I won't oppose it either (given text along the lines of what you suggest above). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Nov 17 15:12:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHNCCkT054604 for ; Mon, 17 Nov 2003 15:12:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHNCC28054603 for ietf-sasl-bks; Mon, 17 Nov 2003 15:12:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHNC9kU054596; Mon, 17 Nov 2003 15:12:09 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 17 Nov 2003 15:13:32 -0800 To: Sam Hartman , ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Re: consensus call on full stop and private use for saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:00 PM -0500 11/14/03, Sam Hartman wrote: >It was fairly obvious at Tuesday's meeting that we did not have a >rough consensus to change the saslprep document either to map full >stops to ASCII full stop or to allow private use characters. > >The saslprep document has already passed working group last call. AS >such, there is a relatively high bar to propose changes to the >document from within the working group. > >Since there is no consensus to change the document, the document will >remain as is for now. > >I realize several people are still actively thinking about these >issues and people are still looking at what actual input methods do in >various situations. If this ongoing discussion reaches a consensus >before the documents are sent to the IESG, then we can act on that >consensus. Echoing my comments in Minneapolis, I'm fine with leaving the document as it stands now. - The ideographic full stop situation is somewhat of a no-win situation. If we map them to periods, some Asian users will be surprised when they try to type the right thing. If we don't map them, other users will be surprised. We mapped them to periods in IDNA because domain names consistently use periods as separators, but that is not the case in SASL or Kerberos names. - Allowing private use characters in names requires specifying many things about them that is way, way out of scope for IETF activities (such as their normalization, their right-to-left properties, and so on). Organizations that use private-use characters often later regret that they did so, particularly when they try to communicate with other organizations who use the same characters for something else. The saslprep document works fine as it is. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHNCCkT054604 for ; Mon, 17 Nov 2003 15:12:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHNCC28054603 for ietf-sasl-bks; Mon, 17 Nov 2003 15:12:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHNC9kU054596; Mon, 17 Nov 2003 15:12:09 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 17 Nov 2003 15:13:32 -0800 To: Sam Hartman , ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Re: consensus call on full stop and private use for saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:00 PM -0500 11/14/03, Sam Hartman wrote: >It was fairly obvious at Tuesday's meeting that we did not have a >rough consensus to change the saslprep document either to map full >stops to ASCII full stop or to allow private use characters. > >The saslprep document has already passed working group last call. AS >such, there is a relatively high bar to propose changes to the >document from within the working group. > >Since there is no consensus to change the document, the document will >remain as is for now. > >I realize several people are still actively thinking about these >issues and people are still looking at what actual input methods do in >various situations. If this ongoing discussion reaches a consensus >before the documents are sent to the IESG, then we can act on that >consensus. Echoing my comments in Minneapolis, I'm fine with leaving the document as it stands now. - The ideographic full stop situation is somewhat of a no-win situation. If we map them to periods, some Asian users will be surprised when they try to type the right thing. If we don't map them, other users will be surprised. We mapped them to periods in IDNA because domain names consistently use periods as separators, but that is not the case in SASL or Kerberos names. - Allowing private use characters in names requires specifying many things about them that is way, way out of scope for IETF activities (such as their normalization, their right-to-left properties, and so on). Organizations that use private-use characters often later regret that they did so, particularly when they try to communicate with other organizations who use the same characters for something else. The saslprep document works fine as it is. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4VYkT061144 for ; Fri, 14 Nov 2003 20:31:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4VYrM061142 for ietf-sasl-bks; Fri, 14 Nov 2003 20:31:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4VXkT061136 for ; Fri, 14 Nov 2003 20:31:33 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hAF4VY5G023232; Fri, 14 Nov 2003 23:31:34 -0500 Date: Fri, 14 Nov 2003 23:31:35 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 14 Nov 2003, Sam Hartman wrote: > New protocol profiles SHOULd require servers to make the list of SASL > mechanisms available for the initial authentication available to the > client after security layers are established. Some older protocols do > not require this; for these protocols clients MUST NOT treat an empty > list of SASL mechanisms after authentication as a MITM attack. This sort of warning seems better to me. > This is valuable because people tend to have fairly lax security > configurations on their clients and servers in the interest of > interoperability. If there are things we can do to make an attacker's > life harder--like protecting negotiations--then we should do so unless > doing so has sufficiently negative consequences. I'm not really convinced there are truly strong benefits here, but since it will mostly be a recommendation for new protocols (which can be designed to negate any negative costs such as the extra round trip), I won't oppose it either (given text along the lines of what you suggest above). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4PLkT060627 for ; Fri, 14 Nov 2003 20:25:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4PL8s060626 for ietf-sasl-bks; Fri, 14 Nov 2003 20:25:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (mcb185e42.tmodns.net [66.94.24.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4P1kT060568 for ; Fri, 14 Nov 2003 20:25:08 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6231015159F; Fri, 14 Nov 2003 23:24:50 -0500 (EST) To: Rob Siemborski Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: From: Sam Hartman Date: Fri, 14 Nov 2003 22:16:15 -0500 In-Reply-To: (Rob Siemborski's message of "Wed, 12 Nov 2003 10:02:13 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Rob" == Rob Siemborski writes: >> No, I wouldn't call that defeated. You get better protection >> by checking after the fact. Rob> I know we briefly discussed this in the meeting yesterday and Rob> we left it as "probably ok, with some modifications to the Rob> text"... Rob> I think for me to be happy with the addition of the text, it Rob> would need to both have the "if possible" fix, and a Rob> clarification that if a server advertises NO mechanisms after Rob> authentication, or the protocol does not support fetching Rob> capabilities after authentication -- as is the case with Rob> MUPDATE (though granted, it isn't standards track), then it Rob> MUST NOT act as if a MITM attack was detected. One thing we need to keep in mind is that over time, we get a better idea of what best practices for using SASL are. Some of our older protocols may not support these best practices. I'd rather encourage new protocols to implement the best practices. So, rather than saying that if the server returns no mechanisms the client should not treat it as a MITM attack, I'd like to say something like the following. New protocol profiles SHOULd require servers to make the list of SASL mechanisms available for the initial authentication available to the client after security layers are established. Some older protocols do not require this; for these protocols clients MUST NOT treat an empty list of SASL mechanisms after authentication as a MITM attack. Rob> But I'm still unclear why this is necessary when: Rob> a) it most likely adds an extra round trip to the Rob> authentication process b) it may not even work with all Rob> protocols/implementations -- so that round trip will be Rob> wasted Rob> What are we trying to prevent here, exactly? The scenario Rob> where it applies seems to be something along the lines of: This is valuable because people tend to have fairly lax security configurations on their clients and servers in the interest of interoperability. If there are things we can do to make an attacker's life harder--like protecting negotiations--then we should do so unless doing so has sufficiently negative consequences. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4PHkT060609 for ; Fri, 14 Nov 2003 20:25:17 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF4PH9C060608 for ietf-sasl-bks; Fri, 14 Nov 2003 20:25:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (mcb185e42.tmodns.net [66.94.24.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF4OxkT060567 for ; Fri, 14 Nov 2003 20:25:08 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2AB8415159D; Fri, 14 Nov 2003 23:24:50 -0500 (EST) To: ietf-sasl@imc.org Subject: consensus call on full stop and private use for saslprep From: Sam Hartman Date: Fri, 14 Nov 2003 22:00:57 -0500 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It was fairly obvious at Tuesday's meeting that we did not have a rough consensus to change the saslprep document either to map full stops to ASCII full stop or to allow private use characters. The saslprep document has already passed working group last call. AS such, there is a relatively high bar to propose changes to the document from within the working group. Since there is no consensus to change the document, the document will remain as is for now. I realize several people are still actively thinking about these issues and people are still looking at what actual input methods do in various situations. If this ongoing discussion reaches a consensus before the documents are sent to the IESG, then we can act on that consensus. Thanks, --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF00BkT046359 for ; Fri, 14 Nov 2003 16:00:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAF00Buk046358 for ietf-sasl-bks; Fri, 14 Nov 2003 16:00:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF007kT046349 for ; Fri, 14 Nov 2003 16:00:10 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hAF006NN011142; Fri, 14 Nov 2003 17:00:07 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Fri, 14 Nov 2003 17:00:01 -0700 From: Lyndon Nerenberg To: Chris Newman cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 missing security consideration Message-ID: <2147483647.1068829201@[192.168.42.6]> In-Reply-To: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> References: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Thanks Chris, I've added the text. I will push a new (and final I hope) draft next week. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKuRkT077926 for ; Thu, 13 Nov 2003 12:56:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKuRZa077925 for ietf-sasl-bks; Thu, 13 Nov 2003 12:56:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKuMkT077907 for ; Thu, 13 Nov 2003 12:56:24 -0800 (PST) (envelope-from Chris.Newman@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id hADKuJcm015615 for ; Thu, 13 Nov 2003 13:56:24 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HOB0045A65UCO@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Thu, 13 Nov 2003 13:56:19 -0700 (MST) Received: from dyn132-212.ietf58.ietf.org ([130.129.132.212]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HOB00F4365SJG@mail.sun.net> for ietf-sasl@imc.org; Thu, 13 Nov 2003 13:56:18 -0700 (MST) Date: Thu, 13 Nov 2003 14:56:16 -0600 From: Chris Newman Subject: CRAM-MD5 missing security consideration To: lyndon@orthanc.ab.ca Cc: ietf-sasl@imc.org Message-id: <2147483647.1068735376@dyn132-212.ietf58.ietf.org> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b9 (Mac OS X) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: CRAM-MD5 does not authenticate the server and does not include a client-supplied nonce. As a result, it is possible to construct a server with a fixed challenge string that has pre-computed the hashes for all possible passwords up to a certain length (or from a dictionary). Such a server could then immediately determine the user's password if it is sufficiently short. - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKs9kT077769 for ; Thu, 13 Nov 2003 12:54:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKs9DD077768 for ietf-sasl-bks; Thu, 13 Nov 2003 12:54:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn131-176.ietf58.ietf.org [130.129.131.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKs8kT077763 for ; Thu, 13 Nov 2003 12:54:09 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1E50C15159D; Thu, 13 Nov 2003 15:53:49 -0500 (EST) To: ietf-sasl@imc.org Subject: ID Nit: Internet drafts cannot expire in six monthse Message-Id: <20031113205349.1E50C15159D@konishi-polis.mit.edu> Date: Thu, 13 Nov 2003 15:53:49 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. Just a reminder that Internet draft formatting requirements do not allow you to say that the draft you are submitting expires in six months; instead you are requested to include an explicit date. I believe that this is a useful requirement even though it is not enforced. IT makes it more clear whether a draft is expired if it escapes from the ID repository and is used in another context. If it is easy for you to have a real expiration date, please do so. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKjNkT077303 for ; Thu, 13 Nov 2003 12:45:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADKjNRs077302 for ietf-sasl-bks; Thu, 13 Nov 2003 12:45:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn131-176.ietf58.ietf.org [130.129.131.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADKjLkT077297 for ; Thu, 13 Nov 2003 12:45:22 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A183215159D; Thu, 13 Nov 2003 15:45:03 -0500 (EST) To: Russ Housley Cc: smb@research.att.com, kurt@openldap.org, hartmans@mit.edu, ietf-sasl@imc.org Subject: Summary for SASL References: <5.2.0.9.2.20031110115446.043e7508@mail.binhost.com> From: Sam Hartman In-Reply-To: <5.2.0.9.2.20031110115446.043e7508@mail.binhost.com> (Russ Housley's message of "Mon, 10 Nov 2003 11:54:54 -0500") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) Date: Thu, 13 Nov 2003 15:45:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SASL working group met for one hour Tuesday. As part of successful SASL authentication, you can set up a channel security layer. If you later have another successful authentication, the security layer remains in place even if the new SASL mechanism does not negotiate a security layer. The There was some concern that this might create problems for distributed server implementations where two components trust each other, but do not trust a third component. The rough consensus of the working group was not to make this change. we had significant discussion of issues surrounding our stringprep profile saslprep. First, we discussed whether we wanted to map all full stop characters to the ASCII full stop character. We also discussed whether we would allow private use characters. The working group failed to reach consensus on these issues at the session. We had a presentation on implementation problems with SMTP authentication. We expect to be making various changes in our specifications to make them more clear. The incorrect behavior is already a violation of the existing specs but there is a desire to add better examples. Alexey Melnikov has agreed to edit the GSSAPI mechanism draft because the previous editor has not had time to edit the document. We expect an initial submission shortly after this meeting. The chairs will get new milestones to the ADs shortly after the meeting. We hope to be done with base, saslprep, plain and anonymous by the end of the year. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFafkT030212 for ; Wed, 12 Nov 2003 07:36:41 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACFafkR030211 for ietf-sasl-bks; Wed, 12 Nov 2003 07:36:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFadkT030204 for ; Wed, 12 Nov 2003 07:36:39 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hACF2DWj011542; Wed, 12 Nov 2003 10:02:13 -0500 Date: Wed, 12 Nov 2003 10:02:13 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 9 Nov 2003, Sam Hartman wrote: > Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: > > >> If the client fetches a list of supported SASL mechanisms from > >> the server and bases its choice of SASL mechanism on the > >> result, it SHOULD fetch that list both before and after the > >> SASL security layer is negotiated. This allows the client to > >> detect active attacks that remove mechanisms from the server's > >> list of supported mechanisms, and allows the client to ensure > >> that it is using the best mechanism supported by both client > >> and server. > > Rob> Isn't this attack defeated simply by requiring the clients to > Rob> not pick a mechanism that does not meet their minimum > Rob> requirements for authentication? > > No, I wouldn't call that defeated. You get better protection by > checking after the fact. I know we briefly discussed this in the meeting yesterday and we left it as "probably ok, with some modifications to the text"... I think for me to be happy with the addition of the text, it would need to both have the "if possible" fix, and a clarification that if a server advertises NO mechanisms after authentication, or the protocol does not support fetching capabilities after authentication -- as is the case with MUPDATE (though granted, it isn't standards track), then it MUST NOT act as if a MITM attack was detected. But I'm still unclear why this is necessary when: a) it most likely adds an extra round trip to the authentication process b) it may not even work with all protocols/implementations -- so that round trip will be wasted What are we trying to prevent here, exactly? The scenario where it applies seems to be something along the lines of: The server advertises GSSAPI and DIGEST-MD5. The client, for whatever reason, decides only GSSAPI (with privacy layer) is secure enough for it. The attacker edits the advertised capabilites and removes GSSAPI, the client sees that the server only supports DIGEST-MD5. I argue that the client should fail the authentication here and not even try to authenticate -- the MITM attack has been defeated. If instead it authenticates, then that implies that it is okay with using DIGEST-MD5. Even if it later discovers that GSSAPI was available, it should be ok with using DIGEST for the session -- what is it going to tell the user "uh, I sent your credentials with a mechanism you didn't want to use, and guess what -- there's an attack in progress!". Sure, the protection may be "better" (as in, you can detect that an attack is in progress), but the costs are high (additional round trip, it might not work anyway) for what seems to me to be a very small gain. I'd be much happier either not adding this, or adding it as a "clients MAY want to do this to detect MITM attacks" -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFHPkT029460 for ; Wed, 12 Nov 2003 07:17:25 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACFHPft029459 for ietf-sasl-bks; Wed, 12 Nov 2003 07:17:25 -0800 (PST) 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.10/8.12.8) with ESMTP id hACFHOkT029453 for ; Wed, 12 Nov 2003 07:17:24 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AJwkD-0002G8-AQ; Wed, 12 Nov 2003 16:17:21 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AJwk8-000846-BG; Wed, 12 Nov 2003 16:17:16 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJwk7-0006l9-00; Wed, 12 Nov 2003 16:17:15 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Siemborski Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Nov 2003 16:17:15 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > I'd be much happier either not adding this, or adding it as a "clients MAY > want to do this to detect MITM attacks" Fine by me. I don't feel strongly about it, I just saw it in LDAP and thought it might be a good idea. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABLOwkT022035 for ; Tue, 11 Nov 2003 13:24:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABLOwrC022033 for ietf-sasl-bks; Tue, 11 Nov 2003 13:24:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hABLOukT022020 for ; Tue, 11 Nov 2003 13:24:57 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AJg0I-0003yW-GR; Tue, 11 Nov 2003 22:24:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AJg0E-0001mt-G1; Tue, 11 Nov 2003 22:24:46 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJg0D-00043k-00; Tue, 11 Nov 2003 22:24:45 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FB148F3.60307@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> <3FB148F3.60307@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 11 Nov 2003 22:24:45 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >> "Only a successful reauthentication is able replace/remove the >> previously negotiated security layer." > > I was thinking specifically about SASL [re]authentication when writing > this. My point was that a failed reauthentication didn't remove a > previously negotiated security layer. Oh. So... server and client may at any time agree to remove the security layer, _except_ after failed reauthentication? > This should apply to non-SASL reauthentications as well. Except that in the message you quoted a few messages ago, you didn't want SASL to know about non-SASL reauthentications, so it shouldn't say anything about them. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKdJkT020214 for ; Tue, 11 Nov 2003 12:39:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKdJM7020213 for ietf-sasl-bks; Tue, 11 Nov 2003 12:39:19 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKdHkT020203 for ; Tue, 11 Nov 2003 12:39:18 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 20:40:51 +0000 Message-ID: <3FB148F3.60307@isode.com> Date: Tue, 11 Nov 2003 20:39:15 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Your text does document that anything else than SASL authentication - >>>and therefore also Simple Bind - may not remove the SASL security layer. >>> >>> >>I am not sure that I wrote this anywhere in the document. >>Anyway, even if I did, that wasn't the intent. >> >> > >You are right, it's not in the document. It's in two explanatory >messages from you in this thread: > > Date: Wed, 15 Oct 2003 12:52:04 +0100 > Message-ID: <3F8D34E4.4020607@isode.com> > URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html > > "No, the layer can only be cancelled/replaced after a subsequent > authentication completes successfully." > >and > > Date: Sat, 01 Nov 2003 14:22:06 +0000 > Message-ID: <3FA3C18E.8010101@isode.com> > URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html > > "Only a successful reauthentication is able replace/remove the > previously negotiated security layer." > I was thinking specifically about SASL [re]authentication when writing this. My point was that a failed reauthentication didn't remove a previously negotiated security layer. This should apply to non-SASL reauthentications as well. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKZ2kT020066 for ; Tue, 11 Nov 2003 12:35:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKZ2XS020065 for ietf-sasl-bks; Tue, 11 Nov 2003 12:35:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKZ0kT020060 for ; Tue, 11 Nov 2003 12:35:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 20:36:37 +0000 Message-ID: <3FB147F5.3070902@isode.com> Date: Tue, 11 Nov 2003 20:35:01 +0000 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: [Fwd: Keeping/dropping existing SASL security layer] 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: Hopefully this clarifies things. -------- Original Message -------- Subject: Keeping/dropping existing SASL security layer Date: Tue, 11 Nov 2003 11:52:48 +0000 From: Alexey Melnikov To: Rob Siemborski The order of events is as follows (I will reference "Encryption endpoint box" as CC server): 1) The client connects to CC in order to request a resource FOO. 2) CC looks up its database to figure which server is managing FOO. It turns out to be server AA. 3). The client authenticates to AA (traffic is passing through CC). The client and AA negotiate a security layer. Upon successful negotiation both ends have pointers to two function (encode/decode) and associated keys. After that there might be 2 variations: a). AA does encoding/decoding itself or b). AA passes encode/decode functions and associated state to CC. (CC is trusted) 4). The client exchanges some information with AA (regarding resource FOO), the exchange is recorded by BB (but at this stage BB can't decode it) Than in case a): 5). The client requests access to resource BAR. Server AA decodes request and notifies CC about request to BAR. 6). CC looks up its database and determines that resource BAR is managed by BB. 7). The client reauthenticates to BB (encrypted traffic is going to AA through CC, than cleartext traffic is going from AA to BB through CC), it negotiates no security layer. When the reauthentication is complete, the old layer is used. 8). The client requests access to resource BAR on the server BB (traffic flow is the same as in 7). 9). Evil server BB instead of responding to request BAR returns specially crafted response in order to verify some guesses about previously recorded data exchange between the client and AA. The response is traveling in clear from BB to AA (through CC), server AA encrypts the response and sends it to the client (through CC). The evil BB records the encrypted version of its response and by analyzing it, BB can try to break the previously recorded exchange between the client and AA. or in case b): 5). The client requests access to resource BAR. Server CC decodes request. 6). CC looks up its database and determines that resource BAR is managed by BB. 7). The client reauthenticates to BB (encrypted traffic is going to CC, than cleartext traffic is going from CC to BB), it negotiates no security layer. When the reauthentication is complete, the old layer is used. 8). The client requests access to resource BAR on the server BB (traffic flow is the same as in 7). 9). Evil server BB instead of responding to request BAR returns specially crafted response in order to verify some guesses about previously recorded data exchange between the client and AA. The response is traveling in clear from BB to CC, server CC encrypts the response and sends it to the client. The evil BB records the encrypted version of its response and by analyzing it, BB can try to break the previously recorded exchange between the client and AA. (I think both cases are equivalent). I am not a security export, but I think this attack allows for "CBC mode attack". TLS is being revised (TLS 1.1) to deal with this issue. Alexey -- Alexey Melnikov __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKNrkT019588 for ; Tue, 11 Nov 2003 12:23:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKNrAY019587 for ietf-sasl-bks; Tue, 11 Nov 2003 12:23:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (Ketorin.ietf58.ietf.org [130.129.134.235] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKNqkT019582 for ; Tue, 11 Nov 2003 12:23:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id CBA0415159D; Tue, 11 Nov 2003 15:23:52 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , SASL WG Subject: Re: Replacing a SASL security layer References: From: Sam Hartman Date: Tue, 11 Nov 2003 15:23:52 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Thu, 6 Nov 2003 00:46:30 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd like to second the lack of understanding here. I have asked several people to explain this attack to me and so far have failed to understand it. Hopefully we'll be able to clarify during the meeting today. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABK73kT018762 for ; Tue, 11 Nov 2003 12:07:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABK73eV018761 for ietf-sasl-bks; Tue, 11 Nov 2003 12:07:03 -0800 (PST) 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.10/8.12.8) with ESMTP id hABK71kT018747 for ; Tue, 11 Nov 2003 12:07:02 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AJemu-000556-6a; Tue, 11 Nov 2003 21:06:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AJems-0002Qx-MU; Tue, 11 Nov 2003 21:06:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJems-0003sl-00; Tue, 11 Nov 2003 21:06:54 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FB13714.7020602@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> <3FB13714.7020602@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 11 Nov 2003 21:06:54 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >> Your text does document that anything else than SASL authentication - >> and therefore also Simple Bind - may not remove the SASL security layer. > > I am not sure that I wrote this anywhere in the document. > Anyway, even if I did, that wasn't the intent. You are right, it's not in the document. It's in two explanatory messages from you in this thread: Date: Wed, 15 Oct 2003 12:52:04 +0100 Message-ID: <3F8D34E4.4020607@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html "No, the layer can only be cancelled/replaced after a subsequent authentication completes successfully." and Date: Sat, 01 Nov 2003 14:22:06 +0000 Message-ID: <3FA3C18E.8010101@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html "Only a successful reauthentication is able replace/remove the previously negotiated security layer." > If the WG feels that this issue should be addressed, I will add some > clarifying text. Well, I at least think it should be clarified. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJN5kT016658 for ; Tue, 11 Nov 2003 11:23:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABJN5n0016657 for ietf-sasl-bks; Tue, 11 Nov 2003 11:23:05 -0800 (PST) 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.10/8.12.8) with ESMTP id hABJN3kT016651 for ; Tue, 11 Nov 2003 11:23:04 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 19:24:35 +0000 Message-ID: <3FB13714.7020602@isode.com> Date: Tue, 11 Nov 2003 19:23:00 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA230D.2000206@isode.com> <6.0.0.22.0.20031106084855.049bf768@127.0.0.1> <3FAA8601.4050507@isode.com> <6.0.0.22.0.20031106095359.048a4a98@127.0.0.1> <3FAA8EA5.5030508@isode.com> <3FAAB693.7080300@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Alexey Melnikov writes: >>> >>>>Whether Simple bind removes or keep a previous security layer has >>>>nothing to do with SASL, this is very LDAP specific. >>>> >>>> >>>If SASL allowed LDAP to do so, it would be LDAP specific. >>> >>> >>SASL can't (and must not) document something it is not aware of. SASL >>doesn't have no be aware about Simple bind. >> >> > >Your text does document that anything else than SASL authentication - >and therefore also Simple Bind - may not remove the SASL security layer. > I am not sure that I wrote this anywhere in the document. Anyway, even if I did, that wasn't the intent. >Even though it's not aware of Simple Bind. All it is aware of is that >whatever Simple Bind is, it's not SASL. > > >>Simple bind is NOT SASL PLAIN, >> >> > >I know. That's why I brought it up. > > > >>>It doesn't, so it isn't. >>> >>> >>Why? >> >> > >Maybe I should start over. > >I did not say that SASL should say whether or not LDAP Simple Bind >should remove the layer. I said that the current text does not allow >_LDAP_ to say that Simple Bind should remove the layer. If we want LDAP >- or other protocols - to be _allowed_ to specify that something like >non-SASL Simple Bind should remove the layer, rfc2222bis must say >instead something like > > the protocol profile may specify that authentication by other means > than SASL may remove the SASL security layer > >or if you don't want SASL to 'know about' non-SASL auth, that > > ... the protocol may at any time decide by other means than SASL to > remove the security layer > >BTW, I'm not saying that we should do this. Nor that we shouldn't. >I simply wanted the issue to be deliberately decided rather than >defaulted. That's all. > > IMHO, something that is not explicitly prohibited is allowed. If the WG feels that this issue should be addressed, I will add some clarifying text. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABB5PkT094235 for ; Tue, 11 Nov 2003 03:05:25 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABB5ON6094234 for ietf-sasl-bks; Tue, 11 Nov 2003 03:05:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hABB5HkT094226 for ; Tue, 11 Nov 2003 03:05:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 Nov 2003 11:06:35 +0000 Message-ID: <3FB0C25E.6000501@isode.com> Date: Tue, 11 Nov 2003 11:05:02 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? References: In-Reply-To: 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: Hallvard B Furuseth wrote: >What is the purpose of the protocol profile? If a protocol spec has >something to say about its SASL entities that are not mentioned in >section 5 (Protocol profile requirements), should it go in the profile >or elsewhere? Could you say something about that in section 5? > >For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says: > > 3.3.5. Rules for using SASL security layers > > If a SASL security layer is negotiated, the client SHOULD discard > information about the server fetched prior to the initiation of the > SASL negotiation and not obtained through secure mechanisms. > > If the client is configured to support multiple SASL mechanisms, it > SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both > before and after the SASL security layer is negotiated. (...) > >Does that belong in the protocol profile? > IMHO, this kind of information does belong to a protocol profile document. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH9XkT082275 for ; Mon, 10 Nov 2003 09:09:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAH9X45082274 for ietf-sasl-bks; Mon, 10 Nov 2003 09:09:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH9WkT082268 for ; Mon, 10 Nov 2003 09:09:32 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAH9V5u005289; Mon, 10 Nov 2003 10:09:31 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAAH9Vru017221; Mon, 10 Nov 2003 09:09:31 -0800 (PST) Received: from unknown (vpn-129-150-20-204.SFBay.Sun.COM [129.150.20.204]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO50080TBNUKX@mpkmail.eng.sun.com>; Mon, 10 Nov 2003 09:09:31 -0800 (PST) Date: Mon, 10 Nov 2003 08:12:42 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO50080UBNUKX@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: pV+zF7NBQ4144jebQniLiQ== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is an explicit flag value that need to be given to the SASLprep and any other Stringprep profile to be more specific. Otherwise, people will be confused and wondering what to do with it on the Unicode version issues and also whether and how to use query string vs. storage string (for simple user names and passwords). Especially, having some version related remarks or at least explicitly giving the flag and also mark the flag with a reference would greatly help people, e.g., "SASLprep(authcid, AllowUnassigned)" or "SASLprep(passwd, AllowUnassigned)" since the flag processing would/better need to be done at the Stringprep protocol processing. With regards, Ienup ] Date: Sun, 09 Nov 2003 14:13:08 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on frigga.ctd.anl.gov ] ] Ienup Sung wrote: ] ] >PS. By the way, on a bit different topic, reading the SALSprep and also the ] >PLAIN mechanism drafts, it appears there is no AllowUnassigned flag ] >setting or mentioning of it in the drafts. Has this issue been discussed ] >and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? ] >If not, it seems either explicitly defining that the unassigned Unicode ] >characters are not allowed in the drafts, or, allow setting of the ] >AllowUnassigned flag as either True or False at the PLAIN draft appears ] >necesary so that the versioning issue is clearly stated... If this question ] >has been asked and answered, sorry, please let me know and I'll scan more of ] >the archived emails. ] > ] > ] > ] Whether or not Unassigned Code Points are to be allowed or not is ] dependent upon ] how the string being prepared is to be used. As described in RFC 3454 ] section 7, ] if the use of the string is for storage in a database then Unassigned ] Code Points ] are to be excluded. However, if the string is to be used for the ] purposed of ] querying a database, then the string may contain Unassigned Code Points. ] ] I do not believe it is required for SASLprep to highlight this ] distinction. ] It should however be specified in the protocol documents which utilize ] string ] preparation methods constructed within the framework of RFC 3454. ] ] Jeffrey Altman ] ] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGpgkT081328 for ; Mon, 10 Nov 2003 08:51:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAGpgEV081327 for ietf-sasl-bks; Mon, 10 Nov 2003 08:51:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGpfkT081322 for ; Mon, 10 Nov 2003 08:51:41 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAGpe5u026011; Mon, 10 Nov 2003 09:51:41 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAAGpVDS018921; Mon, 10 Nov 2003 08:51:31 -0800 (PST) Received: from unknown (vpn-129-150-20-204.SFBay.Sun.COM [129.150.20.204]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO50089KAU3KX@mpkmail.eng.sun.com>; Mon, 10 Nov 2003 08:51:40 -0800 (PST) Date: Mon, 10 Nov 2003 07:54:51 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO50089LAU4KX@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: BYCz81EfVfXsql4UdlhwOg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In my opinion, yes,that's correct and especially for user names and passwords. With regards, Ienup ] Date: Sun, 09 Nov 2003 20:36:37 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on frigga.ctd.anl.gov ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> As U+002E is used as full stop as label separator (not as ] Ienup> decimal point for number representations), the Asian full ] Ienup> stops are used as full stop as label separator in the IDNA. ] ] Ienup> The IDNA's full stop mappings on the Internet domain style ] Ienup> names are possible and rather desireable for convenience ] Ienup> since we know that the full stops in that case are used as ] Ienup> label separators and thus safely map the Asian full stops ] Ienup> to the U+002E as the full stop. ] ] Ienup> With regards, ] ] You believe there is not a similar convenience issue in usernames? ] ] ] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA7AUkT059886 for ; Sun, 9 Nov 2003 23:10:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA7AU8m059885 for ietf-sasl-bks; Sun, 9 Nov 2003 23:10:30 -0800 (PST) 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.10/8.12.8) with ESMTP id hAA7ATkT059880 for ; Sun, 9 Nov 2003 23:10:29 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AJ6Bx-0002tt-LJ; Mon, 10 Nov 2003 08:10:29 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AJ6Br-0001gQ-2m; Mon, 10 Nov 2003 08:10:23 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJ6Bq-0006HE-00; Mon, 10 Nov 2003 08:10:22 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Nov 2003 08:10:22 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I believe section 5 is a set of minimum requirements for protocol > profiles; you should be able to specify additional details in the > profile document. OK, but why would I - or why would I not? What belongs in the protocol profile? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA6QikT058099 for ; Sun, 9 Nov 2003 22:26:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA6Qiwi058098 for ietf-sasl-bks; Sun, 9 Nov 2003 22:26:44 -0800 (PST) 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.10/8.12.8) with ESMTP id hAA6QhkT058093 for ; Sun, 9 Nov 2003 22:26:43 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AJ5Va-0006ZF-LL; Mon, 10 Nov 2003 07:26:42 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AJ5VY-0003y8-4g; Mon, 10 Nov 2003 07:26:40 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AJ5VX-00069p-00; Mon, 10 Nov 2003 07:26:39 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sam Hartman Cc: Rob Siemborski , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Nov 2003 07:26:39 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Rob" == Rob Siemborski writes: > > Rob> There are also currently deployed servers that do not > Rob> continue to advertise their sasl mechanisms after > Rob> authentication, since in almost all current protocols it is > Rob> not valid to issue a second sasl authentication command. > > That's why he said SHOULD not MUST;) Well, it would have been if I had thought of it... I guess I should have put an 'if possible' in there somewhere. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA1aekT046275 for ; Sun, 9 Nov 2003 17:36:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAA1aelv046274 for ietf-sasl-bks; Sun, 9 Nov 2003 17:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAA1adkT046269 for ; Sun, 9 Nov 2003 17:36:39 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id CF5D415159D; Sun, 9 Nov 2003 20:36:37 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HO200029ACLJP@mpkmail.eng.sun.com> From: Sam Hartman Date: Sun, 09 Nov 2003 20:36:37 -0500 In-Reply-To: <0HO200029ACLJP@mpkmail.eng.sun.com> (Ienup Sung's message of "Sat, 08 Nov 2003 17:48:21 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Ienup" == Ienup Sung writes: Ienup> As U+002E is used as full stop as label separator (not as Ienup> decimal point for number representations), the Asian full Ienup> stops are used as full stop as label separator in the IDNA. Ienup> The IDNA's full stop mappings on the Internet domain style Ienup> names are possible and rather desireable for convenience Ienup> since we know that the full stops in that case are used as Ienup> label separators and thus safely map the Asian full stops Ienup> to the U+002E as the full stop. Ienup> With regards, You believe there is not a similar convenience issue in usernames? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NkBkT043040 for ; Sun, 9 Nov 2003 15:46:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NkB8t043039 for ietf-sasl-bks; Sun, 9 Nov 2003 15:46:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NkAkT043034 for ; Sun, 9 Nov 2003 15:46:10 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A61E915159D; Sun, 9 Nov 2003 18:46:12 -0500 (EST) To: Tony Hansen Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 References: <3FAA7E9E.3080704@att.com> From: Sam Hartman Date: Sun, 09 Nov 2003 18:46:12 -0500 In-Reply-To: <3FAA7E9E.3080704@att.com> (Tony Hansen's message of "Thu, 06 Nov 2003 12:02:22 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Tony" == Tony Hansen writes: Tony> May I suggest that this section be rewritten so that it Tony> focusses on the two topics separately. For example, Tony> something like the following below might be considered. This section certainly has been a subject of much discussion about clarity here. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NiCkT043002 for ; Sun, 9 Nov 2003 15:44:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NiCKl043001 for ietf-sasl-bks; Sun, 9 Nov 2003 15:44:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NiBkT042996 for ; Sun, 9 Nov 2003 15:44:11 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id EDA7415159D; Sun, 9 Nov 2003 18:44:13 -0500 (EST) To: Rob Siemborski Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: From: Sam Hartman Date: Sun, 09 Nov 2003 18:44:13 -0500 In-Reply-To: (Rob Siemborski's message of "Sun, 9 Nov 2003 16:33:41 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: >> If the client fetches a list of supported SASL mechanisms from >> the server and bases its choice of SASL mechanism on the >> result, it SHOULD fetch that list both before and after the >> SASL security layer is negotiated. This allows the client to >> detect active attacks that remove mechanisms from the server's >> list of supported mechanisms, and allows the client to ensure >> that it is using the best mechanism supported by both client >> and server. Rob> Isn't this attack defeated simply by requiring the clients to Rob> not pick a mechanism that does not meet their minimum Rob> requirements for authentication? No, I wouldn't call that defeated. You get better protection by checking after the fact. Rob> There are also currently deployed servers that do not Rob> continue to advertise their sasl mechanisms after Rob> authentication, since in almost all current protocols it is Rob> not valid to issue a second sasl authentication command. That's why he said SHOULD not MUST;) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NgEkT042962 for ; Sun, 9 Nov 2003 15:42:14 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9NgE5F042961 for ietf-sasl-bks; Sun, 9 Nov 2003 15:42:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (dyn139-188.ietf58.ietf.org [130.129.139.188]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9NgDkT042956 for ; Sun, 9 Nov 2003 15:42:13 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E92B015159D; Sun, 9 Nov 2003 18:42:14 -0500 (EST) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: protocol profile? References: From: Sam Hartman Date: Sun, 09 Nov 2003 18:42:14 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Sun, 9 Nov 2003 19:48:07 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> What is the purpose of the protocol profile? If a Hallvard> protocol spec has something to say about its SASL Hallvard> entities that are not mentioned in section 5 (Protocol Hallvard> profile requirements), should it go in the profile or Hallvard> elsewhere? Could you say something about that in Hallvard> section 5? I believe section 5 is a set of minimum requirements for protocol profiles; you should be able to specify additional details in the profile document. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LXgkT039697 for ; Sun, 9 Nov 2003 13:33:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9LXghF039696 for ietf-sasl-bks; Sun, 9 Nov 2003 13:33:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LXekT039679 for ; Sun, 9 Nov 2003 13:33:41 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA9LXfWj010566; Sun, 9 Nov 2003 16:33:41 -0500 Date: Sun, 9 Nov 2003 16:33:41 -0500 (EST) From: Rob Siemborski To: Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 9 Nov 2003, Hallvard B Furuseth wrote: > If the client fetches a list of supported SASL mechanisms from the > server and bases its choice of SASL mechanism on the result, it > SHOULD fetch that list both before and after the SASL security layer > is negotiated. This allows the client to detect active attacks that > remove mechanisms from the server's list of supported mechanisms, and > allows the client to ensure that it is using the best mechanism > supported by both client and server. Isn't this attack defeated simply by requiring the clients to not pick a mechanism that does not meet their minimum requirements for authentication? There are also currently deployed servers that do not continue to advertise their sasl mechanisms after authentication, since in almost all current protocols it is not valid to issue a second sasl authentication command. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LLGkT039472 for ; Sun, 9 Nov 2003 13:21:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9LLGEN039471 for ietf-sasl-bks; Sun, 9 Nov 2003 13:21:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9LLFkT039465 for ; Sun, 9 Nov 2003 13:21:15 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (dyn136-204.ietf58.ietf.org [130.129.136.204]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA9LLEB9018768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 9 Nov 2003 16:21:15 -0500 (EST) Message-ID: <3FAE91C4.8060507@columbia.edu> Date: Sun, 09 Nov 2003 14:13:08 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNY0013YHBQT5@mpkmail.eng.sun.com> In-Reply-To: <0HNY0013YHBQT5@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803040500090503080500" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050803040500090503080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ienup Sung wrote: >PS. By the way, on a bit different topic, reading the SALSprep and also the >PLAIN mechanism drafts, it appears there is no AllowUnassigned flag >setting or mentioning of it in the drafts. Has this issue been discussed >and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? >If not, it seems either explicitly defining that the unassigned Unicode >characters are not allowed in the drafts, or, allow setting of the >AllowUnassigned flag as either True or False at the PLAIN draft appears >necesary so that the versioning issue is clearly stated... If this question >has been asked and answered, sorry, please let me know and I'll scan more of >the archived emails. > > > Whether or not Unassigned Code Points are to be allowed or not is dependent upon how the string being prepared is to be used. As described in RFC 3454 section 7, if the use of the string is for storage in a database then Unassigned Code Points are to be excluded. However, if the string is to be used for the purposed of querying a database, then the string may contain Unassigned Code Points. I do not believe it is required for SASLprep to highlight this distinction. It should however be specified in the protocol documents which utilize string preparation methods constructed within the framework of RFC 3454. Jeffrey Altman --------------ms050803040500090503080500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwOTE5MTMwOFowIwYJKoZIhvcNAQkEMRYEFI9NOnix9ysq hUqqXrZin7LNtgEIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAuAHEn3TM1/ArmrmkyUsgSQ9HWjrN ALmDiwe9M5A5ZbGWFVqNoMyngv7e0r3JQErf/Cv4WHgafjlpeQopEJczvEZQ1OxgBPI9zKcY TJW55/wQgcG9+MhjIIc7yaoMXMmHBoyJJ3YMrD0V9jOH7QrH+YR2r63ai++Oo/OWtVdbnAVj P08sZG2BZOkuMtxN794Nxj6rZOpps4EVnnkaQvQ2sY3N3iG3pU+2U/z52WrjYGfe0p3x6goB ZMxcz4o/eHc/nT+PTWubZ9eum0Z8Y77/Zi+LRiS6CLMNZGJTcyWp5zacQ74SdKR02aAwSIKe crnYFSsKDPNcv31dOxzDFn11egAAAAAAAA== --------------ms050803040500090503080500-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9JW4kT036332 for ; Sun, 9 Nov 2003 11:32:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9JW4sr036331 for ietf-sasl-bks; Sun, 9 Nov 2003 11:32:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9JW3kT036326 for ; Sun, 9 Nov 2003 11:32:03 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AIvI1-0003hW-UO for ietf-sasl@imc.org; Sun, 09 Nov 2003 20:32:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AIvHw-0002kj-So for ietf-sasl@imc.org; Sun, 09 Nov 2003 20:31:56 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIvHw-0004Pz-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 20:31:56 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: suggested text about multiple SASL mechanisms Date: Sun, 9 Nov 2003 20:31:56 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I suggest this text is added to rfc2222bis, probably in the Security Considerations. I stole it from draft-ietf-ldapbis-authmeth-08.txt and de-LDAPified it. If the client fetches a list of supported SASL mechanisms from the server and bases its choice of SASL mechanism on the result, it SHOULD fetch that list both before and after the SASL security layer is negotiated. This allows the client to detect active attacks that remove mechanisms from the server's list of supported mechanisms, and allows the client to ensure that it is using the best mechanism supported by both client and server. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9ImBkT034777 for ; Sun, 9 Nov 2003 10:48:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9ImB6e034776 for ietf-sasl-bks; Sun, 9 Nov 2003 10:48:11 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9ImAkT034771 for ; Sun, 9 Nov 2003 10:48:10 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AIubZ-0000Nf-9u for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:48:09 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AIubX-0007i3-NM for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:48:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIubX-0004Jp-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 19:48:07 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: protocol profile? Date: Sun, 9 Nov 2003 19:48:07 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What is the purpose of the protocol profile? If a protocol spec has something to say about its SASL entities that are not mentioned in section 5 (Protocol profile requirements), should it go in the profile or elsewhere? Could you say something about that in section 5? For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says: 3.3.5. Rules for using SASL security layers If a SASL security layer is negotiated, the client SHOULD discard information about the server fetched prior to the initiation of the SASL negotiation and not obtained through secure mechanisms. If the client is configured to support multiple SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both before and after the SASL security layer is negotiated. (...) Does that belong in the protocol profile? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA9IX0kT034093 for ; Sun, 9 Nov 2003 10:33:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA9IX0H5034092 for ietf-sasl-bks; Sun, 9 Nov 2003 10:33:00 -0800 (PST) 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.10/8.12.8) with ESMTP id hA9IWwkT034081 for ; Sun, 9 Nov 2003 10:32:59 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AIuMp-00077C-5e for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:32:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AIuMm-0002DF-JT for ietf-sasl@imc.org; Sun, 09 Nov 2003 19:32:52 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AIuMm-0004HT-00 for ietf-sasl@imc.org; Sun, 9 Nov 2003 19:32:52 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 9 Nov 2003 19:32:52 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: >Alexey Melnikov writes: >> (...) Only a successful reauthentication is able replace/remove the >> previously negotiated security layer. > > Just to make sure it has been mentioned: > > This also means that non-SASL authentication must keep any old SASL > layer. I expect that's intended, including for LDAPv4? Perhaps I should clarify a bit: The current text does not allow protocols - e.g. LDAP - to say that non-SASL authentication (in LDAP, that's "Simple Bind") should remove the layer. If we want protocols to be allowed to specify that, rfc2222bis must say instead something like the protocol profile may specify that authentication by other means than SASL may remove the SASL security layer or if we don't want SASL to 'know about' non-SASL auth at all, that ... the protocol may at any time decide by other means than SASL to remove the security layer BTW, I'm not saying that we should do this. Nor that we shouldn't. I simply want the issue to be deliberately decided rather than defaulted. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA91mLkT007342 for ; Sat, 8 Nov 2003 17:48:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA91mLkP007341 for ietf-sasl-bks; Sat, 8 Nov 2003 17:48:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA91mKkT007336 for ; Sat, 8 Nov 2003 17:48:20 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA91mMPh020191; Sat, 8 Nov 2003 18:48:22 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA91mLru028547; Sat, 8 Nov 2003 17:48:21 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO200028ACLJP@mpkmail.eng.sun.com>; Sat, 08 Nov 2003 17:48:21 -0800 (PST) Date: Sat, 08 Nov 2003 17:48:21 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO200029ACLJP@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=ISO-8859-1 Content-MD5: RC9tYTcDM4zCLW+l5msq/w== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA91mLkT007337 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As U+002E is used as full stop as label separator (not as decimal point for number representations), the Asian full stops are used as full stop as label separator in the IDNA. The IDNA's full stop mappings on the Internet domain style names are possible and rather desireable for convenience since we know that the full stops in that case are used as label separators and thus safely map the Asian full stops to the U+002E as the full stop. With regards, Ienup ] Date: Sat, 08 Nov 2003 17:11:47 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 8BIT ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> Actually that's exactly the problem that I was also talking ] Ienup> about since people will treat the Asian full stops and ] Ienup> U+002E differently at Asian countries and when people tried ] Ienup> to register a new user account with let say 3。14 ] Ienup> (where it is three, Asian full-stop, and fourteen), the ] Ienup> PLAIN based user account system could say, sorry, we ] Ienup> already have 3.14 (that is three point one four) which is ] Ienup> totally different user account name and would deny the new ] Ienup> user account name which will be quite confusing for Asian ] Ienup> people. ] ] OK, then why would people use the Asian full stop in domain names? ] What's different about the world of DNS and the world of user names? ] ] Yours in confusion, ] ] --Sam ] ] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8NnwkT003457 for ; Sat, 8 Nov 2003 15:49:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA8NnwBL003456 for ietf-sasl-bks; Sat, 8 Nov 2003 15:49:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (m15185e42.tmodns.net [66.94.24.21]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8NnfkT003434 for ; Sat, 8 Nov 2003 15:49:51 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id DD5161515A2; Sat, 8 Nov 2003 18:45:11 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> From: Sam Hartman Date: Sat, 08 Nov 2003 17:11:47 -0500 In-Reply-To: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> (Ienup Sung's message of "Fri, 07 Nov 2003 11:35:46 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Ienup" == Ienup Sung writes: Ienup> Actually that's exactly the problem that I was also talking Ienup> about since people will treat the Asian full stops and Ienup> U+002E differently at Asian countries and when people tried Ienup> to register a new user account with let say 3。14 Ienup> (where it is three, Asian full-stop, and fourteen), the Ienup> PLAIN based user account system could say, sorry, we Ienup> already have 3.14 (that is three point one four) which is Ienup> totally different user account name and would deny the new Ienup> user account name which will be quite confusing for Asian Ienup> people. OK, then why would people use the Asian full stop in domain names? What's different about the world of DNS and the world of user names? Yours in confusion, --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7L79kT052972 for ; Fri, 7 Nov 2003 13:07:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7L78Dp052971 for ietf-sasl-bks; Fri, 7 Nov 2003 13:07:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7L78kT052959 for ; Fri, 7 Nov 2003 13:07:08 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA7L74xA011550; Fri, 7 Nov 2003 13:07:04 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA7L6tDS029035; Fri, 7 Nov 2003 13:06:55 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HO000I9V2NRIA@mpkmail.eng.sun.com>; Fri, 07 Nov 2003 13:07:04 -0800 (PST) Date: Fri, 07 Nov 2003 13:07:04 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HO000I9W2NSIA@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: multipart/mixed; boundary="Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ) Content-type: TEXT/plain; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE Content-MD5: xiCw1QO9AzRAFXH/mDmrFA== I believe the question is whether to (incorrectly) generalize/map or not in= my opinion. Actually the confusion will also and sure to occur if you map the all full stops to the U+002E since Asian people distinguish the U+002E and the U+300= 2 even without any thinking if you wrongly use the full stops in the place of decimal point. The point that I can make further is that people have been using various Asian codesets/codepages that have different code point values and differen= t input mechanisms for each of those Asian full stops and the ASCII decimal points many years; they see them and use them differently. The NFKC used in SASLprep will map the U+FF0E to the U+002E since they are equivalent and should be normalized. On the other hands, the U+3002 and the U+FF61 are not equivalent to the U+002E but only to themselves, i.e., the U+FF61 will map to the U+3002 after the NFKC. Here is also another practical example: the ATOK is, arguably, the most pop= ular Japanese input system in my understanding. When you use ATOK to input Japanese, what happens is that when you type with numbers, you will get '.' automatically if you press dot key from your keyboard. When a sentense is ending, used by itself alone, or surrounded with non-gidits, the dot key will be interpreted as the ideographic/Asian full-stop of U+3002. In other words, to input ideographic/Asian full stop (U+3002) with number isn't that easy and when that happened, i.e., a user typed in the U+3002 among numbers= , that means it is most definitely not the full stop. Furthermore, you can as= k any Asian people around you if you can use full stop in a number/numeric notation; most likely almost 100% of them will say, No Way. (Also and at the same time, just as for info, Asian people will absolutely accept and tolerate '.' being used in the place of U+3002 iff it is used as the full stop. Usually, formal documents don't use '.' by the way a= s you know.) I also attached a sample screen shot in JPEG showing the ATOK12 based Japanese input with numbers and would like to demonstrate how Asian input system works in the SASL WG meeting at Tuesday. And so once again my suggestion is that the mappings of all full stops shou= ld be done as similary as defined in the IDNA for Internet style domain names but outside and before the SASLprep if such mappings are needed for Interne= t domain style names. With regards, Ienup ] Date: Fri, 07 Nov 2003 15:16:25 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ]=20 ] It is absolutely a trade off. Avoidance of end user confusion because th= ey ] could not tell the difference between the full stops and the ability to ] specify them as different strings. ]=20 ] By choosing to fold the full stops we are saying that we believe that the= re ] will be more confusion by users who try to use one form of full stop when ] they should be using another than the confusion which will be caused for ] system administrators who desire to create accounts which only differ by ] the type of full stop used. ]=20 ] Jeffrey Altman ]=20 ]=20 ] Ienup Sung wrote: ]=20 ] >Actually that's exactly the problem that I was also talking about since ] >people will treat the Asian full stops and U+002E differently at Asian ] >countries and when people tried to register a new user account with let = say ] >3=E3=80=8214 (where it is three, Asian full-stop, and fourteen), the PLA= IN based user ] >account system could say, sorry, we already have 3.14 (that is three poi= nt ] >one four) which is totally different user account name and would deny ] >the new user account name which will be quite confusing for Asian people= . ] > ] >With regards, ] > ] >Ienup ] > ] > =20 ] > --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ) Content-type: IMAGE/jpeg; name=ATOK12-Japanese.jpg; x-unix-mode=0644 Content-transfer-encoding: BASE64 Content-disposition: attachment; filename=ATOK12-Japanese.jpg Content-description: ATOK12-Japanese.jpg Content-MD5: 35UO0f6/F0u2PYtWXN9K+w== /9j/4AAQSkZJRgABAQAAAQABAAD/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFla Y2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/ xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGh scEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4 +fr/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxO QERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhC Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj Y2NjY2P/wAARCABwAUYDABEAAREBAhEB/9oADAMAAAERAhEAPwBn8v8AP+f8 8QcYfy/z/n/PAAfy/wA/5/zwAbU3/IXi/wB5v/RbVK+Iin/GLNh/yFJP+uZ/ 9lprdm8f4kvka1M1CgCOaaOBA8rbVLKgOM8swUD8yKAJKACgCsuoWhklTzlU xAs7MCq4H3iGPBweDjoeDigCzQBC1wi3kdsQ2+SN5Ae2FKg/+hD9aAHTzR21 vJPM22OJS7tjOABkmgCSgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKAOH/wA/5/z/APWDmD/P+f8AP/1gA/z/AJ/z/wDW ANmb/kLxf7zf+i2qV8RFP+MWbD/kKSf9cz/7LTW7N4/xJfIqafYQzfabYQZj mgaJ7o2jQTYOB8zOP3jNySQAMryORVGw9Ee80+5vbttrTLHGPIjaRXVD12jJ ZGZn6dUI6c0CGNZRz6IUOnQCOO6jl2pa+WJFDKXbyj8wO3cuOSQOOoFAw1G3 idLI21qiWCrKDFJp7yKHLLg+UMEHh/mx3P8AeoApanY3g2MsVxLOljGnm7CX LLHOeoJ53iM8E/NtOc4NAF2+tp4r9bqGyyu5ikRDSB3BBGQDhN553fdBUM2W I2gHQ0hHMWNs8ckTR6dL9pXT5UuJNvlGab93keZ1JJB+fpySCcHDGNjsnnst VtY7ZDHPa4hjSya2jMo3ZO1+jcx/NxnAx904ALV7BBJp8I060WG2W53TxtYP tYbCMmLCl/mKdO4B/hoA0tHieHTY0csTliMx+XhSxKgLk7QAQADyBgHHSkIu 0AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAcP 0/z/AJ/z+gcodP8AP+f8/oAHT/P+f8/oAbM3/IXi/wB5v/RbVK+Imn/GLNh/ yFJP+uZ/9lprdm8f4kvkakiJLG0ciq6OCrKwyCD1BFM1CNEijWONVREAVVUY AA6ACgB1AEc00cCB5W2qWVAcZ5ZgoH5kUASUAFABQBSk1jTIpGjk1G0R0JVl adQQR1BGaAJ7a6t7uMyWs8U6A7S0bhgD6ZFAE1AENzdW9pGJLqeKBCdoaRwo J9MmgCCPWNMlkWOPUbR3chVVZ1JJPQAZoAu0AFAEM11BBJFHLIqNKcID37fh yQM+pA6kUATUAFABQAUAQRX1pPcPbw3UEk0ed8aSAsuDg5HUc0APjmjleVEb LQtscY6HaGx+TD86AJKACgCD7bb+T53mfu/N8nOD9/fsx/31xQBPQAUAVk1G zkuTbRXMUk4JDRxsGZcddwHT0ye+B1IoAljmjleVEbLQtscY6HaGx+TD86AJ KACgAoAKACgAoAKACgDh+n+f8/5/QOUOn+f8/wCf0ADp/n/P+f0ANmb/AJC8 X+83/otqlfETT/jFmw/5Ckn/AFzP/stNbs3j/El8ivctNaW+oXFlcTukFrL5 ksrlw0wGQVB4G3DZCgLkgY4IWjULkvaTXNpDNP5R+yfflZ2HmTMj4ZiWGVAH B46jB5oAsQRNJHf2xkunitp8IiTESMPKRtu8nd95ifvDsM44oApOr3NtYrPD FehrmSKOC4bARl83l2w24qq7e4zk5bggGR6fpaPe3qyaJpRRblVb5s+WPLjJ Cjy+eue3JP1oA1mM6+IIQ07GF7aUiIDCjDRcn1PJ59O3UkEFqZxrd6ks7SL5 MTomMKmWlGAPoBk9z6DAABl2n27bP5P9qeX9qnx5H2bZ/rX6b/m/OgY63edL PUN7XCSPqEMbmUoJNrCFTzHwPlJwRyOO9AFn90ltqMdxJdNDaTgRKk7iQ5jQ hQ24MxLOcAnqQPSgQ2eOewi0lXWW6lW7dtiybm5jlO0M5GdoOMkjIH4UAO1K 8nlghR9NuoVN1b5d2iIH75P7rk/pQBtUgM2KP7VqN9MQnnWzCG3Z13CP92GL Adckvg4IyFA7UwMie9mimVQ/mi8by5TPpM5ONjHAGRleCAoHAJJydxIM19Pi F3ZPDdt9qt+FC3Fq6HI5OQ/LDOMHGeOSxyaBEukO76equzOYpJId7HLMEdkB J7khQSfXNICPWTOsNu8U7RKLmEOqjl8yoMZ7DBOR345xkFgJq0bPgQzzi8ZS LZEkKqrD+NgOqjK53ZHAAGWwQDHi85bli7xNEwvlVPsry4BuUDBlVsvn2Ax3 zQMj0+OO01yJYYbcGcmTeNHljaPGxNqkn5QQSSegJOetAGxFE0eqm1Ml15cs Dl2lmJMxynzJg/JjcQcbeWGAccAiO0guWiuJ9OlcRzYSL7RO8mAu7Milt33s jHUYAbn7tAEEtzcxaTfWzaZam0sojDJGLx8lBGGwD5efusB1HP50DLN5ZajN JB86zJEHU4upLcyZ27WOwdRhgR05yMZwARUkvUlkSUC/FnHYw3CSRzYMIbfl nBb5+FHBD9Dwc8gyOKS7uPEGoi2uLhQ0axxSlUZBhpAcgJkbWD4z1Kct8woA sWlvFDdvDAksDC7C27bDkRJFGH64JQ7NueRkqeuDQBpa07xaJfyRsyOltIys pwQQpwQaQjO23T216NNF00W2MxrcvIjuwY+YoaT5lym0A9ATxg5NMBlyIJdA 1CWA6hbzWiy5WW5lDpIEzydxDDG0jkjn3NAzbtrZLWMpG0rAnP7yVpD+bEn8 KQiagAoAKACgDhz36f5/z/nsHKB79P8AP+f89gAPfp/n/P8AnsAbM3/IXi/3 m/8ARbVK+Imn/GLNh/yFJP8Armf/AGWmt2bx/iS+RZttKtLWMxxrK0Rj8vyp J3kTb6bWJHt0pmo5NNtUikj2O4kxuaSVnfjkYYkkYPIweDyOaAD+zbX7P5Ox 8bt+/wA1vM3YxnfndnHGc9OOnFADW0jTXVBLY28pQYDSxh26k8k5J5JJPckm gCCHw9pkctw7WFo4lkDqpt1+QbVGB+IJ/GncLl5bWBJInSNVMMZjj28BVOMg Dp/Cv5UgBoAJJZotq3EkYTewLDjJXIyOhY+n1oALS3S0to4ELMEGNzcsx7sT 3JOST3JNAFa305hFdLeyJO1zKJGMaGMKQqqMfMSCNgOc5z0pgTJp9skHkhGK +YshLOzMzKQQSxOTjaOp6ADpSAbf2s1ybZ7eZIpIJfMBeMuD8jLjAI/vevag CCay1G5EaXF7amNZY5CEtWUna4bGTIcdPSmBpUgK0toTcm5gmaKYx7DwGR8Z 27h14LE8EZzyaAKB0u/82KRby0QxzGcBbV8FirKePM4zuJ4xzz3OWBZtbK5h tGt2u0QcbHt4drKc5JO9n3E9yeeSepoAtwQx21vHBCu2OJQiLnOABgCkATQx zoElXcoZXAzjlWDA/mBQBBcabb3NwZ389ZCoQtFcSR5AJIB2kZ6n86AJIrG0 guHuIbWCOaTO+RIwGbJycnqeaAK8GnNDfpMsiC3hieOKFUOVDFSfmLHgbeAA AAcdqYE1tp9tayF4UYHG1dzswRf7qgnCjgcDA4HoKQDhbtBZJb2RSHy1VI96 lwoGBjGQTx70AV5tN36Y1jFLtjl3CZ3Xczh8lyMEAMSxOcYHpTAsXVnDd7TK HDJna8cjRsAeo3KQccDjpwPSkBHLplnNsDQ7VRQmxGKKyjorKCAy9eDkcn1N ABJazC6nubeZEklijjG+MsF2sxzgEZzv9R0oAktbVbfcxkeaZ8b5ZMbmA6Dg AADPQADknqSSAPnhjubeSCZd0cqlHXOMgjBFABPCs8TROXCt1KOyH81IIoAi XT7YWctrsZopgRJudmZ8jByxOTxxnPQD0oAs0AFABQAUAFAHEfXt/n/P+cBy h9e3+f8AP+cAB9e3+f8AP+cAGxN/yF4v95v/AEW1SviJp/xizYf8hST/AK5n /wBlprdm8f4kvkWV1W0aOWQNL5UUZkaUwOEKjqQ2MN6jBOe1M1Jpb23haVZJ MNEquwwScMSFx6klSABzn6igCrc6vDBZrciG4ZTMkW1oJFb5mAzgrnofTk8d TTAmfUrdIo5G8/8AeZ2oLeQyEDqdmNwHTnGOR6ikA2XVrGKRUe4X5o1kDAEq VOcHcBjsx69FJ6AmgCBdaT7ZLbtC25SVREbMjMDjDLxt3csvOCoLHABphY1K QFa21C2upCkLsTjcu5GUOv8AeUkYYcjkZHI9RQBWutYhSza4hb92ksStJLGy xlWcKWDHAYYJOQSOhpgT/wBpWv2fzt743bNnlN5m7GcbMbs45xjpz05pATwT R3ESyxNuRvbBBHBBB5BB4IPINAEF5JepPCLWFHjP+sLHkfOg45H8JkP1A+hA JLpLttv2SeCLGd3mwmTPpjDLj9aAC1S7Xd9rnglzjb5UJjx65yzZ/SgDJ069 1G4vNRjRYGZZwud7PHDhFBAbA3HPOwBcENkjIywL1vc3ckV1HsglubaUR5yY kfKq2f4ivDY79O2eACjo2oX9zZu0UKXJM8pErSlYgu9sKr4JftghQuOOoxQB pRXUl3aO1vH5U6sY2jn6xkH+IKTnj5gM8gjkZzSAqWN2Hu0jtdS/tONs+acx nyRjhsoAOTxg8nOR905YGtSAKAKV7NPFe6cscirFLMySLtyW/duw57cr/Ln1 ALtAGXcX87arYxWxX7KZnincj7zCNyFU+xU5PrgZ4YBgT6g1xFG8y3cVvbRx lpSYC7gDJJB3Y6dMqfx6UgM+Gz1wos0+pTjftBtkWEtHlgCTJsw2Bk4Cj0BP UsC4s076nYiVWhMlpK8kO/cFbdFxxwcZIz9aANGkBhxXOotf3lxMYoYLcxwv DGslyWONxK4C4yJFGdp6egpga1tcpdRl41lUA4/eRNGfyYA/jSAmoAKACgAo AKACgDiDx/np/n/PsHKB4/z0/wA/59gAPH+en+f8+wBsTf8AIXi/3m/9FtUr 4iaf8Ys2H/IUk/65n/2Wmt2bx/iS+QWllLB5zXMKR2nlMrW0cr3CsPZWUbQB kbVGDu6cCqNRtnZSNpLNJG09xOFIFzIUcKuNgLAEqwA3HHRyxGM0ASLYXTaa 0Mjr5gmSaNGlaQLsZWCmRhuOSp5I43YwQBQA2+sbq8a2uWjQTRK6NEl3JGMM VOfMVQT90cYxz7cgFS+8PzzRiOB4FRbVYFBLAZEUye5xmVe5OAfxLjuW77TL ue4W4iuv3vzKDuKCIEjaQBndjHKnhyeSAqgAjWpAYVjoBjt3trj/AFYtWtRI LiSRmVgASFb5Y/ujgA9ueOXcLlyaC+urfyp1t1KTQuro7HeFkVmJUj5eF4GT 1696AGS6fcC5kuYvKZxdi4jRmKhh5IiIJwcdz0PQevABb0+3e1tdkhUu0kkj beQC7liAe+N2M8Zx0FICzQBi3uqm0vzIttqF1GF8vyobWT5Gzy3ICsDwM54x xnccMAi19bnfG2n6vaZU4lezY4PtgNz35GOKLBYZpd3bWUl8q296kck4eP8A 0OYlh5aAknbnJYNknknnvQBDbXx3z28sN/HE8kjvOtpMHk3OCgUhcjCfKcgE YG08ZoGOsdTi0zTvKTTdQfE8u2KGycbUMjFTyAMYI49+lAEltqDQ29xKYpxe Ty+ayCzuDHwAoUHYD91RzjqScEcUCGrq63l5bzNYalaC3LEtLZuWkBUjYNoP GcMcnqq8HqAZZh1dvtdx50U/2b5fI2WNxv6fNuymOvTFAif+17b/AJ5Xv/gD N/8AEUAVL3UYpbqwdIL0rDOXc/YpuB5Trn7vqw/OgCzJqtu8bKq36EggMtjN lfcZQj86AMaRBE9ilveayY4pizE2BymUcFv9TySW5znO4nrzQM1ru/s7uznt pI78JNG0bFbKbIBGDj5KBFe08QSFo4bzTb9ZMfPNFaSGLOO2QG/8d6+o5osF gvNTjS8gvYra/nMUbxtEtlKGIYqcglQOCg4JHBPPGCAOt9WE9wLmaDULdFUo kBs5STkjLNhSM8cYPAzzzgAFaHU5LXS7YpbX5mMnnXMSWUm7LEuypldv3jjk /dzg5waBk/8AwkLSwSeVpmpQygqq+fZuRycFvlznaOcZGegosKxYtdZVoB9p t7tJQSp22U2GwSAw+U4yMHGTjOKAsXra5S6jLxrKoBx+8iaM/kwB/GkBNQAU AFABQBxPT/8AX0oOUOn/AOvpQAdP/wBfSgDXm/5C8X+83/otqlfETT/jE1tN HBqLvK21dmM4J549KLpM054wqS5n2ND+0bT/AJ7D/vlv8KfMivb0+4f2jaf8 9h/3y3+FHMg9vT7h/aNp/wA9h/3y3+FHMg9vT7h/aNp/z2H/AHy3+FHMg9vT 7h/aNp/z2H/fLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf8APYf98t/h RzIPb0+4f2jaf89h/wB8t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/z2 H/fLf4UcyD29PuH9o2n/AD2H/fLf4UcyD29PuH9o2n/PYf8AfLf4UcyD29Pu H9o2n/PYf98t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/wA9h/3y3+FH Mg9vT7h/aNp/z2H/AHy3+FHMg9vT7h/aNp/z2H/fLf4UcyD29PuH9o2n/PYf 98t/hRzIPb0+4f2jaf8APYf98t/hRzIPb0+4f2jaf89h/wB8t/hRzIPb0+4f 2jaf89h/3y3+FHMg9vT7h/aNp/z2H/fLf4UcyD29PuH9o2n/AD2H/fLf4Ucy D29PuH9o2n/PYf8AfLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf89h/3 y3+FHMg9vT7h/aNp/wA9h/3y3+FHMg9vT7h/aNp/z2H/AHy3+FHMg9vT7h/a Np/z2H/fLf4UcyD29PuH9o2n/PYf98t/hRzIPb0+4f2jaf8APYf98t/hRzIP b0+4f2jaf89h/wB8t/hRzIPb0+4f2jaf89h/3y3+FHMg9vT7h/aNp/z2H/fL f4UcyD29PuH9o2n/AD2H/fLf4UcyD29PuH9o2n/PYf8AfLf4UcyD29Pucl+X 50zMPy/OgA/L86ANV48asixIpldmAaSRyASjHOM4/SpW4qb/AHti0LW/MhjE 9kXUBivzZAOcHH4H8jVnZcGtb9GRWnslLnaoO4bjgnA9eAT+FAXA2t+JBGZ7 IOwLBfmyQMZOPxH5igLi/YtR/wCelp+TUBcPsWo/89LT8moC4zybzZv+02Gz ds3ZbG7dtx9c8Y9eKAHLa37s6rPZMUO1gNx2nAOD6cEH8aAuL9i1H/npafk1 AXD7FqP/AD0tPyagLh9i1H/npafk1AXD7FqP/PS0/JqAuH2LUf8Anpafk1AX D7FqP/PS0/JqAuH2LUf+elp+TUBcPsWo/wDPS0/JqAuH2LUf+elp+TUBcPsW o/8APS0/JqAuH2LUf+elp+TUBcPsWo/89LT8moC4fYtR/wCelp+TUBcPsWo/ 89LT8moC4fYtR/56Wn5NQFw+xaj/AM9LT8moC4fYtR/56Wn5NQFw+xaj/wA9 LT8moC4fYtR/56Wn5NQFw+xaj/z0tPyagLh9i1H/AJ6Wn5NQFw+xaj/z0tPy agLh9i1H/npafk1AXD7FqP8Az0tPyagLh9i1H/npafk1AXD7FqP/AD0tPyag Lh9i1H/npafk1AXD7FqP/PS0/JqAuH2LUf8Anpafk1AXD7FqP/PS0/JqAuc/ /P6/Wkcgfz+v1oAP5/X60AbDukWtQySMqIjMzMxwABG2STUr4iaf8UzZ45hq sq2kE+6eKJIBPqE6NkmUhmA5xhWbaSCAOzMRVnabD37pFHC9ip8maKKVJptz DcyhJFODvGTwx2nKnuDgEctcWRGsMhsVUAzhEW0AG0SKFIAt2zxjn5uvVc4L GbSxWiLoqahYK4+wyM0K2ZfbITESdiqdvJPYdaQGjpotxfsNOh+zWyxfvYjE YdzkjawQgEcBwWwM8DJ2/KCMzxB5MX2eKddPuW3MZZZ0j37xsK5BkTkrt3Y6 4HABxQNDPCVxFPe74rXT4jLB5kn2dEV1PyDaAJGO31yF5A7mhgzrKQgoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KAOJz/nP1oOUM/5z9aADP+c/WgDUu7dLvUltpCwSbfGxXqAYmBxUr4iaf8U0 YrCeO8a+eWKa6MLRkeXsU8gqAfmKgfNnrktnsALOwZNp1xcHfJJEs0hR3YAs E8tt0aKOMgMSSTgnnpkbQCkdEzcJL/YOkDarLsEvynJByR5PUY4+poHc0rSx 8qW2m8mC28mKSPyIOUG9lOQcD+76d/zBFgW22/e6V/8AWRLG6kf3SSpB7feb Prx0xygMptGuZVQNO0Mkg33E8VzKCXJOQqggcZAVmzgKAQQKYE1jpD6fdp5M jyWq5CK9zLmIY4G3JVxzgcLgAdTzQBrUgCgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA4r/AD/P3oOUP8/z96AD /P8AP3oAs3epRpqBeJJWaNvldF4zjBx+tTZ3ujNxlzc0WH9vz+lz/wB8Cj3g /e9w/t+f0uf++BR7wfve4q69OWYkzgBDgbOS2R/TdRqUnUs9RP7fn9Ln/vgU e8T+97h/b8/pc/8AfAo94P3vcP7fn9Ln/vgUe8H73uH9vz+lz/3wKPeD973D +35/S5/74FHvB+97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP8A 3wKPeD973D+35/S5/wC+BR7wfve4f2/P6XP/AHwKPeD973D+35/S5/74FHvB +97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP/fAo94P3vcP7fn9 Ln/vgUe8H73uH9vz+lz/AN8Cj3g/e9w/t+f0uf8AvgUe8H73uH9vz+lz/wB8 Cj3g/e9w/t+f0uf++BR7wfve4f2/P6XP/fAo94P3vcP7fn9Ln/vgUe8H73uH 9vz+lz/3wKPeD973D+35/S5/74FHvB+97h/b8/pc/wDfAo94P3vcP7fn9Ln/ AL4FHvB+97h/b8/pc/8AfAo94P3vcP7fn9Ln/vgUe8H73uH9vz+lz/3wKPeD 973D+35/S5/74FHvB+97h/b8/pc/98Cj3g/e9w/t+f0uf++BR7wfve4f2/P6 XP8A3wKPeD973D+35/S5/wC+BR7wfve4f2/OOouP++BR7w/3vcrH/PNUWB/z zQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8A PNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/z zQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8A PNAAf880AB/zzQAH/PNAAf8APNAAf880AB/zzQAH/PNAAf8APNACMePx9f8A 69AC/n+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dA B+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/ nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB +f50AH5/nQAfn+dAB+f50AH5/nQAfn+dAB+f50AH5/nQAfn+dACMePx9f/r0 Af/Z --Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KGnkT051434 for ; Fri, 7 Nov 2003 12:16:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7KGniX051433 for ietf-sasl-bks; Fri, 7 Nov 2003 12:16:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KGlkT051427 for ; Fri, 7 Nov 2003 12:16:47 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7KGbB9020077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Nov 2003 15:16:45 -0500 (EST) Message-ID: <3FABFD99.8010107@columbia.edu> Date: Fri, 07 Nov 2003 15:16:25 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> In-Reply-To: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060403050102060802000005" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060403050102060802000005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit It is absolutely a trade off. Avoidance of end user confusion because they could not tell the difference between the full stops and the ability to specify them as different strings. By choosing to fold the full stops we are saying that we believe that there will be more confusion by users who try to use one form of full stop when they should be using another than the confusion which will be caused for system administrators who desire to create accounts which only differ by the type of full stop used. Jeffrey Altman Ienup Sung wrote: >Actually that's exactly the problem that I was also talking about since >people will treat the Asian full stops and U+002E differently at Asian >countries and when people tried to register a new user account with let say >3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user >account system could say, sorry, we already have 3.14 (that is three point >one four) which is totally different user account name and would deny >the new user account name which will be quite confusing for Asian people. > >With regards, > >Ienup > > > --------------ms060403050102060802000005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwNzIwMTYyNVowIwYJKoZIhvcNAQkEMRYEFDu7NOJQKEDW EZbQ0eF75sbu1x+QMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAtV0OcgT6ZT6hqTqs4GWeurOp3c8B BkxBB4DijlFg1gopxa8bCywF8+ZRk0/PuIuXtNkhDVRYhFaZvVfXvEaoD+ByEm4ujhFlpuk3 J3clZTya6lF20bO/4zerMkkm6Kuu0wLc41TySbrf6TZAfhQN4dnqce+xhZHpJp4gigvB8+Cf q8QHohmdwstU0PUHfTpeOoZWrSpk752/JgVFIGg2//p6h8z4vrHumrMnYPICXf4x/RsXsWZ7 XWA0sfw/OERNA9QM757CCBG8HeFS1KvzfSxg6Y98bo19NKKd4QqDFbxbryK7++hI5+73PP/L QD5LcCNP/V1+JPEnpRKYUul3PgAAAAAAAA== --------------ms060403050102060802000005-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7JZlkT050089 for ; Fri, 7 Nov 2003 11:35:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7JZlBd050088 for ietf-sasl-bks; Fri, 7 Nov 2003 11:35:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7JZkkT050083 for ; Fri, 7 Nov 2003 11:35:46 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA7JZk5u011478; Fri, 7 Nov 2003 12:35:46 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA7JZbDS009564; Fri, 7 Nov 2003 11:35:37 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNZ00IWCYFLIA@mpkmail.eng.sun.com>; Fri, 07 Nov 2003 11:35:46 -0800 (PST) Date: Fri, 07 Nov 2003 11:35:46 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNZ00IWDYFMIA@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=UTF-8 Content-MD5: cvDLdFlktZQJJSr4KNqsHw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA7JZkkT050084 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually that's exactly the problem that I was also talking about since people will treat the Asian full stops and U+002E differently at Asian countries and when people tried to register a new user account with let say 3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user account system could say, sorry, we already have 3.14 (that is three point one four) which is totally different user account name and would deny the new user account name which will be quite confusing for Asian people. With regards, Ienup ] Date: Thu, 06 Nov 2003 21:21:08 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] The question is not whether or not the different full stops are used by ] different people in different ways at the user interface level. The ] transformations ] we are discussing for use with SASLPrep are specific to the use of the ] strings ] as Storage and Query strings; not as Display strings. When a string is ] to be used ] as a username or a password is there a reason why we should be concerned ] with ] distinguishing the differences? If there is not a good reason to ] preserve the ] differences then there is a reasonable argument to fold them similar to ] the arguments ] for folding spacing characters. ] ] Users will always be free to choose one representation over another. It ] is only ] on the wire that there should be a distinction. ] ] Jeffrey Altman ] ] ] Ienup Sung wrote: ] ] >I think there will be problems if we treat the Asian full stops as equivalents ] >to the ASCII decimal point/dot/full stop character simply because the Asian ] >full stops are not equivalent to the ASCII decimal points all the time. ] >In other words, Asian people are and will distinguish (almost implicitly) when ] >to use the Asian/ASCII full stops and when to use the decimal point character; ] >if coerced at the protocol level that the Asian full stops are all ] >mapped to the U+002E for all the cases, people will be, sometimes, confused. ] > ] >I do see the pros of convenience but that will, in my opinion, come in with ] >the price of denying the fact that the Asian full stops are only and ] >conditionally equivalent to the U+002E (when the U+002E means the full stop). ] >In other words, by having the general full stop mappings, we are denying ] >the possibility of Asian people using the full stops and decimal points ] >differently in their user names and passwords. ] > ] > ] > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA72LLkT041479 for ; Thu, 6 Nov 2003 18:21:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA72LLUc041478 for ietf-sasl-bks; Thu, 6 Nov 2003 18:21:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA72LJkT041473 for ; Thu, 6 Nov 2003 18:21:20 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hA72LIBU008619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Nov 2003 21:21:20 -0500 (EST) Message-ID: <3FAB0194.2090808@columbia.edu> Date: Thu, 06 Nov 2003 21:21:08 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNY0013YHBQT5@mpkmail.eng.sun.com> In-Reply-To: <0HNY0013YHBQT5@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020500020203020202030107" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020500020203020202030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The question is not whether or not the different full stops are used by different people in different ways at the user interface level. The transformations we are discussing for use with SASLPrep are specific to the use of the strings as Storage and Query strings; not as Display strings. When a string is to be used as a username or a password is there a reason why we should be concerned with distinguishing the differences? If there is not a good reason to preserve the differences then there is a reasonable argument to fold them similar to the arguments for folding spacing characters. Users will always be free to choose one representation over another. It is only on the wire that there should be a distinction. Jeffrey Altman Ienup Sung wrote: >I think there will be problems if we treat the Asian full stops as equivalents >to the ASCII decimal point/dot/full stop character simply because the Asian >full stops are not equivalent to the ASCII decimal points all the time. >In other words, Asian people are and will distinguish (almost implicitly) when >to use the Asian/ASCII full stops and when to use the decimal point character; >if coerced at the protocol level that the Asian full stops are all >mapped to the U+002E for all the cases, people will be, sometimes, confused. > >I do see the pros of convenience but that will, in my opinion, come in with >the price of denying the fact that the Asian full stops are only and >conditionally equivalent to the U+002E (when the U+002E means the full stop). >In other words, by having the general full stop mappings, we are denying >the possibility of Asian people using the full stops and decimal points >differently in their user names and passwords. > > > --------------ms020500020203020202030107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEwNzAyMjEwOFowIwYJKoZIhvcNAQkEMRYEFLTXMmqjlhNl 7TvuiG+w5WeSE8pbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAACslROIT5rqbi2N+JiyjJe7cMXdq FntX0j08ngYKjBwyv0b3OlQBFWcK84uM8+lbJf89qpVRAYElPcZL5/DhGqG8KxR6smuOw6m0 flp60/oOoi68ndqTKHh8meKPhsRJ/3OeHXsFc3j//DR8JOVdDOFwKv0KCesdRxeDNewJ82sF tG9bLkhEk3zPY0vnae5q9lRfmMvte0sRa/XyTj+LoZHBAlRRXIaO3DeRwzpp88gevgff3bG1 MuWGk4L0yr3SQQdfBuupryHTGU0F3+AQH04wVbWl584LUGrK06cCgR9JcaME1bH5/LVBBjYr 0LeVUuGVfrUP3rH1tW35vUXtewAAAAAAAA== --------------ms020500020203020202030107-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71l9kT039951 for ; Thu, 6 Nov 2003 17:47:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA71l9VM039949 for ietf-sasl-bks; Thu, 6 Nov 2003 17:47:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71l7kT039944 for ; Thu, 6 Nov 2003 17:47:07 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA71l8Wj031547; Thu, 6 Nov 2003 20:47:08 -0500 Date: Thu, 6 Nov 2003 20:47:08 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <6.0.0.22.0.20031106141242.04a26900@127.0.0.1> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@isode.com> <6.0.0.22.0.20031106141242.04a26900@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: On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > If the layers are active between the client and server AA, > then the middlebox could not normally insert a re-authenication to > server BB without coordination from AA. That is, the middle > box would need to know how to decrypt/encrypt the exchanges > (before, during, after reauthentication). If AA doesn't trust > the middlebox (and its relations with the likes of BB), then AA > simply need not provide the secrets to the middlebox necessary > to support reauthentication with others. If AA does trust > the middlebox, then it implicitly accepts the risk of that trust. > > If the layers are active between the client and middlebox, > the middlebox likely would need cooperation from AA to > support reauthentication to BB. (In this case, it would be > better to call the middlebox the SASL server and AA and BB > "external systems" (not servers).) If AA doesn't trust the > middlebox, then it should not cooperate with it. But if it > does, even if layers are dropped, it (AA) would be vulnerable > to attack from BB because the subsequent exchange (which > BB has knowledge of) is protected by those layers. Ah, I think I misunderstood the example slightly [didn't understand how the middlebox was playing with the rest of the system]. However, I still agree with Kurt -- this is a minimal case that can be dismissed with a Security Consideration about the trust relationships involved. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA70SdkT037271 for ; Thu, 6 Nov 2003 16:28:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA70Sdfr037270 for ietf-sasl-bks; Thu, 6 Nov 2003 16:28:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA70SckT037265 for ; Thu, 6 Nov 2003 16:28:38 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA70Sc5u016065; Thu, 6 Nov 2003 17:28:39 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA70SUDS005048; Thu, 6 Nov 2003 16:28:30 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNY0013XHBQT5@mpkmail.eng.sun.com>; Thu, 06 Nov 2003 16:28:38 -0800 (PST) Date: Thu, 06 Nov 2003 16:28:38 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNY0013YHBQT5@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: rzDg7/uVrejlQtuahVpKbg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, the POSIX/SUS/XPG specifies that the poratble user names be in the portable file name character set and it includes [A-Za-z._-] with some additional rules. I also have seen many people using the 0x2e in their user names and passwords. And, while I believe I do understand that the SASLprep is intended for simple user names and passowrds at the moment, I believe I'm seeing the full stops vs decimal point issue a bit differently... (and maybe in that way, I'm wrong about it...) I think there will be problems if we treat the Asian full stops as equivalents to the ASCII decimal point/dot/full stop character simply because the Asian full stops are not equivalent to the ASCII decimal points all the time. In other words, Asian people are and will distinguish (almost implicitly) when to use the Asian/ASCII full stops and when to use the decimal point character; if coerced at the protocol level that the Asian full stops are all mapped to the U+002E for all the cases, people will be, sometimes, confused. I do see the pros of convenience but that will, in my opinion, come in with the price of denying the fact that the Asian full stops are only and conditionally equivalent to the U+002E (when the U+002E means the full stop). In other words, by having the general full stop mappings, we are denying the possibility of Asian people using the full stops and decimal points differently in their user names and passwords. I personally can live with such general mappings and so thus many other Asians in my opinion but when we do know about the fact that the characters are different and virtually and practically we are not capable of distinguishing when the two groups of characters can be treated equal or not with the Stringprep and SALSprep, it seems to me that it is not really a good idea to have a generic, simple table-driven mappings at the SASLprep (even for the simple user names and passwords)... Should more opinions needed and if the WG folks agree and assign to me, I can bring this exactly the same question of whether we can treat the Asian full stops as the decimal point to the Unicode Technical Committee and get the opinion of the UTC back to the WGs. With regards, Ienup PS. By the way, on a bit different topic, reading the SALSprep and also the PLAIN mechanism drafts, it appears there is no AllowUnassigned flag setting or mentioning of it in the drafts. Has this issue been discussed and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft? If not, it seems either explicitly defining that the unassigned Unicode characters are not allowed in the drafts, or, allow setting of the AllowUnassigned flag as either True or False at the PLAIN draft appears necesary so that the versioning issue is clearly stated... If this question has been asked and answered, sorry, please let me know and I'll scan more of the archived emails. ] Date: Thu, 06 Nov 2003 16:35:13 -0500 ] From: Sam Hartman ] Subject: Re: SASLPrep vs Full Stop code points ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] ] >>>>> "Ienup" == Ienup Sung writes: ] ] Ienup> I agree that the SASLprep is more suitable and applicable ] Ienup> for simple user names and passwords and if the additional ] Ienup> mappings such as the full stops are needed, they are more ] Ienup> suitable and correct to be done at the outside of any ] Ienup> Stringprep/Stringprep profiles and most preferrably before ] Ienup> the application of the Stringprep profile(s). <-- These are ] Ienup> also my points all along. ] ] I think Kurt's point was that since saslprep was for usernames and ] passwords, it is more appropriate to do full-stop mappings there than ] in some more general context. Do we expect people to need decimal ] points in their usernames? Do we think it a problem if someone uses a ] decimal point in a password, but can later use one of the other ] full-stop characters and have it work? ] ] --Sam ] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6NY3kT035593 for ; Thu, 6 Nov 2003 15:34:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6NY34i035592 for ietf-sasl-bks; Thu, 6 Nov 2003 15:34:03 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6NXwkT035587 for ; Thu, 6 Nov 2003 15:33:58 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6NY0lg048275; Thu, 6 Nov 2003 23:34:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106141242.04a26900@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 15:33:03 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: 'selects no security layer' Cc: ietf-sasl@imc.org In-Reply-To: <3FAAB9B2.2000206@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@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 01:14 PM 11/6/2003, Alexey Melnikov wrote: >Actually, I am not sure I understand what are you saying here Kurt. Part of the problem here is that I am (and maybe others are) having trouble making sense of your scenario. After further examination, I think your text and picture don't match up. The text implies the layers are active between the client and the Realm A server called AA, but your picture implies the layers are active between the client and the middlebox ("proxy/frontend"). If the layers are active between the client and server AA, then the middlebox could not normally insert a re-authenication to server BB without coordination from AA. That is, the middle box would need to know how to decrypt/encrypt the exchanges (before, during, after reauthentication). If AA doesn't trust the middlebox (and its relations with the likes of BB), then AA simply need not provide the secrets to the middlebox necessary to support reauthentication with others. If AA does trust the middlebox, then it implicitly accepts the risk of that trust. If the layers are active between the client and middlebox, the middlebox likely would need cooperation from AA to support reauthentication to BB. (In this case, it would be better to call the middlebox the SASL server and AA and BB "external systems" (not servers).) If AA doesn't trust the middlebox, then it should not cooperate with it. But if it does, even if layers are dropped, it (AA) would be vulnerable to attack from BB because the subsequent exchange (which BB has knowledge of) is protected by those layers. In either case, this risk is quite limited and can be managed as part of the trust relationship between AA and the middlebox. I think these scenarios are part of a larger class of vulnerabilities: attacks from 3rd parties which have limited knowledge of information protected by the SASL. I think this class of vulnerabilities is best addressed by stating a broad security consideration (possibly supported by one or two specific examples). Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MvQkT034362 for ; Thu, 6 Nov 2003 14:57:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6MvQCI034361 for ietf-sasl-bks; Thu, 6 Nov 2003 14:57:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-FOURTEEN.MIT.EDU [18.187.5.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MvPkT034356 for ; Thu, 6 Nov 2003 14:57:25 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 3F2C215159E; Thu, 6 Nov 2003 17:56:57 -0500 (EST) To: Lyndon Nerenberg Cc: Ienup Sung , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> <2147483647.1068133052@[192.168.42.6]> From: Sam Hartman Date: Thu, 06 Nov 2003 17:56:57 -0500 In-Reply-To: <2147483647.1068133052@[192.168.42.6]> (Lyndon Nerenberg's message of "Thu, 06 Nov 2003 15:37:32 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> firstname.lastname is a very common scheme for forming Lyndon> identifiers, so yes we do need to support decimal points Lyndon> (and their equivalent mappings) in usernames. But it seems like in this case mapping all the full stops together would be desirable. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MbnkT033566 for ; Thu, 6 Nov 2003 14:37:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Mbn0H033565 for ietf-sasl-bks; Thu, 6 Nov 2003 14:37:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MbmkT033559 for ; Thu, 6 Nov 2003 14:37:48 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hA6Mbbdo011266; Thu, 6 Nov 2003 15:37:39 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 06 Nov 2003 15:37:32 -0700 From: Lyndon Nerenberg To: Sam Hartman , Ienup Sung cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <2147483647.1068133052@[192.168.42.6]> In-Reply-To: References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: > I think Kurt's point was that since saslprep was for usernames and > passwords, it is more appropriate to do full-stop mappings there than > in some more general context. Do we expect people to need decimal > points in their usernames? firstname.lastname is a very common scheme for forming identifiers, so yes we do need to support decimal points (and their equivalent mappings) in usernames. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MTtkT033049 for ; Thu, 6 Nov 2003 14:29:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6MTsuL033048 for ietf-sasl-bks; Thu, 6 Nov 2003 14:29:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6MTrkT033042 for ; Thu, 6 Nov 2003 14:29:53 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA6MTsWj009655; Thu, 6 Nov 2003 17:29:54 -0500 Date: Thu, 6 Nov 2003 17:29:54 -0500 (EST) From: Rob Siemborski To: Alexey Melnikov cc: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <3FAAB9B2.2000206@isode.com> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> <3FAAB9B2.2000206@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: On Thu, 6 Nov 2003, Alexey Melnikov wrote: > >>I think one of the problems we have adding this profile option > >>is that the specification is now much more complex and > >>framework implementations, especially those which support both > >>options, will need to be much more complex. We need to keep > >>SASL and the specification of SASL simple. > > > >I have to agree with Kurt here. One of the major benefits of SASL is that > >the framework layer has been historically simple. Allowing both modes > >(dropping the layer or continuing under the old layer) needlessly > >complicates the implementation > > Which implementation are you talking about? I'll use the CMU SASL implementation as an example, but I don't think it really matters. Using RFC2222, if you had a re-authentication and the new session didn't have a security layer, you would need to keep the old SASL context around and continue to use it for security layer purposes (from an API standpoint, this sucks, granted). In 2222bis-03, you no longer have to do this, but it breaks LDAP as deployed (which is bad). In your suggested text, there's no longer a set way of handling this -- it varies from protocol to protocol (as long as they allow reauthentication). And its yet another thing that can be gotten wrong in an implementation. In any case though, I suppose this is application layer not framework layer. Due to the related nature of many of the protocols that implement SASL, we often see one product using SASL for many protocols at once (a mail client can implement POP3, IMAP, SMTP, LDAP and IMSP/ACAP without breaking a sweat, and a mail server can come close to twice that). Subtle differences between these protocols can be a nightmare for implementors (just look at how similar the new POP3 and SMTP profiles are, yet how they both have subtle differences). I fear what will happen when we have another protocol that allows reauthentication but does it in a different way from LDAP. Then again, maybe you're right and the benefits of allowing it both ways outweigh the implementation complexity -- especially given the (somewhat inevitable, I think) upcoming "SASL Implementation Recommendations" document. > True. But it is more difficult to implement an attack during > reauthentication. And servers should drop connection after some number > of failed authentications. Are we both talking about the vulnerability discussed at the bottom of section 6.3? I may be misunderstanding the problem -- as I read it, we don't want the initial realm to be able to read traffic going to the newly-authenticated realm. But if the new authentication doesn't have a security layer, how is dropping the old security layer any benefit? We're moving from a tunneled layer (which, granted, can be read/modified by the initial realm) to one that can be read/modified by anyone! I definitely see a win with forcing a change when the new authentication creates a new security layer, but in the absence of a new security layer, I'm not seeing the benefit. > >> The > >>information sent under the subsequent layers is still contains > >>information known by those involved in the reauthentication. > >> > Actually, I am not sure I understand what are you saying here Kurt. Now that I re-read this, I'm not sure it applies to the vulnerability discussed in 6.3. However, it is true that if I know a good deal of the plaintext that you are sending encrypted (e.g. I am a backend server and you are a proxy), I have a huge advantage in trying to break your session key with a client. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LZbkT031268 for ; Thu, 6 Nov 2003 13:35:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LZbcl031267 for ietf-sasl-bks; Thu, 6 Nov 2003 13:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-FOURTEEN.MIT.EDU [18.187.5.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LZakT031262 for ; Thu, 6 Nov 2003 13:35:36 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 20FFF15159E; Thu, 6 Nov 2003 16:35:13 -0500 (EST) To: Ienup Sung Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> From: Sam Hartman Date: Thu, 06 Nov 2003 16:35:13 -0500 In-Reply-To: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> (Ienup Sung's message of "Mon, 03 Nov 2003 11:51:56 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Ienup" == Ienup Sung writes: Ienup> I agree that the SASLprep is more suitable and applicable Ienup> for simple user names and passwords and if the additional Ienup> mappings such as the full stops are needed, they are more Ienup> suitable and correct to be done at the outside of any Ienup> Stringprep/Stringprep profiles and most preferrably before Ienup> the application of the Stringprep profile(s). <-- These are Ienup> also my points all along. I think Kurt's point was that since saslprep was for usernames and passwords, it is more appropriate to do full-stop mappings there than in some more general context. Do we expect people to need decimal points in their usernames? Do we think it a problem if someone uses a decimal point in a password, but can later use one of the other full-stop characters and have it work? --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LEXkT030402 for ; Thu, 6 Nov 2003 13:14:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LEXMT030401 for ietf-sasl-bks; Thu, 6 Nov 2003 13:14:33 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6LEVkT030395 for ; Thu, 6 Nov 2003 13:14:32 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 21:15:38 +0000 Message-ID: <3FAAB9B2.2000206@isode.com> Date: Thu, 06 Nov 2003 21:14:26 +0000 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: Rob Siemborski CC: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> In-Reply-To: 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: Rob Siemborski wrote: >On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > > >>At 02:52 AM 11/6/2003, Alexey Melnikov wrote: >> >> >>>I would welcome any suggestions to make this clearer. >>> >>> >>I think one of the problems we have adding this profile option >>is that the specification is now much more complex and >>framework implementations, especially those which support both >>options, will need to be much more complex. We need to keep >>SASL and the specification of SASL simple. >> >> > >I have to agree with Kurt here. One of the major benefits of SASL is that >the framework layer has been historically simple. Allowing both modes >(dropping the layer or continuing under the old layer) needlessly >complicates the implementation > Which implementation are you talking about? > and breaks backwards compatibility for >minimal gain. > A protocol profile is not allowed to do both. It has to document a choice. This is a checkbox. There is only a single protocol that currently allows for reauthentication. >>I don't see the risk from the described threat being so high >>to warrant the insertion of this option ESPECIALLY given that >>the option doesn't not fully address the vulnerability. >> True. But it is more difficult to implement an attack during reauthentication. And servers should drop connection after some number of failed authentications. >> The >>information sent under the subsequent layers is still contains >>information known by those involved in the reauthentication. >> Actually, I am not sure I understand what are you saying here Kurt. >I tend to agree with this assessment. > > Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IvKkT024542 for ; Thu, 6 Nov 2003 10:57:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6IvK48024541 for ietf-sasl-bks; Thu, 6 Nov 2003 10:57:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IvDkT024534 for ; Thu, 6 Nov 2003 10:57:14 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA6IvDWj005150; Thu, 6 Nov 2003 13:57:13 -0500 Date: Thu, 6 Nov 2003 13:57:14 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> Message-ID: References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> <6.0.0.22.0.20031106071007.048a7428@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: On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote: > At 02:52 AM 11/6/2003, Alexey Melnikov wrote: > >I would welcome any suggestions to make this clearer. > > I think one of the problems we have adding this profile option > is that the specification is now much more complex and > framework implementations, especially those which support both > options, will need to be much more complex. We need to keep > SASL and the specification of SASL simple. I have to agree with Kurt here. One of the major benefits of SASL is that the framework layer has been historically simple. Allowing both modes (dropping the layer or continuing under the old layer) needlessly complicates the implementation and breaks backwards compatibility for minimal gain. > I don't see the risk from the described threat being so high > to warrant the insertion of this option ESPECIALLY given that > the option doesn't not fully address the vulnerability. The > information sent under the subsequent layers is still contains > information known by those involved in the reauthentication. I tend to agree with this assessment. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6H1lkT019060 for ; Thu, 6 Nov 2003 09:01:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6H1lQx019059 for ietf-sasl-bks; Thu, 6 Nov 2003 09:01:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6H1jkT019051 for ; Thu, 6 Nov 2003 09:01:45 -0800 (PST) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hA6H1fmW031162 for ; Thu, 6 Nov 2003 12:01:41 -0500 Received: from att.com (tony-ob.mt.att.com[135.91.110.124](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031106165844gw100lr6g3e> (Authid: tony); Thu, 6 Nov 2003 16:58:44 +0000 Message-ID: <3FAA7E9E.3080704@att.com> Date: Thu, 06 Nov 2003 12:02:22 -0500 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 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: Section "4.2. Authorization identities and proxy authentication", appears to be mixing two totally different discussions together in a slightly confusing mess. The first discussion is about there being two IDs being passed through the mechanism (the authorization identity and the authentication identity) and how they are used, including what it means for the authorization identity to be empty and non-empty. The second discussion that's intermingled with the first discussion is about the format of the two identities. For example, consider this sentence: While some legacy mechanisms are incapable of transmitting an authorization identity other than the empty string, newly defined mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character). This sentence starts by saying that some legacy mechanisms don't provide an authorization identity, but newly defined mechanisms are expected to. But it never finishes saying that. Instead, it diverts the sentence into discussing what the authorization identity should look like. May I suggest that this section be rewritten so that it focusses on the two topics separately. For example, something like the following below might be considered. Tony Hansen tony@att.com 4.2. Authorization and authentication identities, and proxy authentication SASL authentication deals with two identities: the authorization identity and the authentication identity. The transmitted authorization identity may be an empty string (zero length), but the transmitted authentication identity may not be an empty string. (While some legacy mechanisms are incapable of transmitting an authorization identity other than the empty string, newly defined mechanisms SHOULD be capable of transmiting a non-empty authorization identity.) The authorization identity is used by the server as the primary identity for making access policy decisions. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive the authorization identity from the client's authentication identity. If the authorization identity transmitted during the authentication protocol exchange is not the empty string, this is typically referred to as "proxy authentication". This feature permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. The server makes an implementation defined policy decision as to whether the authentication identity is permitted to have the access privileges of the authorization identity and whether the authorization identity is permitted to receive service. If it is not, the server indicates failure of the authentication protocol exchange. As a client might not have the same information as the server, clients SHOULD NOT themselves try to derive authorization identities from authentication identities when clients could instead transmit an authorization identity of the empty string. The server SHOULD verify the correctness of a received authorization identity. Profiles whose authorization identities are simple user names (e.g. IMAP [RFC 3501]) are encouraged to employ [SASLPrep] profile [SASLPrep] of the "stringprep" algorithm [StringPrep] to prepare these names for matching. If the preparation of the authorization identity fails or results in an empty string, the server MUST fail the authentication exchange. The only exception to this rule is when the received authorization identity is already the empty string. 4.x Authorization Identity and Authentication Identity Formats An authorization identity and an authentication identity are strings of ISO 10646 [ISO-10646] coded characters. The NUL (U+0000) character is not permitted in authorization or authentication identities. The character encoding scheme used for transmitting an authorization identity over a protocol is specified in each authentication mechanism (with the authentication mechanism's blob being further restricted/encoded by the protocol profile). Per IETF character set policy [CHARSET-POLICY], authentication mechanisms SHOULD encode these and other strings in UTF-8 [UTF-8]. Mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character). An authorization identity of the empty string and and an absent authorization identity MUST be treated as equivalent. However, mechanisms SHOULD NOT allow both (i.e. if an authorization identity is allowed to be absent, but one is transferred, it SHOULD NOT be an empty string). Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6G7tkT016432 for ; Thu, 6 Nov 2003 08:07:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6G7toF016431 for ietf-sasl-bks; Thu, 6 Nov 2003 08:07:55 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6G7skT016425 for ; Thu, 6 Nov 2003 08:07:54 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 16:09:02 +0000 Message-ID: <3FAA71D7.3090908@isode.com> Date: Thu, 06 Nov 2003 16:07:51 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>rfc2222bis says: >>> >>> >>>>If a security layer is in effect and a subsequent SASL negotiation >>>>selects no security layer, (...) >>>> >>>> >>>Please rephrase as either 'does not select a security layer' (like >>>PLAIN) or '(explicitly) selects that there should be no security layer' >>>(which PLAIN does _not_ do). I presume it's the former. >>> >>> >>No, I actually mean both. >> >> > >Now I'm confused. If a SASL security layer is active and I authenticate >with PLAIN, is the layer removed or not? If it is removed, my first >suggested text above clarifies that. If it is not, my second text. Are >there other alternatives? > Using your own words: PLAIN (implicitly) selects that there should be no security layer, as it is unable to negotiate any. >>DIGEST-MD5 has a mode when you can explicitly >>negotiate no security layer. >> >> > >Where? A search for 'layer' in rfc2831bis-02 only turns up the >reference > > [RFC 2222] Myers, J., "Simple Authentication and Security Layer > (SASL)", RFC 2222, October 1997. > Sections 2.3 and 2.4. Also search for "qop-options" Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Fc0kT014810 for ; Thu, 6 Nov 2003 07:38:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Fc0xf014809 for ietf-sasl-bks; Thu, 6 Nov 2003 07:38:00 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FbxkT014802 for ; Thu, 6 Nov 2003 07:37:59 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHmCq-0005Ka-1x; Thu, 06 Nov 2003 16:37:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHmCn-0001y8-S5; Thu, 06 Nov 2003 16:37:53 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHmCn-00019w-00; Thu, 6 Nov 2003 16:37:53 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer In-Reply-To: <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:37:53 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 02:58 AM 11/6/2003, Alexey Melnikov wrote: > >> IMHO, there is no point in a layer with a null cipher, it just adds >> unnecessary SASL framing. Unless of course the layer does something >> else. > > It replaces the previous layers. Hallvard wanted a way to do that, > I assume for application protocols which only replace layers (don't > deinstall them). Yes. It was a mistake to mention this in relation to an ANONYMOUS-like auth, though. It belongs in the 'selects no security layer' thread. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Fa7kT014707 for ; Thu, 6 Nov 2003 07:36:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Fa7a5014706 for ietf-sasl-bks; Thu, 6 Nov 2003 07:36:07 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6Fa6kT014699 for ; Thu, 6 Nov 2003 07:36:06 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHmAz-00058I-0D; Thu, 06 Nov 2003 16:36:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHmAw-0001k0-24; Thu, 06 Nov 2003 16:35:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHmAs-00019i-00; Thu, 6 Nov 2003 16:35:54 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer In-Reply-To: <3FAA293C.1000206@isode.com> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:35:54 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Kurt D. Zeilenga wrote: >>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >> >>> Looking over the various SASL drafts, I miss one piece of functionality: >>> To authenticate anonymously, removing any SASL layer, but still >>> providing an unauthenticated ID (e.g. for logging purposes). >>> > How is this different from ANONYMOUS (except for @ sign requirement). That's the difference. If there is nothing special about the '@' character in the underlying auth IDs, then the exclusion of names with '@' in them is unnatural. Though one could of course introduce a private hack like using \ for a quote character and type @ as \40, or something. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FMVkT014087 for ; Thu, 6 Nov 2003 07:22:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FMV9p014086 for ietf-sasl-bks; Thu, 6 Nov 2003 07:22:31 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FMUkT014080 for ; Thu, 6 Nov 2003 07:22:30 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AHlxq-0003Rb-4X; Thu, 06 Nov 2003 16:22:26 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AHlxk-0007zM-W1; Thu, 06 Nov 2003 16:22:20 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHlxk-00017M-00; Thu, 6 Nov 2003 16:22:20 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FAA23DE.7000508@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA23DE.7000508@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:22:20 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>Alexey Melnikov writes: >> >>>Also note, that if a subsequent authentication fails, >>>the protocol profile MAY allow the connection state to return to >>>non-authenticated, >> >>I can't find anything about that in section 5. Is it this text? >> >> "A protocol profile MAY further refine the definition of an >> authorization identity by adding additional syntactic restrictions >> and protocol-specific semantics." >> > No. > This is a new text added to allow for LDAP behaviour. That it allows for LDAP is fine, but I'm wondering about the text 'the protocol profile MAY allow the connection state to return to non-authenticated'. If it's not the text I quoted, allowing the connection state to return to non-authenticated has nothing to do with the protocol profile at all. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FIxkT013907 for ; Thu, 6 Nov 2003 07:18:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FIx8i013906 for ietf-sasl-bks; Thu, 6 Nov 2003 07:18:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FIvkT013899 for ; Thu, 6 Nov 2003 07:18:58 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AHluR-00034q-MJ; Thu, 06 Nov 2003 16:18:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AHluQ-0007Zn-2E; Thu, 06 Nov 2003 16:18:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHluM-000172-00; Thu, 6 Nov 2003 16:18:50 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' In-Reply-To: <3FAA27EE.50808@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 16:18:50 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>rfc2222bis says: >> >>>If a security layer is in effect and a subsequent SASL negotiation >>>selects no security layer, (...) >> >>Please rephrase as either 'does not select a security layer' (like >>PLAIN) or '(explicitly) selects that there should be no security layer' >>(which PLAIN does _not_ do). I presume it's the former. >> > No, I actually mean both. Now I'm confused. If a SASL security layer is active and I authenticate with PLAIN, is the layer removed or not? If it is removed, my first suggested text above clarifies that. If it is not, my second text. Are there other alternatives? > DIGEST-MD5 has a mode when you can explicitly > negotiate no security layer. Where? A search for 'layer' in rfc2831bis-02 only turns up the reference [RFC 2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FFLkT013754 for ; Thu, 6 Nov 2003 07:15:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FFLV9013753 for ietf-sasl-bks; Thu, 6 Nov 2003 07:15:21 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FFKkT013748 for ; Thu, 6 Nov 2003 07:15:20 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6FFLlg042692; Thu, 6 Nov 2003 15:15:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106071007.048a7428@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 07:14:25 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: 'selects no security layer' Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FAA27EE.50808@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> <3FAA27EE.50808@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 02:52 AM 11/6/2003, Alexey Melnikov wrote: >I would welcome any suggestions to make this clearer. I think one of the problems we have adding this profile option is that the specification is now much more complex and framework implementations, especially those which support both options, will need to be much more complex. We need to keep SASL and the specification of SASL simple. I don't see the risk from the described threat being so high to warrant the insertion of this option ESPECIALLY given that the option doesn't not fully address the vulnerability. The information sent under the subsequent layers is still contains information known by those involved in the reauthentication. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6FAwkT013591 for ; Thu, 6 Nov 2003 07:10:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6FAwaq013590 for ietf-sasl-bks; Thu, 6 Nov 2003 07:10:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6FAqkT013571 for ; Thu, 6 Nov 2003 07:10:52 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA6FArlg042616; Thu, 6 Nov 2003 15:10:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031106070303.049b17b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 07:09:57 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: unauthenticated access without SASL layer Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FAA293C.1000206@isode.com> References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@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 02:58 AM 11/6/2003, Alexey Melnikov wrote: >>No. If someone really wants this, they should define a new >>mechanism which allowed for an unauthenticated identity and >>a layer with a null cipher. >IMHO, there is no point in a layer with a null cipher, it just adds unnecessary SASL framing. Unless of course the layer does something else. It replaces the previous layers. Hallvard wanted a way to do that, I assume for application protocols which only replace layers (don't deinstall them). This points out a serious problem with your suggestion that some protocols can deinstall layers will others can leave them installed, the applicability of the mechanism may be highly dependent on whether all layers can be removed once established or not. The more I think about adding the option to remove layers on reauthentication, the more I think it is a bad idea. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6BESkT004018 for ; Thu, 6 Nov 2003 03:14:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6BESxx004017 for ietf-sasl-bks; Thu, 6 Nov 2003 03:14:28 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6BERkT004012 for ; Thu, 6 Nov 2003 03:14:27 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 11:15:28 +0000 Message-ID: <3FAA2D0A.9040305@isode.com> Date: Thu, 06 Nov 2003 11:14:18 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> In-Reply-To: <3FAA293C.1000206@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: > > >>> Looking over the various SASL drafts, I miss one piece of >>> functionality: >>> To authenticate anonymously, removing any SASL layer, but still >>> providing an unauthenticated ID (e.g. for logging purposes). >>> > How is this different from ANONYMOUS (except for ... @ sign requirement). Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AwCkT002584 for ; Thu, 6 Nov 2003 02:58:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AwCAQ002583 for ietf-sasl-bks; Thu, 6 Nov 2003 02:58:12 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AwBkT002576 for ; Thu, 6 Nov 2003 02:58:11 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:59:15 +0000 Message-ID: <3FAA293C.1000206@isode.com> Date: Thu, 06 Nov 2003 10:58:04 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: unauthenticated access without SASL layer References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031105173306.048bc888@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: Kurt D. Zeilenga wrote: >At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: > > >>Looking over the various SASL drafts, I miss one piece of functionality: >>To authenticate anonymously, removing any SASL layer, but still >>providing an unauthenticated ID (e.g. for logging purposes). >> How is this different from ANONYMOUS (except for >>Am I missing something? Should one of the mechanisms above be changed to allow this? >> >> > >No. If someone really wants this, they should define a new >mechanism which allowed for an unauthenticated identity and >a layer with a null cipher. > IMHO, there is no point in a layer with a null cipher, it just adds unnecessary SASL framing. Unless of course the layer does something else. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AqZkT002322 for ; Thu, 6 Nov 2003 02:52:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AqZof002321 for ietf-sasl-bks; Thu, 6 Nov 2003 02:52:35 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AqYkT002316 for ; Thu, 6 Nov 2003 02:52:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:53:41 +0000 Message-ID: <3FAA27EE.50808@isode.com> Date: Thu, 06 Nov 2003 10:52:30 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: 'selects no security layer' References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >rfc2222bis says: > > >>If a security layer is in effect and a subsequent SASL negotiation >>selects no security layer, (...) >> >> > >Please rephrase as either 'does not select a security layer' (like >PLAIN) or '(explicitly) selects that there should be no security layer' >(which PLAIN does _not_ do). I presume it's the former. > > No, I actually mean both. DIGEST-MD5 has a mode when you can explicitly negotiate no security layer. I would welcome any suggestions to make this clearer. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.ht ___________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6AZNkT001283 for ; Thu, 6 Nov 2003 02:35:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6AZN5K001282 for ietf-sasl-bks; Thu, 6 Nov 2003 02:35:23 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6AZJkT001150 for ; Thu, 6 Nov 2003 02:35:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 10:36:20 +0000 Message-ID: <3FAA23DE.7000508@isode.com> Date: Thu, 06 Nov 2003 10:35:10 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Ok, the new text reads: >> >> >>(...) >>If a security layer >>is in effect and a subsequent SASL negotiation selects no security layer, >>the protocol profile has to specify a choice between: >> >>1) keeping the original security layer. >>2) removing the original security layer (replacing with no layer). >> >> > >This belongs in section 5 (Protocol Profile Requirements). > Yes, this is also mentioned in section 5 [in my copy]. >I suggest to indent (1) and (2), BTW. > > >>Also note, that if a subsequent authentication fails, >>the protocol profile MAY allow the connection state to return to >>non-authenticated, >> >> > >I can't find anything about that in section 5. Is it this text? > > "A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics." > No. This is a new text added to allow for LDAP behaviour. >If so, maybe that sentence should be clarified to explicitly allow the >protocol profile to say something about the effect of authentication on >authentication/authorization IDs. > > Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA61f2kT010737 for ; Wed, 5 Nov 2003 17:41:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA61f28Q010736 for ietf-sasl-bks; Wed, 5 Nov 2003 17:41:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA61f0kT010727 for ; Wed, 5 Nov 2003 17:41:00 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA61f3lg035207; Thu, 6 Nov 2003 01:41:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 05 Nov 2003 17:40:07 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: unauthenticated access without SASL layer Cc: ietf-sasl@imc.org In-Reply-To: References: 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 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >Looking over the various SASL drafts, I miss one piece of functionality: >To authenticate anonymously, removing any SASL layer, but still >providing an unauthenticated ID (e.g. for logging purposes). >Am I missing something? Should one of the mechanisms above be changed to allow this? No. If someone really wants this, they should define a new mechanism which allowed for an unauthenticated identity and a layer with a null cipher. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA610bkT008908 for ; Wed, 5 Nov 2003 17:00:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA610bf6008907 for ietf-sasl-bks; Wed, 5 Nov 2003 17:00:37 -0800 (PST) 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.10/8.12.8) with ESMTP id hA610akT008901 for ; Wed, 5 Nov 2003 17:00:36 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AHYVn-0006LC-Ot for ietf-sasl@imc.org; Thu, 06 Nov 2003 02:00:35 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AHYVm-0006jF-5T; Thu, 06 Nov 2003 02:00:34 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHYVl-0006iV-00; Thu, 6 Nov 2003 02:00:33 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-sasl@imc.org Subject: rfc2222bis: 'selects no security layer' In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 6 Nov 2003 02:00:33 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis says: > If a security layer is in effect and a subsequent SASL negotiation > selects no security layer, (...) Please rephrase as either 'does not select a security layer' (like PLAIN) or '(explicitly) selects that there should be no security layer' (which PLAIN does _not_ do). I presume it's the former. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA60k4kT008149 for ; Wed, 5 Nov 2003 16:46:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA60k4HJ008148 for ietf-sasl-bks; Wed, 5 Nov 2003 16:46:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hA60k2kT008143 for ; Wed, 5 Nov 2003 16:46:03 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHYHi-00052t-D0 for ietf-sasl@imc.org; Thu, 06 Nov 2003 01:46:02 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHYHe-00044U-Ct; Thu, 06 Nov 2003 01:45:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHYHe-0006gY-00; Thu, 6 Nov 2003 01:45:58 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: unauthenticated access without SASL layer Date: Thu, 6 Nov 2003 01:45:58 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looking over the various SASL drafts, I miss one piece of functionality: To authenticate anonymously, removing any SASL layer, but still providing an unauthenticated ID (e.g. for logging purposes). LDAP provides this with the 'simple' non-SASL authentication choice, except for the part about removing the SASL layer. The ANONYMOUS mechanism (draft-ietf-sasl-anon-02.txt) can be used for this - except if the desired ID contains '@', which means the ID is an e-mail address. The PLAIN mechanism (draft-ietf-sasl-plain-03.txt) could be used if an empty password was allowed, but it isn't. Am I missing something? Should one of the mechanisms above be changed to allow this? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5NkekT006253 for ; Wed, 5 Nov 2003 15:46:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5NkeYC006252 for ietf-sasl-bks; Wed, 5 Nov 2003 15:46:40 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5NkZkT006245 for ; Wed, 5 Nov 2003 15:46:35 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AHXMA-0006qx-JG; Thu, 06 Nov 2003 00:46:34 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AHXM6-000062-7T; Thu, 06 Nov 2003 00:46:30 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHXM6-0006YO-00; Thu, 6 Nov 2003 00:46:30 +0100 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov cc: SASL WG Subject: Re: Replacing a SASL security layer Date: Thu, 6 Nov 2003 00:46:30 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Ignore for a moment any relationship of realm to DIGEST-MD5, > GSSAPI or any other SASL mechanism. Let's use the definition I > have in the document: > > Conceptually, realm is the name of a collection of user's accounts. > Realms allow the protected resources on a server to be partitioned into > a set of protection spaces, each with its own authentication mechanisms > and/or authorization database. For example, a proxy/frontend can use > different realms for different servers/backends it represents. > > So, each "realm" ("a protection space") is served by a separate > server (proxy example above) or a separate process/plugin > (frontend-backend example). Does it make more sense now? Not to me. The client authenticates to server AA with realm A, and to server BB with realm B. So why does server BB see the traffic to server AA? Or if it doesn't, why does it know the realm A traffic, since that belongs on server AA? And why does the client send the same text to server AA as to server BB, sans realm differences, so that server BB can compare them? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5LWjkT001489 for ; Wed, 5 Nov 2003 13:32:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5LWjDp001488 for ietf-sasl-bks; Wed, 5 Nov 2003 13:32:45 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5LWikT001478 for ; Wed, 5 Nov 2003 13:32:44 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1AHVGZ-0002fI-Nz; Wed, 05 Nov 2003 22:32:39 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.14) id 1AHVGS-0007qm-44; Wed, 05 Nov 2003 22:32:32 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHVGQ-0006FJ-00; Wed, 5 Nov 2003 22:32:30 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 5 Nov 2003 22:32:30 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > Ok, the new text reads: > (...) > If a security layer > is in effect and a subsequent SASL negotiation selects no security layer, > the protocol profile has to specify a choice between: > > 1) keeping the original security layer. > 2) removing the original security layer (replacing with no layer). This belongs in section 5 (Protocol Profile Requirements). I suggest to indent (1) and (2), BTW. > Also note, that if a subsequent authentication fails, > the protocol profile MAY allow the connection state to return to > non-authenticated, I can't find anything about that in section 5. Is it this text? "A protocol profile MAY further refine the definition of an authorization identity by adding additional syntactic restrictions and protocol-specific semantics." If so, maybe that sentence should be clarified to explicitly allow the protocol profile to say something about the effect of authentication on authentication/authorization IDs. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Jo2kT097476 for ; Wed, 5 Nov 2003 11:50:02 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Jo29T097475 for ietf-sasl-bks; Wed, 5 Nov 2003 11:50:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5Jo1kT097467 for ; Wed, 5 Nov 2003 11:50:01 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AHTfA-00013d-Rm; Wed, 05 Nov 2003 20:49:56 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AHTf7-0007fz-Su; Wed, 05 Nov 2003 20:49:53 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AHTf7-00060Q-00; Wed, 5 Nov 2003 20:49:53 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3FA95041.6090001@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> <3FA95041.6090001@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 5 Nov 2003 20:49:53 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > (...) Only a successful reauthentication is able replace/remove the > previously negotiated security layer. Just to make sure it has been mentioned: This also means that non-SASL authentication must keep any old SASL layer. I expect that's intended, including for LDAPv4? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JdOkT096779 for ; Wed, 5 Nov 2003 11:39:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5JdOAT096778 for ietf-sasl-bks; Wed, 5 Nov 2003 11:39:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5JdNkT096767 for ; Wed, 5 Nov 2003 11:39:23 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 19:40:26 +0000 Message-ID: <3FA951E7.7090208@isode.com> Date: Wed, 05 Nov 2003 19:39:19 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: SASL Working group agenda for IETF 58 References: <87ptg6g4hk.fsf@luminous.mit.edu> In-Reply-To: <87ptg6g4hk.fsf@luminous.mit.edu> 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: Sam Hartman wrote: > Simple Authentication and Security Layer > Tuesday 1545-1645 > > > 0) Preliminaries - chairs - 10 min > Agenda / WG Status / etc. > 1) Removing security layers on re-authentication discussion - editor - 10 min > (draft-ietf-sasl-rfc2222bis) > I think I've addressed the issue to satisfy both sides (see the message I've just sent to the mailing list). Buf feel free to discuss this and let me know the outcome. Rob Siemborski is my "designed proxy" :-). > 2) SASLprep "Full Stop" discussion - editor - 15 min > (draft-ietf-sasl-saslprep) > 3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes > (draft-siemborski-rfc2554bis) > 4) Next steps / Milestones - chairs - 10 minutes > 5) Open Mic - floor - remaining time > > Is it worth sending updated versions of SASL-base and DIGEST-MD5 documents for the people to review during the meeting? Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5JWbkT096402 for ; Wed, 5 Nov 2003 11:32:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5JWaH0096400 for ietf-sasl-bks; Wed, 5 Nov 2003 11:32:36 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5JWUkT096395 for ; Wed, 5 Nov 2003 11:32:35 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 19:33:24 +0000 Message-ID: <3FA95041.6090001@isode.com> Date: Wed, 05 Nov 2003 19:32:17 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <3FA41ADD.2000308@isode.com> In-Reply-To: <3FA41ADD.2000308@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: > Alexey Melnikov wrote: > >>> The primary reason why this is better is because the change will cause >>> significant interoperability problems. Existing implementations expect >>> those layers to remain in effect. >> >> How about changing MUST to SHOULD to allow for backward compatibility >> for LDAP? > > Thinking more about this. What I didn't like about the original text > is that it was kind of MUST. > What if I rephrase to allow a protocol profile to have a choice: > either keep the original layer if none was negotiated during > reauthentication (and have a security consideration about the issue) > or remove the original layer. > If the protocol profile chooses to do the former, it should recommend > to always negotiate a new security layer during reauthentication. Ok, the new text reads: If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the protocol profile has to specify a choice between: 1) keeping the original security layer. 2) removing the original security layer (replacing with no layer). RFC 2222 only allowed for the first choice, however it was later discovered that the choice is vulnerable to a security attack described later in this section. Thus, new protocol profiles should use the second choice. The protocol profiles that depend on RFC 2222 behaviour should recommend to always negotiate another security layer, once a security layer was installed. Also note, that if a subsequent authentication fails, the protocol profile MAY allow the connection state to return to non-authenticated, however the previously negotiated security layer MUST NOT be removed. Only a successful reauthentication is able replace/remove the previously negotiated security layer. Hopefully this will make everybody happy. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GY5kT088094 for ; Wed, 5 Nov 2003 08:34:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5GY5fL088093 for ietf-sasl-bks; Wed, 5 Nov 2003 08:34:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GY4kT088086 for ; Wed, 5 Nov 2003 08:34:04 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 4572D7661E; Wed, 5 Nov 2003 11:33:11 -0500 (EST) To: agenda@ietf.org Cc: ietf-sasl@imc.org Subject: SASL Working group agenda for IETF 58 From: Sam Hartman Date: Wed, 05 Nov 2003 11:33:11 -0500 Message-ID: <87ptg6g4hk.fsf@luminous.mit.edu> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux) 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: Simple Authentication and Security Layer Tuesday 1545-1645 0) Preliminaries - chairs - 10 min Agenda / WG Status / etc. 1) Removing security layers on re-authentication discussion - editor - 10 min (draft-ietf-sasl-rfc2222bis) 2) SASLprep "Full Stop" discussion - editor - 15 min (draft-ietf-sasl-saslprep) 3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes (draft-siemborski-rfc2554bis) 4) Next steps / Milestones - chairs - 10 minutes 5) Open Mic - floor - remaining time Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5AUdkT068698 for ; Wed, 5 Nov 2003 02:30:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5AUd6w068697 for ietf-sasl-bks; Wed, 5 Nov 2003 02:30:39 -0800 (PST) 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.10/8.12.8) with ESMTP id hA5AUUkT068677 for ; Wed, 5 Nov 2003 02:30:37 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 10:31:29 +0000 Message-ID: <3FA8D140.1060507@isode.com> Date: Wed, 05 Nov 2003 10:30:24 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: <3F9C2F32.1060004@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>draft-ietf-sasl-rfc2831bis-02.txt: >>> >>> >>>> ( *LWS element *( *LWS "," *LWS element )) >>>> >>>> >>>Should this really be asymmetric, or should it be >>> ( element *( *LWS "," *LWS element )) >>>or >>> ( *LWS element *( *LWS "," *LWS element ) *LWS ) >>> >>> >>> >>I can go for the last proposal. At least it seems to be the original intent. >> >> > >I just realized that this was copied from rfc2616. > Correct. >So it's probably >better to leave it alone for compatibility's sake, or ask rfc2616's >author. > I've already fixed several minor ABNF bugs. But it would be a good idea to keep DIGEST-MD5 and RFC 2616 in sync. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LGOkT072941 for ; Tue, 4 Nov 2003 13:16:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4LGO74072940 for ietf-sasl-bks; Tue, 4 Nov 2003 13:16:24 -0800 (PST) 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.10/8.12.8) with ESMTP id hA4LGHkT072933 for ; Tue, 4 Nov 2003 13:16:18 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AH8XA-0007QQ-SV; Tue, 04 Nov 2003 22:16:16 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AH8X6-0005gb-Fu; Tue, 04 Nov 2003 22:16:12 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AH8X5-0002i1-00; Tue, 4 Nov 2003 22:16:11 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis issues In-Reply-To: <3F9C2F32.1060004@isode.com> References: <3F9C2F32.1060004@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 4 Nov 2003 22:16:11 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>draft-ietf-sasl-rfc2831bis-02.txt: >>> >>> ( *LWS element *( *LWS "," *LWS element )) >> >>Should this really be asymmetric, or should it be >> ( element *( *LWS "," *LWS element )) >>or >> ( *LWS element *( *LWS "," *LWS element ) *LWS ) >> >I can go for the last proposal. At least it seems to be the original intent. I just realized that this was copied from rfc2616. So it's probably better to leave it alone for compatibility's sake, or ask rfc2616's author. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JpvkT048391 for ; Mon, 3 Nov 2003 11:51:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3Jpvkb048390 for ietf-sasl-bks; Mon, 3 Nov 2003 11:51:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JpukT048383 for ; Mon, 3 Nov 2003 11:51:56 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3JpuPh001286; Mon, 3 Nov 2003 12:51:56 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA3Jpuru024629; Mon, 3 Nov 2003 11:51:56 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNS00INSKIJNJ@mpkmail.eng.sun.com>; Mon, 03 Nov 2003 11:51:56 -0800 (PST) Date: Mon, 03 Nov 2003 11:51:56 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNS00INWKIKNJ@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=UTF-8 Content-MD5: SfGydn3QK25i2FE+TDdj5Q== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id hA3JpukT048385 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree that the SASLprep is more suitable and applicable for simple user names and passwords and if the additional mappings such as the full stops are needed, they are more suitable and correct to be done at the outside of any Stringprep/Stringprep profiles and most preferrably before the application of the Stringprep profile(s). <-- These are also my points all along. The reasons are like the following that the U+002E (full stop and dot/decimal point) isn't the same or equivalent to the ideographic/Asian full stops all the time; if they were, the Unicode itself would define them as equivalent forms/characters and show canonical/compatiblity decomposition(s) at each characters so that the Unicode normalizations would normalize those characters into a (normalized) character. Also, if everyone would agree on the fact that the ideopgraphic/Asian full stops are not equivalent to the U+002E and yet we still need to support the mappings described in the IDNA for the compatibility/interoperability on the Internet domain style names (only), then, I'm also thinking that everyone would agree this conditional mappings should be done outside of the Stringprep and any of the Stringprep profiles (since the Stringprep itself doesn't really allow conditional mappings at the mapping step as of today even though a profile *possibly and maybe* could define such conditional mappings). Re user provided strings, I have the following example that shouldn't match as the same thing: 3.14 ３。１４ 3。14 The first one is the pi, three point one four, in ASCII and the second is three, ideographic full-stop, and fourteen in Asian full-width digit characters and with ideographic full stop in UTF-8. (The third one is a variation of the second one, three, ideographic full-stop, and fourteen in ASCII digits and with ideographic full stop in UTF-8; and the second and the third can be seen as equivalent.) With regards, Ienup ] Date: Fri, 31 Oct 2003 20:52:15 -0800 ] From: "Kurt D. Zeilenga" ] Subject: Re: SASLPrep vs Full Stop code points ] X-Sender: kurt@127.0.0.1 ] To: Ienup Sung ] Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] ] At 05:42 PM 10/31/2003, Ienup Sung wrote: ] >Regarding the full stops, while I do understand the point of display vs. ] >storage/query string in my opinion, I think the issue boils down onto ] >the followign two things in my view: ] >1. Should/can we treat ideographic/Asian full stops as equivalent characters ] > of the ASCII full stop (U+002E) in 100% of the possible cases/usages? ] ] SASLprep is only applicable to two use cases: simple user names and password. ] ] > The answer is no since the U+002E is not only a full stop character but ] > it is also a period and dot/decimal point character; CJK speakers do not use ] > the ideographic/Asian full stops as the dot/decimal point character and ] > hence some use of the ideographic/Asian full stops rather be preserved as ] > they are to be distingushed. And in that cases, can we distinguish what to ] > preserve and what not to preserve and map? ] ] SASLprep scope is limited to preparation of user input strings for matching. ] Issues such as how to preserving the (unprepared) user input is simply beyond ] our scope as matching and hence SASLprep. ] ] >2. Should/can we keep the compatiblity with the IDNA's additional and ] > pre-processing on the label separators, i.e., mappings of all full stops to ] > the U+002E, for the domain style (IDN) names before they are used? ] > I think the answer should be yes. ] ] SASLprep can define one preparation algorithm for simple user names and ] passwords. Simple here implies the input has no structure. That is, ] names have no particular style in respect to the algorithm. ] ] It is possible that specification using SASLprep could apply additional ] transformations be done. However, such transforms are beyond the scope ] of SASLprep. ] ] >I know the above two sound conflicting and the example shown at the argument ] >#1 could be considered as a case that may not need to be really supported. ] >But I thought presenting them might be a valuable thing to do. ] ] I would be interested in hearing whether you think the additional suggested ] mapping is appropriate or not for matching of simple user names or passwords, ] and why. ] ] I think this issue boils down to whether the user provided strings: ] ] ] ] ] ] should match or not. Because user names are often constructed from domain ] names, and IDNA says these stops are to be treated as equivalent, I believe ] they should match. ] ] Kurt ] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA34ATkT047807 for ; Sun, 2 Nov 2003 20:10:29 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA34ATBr047806 for ietf-sasl-bks; Sun, 2 Nov 2003 20:10:29 -0800 (PST) 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.10/8.12.8) with ESMTP id hA34ARkT047801 for ; Sun, 2 Nov 2003 20:10:28 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA34AUlg047138; Mon, 3 Nov 2003 04:10:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031102194648.02ba7af8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sun, 02 Nov 2003 20:09:39 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031003061141.040ed080@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 07:03 PM 11/2/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> I note that this issue is likely not unique to ANONYMOUS. So, maybe >> it should be dealt with in base SASL specification. >> >> I'm thinking a malformed message should be treated as a protocol >> error in the application protocol. Note that application protocols generally give great freedom in how protocol errors are treated. And, the principle of "be liberal in what you accept but strict in what your send" applies as well. >How detailed should the checking for malformed messages be? I think, in general, protocol peers should check each component of the PDU which they make use of and then some. For ANONYMOUS, a server which uses the message should check that it is properly encoded UTF-8 but a server which didn't make use of the message could simply ignore the message. >For example, is it a protocol error to send a latin-1 string when the >protocol requires UTF-8? Yes. >How about sending an invalid UTF-8-like >sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid? Yes. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA333vkT045942 for ; Sun, 2 Nov 2003 19:03:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA333v3Q045941 for ietf-sasl-bks; Sun, 2 Nov 2003 19:03:57 -0800 (PST) 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.10/8.12.8) with ESMTP id hA333tkT045935 for ; Sun, 2 Nov 2003 19:03:56 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AGV0V-00037v-8J; Mon, 03 Nov 2003 04:03:55 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AGV0P-0008W2-No; Mon, 03 Nov 2003 04:03:49 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AGV0O-0004P6-00; Mon, 3 Nov 2003 04:03:48 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 3 Nov 2003 04:03:48 +0100 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 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > I note that this issue is likely not unique to ANONYMOUS. So, maybe > it should be dealt with in base SASL specification. > > I'm thinking a malformed message should be treated as a protocol > error in the application protocol. How detailed should the checking for malformed messages be? For example, is it a protocol error to send a latin-1 string when the protocol requires UTF-8? How about sending an invalid UTF-8-like sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KhAkT025624 for ; Sat, 1 Nov 2003 12:43:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KhAR9025623 for ietf-sasl-bks; Sat, 1 Nov 2003 12:43:10 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1Kh9kT025618 for ; Sat, 1 Nov 2003 12:43:09 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 20:43:52 +0000 Message-ID: <3FA41ADD.2000308@isode.com> Date: Sat, 01 Nov 2003 20:43:09 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> In-Reply-To: <3FA401B2.50607@isode.com> 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: Alexey Melnikov wrote: >> The primary reason why this is better is because the change will cause >> significant interoperability problems. Existing implementations expect >> those layers to remain in effect. >> > How about changing MUST to SHOULD to allow for backward compatibility > for LDAP? Thinking more about this. What I didn't like about the original text is that it was kind of MUST. What if I rephrase to allow a protocol profile to have a choice: either keep the original layer if none was negotiated during reauthentication (and have a security consideration about the issue) or remove the original layer. If the protocol profile chooses to do the former, it should recommend to always negotiate a new security layer during reauthentication. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KgekT025610 for ; Sat, 1 Nov 2003 12:42:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KgetU025609 for ietf-sasl-bks; Sat, 1 Nov 2003 12:42:40 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1KgdkT025604 for ; Sat, 1 Nov 2003 12:42:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 20:43:23 +0000 Message-ID: <3FA41ABF.1080602@isode.com> Date: Sat, 01 Nov 2003 20:42:39 +0000 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: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@isode.com> <6.0.0.22.0.20031101114709.02b854d0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031101114709.02b854d0@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: >>>The primary reason why this is better is because the change will cause >>>significant interoperability problems. Existing implementations expect >>>those layers to remain in effect. >>> >>> >>How about changing MUST to SHOULD to allow for backward compatibility for LDAP? >> >> >A SHOULD would be inappropriate as interoperability mandates that either all >implementations keep the layer or all implementations drop the layer. > > SHOULD in protocol profile, not "SHOULD keep/drop the old layer". Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1KZxkT025335 for ; Sat, 1 Nov 2003 12:35:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1KZxTG025334 for ietf-sasl-bks; Sat, 1 Nov 2003 12:35:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1KZrkT025328 for ; Sat, 1 Nov 2003 12:35:54 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1KZtlg034106; Sat, 1 Nov 2003 20:35:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101114709.02b854d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 12:35:06 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: re-negotiating SASL security layer Cc: ietf-sasl@imc.org In-Reply-To: <3FA401B2.50607@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> <3FA401B2.50607@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:55 AM 11/1/2003, Alexey Melnikov wrote: >The draft describes a potential security vulnerability. I don't disagree that there is a potential security vulnerability. I disagree that we should address it by changing the protocol. The issue can be (and, in my opinion, should be) addressed through statement of appropriate security considerations. I think we're talking about the same class of attacks. There are numerous cases where a third party (such as BB in your discussion) have limited knowledge of protected content and could use that knowledge to mount an attack. Note that your solution doesn't complete eliminate this particular case as the old layers are in-effect during the reauthentication. Server BB could still use its knowledge of the reauthentication process to attack the encryption of previously sent information. I think the risk of this class of attack is not sufficient to warrant changing the protocol especially considering the interoperability (and security?) problems the change would cause. I say "and security?" as now traffic which an old client expected to be protected by old layers would not be protected. We have to consider that as well. >I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication), but there is no point of propagating something which is known to be broken to new protocols. I don't consider SASL broken in this respect. It just that there are security concerns to be considered. >>The primary reason why this is better is because the change will cause >>significant interoperability problems. Existing implementations expect >>those layers to remain in effect. >How about changing MUST to SHOULD to allow for backward compatibility for LDAP? A SHOULD would be inappropriate as interoperability mandates that either all implementations keep the layer or all implementations drop the layer. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1JfbkT023697 for ; Sat, 1 Nov 2003 11:41:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1JfbAx023696 for ietf-sasl-bks; Sat, 1 Nov 2003 11:41:37 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1JfakT023691 for ; Sat, 1 Nov 2003 11:41:36 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 19:42:18 +0000 Message-ID: <3FA40C6F.3030004@isode.com> Date: Sat, 01 Nov 2003 19:41:35 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>>>>>>In >>>>>>>order to avoid noninteroperability due to differing normalizations, >>>>>>>when a mechanism specifies that a string authentication identity or >>>>>>>password used as input to a cryptographic function (or used for >>>>>>>comparison) it SHOULD specify that the string first be prepared using >>>>>>>the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>>>>>[StringPrep]. >>>>>>> >>>>>>> >>The new text after that reads: >> >>There are three entities that has to deal with this issue: a client >>(upon getting user input or retrieving a value from configuration), a server >>(upon receiving the value from the client) and a utility that is able to >>store >>passwords/hashes in a database that can be later used by the server. >>The preparation must be done by the client and the utility and may be >>done by the >>server. If preparation fails or results in an empty string, the entity doing >>the preparation SHALL fail the authentication exchange. >> > >I like Kurt's suggestion better: The mechanism must define where >preparation is done. That way clients using mechanisms like PLAIN can >leave as much work as possible to the server. > I've updated the draft to say that each mechanism must describe where preparation takes place. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1ItwkT022528 for ; Sat, 1 Nov 2003 10:55:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1ItwGf022527 for ietf-sasl-bks; Sat, 1 Nov 2003 10:55:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1ItukT022522 for ; Sat, 1 Nov 2003 10:55:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 18:56:36 +0000 Message-ID: <3FA401B2.50607@isode.com> Date: Sat, 01 Nov 2003 18:55:46 +0000 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: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@isode.com> <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031101093553.0585dce8@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: Kurt D. Zeilenga wrote: >Alexey, > >RFC 2222 said: > If a security layer is in effect and a subsequent SASL negotiation > selects no security layer, the original security layer remains in effect. > >I think changing this is bad. > >The primary reason posted on the list for the change was: "Applications >should be allowed to remove layers." I argue that this is, effective, >adding a new feature to SASL. Adding new features is beyond our scope. > I never said that and I don't believe this is an important feature. >The primary reason given in the draft is to address a security concern. >I would suspect that there are numerous other cases, including where >re-authentication is not involved, where another party may have direct >knowledge of information being encrypted. For example, the same concern >arises when an LDAP server provides results obtained through chaining. >Or by an LDAP client is chasing a referral. This concerns, I think, >would be better addressed by stating security consideration. > Kurt, I think you are missing the point. You are describing authorized disclosure (or something similar to a situation when one end of the connection is broadcasting decrypted data over the network in the clear). The draft describes a potential security vulnerability. I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication), but there is no point of propagating something which is known to be broken to new protocols. >The primary reason why this is better is because the change will cause >significant interoperability problems. Existing implementations expect >those layers to remain in effect. > How about changing MUST to SHOULD to allow for backward compatibility for LDAP? Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1IGWkT021484 for ; Sat, 1 Nov 2003 10:16:32 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1IGW4T021483 for ietf-sasl-bks; Sat, 1 Nov 2003 10:16:32 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1IGUkT021478 for ; Sat, 1 Nov 2003 10:16:31 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1IGWlg033000; Sat, 1 Nov 2003 18:16:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101093553.0585dce8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 10:15:42 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: re-negotiating SASL security layer Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3FA3C18E.8010101@isode.com> References: <3F8D34E4.4020607@isode.com> <3FA3C18E.8010101@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: Alexey, RFC 2222 said: If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect. I think changing this is bad. The primary reason posted on the list for the change was: "Applications should be allowed to remove layers." I argue that this is, effective, adding a new feature to SASL. Adding new features is beyond our scope. The primary reason given in the draft is to address a security concern. I would suspect that there are numerous other cases, including where re-authentication is not involved, where another party may have direct knowledge of information being encrypted. For example, the same concern arises when an LDAP server provides results obtained through chaining. Or by an LDAP client is chasing a referral. This concerns, I think, would be better addressed by stating security consideration. The primary reason why this is better is because the change will cause significant interoperability problems. Existing implementations expect those layers to remain in effect. Kurt At 06:22 AM 11/1/2003, Alexey Melnikov wrote: >>>>rfc2222bis section 6.3 "Multiple authentications" says: >>>> >>>> If a security layer is in effect >>>> and a subsequent SASL negotiation selects a second security layer, >>>> then the second security layer replaces the first. If a security >>>> layer is in effect and a subsequent SASL negotiation selects no >>>> security layer, the original security layer must be removed. >>>> >>>>Exactly when is the old layer canceled? >>>> >>>>If an old layer is active and the client starts to negotiate a new >>>>layer, it may not know when to expect the response from the server. >>>>So the layer can't be canceled by starting a new negotiation. >>>> >>>No, the layer can only be canceled/replaced after a subsequent authentication completes successfully. >> >>OK. Please mention that explicitly. >After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads: > >If a profile explicitly permits multiple successful SASL >negotiations to occur, then in no case may multiple security layers be >simultaneously in effect. If a security layer is in effect >and a subsequent SASL negotiation selects a second security layer, >then the second security layer replaces the first. If a security layer >is in effect and a subsequent SASL negotiation selects no security layer, >the original security layer MUST be removed. The rest of this section explain >why this is important. Also note, that if a subsequent authentication fails, >the protocol profile MAY allow the connection state to return to non-authenticated, >however the previously negotiated security layer MUST NOT be removed. Only >a successful reauthentication is able replace/remove the previously negotiated >security layer. > >>>Each profile document must document exactly when this takes place. >> >>'this' = 'it completed successfully', I take it. >> >Yes. > >Alexey >__________________________________________ >Isode Limited, http://www.isode.com > >IETF standard related pages: >http://orthanc.ab.ca/mel/devel/Links.html >__________________________________________ > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1HZpkT020002 for ; Sat, 1 Nov 2003 09:35:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1HZpkU020001 for ietf-sasl-bks; Sat, 1 Nov 2003 09:35:51 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1HZmkT019995 for ; Sat, 1 Nov 2003 09:35:48 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1HZilg032752; Sat, 1 Nov 2003 17:35:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101082402.057ffb60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 09:34:54 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Consensus call: changing examples from ACAP to SMTP Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <3FA3BDED.6010804@isode.com> References: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> <3FA3BDED.6010804@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 06:06 AM 11/1/2003, Alexey Melnikov wrote: >Sam Hartman wrote: > >>Hi. The discussion seems to have died down on the issue of replacing >>the ACAP example with an SMTP example in the plain draft. >> >>The rough consensus of this working group is that we will not change >>to an SMTP-based example. We seem to believe that the examples in the >>plain document should illustrate that mechanisms, not illustrate common >>implementation errors in other related protocols. >> >>I think that we have something approaching a consensus that we will be >>better served by encouraging implementers to read all the appropriate >>documents than to include information designed to make sure that >>implementers will not make mistakes even if they do not read the >>appropriate documents. That's not as clear as the consensus against >>changing the example to SMTP; there may be more room for discussion on >>this issue. >> >>Personally I believe that we may want to consider ways in which we can >>make it clear to implementers what documents they want to read. >I suggest the following: >1). Don't change examples in PLAIN As I previously noted, I intend to offer another example illustrating another aspect of the PLAIN feature for WG consideration. But I am going to be very careful to avoid getting into the details more appropriately discussed in referencing documents. >2). Implementation consideration section is added to the base SASL document. I am a bit leery of adding another section to the base SASL document (especially at this late stage). It may be better, as was suggested by someone else, to instead write an "SASL Implementation Guide" as a separate document. I think, however, most of the problems and their solutions are application protocol specific and, hence, should be addressed in documents specific to application protocol. >It will list commonly misimplemented features and will give some protocol examples. >I will make sure that SMTP PLAIN example is one of the examples. Depending on what you intend to illustrate, SMTP may not be the best protocol for the example. (See prior discussion.) >Reference to PLAIN will be informative. (Or this can be a separate document as discussed recently). Again, we need to avoid trumping application profile documents in documents they reference. We need to ensure that any example (and as well as prose) is properly placed in the right document. Now, depending on example what kind of examples you had in mind, they may or may not be appropriate. For instance, examples showing the initial response (without challenge) and final challenge (without response) would likely be useful. But we need to be careful not to specify how exchanges are to be implemented in any particular application-level protocol. I suggest you offer specific text to the list for WG consideration. >3). I am thinking about [co-]authoring a document that is "protocol profile designer guide". It will compare existing protocols and how different features are implemented in them. This can be the same document as in 2, or a separate document. As a separate document, I think this is a good idea. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1GIUkT017160 for ; Sat, 1 Nov 2003 08:18:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1GIUik017159 for ietf-sasl-bks; Sat, 1 Nov 2003 08:18:30 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1GITkT017153 for ; Sat, 1 Nov 2003 08:18:29 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA1GIUlg032178; Sat, 1 Nov 2003 16:18:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031101080111.057ff8d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 01 Nov 2003 08:17:41 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Fwd: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: ietf-sasl@imc.org 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: >Date: Sat, 01 Nov 2003 15:33:40 +0000 >From: Alexey Melnikov >To: Hallvard B Furuseth >CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org >Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments >List-Archive: > > >Hallvard B Furuseth wrote: >>>>>We should not suggest that mechanisms should do both (1) and >>>>>(2). (1) and (3) OR (2) or (3) are sufficient to ensure >>>>>proper matching. >>>>> >>>>IMHO, this is a responsibility of the client, >>>> >> >>Disagree. It's the responsibility of the mechanism definition to say >>where it should happen. >Ok. >But in all SASL mechanisms I know the client end sends username or retrieves-hashes-sends something derived from a password. >So, so far this is the same thing ;-). There are certainly mechanisms which don't transfer a username (authentication identity in simple form) and/or don't transfer a value derived from a simple password. (For example, EXTERNAL.) And for those which do, it should be left up to the mechanism to state where preparation of those strings is to be done. The framework specification should avoid getting details which are mechanism-specific. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1FXokT015378 for ; Sat, 1 Nov 2003 07:33:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1FXoAl015377 for ietf-sasl-bks; Sat, 1 Nov 2003 07:33:50 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1FXnkT015372 for ; Sat, 1 Nov 2003 07:33:49 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 15:34:23 +0000 Message-ID: <3FA3D254.9030809@isode.com> Date: Sat, 01 Nov 2003 15:33:40 +0000 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: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >>>>We should not suggest that mechanisms should do both (1) and >>>>(2). (1) and (3) OR (2) or (3) are sufficient to ensure >>>>proper matching. >>>> >>>> >>>IMHO, this is a responsibility of the client, >>> >>> > >Disagree. It's the responsibility of the mechanism definition to say >where it should happen. > Ok. But in all SASL mechanisms I know the client end sends username or retrieves-hashes-sends something derived from a password. So, so far this is the same thing ;-). Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1F9LkT014548 for ; Sat, 1 Nov 2003 07:09:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1F9Lgu014547 for ietf-sasl-bks; Sat, 1 Nov 2003 07:09:21 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1F9KkT014542 for ; Sat, 1 Nov 2003 07:09:20 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 15:10:02 +0000 Message-ID: <3FA3CCA0.9040909@isode.com> Date: Sat, 01 Nov 2003 15:09:20 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: <3F9C2F32.1060004@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>>>2.1.1 Step One >>>> >>>> The server starts by sending a challenge. >>>> >>>> >>>How does it know that it should do that? >>> >>The client always starts first (according to SASL). If the client >>doesn't includes an initial response, the server will know. >> >>Can you suggest any clarification text here? >> >> > >'The server starts by sending a challenge after the client indicates >that SASL negotiatin should start'? > > SASL framework doesn't support the case when the server initiate authentication exchange. The only way to do that is for the server to return some kind of "authentication required" error code when the client tries to issue other commands. > ... > >>>>2.2 Subsequent Authentication >>>> >>>> If the client has previously authenticated to the server, and >>>> remembers the values of username, realm, nonce, nonce-count, cnonce, >>>> >>>> >>> ^^^^^^^^ >>> >>> >>>> and qop that it used in that authentication, and the SASL profile for >>>> a protocol permits an initial client response, then it MAY perform >>>> "subsequent authentication", as defined in this section. >>>> >>>> >>>What's the point of authenticating again with the same username? Auth >>>with a _different_ username would be more interesting. >>> >>> >>This is a case of fast reauthentication using a different TCP >>connection. This is similar to resuming a TLS session. >> > >Oh. Could you add 'even after closing the connection and reopening a >new one' in section 2.2? > > Actually, this can be done on the same connection, if the protocol supports reauthentication. I've added the following: Note, that a subsequent authentication can be done on a different connection, or on the same connection, if the protocol profile also permits multiple authentications. I've also added some clarification text at the beginning of section 2. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EiwkT013730 for ; Sat, 1 Nov 2003 06:44:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1Eiw78013729 for ietf-sasl-bks; Sat, 1 Nov 2003 06:44:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1EiukT013716 for ; Sat, 1 Nov 2003 06:44:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:42:13 +0000 Message-ID: <3FA3C61A.3040307@isode.com> Date: Sat, 01 Nov 2003 14:41:30 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token References: <3F8D308B.5050208@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >>>rfc2831bis 2.1.1 "Step One" says: >>> >>> qop-options = "qop" "=" <"> qop-list <"> >>> qop-list = 1#qop-value >>> qop-value = "auth" | "auth-int" | "auth-conf" | >>> token >>> >>>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >>>"auth", "auth-int" and "auth-conf", but not when it is . >>> >>> >>Token is specifically for future extensions, if you see a qop value you >>don't recognize - you have to ignore it. >>If you recognize nothing, you have to fail the authentication exchange. >> >>Do you want any clarifications on this to be added to the document. >> >> > >Not sure. I think it would be good to mention that 'token is for future >extensions' somewhere. And perhaps that these extensions must define >A2, since rfc2831bis does not. > Ok, I've clarified this. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EM7kT013069 for ; Sat, 1 Nov 2003 06:22:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1EM7i6013068 for ietf-sasl-bks; Sat, 1 Nov 2003 06:22:07 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1EM6kT013063 for ; Sat, 1 Nov 2003 06:22:06 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:22:48 +0000 Message-ID: <3FA3C18E.8010101@isode.com> Date: Sat, 01 Nov 2003 14:22:06 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: <3F8D34E4.4020607@isode.com> In-Reply-To: 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: > > >>>rfc2222bis section 6.3 "Multiple authentications" says: >>> >>> If a security layer is in effect >>> and a subsequent SASL negotiation selects a second security layer, >>> then the second security layer replaces the first. If a security >>> layer is in effect and a subsequent SASL negotiation selects no >>> security layer, the original security layer must be removed. >>> >>>Exactly when is the old layer canceled? >>> >>>If an old layer is active and the client starts to negotiate a new >>>layer, it may not know when to expect the response from the server. >>>So the layer can't be canceled by starting a new negotiation. >>> >>> >>No, the layer can only be canceled/replaced after a subsequent >>authentication completes successfully. >> > >OK. Please mention that explicitly. > After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads: If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer MUST be removed. The rest of this section explain why this is important. Also note, that if a subsequent authentication fails, the protocol profile MAY allow the connection state to return to non-authenticated, however the previously negotiated security layer MUST NOT be removed. Only a successful reauthentication is able replace/remove the previously negotiated security layer. >>Each profile document must document exactly when this takes place. >> > >'this' = 'it completed successfully', I take it. > > Yes. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1E6dkT012090 for ; Sat, 1 Nov 2003 06:06:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1E6dIE012089 for ietf-sasl-bks; Sat, 1 Nov 2003 06:06:39 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1E6ckT012077 for ; Sat, 1 Nov 2003 06:06:38 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 14:07:19 +0000 Message-ID: <3FA3BDED.6010804@isode.com> Date: Sat, 01 Nov 2003 14:06:37 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Consensus call: changing examples from ACAP to SMTP References: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> In-Reply-To: <20031031195205.60C6F1515E8@konishi-polis.mit.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: Sam Hartman wrote: >Hi. The discussion seems to have died down on the issue of replacing >the ACAP example with an SMTP example in the plain draft. > >The rough consensus of this working group is that we will not change >to an SMTP-based example. We seem to believe that the examples in the >plain document should illustrate that mechanisms, not illustrate common >implementation errors in other related protocols. > >I think that we have something approaching a consensus that we will be >better served by encouraging implementers to read all the appropriate >documents than to include information designed to make sure that >implementers will not make mistakes even if they do not read the >appropriate documents. That's not as clear as the consensus against >changing the example to SMTP; there may be more room for discussion on >this issue. > >Personally I believe that we may want to consider ways in which we can >make it clear to implementers what documents they want to read. > I suggest the following: 1). Don't change examples in PLAIN 2). Implementation consideration section is added to the base SASL document. It will list commonly misimplemented features and will give some protocol examples. I will make sure that SMTP PLAIN example is one of the examples. Reference to PLAIN will be informative. (Or this can be a separate document as discussed recently). 3). I am thinking about [co-]authoring a document that is "protocol profile designer guide". It will compare existing protocols and how different features are implemented in them. This can be the same document as in 2, or a separate document. Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DdwkT010701 for ; Sat, 1 Nov 2003 05:39:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1DdwF2010698 for ietf-sasl-bks; Sat, 1 Nov 2003 05:39:58 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1DdvkT010693 for ; Sat, 1 Nov 2003 05:39:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 13:40:39 +0000 Message-ID: <3FA3B7AD.4010309@isode.com> Date: Sat, 01 Nov 2003 13:39:57 +0000 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: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> In-Reply-To: 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: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>Alexey Melnikov writes: >>> >>> >>>>Hallvard B Furuseth wrote: >>>> >>>> >>>>>>4.1. Authentication protocol exchange >>>>>> >>>>>> >>>Anyway, I think I found the answer in section 6.1. The initial auth >>>command from the client is not part of the exchange, but the optional >>>"response" in the auth command is. >>> >>> >>Sorry, this makes little sense to me. >>Semantically the initial response *is* part of an authentication >>exchange. >> >> > >That's what I wrote. > Ok, but I think arguing whether the initial auth command is part of an exchange or not is not worth the time. >>>>>>4.2. Authorization identities and proxy authentication >>>>>> >>>>>> (...) >>>>>> The character encoding scheme used for transmitting an authorization >>>>>> identity over protocol is specified in each authentication mechanism >>>>>> (with the authentication mechanism's blob being further >>>>>> >>>>>> >>>>> ^^^^ >>>>> >>>>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>>>like the dictionary says:-) >>>>> >>>>> >>>>> >>>>I've changed this to "data". >>>> >>>> >>>I still don't know _which_ data you are talking about. >>> >>> >>> >>Data is defined (and specific to) by each SASL mechanism. >> >> > >Is the text in the ()'s just saying that the SASL mechanism restricts >the data sent between client and server to more than just being random >strings in the character encoding scheme? > No, it talks about encoding data. The data itself is arbitrary binary data as far as the protocol is concerned. > Well, of course. Why mention >that at all? If not, I still don't understand what this () is saying. > > > >>>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>>>top. >>>>> >>>>> >>>>> >>>>I've added a sentence about this in the introduction section. >>>> >>>> >>>I'm pretty sure you will still need to insert the words "Obsoletes: rfc >>>2222" in the header sometime, though I don't remember where this is >>>stated. >>> >>> >>> >>I think this is going to be added by a RFC editor. >> >> >I couldn't find anything saying so. I did find rfc2223 (Instructions >to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks >you to insert. rfc2223 does say that the RFC Editor may make some >changes, but preferably as few as possible, and it doesn't mention >that one. > Ok, I will make sure that Obsoletes: will be inserted. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DYkkT010491 for ; Sat, 1 Nov 2003 05:34:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1DYkXi010490 for ietf-sasl-bks; Sat, 1 Nov 2003 05:34:46 -0800 (PST) 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.10/8.12.8) with ESMTP id hA1DYjkT010484 for ; Sat, 1 Nov 2003 05:34:45 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sat, 1 Nov 2003 13:35:23 +0000 Message-ID: <3FA3B671.10104@isode.com> Date: Sat, 01 Nov 2003 13:34:41 +0000 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: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.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: Sam Hartman wrote: >There has been a lot of discussion on the list since the last IETF and >I'm curious which issues actually need meeting time. I'd appreciate >it if people could suggest issues that still seem to be open. > >Thing I think may be open or need discussion are: > >* Initial server challenges especially as they interact with SMTP > I think there is nothing to discuss here. There are bugs in existing implementation and this need to be clarified with additional examples. >* Security layer replacement in the base SASL spec >* Authorization ID text (data vs blob, confusion about restriction, etc) >* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want >to develop guidance for protocol designers on this issue? > >I think most of the other changes that have been brought forward have >been resolved; please correct me if I'm wrong. I think Greg's >comments on implementing SASL have not suggested any specific changes >to documents that need discussion. > > >There's also been a lot of IDN related discussion in the Kerberos >working group. So far, I don't think any of that discussion affects >saslprep. If any of those issues do end up affecting saslprep, we may >at least want to be aware of them. I'll review those discussion >within the next week. > > > Cheers, Alexey Melnikov __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________