From owner-ietf-sasl Wed Feb 11 08:17:06 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGH5v3068605; Wed, 11 Feb 2004 08:17:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BGH5HQ068604; Wed, 11 Feb 2004 08:17: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.11/8.12.8) with ESMTP id i1BGGxDd068523 for ; Wed, 11 Feb 2004 08:17: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; Wed, 11 Feb 2004 16:17:09 +0000 Message-ID: <402A5584.5080705@isode.com> Date: Wed, 11 Feb 2004 16:17:08 +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: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) 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: I've recently submitted draft-ietf-sasl-rfc2222bis-05 which addressed most of the editorial issues raised by Kurt Zeilenga. I am planning to submit a new revision before the submission deadline. Question: Kurt raised a question about removing the following paragraph from the Security Considerations section. Sam has agreed with Kurt. (This text is not something specific to SASL. After discussing this issue in relationship to XMPP, I thought that it would be a nice idea to add it) SASL implementations might be subject to online dictionary attacks (e.g. username harvesting, password guessing). In order to mitigate the attacks a server implementation is encouraged to implement a policy when after a number of failed authentication attempts it returns errors to all subsequent authentication attempts on the same connection. Alternatively, the server may implement a policy whereby the connection is dropped after a number of failed authentication attempts. If a server implementation chooses to do so, it should not drop the connection until at least 3 authentication attempts have failed. Before I do any changes I would like to hear at least 2 more voices in favor of keeping or removing this paragraph. The changes between 05 and 06 are outlined below: 1). New section 5.2 was introduced that list guidelines for a SASL mechanism designer. 5.2. Mechanism profile guidelines Designers of new SASL mechanism should be aware of the following issues: 1) Authorization identity. While some legacy mechanisms are incapable of transmitting an authorization identity (which means that for these mechanisms the authorization identity is always the empty string), newly defined mechanisms SHOULD be capable of transmitting a non-empty authorization identity. See also section 4.2. 2) Character string issues Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). In order to avoid interoperability problems due to differing normalizations, when a mechanisms specifies that character data is to be used as input to a cryptographic and/or comparison function, the mechanism specification MUST detail how the data is to be represented, including any normalizations or other preparations, to ensure proper function. Designers of mechanisms SHOULD use the "SASLprep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep] where applicable. The preparation can be potentially performed on the client end (upon getting user input or retrieving a value from configuration) or on the server end (upon receiving the value from the client, retrieving a value from its authentication database or generating a new value in order to store in in the authentication database). SASL mechanisms must define which entity (or entities) must perform the preparation. If preparation fails or results in an empty string, the entity doing the preparation SHALL fail the authentication exchange. Implementation note: A server end can be represented by multiple processes. For example, it may consist of the server process itself that communicated with a client, and a command line utility (a server agent) that is able to store passwords/hashes in a database that can be later used by the server. For the server agent the requirement to "fail the authentication exchange" should be interpreted as a requirement to refuse to store the data in the database. 2). I've added a SASL profile requirement that tells that if the protocol supports an initial response, it must specify how an empty initial response is encoded. This was prompted by a recent discussion on XMPP mailing list. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Wed Feb 11 08:50:16 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGoGAW070982; Wed, 11 Feb 2004 08:50:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BGoGAi070981; Wed, 11 Feb 2004 08:50:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hades.jabber.org (hades.all-your-IM-are-belong-to-us.jabber.org [208.245.212.109] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGoEOO070973 for ; Wed, 11 Feb 2004 08:50:14 -0800 (PST) (envelope-from stpeter@jabber.org) Received: by hades.jabber.org (Postfix, from userid 1005) id EBF0D63FCA; Wed, 11 Feb 2004 10:50:27 -0600 (CST) Date: Wed, 11 Feb 2004 10:50:27 -0600 From: Peter Saint-Andre To: Alexey Melnikov Cc: SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) Message-ID: <20040211165027.GL20400@jabber.org> References: <402A5584.5080705@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402A5584.5080705@isode.com> User-Agent: Mutt/1.5.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Feb 11, 2004 at 04:17:08PM +0000, Alexey Melnikov wrote: > > Kurt raised a question about removing the following paragraph from the > Security Considerations section. Sam has agreed with Kurt. > (This text is not something specific to SASL. After discussing this > issue in relationship to XMPP, I thought that it would be a nice idea to > add it) > > SASL implementations might be subject to online dictionary attacks > (e.g. username harvesting, password guessing). In order to mitigate > the attacks a server implementation is encouraged to implement a > policy when after a number of failed authentication attempts it > returns errors to all subsequent authentication attempts on the same > connection. Alternatively, the server may implement a policy whereby > the connection is dropped after a number of failed authentication > attempts. If a server implementation chooses to do so, it should not > drop the connection until at least 3 authentication attempts have > failed. > > Before I do any changes I would like to hear at least 2 more voices in > favor of keeping or removing this paragraph. Hi Alexey, This seems like an issue that should be addressed by the using protocol (e.g., the XMPP specs should say something about this), not something that should be addressed by SASL. So I agree with Kurt and Sam. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php From owner-ietf-sasl Wed Feb 11 09:36:05 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BHa48F074439; Wed, 11 Feb 2004 09:36:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BHa4r6074438; Wed, 11 Feb 2004 09:36:04 -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.11/8.12.8) with ESMTP id i1BHZwL0074429 for ; Wed, 11 Feb 2004 09:35:59 -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 i1BHaCtH015031; Wed, 11 Feb 2004 12:36:12 -0500 Date: Wed, 11 Feb 2004 12:36:11 -0500 (EST) From: Rob Siemborski To: Peter Saint-Andre cc: Alexey Melnikov , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) In-Reply-To: <20040211165027.GL20400@jabber.org> Message-ID: References: <402A5584.5080705@isode.com> <20040211165027.GL20400@jabber.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: On Wed, 11 Feb 2004, Peter Saint-Andre wrote: > Hi Alexey, > > This seems like an issue that should be addressed by the using protocol > (e.g., the XMPP specs should say something about this), not something > that should be addressed by SASL. So I agree with Kurt and Sam. > > Peter I also agree -- this isn't something specific to sasl, it is more applicable to the application's specific authentication policy. -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Feb 11 09:44:43 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BHihRb075191; Wed, 11 Feb 2004 09:44:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BHihEB075190; Wed, 11 Feb 2004 09:44:43 -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.11/8.12.8) with ESMTP id i1BHig8j075184 for ; Wed, 11 Feb 2004 09:44:42 -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, 11 Feb 2004 17:44:53 +0000 Message-ID: <402A6A13.3060309@isode.com> Date: Wed, 11 Feb 2004 17:44: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: Rob Siemborski CC: Peter Saint-Andre , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) References: <402A5584.5080705@isode.com> <20040211165027.GL20400@jabber.org> 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 Wed, 11 Feb 2004, Peter Saint-Andre wrote: > > >>Hi Alexey, >> >>This seems like an issue that should be addressed by the using protocol >>(e.g., the XMPP specs should say something about this), not something >>that should be addressed by SASL. So I agree with Kurt and Sam. >> >>Peter >> >> > >I also agree -- this isn't something specific to sasl, it is more >applicable to the application's specific authentication policy. > Ok, we have 4 votes. Seems like a consensus. I will remove this. Alexey From owner-ietf-sasl Wed Feb 11 10:45:01 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BIj1PZ080759; Wed, 11 Feb 2004 10:45:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BIj02O080758; Wed, 11 Feb 2004 10:45:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1BIithG080741 for ; Wed, 11 Feb 2004 10:44:55 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa07940; 11 Feb 2004 13:44 EST Date: Wed, 11 Feb 2004 13:44:41 -0500 From: Jeffrey Hutzelman To: Alexey Melnikov , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) Message-ID: <3616130000.1076525081@minbar.fac.cs.cmu.edu> In-Reply-To: <402A5584.5080705@isode.com> References: <402A5584.5080705@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, February 11, 2004 16:17:08 +0000 Alexey Melnikov wrote: > Kurt raised a question about removing the following paragraph from the > Security Considerations section. Sam has agreed with Kurt. (This text is > not something specific to SASL. After discussing this issue in > relationship to XMPP, I thought that it would be a nice idea to add it) > > SASL implementations might be subject to online dictionary attacks > (e.g. username harvesting, password guessing). In order to mitigate > the attacks a server implementation is encouraged to implement a > policy when after a number of failed authentication attempts it > returns errors to all subsequent authentication attempts on the same > connection. Alternatively, the server may implement a policy whereby > the connection is dropped after a number of failed authentication > attempts. If a server implementation chooses to do so, it should not > drop the connection until at least 3 authentication attempts have > failed. > > Before I do any changes I would like to hear at least 2 more voices in > favor of keeping or removing this paragraph. I'll have to agree with others here. Particularly, since SASL negotiation is acheived via an exchange of data which it is the application protocol's responsibility to transport in an application-specific manner, the SASL implementation is in no position to detect whether two exchanges occur "on the same connection", let alone drop a connection. This is clearly an issue for the application protocol and for site policy. -- Jeff From owner-ietf-sasl Mon Feb 23 15:31:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NNVoFN029463; Mon, 23 Feb 2004 15:31:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NNVoPQ029461; Mon, 23 Feb 2004 15:31:50 -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.11/8.12.8) with ESMTP id i1NNVnmr029453 for ; Mon, 23 Feb 2004 15:31:50 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1NNVtMs018876 for ; Mon, 23 Feb 2004 23:31:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040223152755.04b77618@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 23 Feb 2004 15:31:51 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASL WG session agenda for IETF#59 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 WG (SASL) TUESDAY, March 2 at 1700-1800 ============================= CHAIRS: Sam Hartman Kurt Zeilenga AGENDA: 0) Preliminaries (Blue Sheets, Scribes) - Chairs - 1m 1) WG Status Summary - Chairs - 5m 2) SASL base specification open issues - 25m - Alexey draft-ietf-sasl-rfc2222bis-xx.txt 3) Other open issues - 15m - Editors draft-ietf-sasl-*-xx.txt 4) Milestone review - Chairs - 5m 5) Open mic - Floor - remaining time From owner-ietf-sasl Mon Feb 23 16:43:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1O0hsbL033551; Mon, 23 Feb 2004 16:43:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1O0hsqi033550; Mon, 23 Feb 2004 16:43:54 -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.11/8.12.8) with ESMTP id i1O0hoAd033542 for ; Mon, 23 Feb 2004 16:43:51 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1O0hlMs019871; Tue, 24 Feb 2004 00:43:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 23 Feb 2004 16:43:43 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@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:04 AM 2/17/2004, Simon Josefsson wrote: >Hello all. I've read the latest document, and in general it looks >good (I've sent a couple of editorial changes to Alexey). However, I >find the SASLprep discussions not as clear. > >I tried to separate my issues into several e-mail, but eventually I >was unable to do so. The issues are closely intertwined, and >resolving one question modify the assumptions for other questions. So >forgive this longish e-mail. I have tried to separate the focus; >first to matters that affect mechanism specifications, then profile >specifications, and then to SASL library implementations. > >I'm sure that most of my issues could be solved by elaborating the >text, so the reader can understand what the intended general >philosophy is. Mostly I have refrained from suggesting specific >solutions, and below I only try to understand the current document. >My hope is that these ramblings can be turned into specific pointers >to where the document could be improvement, so that other people don't >have to ask the same questions I do. > >In 5.2 "Mechanism profile guidelines" there is this paragraph: > > Authentication mechanisms SHOULD encode character strings in UTF-8 > [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character > sets in IETF protocols). In order to avoid interoperability problems > due to differing normalizations, when a mechanisms specifies that > character data is to be used as input to a cryptographic and/or > comparison function, the mechanism specification MUST detail how the > data is to be represented, including any normalizations or other > preparations, to ensure proper function. Designers of mechanisms > SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] where applicable. > >I fail to understand several things here. > >First, does 'character strings' include the authorization identity? >Defining the term 'character string', or at least giving examples, >would help. No. I believe the text should be clarified. Mechanisms should be capable of exchanging the authorization identity, but its handling (in particular for comparison) is specific to the application-level protocol which has profiled use of SASL as an authentication method. >Second, is the 'MUST' conditioned on the 'when', or is the 'when' only >there to give the rationale behind the 'MUST'? In other words, is the >intention that all mechanisms MUST detail the normalization etc steps, >regardless of whether they input the strings to >cryptographic/comparison functions? I believe its conditional. It likely should be reworded for clarity. >Third, similarly, does the 'SHOULD' apply to all mechanisms, or just >those that actually use the 'character strings' as input to >cryptographic operations? It applies to "applicable" character strings. SASLprep is not applicable to all character strings. >For the sake of argument, I'm assuming the authorization identity is >considered a character string (this is my experience with deployed >tools, the administrator just types in the authorization identity). As noted above, I think this text should be clarified as not applying to the authorization identity. Even though most of the rest of your comments depend on your assumption, I went ahead and injected a few comments here and there. >Further, mechanisms MUST specify normalization, and SHOULD use >SASLprep "where applicable", for the processing of all character >strings, including the authorization identity. Ignoring the "including the authorization identity", yes. >The "where applicable" qualifier mostly invalidate the keywords. I think not. The statement says designers should consider whether use of SASLprep, if applicable, is appropriate. That implies that they should consider both the applicability of SASLprep and, if applicable, its appropriateness. The "where applicable" was added because we didn't want designers to think they SHOULD use SASLprep for all character strings. They SHOULD use SASLprep for kinds of character strings which SASLprep was designed to be used with. >When is SASLprep applicable or not? That's discussed in the SASLprep I-D, namely in Section 1 but also in Section 2 and 3. >That seems rather subjective to me. Consideration of a "SHOULD" is always subjective. >Otherwise, I believe this SHOULD, without any verifiable >technical consequences, should be removed. I disagree. >Let's go the section 5.1 "Protocol profile requirements": > 8) A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics. A protocol profile MUST specify the > form of the authorization identity (since it is protocol specific, as > opposed to the authentication identity, which is mechanism specific) > and how authorization identities are to be compared. Profiles whose > authorization identities are simple user names (e.g. IMAP [RFC 3501]) > SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] to prepare these names for matching. The > profiles MAY use a stringprep profile that is more strict than > SASLprep. > >This says the form of the authorization identity is protocol specific. >Given the recommendations in 5.2 for mechanism specification to modify >the form of the authorization identity, it appears to be in conflict. Correct. That's why 5.2 should be clarified as not to apply to authorization identities. >In order words: Should the authzid normalization procedure defined by >the mechanism be run before or after the authzid normalization >procedure defined by the profile? There should be no mechanism specific normalization of the authorization identity. In regards to the mechanism, both peers should use the client provided string in all functions. This likely should be stated in the mechanism profile requirements. >I'm assuming here that "server" refer to the actual application, not >the server part of the generic SASL implementation. The term "server" refers to the service-providing peer and a "server implementation" refers to all components which make up that peer (operating system, libraries, program code, and any and all supporting external systems on that end). What is or isn't in a library is an implementation detail. >Up until now, at >least my SASL implementation has not been aware of the protocol that >uses the library. The justification for this is the same that SASL >mechanisms shouldn't contain SASL profile specific behaviour, and vice >versa: > > A protocol profile SHOULD NOT attempt to amend the definition of > mechanisms or make mechanism-specific encodings. This breaks the > separation between protocol and mechanism that is fundamental to the > design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. I note, this should be s/profile neutral/protocol neutral/. >Is my interpretation of what "server" refer to here correct? That >only the protocol specific part SHOULD verify the authzid form? It means that the protocol profile is to specify the form of the authzid (and how to compare it) and the mechanism should just provide a mechanism for exchanging the authzid. Kurt From owner-ietf-sasl Wed Feb 25 09:16:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHGbI2019285; Wed, 25 Feb 2004 09:16:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PHGbQj019284; Wed, 25 Feb 2004 09:16:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHGTFD019274 for ; Wed, 25 Feb 2004 09:16:30 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aw2e4-0005nY-00 for ; Wed, 25 Feb 2004 18:16:28 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 17:16:28 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 17:16:28 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Wed, 25 Feb 2004 18:16:15 +0100 Lines: 16 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:zwy/LZCR4VXyP4kl2cYxiVwkSBM= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >>First, does 'character strings' include the authorization identity? >>Defining the term 'character string', or at least giving examples, >>would help. > > No. I believe the text should be clarified. Mechanisms should be > capable of exchanging the authorization identity, but its handling > (in particular for comparison) is specific to the application-level > protocol which has profiled use of SASL as an authentication method. I see. Thanks for the reply, I'll review my issues once an updated draft is available. Regards, Simon From owner-ietf-sasl Wed Feb 25 15:08:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PN8dch044214; Wed, 25 Feb 2004 15:08:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PN8cp5044213; Wed, 25 Feb 2004 15:08:38 -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.11/8.12.8) with ESMTP id i1PN8XUm044200 for ; Wed, 25 Feb 2004 15:08:38 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1PN8aMs052713 for ; Wed, 25 Feb 2004 23:08:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 15:08:30 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: sasl-rfc2222bis: multiple authentication attack 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: In review of the latest draft, I've come across a number of technical and editorial concerns which I intend to start a number of separate threads on. This is the first. I am particularity perplexed by the long discussion of the "Multiple Authentication attack", an attack which only impacts certain kinds of distributed server implementations, which seems to overshadow higher risk, more generally applicable attacks. I am quite concerned about the addition of: > The protocol profiles that allow for > reauthentication SHOULD recommend that another security layer is > negotiated once a security layer was installed. as, if the implementation were subject to this kind of attack, simply recommending, or even requiring, negotiation of another security layer does not fully mitigate the risk. A server which is subject to such attack should simply refuse re-authentication (or if the implementor was only concerned about post re-authentication attacks, it can refuse re-authentications which don't result in installation of new layers). It seems odd to address what is a protocol-neutral security consideration in this fashion (a recommendation upon protocol profiles). Anyways, as previously discussed (and, I believe, agreed), this issue is best addressed through statement of security considerations. Hence, I suggest that all mention of this attack be removed from section 6.3, including all of section 6.3.1, and that the Security Consideration mention of 6.3.1 be replaced with (and merged with the preceding paragraph about distributed server implementations): It may be appropriate for a server to disallow all re-authentication, or re-authentications which do not result in new security layers being established, involving non- (or insufficiently) trusted parties. In some cases, it may be appropriate for the server to require separate connections to access information in different protected information spaces. Kurt From owner-ietf-sasl Wed Feb 25 15:45:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PNjbxM046455; Wed, 25 Feb 2004 15:45:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PNjbQ3046454; Wed, 25 Feb 2004 15:45:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PNjYdA046447 for ; Wed, 25 Feb 2004 15:45:35 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aw8ih-0001kO-00 for ; Thu, 26 Feb 2004 00:45:39 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 23:45:39 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 23:45:39 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Thu, 26 Feb 2004 00:45:27 +0100 Lines: 63 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:61ow7DN5S5lmMgWQugLB6GAECxQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Below is an image of how I perceive the normalization in rfc2222bis is intended to work, after extrapolating how Kurt's suggestions will be applied to the next version of the document. The requirement on mechanisms is to transport F(AuthZId) unmodified to the server. Profiles may normalize the AuthZId however they want, and mechanism may normalize authentication identities however they want. Mechanism may not normalize the authorization further (even for internal cryptographic processing). Is this correct? (I prefer not to speculate like this, because it generate long and potentially irrelevant e-mails, but was asked to do so to speed up the progress of the draft, please bear with me.) If so, and here comes my question, if two protocol profiles uses different normalizations, and a mechanism is implemented by storing a hash of H(Username|AuthId|AuthZid) (or it works in some similar way), the mechanism appear to need to select among different password databases, depending on which protocol is used. Implementation wise, the mechanism must know which protocol is used to select the correct database. If this is not done, there is the question of which normalization to use when the server compute H(U|A|Az) when storing it in the database. If only one of the protocol normalization steps is used, then it won't work with the other protocol. If both normalizations are stored, without the information on what protocol is used for each hash, someone might create an authorization identity in one of the protocols that map to another authorization identity in the other protocol. If the database also store which protocol the AuthZId was normalized for, before the hash, it would work if the mechanism knew the protocol that is used, but would prevent using the same database for new protocols using SASL. The password database is coupled to the protocol, in general. This seem to be a different model than what RFC 2222 used, which will affect implementations. Authentication Authorization Identity Identity - AuthZId | | | | | \|/ \|/ +-------------------+ +--------------------+ | Protocol profile | | | | | normalization | | \|/ | +-------------------+ | +---------------+ | | | | Mechanism | | | | | Normalization | | | | +---------------+ | | | | | | | \|/ | | Possibly revised | +-----------+ | | authorization identity | | Mechanism |<----|<-----------+ F(AuthZId) | +-----------+ | | | | | | | +--------------------+ | | Client | ............|.......................... Server | | \|/ Regards, Simon From owner-ietf-sasl Wed Feb 25 17:14:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1ECFS051629; Wed, 25 Feb 2004 17:14:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1ECrM051627; Wed, 25 Feb 2004 17:14:12 -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.11/8.12.8) with ESMTP id i1Q1EBSt051620 for ; Wed, 25 Feb 2004 17:14:11 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1E8Ms054515; Thu, 26 Feb 2004 01:14:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:14:01 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@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: It's my view that the mechanism provides method for transferring an string representing the authorization identity. Not only is the form of this authorization identity protocol specification, but how to compare two authorization identities is a matter of the protocol specification. The protocol specification must detail where any normalization (in the broadest sense) is to be done. It could be done on the client side, or the server side, or a combination. Hence, it is very important that where a mechanism uses the authorization identity as input to a cryptographic function that it uses the precise form transferred (or to be transferred) by the mechanism. That is, any and all client side normalization (per the protocol profile) of the authzid must occur before input to the function and no server side normalization (per the protocol profile) of the authzid must occur before input to the function. From the protocol perspective, user provided authzid -> client side normalization -> transfer by mechanism -> server side normalization -> use From a mechanism perspective, the protocol normalization (if any) that is occurring is irrelevant as it's only responsible for its transfer. If the mechanism does do anything with the authorization identity, such as inputs into a cryptographic function, it MUST use the value as transferred. So, I think your picture is not correct as it implies normalization is a client side matter. That is not necessarily the case. At 03:45 PM 2/25/2004, Simon Josefsson wrote: >Below is an image of how I perceive the normalization in rfc2222bis is >intended to work, after extrapolating how Kurt's suggestions will be >applied to the next version of the document. The requirement on >mechanisms is to transport F(AuthZId) unmodified to the server. >Profiles may normalize the AuthZId however they want, including at the client and/or the server. >and mechanism >may normalize authentication identities however they want. including at the client and/or the server. >Mechanism >may not normalize the authorization further (even for internal >cryptographic processing). Is this correct? Yes. mechanisms are responsible only for transferring the a string which represents, in an protocol specific manner, the authorization identity. >(I prefer not to >speculate like this, because it generate long and potentially >irrelevant e-mails, but was asked to do so to speed up the progress of >the draft, please bear with me.) > >If so, and here comes my question, if two protocol profiles uses >different normalizations, and a mechanism is implemented by storing a >hash of H(Username|AuthId|AuthZid) (or it works in some similar way), Huh? I assume you meant H(authcid|password|authzid) or something similar. Anyways, it's bogus for the mechanism implementation to do much of anything with the authzid, except ensuring it is transferred properly, as its semantics are protocol specific. The mechanism implementation should likely have stored H(authcid|password) instead. >the mechanism appear to need to select among different password >databases, depending on which protocol is used. No, it just should not include the authzid in that database. There should be, logically, a separate database which proxy authentication (identity assumption) policy. Note that this database likely keys off a protocol-specific mapping of the authentication identity. That is, off the authzid which would have been derived from the authentication identity if no authzid has been transferred. It should be noted that this mapping requires both knowledge of the mechanism-specific form of the authentication identity and the protocol-specific form of the authorization identities. Of course, implementations might actual use other forms of identities for access control and other policy decisions... (meaning there may additional identity mappings going on). Kurt >Implementation wise, >the mechanism must know which protocol is used to select the correct >database. If this is not done, there is the question of which >normalization to use when the server compute H(U|A|Az) when storing it >in the database. If only one of the protocol normalization steps is >used, then it won't work with the other protocol. If both >normalizations are stored, without the information on what protocol is >used for each hash, someone might create an authorization identity in >one of the protocols that map to another authorization identity in the >other protocol. If the database also store which protocol the AuthZId >was normalized for, before the hash, it would work if the mechanism >knew the protocol that is used, but would prevent using the same >database for new protocols using SASL. The password database is >coupled to the protocol, in general. This seem to be a different >model than what RFC 2222 used, which will affect implementations. > > Authentication Authorization > Identity Identity - AuthZId > | | > | | > | \|/ > \|/ +-------------------+ > +--------------------+ | Protocol profile | > | | | | normalization | > | \|/ | +-------------------+ > | +---------------+ | | > | | Mechanism | | | > | | Normalization | | | > | +---------------+ | | > | | | | > | \|/ | | Possibly revised > | +-----------+ | | authorization identity > | | Mechanism |<----|<-----------+ F(AuthZId) > | +-----------+ | > | | | > | | | > +--------------------+ > | > | > Client | > ............|.......................... > Server | > | > \|/ > >Regards, >Simon From owner-ietf-sasl Wed Feb 25 17:37:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1bXr9053250; Wed, 25 Feb 2004 17:37:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1bXDL053249; Wed, 25 Feb 2004 17:37:33 -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.11/8.12.8) with ESMTP id i1Q1bWG7053243 for ; Wed, 25 Feb 2004 17:37:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1bUMs054845; Thu, 26 Feb 2004 01:37:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225173539.04ca4028@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:37:23 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@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 05:14 PM 2/25/2004, Kurt D. Zeilenga wrote: >Hence, it is very important that where a mechanism uses the >authorization identity as input to a cryptographic function that >it uses the precise form transferred (or to be transferred) by >the mechanism. I note that DIGEST-MD5 is an example of a mechanism which uses the transferred authzid value as input to a cryptographic function. Kurt From owner-ietf-sasl Wed Feb 25 17:34:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1Y6L6053088; Wed, 25 Feb 2004 17:34:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1Y6Hk053086; Wed, 25 Feb 2004 17:34:06 -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.11/8.12.8) with ESMTP id i1Q1Y3cs053080 for ; Wed, 25 Feb 2004 17:34:03 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1Y9Ms054812 for ; Thu, 26 Feb 2004 01:34:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:34:02 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: sasl-rfc2222bis review notes [long] 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: Here are my review notes.... >Network Working Group A. Melnikov >Internet Draft Editor >Document: draft-ietf-sasl-rfc2222bis-06.txt February 2004 >Obsoletes: RFC 2222 Expires in six months > > > Simple Authentication and Security Layer (SASL) > >Status of this Memo > > This document is an Internet Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet Drafts are working documents of the Internet Engineering > Task Force (IETF), its Areas, and its Working Groups. Note that > other groups may also distribute working documents as Internet > Drafts. Internet Drafts are draft documents valid for a maximum of > six months. Internet Drafts may be updated, replaced, or obsoleted > by other documents at any time. It is not appropriate to use > Internet Drafts as reference material or to cite them other than as > ``work in progress''. > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > A revised version of this draft document will be submitted to the RFC > editor as a Standards Track RFC for the Internet Community. > Discussion and suggestions for improvement are requested. > Distribution of this draft is unlimited. > > When published as an RFC this document will obsolete RFC 2222. This statement needs to be moved into the body of the document. That is, the body of the document needs to explicitly state: This document replaces RFC 2222. (see below) > > >1. Abstract The abstract need not be numbered. > The Simple Authentication and Security Layer (SASL) provides a method > for adding authentication support with an optional security layer to > connection-based protocols. As used here, the word "optional" implies that protocols MAY include security layer support. Suggest this be reworded The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-based protocols. > It also describes a structure for > authentication mechanisms. The result is an abstraction layer > between protocols and authentication mechanisms such that any SASL- > compatible authentication mechanism can be used with any SASL- > compatible protocol. > > This document describes how a SASL authentication mechanism is > structured, describes how a protocol adds support for SASL, defines > the protocol for carrying a security layer over a connection, and > defines the EXTERNAL SASL authentication mechanism. It might be better to transpose EXTERNAL and SASL here. >2. Organization of this document > >2.1. How to read this document > > This document is written to serve several different audiences, > protocol designers using this specification to support authentication > in their protocol, mechanism designers that define new SASL > mechanisms, and implementors of clients or servers for those > protocols using this specification. I suggest using a bullet list for the above. > The sections "Overview", "Authentication Mechanisms", "Protocol > Profile Requirements", "Specific Issues", and "Security > Considerations" cover issues that protocol designers need to > understand and address in profiling this specification for use in a > specific protocol. > > The sections "Overview", "Authentication Mechanisms", "Mechanism > Profile Requirements" and "Security Considerations" cover issues that > mechanism designers need to understand and address in designing new > SASL mechanisms. > > Implementors of a protocol using this specification need the > protocol-specific profiling information in addition to the > information in this document. This implies implementors need to understand all of this document. They should not need to read the protocol and mechanism profiling requirements. >2.2. Conventions used in this document > > In examples, "C:" and "S:" indicate lines sent by the client and > server respectively. > > The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" > in this document are to be interpreted as defined in "Key words for > use in RFCs to Indicate Requirement Levels" [KEYWORDS]. > > Character names in this document use the notation for code points and > names from the Unicode Standard [Unicode]. For example, the letter > "a" may be represented as either or . > > This document uses terms "integrity protection" and "confidentiality > protection". The former references to a security layer that is able > to detect data modification by using some kind of hash. However, I suggest the "by using some kind of hash" qualification be dropped. The term "integrity protection" applies to any layer which is capable of detecting data modification (regardless of whether it using some kind of hash or not). I suggest: The term "integrity protection" refers to a security layer designed to detect unauthorized data modification. > integrity protection doesn't make the data unreadable to an attacker. Suggest instead: However, integrity protection does not (by itself) prevent unauthorized disclose of the data. > Confidentiality protection is a security layer that is able to make > the data unreadable to an attacker by using encryption. Suggest: Confidentiality protection is a security layer which is designed to prevent unauthorized disclose of the data (generally through use of encryption). > Confidentiality protection usually implies integrity protection. Suggest: Confidentiality protection usually (but not necessarily) implies integrity protections. Alteratively, replace this and the above "However, .." with Both integrity protection and confidentiality are needed to achieve data security. Note that this is a paraphrased of [RFC 2828] "data security"]. Which brings up the question, why don't we just use "data integrity service" and 'data confidentiality service" as defined in RFC 2828? I think it best to avoid defining SASL-specific security terminology. Also, some note to the effect: Security layers may offer other kinds of security services. > >3. Overview I suggest this section be moved to immediately follow the Abstract and be retitled "Introduction". I then suggest the section 2 subsections be incorporated into this section. > The Simple Authentication and Security Layer (SASL) is a method for > adding authentication support to connection-based protocols. > > The SASL specification has three layers, as indicated in the diagram > below. I'm not sure I like how SASL is described in terms of protocol profiles (which is a technical specification or document) and a mechanism definition (which is a technical specification or document). Also, it seems odd to say "specifies a profile" as a profile is a specification. And the phrase "mechanism definition specifies an authentication mechanism" seems a bit circular. > At the top, a protocol definition using SASL specifies a > profile, including a command for identifying and authenticating a > user to a server and for optionally negotiating a security layer for > subsequent protocol interactions. At the bottom, a SASL mechanism > definition specifies an authentication mechanism. The SASL > framework, specified by this document, constrains the behavior of > protocol profiles and mechanisms, separating protocol from mechanism > and defining how they interact. > > SMTP Protocol LDAP Protocol Etc > Profile Profile . . . > \----- | -----/ > \ | / > SASL framework > / | \ > /----- | -----\ > EXTERNAL DIGEST-MD5 Etc > SASL mechanism SASL mechanism . . . > > This separation between the definition of protocols and the > definition of authentication mechanisms is crucial. It permits an I think it is the separation between (application-level) protocols and mechanisms, not their definitions, that is crucial. > authentication mechanism to be defined once, making it usable by any > SASL protocol profile. In many implementations, the same SASL > mechanism code is used for multiple protocols. Add another (see above) subsection which X.Y. Relationship to other documents This document obsoletes RFC 2222. It replaces all portions of RFC 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete. The GSSAPI mechanism is now separately specified [SASL-GSSAPI]. Appendix B. details changes since RFC 2222. >4. Authentication mechanisms > > SASL mechanisms are named by strings, from 1 to 20 characters in > length, consisting of ASCII [ASCII] upper-case letters, digits, > hyphens, and/or underscores. SASL mechanism names must be registered > with the Internet Assigned Numbers Authority (IANA). IETF standards > track documents may direct the IANA to reserve a portion of the SASL > mechanism namespace and may specify different registration criteria > for the reserved portion; the GSSAPI mechanism specification > [SASL-GSSAPI] does this. The above sentence should be moved in IANA considerations section. > Procedures for registering new SASL mechanisms are given in section 8. > > The "sasl-mech" production below defines the syntax of a SASL > mechanism name. This uses the Augmented Backus-Naur Form (ABNF) > notation as specified in [ABNF] and the ABNF core rules as specified > in Appendix A of the ABNF specification [ABNF]. > > sasl-mech = 1*20mech-char > mech-char = %x41-5A / DIGIT / "-" / "_" > ; mech names restricted to ASCII uppercase letters, > ; digits, "-" and "_" > I suggest this comment be replaced with: ; mech-char is restricted to "A"-"Z", "0"-"9", "-", and "_" : from ASCII character set. In the ABNF, I suggest (for consistency) replacing DIGIT, "-", and "_" with %x30-39, %x2D, and %x5F, respectively. This also avoids unnecessary reliance on a core rule (which would require the implementor to look up meaning of DIGIT). > >4.1. Authentication protocol exchange > > A SASL mechanism is responsible for conducting an authentication > protocol exchange. This consists of a series of server challenges > and client responses, the contents of which are specific to and > defined by the mechanism. To the protocol, the challenges and > responses are opaque binary tokens of arbitrary length. The > protocol's profile then specifies how these binary tokens are then > encoded for transfer over the connection. I suggest replacing binary tokens with octet string because: 1) the challedge and responses must be aligned on 8-bit boundries and 2) what (in IP) isn't binary? 3) the challedge and responses seem not to be "tokens". > After receiving an authentication command or any client response, a > server mechanism may issue a challenge, indicate failure, or indicate > completion. The server mechanism may return additional data with a > completion indication. The protocol's profile specifies how each of > these is then represented over the connection. > > After receiving a challenge, a client mechanism may issue a response > or abort the exchange. The protocol's profile specifies how each of > these is then represented over the connection. > > During the authentication protocol exchange, the mechanism performs > authentication, transmits an authorization identity (frequently known > as a userid) from the client to server, and negotiates the use of a > mechanism-specific security layer. If the use of a security layer is > agreed upon, then the mechanism must also define or negotiate the > maximum security layer buffer size that each side is able to receive. > > >4.2. Authorization and authentication identities > > SASL authentication deals with two identities: the authorization > identity and the authentication identity. I suggest the "authorization identity" and "authentication identity" be defined here (move the below def'ns to here). I suggest defining "authentication identity" first. Doing so, I also suggest swapping the order of the terms in the section title and first sentence. > The transmitted > authorization identity may be an empty string (zero length), but the > transmitted authentication identity may not be an empty string. I think the latter ("but ...") part should be deleted. Nothing says a mechanism has a "transmitted authentication identity", and nothing (in RFC 2222) prevented a mechanism from transmitting an empty authentication identity. Whether or not such is permissible should be left to the mechanisms to decide. In fact, whether or not an authentication identity is explicitly transferred between the SASL client and server should be left the mechanism. It may simply be implied by the client's credentials (as noted below). > A mechanisms which are incapable of transmitting an authorization > identity must be treated as if it always transmits an authorization > identity of an empty string. > > Authentication identity is the identity derived from the client's > authentication credentials. > > The authorization identity is used by the server as the primary > identity for making access policy decisions. > >4.2.1. Authorization identities and proxy authentication > > 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 derive authorization identities from > authentication identities. Instead, clients SHOULD provide no (or > empty) authorization identity when the user has not provided an > authorization identity. > > The server SHOULD verify that a received authorization identity is in > the correct form. Why isn't this a MUST? That is, how are servers to compare or otherwise handle authorization identities which are not in correct form? > Profiles whose authorization identities are simple > user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile > [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare > these names for matching. The profiles MAY use a stringprep profile > that is more strict than "SASLprep". 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. "profile" should be qualified above to refer to the protocol profile. I think it mostly states a protocol profile requirement. But then it includes an implementation imperative. But this is odd in that server may not actually be required to do any preparation (the profile might place that burden on the client). I think the "If the preparation..." part should be reworded as a profile requirement. That is, it should state that profiles should detail how implementations are to behave when required preparation fails. Given that, I think this can and should be moved to Section 5. >4.2.2. Authorization Identity Format > > An authorization identity is a string of zero or more Unicode > [Unicode] coded characters. The NUL character is not > permitted in authorization identities. > > The character encoding scheme used for transmitting an authorization > identity over the protocol is specified in each authentication > mechanism. All IETF-defined mechanisms MUST, and all other > mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF > policy regarding character sets and encoding schemes.) > > 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 an absent > authorization identity MUST be treated as equivalent. A mechanism > which provides an optional field for an authorization identity, > SHOULD NOT allow that field, when present, to be empty. The meaning > of the empty string as an authorization identity is described in the > previous section. > >4.3. Security layers > > If use of a security layer is negotiated by the authentication > protocol exchange, the security layer is applied to all subsequent > data sent over the connection (until another security layer is > negotiated; see also section 6.3). The security layer takes effect > immediately following the last response of the authentication > exchange for data sent by the client and the completion indication > for data sent by the server. > > Note that all SASL mechanisms that are unable to negotiate a security > layer automatically select no security layer. > > Once the security layer is in effect the protocol stream is processed > by the security layer into buffers of security encoded data. Each > buffer of security encoded data is transferred over the connection as > a stream of octets prepended with a four octet field in network byte > order that represents the length of the following buffer. The length > of the security encoded data buffer MUST be no larger than the > maximum size that was either defined in the mechanism specification > or negotiated by the other side during the authentication protocol > exchange. Upon the receipt of a data buffer which is larger than the > defined/negotiated maximal buffer size the receiver SHOULD close the > connection. This might be a sign of an attack or a buggy > implementation. > >5. Protocol and mechanism profiles > >5.1. Protocol profile requirements > > In order to use this specification, a protocol definition MUST supply > the following information: > > 1) A service name, to be selected from the IANA registry of "service" > elements for the GSSAPI host-based service name form [GSSAPI]. This > service name is made available to the authentication mechanism. > > The registry is available at the URL > . > > 2) A definition of the command to initiate the authentication > protocol exchange. This command must have as a parameter the name of > the mechanism being selected by the client. > > The command SHOULD have an optional parameter giving an initial > response. If the protocol allows for the initial response, the > protocol profile SHOULD also describe how an empty initial response > is encoded. This optional parameter allows the client to avoid a > round trip when using a mechanism which is defined to have the client > send data first. When this initial response is sent by the client > and the selected mechanism is defined to have the server start with > an initial challenge, the command fails. See section 6.1 of this > document for further information. > > 3) A definition of the method by which the authentication protocol > exchange is carried out, including how the challenges and responses > are encoded, how the server indicates completion or failure of the > exchange, how the client aborts an exchange, and how the exchange > method interacts with any line length limits in the protocol. > > The exchange method SHOULD allow the server to include an optional > data ("optional challenge") with a success notification. This allows > the server to avoid a round trip when using a mechanism which is > defined to have the server send additional data along with the > indication of successful completion. See section 6.2 of this > document for further information. > > 4) A protocol profile SHOULD specify a mechanism through which a > client may obtain the names of the SASL mechanisms available to it. > This is typically done through the protocol's extensions or > capabilities mechanism. > > 5) Identification of the octet where any negotiated security layer > starts to take effect, in both directions. > > 6) Specify if the protocol profile supports "multiple > authentications" (see section 6.3). > > 7) If both TLS and SASL security layer are allowed to be negotiated > by the protocol, the protocol profile MUST define in which order they > are applied to a cleartext data sent over the connection. Spell TLS out on first use. > 8) A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics. A protocol profile MUST specify the > form of the authorization identity (since it is protocol specific, as > opposed to the authentication identity, which is mechanism specific) > and how authorization identities are to be compared. Profiles whose > authorization identities are simple user names (e.g. IMAP [RFC 3501]) > SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] to prepare these names for matching. The > profiles MAY use a stringprep profile that is more strict than > SASLprep. > > A protocol profile SHOULD NOT attempt to amend the definition of > mechanisms or make mechanism-specific encodings. This breaks the > separation between protocol and mechanism that is fundamental to the > design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. > >5.2. Mechanism profile guidelines > > Designers of new SASL mechanism should be aware of the following > issues: > > 1) Authorization identity. Remove the "." > While some legacy mechanisms are incapable of transmitting an > authorization identity (which means that for these mechanisms the > authorization identity is always the empty string), newly defined > mechanisms SHOULD be capable of transmitting a non-empty > authorization identity. See also section 4.2. > > 2) Character string issues > > Authentication mechanisms SHOULD encode character strings in UTF-8 > [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character > sets in IETF protocols). In order to avoid interoperability problems > due to differing normalizations, when a mechanisms specifies that > character data is to be used as input to a cryptographic and/or > comparison function, the mechanism specification MUST detail how the > data is to be represented, including any normalizations or other > preparations, to ensure proper function. Designers of mechanisms > SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] where applicable. excepting authzid > The preparation can be potentially performed on the client end (upon > getting user input or retrieving a value from configuration) or on > the server end (upon receiving the value from the client, retrieving > a value from its authentication database or generating a new value in > order to store in in the authentication database). SASL mechanisms > must define which entity (or entities) must perform the preparation. > If preparation fails or results in an empty string, the entity doing > the preparation SHALL fail the authentication exchange. > > Implementation note: A server end can be represented by multiple > processes. For example, it may consist of the server process itself > that communicated with a client, and a command line utility (a server > agent) that is able to store passwords/hashes in a database that can > be later used by the server. For the server agent the requirement to > "fail the authentication exchange" should be interpreted as a > requirement to refuse to store the data in the database. > >6. Specific issues > >6.1. Client sends data first > > Some mechanisms specify that the first data sent in the > authentication protocol exchange is from the client to the server. > > If a protocol's profile permits the command which initiates an > authentication protocol exchange to contain an initial client > response, this parameter SHOULD be used with such mechanisms. > > If the initial client response parameter is not given, or if a > protocol's profile does not permit the command which initiates an > authentication protocol exchange to contain an initial client > response, then the server issues a challenge with no data. The > client's response to this challenge is then used as the initial > client response. (The server then proceeds to send the next > challenge, indicates completion, or indicates failure.) > >6.1.1. Client sends data first examples > > The following are two examples of an SECURID authentication [SASL- > SECURID] in the SMTP protocol [SMTP]. In the first example below, > the client is trying fast reauthentication by sending the initial > response: > > S: 220-smtp.example.com ESMTP Server > C: EHLO client.example.com > S: 250-smtp.example.com Hello client.example.com, pleased to meet you This line is too long. Suggest you s/Hello.*/Welcome client.example.com/ > S: 250-AUTH GSSAPI SECURID > S: 250 DSN > C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= > S: 235 Authentication successful > > The example below is almost identical to the previous, but here the > client chooses not to use the initial response parameter. > > S: 220-smtp.example.com ESMTP Server > C: EHLO client.example.com > S: 250-smtp.example.com Hello client.example.com, pleased to meet you This line is too long. > S: 250-AUTH GSSAPI SECURID > S: 250 DSN > C: AUTH SECURID > S: 334 > C: AG1hZ251cwAxMjM0NTY3OAA= > S: 235 Authentication successful > > Section 7.2 contains an additional example. Indention is off here. Also note that 7.2 provides two examples as does 6.2.1. So, this should read: Additonal examples can be found in sections 6.2.1 and 7.2. >6.2. Server returns success with additional data > > Some mechanisms may specify that additional data be sent to the > client along with an indication of successful completion of the > exchange. This data would, for example, authenticate the server to > the client. > > If a protocol's profile does not permit this additional data to be > returned with a success indication, then the server issues the data > as a server challenge, without an indication of successful > completion. The client then responds with no data. After receiving > this empty response, the server then indicates successful completion > (with no additional data). > > Client implementors should be aware of an additional failure case > that might occur when the profile supports sending the additional > data with success. Imagine that an active attacker is trying to > impersonate the server and sends faked data, which should be used to > authenticate the server to the client, with success. (A similar > situation can happen when either the server and/or the client has a > bug and they calculate different responses.) After checking the data, > the client will think that the authentication exchange has failed, > however the server will think that the authentication exchange has > completed successfully. At this point the client can not abort the > authentication exchange; it SHOULD close the connection instead. > However, if the profile did not support sending of additional data > with success, the client could have aborted the exchange at the very > last step of the authentication exchange. > >6.2.1. Server returns success with additional data examples > > The following are two examples of a DIGEST-MD5 authentication [SASL- > DIGEST] in the XMPP protocol [XMPP]. In the first example below, the > server is sending mutual authentication data with success. spell XMPP out on first use. > > C: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > to='example.com' > version='1.0'> > S: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > id='c2s_234' > from='example.com' > version='1.0'> > S: > > DIGEST-MD5 > CRAM-MD5 > > > C: mechanism='DIGEST-MD5'/> > S: > cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi This line is too long... > LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== > > C: > dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i > T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw > MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i > LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo > YXJzZXQ9dXRmLTgK > > S: > cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= > > > The example below is almost identical to the previous, but here > the server chooses not to use the additional data with success. > > C: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > to='example.com' > version='1.0'> > S: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > id='c2s_234' > from='example.com' > version='1.0'> > S: > > DIGEST-MD5 > CRAM-MD5 > > > C: mechanism='DIGEST-MD5'/> > S: > cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi This line is too long. > LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== > > C: > dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i > T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw > MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i > LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo > YXJzZXQ9dXRmLTgK > > S: > cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= > > C: > S: > >6.3. Multiple authentications > > Unless otherwise stated by the protocol's profile, only one > successful SASL negotiation may occur in a protocol session. In this > case, once an authentication protocol exchange has successfully > completed, further attempts to initiate an authentication protocol > exchange fail. > 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 remains in effect. > > Note that keeping the original security layer is a subject to a class > of security attack described in section 6.3.1. I think this note should be deleted. We haven't inserted notes for other security attacks. And we've covered this with a far more general security consideration. The description itself, which I don't think is terrible useful (have such a long description over such a minor security issue distracts attention from major security issues which have little to no description). I think section 6.3.1 (and this paragraph, especially given the need to further detail the limited effectiveness of the below SHOULD) should be deleted. > However, at the time > of the writing of this document the Working Group consensus is not to > change SASL handling of security layers, as the risk of such attacks > is considered to be low and specific to only certain classes of > implementations. The protocol profiles that allow for > reauthentication SHOULD recommend that another security layer is > negotiated once a security layer was installed. I don't believe there is sufficient reason to state this as a SHOULD upon protocols profiles. As noted, it is only specific to a certain class of implementations. As previously discussed in the WG, this can and should be addressed through a security consideration stating that implementations within this class takes steps, such as enforcing a local policy disallowing subsequent authentication, to mitigate this risk. The security consideration description seems to be sufficiently address this risk. I suggest we focus discussion on this (the stated security consideration). (Also, note that simply reauthenticating with another security layer does fully mitigate the risk as the subsequent authentication is operating over the old layers. If we state this SHOULD, then we'd have to also state a security consideration noting that it ineffective in some cases.) > 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. I suggest this be replaced with: Where a protocol profile does permit multiple successful SASL negotiations, the profile MUST detail the effect of a failed SASL negotiation upon the previously established authentication state. In particular, it MUST state whether the previously established authenticated state remain in force or whether the connection is to revert to an non-authenticated state. Regardless of the specified effect upon authentication state, the previously negotiated security layer remains in effect. >6.3.1. Description of Multiple Authentication attack > > Let's assume that the protected resources on a server are partitioned > into a set of protection spaces, each with its own authentication > mechanisms and/or authorization database. Let's use the term > "partition" to reference any such protected space. An example of a > partition might be an HTTP "realm". Also a proxy/frontend can use > different partitions for different servers/backends it represents. > > Now consider the following scenario. A client has already > authenticated and established a security layer with "Partition A" > which is managed by the server AA. Now the same client authenticates > to "Partition B" (managed by the server BB) without negotiating a new > security layer, while the security layer negotiated with "Partition > A" remains in effect. The server BB is now able to observe how known > cleartext is encrypted. This scenario enables the server BB to make > guesses about previously observed ciphertext between the client and > the server AA using the server's SASL engine as an oracle. This > scenario is illustrated below: > > > +---------+ +---------+ > | | | | > |Partition| |Partition| > | B | | A | > +---------+ +---------+ > | ^ | > | : +-----------+ | > Traffic from | : | Encryption| | Traffic from A > B to client +-------->| end point |<-------+ to client > : | (SSL/SASL)| > : +-----------+ > : | > : | > : +---+ > : | | > : | | > : | | Encryption tunnel, e.g. SASL or SSL, > : | | between the server > (1) Recording +---------:| | and a single client only. > encrypted | | Separate tunnels to different > traffic between | | clients. > Partition A and client +---+ > | > | > +-----------> Traffic to clients > > < > > Where this situation cannot be managed through trust relationship, it > may be appropriate for the server implementation to not support > multiple authentications. >> > > > >7. The EXTERNAL mechanism > > The mechanism name associated with external authentication is > "EXTERNAL". > > The client sends an initial response with the UTF-8 encoding of the > authorization identity. The form of the authorization identity is > further restricted by the application-level protocol's SASL profile. > > The server uses information, external to SASL, to determine whether > the client is authorized to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > > > >A. Melnikov FORMFEED[Page 14] > > > > > >Internet DRAFT SASL 14 February 2004 > > > server indicates failure. > > The system providing this external information may be, for example, > IPSec or TLS. Spell IPsec out on first use. > However, the client can make no assumptions as to what > information the server can use in determining client authorization. > For example, just because TLS was established, doesn't mean that the > server will use the information provided by TLS. > > If the client sends the empty string as the authorization identity, > the authorization identity is to be derived from authentication > credentials which exist in the system that is providing the external > authentication. > >7.1. Formal syntax > > The following syntax specification uses the augmented Backus-Naur > Form (BNF) notation as specified in [ABNF]. This uses the ABNF core > rules as specified in Appendix A of the ABNF specification [ABNF]. I don't believe any Appendix A core rules are used here. > Non-terminals referenced but not defined below are as defined by > [UTF-8]. I suggest the non-terminal productions be directly incorporated into this document. > The "extern-init-resp" rule below defines the initial response sent > from client to server. > > extern-init-resp = *( UTF8-char-no-nul ) > > UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 > > UTF8-1-no-nul = %x01-7F > > >7.2. Example > > The following is an example of an EXTERNAL authentication in the SMTP > protocol [SMTP]. In this example, the client is proxy > authenticating, sending the authorization identity "fred" using in > the (optional) initial response. The server has determined the > client's identity through IPsec and has a security policy that > permits that identity to proxy authenticate as any other identity. An informative reference for IPsec seems appropriate here as presently worded. Suggest it be reworded, The server has obtained the client's (authentication) identity from an external service, such as IPsec, and has a security policy that permits that identity to assume the identity of the asserted authorization identity. > To the protocol profile, the four octet sequence "fred" is an opaque > binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies > that server challenges and client responses are encoded in BASE64 > [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==". > > S: 220 smtp.example.com ESMTP server ready > C: EHLO jgm.example.com > S: 250-smtp.example.com > > > >A. Melnikov FORMFEED[Page 15] > > > > > >Internet DRAFT SASL 14 February 2004 > > > S: 250 AUTH DIGEST-MD5 EXTERNAL > C: AUTH EXTERNAL ZnJlZA== > S: 235 Authentication successful. > > The following example is almost identical to the one above, but the > client doesn't use proxy authentication. s/use/request/ > S: 220 smtp.example.com ESMTP server ready > C: EHLO jgm.example.com > S: 250-smtp.example.com > S: 250 AUTH DIGEST-MD5 EXTERNAL > C: AUTH EXTERNAL > S: 235 Authentication successful. > > >8. IANA Considerations > >8.1. Guidelines for IANA > > It is requested that IANA updates the SASL mechanisms registry as > follows: > > Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism > registrations to OBSOLETE. Change the "Published specification" > of the EXTERNAL mechanism to this document. Updated registration > is provided in Section 8.6. s/registration/registration information/ > >8.2. Registration procedure > > > Registration of a SASL mechanism is done by filling in the template > in section 8.5 and sending it via electronic mail to . > IANA has the right to reject obviously bogus registrations, but will > perform no review of claims made in the registration form. SASL > mechanism registrations are currently available at the URL > . > > There is no naming convention for SASL mechanisms; any name that > conforms to the syntax of a SASL mechanism name can be registered. > An IETF Standards Track document may reserve a portion of the SASL > mechanism namespace ("family of SASL mechanisms") for its own use, > amending the registration rules for that portion of the namespace. > Each family of SASL mechanisms MUST be identified by a prefix. > > While the registration procedures do not require it, authors of SASL > > > >A. Melnikov FORMFEED[Page 16] > > > > > >Internet DRAFT SASL 14 February 2004 > > > mechanisms are encouraged to seek community review and comment > whenever that is feasible. Authors may seek community review by > posting a specification of their proposed mechanism as an Internet- > Draft. SASL mechanisms intended for widespread use should be > standardized through the normal IETF process, when appropriate. > >8.3. Comments on SASL mechanism registrations > > Comments on registered SASL mechanisms should first be sent to the > "owner" of the mechanism and/or to the SASL WG mailing list. > Submitters of comments may, after a reasonable attempt to contact the > owner, request IANA to attach their comment to the SASL mechanism > registration itself. If IANA approves of this, the comment will be > made accessible in conjunction with the SASL mechanism registration > itself. > >8.4. Change control > > Once a SASL mechanism registration has been published by IANA, the > author may request a change to its definition. The change request > follows the same procedure as the registration request. > > The owner of a SASL mechanism may pass responsibility for the SASL > mechanism to another person or agency by informing IANA; this can be > done without discussion or review. > > The IESG may reassign responsibility for a SASL mechanism. The most > common case of this will be to enable changes to be made to > mechanisms where the author of the registration has died, moved out > of contact or is otherwise unable to make changes that are important > to the community. > > SASL mechanism registrations may not be deleted; mechanisms which are > no longer believed appropriate for use can be declared OBSOLETE by a > change to their "intended use" field; such SASL mechanisms will be > clearly marked in the lists published by IANA. > > The IESG is considered to be the owner of all SASL mechanisms which > are on the IETF standards track. > >8.5. Registration template > > > Subject: Registration of SASL mechanism X > > Family of SASL mechanisms: (YES or NO) > > SASL mechanism name (or prefix for the family): > > > >A. Melnikov FORMFEED[Page 17] > > > > > >Internet DRAFT SASL 14 February 2004 > > > Security considerations: > > Published specification (optional, recommended): > > Person & email address to contact for further information: > > Intended usage: > > (One of COMMON, LIMITED USE or OBSOLETE) > > Owner/Change controller: > > (Any other information that the author deems interesting may be > added below this line.) > > >8.6. The EXTERNAL mechanism registration > > It is requested that the SASL Mechanism registry [IANA-SASL] entry > for the EXTERNAL mechanism be updated to reflect that this document > now provides its technical specification. > > > Subject: Updated Registration of SASL mechanism EXTERNAL > > Family of SASL mechanisms: NO > > SASL mechanism name: EXTERNAL > > Security considerations: See RFC XXXX, section 9. > > Published specification (optional, recommended): RFC XXXX > > Person & email address to contact for further information: > Alexey Melnikov > > Intended usage: COMMON > > Owner/Change controller: IESG > > Note: Updates existing entry for EXTERNAL > >9. Security considerations > > Security issues are discussed throughout this memo. > > The mechanisms that support integrity protection are designed such > that the negotiation of the security layer and authorization identity > is integrity protected. This statement seems a bit circular. Also, "integrity protection" was defined as providing the capability to detection unauthorized changes to data transfered by the security layer. However this uses the term implies that the authentication exchange, including layer negotiation is protected. This is problematic. If we look at DIGEST-MD5, which does offer a security layer with "integrity protection", we find a mechanism which does provide full integrity protection over the authentication exchange itself. I think we need to a bit more precise with our terminology. To avoid having to define a SASL-specific terminology, I strongly recommend we try to use RFC 2828 based terminology. When the client selects a security layer > with at least integrity protection, this protects against an active > attacker hijacking the connection and modifying the authentication > exchange to negotiate a plaintext connection. > > When a server or client supports multiple authentication mechanisms, > each of which has a different security strength, it is possible for > an active attacker to cause a party to use the least secure mechanism > supported. To protect against this sort of attack, a client or > server which supports mechanisms of different strengths should have a > configurable minimum strength that it will use. It is not sufficient > for this minimum strength check to only be on the server, since an > active attacker can change which mechanisms the client sees as being > supported, causing the client to send authentication credentials for > its weakest supported mechanism. > > The client's selection of a SASL mechanism is done in the clear and > may be modified by an active attacker. It is important for any new > SASL mechanisms to be designed such that an active attacker cannot > obtain an authentication with weaker security properties by modifying > the SASL mechanism name and/or the challenges and responses. > > In order to detect Man-in-the-middle (MITM) attacks the client MAY > list available SASL mechanisms 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. 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 (or don't support listing of SASL mechanisms once > authentication is complete); for these protocols clients MUST NOT > treat an empty list of SASL mechanisms after authentication as a MITM > attack. > > Any protocol interactions prior to authentication are performed in > the clear and may be modified by an active attacker. In the case > where a client selects integrity protection, it is important that any > security-sensitive protocol negotiations be performed after > authentication is complete. Protocols should be designed such that > negotiations performed prior to authentication should be either > ignored or revalidated once authentication is complete. > > When use of a security layer is negotiated by the authentication > protocol exchange, the receiver should handle gracefully any security > encoded data buffer larger than the defined/negotiated maximal size. > In particular, it must not blindly allocate the amount of memory > specified in the buffer size field, as this might cause the "out of > memory" condition. If the receiver detects a large block, it SHOULD > close the connection. > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. It should be > noted that, where those secrets are used to provide data > confidentiality protections, if a third party (other than the > discloser/disclosee) has knowledge of some portion of the protected > information, it can use this knowledge in an attack upon other > portions of the protected information. > > Section 6.3.1 contains a description of a potential class of attack > on a distributed server implementation. The section also gives some > recommendations about mitigating such attacks. Replace with (and append to preceding paragraph): It may be appropriate for a server to disallow all re-authentication, or re-authentications which do not result in new security layers being established, involving non- (or insufficiently) trusted parties. In some cases, it may be appropriate for the server to require separate connections to access information in different protected information spaces. > "stringprep" and Unicode security considerations apply to > authentication identities, authorization identities and passwords. > > The EXTERNAL mechanism provides no security protection; it is > vulnerable to spoofing by either client or server, active attack, and > eavesdropping. It should only be used when external security > mechanisms are present and have sufficient strength. > >10. References > >10.1. Normative References > > [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997 > > [ASCII] American National Standards Institute, "Code Extension > Techniques for Use with the 7-bit Coded Character Set of American > National Standard Code (ASCII) for Information Interchange", FIPS PUB > 35, 1974 > > [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and > Languages", RFC 2277, BCP 18, January 1998 > > [GSSAPI] Linn, J., "Generic Security Service Application Program > Interface, Version 2, Update 1", RFC 2743, January 2000 > > [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - > Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. This reference is never used and hence should be deleted. > [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", RFC 2119, BCP 19, March 1997 > > [Unicode] The Unicode Consortium, "The Unicode Standard, Version > 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, > MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the > "Unicode Standard Annex #27: Unicode 3.1" > (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard > Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). > > [Stringprep] Hoffman, P., Blanchet, M., "Preparation of > Internationalized Strings ("stringprep")", RFC 3454, December 2002. > > [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names > and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. > > [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", > RFC 3629, STD 63, November 2003. > >10.2. Informative References > > [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in > progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 > > [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest > Authentication as a SASL Mechanism", work in progress, draft-ietf- > sasl-rfc2831bis-XX.txt, replaces RFC 2831 > > [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC > 2444, October 1998. > > [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC > 2808, April 2000. > > [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April > 2001. > > [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", > RFC 2554, March 1999. > > Being revised by Siemborski, R., "SMTP Service Extension for > Authentication", work in progress, draft-siemborski-rfc2554bis- > XX.txt. This reference should be put into proper form. > > [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol > (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data > > > >A. Melnikov FORMFEED[Page 21] > > > > > >Internet DRAFT SASL 14 February 2004 > > > Encodings", RFC 3548, July 2003. > > [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC > Authors", RFC 2223, October 1997. > > [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) > MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. > >11. Editor's Address > > Alexey Melnikov > Isode Limited > > Email: Alexey.Melnikov@isode.com > >12. Acknowledgments > > This document is a revision of RFC 2222 written by John G. Myers. He > also contributed significantly to this revision. > > Magnus Nystrom provided the ASCII art used in Section 6.3. > > Definition of partition was extracted from RFC 2617 ("HTTP > Authentication: Basic and Digest Access Authentication"). > > Contributions of many members of the SASL mailing list are gratefully > acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob > Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen and > Abhijit Menon-Sen for proofreading the document and various editorial > suggestions. Suggest you drop middle initials. Needs IPR notice. > >13. Full Copyright Statement > > Copyright (C) The Internet Society (2004). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > >Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > >Appendix A. Relation of SASL to transport security > > Questions have been raised about the relationship between SASL and > various services (such as IPsec and TLS) which provide a secured > connection. > > Two of the key features of SASL are: > > The separation of the authorization identity from the identity in > the client's credentials. This 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. > > Upon successful completion of an authentication exchange, the > server knows the authorization identity the client wishes to use. > This allows servers to move to a "user is authenticated" state in > the protocol. > > These features are extremely important to some application protocols, > yet Transport Security services do not always provide them. To > define SASL mechanisms based on these services would be a very messy > task, as the framing of these services would be redundant with the > framing of SASL and some method of providing these important SASL > features would have to be devised. > > Sometimes it is desired to enable within an existing connection the > use of a security service which does not fit the SASL model. (TLS is > an example of such a service.) This can be done by adding a command, > for example "STARTTLS", to the protocol. Such a command is outside > the scope of SASL, and should be different from the command which > starts a SASL authentication protocol exchange. > > In certain situations, it is reasonable to use SASL underneath one of > these Transport Security services. The transport service would > secure the connection, either service would authenticate the client, > and SASL would negotiate the authorization identity. The SASL > negotiation would be what moves the protocol from "unauthenticated" > to "authenticated" state. The "EXTERNAL" SASL mechanism is > explicitly intended to handle the case where the transport service > secures the connection and authenticates the client and SASL > negotiates the authorization identity. > >Appendix B. Changes since RFC 2222 > > The GSSAPI mechanism was removed. It is now specified in a separate > document [SASL-GSSAPI]. > > The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has > been removed. > > The "SKEY" mechanism described in RFC 2222 is obsolete and has been > removed. It has been replaced by the OTP mechanism [SASL-OTP]. > > The overview has been substantially reorganized and clarified. > > Clarified the definition and semantics of the authorization identity. > > Prohibited the NUL character in authorization identities. > > Added a section on character string issues. > > The word "must" in the first paragraph of the "Protocol profile > requirements" section was changed to "MUST". > > Specified that protocol profiles SHOULD provide a way for clients to > discover available SASL mechanisms. > > Made the requirement that protocol profiles specify the semantics of > the authorization identity optional to the protocol profile. > Clarified that such a specification is a refinement of the definition > in the base SASL spec. > > Added a requirement discouraging protocol profiles from breaking the > separation between protocol and mechanism. > > Mentioned that standards track documents may carve out their own > portions of the SASL mechanism namespace and may amend registration > rules for the portion. However registration of individual SASL > mechanisms is still required. > > Specified that the authorization identity in the EXTERNAL mechanism > is encoded in UTF-8. > > Added a statement that a protocol profile SHOULD allow challenge data > to be sent with a success indication. > > Added a security consideration for the EXTERNAL mechanism. > > Clarified sections concerning success with additional data. > > Cleaned up IANA considerations/registrations and assembled them in > one place. > > Updated references and split them into Informative and Normative. > > Added text to the Security Considerations section regarding handling > of extremely large SASL blocks. > > Replaced UTF-8 ABNF with the reference to the UTF-8 document. > > Added text about SASLprep for authentication identities and > passwords. Described where SASLprep preparation should take place. > > Added paragraph about verifying authorization identities. > > Added a protocol profile requirement to specify interaction between > SASL and TLS security layers. > > Added a protocol profile requirement to specify if it supports > reauthentication. > > Removed the text that seemed to suggest that SASL security layer must > not be used when TLS is available. > > Created two subsections in 4.2 to talk separately about proxy > authorization and format of the authorization identities. > > Made requirement to verify that an authorization identity is correct > by performing SASLprep a SHOULD, instead of a MUST. > > Clarified that each SASL mechanism must decide where SASLprep is > taking place. > > Added 4 new examples for initial response and additional data with > success. > > Added text on checking the list of available SASL mechanisms after > negotiating a security layer. > > Added definition of "integrity protection" and "confidentiality > protection". > > Added warning about negotiating no layer once a security layer is > negotiated. > > Added new section with guidelines to a SASL mechanism designer. > > Added a requirement to specify how an empty initial challenge is > encoded if initial response is supported by a protocol. > > > > Status of this Memo .......................................... i > 1. Abstract ............................................... 2 > 2. Organization of this document .......................... 2 > 2.1. How to read this document .............................. 2 > 2.2. Conventions used in this document ...................... 2 > 3. Overview ............................................... 3 > 4. Authentication mechanisms .............................. 3 > 4.1. Authentication protocol exchange ....................... 4 > 4.2. Authorization and authentication identities ............ 4 > 4.2.1. Authorization identities and proxy authentication .... 5 > 4.2.2. Authorization Identity Format ........................ 6 > 4.3. Security layers ........................................ 6 > 4.4. Character string issues ................................ 7 > 5. Protocol profile requirements .......................... 7 > 5. Protocol and mechanism profiles ........................ 7 > 5.1. Protocol profile requirements .......................... 7 > 5.2. Mechanism profile guidelines ........................... 8 > 6. Specific issues ........................................ 9 > 6.1. Client sends data first ................................ 9 > 6.1.1. Examples ............................................. 9 > 6.2. Server returns success with additional data ........... 10 > 6.2.1. Examples ............................................ 10 > 6.3. Multiple authentications .............................. 12 > 6.3.1. Description of Multiple Authentication attack ....... 13 > 7. The EXTERNAL mechanism ................................ 14 > 7.1. Formal syntax ......................................... 15 > 7.2. Example ............................................... 15 > 8. IANA Considerations ................................... 15 > 8.1. Guidelines for IANA ................................... 16 > 8.2. Registration procedure ................................ 16 > 8.3. Comments on SASL mechanism registrations .............. 16 > 8.4. Change control ........................................ 17 > 8.5. Registration template ................................. 17 > 8.6. The EXTERNAL mechanism registration ................... 18 > 9. Security considerations ................................ 18 > 10. References ........................................... 20 > 10.1. Normative References ................................. 20 > 10.2. Informative References ............................... 21 > 11. Editor's Address ...................................... 21 > 12. Acknowledgments ....................................... 22 > 13. Full Copyright Statement .............................. 22 > Appendix A. Relation of SASL to transport security .......... 23 > Appendix B. Changes since RFC 2222 .......................... 24 From owner-ietf-sasl Thu Feb 26 01:03:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q93JnG036081; Thu, 26 Feb 2004 01:03:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q93JWe036079; Thu, 26 Feb 2004 01:03:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q93En8036047 for ; Thu, 26 Feb 2004 01:03:15 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AwHQI-000622-00 for ; Thu, 26 Feb 2004 10:03:14 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu Feb 26 09:03:14 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu Feb 26 09:03:14 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Thu, 26 Feb 2004 10:03:02 +0100 Lines: 47 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:pa8CHJC5cwcYNgNCXITdmEtZdww= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > So, I think your picture is not correct as it implies normalization > is a client side matter. That is not necessarily the case. The server part wasn't part of the picture, and for the client side the picture tried to imply that the normalization may be the identity function ("_Possibly_ revised authorization identity"), so I think we actually agree. >>(I prefer not to >>speculate like this, because it generate long and potentially >>irrelevant e-mails, but was asked to do so to speed up the progress of >>the draft, please bear with me.) >> >>If so, and here comes my question, if two protocol profiles uses >>different normalizations, and a mechanism is implemented by storing a >>hash of H(Username|AuthId|AuthZid) (or it works in some similar way), > > Huh? I assume you meant H(authcid|password|authzid) or something similar. Yes, sorry. > Anyways, it's bogus for the mechanism implementation to do much of > anything with the authzid, except ensuring it is transferred properly, > as its semantics are protocol specific. I think this is not clear -- and many implementations do authorization for you, all suggesting it is a service from the SASL mechanism framework. >>the mechanism appear to need to select among different password >>databases, depending on which protocol is used. > > No, it just should not include the authzid in that database. There > should be, logically, a separate database which proxy authentication > (identity assumption) policy. Note that this database likely keys > off a protocol-specific mapping of the authentication identity. That > is, off the authzid which would have been derived from the authentication > identity if no authzid has been transferred. It should be noted that > this mapping requires both knowledge of the mechanism-specific form > of the authentication identity and the protocol-specific form of the > authorization identities. This view helps. A picture with (conceptually) two databases, one mechanism specific for authentication identities and, and one protocol specific with authorization identities, would help. From owner-ietf-sasl Thu Feb 26 06:35:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QEZvAt067566; Thu, 26 Feb 2004 06:35:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QEZugu067565; Thu, 26 Feb 2004 06:35:56 -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.11/8.12.8) with ESMTP id i1QEZt4X067556 for ; Thu, 26 Feb 2004 06:35:55 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QEZmMu063798; Thu, 26 Feb 2004 14:35:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226055821.04c18980@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 06:35:40 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@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 01:03 AM 2/26/2004, Simon Josefsson wrote: >> Anyways, it's bogus for the mechanism implementation to do much of >> anything with the authzid, except ensuring it is transferred properly, >> as its semantics are protocol specific. > >I think this is not clear -- and many implementations do authorization >for you, all suggesting it is a service from the SASL mechanism >framework. I think RFC 2222 was quite clear that the form of the authorization identity is mechanism specific, and in fact, says its the protocol profiles responsibility to provide: 5. A specification of how the authorization identity passed from the client to the server is to be interpreted. This should be even clearer in the revised specification and, possibly, could be made even more clear. What some so-called SASL developers have done is provide SASL implementations which interpret the authorization identity in a fashion consistent with some set of the protocol profiles, but obviously not all possible (or even all existing) protocol profiles. I question however whether saying more actually will help. The (inherent) fact is that implementors often write with binders on (e.g., with a limited set of mechanisms and protocols in mind) and only realize their false assumptions upon attempts to adapt their work to other mechanisms/protocols. I am not saying such implementations are broken (when used in the set of protocol they were designed to support), just that they are part implementation and part implementation of a set of similar protocol profiles. It should be clear that such implementations are not readily usable in implementations of dissimilar protocol profiles. >>>the mechanism appear to need to select among different password >>>databases, depending on which protocol is used. >> >> No, it just should not include the authzid in that database. There >> should be, logically, a separate database which proxy authentication >> (identity assumption) policy. Note that this database likely keys >> off a protocol-specific mapping of the authentication identity. That >> is, off the authzid which would have been derived from the authentication >> identity if no authzid has been transferred. It should be noted that >> this mapping requires both knowledge of the mechanism-specific form >> of the authentication identity and the protocol-specific form of the >> authorization identities. > >This view helps. A picture with (conceptually) two databases, one >mechanism specific for authentication identities and, and one protocol >specific with authorization identities, would help. Maybe, but then again many readers will get confused by unnecessary elaboration. Saying more (in prose or with pictures) tends to lead to inconsistencies in the specification, which lead to different interpretations, and to interoperability problems. That is, while I don't necessarily oppose new text (and/or new pictures), I generally think the specification would be clearer if it were more concise. Kurt From owner-ietf-sasl Thu Feb 26 07:33:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QFX6FB070684; Thu, 26 Feb 2004 07:33:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QFX68S070683; Thu, 26 Feb 2004 07:33:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1QFX5rw070677 for ; Thu, 26 Feb 2004 07:33:05 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa21736; 26 Feb 2004 10:32 EST Date: Thu, 26 Feb 2004 10:32:53 -0500 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] Message-ID: <155180000.1077809573@mariner.pc.cs.cmu.edu> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, February 25, 2004 17:34:02 -0800 "Kurt D. Zeilenga" wrote: >> This separation between the definition of protocols and the >> definition of authentication mechanisms is crucial. It permits an > > I think it is the separation between (application-level) protocols > and mechanisms, not their definitions, that is crucial. > >> authentication mechanism to be defined once, making it usable by any >> SASL protocol profile. In many implementations, the same SASL >> mechanism code is used for multiple protocols. On the contrary, it is the modularity of definition that's critical. There are plenty of single-mechanism and especially single-application SASL implementations out there. I'd not be the least bit surprised to find application implementations which do their own SASL and support only one mechanism. These folks don't need a modular implementation; they don't care much about having a "SASL framework implementation" that exports one API to applications and another to mechanisms. That's nice for some of us, but not essential in every implementation. What you get from modularity of definition is that you only need N+M+1 specs, instead of N*M. If a someone invents a new mechanism, I don't have to wait for its use to be defined for my favorite application before I can start implementing it (let alone using it). Similarly, if a new application protocol comes along that I want to use, I don't have to lose because my favorite mechanism isn't popular enough for the application designers to bother specifying it. Modularity of definition also makes the security analysis easier. Not only do we collectively only have to analyze N+M+1 documents instead of N*M documents, but the analysis is simpler for each document, especially in the case of the application protocol profiles. IMHO the language is fine as it stands. -- Jeff From owner-ietf-sasl Thu Feb 26 08:20:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QGKAvI074514; Thu, 26 Feb 2004 08:20:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QGK920074513; Thu, 26 Feb 2004 08:20:10 -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.11/8.12.8) with ESMTP id i1QGK909074507 for ; Thu, 26 Feb 2004 08:20:09 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QGKAMs065621; Thu, 26 Feb 2004 16:20:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226081505.04d11fc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 08:20:02 -0800 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: <155180000.1077809573@mariner.pc.cs.cmu.edu> References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <155180000.1077809573@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Without proper separation within the SASL framework, one cannot have proper separation of protocol and mechanism specifications. The overview section should first provide an overview of the SASL framework and the abstractions involved and then state that the intent is to allow separate specification of protocol and mechanisms that framework support. Kurt At 07:32 AM 2/26/2004, Jeffrey Hutzelman wrote: >On Wednesday, February 25, 2004 17:34:02 -0800 "Kurt D. Zeilenga" wrote: > >>> This separation between the definition of protocols and the >>> definition of authentication mechanisms is crucial. It permits an >> >>I think it is the separation between (application-level) protocols >>and mechanisms, not their definitions, that is crucial. >> >>> authentication mechanism to be defined once, making it usable by any >>> SASL protocol profile. In many implementations, the same SASL >>> mechanism code is used for multiple protocols. > >On the contrary, it is the modularity of definition that's critical. >There are plenty of single-mechanism and especially single-application SASL implementations out there. I'd not be the least bit surprised to find application implementations which do their own SASL and support only one mechanism. These folks don't need a modular implementation; they don't care much about having a "SASL framework implementation" that exports one API to applications and another to mechanisms. That's nice for some of us, but not essential in every implementation. > >What you get from modularity of definition is that you only need N+M+1 specs, instead of N*M. If a someone invents a new mechanism, I don't have to wait for its use to be defined for my favorite application before I can start implementing it (let alone using it). Similarly, if a new application protocol comes along that I want to use, I don't have to lose because my favorite mechanism isn't popular enough for the application designers to bother specifying it. > >Modularity of definition also makes the security analysis easier. Not only do we collectively only have to analyze N+M+1 documents instead of N*M documents, but the analysis is simpler for each document, especially in the case of the application protocol profiles. > > >IMHO the language is fine as it stands. > >-- Jeff > From owner-ietf-sasl Thu Feb 26 11:07:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QJ71Fc083335; Thu, 26 Feb 2004 11:07:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QJ71PA083334; Thu, 26 Feb 2004 11:07:01 -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 (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QJ70tm083328 for ; Thu, 26 Feb 2004 11:07:01 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1EEE215200A; Thu, 26 Feb 2004 14:07:03 -0500 (EST) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis: multiple authentication attack References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> From: Sam Hartman Date: Thu, 26 Feb 2004 14:07:03 -0500 In-Reply-To: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 25 Feb 2004 15:08:30 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> In review of the latest draft, I've come across a number of Kurt> technical and editorial concerns which I intend to start a Kurt> number of separate threads on. This is the first. Kurt> I am particularity perplexed by the long discussion of the Kurt> "Multiple Authentication attack", an attack which only Kurt> impacts certain kinds of distributed server implementations, Kurt> which seems to overshadow higher risk, more generally Kurt> applicable attacks. I am quite concerned about the addition Kurt> of: >> The protocol profiles that allow for reauthentication SHOULD >> recommend that another security layer is negotiated once a >> security layer was installed. I actually think this text may be reasonable, but would need to think about it more. I think the assumption is that by setting up a new security layer you will end up getting new key material and thus will prevent the new server from decrypting data destined for the old server. --Sam From owner-ietf-sasl Thu Feb 26 12:08:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QK8K2f087746; Thu, 26 Feb 2004 12:08:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QK8KR8087745; Thu, 26 Feb 2004 12:08:20 -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.11/8.12.8) with ESMTP id i1QK8J8J087737 for ; Thu, 26 Feb 2004 12:08:19 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QK8NMs069057; Thu, 26 Feb 2004 20:08:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 12:08:15 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis: multiple authentication attack Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225140730.04ba6788@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 11:07 AM 2/26/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> In review of the latest draft, I've come across a number of > Kurt> technical and editorial concerns which I intend to start a > Kurt> number of separate threads on. This is the first. > > Kurt> I am particularity perplexed by the long discussion of the > Kurt> "Multiple Authentication attack", an attack which only > Kurt> impacts certain kinds of distributed server implementations, > Kurt> which seems to overshadow higher risk, more generally > Kurt> applicable attacks. I am quite concerned about the addition > Kurt> of: > >> The protocol profiles that allow for reauthentication SHOULD > >> recommend that another security layer is negotiated once a > >> security layer was installed. > > >I actually think this text may be reasonable, but would need to think >about it more. Maybe we should have a hallway discussion at IETF#59 before our session. Sunday afternoon is good for me. >I think the assumption is that by setting up a new security layer you >will end up getting new key material and thus will prevent the new >server from decrypting data destined for the old server. I don't disagree that negotiating new layers mitigated, to some degree, this attack. (I note however that this alone does not fully mitigate this class of attack.) But note that the text doesn't state a recommendation to negotiate new layers, it a statement that documents detailing a protocol's use of SASL SHOULD state a recommendation. My suggestion is to, in the security consideration section of this document, to discuss a class of similar attacks upon a class of server implementations, and then to suggest approaches which may be used in these implementations to mitigated these attacks. I, however, remain opposed to addition any implementation or specification imperative that would require/recommend all server implementations (of all protocols, or select protocol), including those which are not prone to this attack, to have to negotiate new security layers. Kurt From owner-ietf-sasl Thu Feb 26 12:18:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKINWr088392; Thu, 26 Feb 2004 12:18:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QKINuQ088391; Thu, 26 Feb 2004 12:18: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 (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKIMWA088381 for ; Thu, 26 Feb 2004 12:18:22 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A369415200A; Thu, 26 Feb 2004 15:18:26 -0500 (EST) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis: multiple authentication attack References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> From: Sam Hartman Date: Thu, 26 Feb 2004 15:18:26 -0500 In-Reply-To: <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> (Kurt D. Zeilenga's message of "Thu, 26 Feb 2004 12:08:15 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> My suggestion is to, in the security consideration section Kurt> of this document, to discuss a class of similar attacks upon Kurt> a class of server implementations, and then to suggest Kurt> approaches which may be used in these implementations to Kurt> mitigated these attacks. Sounds reasonable to me. Kurt> I, however, remain opposed to addition any implementation or Kurt> specification imperative that would require/recommend all Kurt> server implementations (of all protocols, or select Kurt> protocol), including those which are not prone to this Kurt> attack, to have to negotiate new security layers. Also reasonable. So apparently we don't disagree after all. From owner-ietf-sasl Thu Feb 26 12:44:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKiq5U089714; Thu, 26 Feb 2004 12:44:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QKiqb4089713; Thu, 26 Feb 2004 12:44:52 -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.11/8.12.8) with ESMTP id i1QKim0R089704 for ; Thu, 26 Feb 2004 12:44:51 -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 i1QKiqFK023082; Thu, 26 Feb 2004 15:44:52 -0500 Date: Thu, 26 Feb 2004 15:44:52 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> Message-ID: References: <6.0.1.1.0.20040225173049.04ce5210@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 Wed, 25 Feb 2004, Kurt D. Zeilenga wrote: > > Here are my review notes.... > Wow. Thats quite extensive. Comments on a few of your comments.. > > The sections "Overview", "Authentication Mechanisms", "Mechanism > > Profile Requirements" and "Security Considerations" cover issues that > > mechanism designers need to understand and address in designing new > > SASL mechanisms. > > > > Implementors of a protocol using this specification need the > > protocol-specific profiling information in addition to the > > information in this document. > > This implies implementors need to understand all of this document. > They should not need to read the protocol and mechanism profiling > requirements. Isn't the implication here that implemetors should be aware that there are generally at least three documents they need to read to implement any SASL profile? That is, the mechanism, the protocol profile, and the "framework" (this document). They most certainly do need to read the protcol and mechanism profiling requirements in order to have a successful implementation. > > The server SHOULD verify that a received authorization identity is in > > the correct form. > > Why isn't this a MUST? That is, how are servers to compare or > otherwise handle authorization identities which are not in correct > form? I suspect this is to allow older implementiations to remain compliant. However, I'm not sure that we're doing that at this point anyway... > > 7) If both TLS and SASL security layer are allowed to be negotiated > > by the protocol, the protocol profile MUST define in which order they > > are applied to a cleartext data sent over the connection. > > Spell TLS out on first use. We should extend this to also cover things other than just TLS (e.g. a compression layer, separate from either TLS or SASL). For example: If other transport or session layers (such as a Transport Layer Security layer or a compression layer) in addition to the SASL security layer are allowed to be negotiated by the protocol.... -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Feb 26 13:17:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLHWwr091419; Thu, 26 Feb 2004 13:17:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLHWYC091418; Thu, 26 Feb 2004 13:17: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.11/8.12.8) with ESMTP id i1QLHVbH091412 for ; Thu, 26 Feb 2004 13:17:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QLHaMs070296; Thu, 26 Feb 2004 21:17:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226130013.04e0a350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 13:17:28 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: use of the word "profile" (Was: sasl-rfc2222bis: multiple authentication attack) Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> <6.0.1.1.0.20040226112948.04dd4578@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 12:18 PM 2/26/2004, Sam Hartman wrote: >So apparently we don't disagree after all. Apparently. From this discussion, as well as other recent discussions, it seems that there might be some disagreement as to the meaning of the word "profile". I tend to use the term "protocol profile" to either refer to, in the SASL context, as: The set of items that an specification detailing a protocol use of SASL must provide. or: A protocol specification which provides these items. The following would be a use of the former: RFC 2222 provides a profile (e.g., an outline) of what an protocol specifications making use of SASL are to contain. and for the latter: RFC 2829 provides a profile of how SASL is used in LDAP. (that latter is, it seems, not perfect). I, however, try to avoid the term "profile implementation" as it's ambiguous as to whether it is are referring to the specification, such as RFC 2829, which provides the profile or an implementation of that specification. Of course, as we also are providing in this I-D a requirements for documents specifying mechanisms, the term becomes even more overloaded... Kurt From owner-ietf-sasl Thu Feb 26 13:28:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLSIHn091859; Thu, 26 Feb 2004 13:28:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLSIRq091858; Thu, 26 Feb 2004 13:28:18 -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.11/8.12.8) with ESMTP id i1QLSHRT091852 for ; Thu, 26 Feb 2004 13:28:17 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QLSKMs070440; Thu, 26 Feb 2004 21:28:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226131906.04df6c68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 13:28:12 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225173049.04ce5210@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 12:44 PM 2/26/2004, Rob Siemborski wrote: >> > The sections "Overview", "Authentication Mechanisms", "Mechanism >> > Profile Requirements" and "Security Considerations" cover issues that >> > mechanism designers need to understand and address in designing new >> > SASL mechanisms. >> > >> > Implementors of a protocol using this specification need the >> > protocol-specific profiling information in addition to the >> > information in this document. >> >> This implies implementors need to understand all of this document. >> They should not need to read the protocol and mechanism profiling >> requirements. > >Isn't the implication here that implemetors should be aware that there are >generally at least three documents they need to read to implement any SASL >profile? That is, the mechanism, the protocol profile, and the >"framework" (this document). Well, the statement implies that an implementor of a protocol needs understand what requirements placed upon ALL protocol specifications and upon ALL mechanism specifications, not just those requirements placed upon the implementor of the specifications which he is implementing. >They most certainly do need to read the protcol and mechanism profiling >requirements in order to have a successful implementation. An implementor of a specification should not need to read nor understand requirements which were intended for authors of that specifications. Kurt From owner-ietf-sasl Thu Feb 26 13:39:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLds7w092311; Thu, 26 Feb 2004 13:39:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLdsfH092310; Thu, 26 Feb 2004 13:39:54 -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.11/8.12.8) with ESMTP id i1QLdrs9092304 for ; Thu, 26 Feb 2004 13:39:53 -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 i1QLdvFK023217; Thu, 26 Feb 2004 16:39:57 -0500 Date: Thu, 26 Feb 2004 16:39:57 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] In-Reply-To: <6.0.1.1.0.20040226131906.04df6c68@127.0.0.1> Message-ID: References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <6.0.1.1.0.20040226131906.04df6c68@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, 26 Feb 2004, Kurt D. Zeilenga wrote: > >>> Implementors of a protocol using this specification need the > >>> protocol-specific profiling information in addition to the > >>> information in this document. > > > >> This implies implementors need to understand all of this document. > >> They should not need to read the protocol and mechanism profiling > >> requirements. > > > >Isn't the implication here that implemetors should be aware that there are > >generally at least three documents they need to read to implement any SASL > >profile? That is, the mechanism, the protocol profile, and the > >"framework" (this document). > > Well, the statement implies that an implementor of a protocol needs understand > what requirements placed upon ALL protocol specifications and upon ALL > mechanism specifications, not just those requirements placed upon the > implementor of the specifications which he is implementing. Wow, I think my brain just tied itself in a knot. However, let me try to restate what you said to be sure I understand: "Implementors [who write code] don't need to understand all of 2222bis" Which I'll agree with, but I'd argue that the key part of the paragraph in question is the "you need to read other documents" bit, not the "you need *all* of this document" bit -- which is not how I read the paragraph. > >They most certainly do need to read the protcol and mechanism profiling > >requirements in order to have a successful implementation. > > An implementor of a specification should not need to read nor understand > requirements which were intended for authors of that specifications. I'll agree with this, but I do not believe that is what the statement in the document is saying. Perhaps rewrite the paragraph as something closer to: Implementors of a protocol using this specification will also need a specification of a profile specific the protocol. -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Feb 26 14:21:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QMLGMK094261; Thu, 26 Feb 2004 14:21:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QMLGQP094260; Thu, 26 Feb 2004 14:21:16 -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.11/8.12.8) with ESMTP id i1QMLFFk094254 for ; Thu, 26 Feb 2004 14:21:15 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QMLJMs071040; Thu, 26 Feb 2004 22:21:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226140018.04df3500@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 14:21:11 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <6.0.1.1.0.20040226131906.04df6c68@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 01:39 PM 2/26/2004, Rob Siemborski wrote: >Implementors of a protocol using this specification will also need >a specification of a profile specific the protocol. This is somewhat better. My previous concern was with the "all of this document" part of the current statement. For the other audiences, the section is quite specific as to what portions of this document they need to read. I think we should detail what each audience should read with equal specificity. I have no objection to saying, in addition to portions of this document, they need to read the specification of the protocol they are implementing, especially those portions of that specification which fulfill the requirements placed upon that specification by this document. I note as well that it might be appropriate to note that implementors need to read and understand aspects of mechanism specifications they intend to use (regardless of whether they are implementing the mechanisms themselves or using an existing implementation) to understand, for instance, the mechanism specific authentication identity forms, the offered services, and security and other considerations. Kurt From owner-ietf-sasl Sat Feb 28 21:57:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5vogm030903; Sat, 28 Feb 2004 21:57:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1T5vore030902; Sat, 28 Feb 2004 21:57:50 -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 (MAC-0-20-e0-89-cc-d2.dhcp.ietf59.or.kr [218.37.231.156]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5vksd030878 for ; Sat, 28 Feb 2004 21:57:46 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 36CB815159C; Sun, 29 Feb 2004 00:57:51 -0500 (EST) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: SASLprep in rfc2222bis-06 References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> From: Sam Hartman Date: Sat, 28 Feb 2004 03:23:04 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 25 Feb 2004 18:16:15 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Simon" == Simon Josefsson writes: Simon> "Kurt D. Zeilenga" writes: >>> First, does 'character strings' include the authorization >>> identity? Defining the term 'character string', or at least >>> giving examples, would help. >> No. I believe the text should be clarified. Mechanisms >> should be capable of exchanging the authorization identity, but >> its handling (in particular for comparison) is specific to the >> application-level protocol which has profiled use of SASL as an >> authentication method. The authorization identity is a string; this is certainly true in 2222bis, and I believe was true in RFC 2222. I agree that the comparison and normalization of this string should be an application or protocol profile matter. It seems to me that we need to decide what the encoding of the authorization identity is either in the protocol profile or the mechanism specification. The base spec does need to be clarified to say which of these two is responsible for defining the encoding of the authorization ID. I also find that the digest-md5 spec is unclear on whether the authorization ID is UTF8 or is in some unspecified character set. Perhaps we believe that specification belongs to the protocol profile; if so we should be more explicit. Absent a good reason to do otherwise, I'd prefer that the mechanism specification define the encoding of the authorization ID. After all the mechanism must transport it. From owner-ietf-sasl Sun Feb 29 15:52:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq3Wj058266; Sun, 29 Feb 2004 15:52:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq3gt058265; Sun, 29 Feb 2004 15:52:03 -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.11/8.12.8) with ESMTP id i1TNq03m058244 for ; Sun, 29 Feb 2004 15:52:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:52:02 +0000 Message-ID: <4042462A.6070806@isode.com> Date: Mon, 01 Mar 2004 05:06:02 +0900 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: New text is authentication/authorization id description (section 4.2) 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: After the last round of discussions the section 4.2 looks like this: 4.2. Authorization and authentication identities SASL authentication deals with two identities: the authentication identity, derived from the client's authentication credentials; and the authorization identity, which is used by the server as the primary identity for making access policy decisions. The authorization identity may be an empty (zero length) string. In this case, the server derives an authorization identity from the client's authentication identity. A mechanism which is incapable of transmitting an authorization identity must be treated as if it always transmits an authorization identity of an empty string. Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Any normalization of the authorization identity is defined within each SASL protocol profile, and occurs before the authorization identity is handed to the mechanism. The mechanism may not modify (by, e.g., normalization) the authorization identity. Alexey From owner-ietf-sasl Sun Feb 29 15:52:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq4LI058281; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq4CT058275; Sun, 29 Feb 2004 15:52:04 -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.11/8.12.8) with ESMTP id i1TNq03l058244 for ; Sun, 29 Feb 2004 15:52:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:52 +0000 Message-ID: <4042445A.7080506@isode.com> Date: Mon, 01 Mar 2004 04:58:18 +0900 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: Authentication/authorization id clarification (was Re: sasl-rfc2222bis review notes [long]) References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@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: >>4.2. Authorization and authentication identities >> >> SASL authentication deals with two identities: the authorization >> identity and the authentication identity. >> >> > >I suggest the "authorization identity" and "authentication identity" >be defined here (move the below def'ns to here). I suggest defining >"authentication identity" first. Doing so, I also suggest swapping >the order of the terms in the section title and first sentence. > > Other people already suggested this and I've made the change (will post a separate message to the list). >> The transmitted >> authorization identity may be an empty string (zero length), but the >> transmitted authentication identity may not be an empty string. >> >> > >I think the latter ("but ...") part should be deleted. Nothing >says a mechanism has a "transmitted authentication identity", and >nothing (in RFC 2222) prevented a mechanism from transmitting an >empty authentication identity. Whether or not such is permissible >should be left to the mechanisms to decide. In fact, whether or >not an authentication identity is explicitly transferred between >the SASL client and server should be left the mechanism. It may >simply be implied by the client's credentials (as noted below). > I agree. >> A mechanisms which are incapable of transmitting an authorization >> identity must be treated as if it always transmits an authorization >> identity of an empty string. >> >> Authentication identity is the identity derived from the client's >> authentication credentials. >> >> The authorization identity is used by the server as the primary >> identity for making access policy decisions. >> >> >> ... >> Profiles whose authorization identities are simple >> user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile >> [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare >> these names for matching. The profiles MAY use a stringprep profile >> that is more strict than "SASLprep". 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. >> >> > >"profile" should be qualified above to refer to the protocol profile. > Done. >I think it mostly states a protocol profile requirement. But then >it includes an implementation imperative. But this is odd in that >server may not actually be required to do any preparation (the >profile might place that burden on the client). > Authorization identity is always sent from the client to the server. So the verification is always happening on the server. > > >I think the "If the preparation..." part should be reworded as >a profile requirement. That is, it should state that profiles >should detail how implementations are to behave when required >preparation fails. > >Given that, I think this can and should be moved to Section 5. > > > Alexey From owner-ietf-sasl Sun Feb 29 15:52:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq52T058284; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq5J5058283; Sun, 29 Feb 2004 15:52: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.11/8.12.8) with ESMTP id i1TNq0bL058245 for ; Sun, 29 Feb 2004 15:52:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:47 +0000 Message-ID: <40423F33.8020708@isode.com> Date: Mon, 01 Mar 2004 04:36:19 +0900 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: Simon Josefsson CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: SASLprep in rfc2222bis-06 References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225140352.04ba6fb8@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: Simon Josefsson wrote: > ... > >I think the most important modification that should be done is to >stress the relationship "authorization identity"<->"protocol profile" >and "authentication identity"<-> "mechanism". This isn't clear now, >but helps with the conceptual understanding. I wasn't aware of this >distinction after reading RFC 2222, so it appears to be something new >in 2222bis. Perhaps adding the sentences as below could help, if they >are correct (I'm not sure, correct me if not). > >Regards, >Simon > >4.2. Authorization and authentication identities > > 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. > > A mechanisms which are incapable of transmitting an authorization > identity must be treated as if it always transmits an authorization > identity of an empty string. > > Authentication identity is the identity derived from the client's > authentication credentials. Any normalization of the > authentication identity is defined by each mechanism, the profile > does not influence it. > > The authorization identity is used by the server as the primary > identity for making access policy decisions. Any normalization of > the authorization identity is defined within each SASL protocol > profile, and occur before the authorization identity is handed to > the mechanism. The mechanism may not modify (by, e.g., > normalization) the authorization identity. > I've integrated the suggested text about normalization. Alexey From owner-ietf-sasl Sun Feb 29 15:53:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNrIwH058340; Sun, 29 Feb 2004 15:53:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNrIst058338; Sun, 29 Feb 2004 15:53:18 -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.11/8.12.8) with ESMTP id i1TNq0bM058245 for ; Sun, 29 Feb 2004 15:52:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:57 +0000 Message-ID: <404245EB.6070806@isode.com> Date: Mon, 01 Mar 2004 05:04:59 +0900 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" , ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] References: <6.0.1.1.0.20040225173049.04ce5210@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: >>> The sections "Overview", "Authentication Mechanisms", "Mechanism >>> Profile Requirements" and "Security Considerations" cover issues that >>> mechanism designers need to understand and address in designing new >>> SASL mechanisms. >>> >>> Implementors of a protocol using this specification need the >>> protocol-specific profiling information in addition to the >>> information in this document. >>> >>> >>This implies implementors need to understand all of this document. >>They should not need to read the protocol and mechanism profiling >>requirements. >> >> > >Isn't the implication here that implementors should be aware that there are >generally at least three documents they need to read to implement any SASL >profile? That is, the mechanism, the protocol profile, and the >"framework" (this document). > >They most certainly do need to read the protocol and mechanism profiling >requirements in order to have a successful implementation. > I agree with Rob. >>> The server SHOULD verify that a received authorization identity is in >>> the correct form. >>> >>> >>Why isn't this a MUST? That is, how are servers to compare or >>otherwise handle authorization identities which are not in correct >>form? >> >> > >I suspect this is to allow older implementations to remain compliant. >However, I'm not sure that we're doing that at this point anyway... > Correct. If we change this to MUST, we effectively will make all existing implementations non-compliant. >>> 7) If both TLS and SASL security layer are allowed to be negotiated >>> by the protocol, the protocol profile MUST define in which order they >>> are applied to a cleartext data sent over the connection. >>> >>> >>Spell TLS out on first use. >> >> > >We should extend this to also cover things other than just TLS (e.g. a >compression layer, separate from either TLS or SASL). > >For example: > >If other transport or session layers (such as a Transport Layer Security >layer or a compression layer) in addition to the SASL security layer are >allowed to be negotiated by the protocol.... > I don't think a protocol profile can reasonably define layering of multiple things when at least one of them is not known when the protocol profile is written. So I would rather not change the description. Alexey From owner-ietf-sasl Sun Feb 29 15:52:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq55m058282; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq4Mp058276; Sun, 29 Feb 2004 15:52:04 -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.11/8.12.8) with ESMTP id i1TNq0bN058245 for ; Sun, 29 Feb 2004 15:52:03 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:52:07 +0000 Message-ID: <40424814.9050703@isode.com> Date: Mon, 01 Mar 2004 05:14:12 +0900 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: sasl-rfc2222bis review notes [long] References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@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: >>3. Overview >> > >I suggest this section be moved to immediately follow the Abstract >and be retitled "Introduction". I then suggest the section 2 >subsections be incorporated into this section. > How about the following instead: Subsection 2.2. ("Conventions used in this document") becomes section 2 [note, I will remove numbering of Abstract later on]. Subsection 2.1 ("How to read this document") is merged with section 3 and will become Introduction as suggested. ... >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, the contents of which are specific to and >> defined by the mechanism. To the protocol, the challenges and >> responses are opaque binary tokens of arbitrary length. The >> protocol's profile then specifies how these binary tokens are then >> encoded for transfer over the connection. >> >> >I suggest replacing binary tokens with octet string because: > 1) the challedge and responses must be aligned on 8-bit boundries and > 2) what (in IP) isn't binary? > 3) the challedge and responses seem not to be "tokens". > Kurt, I think we are going in circles now. If I am not mistaken, we've already used the tern octet string before (and I did like the fuzzy term "blob"). Alexey From owner-ietf-sasl Sun Feb 29 21:52:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215qXig090541; Sun, 29 Feb 2004 21:52:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i215qXS6090540; Sun, 29 Feb 2004 21:52:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215qWol090534 for ; Sun, 29 Feb 2004 21:52:32 -0800 (PST) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i215qY95021957; Sun, 29 Feb 2004 21:52:39 -0800 Received: from MAC-0-5-4e-40-cf-b0.dhcp.ietf59.or.kr (MAC-0-5-4e-40-cf-b0.dhcp.ietf59.or.kr [218.37.227.67]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i215qUWB026713 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 29 Feb 2004 21:52:33 -0800 Date: Sun, 29 Feb 2004 21:52:23 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Alexey Melnikov cc: SASL WG Subject: Re: New text is authentication/authorization id description (section 4.2) In-Reply-To: <4042462A.6070806@isode.com> Message-ID: References: <4042462A.6070806@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 Mon, 1 Mar 2004, Alexey Melnikov wrote: > After the last round of discussions the section 4.2 looks like this: Let me suggest a restructuring of this text (and some of 4.2.1 too). My main point is to remove the concept of "authentication identity" (which has been added in this revision, it doesn't appear in 2222). A secondary point is to clarify the difference between the authorization identity string sent by the client and the authorization identity derived by the server. My justification for removing "authentication identity" is that its existence is a speculative intermediate step between two concrete elements, which are the authentication credential, and the derived authorization id. Moreover, calling it an "identity" is inevitably confusing with "authorization identity" (and this stuff has already proven to be very confusing). So I'd revise this section as below. This revision also incorporates the "empty string" text that is now in 4.2.1, and would be removed from that section. (I have problems with the last two proposed paragraphs, re normalization, but I'll address those separately.) (And the use of "authentication identity" in 4.2.1 would have to be removed too.) - RL "Bob" --- 4.2. Authorization and authentication The SASL framework supports flexible mapping between authentication and authorization by defining the concept of "authorization identity" as the result of SASL processing. The processing model is as follows. A server, upon completion of the authentication mechanism, uses the results produced by the authentication mechanism, the client-provided authorization identity value (which may be the empty string), and local policy information to derive an authorization identity. The authorization identity is made available to further server processing for use in making access policy decisions. The provision of additional client attributes that may affect access policy is not covered by this specification. Note that the derivation of the authorization identity is often trivial: simply using the identifier produced by the authentication mechanism directly as the authorization identity. 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. A mechanism which is incapable of transmitting an authorization identity must be treated as if it always transmits an authorization identity of an empty string. From owner-ietf-sasl Wed Feb 11 08:17:06 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGH5v3068605; Wed, 11 Feb 2004 08:17:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BGH5HQ068604; Wed, 11 Feb 2004 08:17: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.11/8.12.8) with ESMTP id i1BGGxDd068523 for ; Wed, 11 Feb 2004 08:17: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; Wed, 11 Feb 2004 16:17:09 +0000 Message-ID: <402A5584.5080705@isode.com> Date: Wed, 11 Feb 2004 16:17:08 +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: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) 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: I've recently submitted draft-ietf-sasl-rfc2222bis-05 which addressed most of the editorial issues raised by Kurt Zeilenga. I am planning to submit a new revision before the submission deadline. Question: Kurt raised a question about removing the following paragraph from the Security Considerations section. Sam has agreed with Kurt. (This text is not something specific to SASL. After discussing this issue in relationship to XMPP, I thought that it would be a nice idea to add it) SASL implementations might be subject to online dictionary attacks (e.g. username harvesting, password guessing). In order to mitigate the attacks a server implementation is encouraged to implement a policy when after a number of failed authentication attempts it returns errors to all subsequent authentication attempts on the same connection. Alternatively, the server may implement a policy whereby the connection is dropped after a number of failed authentication attempts. If a server implementation chooses to do so, it should not drop the connection until at least 3 authentication attempts have failed. Before I do any changes I would like to hear at least 2 more voices in favor of keeping or removing this paragraph. The changes between 05 and 06 are outlined below: 1). New section 5.2 was introduced that list guidelines for a SASL mechanism designer. 5.2. Mechanism profile guidelines Designers of new SASL mechanism should be aware of the following issues: 1) Authorization identity. While some legacy mechanisms are incapable of transmitting an authorization identity (which means that for these mechanisms the authorization identity is always the empty string), newly defined mechanisms SHOULD be capable of transmitting a non-empty authorization identity. See also section 4.2. 2) Character string issues Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). In order to avoid interoperability problems due to differing normalizations, when a mechanisms specifies that character data is to be used as input to a cryptographic and/or comparison function, the mechanism specification MUST detail how the data is to be represented, including any normalizations or other preparations, to ensure proper function. Designers of mechanisms SHOULD use the "SASLprep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep] where applicable. The preparation can be potentially performed on the client end (upon getting user input or retrieving a value from configuration) or on the server end (upon receiving the value from the client, retrieving a value from its authentication database or generating a new value in order to store in in the authentication database). SASL mechanisms must define which entity (or entities) must perform the preparation. If preparation fails or results in an empty string, the entity doing the preparation SHALL fail the authentication exchange. Implementation note: A server end can be represented by multiple processes. For example, it may consist of the server process itself that communicated with a client, and a command line utility (a server agent) that is able to store passwords/hashes in a database that can be later used by the server. For the server agent the requirement to "fail the authentication exchange" should be interpreted as a requirement to refuse to store the data in the database. 2). I've added a SASL profile requirement that tells that if the protocol supports an initial response, it must specify how an empty initial response is encoded. This was prompted by a recent discussion on XMPP mailing list. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Wed Feb 11 08:50:16 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGoGAW070982; Wed, 11 Feb 2004 08:50:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BGoGAi070981; Wed, 11 Feb 2004 08:50:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hades.jabber.org (hades.all-your-IM-are-belong-to-us.jabber.org [208.245.212.109] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGoEOO070973 for ; Wed, 11 Feb 2004 08:50:14 -0800 (PST) (envelope-from stpeter@jabber.org) Received: by hades.jabber.org (Postfix, from userid 1005) id EBF0D63FCA; Wed, 11 Feb 2004 10:50:27 -0600 (CST) Date: Wed, 11 Feb 2004 10:50:27 -0600 From: Peter Saint-Andre To: Alexey Melnikov Cc: SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) Message-ID: <20040211165027.GL20400@jabber.org> References: <402A5584.5080705@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402A5584.5080705@isode.com> User-Agent: Mutt/1.5.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Feb 11, 2004 at 04:17:08PM +0000, Alexey Melnikov wrote: > > Kurt raised a question about removing the following paragraph from the > Security Considerations section. Sam has agreed with Kurt. > (This text is not something specific to SASL. After discussing this > issue in relationship to XMPP, I thought that it would be a nice idea to > add it) > > SASL implementations might be subject to online dictionary attacks > (e.g. username harvesting, password guessing). In order to mitigate > the attacks a server implementation is encouraged to implement a > policy when after a number of failed authentication attempts it > returns errors to all subsequent authentication attempts on the same > connection. Alternatively, the server may implement a policy whereby > the connection is dropped after a number of failed authentication > attempts. If a server implementation chooses to do so, it should not > drop the connection until at least 3 authentication attempts have > failed. > > Before I do any changes I would like to hear at least 2 more voices in > favor of keeping or removing this paragraph. Hi Alexey, This seems like an issue that should be addressed by the using protocol (e.g., the XMPP specs should say something about this), not something that should be addressed by SASL. So I agree with Kurt and Sam. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php From owner-ietf-sasl Wed Feb 11 09:36:05 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BHa48F074439; Wed, 11 Feb 2004 09:36:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BHa4r6074438; Wed, 11 Feb 2004 09:36:04 -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.11/8.12.8) with ESMTP id i1BHZwL0074429 for ; Wed, 11 Feb 2004 09:35:59 -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 i1BHaCtH015031; Wed, 11 Feb 2004 12:36:12 -0500 Date: Wed, 11 Feb 2004 12:36:11 -0500 (EST) From: Rob Siemborski To: Peter Saint-Andre cc: Alexey Melnikov , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) In-Reply-To: <20040211165027.GL20400@jabber.org> Message-ID: References: <402A5584.5080705@isode.com> <20040211165027.GL20400@jabber.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: On Wed, 11 Feb 2004, Peter Saint-Andre wrote: > Hi Alexey, > > This seems like an issue that should be addressed by the using protocol > (e.g., the XMPP specs should say something about this), not something > that should be addressed by SASL. So I agree with Kurt and Sam. > > Peter I also agree -- this isn't something specific to sasl, it is more applicable to the application's specific authentication policy. -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Feb 11 09:44:43 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BHihRb075191; Wed, 11 Feb 2004 09:44:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BHihEB075190; Wed, 11 Feb 2004 09:44:43 -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.11/8.12.8) with ESMTP id i1BHig8j075184 for ; Wed, 11 Feb 2004 09:44:42 -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, 11 Feb 2004 17:44:53 +0000 Message-ID: <402A6A13.3060309@isode.com> Date: Wed, 11 Feb 2004 17:44: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: Rob Siemborski CC: Peter Saint-Andre , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) References: <402A5584.5080705@isode.com> <20040211165027.GL20400@jabber.org> 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 Wed, 11 Feb 2004, Peter Saint-Andre wrote: > > >>Hi Alexey, >> >>This seems like an issue that should be addressed by the using protocol >>(e.g., the XMPP specs should say something about this), not something >>that should be addressed by SASL. So I agree with Kurt and Sam. >> >>Peter >> >> > >I also agree -- this isn't something specific to sasl, it is more >applicable to the application's specific authentication policy. > Ok, we have 4 votes. Seems like a consensus. I will remove this. Alexey From owner-ietf-sasl Wed Feb 11 10:45:01 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BIj1PZ080759; Wed, 11 Feb 2004 10:45:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BIj02O080758; Wed, 11 Feb 2004 10:45:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1BIithG080741 for ; Wed, 11 Feb 2004 10:44:55 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa07940; 11 Feb 2004 13:44 EST Date: Wed, 11 Feb 2004 13:44:41 -0500 From: Jeffrey Hutzelman To: Alexey Melnikov , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) Message-ID: <3616130000.1076525081@minbar.fac.cs.cmu.edu> In-Reply-To: <402A5584.5080705@isode.com> References: <402A5584.5080705@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, February 11, 2004 16:17:08 +0000 Alexey Melnikov wrote: > Kurt raised a question about removing the following paragraph from the > Security Considerations section. Sam has agreed with Kurt. (This text is > not something specific to SASL. After discussing this issue in > relationship to XMPP, I thought that it would be a nice idea to add it) > > SASL implementations might be subject to online dictionary attacks > (e.g. username harvesting, password guessing). In order to mitigate > the attacks a server implementation is encouraged to implement a > policy when after a number of failed authentication attempts it > returns errors to all subsequent authentication attempts on the same > connection. Alternatively, the server may implement a policy whereby > the connection is dropped after a number of failed authentication > attempts. If a server implementation chooses to do so, it should not > drop the connection until at least 3 authentication attempts have > failed. > > Before I do any changes I would like to hear at least 2 more voices in > favor of keeping or removing this paragraph. I'll have to agree with others here. Particularly, since SASL negotiation is acheived via an exchange of data which it is the application protocol's responsibility to transport in an application-specific manner, the SASL implementation is in no position to detect whether two exchanges occur "on the same connection", let alone drop a connection. This is clearly an issue for the application protocol and for site policy. -- Jeff From owner-ietf-sasl Mon Feb 23 15:31:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NNVoFN029463; Mon, 23 Feb 2004 15:31:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NNVoPQ029461; Mon, 23 Feb 2004 15:31:50 -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.11/8.12.8) with ESMTP id i1NNVnmr029453 for ; Mon, 23 Feb 2004 15:31:50 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1NNVtMs018876 for ; Mon, 23 Feb 2004 23:31:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040223152755.04b77618@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 23 Feb 2004 15:31:51 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASL WG session agenda for IETF#59 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 WG (SASL) TUESDAY, March 2 at 1700-1800 ============================= CHAIRS: Sam Hartman Kurt Zeilenga AGENDA: 0) Preliminaries (Blue Sheets, Scribes) - Chairs - 1m 1) WG Status Summary - Chairs - 5m 2) SASL base specification open issues - 25m - Alexey draft-ietf-sasl-rfc2222bis-xx.txt 3) Other open issues - 15m - Editors draft-ietf-sasl-*-xx.txt 4) Milestone review - Chairs - 5m 5) Open mic - Floor - remaining time From owner-ietf-sasl Mon Feb 23 16:43:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1O0hsbL033551; Mon, 23 Feb 2004 16:43:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1O0hsqi033550; Mon, 23 Feb 2004 16:43:54 -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.11/8.12.8) with ESMTP id i1O0hoAd033542 for ; Mon, 23 Feb 2004 16:43:51 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1O0hlMs019871; Tue, 24 Feb 2004 00:43:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 23 Feb 2004 16:43:43 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@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:04 AM 2/17/2004, Simon Josefsson wrote: >Hello all. I've read the latest document, and in general it looks >good (I've sent a couple of editorial changes to Alexey). However, I >find the SASLprep discussions not as clear. > >I tried to separate my issues into several e-mail, but eventually I >was unable to do so. The issues are closely intertwined, and >resolving one question modify the assumptions for other questions. So >forgive this longish e-mail. I have tried to separate the focus; >first to matters that affect mechanism specifications, then profile >specifications, and then to SASL library implementations. > >I'm sure that most of my issues could be solved by elaborating the >text, so the reader can understand what the intended general >philosophy is. Mostly I have refrained from suggesting specific >solutions, and below I only try to understand the current document. >My hope is that these ramblings can be turned into specific pointers >to where the document could be improvement, so that other people don't >have to ask the same questions I do. > >In 5.2 "Mechanism profile guidelines" there is this paragraph: > > Authentication mechanisms SHOULD encode character strings in UTF-8 > [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character > sets in IETF protocols). In order to avoid interoperability problems > due to differing normalizations, when a mechanisms specifies that > character data is to be used as input to a cryptographic and/or > comparison function, the mechanism specification MUST detail how the > data is to be represented, including any normalizations or other > preparations, to ensure proper function. Designers of mechanisms > SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] where applicable. > >I fail to understand several things here. > >First, does 'character strings' include the authorization identity? >Defining the term 'character string', or at least giving examples, >would help. No. I believe the text should be clarified. Mechanisms should be capable of exchanging the authorization identity, but its handling (in particular for comparison) is specific to the application-level protocol which has profiled use of SASL as an authentication method. >Second, is the 'MUST' conditioned on the 'when', or is the 'when' only >there to give the rationale behind the 'MUST'? In other words, is the >intention that all mechanisms MUST detail the normalization etc steps, >regardless of whether they input the strings to >cryptographic/comparison functions? I believe its conditional. It likely should be reworded for clarity. >Third, similarly, does the 'SHOULD' apply to all mechanisms, or just >those that actually use the 'character strings' as input to >cryptographic operations? It applies to "applicable" character strings. SASLprep is not applicable to all character strings. >For the sake of argument, I'm assuming the authorization identity is >considered a character string (this is my experience with deployed >tools, the administrator just types in the authorization identity). As noted above, I think this text should be clarified as not applying to the authorization identity. Even though most of the rest of your comments depend on your assumption, I went ahead and injected a few comments here and there. >Further, mechanisms MUST specify normalization, and SHOULD use >SASLprep "where applicable", for the processing of all character >strings, including the authorization identity. Ignoring the "including the authorization identity", yes. >The "where applicable" qualifier mostly invalidate the keywords. I think not. The statement says designers should consider whether use of SASLprep, if applicable, is appropriate. That implies that they should consider both the applicability of SASLprep and, if applicable, its appropriateness. The "where applicable" was added because we didn't want designers to think they SHOULD use SASLprep for all character strings. They SHOULD use SASLprep for kinds of character strings which SASLprep was designed to be used with. >When is SASLprep applicable or not? That's discussed in the SASLprep I-D, namely in Section 1 but also in Section 2 and 3. >That seems rather subjective to me. Consideration of a "SHOULD" is always subjective. >Otherwise, I believe this SHOULD, without any verifiable >technical consequences, should be removed. I disagree. >Let's go the section 5.1 "Protocol profile requirements": > 8) A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics. A protocol profile MUST specify the > form of the authorization identity (since it is protocol specific, as > opposed to the authentication identity, which is mechanism specific) > and how authorization identities are to be compared. Profiles whose > authorization identities are simple user names (e.g. IMAP [RFC 3501]) > SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] to prepare these names for matching. The > profiles MAY use a stringprep profile that is more strict than > SASLprep. > >This says the form of the authorization identity is protocol specific. >Given the recommendations in 5.2 for mechanism specification to modify >the form of the authorization identity, it appears to be in conflict. Correct. That's why 5.2 should be clarified as not to apply to authorization identities. >In order words: Should the authzid normalization procedure defined by >the mechanism be run before or after the authzid normalization >procedure defined by the profile? There should be no mechanism specific normalization of the authorization identity. In regards to the mechanism, both peers should use the client provided string in all functions. This likely should be stated in the mechanism profile requirements. >I'm assuming here that "server" refer to the actual application, not >the server part of the generic SASL implementation. The term "server" refers to the service-providing peer and a "server implementation" refers to all components which make up that peer (operating system, libraries, program code, and any and all supporting external systems on that end). What is or isn't in a library is an implementation detail. >Up until now, at >least my SASL implementation has not been aware of the protocol that >uses the library. The justification for this is the same that SASL >mechanisms shouldn't contain SASL profile specific behaviour, and vice >versa: > > A protocol profile SHOULD NOT attempt to amend the definition of > mechanisms or make mechanism-specific encodings. This breaks the > separation between protocol and mechanism that is fundamental to the > design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. I note, this should be s/profile neutral/protocol neutral/. >Is my interpretation of what "server" refer to here correct? That >only the protocol specific part SHOULD verify the authzid form? It means that the protocol profile is to specify the form of the authzid (and how to compare it) and the mechanism should just provide a mechanism for exchanging the authzid. Kurt From owner-ietf-sasl Wed Feb 25 09:16:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHGbI2019285; Wed, 25 Feb 2004 09:16:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PHGbQj019284; Wed, 25 Feb 2004 09:16:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHGTFD019274 for ; Wed, 25 Feb 2004 09:16:30 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aw2e4-0005nY-00 for ; Wed, 25 Feb 2004 18:16:28 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 17:16:28 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 17:16:28 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Wed, 25 Feb 2004 18:16:15 +0100 Lines: 16 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:zwy/LZCR4VXyP4kl2cYxiVwkSBM= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >>First, does 'character strings' include the authorization identity? >>Defining the term 'character string', or at least giving examples, >>would help. > > No. I believe the text should be clarified. Mechanisms should be > capable of exchanging the authorization identity, but its handling > (in particular for comparison) is specific to the application-level > protocol which has profiled use of SASL as an authentication method. I see. Thanks for the reply, I'll review my issues once an updated draft is available. Regards, Simon From owner-ietf-sasl Wed Feb 25 15:08:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PN8dch044214; Wed, 25 Feb 2004 15:08:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PN8cp5044213; Wed, 25 Feb 2004 15:08:38 -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.11/8.12.8) with ESMTP id i1PN8XUm044200 for ; Wed, 25 Feb 2004 15:08:38 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1PN8aMs052713 for ; Wed, 25 Feb 2004 23:08:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 15:08:30 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: sasl-rfc2222bis: multiple authentication attack 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: In review of the latest draft, I've come across a number of technical and editorial concerns which I intend to start a number of separate threads on. This is the first. I am particularity perplexed by the long discussion of the "Multiple Authentication attack", an attack which only impacts certain kinds of distributed server implementations, which seems to overshadow higher risk, more generally applicable attacks. I am quite concerned about the addition of: > The protocol profiles that allow for > reauthentication SHOULD recommend that another security layer is > negotiated once a security layer was installed. as, if the implementation were subject to this kind of attack, simply recommending, or even requiring, negotiation of another security layer does not fully mitigate the risk. A server which is subject to such attack should simply refuse re-authentication (or if the implementor was only concerned about post re-authentication attacks, it can refuse re-authentications which don't result in installation of new layers). It seems odd to address what is a protocol-neutral security consideration in this fashion (a recommendation upon protocol profiles). Anyways, as previously discussed (and, I believe, agreed), this issue is best addressed through statement of security considerations. Hence, I suggest that all mention of this attack be removed from section 6.3, including all of section 6.3.1, and that the Security Consideration mention of 6.3.1 be replaced with (and merged with the preceding paragraph about distributed server implementations): It may be appropriate for a server to disallow all re-authentication, or re-authentications which do not result in new security layers being established, involving non- (or insufficiently) trusted parties. In some cases, it may be appropriate for the server to require separate connections to access information in different protected information spaces. Kurt From owner-ietf-sasl Wed Feb 25 15:45:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PNjbxM046455; Wed, 25 Feb 2004 15:45:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PNjbQ3046454; Wed, 25 Feb 2004 15:45:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PNjYdA046447 for ; Wed, 25 Feb 2004 15:45:35 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aw8ih-0001kO-00 for ; Thu, 26 Feb 2004 00:45:39 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 23:45:39 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 23:45:39 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Thu, 26 Feb 2004 00:45:27 +0100 Lines: 63 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:61ow7DN5S5lmMgWQugLB6GAECxQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Below is an image of how I perceive the normalization in rfc2222bis is intended to work, after extrapolating how Kurt's suggestions will be applied to the next version of the document. The requirement on mechanisms is to transport F(AuthZId) unmodified to the server. Profiles may normalize the AuthZId however they want, and mechanism may normalize authentication identities however they want. Mechanism may not normalize the authorization further (even for internal cryptographic processing). Is this correct? (I prefer not to speculate like this, because it generate long and potentially irrelevant e-mails, but was asked to do so to speed up the progress of the draft, please bear with me.) If so, and here comes my question, if two protocol profiles uses different normalizations, and a mechanism is implemented by storing a hash of H(Username|AuthId|AuthZid) (or it works in some similar way), the mechanism appear to need to select among different password databases, depending on which protocol is used. Implementation wise, the mechanism must know which protocol is used to select the correct database. If this is not done, there is the question of which normalization to use when the server compute H(U|A|Az) when storing it in the database. If only one of the protocol normalization steps is used, then it won't work with the other protocol. If both normalizations are stored, without the information on what protocol is used for each hash, someone might create an authorization identity in one of the protocols that map to another authorization identity in the other protocol. If the database also store which protocol the AuthZId was normalized for, before the hash, it would work if the mechanism knew the protocol that is used, but would prevent using the same database for new protocols using SASL. The password database is coupled to the protocol, in general. This seem to be a different model than what RFC 2222 used, which will affect implementations. Authentication Authorization Identity Identity - AuthZId | | | | | \|/ \|/ +-------------------+ +--------------------+ | Protocol profile | | | | | normalization | | \|/ | +-------------------+ | +---------------+ | | | | Mechanism | | | | | Normalization | | | | +---------------+ | | | | | | | \|/ | | Possibly revised | +-----------+ | | authorization identity | | Mechanism |<----|<-----------+ F(AuthZId) | +-----------+ | | | | | | | +--------------------+ | | Client | ............|.......................... Server | | \|/ Regards, Simon From owner-ietf-sasl Wed Feb 25 17:14:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1ECFS051629; Wed, 25 Feb 2004 17:14:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1ECrM051627; Wed, 25 Feb 2004 17:14:12 -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.11/8.12.8) with ESMTP id i1Q1EBSt051620 for ; Wed, 25 Feb 2004 17:14:11 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1E8Ms054515; Thu, 26 Feb 2004 01:14:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:14:01 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@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: It's my view that the mechanism provides method for transferring an string representing the authorization identity. Not only is the form of this authorization identity protocol specification, but how to compare two authorization identities is a matter of the protocol specification. The protocol specification must detail where any normalization (in the broadest sense) is to be done. It could be done on the client side, or the server side, or a combination. Hence, it is very important that where a mechanism uses the authorization identity as input to a cryptographic function that it uses the precise form transferred (or to be transferred) by the mechanism. That is, any and all client side normalization (per the protocol profile) of the authzid must occur before input to the function and no server side normalization (per the protocol profile) of the authzid must occur before input to the function. From the protocol perspective, user provided authzid -> client side normalization -> transfer by mechanism -> server side normalization -> use From a mechanism perspective, the protocol normalization (if any) that is occurring is irrelevant as it's only responsible for its transfer. If the mechanism does do anything with the authorization identity, such as inputs into a cryptographic function, it MUST use the value as transferred. So, I think your picture is not correct as it implies normalization is a client side matter. That is not necessarily the case. At 03:45 PM 2/25/2004, Simon Josefsson wrote: >Below is an image of how I perceive the normalization in rfc2222bis is >intended to work, after extrapolating how Kurt's suggestions will be >applied to the next version of the document. The requirement on >mechanisms is to transport F(AuthZId) unmodified to the server. >Profiles may normalize the AuthZId however they want, including at the client and/or the server. >and mechanism >may normalize authentication identities however they want. including at the client and/or the server. >Mechanism >may not normalize the authorization further (even for internal >cryptographic processing). Is this correct? Yes. mechanisms are responsible only for transferring the a string which represents, in an protocol specific manner, the authorization identity. >(I prefer not to >speculate like this, because it generate long and potentially >irrelevant e-mails, but was asked to do so to speed up the progress of >the draft, please bear with me.) > >If so, and here comes my question, if two protocol profiles uses >different normalizations, and a mechanism is implemented by storing a >hash of H(Username|AuthId|AuthZid) (or it works in some similar way), Huh? I assume you meant H(authcid|password|authzid) or something similar. Anyways, it's bogus for the mechanism implementation to do much of anything with the authzid, except ensuring it is transferred properly, as its semantics are protocol specific. The mechanism implementation should likely have stored H(authcid|password) instead. >the mechanism appear to need to select among different password >databases, depending on which protocol is used. No, it just should not include the authzid in that database. There should be, logically, a separate database which proxy authentication (identity assumption) policy. Note that this database likely keys off a protocol-specific mapping of the authentication identity. That is, off the authzid which would have been derived from the authentication identity if no authzid has been transferred. It should be noted that this mapping requires both knowledge of the mechanism-specific form of the authentication identity and the protocol-specific form of the authorization identities. Of course, implementations might actual use other forms of identities for access control and other policy decisions... (meaning there may additional identity mappings going on). Kurt >Implementation wise, >the mechanism must know which protocol is used to select the correct >database. If this is not done, there is the question of which >normalization to use when the server compute H(U|A|Az) when storing it >in the database. If only one of the protocol normalization steps is >used, then it won't work with the other protocol. If both >normalizations are stored, without the information on what protocol is >used for each hash, someone might create an authorization identity in >one of the protocols that map to another authorization identity in the >other protocol. If the database also store which protocol the AuthZId >was normalized for, before the hash, it would work if the mechanism >knew the protocol that is used, but would prevent using the same >database for new protocols using SASL. The password database is >coupled to the protocol, in general. This seem to be a different >model than what RFC 2222 used, which will affect implementations. > > Authentication Authorization > Identity Identity - AuthZId > | | > | | > | \|/ > \|/ +-------------------+ > +--------------------+ | Protocol profile | > | | | | normalization | > | \|/ | +-------------------+ > | +---------------+ | | > | | Mechanism | | | > | | Normalization | | | > | +---------------+ | | > | | | | > | \|/ | | Possibly revised > | +-----------+ | | authorization identity > | | Mechanism |<----|<-----------+ F(AuthZId) > | +-----------+ | > | | | > | | | > +--------------------+ > | > | > Client | > ............|.......................... > Server | > | > \|/ > >Regards, >Simon From owner-ietf-sasl Wed Feb 25 17:37:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1bXr9053250; Wed, 25 Feb 2004 17:37:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1bXDL053249; Wed, 25 Feb 2004 17:37:33 -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.11/8.12.8) with ESMTP id i1Q1bWG7053243 for ; Wed, 25 Feb 2004 17:37:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1bUMs054845; Thu, 26 Feb 2004 01:37:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225173539.04ca4028@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:37:23 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@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 05:14 PM 2/25/2004, Kurt D. Zeilenga wrote: >Hence, it is very important that where a mechanism uses the >authorization identity as input to a cryptographic function that >it uses the precise form transferred (or to be transferred) by >the mechanism. I note that DIGEST-MD5 is an example of a mechanism which uses the transferred authzid value as input to a cryptographic function. Kurt From owner-ietf-sasl Wed Feb 25 17:34:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1Y6L6053088; Wed, 25 Feb 2004 17:34:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1Y6Hk053086; Wed, 25 Feb 2004 17:34:06 -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.11/8.12.8) with ESMTP id i1Q1Y3cs053080 for ; Wed, 25 Feb 2004 17:34:03 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1Y9Ms054812 for ; Thu, 26 Feb 2004 01:34:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:34:02 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: sasl-rfc2222bis review notes [long] 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: Here are my review notes.... >Network Working Group A. Melnikov >Internet Draft Editor >Document: draft-ietf-sasl-rfc2222bis-06.txt February 2004 >Obsoletes: RFC 2222 Expires in six months > > > Simple Authentication and Security Layer (SASL) > >Status of this Memo > > This document is an Internet Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet Drafts are working documents of the Internet Engineering > Task Force (IETF), its Areas, and its Working Groups. Note that > other groups may also distribute working documents as Internet > Drafts. Internet Drafts are draft documents valid for a maximum of > six months. Internet Drafts may be updated, replaced, or obsoleted > by other documents at any time. It is not appropriate to use > Internet Drafts as reference material or to cite them other than as > ``work in progress''. > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > A revised version of this draft document will be submitted to the RFC > editor as a Standards Track RFC for the Internet Community. > Discussion and suggestions for improvement are requested. > Distribution of this draft is unlimited. > > When published as an RFC this document will obsolete RFC 2222. This statement needs to be moved into the body of the document. That is, the body of the document needs to explicitly state: This document replaces RFC 2222. (see below) > > >1. Abstract The abstract need not be numbered. > The Simple Authentication and Security Layer (SASL) provides a method > for adding authentication support with an optional security layer to > connection-based protocols. As used here, the word "optional" implies that protocols MAY include security layer support. Suggest this be reworded The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-based protocols. > It also describes a structure for > authentication mechanisms. The result is an abstraction layer > between protocols and authentication mechanisms such that any SASL- > compatible authentication mechanism can be used with any SASL- > compatible protocol. > > This document describes how a SASL authentication mechanism is > structured, describes how a protocol adds support for SASL, defines > the protocol for carrying a security layer over a connection, and > defines the EXTERNAL SASL authentication mechanism. It might be better to transpose EXTERNAL and SASL here. >2. Organization of this document > >2.1. How to read this document > > This document is written to serve several different audiences, > protocol designers using this specification to support authentication > in their protocol, mechanism designers that define new SASL > mechanisms, and implementors of clients or servers for those > protocols using this specification. I suggest using a bullet list for the above. > The sections "Overview", "Authentication Mechanisms", "Protocol > Profile Requirements", "Specific Issues", and "Security > Considerations" cover issues that protocol designers need to > understand and address in profiling this specification for use in a > specific protocol. > > The sections "Overview", "Authentication Mechanisms", "Mechanism > Profile Requirements" and "Security Considerations" cover issues that > mechanism designers need to understand and address in designing new > SASL mechanisms. > > Implementors of a protocol using this specification need the > protocol-specific profiling information in addition to the > information in this document. This implies implementors need to understand all of this document. They should not need to read the protocol and mechanism profiling requirements. >2.2. Conventions used in this document > > In examples, "C:" and "S:" indicate lines sent by the client and > server respectively. > > The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" > in this document are to be interpreted as defined in "Key words for > use in RFCs to Indicate Requirement Levels" [KEYWORDS]. > > Character names in this document use the notation for code points and > names from the Unicode Standard [Unicode]. For example, the letter > "a" may be represented as either or . > > This document uses terms "integrity protection" and "confidentiality > protection". The former references to a security layer that is able > to detect data modification by using some kind of hash. However, I suggest the "by using some kind of hash" qualification be dropped. The term "integrity protection" applies to any layer which is capable of detecting data modification (regardless of whether it using some kind of hash or not). I suggest: The term "integrity protection" refers to a security layer designed to detect unauthorized data modification. > integrity protection doesn't make the data unreadable to an attacker. Suggest instead: However, integrity protection does not (by itself) prevent unauthorized disclose of the data. > Confidentiality protection is a security layer that is able to make > the data unreadable to an attacker by using encryption. Suggest: Confidentiality protection is a security layer which is designed to prevent unauthorized disclose of the data (generally through use of encryption). > Confidentiality protection usually implies integrity protection. Suggest: Confidentiality protection usually (but not necessarily) implies integrity protections. Alteratively, replace this and the above "However, .." with Both integrity protection and confidentiality are needed to achieve data security. Note that this is a paraphrased of [RFC 2828] "data security"]. Which brings up the question, why don't we just use "data integrity service" and 'data confidentiality service" as defined in RFC 2828? I think it best to avoid defining SASL-specific security terminology. Also, some note to the effect: Security layers may offer other kinds of security services. > >3. Overview I suggest this section be moved to immediately follow the Abstract and be retitled "Introduction". I then suggest the section 2 subsections be incorporated into this section. > The Simple Authentication and Security Layer (SASL) is a method for > adding authentication support to connection-based protocols. > > The SASL specification has three layers, as indicated in the diagram > below. I'm not sure I like how SASL is described in terms of protocol profiles (which is a technical specification or document) and a mechanism definition (which is a technical specification or document). Also, it seems odd to say "specifies a profile" as a profile is a specification. And the phrase "mechanism definition specifies an authentication mechanism" seems a bit circular. > At the top, a protocol definition using SASL specifies a > profile, including a command for identifying and authenticating a > user to a server and for optionally negotiating a security layer for > subsequent protocol interactions. At the bottom, a SASL mechanism > definition specifies an authentication mechanism. The SASL > framework, specified by this document, constrains the behavior of > protocol profiles and mechanisms, separating protocol from mechanism > and defining how they interact. > > SMTP Protocol LDAP Protocol Etc > Profile Profile . . . > \----- | -----/ > \ | / > SASL framework > / | \ > /----- | -----\ > EXTERNAL DIGEST-MD5 Etc > SASL mechanism SASL mechanism . . . > > This separation between the definition of protocols and the > definition of authentication mechanisms is crucial. It permits an I think it is the separation between (application-level) protocols and mechanisms, not their definitions, that is crucial. > authentication mechanism to be defined once, making it usable by any > SASL protocol profile. In many implementations, the same SASL > mechanism code is used for multiple protocols. Add another (see above) subsection which X.Y. Relationship to other documents This document obsoletes RFC 2222. It replaces all portions of RFC 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete. The GSSAPI mechanism is now separately specified [SASL-GSSAPI]. Appendix B. details changes since RFC 2222. >4. Authentication mechanisms > > SASL mechanisms are named by strings, from 1 to 20 characters in > length, consisting of ASCII [ASCII] upper-case letters, digits, > hyphens, and/or underscores. SASL mechanism names must be registered > with the Internet Assigned Numbers Authority (IANA). IETF standards > track documents may direct the IANA to reserve a portion of the SASL > mechanism namespace and may specify different registration criteria > for the reserved portion; the GSSAPI mechanism specification > [SASL-GSSAPI] does this. The above sentence should be moved in IANA considerations section. > Procedures for registering new SASL mechanisms are given in section 8. > > The "sasl-mech" production below defines the syntax of a SASL > mechanism name. This uses the Augmented Backus-Naur Form (ABNF) > notation as specified in [ABNF] and the ABNF core rules as specified > in Appendix A of the ABNF specification [ABNF]. > > sasl-mech = 1*20mech-char > mech-char = %x41-5A / DIGIT / "-" / "_" > ; mech names restricted to ASCII uppercase letters, > ; digits, "-" and "_" > I suggest this comment be replaced with: ; mech-char is restricted to "A"-"Z", "0"-"9", "-", and "_" : from ASCII character set. In the ABNF, I suggest (for consistency) replacing DIGIT, "-", and "_" with %x30-39, %x2D, and %x5F, respectively. This also avoids unnecessary reliance on a core rule (which would require the implementor to look up meaning of DIGIT). > >4.1. Authentication protocol exchange > > A SASL mechanism is responsible for conducting an authentication > protocol exchange. This consists of a series of server challenges > and client responses, the contents of which are specific to and > defined by the mechanism. To the protocol, the challenges and > responses are opaque binary tokens of arbitrary length. The > protocol's profile then specifies how these binary tokens are then > encoded for transfer over the connection. I suggest replacing binary tokens with octet string because: 1) the challedge and responses must be aligned on 8-bit boundries and 2) what (in IP) isn't binary? 3) the challedge and responses seem not to be "tokens". > After receiving an authentication command or any client response, a > server mechanism may issue a challenge, indicate failure, or indicate > completion. The server mechanism may return additional data with a > completion indication. The protocol's profile specifies how each of > these is then represented over the connection. > > After receiving a challenge, a client mechanism may issue a response > or abort the exchange. The protocol's profile specifies how each of > these is then represented over the connection. > > During the authentication protocol exchange, the mechanism performs > authentication, transmits an authorization identity (frequently known > as a userid) from the client to server, and negotiates the use of a > mechanism-specific security layer. If the use of a security layer is > agreed upon, then the mechanism must also define or negotiate the > maximum security layer buffer size that each side is able to receive. > > >4.2. Authorization and authentication identities > > SASL authentication deals with two identities: the authorization > identity and the authentication identity. I suggest the "authorization identity" and "authentication identity" be defined here (move the below def'ns to here). I suggest defining "authentication identity" first. Doing so, I also suggest swapping the order of the terms in the section title and first sentence. > The transmitted > authorization identity may be an empty string (zero length), but the > transmitted authentication identity may not be an empty string. I think the latter ("but ...") part should be deleted. Nothing says a mechanism has a "transmitted authentication identity", and nothing (in RFC 2222) prevented a mechanism from transmitting an empty authentication identity. Whether or not such is permissible should be left to the mechanisms to decide. In fact, whether or not an authentication identity is explicitly transferred between the SASL client and server should be left the mechanism. It may simply be implied by the client's credentials (as noted below). > A mechanisms which are incapable of transmitting an authorization > identity must be treated as if it always transmits an authorization > identity of an empty string. > > Authentication identity is the identity derived from the client's > authentication credentials. > > The authorization identity is used by the server as the primary > identity for making access policy decisions. > >4.2.1. Authorization identities and proxy authentication > > 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 derive authorization identities from > authentication identities. Instead, clients SHOULD provide no (or > empty) authorization identity when the user has not provided an > authorization identity. > > The server SHOULD verify that a received authorization identity is in > the correct form. Why isn't this a MUST? That is, how are servers to compare or otherwise handle authorization identities which are not in correct form? > Profiles whose authorization identities are simple > user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile > [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare > these names for matching. The profiles MAY use a stringprep profile > that is more strict than "SASLprep". 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. "profile" should be qualified above to refer to the protocol profile. I think it mostly states a protocol profile requirement. But then it includes an implementation imperative. But this is odd in that server may not actually be required to do any preparation (the profile might place that burden on the client). I think the "If the preparation..." part should be reworded as a profile requirement. That is, it should state that profiles should detail how implementations are to behave when required preparation fails. Given that, I think this can and should be moved to Section 5. >4.2.2. Authorization Identity Format > > An authorization identity is a string of zero or more Unicode > [Unicode] coded characters. The NUL character is not > permitted in authorization identities. > > The character encoding scheme used for transmitting an authorization > identity over the protocol is specified in each authentication > mechanism. All IETF-defined mechanisms MUST, and all other > mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF > policy regarding character sets and encoding schemes.) > > 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 an absent > authorization identity MUST be treated as equivalent. A mechanism > which provides an optional field for an authorization identity, > SHOULD NOT allow that field, when present, to be empty. The meaning > of the empty string as an authorization identity is described in the > previous section. > >4.3. Security layers > > If use of a security layer is negotiated by the authentication > protocol exchange, the security layer is applied to all subsequent > data sent over the connection (until another security layer is > negotiated; see also section 6.3). The security layer takes effect > immediately following the last response of the authentication > exchange for data sent by the client and the completion indication > for data sent by the server. > > Note that all SASL mechanisms that are unable to negotiate a security > layer automatically select no security layer. > > Once the security layer is in effect the protocol stream is processed > by the security layer into buffers of security encoded data. Each > buffer of security encoded data is transferred over the connection as > a stream of octets prepended with a four octet field in network byte > order that represents the length of the following buffer. The length > of the security encoded data buffer MUST be no larger than the > maximum size that was either defined in the mechanism specification > or negotiated by the other side during the authentication protocol > exchange. Upon the receipt of a data buffer which is larger than the > defined/negotiated maximal buffer size the receiver SHOULD close the > connection. This might be a sign of an attack or a buggy > implementation. > >5. Protocol and mechanism profiles > >5.1. Protocol profile requirements > > In order to use this specification, a protocol definition MUST supply > the following information: > > 1) A service name, to be selected from the IANA registry of "service" > elements for the GSSAPI host-based service name form [GSSAPI]. This > service name is made available to the authentication mechanism. > > The registry is available at the URL > . > > 2) A definition of the command to initiate the authentication > protocol exchange. This command must have as a parameter the name of > the mechanism being selected by the client. > > The command SHOULD have an optional parameter giving an initial > response. If the protocol allows for the initial response, the > protocol profile SHOULD also describe how an empty initial response > is encoded. This optional parameter allows the client to avoid a > round trip when using a mechanism which is defined to have the client > send data first. When this initial response is sent by the client > and the selected mechanism is defined to have the server start with > an initial challenge, the command fails. See section 6.1 of this > document for further information. > > 3) A definition of the method by which the authentication protocol > exchange is carried out, including how the challenges and responses > are encoded, how the server indicates completion or failure of the > exchange, how the client aborts an exchange, and how the exchange > method interacts with any line length limits in the protocol. > > The exchange method SHOULD allow the server to include an optional > data ("optional challenge") with a success notification. This allows > the server to avoid a round trip when using a mechanism which is > defined to have the server send additional data along with the > indication of successful completion. See section 6.2 of this > document for further information. > > 4) A protocol profile SHOULD specify a mechanism through which a > client may obtain the names of the SASL mechanisms available to it. > This is typically done through the protocol's extensions or > capabilities mechanism. > > 5) Identification of the octet where any negotiated security layer > starts to take effect, in both directions. > > 6) Specify if the protocol profile supports "multiple > authentications" (see section 6.3). > > 7) If both TLS and SASL security layer are allowed to be negotiated > by the protocol, the protocol profile MUST define in which order they > are applied to a cleartext data sent over the connection. Spell TLS out on first use. > 8) A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics. A protocol profile MUST specify the > form of the authorization identity (since it is protocol specific, as > opposed to the authentication identity, which is mechanism specific) > and how authorization identities are to be compared. Profiles whose > authorization identities are simple user names (e.g. IMAP [RFC 3501]) > SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] to prepare these names for matching. The > profiles MAY use a stringprep profile that is more strict than > SASLprep. > > A protocol profile SHOULD NOT attempt to amend the definition of > mechanisms or make mechanism-specific encodings. This breaks the > separation between protocol and mechanism that is fundamental to the > design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. > >5.2. Mechanism profile guidelines > > Designers of new SASL mechanism should be aware of the following > issues: > > 1) Authorization identity. Remove the "." > While some legacy mechanisms are incapable of transmitting an > authorization identity (which means that for these mechanisms the > authorization identity is always the empty string), newly defined > mechanisms SHOULD be capable of transmitting a non-empty > authorization identity. See also section 4.2. > > 2) Character string issues > > Authentication mechanisms SHOULD encode character strings in UTF-8 > [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character > sets in IETF protocols). In order to avoid interoperability problems > due to differing normalizations, when a mechanisms specifies that > character data is to be used as input to a cryptographic and/or > comparison function, the mechanism specification MUST detail how the > data is to be represented, including any normalizations or other > preparations, to ensure proper function. Designers of mechanisms > SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] where applicable. excepting authzid > The preparation can be potentially performed on the client end (upon > getting user input or retrieving a value from configuration) or on > the server end (upon receiving the value from the client, retrieving > a value from its authentication database or generating a new value in > order to store in in the authentication database). SASL mechanisms > must define which entity (or entities) must perform the preparation. > If preparation fails or results in an empty string, the entity doing > the preparation SHALL fail the authentication exchange. > > Implementation note: A server end can be represented by multiple > processes. For example, it may consist of the server process itself > that communicated with a client, and a command line utility (a server > agent) that is able to store passwords/hashes in a database that can > be later used by the server. For the server agent the requirement to > "fail the authentication exchange" should be interpreted as a > requirement to refuse to store the data in the database. > >6. Specific issues > >6.1. Client sends data first > > Some mechanisms specify that the first data sent in the > authentication protocol exchange is from the client to the server. > > If a protocol's profile permits the command which initiates an > authentication protocol exchange to contain an initial client > response, this parameter SHOULD be used with such mechanisms. > > If the initial client response parameter is not given, or if a > protocol's profile does not permit the command which initiates an > authentication protocol exchange to contain an initial client > response, then the server issues a challenge with no data. The > client's response to this challenge is then used as the initial > client response. (The server then proceeds to send the next > challenge, indicates completion, or indicates failure.) > >6.1.1. Client sends data first examples > > The following are two examples of an SECURID authentication [SASL- > SECURID] in the SMTP protocol [SMTP]. In the first example below, > the client is trying fast reauthentication by sending the initial > response: > > S: 220-smtp.example.com ESMTP Server > C: EHLO client.example.com > S: 250-smtp.example.com Hello client.example.com, pleased to meet you This line is too long. Suggest you s/Hello.*/Welcome client.example.com/ > S: 250-AUTH GSSAPI SECURID > S: 250 DSN > C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= > S: 235 Authentication successful > > The example below is almost identical to the previous, but here the > client chooses not to use the initial response parameter. > > S: 220-smtp.example.com ESMTP Server > C: EHLO client.example.com > S: 250-smtp.example.com Hello client.example.com, pleased to meet you This line is too long. > S: 250-AUTH GSSAPI SECURID > S: 250 DSN > C: AUTH SECURID > S: 334 > C: AG1hZ251cwAxMjM0NTY3OAA= > S: 235 Authentication successful > > Section 7.2 contains an additional example. Indention is off here. Also note that 7.2 provides two examples as does 6.2.1. So, this should read: Additonal examples can be found in sections 6.2.1 and 7.2. >6.2. Server returns success with additional data > > Some mechanisms may specify that additional data be sent to the > client along with an indication of successful completion of the > exchange. This data would, for example, authenticate the server to > the client. > > If a protocol's profile does not permit this additional data to be > returned with a success indication, then the server issues the data > as a server challenge, without an indication of successful > completion. The client then responds with no data. After receiving > this empty response, the server then indicates successful completion > (with no additional data). > > Client implementors should be aware of an additional failure case > that might occur when the profile supports sending the additional > data with success. Imagine that an active attacker is trying to > impersonate the server and sends faked data, which should be used to > authenticate the server to the client, with success. (A similar > situation can happen when either the server and/or the client has a > bug and they calculate different responses.) After checking the data, > the client will think that the authentication exchange has failed, > however the server will think that the authentication exchange has > completed successfully. At this point the client can not abort the > authentication exchange; it SHOULD close the connection instead. > However, if the profile did not support sending of additional data > with success, the client could have aborted the exchange at the very > last step of the authentication exchange. > >6.2.1. Server returns success with additional data examples > > The following are two examples of a DIGEST-MD5 authentication [SASL- > DIGEST] in the XMPP protocol [XMPP]. In the first example below, the > server is sending mutual authentication data with success. spell XMPP out on first use. > > C: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > to='example.com' > version='1.0'> > S: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > id='c2s_234' > from='example.com' > version='1.0'> > S: > > DIGEST-MD5 > CRAM-MD5 > > > C: mechanism='DIGEST-MD5'/> > S: > cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi This line is too long... > LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== > > C: > dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i > T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw > MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i > LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo > YXJzZXQ9dXRmLTgK > > S: > cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= > > > The example below is almost identical to the previous, but here > the server chooses not to use the additional data with success. > > C: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > to='example.com' > version='1.0'> > S: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > id='c2s_234' > from='example.com' > version='1.0'> > S: > > DIGEST-MD5 > CRAM-MD5 > > > C: mechanism='DIGEST-MD5'/> > S: > cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi This line is too long. > LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== > > C: > dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i > T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw > MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i > LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo > YXJzZXQ9dXRmLTgK > > S: > cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= > > C: > S: > >6.3. Multiple authentications > > Unless otherwise stated by the protocol's profile, only one > successful SASL negotiation may occur in a protocol session. In this > case, once an authentication protocol exchange has successfully > completed, further attempts to initiate an authentication protocol > exchange fail. > 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 remains in effect. > > Note that keeping the original security layer is a subject to a class > of security attack described in section 6.3.1. I think this note should be deleted. We haven't inserted notes for other security attacks. And we've covered this with a far more general security consideration. The description itself, which I don't think is terrible useful (have such a long description over such a minor security issue distracts attention from major security issues which have little to no description). I think section 6.3.1 (and this paragraph, especially given the need to further detail the limited effectiveness of the below SHOULD) should be deleted. > However, at the time > of the writing of this document the Working Group consensus is not to > change SASL handling of security layers, as the risk of such attacks > is considered to be low and specific to only certain classes of > implementations. The protocol profiles that allow for > reauthentication SHOULD recommend that another security layer is > negotiated once a security layer was installed. I don't believe there is sufficient reason to state this as a SHOULD upon protocols profiles. As noted, it is only specific to a certain class of implementations. As previously discussed in the WG, this can and should be addressed through a security consideration stating that implementations within this class takes steps, such as enforcing a local policy disallowing subsequent authentication, to mitigate this risk. The security consideration description seems to be sufficiently address this risk. I suggest we focus discussion on this (the stated security consideration). (Also, note that simply reauthenticating with another security layer does fully mitigate the risk as the subsequent authentication is operating over the old layers. If we state this SHOULD, then we'd have to also state a security consideration noting that it ineffective in some cases.) > 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. I suggest this be replaced with: Where a protocol profile does permit multiple successful SASL negotiations, the profile MUST detail the effect of a failed SASL negotiation upon the previously established authentication state. In particular, it MUST state whether the previously established authenticated state remain in force or whether the connection is to revert to an non-authenticated state. Regardless of the specified effect upon authentication state, the previously negotiated security layer remains in effect. >6.3.1. Description of Multiple Authentication attack > > Let's assume that the protected resources on a server are partitioned > into a set of protection spaces, each with its own authentication > mechanisms and/or authorization database. Let's use the term > "partition" to reference any such protected space. An example of a > partition might be an HTTP "realm". Also a proxy/frontend can use > different partitions for different servers/backends it represents. > > Now consider the following scenario. A client has already > authenticated and established a security layer with "Partition A" > which is managed by the server AA. Now the same client authenticates > to "Partition B" (managed by the server BB) without negotiating a new > security layer, while the security layer negotiated with "Partition > A" remains in effect. The server BB is now able to observe how known > cleartext is encrypted. This scenario enables the server BB to make > guesses about previously observed ciphertext between the client and > the server AA using the server's SASL engine as an oracle. This > scenario is illustrated below: > > > +---------+ +---------+ > | | | | > |Partition| |Partition| > | B | | A | > +---------+ +---------+ > | ^ | > | : +-----------+ | > Traffic from | : | Encryption| | Traffic from A > B to client +-------->| end point |<-------+ to client > : | (SSL/SASL)| > : +-----------+ > : | > : | > : +---+ > : | | > : | | > : | | Encryption tunnel, e.g. SASL or SSL, > : | | between the server > (1) Recording +---------:| | and a single client only. > encrypted | | Separate tunnels to different > traffic between | | clients. > Partition A and client +---+ > | > | > +-----------> Traffic to clients > > < > > Where this situation cannot be managed through trust relationship, it > may be appropriate for the server implementation to not support > multiple authentications. >> > > > >7. The EXTERNAL mechanism > > The mechanism name associated with external authentication is > "EXTERNAL". > > The client sends an initial response with the UTF-8 encoding of the > authorization identity. The form of the authorization identity is > further restricted by the application-level protocol's SASL profile. > > The server uses information, external to SASL, to determine whether > the client is authorized to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > > > >A. Melnikov FORMFEED[Page 14] > > > > > >Internet DRAFT SASL 14 February 2004 > > > server indicates failure. > > The system providing this external information may be, for example, > IPSec or TLS. Spell IPsec out on first use. > However, the client can make no assumptions as to what > information the server can use in determining client authorization. > For example, just because TLS was established, doesn't mean that the > server will use the information provided by TLS. > > If the client sends the empty string as the authorization identity, > the authorization identity is to be derived from authentication > credentials which exist in the system that is providing the external > authentication. > >7.1. Formal syntax > > The following syntax specification uses the augmented Backus-Naur > Form (BNF) notation as specified in [ABNF]. This uses the ABNF core > rules as specified in Appendix A of the ABNF specification [ABNF]. I don't believe any Appendix A core rules are used here. > Non-terminals referenced but not defined below are as defined by > [UTF-8]. I suggest the non-terminal productions be directly incorporated into this document. > The "extern-init-resp" rule below defines the initial response sent > from client to server. > > extern-init-resp = *( UTF8-char-no-nul ) > > UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 > > UTF8-1-no-nul = %x01-7F > > >7.2. Example > > The following is an example of an EXTERNAL authentication in the SMTP > protocol [SMTP]. In this example, the client is proxy > authenticating, sending the authorization identity "fred" using in > the (optional) initial response. The server has determined the > client's identity through IPsec and has a security policy that > permits that identity to proxy authenticate as any other identity. An informative reference for IPsec seems appropriate here as presently worded. Suggest it be reworded, The server has obtained the client's (authentication) identity from an external service, such as IPsec, and has a security policy that permits that identity to assume the identity of the asserted authorization identity. > To the protocol profile, the four octet sequence "fred" is an opaque > binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies > that server challenges and client responses are encoded in BASE64 > [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==". > > S: 220 smtp.example.com ESMTP server ready > C: EHLO jgm.example.com > S: 250-smtp.example.com > > > >A. Melnikov FORMFEED[Page 15] > > > > > >Internet DRAFT SASL 14 February 2004 > > > S: 250 AUTH DIGEST-MD5 EXTERNAL > C: AUTH EXTERNAL ZnJlZA== > S: 235 Authentication successful. > > The following example is almost identical to the one above, but the > client doesn't use proxy authentication. s/use/request/ > S: 220 smtp.example.com ESMTP server ready > C: EHLO jgm.example.com > S: 250-smtp.example.com > S: 250 AUTH DIGEST-MD5 EXTERNAL > C: AUTH EXTERNAL > S: 235 Authentication successful. > > >8. IANA Considerations > >8.1. Guidelines for IANA > > It is requested that IANA updates the SASL mechanisms registry as > follows: > > Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism > registrations to OBSOLETE. Change the "Published specification" > of the EXTERNAL mechanism to this document. Updated registration > is provided in Section 8.6. s/registration/registration information/ > >8.2. Registration procedure > > > Registration of a SASL mechanism is done by filling in the template > in section 8.5 and sending it via electronic mail to . > IANA has the right to reject obviously bogus registrations, but will > perform no review of claims made in the registration form. SASL > mechanism registrations are currently available at the URL > . > > There is no naming convention for SASL mechanisms; any name that > conforms to the syntax of a SASL mechanism name can be registered. > An IETF Standards Track document may reserve a portion of the SASL > mechanism namespace ("family of SASL mechanisms") for its own use, > amending the registration rules for that portion of the namespace. > Each family of SASL mechanisms MUST be identified by a prefix. > > While the registration procedures do not require it, authors of SASL > > > >A. Melnikov FORMFEED[Page 16] > > > > > >Internet DRAFT SASL 14 February 2004 > > > mechanisms are encouraged to seek community review and comment > whenever that is feasible. Authors may seek community review by > posting a specification of their proposed mechanism as an Internet- > Draft. SASL mechanisms intended for widespread use should be > standardized through the normal IETF process, when appropriate. > >8.3. Comments on SASL mechanism registrations > > Comments on registered SASL mechanisms should first be sent to the > "owner" of the mechanism and/or to the SASL WG mailing list. > Submitters of comments may, after a reasonable attempt to contact the > owner, request IANA to attach their comment to the SASL mechanism > registration itself. If IANA approves of this, the comment will be > made accessible in conjunction with the SASL mechanism registration > itself. > >8.4. Change control > > Once a SASL mechanism registration has been published by IANA, the > author may request a change to its definition. The change request > follows the same procedure as the registration request. > > The owner of a SASL mechanism may pass responsibility for the SASL > mechanism to another person or agency by informing IANA; this can be > done without discussion or review. > > The IESG may reassign responsibility for a SASL mechanism. The most > common case of this will be to enable changes to be made to > mechanisms where the author of the registration has died, moved out > of contact or is otherwise unable to make changes that are important > to the community. > > SASL mechanism registrations may not be deleted; mechanisms which are > no longer believed appropriate for use can be declared OBSOLETE by a > change to their "intended use" field; such SASL mechanisms will be > clearly marked in the lists published by IANA. > > The IESG is considered to be the owner of all SASL mechanisms which > are on the IETF standards track. > >8.5. Registration template > > > Subject: Registration of SASL mechanism X > > Family of SASL mechanisms: (YES or NO) > > SASL mechanism name (or prefix for the family): > > > >A. Melnikov FORMFEED[Page 17] > > > > > >Internet DRAFT SASL 14 February 2004 > > > Security considerations: > > Published specification (optional, recommended): > > Person & email address to contact for further information: > > Intended usage: > > (One of COMMON, LIMITED USE or OBSOLETE) > > Owner/Change controller: > > (Any other information that the author deems interesting may be > added below this line.) > > >8.6. The EXTERNAL mechanism registration > > It is requested that the SASL Mechanism registry [IANA-SASL] entry > for the EXTERNAL mechanism be updated to reflect that this document > now provides its technical specification. > > > Subject: Updated Registration of SASL mechanism EXTERNAL > > Family of SASL mechanisms: NO > > SASL mechanism name: EXTERNAL > > Security considerations: See RFC XXXX, section 9. > > Published specification (optional, recommended): RFC XXXX > > Person & email address to contact for further information: > Alexey Melnikov > > Intended usage: COMMON > > Owner/Change controller: IESG > > Note: Updates existing entry for EXTERNAL > >9. Security considerations > > Security issues are discussed throughout this memo. > > The mechanisms that support integrity protection are designed such > that the negotiation of the security layer and authorization identity > is integrity protected. This statement seems a bit circular. Also, "integrity protection" was defined as providing the capability to detection unauthorized changes to data transfered by the security layer. However this uses the term implies that the authentication exchange, including layer negotiation is protected. This is problematic. If we look at DIGEST-MD5, which does offer a security layer with "integrity protection", we find a mechanism which does provide full integrity protection over the authentication exchange itself. I think we need to a bit more precise with our terminology. To avoid having to define a SASL-specific terminology, I strongly recommend we try to use RFC 2828 based terminology. When the client selects a security layer > with at least integrity protection, this protects against an active > attacker hijacking the connection and modifying the authentication > exchange to negotiate a plaintext connection. > > When a server or client supports multiple authentication mechanisms, > each of which has a different security strength, it is possible for > an active attacker to cause a party to use the least secure mechanism > supported. To protect against this sort of attack, a client or > server which supports mechanisms of different strengths should have a > configurable minimum strength that it will use. It is not sufficient > for this minimum strength check to only be on the server, since an > active attacker can change which mechanisms the client sees as being > supported, causing the client to send authentication credentials for > its weakest supported mechanism. > > The client's selection of a SASL mechanism is done in the clear and > may be modified by an active attacker. It is important for any new > SASL mechanisms to be designed such that an active attacker cannot > obtain an authentication with weaker security properties by modifying > the SASL mechanism name and/or the challenges and responses. > > In order to detect Man-in-the-middle (MITM) attacks the client MAY > list available SASL mechanisms 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. 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 (or don't support listing of SASL mechanisms once > authentication is complete); for these protocols clients MUST NOT > treat an empty list of SASL mechanisms after authentication as a MITM > attack. > > Any protocol interactions prior to authentication are performed in > the clear and may be modified by an active attacker. In the case > where a client selects integrity protection, it is important that any > security-sensitive protocol negotiations be performed after > authentication is complete. Protocols should be designed such that > negotiations performed prior to authentication should be either > ignored or revalidated once authentication is complete. > > When use of a security layer is negotiated by the authentication > protocol exchange, the receiver should handle gracefully any security > encoded data buffer larger than the defined/negotiated maximal size. > In particular, it must not blindly allocate the amount of memory > specified in the buffer size field, as this might cause the "out of > memory" condition. If the receiver detects a large block, it SHOULD > close the connection. > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. It should be > noted that, where those secrets are used to provide data > confidentiality protections, if a third party (other than the > discloser/disclosee) has knowledge of some portion of the protected > information, it can use this knowledge in an attack upon other > portions of the protected information. > > Section 6.3.1 contains a description of a potential class of attack > on a distributed server implementation. The section also gives some > recommendations about mitigating such attacks. Replace with (and append to preceding paragraph): It may be appropriate for a server to disallow all re-authentication, or re-authentications which do not result in new security layers being established, involving non- (or insufficiently) trusted parties. In some cases, it may be appropriate for the server to require separate connections to access information in different protected information spaces. > "stringprep" and Unicode security considerations apply to > authentication identities, authorization identities and passwords. > > The EXTERNAL mechanism provides no security protection; it is > vulnerable to spoofing by either client or server, active attack, and > eavesdropping. It should only be used when external security > mechanisms are present and have sufficient strength. > >10. References > >10.1. Normative References > > [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997 > > [ASCII] American National Standards Institute, "Code Extension > Techniques for Use with the 7-bit Coded Character Set of American > National Standard Code (ASCII) for Information Interchange", FIPS PUB > 35, 1974 > > [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and > Languages", RFC 2277, BCP 18, January 1998 > > [GSSAPI] Linn, J., "Generic Security Service Application Program > Interface, Version 2, Update 1", RFC 2743, January 2000 > > [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - > Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. This reference is never used and hence should be deleted. > [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", RFC 2119, BCP 19, March 1997 > > [Unicode] The Unicode Consortium, "The Unicode Standard, Version > 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, > MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the > "Unicode Standard Annex #27: Unicode 3.1" > (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard > Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). > > [Stringprep] Hoffman, P., Blanchet, M., "Preparation of > Internationalized Strings ("stringprep")", RFC 3454, December 2002. > > [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names > and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. > > [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", > RFC 3629, STD 63, November 2003. > >10.2. Informative References > > [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in > progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 > > [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest > Authentication as a SASL Mechanism", work in progress, draft-ietf- > sasl-rfc2831bis-XX.txt, replaces RFC 2831 > > [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC > 2444, October 1998. > > [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC > 2808, April 2000. > > [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April > 2001. > > [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", > RFC 2554, March 1999. > > Being revised by Siemborski, R., "SMTP Service Extension for > Authentication", work in progress, draft-siemborski-rfc2554bis- > XX.txt. This reference should be put into proper form. > > [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol > (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data > > > >A. Melnikov FORMFEED[Page 21] > > > > > >Internet DRAFT SASL 14 February 2004 > > > Encodings", RFC 3548, July 2003. > > [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC > Authors", RFC 2223, October 1997. > > [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) > MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. > >11. Editor's Address > > Alexey Melnikov > Isode Limited > > Email: Alexey.Melnikov@isode.com > >12. Acknowledgments > > This document is a revision of RFC 2222 written by John G. Myers. He > also contributed significantly to this revision. > > Magnus Nystrom provided the ASCII art used in Section 6.3. > > Definition of partition was extracted from RFC 2617 ("HTTP > Authentication: Basic and Digest Access Authentication"). > > Contributions of many members of the SASL mailing list are gratefully > acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob > Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen and > Abhijit Menon-Sen for proofreading the document and various editorial > suggestions. Suggest you drop middle initials. Needs IPR notice. > >13. Full Copyright Statement > > Copyright (C) The Internet Society (2004). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > >Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > >Appendix A. Relation of SASL to transport security > > Questions have been raised about the relationship between SASL and > various services (such as IPsec and TLS) which provide a secured > connection. > > Two of the key features of SASL are: > > The separation of the authorization identity from the identity in > the client's credentials. This 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. > > Upon successful completion of an authentication exchange, the > server knows the authorization identity the client wishes to use. > This allows servers to move to a "user is authenticated" state in > the protocol. > > These features are extremely important to some application protocols, > yet Transport Security services do not always provide them. To > define SASL mechanisms based on these services would be a very messy > task, as the framing of these services would be redundant with the > framing of SASL and some method of providing these important SASL > features would have to be devised. > > Sometimes it is desired to enable within an existing connection the > use of a security service which does not fit the SASL model. (TLS is > an example of such a service.) This can be done by adding a command, > for example "STARTTLS", to the protocol. Such a command is outside > the scope of SASL, and should be different from the command which > starts a SASL authentication protocol exchange. > > In certain situations, it is reasonable to use SASL underneath one of > these Transport Security services. The transport service would > secure the connection, either service would authenticate the client, > and SASL would negotiate the authorization identity. The SASL > negotiation would be what moves the protocol from "unauthenticated" > to "authenticated" state. The "EXTERNAL" SASL mechanism is > explicitly intended to handle the case where the transport service > secures the connection and authenticates the client and SASL > negotiates the authorization identity. > >Appendix B. Changes since RFC 2222 > > The GSSAPI mechanism was removed. It is now specified in a separate > document [SASL-GSSAPI]. > > The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has > been removed. > > The "SKEY" mechanism described in RFC 2222 is obsolete and has been > removed. It has been replaced by the OTP mechanism [SASL-OTP]. > > The overview has been substantially reorganized and clarified. > > Clarified the definition and semantics of the authorization identity. > > Prohibited the NUL character in authorization identities. > > Added a section on character string issues. > > The word "must" in the first paragraph of the "Protocol profile > requirements" section was changed to "MUST". > > Specified that protocol profiles SHOULD provide a way for clients to > discover available SASL mechanisms. > > Made the requirement that protocol profiles specify the semantics of > the authorization identity optional to the protocol profile. > Clarified that such a specification is a refinement of the definition > in the base SASL spec. > > Added a requirement discouraging protocol profiles from breaking the > separation between protocol and mechanism. > > Mentioned that standards track documents may carve out their own > portions of the SASL mechanism namespace and may amend registration > rules for the portion. However registration of individual SASL > mechanisms is still required. > > Specified that the authorization identity in the EXTERNAL mechanism > is encoded in UTF-8. > > Added a statement that a protocol profile SHOULD allow challenge data > to be sent with a success indication. > > Added a security consideration for the EXTERNAL mechanism. > > Clarified sections concerning success with additional data. > > Cleaned up IANA considerations/registrations and assembled them in > one place. > > Updated references and split them into Informative and Normative. > > Added text to the Security Considerations section regarding handling > of extremely large SASL blocks. > > Replaced UTF-8 ABNF with the reference to the UTF-8 document. > > Added text about SASLprep for authentication identities and > passwords. Described where SASLprep preparation should take place. > > Added paragraph about verifying authorization identities. > > Added a protocol profile requirement to specify interaction between > SASL and TLS security layers. > > Added a protocol profile requirement to specify if it supports > reauthentication. > > Removed the text that seemed to suggest that SASL security layer must > not be used when TLS is available. > > Created two subsections in 4.2 to talk separately about proxy > authorization and format of the authorization identities. > > Made requirement to verify that an authorization identity is correct > by performing SASLprep a SHOULD, instead of a MUST. > > Clarified that each SASL mechanism must decide where SASLprep is > taking place. > > Added 4 new examples for initial response and additional data with > success. > > Added text on checking the list of available SASL mechanisms after > negotiating a security layer. > > Added definition of "integrity protection" and "confidentiality > protection". > > Added warning about negotiating no layer once a security layer is > negotiated. > > Added new section with guidelines to a SASL mechanism designer. > > Added a requirement to specify how an empty initial challenge is > encoded if initial response is supported by a protocol. > > > > Status of this Memo .......................................... i > 1. Abstract ............................................... 2 > 2. Organization of this document .......................... 2 > 2.1. How to read this document .............................. 2 > 2.2. Conventions used in this document ...................... 2 > 3. Overview ............................................... 3 > 4. Authentication mechanisms .............................. 3 > 4.1. Authentication protocol exchange ....................... 4 > 4.2. Authorization and authentication identities ............ 4 > 4.2.1. Authorization identities and proxy authentication .... 5 > 4.2.2. Authorization Identity Format ........................ 6 > 4.3. Security layers ........................................ 6 > 4.4. Character string issues ................................ 7 > 5. Protocol profile requirements .......................... 7 > 5. Protocol and mechanism profiles ........................ 7 > 5.1. Protocol profile requirements .......................... 7 > 5.2. Mechanism profile guidelines ........................... 8 > 6. Specific issues ........................................ 9 > 6.1. Client sends data first ................................ 9 > 6.1.1. Examples ............................................. 9 > 6.2. Server returns success with additional data ........... 10 > 6.2.1. Examples ............................................ 10 > 6.3. Multiple authentications .............................. 12 > 6.3.1. Description of Multiple Authentication attack ....... 13 > 7. The EXTERNAL mechanism ................................ 14 > 7.1. Formal syntax ......................................... 15 > 7.2. Example ............................................... 15 > 8. IANA Considerations ................................... 15 > 8.1. Guidelines for IANA ................................... 16 > 8.2. Registration procedure ................................ 16 > 8.3. Comments on SASL mechanism registrations .............. 16 > 8.4. Change control ........................................ 17 > 8.5. Registration template ................................. 17 > 8.6. The EXTERNAL mechanism registration ................... 18 > 9. Security considerations ................................ 18 > 10. References ........................................... 20 > 10.1. Normative References ................................. 20 > 10.2. Informative References ............................... 21 > 11. Editor's Address ...................................... 21 > 12. Acknowledgments ....................................... 22 > 13. Full Copyright Statement .............................. 22 > Appendix A. Relation of SASL to transport security .......... 23 > Appendix B. Changes since RFC 2222 .......................... 24 From owner-ietf-sasl Thu Feb 26 01:03:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q93JnG036081; Thu, 26 Feb 2004 01:03:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q93JWe036079; Thu, 26 Feb 2004 01:03:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q93En8036047 for ; Thu, 26 Feb 2004 01:03:15 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AwHQI-000622-00 for ; Thu, 26 Feb 2004 10:03:14 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu Feb 26 09:03:14 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu Feb 26 09:03:14 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Thu, 26 Feb 2004 10:03:02 +0100 Lines: 47 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:pa8CHJC5cwcYNgNCXITdmEtZdww= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > So, I think your picture is not correct as it implies normalization > is a client side matter. That is not necessarily the case. The server part wasn't part of the picture, and for the client side the picture tried to imply that the normalization may be the identity function ("_Possibly_ revised authorization identity"), so I think we actually agree. >>(I prefer not to >>speculate like this, because it generate long and potentially >>irrelevant e-mails, but was asked to do so to speed up the progress of >>the draft, please bear with me.) >> >>If so, and here comes my question, if two protocol profiles uses >>different normalizations, and a mechanism is implemented by storing a >>hash of H(Username|AuthId|AuthZid) (or it works in some similar way), > > Huh? I assume you meant H(authcid|password|authzid) or something similar. Yes, sorry. > Anyways, it's bogus for the mechanism implementation to do much of > anything with the authzid, except ensuring it is transferred properly, > as its semantics are protocol specific. I think this is not clear -- and many implementations do authorization for you, all suggesting it is a service from the SASL mechanism framework. >>the mechanism appear to need to select among different password >>databases, depending on which protocol is used. > > No, it just should not include the authzid in that database. There > should be, logically, a separate database which proxy authentication > (identity assumption) policy. Note that this database likely keys > off a protocol-specific mapping of the authentication identity. That > is, off the authzid which would have been derived from the authentication > identity if no authzid has been transferred. It should be noted that > this mapping requires both knowledge of the mechanism-specific form > of the authentication identity and the protocol-specific form of the > authorization identities. This view helps. A picture with (conceptually) two databases, one mechanism specific for authentication identities and, and one protocol specific with authorization identities, would help. From owner-ietf-sasl Thu Feb 26 06:35:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QEZvAt067566; Thu, 26 Feb 2004 06:35:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QEZugu067565; Thu, 26 Feb 2004 06:35:56 -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.11/8.12.8) with ESMTP id i1QEZt4X067556 for ; Thu, 26 Feb 2004 06:35:55 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QEZmMu063798; Thu, 26 Feb 2004 14:35:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226055821.04c18980@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 06:35:40 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@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 01:03 AM 2/26/2004, Simon Josefsson wrote: >> Anyways, it's bogus for the mechanism implementation to do much of >> anything with the authzid, except ensuring it is transferred properly, >> as its semantics are protocol specific. > >I think this is not clear -- and many implementations do authorization >for you, all suggesting it is a service from the SASL mechanism >framework. I think RFC 2222 was quite clear that the form of the authorization identity is mechanism specific, and in fact, says its the protocol profiles responsibility to provide: 5. A specification of how the authorization identity passed from the client to the server is to be interpreted. This should be even clearer in the revised specification and, possibly, could be made even more clear. What some so-called SASL developers have done is provide SASL implementations which interpret the authorization identity in a fashion consistent with some set of the protocol profiles, but obviously not all possible (or even all existing) protocol profiles. I question however whether saying more actually will help. The (inherent) fact is that implementors often write with binders on (e.g., with a limited set of mechanisms and protocols in mind) and only realize their false assumptions upon attempts to adapt their work to other mechanisms/protocols. I am not saying such implementations are broken (when used in the set of protocol they were designed to support), just that they are part implementation and part implementation of a set of similar protocol profiles. It should be clear that such implementations are not readily usable in implementations of dissimilar protocol profiles. >>>the mechanism appear to need to select among different password >>>databases, depending on which protocol is used. >> >> No, it just should not include the authzid in that database. There >> should be, logically, a separate database which proxy authentication >> (identity assumption) policy. Note that this database likely keys >> off a protocol-specific mapping of the authentication identity. That >> is, off the authzid which would have been derived from the authentication >> identity if no authzid has been transferred. It should be noted that >> this mapping requires both knowledge of the mechanism-specific form >> of the authentication identity and the protocol-specific form of the >> authorization identities. > >This view helps. A picture with (conceptually) two databases, one >mechanism specific for authentication identities and, and one protocol >specific with authorization identities, would help. Maybe, but then again many readers will get confused by unnecessary elaboration. Saying more (in prose or with pictures) tends to lead to inconsistencies in the specification, which lead to different interpretations, and to interoperability problems. That is, while I don't necessarily oppose new text (and/or new pictures), I generally think the specification would be clearer if it were more concise. Kurt From owner-ietf-sasl Thu Feb 26 07:33:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QFX6FB070684; Thu, 26 Feb 2004 07:33:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QFX68S070683; Thu, 26 Feb 2004 07:33:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1QFX5rw070677 for ; Thu, 26 Feb 2004 07:33:05 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa21736; 26 Feb 2004 10:32 EST Date: Thu, 26 Feb 2004 10:32:53 -0500 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] Message-ID: <155180000.1077809573@mariner.pc.cs.cmu.edu> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, February 25, 2004 17:34:02 -0800 "Kurt D. Zeilenga" wrote: >> This separation between the definition of protocols and the >> definition of authentication mechanisms is crucial. It permits an > > I think it is the separation between (application-level) protocols > and mechanisms, not their definitions, that is crucial. > >> authentication mechanism to be defined once, making it usable by any >> SASL protocol profile. In many implementations, the same SASL >> mechanism code is used for multiple protocols. On the contrary, it is the modularity of definition that's critical. There are plenty of single-mechanism and especially single-application SASL implementations out there. I'd not be the least bit surprised to find application implementations which do their own SASL and support only one mechanism. These folks don't need a modular implementation; they don't care much about having a "SASL framework implementation" that exports one API to applications and another to mechanisms. That's nice for some of us, but not essential in every implementation. What you get from modularity of definition is that you only need N+M+1 specs, instead of N*M. If a someone invents a new mechanism, I don't have to wait for its use to be defined for my favorite application before I can start implementing it (let alone using it). Similarly, if a new application protocol comes along that I want to use, I don't have to lose because my favorite mechanism isn't popular enough for the application designers to bother specifying it. Modularity of definition also makes the security analysis easier. Not only do we collectively only have to analyze N+M+1 documents instead of N*M documents, but the analysis is simpler for each document, especially in the case of the application protocol profiles. IMHO the language is fine as it stands. -- Jeff From owner-ietf-sasl Thu Feb 26 08:20:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QGKAvI074514; Thu, 26 Feb 2004 08:20:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QGK920074513; Thu, 26 Feb 2004 08:20:10 -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.11/8.12.8) with ESMTP id i1QGK909074507 for ; Thu, 26 Feb 2004 08:20:09 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QGKAMs065621; Thu, 26 Feb 2004 16:20:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226081505.04d11fc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 08:20:02 -0800 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: <155180000.1077809573@mariner.pc.cs.cmu.edu> References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <155180000.1077809573@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Without proper separation within the SASL framework, one cannot have proper separation of protocol and mechanism specifications. The overview section should first provide an overview of the SASL framework and the abstractions involved and then state that the intent is to allow separate specification of protocol and mechanisms that framework support. Kurt At 07:32 AM 2/26/2004, Jeffrey Hutzelman wrote: >On Wednesday, February 25, 2004 17:34:02 -0800 "Kurt D. Zeilenga" wrote: > >>> This separation between the definition of protocols and the >>> definition of authentication mechanisms is crucial. It permits an >> >>I think it is the separation between (application-level) protocols >>and mechanisms, not their definitions, that is crucial. >> >>> authentication mechanism to be defined once, making it usable by any >>> SASL protocol profile. In many implementations, the same SASL >>> mechanism code is used for multiple protocols. > >On the contrary, it is the modularity of definition that's critical. >There are plenty of single-mechanism and especially single-application SASL implementations out there. I'd not be the least bit surprised to find application implementations which do their own SASL and support only one mechanism. These folks don't need a modular implementation; they don't care much about having a "SASL framework implementation" that exports one API to applications and another to mechanisms. That's nice for some of us, but not essential in every implementation. > >What you get from modularity of definition is that you only need N+M+1 specs, instead of N*M. If a someone invents a new mechanism, I don't have to wait for its use to be defined for my favorite application before I can start implementing it (let alone using it). Similarly, if a new application protocol comes along that I want to use, I don't have to lose because my favorite mechanism isn't popular enough for the application designers to bother specifying it. > >Modularity of definition also makes the security analysis easier. Not only do we collectively only have to analyze N+M+1 documents instead of N*M documents, but the analysis is simpler for each document, especially in the case of the application protocol profiles. > > >IMHO the language is fine as it stands. > >-- Jeff > From owner-ietf-sasl Thu Feb 26 11:07:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QJ71Fc083335; Thu, 26 Feb 2004 11:07:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QJ71PA083334; Thu, 26 Feb 2004 11:07:01 -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 (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QJ70tm083328 for ; Thu, 26 Feb 2004 11:07:01 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1EEE215200A; Thu, 26 Feb 2004 14:07:03 -0500 (EST) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis: multiple authentication attack References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> From: Sam Hartman Date: Thu, 26 Feb 2004 14:07:03 -0500 In-Reply-To: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 25 Feb 2004 15:08:30 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> In review of the latest draft, I've come across a number of Kurt> technical and editorial concerns which I intend to start a Kurt> number of separate threads on. This is the first. Kurt> I am particularity perplexed by the long discussion of the Kurt> "Multiple Authentication attack", an attack which only Kurt> impacts certain kinds of distributed server implementations, Kurt> which seems to overshadow higher risk, more generally Kurt> applicable attacks. I am quite concerned about the addition Kurt> of: >> The protocol profiles that allow for reauthentication SHOULD >> recommend that another security layer is negotiated once a >> security layer was installed. I actually think this text may be reasonable, but would need to think about it more. I think the assumption is that by setting up a new security layer you will end up getting new key material and thus will prevent the new server from decrypting data destined for the old server. --Sam From owner-ietf-sasl Thu Feb 26 12:08:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QK8K2f087746; Thu, 26 Feb 2004 12:08:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QK8KR8087745; Thu, 26 Feb 2004 12:08:20 -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.11/8.12.8) with ESMTP id i1QK8J8J087737 for ; Thu, 26 Feb 2004 12:08:19 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QK8NMs069057; Thu, 26 Feb 2004 20:08:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 12:08:15 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis: multiple authentication attack Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225140730.04ba6788@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 11:07 AM 2/26/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> In review of the latest draft, I've come across a number of > Kurt> technical and editorial concerns which I intend to start a > Kurt> number of separate threads on. This is the first. > > Kurt> I am particularity perplexed by the long discussion of the > Kurt> "Multiple Authentication attack", an attack which only > Kurt> impacts certain kinds of distributed server implementations, > Kurt> which seems to overshadow higher risk, more generally > Kurt> applicable attacks. I am quite concerned about the addition > Kurt> of: > >> The protocol profiles that allow for reauthentication SHOULD > >> recommend that another security layer is negotiated once a > >> security layer was installed. > > >I actually think this text may be reasonable, but would need to think >about it more. Maybe we should have a hallway discussion at IETF#59 before our session. Sunday afternoon is good for me. >I think the assumption is that by setting up a new security layer you >will end up getting new key material and thus will prevent the new >server from decrypting data destined for the old server. I don't disagree that negotiating new layers mitigated, to some degree, this attack. (I note however that this alone does not fully mitigate this class of attack.) But note that the text doesn't state a recommendation to negotiate new layers, it a statement that documents detailing a protocol's use of SASL SHOULD state a recommendation. My suggestion is to, in the security consideration section of this document, to discuss a class of similar attacks upon a class of server implementations, and then to suggest approaches which may be used in these implementations to mitigated these attacks. I, however, remain opposed to addition any implementation or specification imperative that would require/recommend all server implementations (of all protocols, or select protocol), including those which are not prone to this attack, to have to negotiate new security layers. Kurt From owner-ietf-sasl Thu Feb 26 12:18:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKINWr088392; Thu, 26 Feb 2004 12:18:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QKINuQ088391; Thu, 26 Feb 2004 12:18: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 (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKIMWA088381 for ; Thu, 26 Feb 2004 12:18:22 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A369415200A; Thu, 26 Feb 2004 15:18:26 -0500 (EST) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis: multiple authentication attack References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> From: Sam Hartman Date: Thu, 26 Feb 2004 15:18:26 -0500 In-Reply-To: <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> (Kurt D. Zeilenga's message of "Thu, 26 Feb 2004 12:08:15 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> My suggestion is to, in the security consideration section Kurt> of this document, to discuss a class of similar attacks upon Kurt> a class of server implementations, and then to suggest Kurt> approaches which may be used in these implementations to Kurt> mitigated these attacks. Sounds reasonable to me. Kurt> I, however, remain opposed to addition any implementation or Kurt> specification imperative that would require/recommend all Kurt> server implementations (of all protocols, or select Kurt> protocol), including those which are not prone to this Kurt> attack, to have to negotiate new security layers. Also reasonable. So apparently we don't disagree after all. From owner-ietf-sasl Thu Feb 26 12:44:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKiq5U089714; Thu, 26 Feb 2004 12:44:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QKiqb4089713; Thu, 26 Feb 2004 12:44:52 -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.11/8.12.8) with ESMTP id i1QKim0R089704 for ; Thu, 26 Feb 2004 12:44:51 -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 i1QKiqFK023082; Thu, 26 Feb 2004 15:44:52 -0500 Date: Thu, 26 Feb 2004 15:44:52 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> Message-ID: References: <6.0.1.1.0.20040225173049.04ce5210@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 Wed, 25 Feb 2004, Kurt D. Zeilenga wrote: > > Here are my review notes.... > Wow. Thats quite extensive. Comments on a few of your comments.. > > The sections "Overview", "Authentication Mechanisms", "Mechanism > > Profile Requirements" and "Security Considerations" cover issues that > > mechanism designers need to understand and address in designing new > > SASL mechanisms. > > > > Implementors of a protocol using this specification need the > > protocol-specific profiling information in addition to the > > information in this document. > > This implies implementors need to understand all of this document. > They should not need to read the protocol and mechanism profiling > requirements. Isn't the implication here that implemetors should be aware that there are generally at least three documents they need to read to implement any SASL profile? That is, the mechanism, the protocol profile, and the "framework" (this document). They most certainly do need to read the protcol and mechanism profiling requirements in order to have a successful implementation. > > The server SHOULD verify that a received authorization identity is in > > the correct form. > > Why isn't this a MUST? That is, how are servers to compare or > otherwise handle authorization identities which are not in correct > form? I suspect this is to allow older implementiations to remain compliant. However, I'm not sure that we're doing that at this point anyway... > > 7) If both TLS and SASL security layer are allowed to be negotiated > > by the protocol, the protocol profile MUST define in which order they > > are applied to a cleartext data sent over the connection. > > Spell TLS out on first use. We should extend this to also cover things other than just TLS (e.g. a compression layer, separate from either TLS or SASL). For example: If other transport or session layers (such as a Transport Layer Security layer or a compression layer) in addition to the SASL security layer are allowed to be negotiated by the protocol.... -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Feb 26 13:17:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLHWwr091419; Thu, 26 Feb 2004 13:17:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLHWYC091418; Thu, 26 Feb 2004 13:17: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.11/8.12.8) with ESMTP id i1QLHVbH091412 for ; Thu, 26 Feb 2004 13:17:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QLHaMs070296; Thu, 26 Feb 2004 21:17:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226130013.04e0a350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 13:17:28 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: use of the word "profile" (Was: sasl-rfc2222bis: multiple authentication attack) Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> <6.0.1.1.0.20040226112948.04dd4578@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 12:18 PM 2/26/2004, Sam Hartman wrote: >So apparently we don't disagree after all. Apparently. From this discussion, as well as other recent discussions, it seems that there might be some disagreement as to the meaning of the word "profile". I tend to use the term "protocol profile" to either refer to, in the SASL context, as: The set of items that an specification detailing a protocol use of SASL must provide. or: A protocol specification which provides these items. The following would be a use of the former: RFC 2222 provides a profile (e.g., an outline) of what an protocol specifications making use of SASL are to contain. and for the latter: RFC 2829 provides a profile of how SASL is used in LDAP. (that latter is, it seems, not perfect). I, however, try to avoid the term "profile implementation" as it's ambiguous as to whether it is are referring to the specification, such as RFC 2829, which provides the profile or an implementation of that specification. Of course, as we also are providing in this I-D a requirements for documents specifying mechanisms, the term becomes even more overloaded... Kurt From owner-ietf-sasl Thu Feb 26 13:28:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLSIHn091859; Thu, 26 Feb 2004 13:28:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLSIRq091858; Thu, 26 Feb 2004 13:28:18 -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.11/8.12.8) with ESMTP id i1QLSHRT091852 for ; Thu, 26 Feb 2004 13:28:17 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QLSKMs070440; Thu, 26 Feb 2004 21:28:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226131906.04df6c68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 13:28:12 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225173049.04ce5210@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 12:44 PM 2/26/2004, Rob Siemborski wrote: >> > The sections "Overview", "Authentication Mechanisms", "Mechanism >> > Profile Requirements" and "Security Considerations" cover issues that >> > mechanism designers need to understand and address in designing new >> > SASL mechanisms. >> > >> > Implementors of a protocol using this specification need the >> > protocol-specific profiling information in addition to the >> > information in this document. >> >> This implies implementors need to understand all of this document. >> They should not need to read the protocol and mechanism profiling >> requirements. > >Isn't the implication here that implemetors should be aware that there are >generally at least three documents they need to read to implement any SASL >profile? That is, the mechanism, the protocol profile, and the >"framework" (this document). Well, the statement implies that an implementor of a protocol needs understand what requirements placed upon ALL protocol specifications and upon ALL mechanism specifications, not just those requirements placed upon the implementor of the specifications which he is implementing. >They most certainly do need to read the protcol and mechanism profiling >requirements in order to have a successful implementation. An implementor of a specification should not need to read nor understand requirements which were intended for authors of that specifications. Kurt From owner-ietf-sasl Thu Feb 26 13:39:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLds7w092311; Thu, 26 Feb 2004 13:39:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLdsfH092310; Thu, 26 Feb 2004 13:39:54 -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.11/8.12.8) with ESMTP id i1QLdrs9092304 for ; Thu, 26 Feb 2004 13:39:53 -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 i1QLdvFK023217; Thu, 26 Feb 2004 16:39:57 -0500 Date: Thu, 26 Feb 2004 16:39:57 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] In-Reply-To: <6.0.1.1.0.20040226131906.04df6c68@127.0.0.1> Message-ID: References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <6.0.1.1.0.20040226131906.04df6c68@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, 26 Feb 2004, Kurt D. Zeilenga wrote: > >>> Implementors of a protocol using this specification need the > >>> protocol-specific profiling information in addition to the > >>> information in this document. > > > >> This implies implementors need to understand all of this document. > >> They should not need to read the protocol and mechanism profiling > >> requirements. > > > >Isn't the implication here that implemetors should be aware that there are > >generally at least three documents they need to read to implement any SASL > >profile? That is, the mechanism, the protocol profile, and the > >"framework" (this document). > > Well, the statement implies that an implementor of a protocol needs understand > what requirements placed upon ALL protocol specifications and upon ALL > mechanism specifications, not just those requirements placed upon the > implementor of the specifications which he is implementing. Wow, I think my brain just tied itself in a knot. However, let me try to restate what you said to be sure I understand: "Implementors [who write code] don't need to understand all of 2222bis" Which I'll agree with, but I'd argue that the key part of the paragraph in question is the "you need to read other documents" bit, not the "you need *all* of this document" bit -- which is not how I read the paragraph. > >They most certainly do need to read the protcol and mechanism profiling > >requirements in order to have a successful implementation. > > An implementor of a specification should not need to read nor understand > requirements which were intended for authors of that specifications. I'll agree with this, but I do not believe that is what the statement in the document is saying. Perhaps rewrite the paragraph as something closer to: Implementors of a protocol using this specification will also need a specification of a profile specific the protocol. -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Feb 26 14:21:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QMLGMK094261; Thu, 26 Feb 2004 14:21:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QMLGQP094260; Thu, 26 Feb 2004 14:21:16 -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.11/8.12.8) with ESMTP id i1QMLFFk094254 for ; Thu, 26 Feb 2004 14:21:15 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QMLJMs071040; Thu, 26 Feb 2004 22:21:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226140018.04df3500@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 14:21:11 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <6.0.1.1.0.20040226131906.04df6c68@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 01:39 PM 2/26/2004, Rob Siemborski wrote: >Implementors of a protocol using this specification will also need >a specification of a profile specific the protocol. This is somewhat better. My previous concern was with the "all of this document" part of the current statement. For the other audiences, the section is quite specific as to what portions of this document they need to read. I think we should detail what each audience should read with equal specificity. I have no objection to saying, in addition to portions of this document, they need to read the specification of the protocol they are implementing, especially those portions of that specification which fulfill the requirements placed upon that specification by this document. I note as well that it might be appropriate to note that implementors need to read and understand aspects of mechanism specifications they intend to use (regardless of whether they are implementing the mechanisms themselves or using an existing implementation) to understand, for instance, the mechanism specific authentication identity forms, the offered services, and security and other considerations. Kurt From owner-ietf-sasl Sat Feb 28 21:57:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5vogm030903; Sat, 28 Feb 2004 21:57:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1T5vore030902; Sat, 28 Feb 2004 21:57:50 -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 (MAC-0-20-e0-89-cc-d2.dhcp.ietf59.or.kr [218.37.231.156]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5vksd030878 for ; Sat, 28 Feb 2004 21:57:46 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 36CB815159C; Sun, 29 Feb 2004 00:57:51 -0500 (EST) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: SASLprep in rfc2222bis-06 References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> From: Sam Hartman Date: Sat, 28 Feb 2004 03:23:04 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 25 Feb 2004 18:16:15 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Simon" == Simon Josefsson writes: Simon> "Kurt D. Zeilenga" writes: >>> First, does 'character strings' include the authorization >>> identity? Defining the term 'character string', or at least >>> giving examples, would help. >> No. I believe the text should be clarified. Mechanisms >> should be capable of exchanging the authorization identity, but >> its handling (in particular for comparison) is specific to the >> application-level protocol which has profiled use of SASL as an >> authentication method. The authorization identity is a string; this is certainly true in 2222bis, and I believe was true in RFC 2222. I agree that the comparison and normalization of this string should be an application or protocol profile matter. It seems to me that we need to decide what the encoding of the authorization identity is either in the protocol profile or the mechanism specification. The base spec does need to be clarified to say which of these two is responsible for defining the encoding of the authorization ID. I also find that the digest-md5 spec is unclear on whether the authorization ID is UTF8 or is in some unspecified character set. Perhaps we believe that specification belongs to the protocol profile; if so we should be more explicit. Absent a good reason to do otherwise, I'd prefer that the mechanism specification define the encoding of the authorization ID. After all the mechanism must transport it. From owner-ietf-sasl Sun Feb 29 15:52:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq3Wj058266; Sun, 29 Feb 2004 15:52:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq3gt058265; Sun, 29 Feb 2004 15:52:03 -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.11/8.12.8) with ESMTP id i1TNq03m058244 for ; Sun, 29 Feb 2004 15:52:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:52:02 +0000 Message-ID: <4042462A.6070806@isode.com> Date: Mon, 01 Mar 2004 05:06:02 +0900 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: New text is authentication/authorization id description (section 4.2) 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: After the last round of discussions the section 4.2 looks like this: 4.2. Authorization and authentication identities SASL authentication deals with two identities: the authentication identity, derived from the client's authentication credentials; and the authorization identity, which is used by the server as the primary identity for making access policy decisions. The authorization identity may be an empty (zero length) string. In this case, the server derives an authorization identity from the client's authentication identity. A mechanism which is incapable of transmitting an authorization identity must be treated as if it always transmits an authorization identity of an empty string. Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Any normalization of the authorization identity is defined within each SASL protocol profile, and occurs before the authorization identity is handed to the mechanism. The mechanism may not modify (by, e.g., normalization) the authorization identity. Alexey From owner-ietf-sasl Sun Feb 29 15:52:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq4LI058281; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq4CT058275; Sun, 29 Feb 2004 15:52:04 -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.11/8.12.8) with ESMTP id i1TNq03l058244 for ; Sun, 29 Feb 2004 15:52:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:52 +0000 Message-ID: <4042445A.7080506@isode.com> Date: Mon, 01 Mar 2004 04:58:18 +0900 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: Authentication/authorization id clarification (was Re: sasl-rfc2222bis review notes [long]) References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@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: >>4.2. Authorization and authentication identities >> >> SASL authentication deals with two identities: the authorization >> identity and the authentication identity. >> >> > >I suggest the "authorization identity" and "authentication identity" >be defined here (move the below def'ns to here). I suggest defining >"authentication identity" first. Doing so, I also suggest swapping >the order of the terms in the section title and first sentence. > > Other people already suggested this and I've made the change (will post a separate message to the list). >> The transmitted >> authorization identity may be an empty string (zero length), but the >> transmitted authentication identity may not be an empty string. >> >> > >I think the latter ("but ...") part should be deleted. Nothing >says a mechanism has a "transmitted authentication identity", and >nothing (in RFC 2222) prevented a mechanism from transmitting an >empty authentication identity. Whether or not such is permissible >should be left to the mechanisms to decide. In fact, whether or >not an authentication identity is explicitly transferred between >the SASL client and server should be left the mechanism. It may >simply be implied by the client's credentials (as noted below). > I agree. >> A mechanisms which are incapable of transmitting an authorization >> identity must be treated as if it always transmits an authorization >> identity of an empty string. >> >> Authentication identity is the identity derived from the client's >> authentication credentials. >> >> The authorization identity is used by the server as the primary >> identity for making access policy decisions. >> >> >> ... >> Profiles whose authorization identities are simple >> user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile >> [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare >> these names for matching. The profiles MAY use a stringprep profile >> that is more strict than "SASLprep". 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. >> >> > >"profile" should be qualified above to refer to the protocol profile. > Done. >I think it mostly states a protocol profile requirement. But then >it includes an implementation imperative. But this is odd in that >server may not actually be required to do any preparation (the >profile might place that burden on the client). > Authorization identity is always sent from the client to the server. So the verification is always happening on the server. > > >I think the "If the preparation..." part should be reworded as >a profile requirement. That is, it should state that profiles >should detail how implementations are to behave when required >preparation fails. > >Given that, I think this can and should be moved to Section 5. > > > Alexey From owner-ietf-sasl Sun Feb 29 15:52:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq52T058284; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq5J5058283; Sun, 29 Feb 2004 15:52: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.11/8.12.8) with ESMTP id i1TNq0bL058245 for ; Sun, 29 Feb 2004 15:52:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:47 +0000 Message-ID: <40423F33.8020708@isode.com> Date: Mon, 01 Mar 2004 04:36:19 +0900 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: Simon Josefsson CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: SASLprep in rfc2222bis-06 References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225140352.04ba6fb8@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: Simon Josefsson wrote: > ... > >I think the most important modification that should be done is to >stress the relationship "authorization identity"<->"protocol profile" >and "authentication identity"<-> "mechanism". This isn't clear now, >but helps with the conceptual understanding. I wasn't aware of this >distinction after reading RFC 2222, so it appears to be something new >in 2222bis. Perhaps adding the sentences as below could help, if they >are correct (I'm not sure, correct me if not). > >Regards, >Simon > >4.2. Authorization and authentication identities > > 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. > > A mechanisms which are incapable of transmitting an authorization > identity must be treated as if it always transmits an authorization > identity of an empty string. > > Authentication identity is the identity derived from the client's > authentication credentials. Any normalization of the > authentication identity is defined by each mechanism, the profile > does not influence it. > > The authorization identity is used by the server as the primary > identity for making access policy decisions. Any normalization of > the authorization identity is defined within each SASL protocol > profile, and occur before the authorization identity is handed to > the mechanism. The mechanism may not modify (by, e.g., > normalization) the authorization identity. > I've integrated the suggested text about normalization. Alexey From owner-ietf-sasl Sun Feb 29 15:53:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNrIwH058340; Sun, 29 Feb 2004 15:53:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNrIst058338; Sun, 29 Feb 2004 15:53:18 -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.11/8.12.8) with ESMTP id i1TNq0bM058245 for ; Sun, 29 Feb 2004 15:52:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:57 +0000 Message-ID: <404245EB.6070806@isode.com> Date: Mon, 01 Mar 2004 05:04:59 +0900 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" , ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] References: <6.0.1.1.0.20040225173049.04ce5210@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: >>> The sections "Overview", "Authentication Mechanisms", "Mechanism >>> Profile Requirements" and "Security Considerations" cover issues that >>> mechanism designers need to understand and address in designing new >>> SASL mechanisms. >>> >>> Implementors of a protocol using this specification need the >>> protocol-specific profiling information in addition to the >>> information in this document. >>> >>> >>This implies implementors need to understand all of this document. >>They should not need to read the protocol and mechanism profiling >>requirements. >> >> > >Isn't the implication here that implementors should be aware that there are >generally at least three documents they need to read to implement any SASL >profile? That is, the mechanism, the protocol profile, and the >"framework" (this document). > >They most certainly do need to read the protocol and mechanism profiling >requirements in order to have a successful implementation. > I agree with Rob. >>> The server SHOULD verify that a received authorization identity is in >>> the correct form. >>> >>> >>Why isn't this a MUST? That is, how are servers to compare or >>otherwise handle authorization identities which are not in correct >>form? >> >> > >I suspect this is to allow older implementations to remain compliant. >However, I'm not sure that we're doing that at this point anyway... > Correct. If we change this to MUST, we effectively will make all existing implementations non-compliant. >>> 7) If both TLS and SASL security layer are allowed to be negotiated >>> by the protocol, the protocol profile MUST define in which order they >>> are applied to a cleartext data sent over the connection. >>> >>> >>Spell TLS out on first use. >> >> > >We should extend this to also cover things other than just TLS (e.g. a >compression layer, separate from either TLS or SASL). > >For example: > >If other transport or session layers (such as a Transport Layer Security >layer or a compression layer) in addition to the SASL security layer are >allowed to be negotiated by the protocol.... > I don't think a protocol profile can reasonably define layering of multiple things when at least one of them is not known when the protocol profile is written. So I would rather not change the description. Alexey From owner-ietf-sasl Sun Feb 29 15:52:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq55m058282; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq4Mp058276; Sun, 29 Feb 2004 15:52:04 -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.11/8.12.8) with ESMTP id i1TNq0bN058245 for ; Sun, 29 Feb 2004 15:52:03 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:52:07 +0000 Message-ID: <40424814.9050703@isode.com> Date: Mon, 01 Mar 2004 05:14:12 +0900 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: sasl-rfc2222bis review notes [long] References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@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: >>3. Overview >> > >I suggest this section be moved to immediately follow the Abstract >and be retitled "Introduction". I then suggest the section 2 >subsections be incorporated into this section. > How about the following instead: Subsection 2.2. ("Conventions used in this document") becomes section 2 [note, I will remove numbering of Abstract later on]. Subsection 2.1 ("How to read this document") is merged with section 3 and will become Introduction as suggested. ... >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, the contents of which are specific to and >> defined by the mechanism. To the protocol, the challenges and >> responses are opaque binary tokens of arbitrary length. The >> protocol's profile then specifies how these binary tokens are then >> encoded for transfer over the connection. >> >> >I suggest replacing binary tokens with octet string because: > 1) the challedge and responses must be aligned on 8-bit boundries and > 2) what (in IP) isn't binary? > 3) the challedge and responses seem not to be "tokens". > Kurt, I think we are going in circles now. If I am not mistaken, we've already used the tern octet string before (and I did like the fuzzy term "blob"). Alexey From owner-ietf-sasl Sun Feb 29 21:52:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215qXig090541; Sun, 29 Feb 2004 21:52:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i215qXS6090540; Sun, 29 Feb 2004 21:52:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215qWol090534 for ; Sun, 29 Feb 2004 21:52:32 -0800 (PST) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i215qY95021957; Sun, 29 Feb 2004 21:52:39 -0800 Received: from MAC-0-5-4e-40-cf-b0.dhcp.ietf59.or.kr (MAC-0-5-4e-40-cf-b0.dhcp.ietf59.or.kr [218.37.227.67]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i215qUWB026713 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 29 Feb 2004 21:52:33 -0800 Date: Sun, 29 Feb 2004 21:52:23 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Alexey Melnikov cc: SASL WG Subject: Re: New text is authentication/authorization id description (section 4.2) In-Reply-To: <4042462A.6070806@isode.com> Message-ID: References: <4042462A.6070806@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 Mon, 1 Mar 2004, Alexey Melnikov wrote: > After the last round of discussions the section 4.2 looks like this: Let me suggest a restructuring of this text (and some of 4.2.1 too). My main point is to remove the concept of "authentication identity" (which has been added in this revision, it doesn't appear in 2222). A secondary point is to clarify the difference between the authorization identity string sent by the client and the authorization identity derived by the server. My justification for removing "authentication identity" is that its existence is a speculative intermediate step between two concrete elements, which are the authentication credential, and the derived authorization id. Moreover, calling it an "identity" is inevitably confusing with "authorization identity" (and this stuff has already proven to be very confusing). So I'd revise this section as below. This revision also incorporates the "empty string" text that is now in 4.2.1, and would be removed from that section. (I have problems with the last two proposed paragraphs, re normalization, but I'll address those separately.) (And the use of "authentication identity" in 4.2.1 would have to be removed too.) - RL "Bob" --- 4.2. Authorization and authentication The SASL framework supports flexible mapping between authentication and authorization by defining the concept of "authorization identity" as the result of SASL processing. The processing model is as follows. A server, upon completion of the authentication mechanism, uses the results produced by the authentication mechanism, the client-provided authorization identity value (which may be the empty string), and local policy information to derive an authorization identity. The authorization identity is made available to further server processing for use in making access policy decisions. The provision of additional client attributes that may affect access policy is not covered by this specification. Note that the derivation of the authorization identity is often trivial: simply using the identifier produced by the authentication mechanism directly as the authorization identity. 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. A mechanism which is incapable of transmitting an authorization identity must be treated as if it always transmits an authorization identity of an empty string. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215qXig090541; Sun, 29 Feb 2004 21:52:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i215qXS6090540; Sun, 29 Feb 2004 21:52:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215qWol090534 for ; Sun, 29 Feb 2004 21:52:32 -0800 (PST) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i215qY95021957; Sun, 29 Feb 2004 21:52:39 -0800 Received: from MAC-0-5-4e-40-cf-b0.dhcp.ietf59.or.kr (MAC-0-5-4e-40-cf-b0.dhcp.ietf59.or.kr [218.37.227.67]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.02) with ESMTP id i215qUWB026713 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 29 Feb 2004 21:52:33 -0800 Date: Sun, 29 Feb 2004 21:52:23 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Alexey Melnikov cc: SASL WG Subject: Re: New text is authentication/authorization id description (section 4.2) In-Reply-To: <4042462A.6070806@isode.com> Message-ID: References: <4042462A.6070806@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 Mon, 1 Mar 2004, Alexey Melnikov wrote: > After the last round of discussions the section 4.2 looks like this: Let me suggest a restructuring of this text (and some of 4.2.1 too). My main point is to remove the concept of "authentication identity" (which has been added in this revision, it doesn't appear in 2222). A secondary point is to clarify the difference between the authorization identity string sent by the client and the authorization identity derived by the server. My justification for removing "authentication identity" is that its existence is a speculative intermediate step between two concrete elements, which are the authentication credential, and the derived authorization id. Moreover, calling it an "identity" is inevitably confusing with "authorization identity" (and this stuff has already proven to be very confusing). So I'd revise this section as below. This revision also incorporates the "empty string" text that is now in 4.2.1, and would be removed from that section. (I have problems with the last two proposed paragraphs, re normalization, but I'll address those separately.) (And the use of "authentication identity" in 4.2.1 would have to be removed too.) - RL "Bob" --- 4.2. Authorization and authentication The SASL framework supports flexible mapping between authentication and authorization by defining the concept of "authorization identity" as the result of SASL processing. The processing model is as follows. A server, upon completion of the authentication mechanism, uses the results produced by the authentication mechanism, the client-provided authorization identity value (which may be the empty string), and local policy information to derive an authorization identity. The authorization identity is made available to further server processing for use in making access policy decisions. The provision of additional client attributes that may affect access policy is not covered by this specification. Note that the derivation of the authorization identity is often trivial: simply using the identifier produced by the authentication mechanism directly as the authorization identity. 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. A mechanism which is incapable of transmitting an authorization identity must be treated as if it always transmits an authorization identity of an empty string. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNrIwH058340; Sun, 29 Feb 2004 15:53:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNrIst058338; Sun, 29 Feb 2004 15:53:18 -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.11/8.12.8) with ESMTP id i1TNq0bM058245 for ; Sun, 29 Feb 2004 15:52:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:57 +0000 Message-ID: <404245EB.6070806@isode.com> Date: Mon, 01 Mar 2004 05:04:59 +0900 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" , ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] References: <6.0.1.1.0.20040225173049.04ce5210@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: >>> The sections "Overview", "Authentication Mechanisms", "Mechanism >>> Profile Requirements" and "Security Considerations" cover issues that >>> mechanism designers need to understand and address in designing new >>> SASL mechanisms. >>> >>> Implementors of a protocol using this specification need the >>> protocol-specific profiling information in addition to the >>> information in this document. >>> >>> >>This implies implementors need to understand all of this document. >>They should not need to read the protocol and mechanism profiling >>requirements. >> >> > >Isn't the implication here that implementors should be aware that there are >generally at least three documents they need to read to implement any SASL >profile? That is, the mechanism, the protocol profile, and the >"framework" (this document). > >They most certainly do need to read the protocol and mechanism profiling >requirements in order to have a successful implementation. > I agree with Rob. >>> The server SHOULD verify that a received authorization identity is in >>> the correct form. >>> >>> >>Why isn't this a MUST? That is, how are servers to compare or >>otherwise handle authorization identities which are not in correct >>form? >> >> > >I suspect this is to allow older implementations to remain compliant. >However, I'm not sure that we're doing that at this point anyway... > Correct. If we change this to MUST, we effectively will make all existing implementations non-compliant. >>> 7) If both TLS and SASL security layer are allowed to be negotiated >>> by the protocol, the protocol profile MUST define in which order they >>> are applied to a cleartext data sent over the connection. >>> >>> >>Spell TLS out on first use. >> >> > >We should extend this to also cover things other than just TLS (e.g. a >compression layer, separate from either TLS or SASL). > >For example: > >If other transport or session layers (such as a Transport Layer Security >layer or a compression layer) in addition to the SASL security layer are >allowed to be negotiated by the protocol.... > I don't think a protocol profile can reasonably define layering of multiple things when at least one of them is not known when the protocol profile is written. So I would rather not change the description. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq4LI058281; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq4CT058275; Sun, 29 Feb 2004 15:52:04 -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.11/8.12.8) with ESMTP id i1TNq03l058244 for ; Sun, 29 Feb 2004 15:52:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:52 +0000 Message-ID: <4042445A.7080506@isode.com> Date: Mon, 01 Mar 2004 04:58:18 +0900 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: Authentication/authorization id clarification (was Re: sasl-rfc2222bis review notes [long]) References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@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: >>4.2. Authorization and authentication identities >> >> SASL authentication deals with two identities: the authorization >> identity and the authentication identity. >> >> > >I suggest the "authorization identity" and "authentication identity" >be defined here (move the below def'ns to here). I suggest defining >"authentication identity" first. Doing so, I also suggest swapping >the order of the terms in the section title and first sentence. > > Other people already suggested this and I've made the change (will post a separate message to the list). >> The transmitted >> authorization identity may be an empty string (zero length), but the >> transmitted authentication identity may not be an empty string. >> >> > >I think the latter ("but ...") part should be deleted. Nothing >says a mechanism has a "transmitted authentication identity", and >nothing (in RFC 2222) prevented a mechanism from transmitting an >empty authentication identity. Whether or not such is permissible >should be left to the mechanisms to decide. In fact, whether or >not an authentication identity is explicitly transferred between >the SASL client and server should be left the mechanism. It may >simply be implied by the client's credentials (as noted below). > I agree. >> A mechanisms which are incapable of transmitting an authorization >> identity must be treated as if it always transmits an authorization >> identity of an empty string. >> >> Authentication identity is the identity derived from the client's >> authentication credentials. >> >> The authorization identity is used by the server as the primary >> identity for making access policy decisions. >> >> >> ... >> Profiles whose authorization identities are simple >> user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile >> [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare >> these names for matching. The profiles MAY use a stringprep profile >> that is more strict than "SASLprep". 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. >> >> > >"profile" should be qualified above to refer to the protocol profile. > Done. >I think it mostly states a protocol profile requirement. But then >it includes an implementation imperative. But this is odd in that >server may not actually be required to do any preparation (the >profile might place that burden on the client). > Authorization identity is always sent from the client to the server. So the verification is always happening on the server. > > >I think the "If the preparation..." part should be reworded as >a profile requirement. That is, it should state that profiles >should detail how implementations are to behave when required >preparation fails. > >Given that, I think this can and should be moved to Section 5. > > > Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq52T058284; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq5J5058283; Sun, 29 Feb 2004 15:52: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.11/8.12.8) with ESMTP id i1TNq0bL058245 for ; Sun, 29 Feb 2004 15:52:01 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:51:47 +0000 Message-ID: <40423F33.8020708@isode.com> Date: Mon, 01 Mar 2004 04:36:19 +0900 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: Simon Josefsson CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: SASLprep in rfc2222bis-06 References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225140352.04ba6fb8@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: Simon Josefsson wrote: > ... > >I think the most important modification that should be done is to >stress the relationship "authorization identity"<->"protocol profile" >and "authentication identity"<-> "mechanism". This isn't clear now, >but helps with the conceptual understanding. I wasn't aware of this >distinction after reading RFC 2222, so it appears to be something new >in 2222bis. Perhaps adding the sentences as below could help, if they >are correct (I'm not sure, correct me if not). > >Regards, >Simon > >4.2. Authorization and authentication identities > > 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. > > A mechanisms which are incapable of transmitting an authorization > identity must be treated as if it always transmits an authorization > identity of an empty string. > > Authentication identity is the identity derived from the client's > authentication credentials. Any normalization of the > authentication identity is defined by each mechanism, the profile > does not influence it. > > The authorization identity is used by the server as the primary > identity for making access policy decisions. Any normalization of > the authorization identity is defined within each SASL protocol > profile, and occur before the authorization identity is handed to > the mechanism. The mechanism may not modify (by, e.g., > normalization) the authorization identity. > I've integrated the suggested text about normalization. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq55m058282; Sun, 29 Feb 2004 15:52:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq4Mp058276; Sun, 29 Feb 2004 15:52:04 -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.11/8.12.8) with ESMTP id i1TNq0bN058245 for ; Sun, 29 Feb 2004 15:52:03 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:52:07 +0000 Message-ID: <40424814.9050703@isode.com> Date: Mon, 01 Mar 2004 05:14:12 +0900 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: sasl-rfc2222bis review notes [long] References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@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: >>3. Overview >> > >I suggest this section be moved to immediately follow the Abstract >and be retitled "Introduction". I then suggest the section 2 >subsections be incorporated into this section. > How about the following instead: Subsection 2.2. ("Conventions used in this document") becomes section 2 [note, I will remove numbering of Abstract later on]. Subsection 2.1 ("How to read this document") is merged with section 3 and will become Introduction as suggested. ... >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, the contents of which are specific to and >> defined by the mechanism. To the protocol, the challenges and >> responses are opaque binary tokens of arbitrary length. The >> protocol's profile then specifies how these binary tokens are then >> encoded for transfer over the connection. >> >> >I suggest replacing binary tokens with octet string because: > 1) the challedge and responses must be aligned on 8-bit boundries and > 2) what (in IP) isn't binary? > 3) the challedge and responses seem not to be "tokens". > Kurt, I think we are going in circles now. If I am not mistaken, we've already used the tern octet string before (and I did like the fuzzy term "blob"). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TNq3Wj058266; Sun, 29 Feb 2004 15:52:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TNq3gt058265; Sun, 29 Feb 2004 15:52:03 -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.11/8.12.8) with ESMTP id i1TNq03m058244 for ; Sun, 29 Feb 2004 15:52:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (MISHA.isode.net [218.37.230.80]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 29 Feb 2004 23:52:02 +0000 Message-ID: <4042462A.6070806@isode.com> Date: Mon, 01 Mar 2004 05:06:02 +0900 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: New text is authentication/authorization id description (section 4.2) 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: After the last round of discussions the section 4.2 looks like this: 4.2. Authorization and authentication identities SASL authentication deals with two identities: the authentication identity, derived from the client's authentication credentials; and the authorization identity, which is used by the server as the primary identity for making access policy decisions. The authorization identity may be an empty (zero length) string. In this case, the server derives an authorization identity from the client's authentication identity. A mechanism which is incapable of transmitting an authorization identity must be treated as if it always transmits an authorization identity of an empty string. Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Any normalization of the authorization identity is defined within each SASL protocol profile, and occurs before the authorization identity is handed to the mechanism. The mechanism may not modify (by, e.g., normalization) the authorization identity. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5vogm030903; Sat, 28 Feb 2004 21:57:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1T5vore030902; Sat, 28 Feb 2004 21:57:50 -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 (MAC-0-20-e0-89-cc-d2.dhcp.ietf59.or.kr [218.37.231.156]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5vksd030878 for ; Sat, 28 Feb 2004 21:57:46 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 36CB815159C; Sun, 29 Feb 2004 00:57:51 -0500 (EST) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: SASLprep in rfc2222bis-06 References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> From: Sam Hartman Date: Sat, 28 Feb 2004 03:23:04 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 25 Feb 2004 18:16:15 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Simon" == Simon Josefsson writes: Simon> "Kurt D. Zeilenga" writes: >>> First, does 'character strings' include the authorization >>> identity? Defining the term 'character string', or at least >>> giving examples, would help. >> No. I believe the text should be clarified. Mechanisms >> should be capable of exchanging the authorization identity, but >> its handling (in particular for comparison) is specific to the >> application-level protocol which has profiled use of SASL as an >> authentication method. The authorization identity is a string; this is certainly true in 2222bis, and I believe was true in RFC 2222. I agree that the comparison and normalization of this string should be an application or protocol profile matter. It seems to me that we need to decide what the encoding of the authorization identity is either in the protocol profile or the mechanism specification. The base spec does need to be clarified to say which of these two is responsible for defining the encoding of the authorization ID. I also find that the digest-md5 spec is unclear on whether the authorization ID is UTF8 or is in some unspecified character set. Perhaps we believe that specification belongs to the protocol profile; if so we should be more explicit. Absent a good reason to do otherwise, I'd prefer that the mechanism specification define the encoding of the authorization ID. After all the mechanism must transport it. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QMLGMK094261; Thu, 26 Feb 2004 14:21:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QMLGQP094260; Thu, 26 Feb 2004 14:21:16 -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.11/8.12.8) with ESMTP id i1QMLFFk094254 for ; Thu, 26 Feb 2004 14:21:15 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QMLJMs071040; Thu, 26 Feb 2004 22:21:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226140018.04df3500@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 14:21:11 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <6.0.1.1.0.20040226131906.04df6c68@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 01:39 PM 2/26/2004, Rob Siemborski wrote: >Implementors of a protocol using this specification will also need >a specification of a profile specific the protocol. This is somewhat better. My previous concern was with the "all of this document" part of the current statement. For the other audiences, the section is quite specific as to what portions of this document they need to read. I think we should detail what each audience should read with equal specificity. I have no objection to saying, in addition to portions of this document, they need to read the specification of the protocol they are implementing, especially those portions of that specification which fulfill the requirements placed upon that specification by this document. I note as well that it might be appropriate to note that implementors need to read and understand aspects of mechanism specifications they intend to use (regardless of whether they are implementing the mechanisms themselves or using an existing implementation) to understand, for instance, the mechanism specific authentication identity forms, the offered services, and security and other considerations. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLds7w092311; Thu, 26 Feb 2004 13:39:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLdsfH092310; Thu, 26 Feb 2004 13:39:54 -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.11/8.12.8) with ESMTP id i1QLdrs9092304 for ; Thu, 26 Feb 2004 13:39:53 -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 i1QLdvFK023217; Thu, 26 Feb 2004 16:39:57 -0500 Date: Thu, 26 Feb 2004 16:39:57 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] In-Reply-To: <6.0.1.1.0.20040226131906.04df6c68@127.0.0.1> Message-ID: References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <6.0.1.1.0.20040226131906.04df6c68@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, 26 Feb 2004, Kurt D. Zeilenga wrote: > >>> Implementors of a protocol using this specification need the > >>> protocol-specific profiling information in addition to the > >>> information in this document. > > > >> This implies implementors need to understand all of this document. > >> They should not need to read the protocol and mechanism profiling > >> requirements. > > > >Isn't the implication here that implemetors should be aware that there are > >generally at least three documents they need to read to implement any SASL > >profile? That is, the mechanism, the protocol profile, and the > >"framework" (this document). > > Well, the statement implies that an implementor of a protocol needs understand > what requirements placed upon ALL protocol specifications and upon ALL > mechanism specifications, not just those requirements placed upon the > implementor of the specifications which he is implementing. Wow, I think my brain just tied itself in a knot. However, let me try to restate what you said to be sure I understand: "Implementors [who write code] don't need to understand all of 2222bis" Which I'll agree with, but I'd argue that the key part of the paragraph in question is the "you need to read other documents" bit, not the "you need *all* of this document" bit -- which is not how I read the paragraph. > >They most certainly do need to read the protcol and mechanism profiling > >requirements in order to have a successful implementation. > > An implementor of a specification should not need to read nor understand > requirements which were intended for authors of that specifications. I'll agree with this, but I do not believe that is what the statement in the document is saying. Perhaps rewrite the paragraph as something closer to: Implementors of a protocol using this specification will also need a specification of a profile specific the protocol. -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLSIHn091859; Thu, 26 Feb 2004 13:28:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLSIRq091858; Thu, 26 Feb 2004 13:28:18 -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.11/8.12.8) with ESMTP id i1QLSHRT091852 for ; Thu, 26 Feb 2004 13:28:17 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QLSKMs070440; Thu, 26 Feb 2004 21:28:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226131906.04df6c68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 13:28:12 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225173049.04ce5210@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 12:44 PM 2/26/2004, Rob Siemborski wrote: >> > The sections "Overview", "Authentication Mechanisms", "Mechanism >> > Profile Requirements" and "Security Considerations" cover issues that >> > mechanism designers need to understand and address in designing new >> > SASL mechanisms. >> > >> > Implementors of a protocol using this specification need the >> > protocol-specific profiling information in addition to the >> > information in this document. >> >> This implies implementors need to understand all of this document. >> They should not need to read the protocol and mechanism profiling >> requirements. > >Isn't the implication here that implemetors should be aware that there are >generally at least three documents they need to read to implement any SASL >profile? That is, the mechanism, the protocol profile, and the >"framework" (this document). Well, the statement implies that an implementor of a protocol needs understand what requirements placed upon ALL protocol specifications and upon ALL mechanism specifications, not just those requirements placed upon the implementor of the specifications which he is implementing. >They most certainly do need to read the protcol and mechanism profiling >requirements in order to have a successful implementation. An implementor of a specification should not need to read nor understand requirements which were intended for authors of that specifications. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLHWwr091419; Thu, 26 Feb 2004 13:17:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLHWYC091418; Thu, 26 Feb 2004 13:17: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.11/8.12.8) with ESMTP id i1QLHVbH091412 for ; Thu, 26 Feb 2004 13:17:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QLHaMs070296; Thu, 26 Feb 2004 21:17:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226130013.04e0a350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 13:17:28 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: use of the word "profile" (Was: sasl-rfc2222bis: multiple authentication attack) Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> <6.0.1.1.0.20040226112948.04dd4578@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 12:18 PM 2/26/2004, Sam Hartman wrote: >So apparently we don't disagree after all. Apparently. From this discussion, as well as other recent discussions, it seems that there might be some disagreement as to the meaning of the word "profile". I tend to use the term "protocol profile" to either refer to, in the SASL context, as: The set of items that an specification detailing a protocol use of SASL must provide. or: A protocol specification which provides these items. The following would be a use of the former: RFC 2222 provides a profile (e.g., an outline) of what an protocol specifications making use of SASL are to contain. and for the latter: RFC 2829 provides a profile of how SASL is used in LDAP. (that latter is, it seems, not perfect). I, however, try to avoid the term "profile implementation" as it's ambiguous as to whether it is are referring to the specification, such as RFC 2829, which provides the profile or an implementation of that specification. Of course, as we also are providing in this I-D a requirements for documents specifying mechanisms, the term becomes even more overloaded... Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKiq5U089714; Thu, 26 Feb 2004 12:44:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QKiqb4089713; Thu, 26 Feb 2004 12:44:52 -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.11/8.12.8) with ESMTP id i1QKim0R089704 for ; Thu, 26 Feb 2004 12:44:51 -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 i1QKiqFK023082; Thu, 26 Feb 2004 15:44:52 -0500 Date: Thu, 26 Feb 2004 15:44:52 -0500 (EST) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> Message-ID: References: <6.0.1.1.0.20040225173049.04ce5210@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 Wed, 25 Feb 2004, Kurt D. Zeilenga wrote: > > Here are my review notes.... > Wow. Thats quite extensive. Comments on a few of your comments.. > > The sections "Overview", "Authentication Mechanisms", "Mechanism > > Profile Requirements" and "Security Considerations" cover issues that > > mechanism designers need to understand and address in designing new > > SASL mechanisms. > > > > Implementors of a protocol using this specification need the > > protocol-specific profiling information in addition to the > > information in this document. > > This implies implementors need to understand all of this document. > They should not need to read the protocol and mechanism profiling > requirements. Isn't the implication here that implemetors should be aware that there are generally at least three documents they need to read to implement any SASL profile? That is, the mechanism, the protocol profile, and the "framework" (this document). They most certainly do need to read the protcol and mechanism profiling requirements in order to have a successful implementation. > > The server SHOULD verify that a received authorization identity is in > > the correct form. > > Why isn't this a MUST? That is, how are servers to compare or > otherwise handle authorization identities which are not in correct > form? I suspect this is to allow older implementiations to remain compliant. However, I'm not sure that we're doing that at this point anyway... > > 7) If both TLS and SASL security layer are allowed to be negotiated > > by the protocol, the protocol profile MUST define in which order they > > are applied to a cleartext data sent over the connection. > > Spell TLS out on first use. We should extend this to also cover things other than just TLS (e.g. a compression layer, separate from either TLS or SASL). For example: If other transport or session layers (such as a Transport Layer Security layer or a compression layer) in addition to the SASL security layer are allowed to be negotiated by the protocol.... -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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKINWr088392; Thu, 26 Feb 2004 12:18:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QKINuQ088391; Thu, 26 Feb 2004 12:18: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 (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QKIMWA088381 for ; Thu, 26 Feb 2004 12:18:22 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A369415200A; Thu, 26 Feb 2004 15:18:26 -0500 (EST) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis: multiple authentication attack References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> From: Sam Hartman Date: Thu, 26 Feb 2004 15:18:26 -0500 In-Reply-To: <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> (Kurt D. Zeilenga's message of "Thu, 26 Feb 2004 12:08:15 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> My suggestion is to, in the security consideration section Kurt> of this document, to discuss a class of similar attacks upon Kurt> a class of server implementations, and then to suggest Kurt> approaches which may be used in these implementations to Kurt> mitigated these attacks. Sounds reasonable to me. Kurt> I, however, remain opposed to addition any implementation or Kurt> specification imperative that would require/recommend all Kurt> server implementations (of all protocols, or select Kurt> protocol), including those which are not prone to this Kurt> attack, to have to negotiate new security layers. Also reasonable. So apparently we don't disagree after all. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QK8K2f087746; Thu, 26 Feb 2004 12:08:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QK8KR8087745; Thu, 26 Feb 2004 12:08:20 -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.11/8.12.8) with ESMTP id i1QK8J8J087737 for ; Thu, 26 Feb 2004 12:08:19 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QK8NMs069057; Thu, 26 Feb 2004 20:08:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226112948.04dd4578@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 12:08:15 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis: multiple authentication attack Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040225140730.04ba6788@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 11:07 AM 2/26/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> In review of the latest draft, I've come across a number of > Kurt> technical and editorial concerns which I intend to start a > Kurt> number of separate threads on. This is the first. > > Kurt> I am particularity perplexed by the long discussion of the > Kurt> "Multiple Authentication attack", an attack which only > Kurt> impacts certain kinds of distributed server implementations, > Kurt> which seems to overshadow higher risk, more generally > Kurt> applicable attacks. I am quite concerned about the addition > Kurt> of: > >> The protocol profiles that allow for reauthentication SHOULD > >> recommend that another security layer is negotiated once a > >> security layer was installed. > > >I actually think this text may be reasonable, but would need to think >about it more. Maybe we should have a hallway discussion at IETF#59 before our session. Sunday afternoon is good for me. >I think the assumption is that by setting up a new security layer you >will end up getting new key material and thus will prevent the new >server from decrypting data destined for the old server. I don't disagree that negotiating new layers mitigated, to some degree, this attack. (I note however that this alone does not fully mitigate this class of attack.) But note that the text doesn't state a recommendation to negotiate new layers, it a statement that documents detailing a protocol's use of SASL SHOULD state a recommendation. My suggestion is to, in the security consideration section of this document, to discuss a class of similar attacks upon a class of server implementations, and then to suggest approaches which may be used in these implementations to mitigated these attacks. I, however, remain opposed to addition any implementation or specification imperative that would require/recommend all server implementations (of all protocols, or select protocol), including those which are not prone to this attack, to have to negotiate new security layers. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QJ71Fc083335; Thu, 26 Feb 2004 11:07:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QJ71PA083334; Thu, 26 Feb 2004 11:07:01 -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 (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QJ70tm083328 for ; Thu, 26 Feb 2004 11:07:01 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1EEE215200A; Thu, 26 Feb 2004 14:07:03 -0500 (EST) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis: multiple authentication attack References: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> From: Sam Hartman Date: Thu, 26 Feb 2004 14:07:03 -0500 In-Reply-To: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 25 Feb 2004 15:08:30 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> In review of the latest draft, I've come across a number of Kurt> technical and editorial concerns which I intend to start a Kurt> number of separate threads on. This is the first. Kurt> I am particularity perplexed by the long discussion of the Kurt> "Multiple Authentication attack", an attack which only Kurt> impacts certain kinds of distributed server implementations, Kurt> which seems to overshadow higher risk, more generally Kurt> applicable attacks. I am quite concerned about the addition Kurt> of: >> The protocol profiles that allow for reauthentication SHOULD >> recommend that another security layer is negotiated once a >> security layer was installed. I actually think this text may be reasonable, but would need to think about it more. I think the assumption is that by setting up a new security layer you will end up getting new key material and thus will prevent the new server from decrypting data destined for the old server. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QGKAvI074514; Thu, 26 Feb 2004 08:20:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QGK920074513; Thu, 26 Feb 2004 08:20:10 -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.11/8.12.8) with ESMTP id i1QGK909074507 for ; Thu, 26 Feb 2004 08:20:09 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QGKAMs065621; Thu, 26 Feb 2004 16:20:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226081505.04d11fc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 08:20:02 -0800 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: sasl-rfc2222bis review notes [long] Cc: ietf-sasl@imc.org In-Reply-To: <155180000.1077809573@mariner.pc.cs.cmu.edu> References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> <155180000.1077809573@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Without proper separation within the SASL framework, one cannot have proper separation of protocol and mechanism specifications. The overview section should first provide an overview of the SASL framework and the abstractions involved and then state that the intent is to allow separate specification of protocol and mechanisms that framework support. Kurt At 07:32 AM 2/26/2004, Jeffrey Hutzelman wrote: >On Wednesday, February 25, 2004 17:34:02 -0800 "Kurt D. Zeilenga" wrote: > >>> This separation between the definition of protocols and the >>> definition of authentication mechanisms is crucial. It permits an >> >>I think it is the separation between (application-level) protocols >>and mechanisms, not their definitions, that is crucial. >> >>> authentication mechanism to be defined once, making it usable by any >>> SASL protocol profile. In many implementations, the same SASL >>> mechanism code is used for multiple protocols. > >On the contrary, it is the modularity of definition that's critical. >There are plenty of single-mechanism and especially single-application SASL implementations out there. I'd not be the least bit surprised to find application implementations which do their own SASL and support only one mechanism. These folks don't need a modular implementation; they don't care much about having a "SASL framework implementation" that exports one API to applications and another to mechanisms. That's nice for some of us, but not essential in every implementation. > >What you get from modularity of definition is that you only need N+M+1 specs, instead of N*M. If a someone invents a new mechanism, I don't have to wait for its use to be defined for my favorite application before I can start implementing it (let alone using it). Similarly, if a new application protocol comes along that I want to use, I don't have to lose because my favorite mechanism isn't popular enough for the application designers to bother specifying it. > >Modularity of definition also makes the security analysis easier. Not only do we collectively only have to analyze N+M+1 documents instead of N*M documents, but the analysis is simpler for each document, especially in the case of the application protocol profiles. > > >IMHO the language is fine as it stands. > >-- Jeff > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QFX6FB070684; Thu, 26 Feb 2004 07:33:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QFX68S070683; Thu, 26 Feb 2004 07:33:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1QFX5rw070677 for ; Thu, 26 Feb 2004 07:33:05 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa21736; 26 Feb 2004 10:32 EST Date: Thu, 26 Feb 2004 10:32:53 -0500 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: sasl-rfc2222bis review notes [long] Message-ID: <155180000.1077809573@mariner.pc.cs.cmu.edu> In-Reply-To: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> References: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, February 25, 2004 17:34:02 -0800 "Kurt D. Zeilenga" wrote: >> This separation between the definition of protocols and the >> definition of authentication mechanisms is crucial. It permits an > > I think it is the separation between (application-level) protocols > and mechanisms, not their definitions, that is crucial. > >> authentication mechanism to be defined once, making it usable by any >> SASL protocol profile. In many implementations, the same SASL >> mechanism code is used for multiple protocols. On the contrary, it is the modularity of definition that's critical. There are plenty of single-mechanism and especially single-application SASL implementations out there. I'd not be the least bit surprised to find application implementations which do their own SASL and support only one mechanism. These folks don't need a modular implementation; they don't care much about having a "SASL framework implementation" that exports one API to applications and another to mechanisms. That's nice for some of us, but not essential in every implementation. What you get from modularity of definition is that you only need N+M+1 specs, instead of N*M. If a someone invents a new mechanism, I don't have to wait for its use to be defined for my favorite application before I can start implementing it (let alone using it). Similarly, if a new application protocol comes along that I want to use, I don't have to lose because my favorite mechanism isn't popular enough for the application designers to bother specifying it. Modularity of definition also makes the security analysis easier. Not only do we collectively only have to analyze N+M+1 documents instead of N*M documents, but the analysis is simpler for each document, especially in the case of the application protocol profiles. IMHO the language is fine as it stands. -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QEZvAt067566; Thu, 26 Feb 2004 06:35:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QEZugu067565; Thu, 26 Feb 2004 06:35:56 -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.11/8.12.8) with ESMTP id i1QEZt4X067556 for ; Thu, 26 Feb 2004 06:35:55 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1QEZmMu063798; Thu, 26 Feb 2004 14:35:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040226055821.04c18980@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 26 Feb 2004 06:35:40 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@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 01:03 AM 2/26/2004, Simon Josefsson wrote: >> Anyways, it's bogus for the mechanism implementation to do much of >> anything with the authzid, except ensuring it is transferred properly, >> as its semantics are protocol specific. > >I think this is not clear -- and many implementations do authorization >for you, all suggesting it is a service from the SASL mechanism >framework. I think RFC 2222 was quite clear that the form of the authorization identity is mechanism specific, and in fact, says its the protocol profiles responsibility to provide: 5. A specification of how the authorization identity passed from the client to the server is to be interpreted. This should be even clearer in the revised specification and, possibly, could be made even more clear. What some so-called SASL developers have done is provide SASL implementations which interpret the authorization identity in a fashion consistent with some set of the protocol profiles, but obviously not all possible (or even all existing) protocol profiles. I question however whether saying more actually will help. The (inherent) fact is that implementors often write with binders on (e.g., with a limited set of mechanisms and protocols in mind) and only realize their false assumptions upon attempts to adapt their work to other mechanisms/protocols. I am not saying such implementations are broken (when used in the set of protocol they were designed to support), just that they are part implementation and part implementation of a set of similar protocol profiles. It should be clear that such implementations are not readily usable in implementations of dissimilar protocol profiles. >>>the mechanism appear to need to select among different password >>>databases, depending on which protocol is used. >> >> No, it just should not include the authzid in that database. There >> should be, logically, a separate database which proxy authentication >> (identity assumption) policy. Note that this database likely keys >> off a protocol-specific mapping of the authentication identity. That >> is, off the authzid which would have been derived from the authentication >> identity if no authzid has been transferred. It should be noted that >> this mapping requires both knowledge of the mechanism-specific form >> of the authentication identity and the protocol-specific form of the >> authorization identities. > >This view helps. A picture with (conceptually) two databases, one >mechanism specific for authentication identities and, and one protocol >specific with authorization identities, would help. Maybe, but then again many readers will get confused by unnecessary elaboration. Saying more (in prose or with pictures) tends to lead to inconsistencies in the specification, which lead to different interpretations, and to interoperability problems. That is, while I don't necessarily oppose new text (and/or new pictures), I generally think the specification would be clearer if it were more concise. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q93JnG036081; Thu, 26 Feb 2004 01:03:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q93JWe036079; Thu, 26 Feb 2004 01:03:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q93En8036047 for ; Thu, 26 Feb 2004 01:03:15 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AwHQI-000622-00 for ; Thu, 26 Feb 2004 10:03:14 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu Feb 26 09:03:14 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu Feb 26 09:03:14 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Thu, 26 Feb 2004 10:03:02 +0100 Lines: 47 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:pa8CHJC5cwcYNgNCXITdmEtZdww= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > So, I think your picture is not correct as it implies normalization > is a client side matter. That is not necessarily the case. The server part wasn't part of the picture, and for the client side the picture tried to imply that the normalization may be the identity function ("_Possibly_ revised authorization identity"), so I think we actually agree. >>(I prefer not to >>speculate like this, because it generate long and potentially >>irrelevant e-mails, but was asked to do so to speed up the progress of >>the draft, please bear with me.) >> >>If so, and here comes my question, if two protocol profiles uses >>different normalizations, and a mechanism is implemented by storing a >>hash of H(Username|AuthId|AuthZid) (or it works in some similar way), > > Huh? I assume you meant H(authcid|password|authzid) or something similar. Yes, sorry. > Anyways, it's bogus for the mechanism implementation to do much of > anything with the authzid, except ensuring it is transferred properly, > as its semantics are protocol specific. I think this is not clear -- and many implementations do authorization for you, all suggesting it is a service from the SASL mechanism framework. >>the mechanism appear to need to select among different password >>databases, depending on which protocol is used. > > No, it just should not include the authzid in that database. There > should be, logically, a separate database which proxy authentication > (identity assumption) policy. Note that this database likely keys > off a protocol-specific mapping of the authentication identity. That > is, off the authzid which would have been derived from the authentication > identity if no authzid has been transferred. It should be noted that > this mapping requires both knowledge of the mechanism-specific form > of the authentication identity and the protocol-specific form of the > authorization identities. This view helps. A picture with (conceptually) two databases, one mechanism specific for authentication identities and, and one protocol specific with authorization identities, would help. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1bXr9053250; Wed, 25 Feb 2004 17:37:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1bXDL053249; Wed, 25 Feb 2004 17:37:33 -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.11/8.12.8) with ESMTP id i1Q1bWG7053243 for ; Wed, 25 Feb 2004 17:37:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1bUMs054845; Thu, 26 Feb 2004 01:37:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225173539.04ca4028@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:37:23 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> <6.0.1.1.0.20040225170830.04ce6f88@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 05:14 PM 2/25/2004, Kurt D. Zeilenga wrote: >Hence, it is very important that where a mechanism uses the >authorization identity as input to a cryptographic function that >it uses the precise form transferred (or to be transferred) by >the mechanism. I note that DIGEST-MD5 is an example of a mechanism which uses the transferred authzid value as input to a cryptographic function. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1Y6L6053088; Wed, 25 Feb 2004 17:34:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1Y6Hk053086; Wed, 25 Feb 2004 17:34:06 -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.11/8.12.8) with ESMTP id i1Q1Y3cs053080 for ; Wed, 25 Feb 2004 17:34:03 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1Y9Ms054812 for ; Thu, 26 Feb 2004 01:34:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225173049.04ce5210@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:34:02 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: sasl-rfc2222bis review notes [long] 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: Here are my review notes.... >Network Working Group A. Melnikov >Internet Draft Editor >Document: draft-ietf-sasl-rfc2222bis-06.txt February 2004 >Obsoletes: RFC 2222 Expires in six months > > > Simple Authentication and Security Layer (SASL) > >Status of this Memo > > This document is an Internet Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet Drafts are working documents of the Internet Engineering > Task Force (IETF), its Areas, and its Working Groups. Note that > other groups may also distribute working documents as Internet > Drafts. Internet Drafts are draft documents valid for a maximum of > six months. Internet Drafts may be updated, replaced, or obsoleted > by other documents at any time. It is not appropriate to use > Internet Drafts as reference material or to cite them other than as > ``work in progress''. > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > A revised version of this draft document will be submitted to the RFC > editor as a Standards Track RFC for the Internet Community. > Discussion and suggestions for improvement are requested. > Distribution of this draft is unlimited. > > When published as an RFC this document will obsolete RFC 2222. This statement needs to be moved into the body of the document. That is, the body of the document needs to explicitly state: This document replaces RFC 2222. (see below) > > >1. Abstract The abstract need not be numbered. > The Simple Authentication and Security Layer (SASL) provides a method > for adding authentication support with an optional security layer to > connection-based protocols. As used here, the word "optional" implies that protocols MAY include security layer support. Suggest this be reworded The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-based protocols. > It also describes a structure for > authentication mechanisms. The result is an abstraction layer > between protocols and authentication mechanisms such that any SASL- > compatible authentication mechanism can be used with any SASL- > compatible protocol. > > This document describes how a SASL authentication mechanism is > structured, describes how a protocol adds support for SASL, defines > the protocol for carrying a security layer over a connection, and > defines the EXTERNAL SASL authentication mechanism. It might be better to transpose EXTERNAL and SASL here. >2. Organization of this document > >2.1. How to read this document > > This document is written to serve several different audiences, > protocol designers using this specification to support authentication > in their protocol, mechanism designers that define new SASL > mechanisms, and implementors of clients or servers for those > protocols using this specification. I suggest using a bullet list for the above. > The sections "Overview", "Authentication Mechanisms", "Protocol > Profile Requirements", "Specific Issues", and "Security > Considerations" cover issues that protocol designers need to > understand and address in profiling this specification for use in a > specific protocol. > > The sections "Overview", "Authentication Mechanisms", "Mechanism > Profile Requirements" and "Security Considerations" cover issues that > mechanism designers need to understand and address in designing new > SASL mechanisms. > > Implementors of a protocol using this specification need the > protocol-specific profiling information in addition to the > information in this document. This implies implementors need to understand all of this document. They should not need to read the protocol and mechanism profiling requirements. >2.2. Conventions used in this document > > In examples, "C:" and "S:" indicate lines sent by the client and > server respectively. > > The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" > in this document are to be interpreted as defined in "Key words for > use in RFCs to Indicate Requirement Levels" [KEYWORDS]. > > Character names in this document use the notation for code points and > names from the Unicode Standard [Unicode]. For example, the letter > "a" may be represented as either or . > > This document uses terms "integrity protection" and "confidentiality > protection". The former references to a security layer that is able > to detect data modification by using some kind of hash. However, I suggest the "by using some kind of hash" qualification be dropped. The term "integrity protection" applies to any layer which is capable of detecting data modification (regardless of whether it using some kind of hash or not). I suggest: The term "integrity protection" refers to a security layer designed to detect unauthorized data modification. > integrity protection doesn't make the data unreadable to an attacker. Suggest instead: However, integrity protection does not (by itself) prevent unauthorized disclose of the data. > Confidentiality protection is a security layer that is able to make > the data unreadable to an attacker by using encryption. Suggest: Confidentiality protection is a security layer which is designed to prevent unauthorized disclose of the data (generally through use of encryption). > Confidentiality protection usually implies integrity protection. Suggest: Confidentiality protection usually (but not necessarily) implies integrity protections. Alteratively, replace this and the above "However, .." with Both integrity protection and confidentiality are needed to achieve data security. Note that this is a paraphrased of [RFC 2828] "data security"]. Which brings up the question, why don't we just use "data integrity service" and 'data confidentiality service" as defined in RFC 2828? I think it best to avoid defining SASL-specific security terminology. Also, some note to the effect: Security layers may offer other kinds of security services. > >3. Overview I suggest this section be moved to immediately follow the Abstract and be retitled "Introduction". I then suggest the section 2 subsections be incorporated into this section. > The Simple Authentication and Security Layer (SASL) is a method for > adding authentication support to connection-based protocols. > > The SASL specification has three layers, as indicated in the diagram > below. I'm not sure I like how SASL is described in terms of protocol profiles (which is a technical specification or document) and a mechanism definition (which is a technical specification or document). Also, it seems odd to say "specifies a profile" as a profile is a specification. And the phrase "mechanism definition specifies an authentication mechanism" seems a bit circular. > At the top, a protocol definition using SASL specifies a > profile, including a command for identifying and authenticating a > user to a server and for optionally negotiating a security layer for > subsequent protocol interactions. At the bottom, a SASL mechanism > definition specifies an authentication mechanism. The SASL > framework, specified by this document, constrains the behavior of > protocol profiles and mechanisms, separating protocol from mechanism > and defining how they interact. > > SMTP Protocol LDAP Protocol Etc > Profile Profile . . . > \----- | -----/ > \ | / > SASL framework > / | \ > /----- | -----\ > EXTERNAL DIGEST-MD5 Etc > SASL mechanism SASL mechanism . . . > > This separation between the definition of protocols and the > definition of authentication mechanisms is crucial. It permits an I think it is the separation between (application-level) protocols and mechanisms, not their definitions, that is crucial. > authentication mechanism to be defined once, making it usable by any > SASL protocol profile. In many implementations, the same SASL > mechanism code is used for multiple protocols. Add another (see above) subsection which X.Y. Relationship to other documents This document obsoletes RFC 2222. It replaces all portions of RFC 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete. The GSSAPI mechanism is now separately specified [SASL-GSSAPI]. Appendix B. details changes since RFC 2222. >4. Authentication mechanisms > > SASL mechanisms are named by strings, from 1 to 20 characters in > length, consisting of ASCII [ASCII] upper-case letters, digits, > hyphens, and/or underscores. SASL mechanism names must be registered > with the Internet Assigned Numbers Authority (IANA). IETF standards > track documents may direct the IANA to reserve a portion of the SASL > mechanism namespace and may specify different registration criteria > for the reserved portion; the GSSAPI mechanism specification > [SASL-GSSAPI] does this. The above sentence should be moved in IANA considerations section. > Procedures for registering new SASL mechanisms are given in section 8. > > The "sasl-mech" production below defines the syntax of a SASL > mechanism name. This uses the Augmented Backus-Naur Form (ABNF) > notation as specified in [ABNF] and the ABNF core rules as specified > in Appendix A of the ABNF specification [ABNF]. > > sasl-mech = 1*20mech-char > mech-char = %x41-5A / DIGIT / "-" / "_" > ; mech names restricted to ASCII uppercase letters, > ; digits, "-" and "_" > I suggest this comment be replaced with: ; mech-char is restricted to "A"-"Z", "0"-"9", "-", and "_" : from ASCII character set. In the ABNF, I suggest (for consistency) replacing DIGIT, "-", and "_" with %x30-39, %x2D, and %x5F, respectively. This also avoids unnecessary reliance on a core rule (which would require the implementor to look up meaning of DIGIT). > >4.1. Authentication protocol exchange > > A SASL mechanism is responsible for conducting an authentication > protocol exchange. This consists of a series of server challenges > and client responses, the contents of which are specific to and > defined by the mechanism. To the protocol, the challenges and > responses are opaque binary tokens of arbitrary length. The > protocol's profile then specifies how these binary tokens are then > encoded for transfer over the connection. I suggest replacing binary tokens with octet string because: 1) the challedge and responses must be aligned on 8-bit boundries and 2) what (in IP) isn't binary? 3) the challedge and responses seem not to be "tokens". > After receiving an authentication command or any client response, a > server mechanism may issue a challenge, indicate failure, or indicate > completion. The server mechanism may return additional data with a > completion indication. The protocol's profile specifies how each of > these is then represented over the connection. > > After receiving a challenge, a client mechanism may issue a response > or abort the exchange. The protocol's profile specifies how each of > these is then represented over the connection. > > During the authentication protocol exchange, the mechanism performs > authentication, transmits an authorization identity (frequently known > as a userid) from the client to server, and negotiates the use of a > mechanism-specific security layer. If the use of a security layer is > agreed upon, then the mechanism must also define or negotiate the > maximum security layer buffer size that each side is able to receive. > > >4.2. Authorization and authentication identities > > SASL authentication deals with two identities: the authorization > identity and the authentication identity. I suggest the "authorization identity" and "authentication identity" be defined here (move the below def'ns to here). I suggest defining "authentication identity" first. Doing so, I also suggest swapping the order of the terms in the section title and first sentence. > The transmitted > authorization identity may be an empty string (zero length), but the > transmitted authentication identity may not be an empty string. I think the latter ("but ...") part should be deleted. Nothing says a mechanism has a "transmitted authentication identity", and nothing (in RFC 2222) prevented a mechanism from transmitting an empty authentication identity. Whether or not such is permissible should be left to the mechanisms to decide. In fact, whether or not an authentication identity is explicitly transferred between the SASL client and server should be left the mechanism. It may simply be implied by the client's credentials (as noted below). > A mechanisms which are incapable of transmitting an authorization > identity must be treated as if it always transmits an authorization > identity of an empty string. > > Authentication identity is the identity derived from the client's > authentication credentials. > > The authorization identity is used by the server as the primary > identity for making access policy decisions. > >4.2.1. Authorization identities and proxy authentication > > 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 derive authorization identities from > authentication identities. Instead, clients SHOULD provide no (or > empty) authorization identity when the user has not provided an > authorization identity. > > The server SHOULD verify that a received authorization identity is in > the correct form. Why isn't this a MUST? That is, how are servers to compare or otherwise handle authorization identities which are not in correct form? > Profiles whose authorization identities are simple > user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile > [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare > these names for matching. The profiles MAY use a stringprep profile > that is more strict than "SASLprep". 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. "profile" should be qualified above to refer to the protocol profile. I think it mostly states a protocol profile requirement. But then it includes an implementation imperative. But this is odd in that server may not actually be required to do any preparation (the profile might place that burden on the client). I think the "If the preparation..." part should be reworded as a profile requirement. That is, it should state that profiles should detail how implementations are to behave when required preparation fails. Given that, I think this can and should be moved to Section 5. >4.2.2. Authorization Identity Format > > An authorization identity is a string of zero or more Unicode > [Unicode] coded characters. The NUL character is not > permitted in authorization identities. > > The character encoding scheme used for transmitting an authorization > identity over the protocol is specified in each authentication > mechanism. All IETF-defined mechanisms MUST, and all other > mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF > policy regarding character sets and encoding schemes.) > > 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 an absent > authorization identity MUST be treated as equivalent. A mechanism > which provides an optional field for an authorization identity, > SHOULD NOT allow that field, when present, to be empty. The meaning > of the empty string as an authorization identity is described in the > previous section. > >4.3. Security layers > > If use of a security layer is negotiated by the authentication > protocol exchange, the security layer is applied to all subsequent > data sent over the connection (until another security layer is > negotiated; see also section 6.3). The security layer takes effect > immediately following the last response of the authentication > exchange for data sent by the client and the completion indication > for data sent by the server. > > Note that all SASL mechanisms that are unable to negotiate a security > layer automatically select no security layer. > > Once the security layer is in effect the protocol stream is processed > by the security layer into buffers of security encoded data. Each > buffer of security encoded data is transferred over the connection as > a stream of octets prepended with a four octet field in network byte > order that represents the length of the following buffer. The length > of the security encoded data buffer MUST be no larger than the > maximum size that was either defined in the mechanism specification > or negotiated by the other side during the authentication protocol > exchange. Upon the receipt of a data buffer which is larger than the > defined/negotiated maximal buffer size the receiver SHOULD close the > connection. This might be a sign of an attack or a buggy > implementation. > >5. Protocol and mechanism profiles > >5.1. Protocol profile requirements > > In order to use this specification, a protocol definition MUST supply > the following information: > > 1) A service name, to be selected from the IANA registry of "service" > elements for the GSSAPI host-based service name form [GSSAPI]. This > service name is made available to the authentication mechanism. > > The registry is available at the URL > . > > 2) A definition of the command to initiate the authentication > protocol exchange. This command must have as a parameter the name of > the mechanism being selected by the client. > > The command SHOULD have an optional parameter giving an initial > response. If the protocol allows for the initial response, the > protocol profile SHOULD also describe how an empty initial response > is encoded. This optional parameter allows the client to avoid a > round trip when using a mechanism which is defined to have the client > send data first. When this initial response is sent by the client > and the selected mechanism is defined to have the server start with > an initial challenge, the command fails. See section 6.1 of this > document for further information. > > 3) A definition of the method by which the authentication protocol > exchange is carried out, including how the challenges and responses > are encoded, how the server indicates completion or failure of the > exchange, how the client aborts an exchange, and how the exchange > method interacts with any line length limits in the protocol. > > The exchange method SHOULD allow the server to include an optional > data ("optional challenge") with a success notification. This allows > the server to avoid a round trip when using a mechanism which is > defined to have the server send additional data along with the > indication of successful completion. See section 6.2 of this > document for further information. > > 4) A protocol profile SHOULD specify a mechanism through which a > client may obtain the names of the SASL mechanisms available to it. > This is typically done through the protocol's extensions or > capabilities mechanism. > > 5) Identification of the octet where any negotiated security layer > starts to take effect, in both directions. > > 6) Specify if the protocol profile supports "multiple > authentications" (see section 6.3). > > 7) If both TLS and SASL security layer are allowed to be negotiated > by the protocol, the protocol profile MUST define in which order they > are applied to a cleartext data sent over the connection. Spell TLS out on first use. > 8) A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics. A protocol profile MUST specify the > form of the authorization identity (since it is protocol specific, as > opposed to the authentication identity, which is mechanism specific) > and how authorization identities are to be compared. Profiles whose > authorization identities are simple user names (e.g. IMAP [RFC 3501]) > SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] to prepare these names for matching. The > profiles MAY use a stringprep profile that is more strict than > SASLprep. > > A protocol profile SHOULD NOT attempt to amend the definition of > mechanisms or make mechanism-specific encodings. This breaks the > separation between protocol and mechanism that is fundamental to the > design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. > >5.2. Mechanism profile guidelines > > Designers of new SASL mechanism should be aware of the following > issues: > > 1) Authorization identity. Remove the "." > While some legacy mechanisms are incapable of transmitting an > authorization identity (which means that for these mechanisms the > authorization identity is always the empty string), newly defined > mechanisms SHOULD be capable of transmitting a non-empty > authorization identity. See also section 4.2. > > 2) Character string issues > > Authentication mechanisms SHOULD encode character strings in UTF-8 > [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character > sets in IETF protocols). In order to avoid interoperability problems > due to differing normalizations, when a mechanisms specifies that > character data is to be used as input to a cryptographic and/or > comparison function, the mechanism specification MUST detail how the > data is to be represented, including any normalizations or other > preparations, to ensure proper function. Designers of mechanisms > SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] where applicable. excepting authzid > The preparation can be potentially performed on the client end (upon > getting user input or retrieving a value from configuration) or on > the server end (upon receiving the value from the client, retrieving > a value from its authentication database or generating a new value in > order to store in in the authentication database). SASL mechanisms > must define which entity (or entities) must perform the preparation. > If preparation fails or results in an empty string, the entity doing > the preparation SHALL fail the authentication exchange. > > Implementation note: A server end can be represented by multiple > processes. For example, it may consist of the server process itself > that communicated with a client, and a command line utility (a server > agent) that is able to store passwords/hashes in a database that can > be later used by the server. For the server agent the requirement to > "fail the authentication exchange" should be interpreted as a > requirement to refuse to store the data in the database. > >6. Specific issues > >6.1. Client sends data first > > Some mechanisms specify that the first data sent in the > authentication protocol exchange is from the client to the server. > > If a protocol's profile permits the command which initiates an > authentication protocol exchange to contain an initial client > response, this parameter SHOULD be used with such mechanisms. > > If the initial client response parameter is not given, or if a > protocol's profile does not permit the command which initiates an > authentication protocol exchange to contain an initial client > response, then the server issues a challenge with no data. The > client's response to this challenge is then used as the initial > client response. (The server then proceeds to send the next > challenge, indicates completion, or indicates failure.) > >6.1.1. Client sends data first examples > > The following are two examples of an SECURID authentication [SASL- > SECURID] in the SMTP protocol [SMTP]. In the first example below, > the client is trying fast reauthentication by sending the initial > response: > > S: 220-smtp.example.com ESMTP Server > C: EHLO client.example.com > S: 250-smtp.example.com Hello client.example.com, pleased to meet you This line is too long. Suggest you s/Hello.*/Welcome client.example.com/ > S: 250-AUTH GSSAPI SECURID > S: 250 DSN > C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= > S: 235 Authentication successful > > The example below is almost identical to the previous, but here the > client chooses not to use the initial response parameter. > > S: 220-smtp.example.com ESMTP Server > C: EHLO client.example.com > S: 250-smtp.example.com Hello client.example.com, pleased to meet you This line is too long. > S: 250-AUTH GSSAPI SECURID > S: 250 DSN > C: AUTH SECURID > S: 334 > C: AG1hZ251cwAxMjM0NTY3OAA= > S: 235 Authentication successful > > Section 7.2 contains an additional example. Indention is off here. Also note that 7.2 provides two examples as does 6.2.1. So, this should read: Additonal examples can be found in sections 6.2.1 and 7.2. >6.2. Server returns success with additional data > > Some mechanisms may specify that additional data be sent to the > client along with an indication of successful completion of the > exchange. This data would, for example, authenticate the server to > the client. > > If a protocol's profile does not permit this additional data to be > returned with a success indication, then the server issues the data > as a server challenge, without an indication of successful > completion. The client then responds with no data. After receiving > this empty response, the server then indicates successful completion > (with no additional data). > > Client implementors should be aware of an additional failure case > that might occur when the profile supports sending the additional > data with success. Imagine that an active attacker is trying to > impersonate the server and sends faked data, which should be used to > authenticate the server to the client, with success. (A similar > situation can happen when either the server and/or the client has a > bug and they calculate different responses.) After checking the data, > the client will think that the authentication exchange has failed, > however the server will think that the authentication exchange has > completed successfully. At this point the client can not abort the > authentication exchange; it SHOULD close the connection instead. > However, if the profile did not support sending of additional data > with success, the client could have aborted the exchange at the very > last step of the authentication exchange. > >6.2.1. Server returns success with additional data examples > > The following are two examples of a DIGEST-MD5 authentication [SASL- > DIGEST] in the XMPP protocol [XMPP]. In the first example below, the > server is sending mutual authentication data with success. spell XMPP out on first use. > > C: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > to='example.com' > version='1.0'> > S: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > id='c2s_234' > from='example.com' > version='1.0'> > S: > > DIGEST-MD5 > CRAM-MD5 > > > C: mechanism='DIGEST-MD5'/> > S: > cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi This line is too long... > LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== > > C: > dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i > T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw > MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i > LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo > YXJzZXQ9dXRmLTgK > > S: > cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= > > > The example below is almost identical to the previous, but here > the server chooses not to use the additional data with success. > > C: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > to='example.com' > version='1.0'> > S: xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > id='c2s_234' > from='example.com' > version='1.0'> > S: > > DIGEST-MD5 > CRAM-MD5 > > > C: mechanism='DIGEST-MD5'/> > S: > cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi This line is too long. > LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== > > C: > dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i > T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw > MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i > LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo > YXJzZXQ9dXRmLTgK > > S: > cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= > > C: > S: > >6.3. Multiple authentications > > Unless otherwise stated by the protocol's profile, only one > successful SASL negotiation may occur in a protocol session. In this > case, once an authentication protocol exchange has successfully > completed, further attempts to initiate an authentication protocol > exchange fail. > 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 remains in effect. > > Note that keeping the original security layer is a subject to a class > of security attack described in section 6.3.1. I think this note should be deleted. We haven't inserted notes for other security attacks. And we've covered this with a far more general security consideration. The description itself, which I don't think is terrible useful (have such a long description over such a minor security issue distracts attention from major security issues which have little to no description). I think section 6.3.1 (and this paragraph, especially given the need to further detail the limited effectiveness of the below SHOULD) should be deleted. > However, at the time > of the writing of this document the Working Group consensus is not to > change SASL handling of security layers, as the risk of such attacks > is considered to be low and specific to only certain classes of > implementations. The protocol profiles that allow for > reauthentication SHOULD recommend that another security layer is > negotiated once a security layer was installed. I don't believe there is sufficient reason to state this as a SHOULD upon protocols profiles. As noted, it is only specific to a certain class of implementations. As previously discussed in the WG, this can and should be addressed through a security consideration stating that implementations within this class takes steps, such as enforcing a local policy disallowing subsequent authentication, to mitigate this risk. The security consideration description seems to be sufficiently address this risk. I suggest we focus discussion on this (the stated security consideration). (Also, note that simply reauthenticating with another security layer does fully mitigate the risk as the subsequent authentication is operating over the old layers. If we state this SHOULD, then we'd have to also state a security consideration noting that it ineffective in some cases.) > 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. I suggest this be replaced with: Where a protocol profile does permit multiple successful SASL negotiations, the profile MUST detail the effect of a failed SASL negotiation upon the previously established authentication state. In particular, it MUST state whether the previously established authenticated state remain in force or whether the connection is to revert to an non-authenticated state. Regardless of the specified effect upon authentication state, the previously negotiated security layer remains in effect. >6.3.1. Description of Multiple Authentication attack > > Let's assume that the protected resources on a server are partitioned > into a set of protection spaces, each with its own authentication > mechanisms and/or authorization database. Let's use the term > "partition" to reference any such protected space. An example of a > partition might be an HTTP "realm". Also a proxy/frontend can use > different partitions for different servers/backends it represents. > > Now consider the following scenario. A client has already > authenticated and established a security layer with "Partition A" > which is managed by the server AA. Now the same client authenticates > to "Partition B" (managed by the server BB) without negotiating a new > security layer, while the security layer negotiated with "Partition > A" remains in effect. The server BB is now able to observe how known > cleartext is encrypted. This scenario enables the server BB to make > guesses about previously observed ciphertext between the client and > the server AA using the server's SASL engine as an oracle. This > scenario is illustrated below: > > > +---------+ +---------+ > | | | | > |Partition| |Partition| > | B | | A | > +---------+ +---------+ > | ^ | > | : +-----------+ | > Traffic from | : | Encryption| | Traffic from A > B to client +-------->| end point |<-------+ to client > : | (SSL/SASL)| > : +-----------+ > : | > : | > : +---+ > : | | > : | | > : | | Encryption tunnel, e.g. SASL or SSL, > : | | between the server > (1) Recording +---------:| | and a single client only. > encrypted | | Separate tunnels to different > traffic between | | clients. > Partition A and client +---+ > | > | > +-----------> Traffic to clients > > < > > Where this situation cannot be managed through trust relationship, it > may be appropriate for the server implementation to not support > multiple authentications. >> > > > >7. The EXTERNAL mechanism > > The mechanism name associated with external authentication is > "EXTERNAL". > > The client sends an initial response with the UTF-8 encoding of the > authorization identity. The form of the authorization identity is > further restricted by the application-level protocol's SASL profile. > > The server uses information, external to SASL, to determine whether > the client is authorized to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > > > >A. Melnikov FORMFEED[Page 14] > > > > > >Internet DRAFT SASL 14 February 2004 > > > server indicates failure. > > The system providing this external information may be, for example, > IPSec or TLS. Spell IPsec out on first use. > However, the client can make no assumptions as to what > information the server can use in determining client authorization. > For example, just because TLS was established, doesn't mean that the > server will use the information provided by TLS. > > If the client sends the empty string as the authorization identity, > the authorization identity is to be derived from authentication > credentials which exist in the system that is providing the external > authentication. > >7.1. Formal syntax > > The following syntax specification uses the augmented Backus-Naur > Form (BNF) notation as specified in [ABNF]. This uses the ABNF core > rules as specified in Appendix A of the ABNF specification [ABNF]. I don't believe any Appendix A core rules are used here. > Non-terminals referenced but not defined below are as defined by > [UTF-8]. I suggest the non-terminal productions be directly incorporated into this document. > The "extern-init-resp" rule below defines the initial response sent > from client to server. > > extern-init-resp = *( UTF8-char-no-nul ) > > UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 > > UTF8-1-no-nul = %x01-7F > > >7.2. Example > > The following is an example of an EXTERNAL authentication in the SMTP > protocol [SMTP]. In this example, the client is proxy > authenticating, sending the authorization identity "fred" using in > the (optional) initial response. The server has determined the > client's identity through IPsec and has a security policy that > permits that identity to proxy authenticate as any other identity. An informative reference for IPsec seems appropriate here as presently worded. Suggest it be reworded, The server has obtained the client's (authentication) identity from an external service, such as IPsec, and has a security policy that permits that identity to assume the identity of the asserted authorization identity. > To the protocol profile, the four octet sequence "fred" is an opaque > binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies > that server challenges and client responses are encoded in BASE64 > [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==". > > S: 220 smtp.example.com ESMTP server ready > C: EHLO jgm.example.com > S: 250-smtp.example.com > > > >A. Melnikov FORMFEED[Page 15] > > > > > >Internet DRAFT SASL 14 February 2004 > > > S: 250 AUTH DIGEST-MD5 EXTERNAL > C: AUTH EXTERNAL ZnJlZA== > S: 235 Authentication successful. > > The following example is almost identical to the one above, but the > client doesn't use proxy authentication. s/use/request/ > S: 220 smtp.example.com ESMTP server ready > C: EHLO jgm.example.com > S: 250-smtp.example.com > S: 250 AUTH DIGEST-MD5 EXTERNAL > C: AUTH EXTERNAL > S: 235 Authentication successful. > > >8. IANA Considerations > >8.1. Guidelines for IANA > > It is requested that IANA updates the SASL mechanisms registry as > follows: > > Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism > registrations to OBSOLETE. Change the "Published specification" > of the EXTERNAL mechanism to this document. Updated registration > is provided in Section 8.6. s/registration/registration information/ > >8.2. Registration procedure > > > Registration of a SASL mechanism is done by filling in the template > in section 8.5 and sending it via electronic mail to . > IANA has the right to reject obviously bogus registrations, but will > perform no review of claims made in the registration form. SASL > mechanism registrations are currently available at the URL > . > > There is no naming convention for SASL mechanisms; any name that > conforms to the syntax of a SASL mechanism name can be registered. > An IETF Standards Track document may reserve a portion of the SASL > mechanism namespace ("family of SASL mechanisms") for its own use, > amending the registration rules for that portion of the namespace. > Each family of SASL mechanisms MUST be identified by a prefix. > > While the registration procedures do not require it, authors of SASL > > > >A. Melnikov FORMFEED[Page 16] > > > > > >Internet DRAFT SASL 14 February 2004 > > > mechanisms are encouraged to seek community review and comment > whenever that is feasible. Authors may seek community review by > posting a specification of their proposed mechanism as an Internet- > Draft. SASL mechanisms intended for widespread use should be > standardized through the normal IETF process, when appropriate. > >8.3. Comments on SASL mechanism registrations > > Comments on registered SASL mechanisms should first be sent to the > "owner" of the mechanism and/or to the SASL WG mailing list. > Submitters of comments may, after a reasonable attempt to contact the > owner, request IANA to attach their comment to the SASL mechanism > registration itself. If IANA approves of this, the comment will be > made accessible in conjunction with the SASL mechanism registration > itself. > >8.4. Change control > > Once a SASL mechanism registration has been published by IANA, the > author may request a change to its definition. The change request > follows the same procedure as the registration request. > > The owner of a SASL mechanism may pass responsibility for the SASL > mechanism to another person or agency by informing IANA; this can be > done without discussion or review. > > The IESG may reassign responsibility for a SASL mechanism. The most > common case of this will be to enable changes to be made to > mechanisms where the author of the registration has died, moved out > of contact or is otherwise unable to make changes that are important > to the community. > > SASL mechanism registrations may not be deleted; mechanisms which are > no longer believed appropriate for use can be declared OBSOLETE by a > change to their "intended use" field; such SASL mechanisms will be > clearly marked in the lists published by IANA. > > The IESG is considered to be the owner of all SASL mechanisms which > are on the IETF standards track. > >8.5. Registration template > > > Subject: Registration of SASL mechanism X > > Family of SASL mechanisms: (YES or NO) > > SASL mechanism name (or prefix for the family): > > > >A. Melnikov FORMFEED[Page 17] > > > > > >Internet DRAFT SASL 14 February 2004 > > > Security considerations: > > Published specification (optional, recommended): > > Person & email address to contact for further information: > > Intended usage: > > (One of COMMON, LIMITED USE or OBSOLETE) > > Owner/Change controller: > > (Any other information that the author deems interesting may be > added below this line.) > > >8.6. The EXTERNAL mechanism registration > > It is requested that the SASL Mechanism registry [IANA-SASL] entry > for the EXTERNAL mechanism be updated to reflect that this document > now provides its technical specification. > > > Subject: Updated Registration of SASL mechanism EXTERNAL > > Family of SASL mechanisms: NO > > SASL mechanism name: EXTERNAL > > Security considerations: See RFC XXXX, section 9. > > Published specification (optional, recommended): RFC XXXX > > Person & email address to contact for further information: > Alexey Melnikov > > Intended usage: COMMON > > Owner/Change controller: IESG > > Note: Updates existing entry for EXTERNAL > >9. Security considerations > > Security issues are discussed throughout this memo. > > The mechanisms that support integrity protection are designed such > that the negotiation of the security layer and authorization identity > is integrity protected. This statement seems a bit circular. Also, "integrity protection" was defined as providing the capability to detection unauthorized changes to data transfered by the security layer. However this uses the term implies that the authentication exchange, including layer negotiation is protected. This is problematic. If we look at DIGEST-MD5, which does offer a security layer with "integrity protection", we find a mechanism which does provide full integrity protection over the authentication exchange itself. I think we need to a bit more precise with our terminology. To avoid having to define a SASL-specific terminology, I strongly recommend we try to use RFC 2828 based terminology. When the client selects a security layer > with at least integrity protection, this protects against an active > attacker hijacking the connection and modifying the authentication > exchange to negotiate a plaintext connection. > > When a server or client supports multiple authentication mechanisms, > each of which has a different security strength, it is possible for > an active attacker to cause a party to use the least secure mechanism > supported. To protect against this sort of attack, a client or > server which supports mechanisms of different strengths should have a > configurable minimum strength that it will use. It is not sufficient > for this minimum strength check to only be on the server, since an > active attacker can change which mechanisms the client sees as being > supported, causing the client to send authentication credentials for > its weakest supported mechanism. > > The client's selection of a SASL mechanism is done in the clear and > may be modified by an active attacker. It is important for any new > SASL mechanisms to be designed such that an active attacker cannot > obtain an authentication with weaker security properties by modifying > the SASL mechanism name and/or the challenges and responses. > > In order to detect Man-in-the-middle (MITM) attacks the client MAY > list available SASL mechanisms 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. 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 (or don't support listing of SASL mechanisms once > authentication is complete); for these protocols clients MUST NOT > treat an empty list of SASL mechanisms after authentication as a MITM > attack. > > Any protocol interactions prior to authentication are performed in > the clear and may be modified by an active attacker. In the case > where a client selects integrity protection, it is important that any > security-sensitive protocol negotiations be performed after > authentication is complete. Protocols should be designed such that > negotiations performed prior to authentication should be either > ignored or revalidated once authentication is complete. > > When use of a security layer is negotiated by the authentication > protocol exchange, the receiver should handle gracefully any security > encoded data buffer larger than the defined/negotiated maximal size. > In particular, it must not blindly allocate the amount of memory > specified in the buffer size field, as this might cause the "out of > memory" condition. If the receiver detects a large block, it SHOULD > close the connection. > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. It should be > noted that, where those secrets are used to provide data > confidentiality protections, if a third party (other than the > discloser/disclosee) has knowledge of some portion of the protected > information, it can use this knowledge in an attack upon other > portions of the protected information. > > Section 6.3.1 contains a description of a potential class of attack > on a distributed server implementation. The section also gives some > recommendations about mitigating such attacks. Replace with (and append to preceding paragraph): It may be appropriate for a server to disallow all re-authentication, or re-authentications which do not result in new security layers being established, involving non- (or insufficiently) trusted parties. In some cases, it may be appropriate for the server to require separate connections to access information in different protected information spaces. > "stringprep" and Unicode security considerations apply to > authentication identities, authorization identities and passwords. > > The EXTERNAL mechanism provides no security protection; it is > vulnerable to spoofing by either client or server, active attack, and > eavesdropping. It should only be used when external security > mechanisms are present and have sufficient strength. > >10. References > >10.1. Normative References > > [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997 > > [ASCII] American National Standards Institute, "Code Extension > Techniques for Use with the 7-bit Coded Character Set of American > National Standard Code (ASCII) for Information Interchange", FIPS PUB > 35, 1974 > > [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and > Languages", RFC 2277, BCP 18, January 1998 > > [GSSAPI] Linn, J., "Generic Security Service Application Program > Interface, Version 2, Update 1", RFC 2743, January 2000 > > [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - > Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. This reference is never used and hence should be deleted. > [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", RFC 2119, BCP 19, March 1997 > > [Unicode] The Unicode Consortium, "The Unicode Standard, Version > 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, > MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the > "Unicode Standard Annex #27: Unicode 3.1" > (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard > Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). > > [Stringprep] Hoffman, P., Blanchet, M., "Preparation of > Internationalized Strings ("stringprep")", RFC 3454, December 2002. > > [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names > and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. > > [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", > RFC 3629, STD 63, November 2003. > >10.2. Informative References > > [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in > progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 > > [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest > Authentication as a SASL Mechanism", work in progress, draft-ietf- > sasl-rfc2831bis-XX.txt, replaces RFC 2831 > > [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC > 2444, October 1998. > > [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC > 2808, April 2000. > > [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April > 2001. > > [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", > RFC 2554, March 1999. > > Being revised by Siemborski, R., "SMTP Service Extension for > Authentication", work in progress, draft-siemborski-rfc2554bis- > XX.txt. This reference should be put into proper form. > > [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol > (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data > > > >A. Melnikov FORMFEED[Page 21] > > > > > >Internet DRAFT SASL 14 February 2004 > > > Encodings", RFC 3548, July 2003. > > [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC > Authors", RFC 2223, October 1997. > > [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) > MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. > >11. Editor's Address > > Alexey Melnikov > Isode Limited > > Email: Alexey.Melnikov@isode.com > >12. Acknowledgments > > This document is a revision of RFC 2222 written by John G. Myers. He > also contributed significantly to this revision. > > Magnus Nystrom provided the ASCII art used in Section 6.3. > > Definition of partition was extracted from RFC 2617 ("HTTP > Authentication: Basic and Digest Access Authentication"). > > Contributions of many members of the SASL mailing list are gratefully > acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob > Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen and > Abhijit Menon-Sen for proofreading the document and various editorial > suggestions. Suggest you drop middle initials. Needs IPR notice. > >13. Full Copyright Statement > > Copyright (C) The Internet Society (2004). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > >Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > >Appendix A. Relation of SASL to transport security > > Questions have been raised about the relationship between SASL and > various services (such as IPsec and TLS) which provide a secured > connection. > > Two of the key features of SASL are: > > The separation of the authorization identity from the identity in > the client's credentials. This 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. > > Upon successful completion of an authentication exchange, the > server knows the authorization identity the client wishes to use. > This allows servers to move to a "user is authenticated" state in > the protocol. > > These features are extremely important to some application protocols, > yet Transport Security services do not always provide them. To > define SASL mechanisms based on these services would be a very messy > task, as the framing of these services would be redundant with the > framing of SASL and some method of providing these important SASL > features would have to be devised. > > Sometimes it is desired to enable within an existing connection the > use of a security service which does not fit the SASL model. (TLS is > an example of such a service.) This can be done by adding a command, > for example "STARTTLS", to the protocol. Such a command is outside > the scope of SASL, and should be different from the command which > starts a SASL authentication protocol exchange. > > In certain situations, it is reasonable to use SASL underneath one of > these Transport Security services. The transport service would > secure the connection, either service would authenticate the client, > and SASL would negotiate the authorization identity. The SASL > negotiation would be what moves the protocol from "unauthenticated" > to "authenticated" state. The "EXTERNAL" SASL mechanism is > explicitly intended to handle the case where the transport service > secures the connection and authenticates the client and SASL > negotiates the authorization identity. > >Appendix B. Changes since RFC 2222 > > The GSSAPI mechanism was removed. It is now specified in a separate > document [SASL-GSSAPI]. > > The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has > been removed. > > The "SKEY" mechanism described in RFC 2222 is obsolete and has been > removed. It has been replaced by the OTP mechanism [SASL-OTP]. > > The overview has been substantially reorganized and clarified. > > Clarified the definition and semantics of the authorization identity. > > Prohibited the NUL character in authorization identities. > > Added a section on character string issues. > > The word "must" in the first paragraph of the "Protocol profile > requirements" section was changed to "MUST". > > Specified that protocol profiles SHOULD provide a way for clients to > discover available SASL mechanisms. > > Made the requirement that protocol profiles specify the semantics of > the authorization identity optional to the protocol profile. > Clarified that such a specification is a refinement of the definition > in the base SASL spec. > > Added a requirement discouraging protocol profiles from breaking the > separation between protocol and mechanism. > > Mentioned that standards track documents may carve out their own > portions of the SASL mechanism namespace and may amend registration > rules for the portion. However registration of individual SASL > mechanisms is still required. > > Specified that the authorization identity in the EXTERNAL mechanism > is encoded in UTF-8. > > Added a statement that a protocol profile SHOULD allow challenge data > to be sent with a success indication. > > Added a security consideration for the EXTERNAL mechanism. > > Clarified sections concerning success with additional data. > > Cleaned up IANA considerations/registrations and assembled them in > one place. > > Updated references and split them into Informative and Normative. > > Added text to the Security Considerations section regarding handling > of extremely large SASL blocks. > > Replaced UTF-8 ABNF with the reference to the UTF-8 document. > > Added text about SASLprep for authentication identities and > passwords. Described where SASLprep preparation should take place. > > Added paragraph about verifying authorization identities. > > Added a protocol profile requirement to specify interaction between > SASL and TLS security layers. > > Added a protocol profile requirement to specify if it supports > reauthentication. > > Removed the text that seemed to suggest that SASL security layer must > not be used when TLS is available. > > Created two subsections in 4.2 to talk separately about proxy > authorization and format of the authorization identities. > > Made requirement to verify that an authorization identity is correct > by performing SASLprep a SHOULD, instead of a MUST. > > Clarified that each SASL mechanism must decide where SASLprep is > taking place. > > Added 4 new examples for initial response and additional data with > success. > > Added text on checking the list of available SASL mechanisms after > negotiating a security layer. > > Added definition of "integrity protection" and "confidentiality > protection". > > Added warning about negotiating no layer once a security layer is > negotiated. > > Added new section with guidelines to a SASL mechanism designer. > > Added a requirement to specify how an empty initial challenge is > encoded if initial response is supported by a protocol. > > > > Status of this Memo .......................................... i > 1. Abstract ............................................... 2 > 2. Organization of this document .......................... 2 > 2.1. How to read this document .............................. 2 > 2.2. Conventions used in this document ...................... 2 > 3. Overview ............................................... 3 > 4. Authentication mechanisms .............................. 3 > 4.1. Authentication protocol exchange ....................... 4 > 4.2. Authorization and authentication identities ............ 4 > 4.2.1. Authorization identities and proxy authentication .... 5 > 4.2.2. Authorization Identity Format ........................ 6 > 4.3. Security layers ........................................ 6 > 4.4. Character string issues ................................ 7 > 5. Protocol profile requirements .......................... 7 > 5. Protocol and mechanism profiles ........................ 7 > 5.1. Protocol profile requirements .......................... 7 > 5.2. Mechanism profile guidelines ........................... 8 > 6. Specific issues ........................................ 9 > 6.1. Client sends data first ................................ 9 > 6.1.1. Examples ............................................. 9 > 6.2. Server returns success with additional data ........... 10 > 6.2.1. Examples ............................................ 10 > 6.3. Multiple authentications .............................. 12 > 6.3.1. Description of Multiple Authentication attack ....... 13 > 7. The EXTERNAL mechanism ................................ 14 > 7.1. Formal syntax ......................................... 15 > 7.2. Example ............................................... 15 > 8. IANA Considerations ................................... 15 > 8.1. Guidelines for IANA ................................... 16 > 8.2. Registration procedure ................................ 16 > 8.3. Comments on SASL mechanism registrations .............. 16 > 8.4. Change control ........................................ 17 > 8.5. Registration template ................................. 17 > 8.6. The EXTERNAL mechanism registration ................... 18 > 9. Security considerations ................................ 18 > 10. References ........................................... 20 > 10.1. Normative References ................................. 20 > 10.2. Informative References ............................... 21 > 11. Editor's Address ...................................... 21 > 12. Acknowledgments ....................................... 22 > 13. Full Copyright Statement .............................. 22 > Appendix A. Relation of SASL to transport security .......... 23 > Appendix B. Changes since RFC 2222 .......................... 24 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1ECFS051629; Wed, 25 Feb 2004 17:14:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q1ECrM051627; Wed, 25 Feb 2004 17:14:12 -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.11/8.12.8) with ESMTP id i1Q1EBSt051620 for ; Wed, 25 Feb 2004 17:14:11 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1Q1E8Ms054515; Thu, 26 Feb 2004 01:14:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225170830.04ce6f88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 17:14:01 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@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: It's my view that the mechanism provides method for transferring an string representing the authorization identity. Not only is the form of this authorization identity protocol specification, but how to compare two authorization identities is a matter of the protocol specification. The protocol specification must detail where any normalization (in the broadest sense) is to be done. It could be done on the client side, or the server side, or a combination. Hence, it is very important that where a mechanism uses the authorization identity as input to a cryptographic function that it uses the precise form transferred (or to be transferred) by the mechanism. That is, any and all client side normalization (per the protocol profile) of the authzid must occur before input to the function and no server side normalization (per the protocol profile) of the authzid must occur before input to the function. From the protocol perspective, user provided authzid -> client side normalization -> transfer by mechanism -> server side normalization -> use From a mechanism perspective, the protocol normalization (if any) that is occurring is irrelevant as it's only responsible for its transfer. If the mechanism does do anything with the authorization identity, such as inputs into a cryptographic function, it MUST use the value as transferred. So, I think your picture is not correct as it implies normalization is a client side matter. That is not necessarily the case. At 03:45 PM 2/25/2004, Simon Josefsson wrote: >Below is an image of how I perceive the normalization in rfc2222bis is >intended to work, after extrapolating how Kurt's suggestions will be >applied to the next version of the document. The requirement on >mechanisms is to transport F(AuthZId) unmodified to the server. >Profiles may normalize the AuthZId however they want, including at the client and/or the server. >and mechanism >may normalize authentication identities however they want. including at the client and/or the server. >Mechanism >may not normalize the authorization further (even for internal >cryptographic processing). Is this correct? Yes. mechanisms are responsible only for transferring the a string which represents, in an protocol specific manner, the authorization identity. >(I prefer not to >speculate like this, because it generate long and potentially >irrelevant e-mails, but was asked to do so to speed up the progress of >the draft, please bear with me.) > >If so, and here comes my question, if two protocol profiles uses >different normalizations, and a mechanism is implemented by storing a >hash of H(Username|AuthId|AuthZid) (or it works in some similar way), Huh? I assume you meant H(authcid|password|authzid) or something similar. Anyways, it's bogus for the mechanism implementation to do much of anything with the authzid, except ensuring it is transferred properly, as its semantics are protocol specific. The mechanism implementation should likely have stored H(authcid|password) instead. >the mechanism appear to need to select among different password >databases, depending on which protocol is used. No, it just should not include the authzid in that database. There should be, logically, a separate database which proxy authentication (identity assumption) policy. Note that this database likely keys off a protocol-specific mapping of the authentication identity. That is, off the authzid which would have been derived from the authentication identity if no authzid has been transferred. It should be noted that this mapping requires both knowledge of the mechanism-specific form of the authentication identity and the protocol-specific form of the authorization identities. Of course, implementations might actual use other forms of identities for access control and other policy decisions... (meaning there may additional identity mappings going on). Kurt >Implementation wise, >the mechanism must know which protocol is used to select the correct >database. If this is not done, there is the question of which >normalization to use when the server compute H(U|A|Az) when storing it >in the database. If only one of the protocol normalization steps is >used, then it won't work with the other protocol. If both >normalizations are stored, without the information on what protocol is >used for each hash, someone might create an authorization identity in >one of the protocols that map to another authorization identity in the >other protocol. If the database also store which protocol the AuthZId >was normalized for, before the hash, it would work if the mechanism >knew the protocol that is used, but would prevent using the same >database for new protocols using SASL. The password database is >coupled to the protocol, in general. This seem to be a different >model than what RFC 2222 used, which will affect implementations. > > Authentication Authorization > Identity Identity - AuthZId > | | > | | > | \|/ > \|/ +-------------------+ > +--------------------+ | Protocol profile | > | | | | normalization | > | \|/ | +-------------------+ > | +---------------+ | | > | | Mechanism | | | > | | Normalization | | | > | +---------------+ | | > | | | | > | \|/ | | Possibly revised > | +-----------+ | | authorization identity > | | Mechanism |<----|<-----------+ F(AuthZId) > | +-----------+ | > | | | > | | | > +--------------------+ > | > | > Client | > ............|.......................... > Server | > | > \|/ > >Regards, >Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PNjbxM046455; Wed, 25 Feb 2004 15:45:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PNjbQ3046454; Wed, 25 Feb 2004 15:45:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PNjYdA046447 for ; Wed, 25 Feb 2004 15:45:35 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aw8ih-0001kO-00 for ; Thu, 26 Feb 2004 00:45:39 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 23:45:39 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 23:45:39 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Thu, 26 Feb 2004 00:45:27 +0100 Lines: 63 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:61ow7DN5S5lmMgWQugLB6GAECxQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Below is an image of how I perceive the normalization in rfc2222bis is intended to work, after extrapolating how Kurt's suggestions will be applied to the next version of the document. The requirement on mechanisms is to transport F(AuthZId) unmodified to the server. Profiles may normalize the AuthZId however they want, and mechanism may normalize authentication identities however they want. Mechanism may not normalize the authorization further (even for internal cryptographic processing). Is this correct? (I prefer not to speculate like this, because it generate long and potentially irrelevant e-mails, but was asked to do so to speed up the progress of the draft, please bear with me.) If so, and here comes my question, if two protocol profiles uses different normalizations, and a mechanism is implemented by storing a hash of H(Username|AuthId|AuthZid) (or it works in some similar way), the mechanism appear to need to select among different password databases, depending on which protocol is used. Implementation wise, the mechanism must know which protocol is used to select the correct database. If this is not done, there is the question of which normalization to use when the server compute H(U|A|Az) when storing it in the database. If only one of the protocol normalization steps is used, then it won't work with the other protocol. If both normalizations are stored, without the information on what protocol is used for each hash, someone might create an authorization identity in one of the protocols that map to another authorization identity in the other protocol. If the database also store which protocol the AuthZId was normalized for, before the hash, it would work if the mechanism knew the protocol that is used, but would prevent using the same database for new protocols using SASL. The password database is coupled to the protocol, in general. This seem to be a different model than what RFC 2222 used, which will affect implementations. Authentication Authorization Identity Identity - AuthZId | | | | | \|/ \|/ +-------------------+ +--------------------+ | Protocol profile | | | | | normalization | | \|/ | +-------------------+ | +---------------+ | | | | Mechanism | | | | | Normalization | | | | +---------------+ | | | | | | | \|/ | | Possibly revised | +-----------+ | | authorization identity | | Mechanism |<----|<-----------+ F(AuthZId) | +-----------+ | | | | | | | +--------------------+ | | Client | ............|.......................... Server | | \|/ Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PN8dch044214; Wed, 25 Feb 2004 15:08:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PN8cp5044213; Wed, 25 Feb 2004 15:08:38 -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.11/8.12.8) with ESMTP id i1PN8XUm044200 for ; Wed, 25 Feb 2004 15:08:38 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1PN8aMs052713 for ; Wed, 25 Feb 2004 23:08:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040225140730.04ba6788@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 25 Feb 2004 15:08:30 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: sasl-rfc2222bis: multiple authentication attack 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: In review of the latest draft, I've come across a number of technical and editorial concerns which I intend to start a number of separate threads on. This is the first. I am particularity perplexed by the long discussion of the "Multiple Authentication attack", an attack which only impacts certain kinds of distributed server implementations, which seems to overshadow higher risk, more generally applicable attacks. I am quite concerned about the addition of: > The protocol profiles that allow for > reauthentication SHOULD recommend that another security layer is > negotiated once a security layer was installed. as, if the implementation were subject to this kind of attack, simply recommending, or even requiring, negotiation of another security layer does not fully mitigate the risk. A server which is subject to such attack should simply refuse re-authentication (or if the implementor was only concerned about post re-authentication attacks, it can refuse re-authentications which don't result in installation of new layers). It seems odd to address what is a protocol-neutral security consideration in this fashion (a recommendation upon protocol profiles). Anyways, as previously discussed (and, I believe, agreed), this issue is best addressed through statement of security considerations. Hence, I suggest that all mention of this attack be removed from section 6.3, including all of section 6.3.1, and that the Security Consideration mention of 6.3.1 be replaced with (and merged with the preceding paragraph about distributed server implementations): It may be appropriate for a server to disallow all re-authentication, or re-authentications which do not result in new security layers being established, involving non- (or insufficiently) trusted parties. In some cases, it may be appropriate for the server to require separate connections to access information in different protected information spaces. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHGbI2019285; Wed, 25 Feb 2004 09:16:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PHGbQj019284; Wed, 25 Feb 2004 09:16:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHGTFD019274 for ; Wed, 25 Feb 2004 09:16:30 -0800 (PST) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aw2e4-0005nY-00 for ; Wed, 25 Feb 2004 18:16:28 +0100 Received: from h42n5c1o299.bredband.skanova.com ([217.211.246.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 17:16:28 2004 Received: from jas by h42n5c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Feb 25 17:16:28 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep in rfc2222bis-06 Date: Wed, 25 Feb 2004 18:16:15 +0100 Lines: 16 Message-ID: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@isode.com> <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h42n5c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:zwy/LZCR4VXyP4kl2cYxiVwkSBM= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >>First, does 'character strings' include the authorization identity? >>Defining the term 'character string', or at least giving examples, >>would help. > > No. I believe the text should be clarified. Mechanisms should be > capable of exchanging the authorization identity, but its handling > (in particular for comparison) is specific to the application-level > protocol which has profiled use of SASL as an authentication method. I see. Thanks for the reply, I'll review my issues once an updated draft is available. Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1O0hsbL033551; Mon, 23 Feb 2004 16:43:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1O0hsqi033550; Mon, 23 Feb 2004 16:43:54 -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.11/8.12.8) with ESMTP id i1O0hoAd033542 for ; Mon, 23 Feb 2004 16:43:51 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1O0hlMs019871; Tue, 24 Feb 2004 00:43:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040223154320.04b42a30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 23 Feb 2004 16:43:43 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: SASLprep in rfc2222bis-06 Cc: ietf-sasl@imc.org In-Reply-To: References: <200402162041.PAA20167@ietf.org> <6.0.1.1.0.20040216200054.04c9df08@127.0.0.1> <4031F175.1070301@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:04 AM 2/17/2004, Simon Josefsson wrote: >Hello all. I've read the latest document, and in general it looks >good (I've sent a couple of editorial changes to Alexey). However, I >find the SASLprep discussions not as clear. > >I tried to separate my issues into several e-mail, but eventually I >was unable to do so. The issues are closely intertwined, and >resolving one question modify the assumptions for other questions. So >forgive this longish e-mail. I have tried to separate the focus; >first to matters that affect mechanism specifications, then profile >specifications, and then to SASL library implementations. > >I'm sure that most of my issues could be solved by elaborating the >text, so the reader can understand what the intended general >philosophy is. Mostly I have refrained from suggesting specific >solutions, and below I only try to understand the current document. >My hope is that these ramblings can be turned into specific pointers >to where the document could be improvement, so that other people don't >have to ask the same questions I do. > >In 5.2 "Mechanism profile guidelines" there is this paragraph: > > Authentication mechanisms SHOULD encode character strings in UTF-8 > [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character > sets in IETF protocols). In order to avoid interoperability problems > due to differing normalizations, when a mechanisms specifies that > character data is to be used as input to a cryptographic and/or > comparison function, the mechanism specification MUST detail how the > data is to be represented, including any normalizations or other > preparations, to ensure proper function. Designers of mechanisms > SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] where applicable. > >I fail to understand several things here. > >First, does 'character strings' include the authorization identity? >Defining the term 'character string', or at least giving examples, >would help. No. I believe the text should be clarified. Mechanisms should be capable of exchanging the authorization identity, but its handling (in particular for comparison) is specific to the application-level protocol which has profiled use of SASL as an authentication method. >Second, is the 'MUST' conditioned on the 'when', or is the 'when' only >there to give the rationale behind the 'MUST'? In other words, is the >intention that all mechanisms MUST detail the normalization etc steps, >regardless of whether they input the strings to >cryptographic/comparison functions? I believe its conditional. It likely should be reworded for clarity. >Third, similarly, does the 'SHOULD' apply to all mechanisms, or just >those that actually use the 'character strings' as input to >cryptographic operations? It applies to "applicable" character strings. SASLprep is not applicable to all character strings. >For the sake of argument, I'm assuming the authorization identity is >considered a character string (this is my experience with deployed >tools, the administrator just types in the authorization identity). As noted above, I think this text should be clarified as not applying to the authorization identity. Even though most of the rest of your comments depend on your assumption, I went ahead and injected a few comments here and there. >Further, mechanisms MUST specify normalization, and SHOULD use >SASLprep "where applicable", for the processing of all character >strings, including the authorization identity. Ignoring the "including the authorization identity", yes. >The "where applicable" qualifier mostly invalidate the keywords. I think not. The statement says designers should consider whether use of SASLprep, if applicable, is appropriate. That implies that they should consider both the applicability of SASLprep and, if applicable, its appropriateness. The "where applicable" was added because we didn't want designers to think they SHOULD use SASLprep for all character strings. They SHOULD use SASLprep for kinds of character strings which SASLprep was designed to be used with. >When is SASLprep applicable or not? That's discussed in the SASLprep I-D, namely in Section 1 but also in Section 2 and 3. >That seems rather subjective to me. Consideration of a "SHOULD" is always subjective. >Otherwise, I believe this SHOULD, without any verifiable >technical consequences, should be removed. I disagree. >Let's go the section 5.1 "Protocol profile requirements": > 8) A protocol profile MAY further refine the definition of an > authorization identity by adding additional syntactic restrictions > and protocol-specific semantics. A protocol profile MUST specify the > form of the authorization identity (since it is protocol specific, as > opposed to the authentication identity, which is mechanism specific) > and how authorization identities are to be compared. Profiles whose > authorization identities are simple user names (e.g. IMAP [RFC 3501]) > SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" > algorithm [StringPrep] to prepare these names for matching. The > profiles MAY use a stringprep profile that is more strict than > SASLprep. > >This says the form of the authorization identity is protocol specific. >Given the recommendations in 5.2 for mechanism specification to modify >the form of the authorization identity, it appears to be in conflict. Correct. That's why 5.2 should be clarified as not to apply to authorization identities. >In order words: Should the authzid normalization procedure defined by >the mechanism be run before or after the authzid normalization >procedure defined by the profile? There should be no mechanism specific normalization of the authorization identity. In regards to the mechanism, both peers should use the client provided string in all functions. This likely should be stated in the mechanism profile requirements. >I'm assuming here that "server" refer to the actual application, not >the server part of the generic SASL implementation. The term "server" refers to the service-providing peer and a "server implementation" refers to all components which make up that peer (operating system, libraries, program code, and any and all supporting external systems on that end). What is or isn't in a library is an implementation detail. >Up until now, at >least my SASL implementation has not been aware of the protocol that >uses the library. The justification for this is the same that SASL >mechanisms shouldn't contain SASL profile specific behaviour, and vice >versa: > > A protocol profile SHOULD NOT attempt to amend the definition of > mechanisms or make mechanism-specific encodings. This breaks the > separation between protocol and mechanism that is fundamental to the > design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. I note, this should be s/profile neutral/protocol neutral/. >Is my interpretation of what "server" refer to here correct? That >only the protocol specific part SHOULD verify the authzid form? It means that the protocol profile is to specify the form of the authzid (and how to compare it) and the mechanism should just provide a mechanism for exchanging the authzid. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NNVoFN029463; Mon, 23 Feb 2004 15:31:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NNVoPQ029461; Mon, 23 Feb 2004 15:31:50 -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.11/8.12.8) with ESMTP id i1NNVnmr029453 for ; Mon, 23 Feb 2004 15:31:50 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1NNVtMs018876 for ; Mon, 23 Feb 2004 23:31:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040223152755.04b77618@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 23 Feb 2004 15:31:51 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASL WG session agenda for IETF#59 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 WG (SASL) TUESDAY, March 2 at 1700-1800 ============================= CHAIRS: Sam Hartman Kurt Zeilenga AGENDA: 0) Preliminaries (Blue Sheets, Scribes) - Chairs - 1m 1) WG Status Summary - Chairs - 5m 2) SASL base specification open issues - 25m - Alexey draft-ietf-sasl-rfc2222bis-xx.txt 3) Other open issues - 15m - Editors draft-ietf-sasl-*-xx.txt 4) Milestone review - Chairs - 5m 5) Open mic - Floor - remaining time Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BIj1PZ080759; Wed, 11 Feb 2004 10:45:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BIj02O080758; Wed, 11 Feb 2004 10:45:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1BIithG080741 for ; Wed, 11 Feb 2004 10:44:55 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa07940; 11 Feb 2004 13:44 EST Date: Wed, 11 Feb 2004 13:44:41 -0500 From: Jeffrey Hutzelman To: Alexey Melnikov , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) Message-ID: <3616130000.1076525081@minbar.fac.cs.cmu.edu> In-Reply-To: <402A5584.5080705@isode.com> References: <402A5584.5080705@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, February 11, 2004 16:17:08 +0000 Alexey Melnikov wrote: > Kurt raised a question about removing the following paragraph from the > Security Considerations section. Sam has agreed with Kurt. (This text is > not something specific to SASL. After discussing this issue in > relationship to XMPP, I thought that it would be a nice idea to add it) > > SASL implementations might be subject to online dictionary attacks > (e.g. username harvesting, password guessing). In order to mitigate > the attacks a server implementation is encouraged to implement a > policy when after a number of failed authentication attempts it > returns errors to all subsequent authentication attempts on the same > connection. Alternatively, the server may implement a policy whereby > the connection is dropped after a number of failed authentication > attempts. If a server implementation chooses to do so, it should not > drop the connection until at least 3 authentication attempts have > failed. > > Before I do any changes I would like to hear at least 2 more voices in > favor of keeping or removing this paragraph. I'll have to agree with others here. Particularly, since SASL negotiation is acheived via an exchange of data which it is the application protocol's responsibility to transport in an application-specific manner, the SASL implementation is in no position to detect whether two exchanges occur "on the same connection", let alone drop a connection. This is clearly an issue for the application protocol and for site policy. -- Jeff Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BHihRb075191; Wed, 11 Feb 2004 09:44:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BHihEB075190; Wed, 11 Feb 2004 09:44:43 -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.11/8.12.8) with ESMTP id i1BHig8j075184 for ; Wed, 11 Feb 2004 09:44:42 -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, 11 Feb 2004 17:44:53 +0000 Message-ID: <402A6A13.3060309@isode.com> Date: Wed, 11 Feb 2004 17:44: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: Rob Siemborski CC: Peter Saint-Andre , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) References: <402A5584.5080705@isode.com> <20040211165027.GL20400@jabber.org> 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 Wed, 11 Feb 2004, Peter Saint-Andre wrote: > > >>Hi Alexey, >> >>This seems like an issue that should be addressed by the using protocol >>(e.g., the XMPP specs should say something about this), not something >>that should be addressed by SASL. So I agree with Kurt and Sam. >> >>Peter >> >> > >I also agree -- this isn't something specific to sasl, it is more >applicable to the application's specific authentication policy. > Ok, we have 4 votes. Seems like a consensus. I will remove this. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BHa48F074439; Wed, 11 Feb 2004 09:36:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BHa4r6074438; Wed, 11 Feb 2004 09:36:04 -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.11/8.12.8) with ESMTP id i1BHZwL0074429 for ; Wed, 11 Feb 2004 09:35:59 -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 i1BHaCtH015031; Wed, 11 Feb 2004 12:36:12 -0500 Date: Wed, 11 Feb 2004 12:36:11 -0500 (EST) From: Rob Siemborski To: Peter Saint-Andre cc: Alexey Melnikov , SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) In-Reply-To: <20040211165027.GL20400@jabber.org> Message-ID: References: <402A5584.5080705@isode.com> <20040211165027.GL20400@jabber.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: On Wed, 11 Feb 2004, Peter Saint-Andre wrote: > Hi Alexey, > > This seems like an issue that should be addressed by the using protocol > (e.g., the XMPP specs should say something about this), not something > that should be addressed by SASL. So I agree with Kurt and Sam. > > Peter I also agree -- this isn't something specific to sasl, it is more applicable to the application's specific authentication policy. -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+++ X- R@ tv-- b+ DI+++ D++ 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.11/8.12.8) with ESMTP id i1BGoGAW070982; Wed, 11 Feb 2004 08:50:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BGoGAi070981; Wed, 11 Feb 2004 08:50:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hades.jabber.org (hades.all-your-IM-are-belong-to-us.jabber.org [208.245.212.109] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGoEOO070973 for ; Wed, 11 Feb 2004 08:50:14 -0800 (PST) (envelope-from stpeter@jabber.org) Received: by hades.jabber.org (Postfix, from userid 1005) id EBF0D63FCA; Wed, 11 Feb 2004 10:50:27 -0600 (CST) Date: Wed, 11 Feb 2004 10:50:27 -0600 From: Peter Saint-Andre To: Alexey Melnikov Cc: SASL WG Subject: Re: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) Message-ID: <20040211165027.GL20400@jabber.org> References: <402A5584.5080705@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402A5584.5080705@isode.com> User-Agent: Mutt/1.5.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Feb 11, 2004 at 04:17:08PM +0000, Alexey Melnikov wrote: > > Kurt raised a question about removing the following paragraph from the > Security Considerations section. Sam has agreed with Kurt. > (This text is not something specific to SASL. After discussing this > issue in relationship to XMPP, I thought that it would be a nice idea to > add it) > > SASL implementations might be subject to online dictionary attacks > (e.g. username harvesting, password guessing). In order to mitigate > the attacks a server implementation is encouraged to implement a > policy when after a number of failed authentication attempts it > returns errors to all subsequent authentication attempts on the same > connection. Alternatively, the server may implement a policy whereby > the connection is dropped after a number of failed authentication > attempts. If a server implementation chooses to do so, it should not > drop the connection until at least 3 authentication attempts have > failed. > > Before I do any changes I would like to hear at least 2 more voices in > favor of keeping or removing this paragraph. Hi Alexey, This seems like an issue that should be addressed by the using protocol (e.g., the XMPP specs should say something about this), not something that should be addressed by SASL. So I agree with Kurt and Sam. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BGH5v3068605; Wed, 11 Feb 2004 08:17:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BGH5HQ068604; Wed, 11 Feb 2004 08:17: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.11/8.12.8) with ESMTP id i1BGGxDd068523 for ; Wed, 11 Feb 2004 08:17: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; Wed, 11 Feb 2004 16:17:09 +0000 Message-ID: <402A5584.5080705@isode.com> Date: Wed, 11 Feb 2004 16:17:08 +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: Update on RFC 2222bis (soon to be draft-ietf-sasl-rfc2222bis-06.txt) 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: I've recently submitted draft-ietf-sasl-rfc2222bis-05 which addressed most of the editorial issues raised by Kurt Zeilenga. I am planning to submit a new revision before the submission deadline. Question: Kurt raised a question about removing the following paragraph from the Security Considerations section. Sam has agreed with Kurt. (This text is not something specific to SASL. After discussing this issue in relationship to XMPP, I thought that it would be a nice idea to add it) SASL implementations might be subject to online dictionary attacks (e.g. username harvesting, password guessing). In order to mitigate the attacks a server implementation is encouraged to implement a policy when after a number of failed authentication attempts it returns errors to all subsequent authentication attempts on the same connection. Alternatively, the server may implement a policy whereby the connection is dropped after a number of failed authentication attempts. If a server implementation chooses to do so, it should not drop the connection until at least 3 authentication attempts have failed. Before I do any changes I would like to hear at least 2 more voices in favor of keeping or removing this paragraph. The changes between 05 and 06 are outlined below: 1). New section 5.2 was introduced that list guidelines for a SASL mechanism designer. 5.2. Mechanism profile guidelines Designers of new SASL mechanism should be aware of the following issues: 1) Authorization identity. While some legacy mechanisms are incapable of transmitting an authorization identity (which means that for these mechanisms the authorization identity is always the empty string), newly defined mechanisms SHOULD be capable of transmitting a non-empty authorization identity. See also section 4.2. 2) Character string issues Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). In order to avoid interoperability problems due to differing normalizations, when a mechanisms specifies that character data is to be used as input to a cryptographic and/or comparison function, the mechanism specification MUST detail how the data is to be represented, including any normalizations or other preparations, to ensure proper function. Designers of mechanisms SHOULD use the "SASLprep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep] where applicable. The preparation can be potentially performed on the client end (upon getting user input or retrieving a value from configuration) or on the server end (upon receiving the value from the client, retrieving a value from its authentication database or generating a new value in order to store in in the authentication database). SASL mechanisms must define which entity (or entities) must perform the preparation. If preparation fails or results in an empty string, the entity doing the preparation SHALL fail the authentication exchange. Implementation note: A server end can be represented by multiple processes. For example, it may consist of the server process itself that communicated with a client, and a command line utility (a server agent) that is able to store passwords/hashes in a database that can be later used by the server. For the server agent the requirement to "fail the authentication exchange" should be interpreted as a requirement to refuse to store the data in the database. 2). I've added a SASL profile requirement that tells that if the protocol supports an initial response, it must specify how an empty initial response is encoded. This was prompted by a recent discussion on XMPP mailing list. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________