From owner-ietf-sasl Fri Oct 1 06:59:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91DxtP9030106; Fri, 1 Oct 2004 06:59:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Dxtdt030105; Fri, 1 Oct 2004 06:59:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Dxr87030096 for ; Fri, 1 Oct 2004 06:59:54 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CDNwr-0003xT-9d for ietf-sasl@imc.org; Fri, 01 Oct 2004 15:59:49 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CDNwn-0005qc-Dt; Fri, 01 Oct 2004 15:59:45 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CDNwm-0003D0-00; Fri, 1 Oct 2004 15:59:44 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis-08 comments Date: Fri, 1 Oct 2004 15:59:44 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These are rather rather hurried comments, since Kurt said reviews are needed but soon. So I have only made a cursory check if these issues have been discussed before; I don't know how much they would have been delayed if I were to check properly. Sorry about that. > Abstract I had trouble getting into SASL the first time I read the draft - mostly things that did not make sense to me at first, only when I got to a closer explanation later in the draft. I'm beginning to figure out why now, though I'm guessing a bit about what it was I didn't get. Starting with the Abstract: I didn't get that at all, though I don't really see why, given the second paragraph. "So I have a protocol here, and an authentication mechanism there, and somehow if I include SASL, the two will be able to talk to each other. Um...?" It's better now, but I still suggest: > The Simple Authentication and Security Layer (SASL) is a framework > for providing authentication and data security services in > connection-oriented protocols via replaceable authentication [nothing in the abstract says that's the kind of mechanisms it is talking about.] > mechanisms. It > provides structured interface between protocols and such SASL > mechanisms. Or maybe "...and mechanisms that adhere to SASL", but that's probably more wordy than necessary. The same change would be nice in the Introduction section, though of course the diagram there helps. Personally I would also have found an asymmetric definition easier to relate to: SASL defines a common interface to authentication mechanisms for protocols. (Is that the right way to put it?) But maybe that's not at all the view SASL intends to convey. Is the protocol profile the common interface to protocols for authentication mechanisms? > 2. Introduction > The implementors will also need to understand a > specification of a SASL > profile specific to the protocol, > 3.1. Authentication protocol exchange This phrase looks to me like it is about an authentication protocol - i.e. part of SASL - and not the protocol which uses SASL. I don't see anything in the following section to correct that notion. Also, > A SASL mechanism is responsible for conducting an authentication > protocol exchange. I don't think so. It's the protocol which conducts the _exchange_, and (below) which transmits anything. > During the authentication protocol exchange, the mechanism performs I suggest s/performs/can perform/, since not all of them need be done. > authentication, transmits an authorization identity (frequently known > as a userid) from the client to server, This sounds like the authorization identity is independent of the authentication. See below. > 3.2. Authorization and authentication identities > 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. As above. As described, the authorization ID appears not to be part of the 'results produced by the authentication mechanism', only something which is grabbed after completion of the authentication. When I first read about this, I was left wondering when the server checks if the authentication ID has the authorization ID's access. Each time one tries to access something after the authentication? Please clarify that the authorization ID is checked during the authentication (as section 3.2.1 says). And local policy is used to either derive the authorization identity or check it. But it looks a little strange to use that local policy during the exchange if the user provides it, but after the exchange if it is derived. Should both be done during the exchange instead? > 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. I wonder a little why the authorization ID is explicitly said to be provided by the client, when the authentication ID is not. > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. That's a bit misleading from the protocol's point of view. From discussions elsewhere I gather the protocol may normalize the ID as it pleases for its own use, including when it locates the server-side secret matching the authentication ID, as long as this does not affect the ID which the authentication mechanism sees. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). The () part does not seem say the same as the preceding sentence: 'when transferring...' sounds like only the client-side part of the mechanism must preserve the ID, while the () sounds like the server side also must preserve it. > 3.2.1. Authorization identities and proxy authentication > The server SHOULD verify that a received authorization identity is in > the correct form. Protocol 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. In that case there can be authorization IDs which one can only get by sending an empty authorization ID: IDs that are derived from the authentication ID but would be invalid if specified explicitly. Seems strange. > 3.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. But a NUL octet in a multibyte character is OK? (Does not apply to UTF-8, of course.) > 3.3. Security layers > 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. The exact position MUST be defined by > the protocol profile (see section 4 part 5). When does it stop having effect, if the protocol supports multiple authentication? > Note that all SASL mechanisms that are unable to negotiate a security > layer automatically select no security layer. Without checking up the 'selects no security layer' thread, I still can't tell if this says that such a mechanism cancels an old security layer or if it says that it doesn't affect it. I'll check that later, unless someone replies first. -- Hallvard From owner-ietf-sasl Fri Oct 1 07:39:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91EdLFb032699; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91EdL0I032698; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91EdLQr032689 for ; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91EdLZv065770 for ; Fri, 1 Oct 2004 14:39:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001072559.04412a90@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 07:39:20 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis-08 comments In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >These are rather rather hurried comments, since Kurt said reviews are >needed but soon. Thanks for responding to my late request for review! To the WG, Sam and I have some concerns regarding the depth and breadth of the WG review of this I-D. The chairs continue to actively seek additional review. Kurt From owner-ietf-sasl Fri Oct 1 11:09:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I9RiC047225; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91I9RpB047224; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I9ROw047216 for ; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91I9SZv067220 for ; Fri, 1 Oct 2004 18:09:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001085527.044c67c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 09:14:18 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Reconsideration Identity And Authorization Issue (Was: Summary of 2222bis WGLC) In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> References: <6.1.2.0.0.20040924123829.0433b4c8@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:40 PM 9/24/2004, Kurt D. Zeilenga wrote: >5) Identities and Authorization > >Kurt indicated that the I-D use of term "authorization >identity" is confusing and suggested use of different >terms for each distinct use of this term. Jeffery >suggested using the terms: > "authentication identity" to refer to the > identity associated with the users creditials, > "requested identity" to refer to identity > which the user requests to act as, and > "authorization identity" to refer to identity > used by the server in making authorization > decisions. (The latter being derived from > by former two.) > >The chairs conclude the WG supports use of this >suggested terminology. After some lengthy discussions between the Sam, Alexey, and I (with and without our respective chair/editor hats), the chairs have decided to vacate their conclusion regarding this issue and re-open discussion in this area. This post will be followed by a messaging summarizing problems with above terminology choice and offering a way to resolve the underlying terminology problem. Kurt, as SASL co-chair From owner-ietf-sasl Fri Oct 1 11:21:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91ILDdj048000; Fri, 1 Oct 2004 11:21:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91ILDmV047999; Fri, 1 Oct 2004 11:21:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91ILCCJ047988 for ; Fri, 1 Oct 2004 11:21:12 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91ILFZv067280 for ; Fri, 1 Oct 2004 18:21:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 11:21:13 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Identity terminology in 2222bis 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: Historically, there was a bit of hand waving in regards to identities. In trying to nail down what identities are involved in the SASL framework, where each identity comes from and what are they used for, we ended up with 3 identities: - the "authentication identity" to refer to the identity associated with the users credentials, - the "requested identity" to refer to identity which the user requests to act as, and - "authorization identity" to refer to identity used by the server in making authorization decisions. (The latter being derived from by former two.) However, we now face is that what we've historically called an authorization identity is not the precise identity used in making authorization decisions. The amount of 2222bis editing to implement the WGLC conclusion is actually minor in comparison to the impact upon other documents, including most mechanism specifications and application profiles. If it was only 2222bis, I'd be inclined to just bit the bullet and make the terminology changes. But given the broader impact this terminology change would have, we need to consider other approaches to resolving our terminology woes. In particular, I think this can be done by separating how identities are used conceptually from how they are used in practice and, in particular, their form. Below is a 3.2 rewrite which, I think, demonstrates how we can avoid the terminology problem. I do think other portions need work as well, but this should give you reasonable idea of the approach I suggest we take. Comments? -- Kurt (as an individual contributor) 3.2 Identity Concepts Conceptually, SASL framework involves two identities: 1) an identity associated with the authentication credentials (termed the authentication identity), and 2) an identity to act as (termed the authorization identity). The client provides its credentials and, optionally, a string representing the requested authorization identity as part of the SASL exchange. When this string is not provided, the client is requesting to act as the identity associated with the credentials (e.g., the user is requesting to act as the authentication identity). The server is responsible for verifying the user's credentials and verifying that the user is able to act as the authorization identity. A SASL exchange is successful if and only if both of these verifications are successful. While SASL mechanisms specify the form of credentials used to authenticating users and SASL application profiles specify the form of authorization identities transferred as part of authentication exchange, the precise form(s) of the authentication identities (used within the server in its verifications, or otherwise) and the precise form(s) of the authorization identities (used in making authorization decisions, or otherwise) is beyond the scope of the SASL and this specification. In some circumstances, the precise identity forms used outside of the SASL exchange may be dictated by other specifications. For instance, the authorization policy specification for an application protocol may dictate the precise form that an authorization identity is to be represented in the authorization policy. From owner-ietf-sasl Fri Oct 1 11:23:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91INkBq048111; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91INk6n048110; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91INkHI048104 for ; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91INnZv067292; Fri, 1 Oct 2004 18:23:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 11:23:07 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis-08 comments Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a few (initial) comments to inject here and there. At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >> Abstract > >> The Simple Authentication and Security Layer (SASL) is a framework >> for providing authentication and data security services in >> connection-oriented protocols via replaceable > >authentication The sentence might be more clear if worded: The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services via replaceable mechanisms to connection-oriented protocols. >[nothing in the abstract says that's the kind of mechanisms it is >talking about.] Mechanisms provide authentication and data security services to connection-oriented protocols through the SASL framework. >> mechanisms. It >> provides structured interface between protocols and > >such SASL > >> mechanisms. I think its clear that both "protocols" and "mechanisms" refer to those protocols and mechanisms which are utilizing the SASL framework. I don't think either needs to be qualified here. It would seem odd to qualify one and not the other. And as this is the Abstract, we should avoid being too wordy. >Or maybe "...and mechanisms that adhere to SASL", but that's probably >more wordy than necessary. First, you'd have to say s/SASL/SASL technical specification/. But, yes, too wordy. >The same change would be nice in the Introduction section, though of >course the diagram there helps. > >Personally I would also have found an asymmetric definition easier to >relate to: SASL defines a common interface to authentication mechanisms >for protocols. (Is that the right way to put it?) But maybe that's not >at all the view SASL intends to convey. Is the protocol profile the >common interface to protocols for authentication mechanisms? The "protocol profile" is the part of the protocol's technical specification which details how it makes use of the SASL framework. >> 2. Introduction > >> The implementors will also need to understand a >> specification of a > >SASL > >> profile specific to the protocol, > >> 3.1. Authentication protocol exchange > >This phrase looks to me like it is about an authentication protocol - >i.e. part of SASL - and not the protocol which uses SASL. >I don't see anything in the following section to correct that notion. I think the word "protocol' here should be dropped here and elsewhere where we're referring to the mechanism exchange. >Also, > >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. > >I don't think so. It's the protocol which conducts the _exchange_, >and (below) which transmits anything. > >> During the authentication protocol exchange, the mechanism performs > >I suggest s/performs/can perform/, since not all of them need be done. > >> authentication, transmits an authorization identity (frequently known >> as a userid) from the client to server, > >This sounds like the authorization identity is independent of the >authentication. See below. > >> 3.2. Authorization and authentication identities There was some discussion in this area during WGLC. That discussion was recently re-opened. I suggest you read my latest post in this area as well as the WGLC thread. >> 3.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. > >But a NUL octet in a multibyte character is OK? This sentence refers only to specific character, not octets belonging to an encoding of other characters. From owner-ietf-sasl Fri Oct 1 14:06:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91L63tA057281; Fri, 1 Oct 2004 14:06:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91L63cL057280; Fri, 1 Oct 2004 14:06:03 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91L61JI057271 for ; Fri, 1 Oct 2004 14:06:01 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDUbF-000316-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Fri, 01 Oct 2004 23:05:31 +0200 Lines: 46 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:pqbbMshAe7vTm5P+HVrgAxdOyMk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > While SASL mechanisms specify the form of credentials > used to authenticating users and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange, the > precise form(s) of the authentication identities (used > within the server in its verifications, or otherwise) > and the precise form(s) of the authorization identities > (used in making authorization decisions, or otherwise) is > beyond the scope of the SASL and this specification. I'm worried by how this new text interact with string normalization like SASLPrep. To me, it sounds as if the above leave the precise form of authentication/authorization identities up to either, or both, of application profiles and mechanisms. Is that a correct interpretation? If so, the new text would appear to permit, e.g., mechanisms to perform SASLPrep on the authorization identity. And to permit application profiles to apply perform SASLPrep on the authentication identity. Here, SASLPrep could even be some other function, like Unicode NFKC, or SASLPrep2, or some proprietary normalization procedure. For comparison, here is part of the old text: Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Read in contrast to each other, this seem like a major design change. Instead, I propose to clarify the terminology. Further, the requirements on application profile and mechanisms should be specified, and not left "beyond the scope of 2222bis". One concrete approach is to require that, for IETF application profiles and mechanisms, both authentication and authorization identities MUST be SASLPrep strings, and that the SASL library, the application profile, and the mechanism may all perform SASLPrep on the identities. Thanks, Simon From owner-ietf-sasl Fri Oct 1 15:38:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McWYt061399; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91McWIo061398; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McT4j061390 for ; Fri, 1 Oct 2004 15:38:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 434F9E004F; Fri, 1 Oct 2004 18:38:33 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> From: Sam Hartman Date: Fri, 01 Oct 2004 18:38:33 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 01 Oct 2004 23:05:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >> While SASL mechanisms specify the form of credentials used to >> authenticating users and SASL application profiles specify the >> form of authorization identities transferred as part of >> authentication exchange, the precise form(s) of the >> authentication identities (used within the server in its >> verifications, or otherwise) and the precise form(s) of the >> authorization identities (used in making authorization >> decisions, or otherwise) is beyond the scope of the SASL and >> this specification. Simon> I'm worried by how this new text interact with string Simon> normalization like SASLPrep. To me, it sounds as if the Simon> above leave the precise form of Simon> authentication/authorization identities up to either, or Simon> both, of application profiles and mechanisms. Is that a Simon> correct interpretation? The consensus of this working group is that the mechanism must transport the requested authorization identity so that all unicode code points are preserved. I.E. the mechanism can use any bijective transformation it desires; transforms like utf8-encode are assumed to be bijective on the set of unicode code points. Trying to be a bit more clear, mechanisms choose the encoding, but must preserve the unicode code points given to them by the protocol. The authentication identity is completely a matter for the mechanism; it may (and often should) normalize it. The normalization and interpretation of the requested authorization identity is a protocol matter. --Sam From owner-ietf-sasl Fri Oct 1 15:58:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91MwtoH062300; Fri, 1 Oct 2004 15:58:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91MwtBo062299; Fri, 1 Oct 2004 15:58:55 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Mws7d062293 for ; Fri, 1 Oct 2004 15:58:54 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDWMd-000605-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Sat, 02 Oct 2004 00:58:33 +0200 Lines: 27 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:TTdNN5xkyEqxgQU8B6PSnsAdaIk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > The consensus of this working group is that the mechanism must > transport the requested authorization identity so that all unicode > code points are preserved. Then I propose to keep the following in section 3.2: The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Otherwise, I cannot find any normative text reflecting the consensus. > The authentication identity is completely a matter for the mechanism; > it may (and often should) normalize it. Then I propose to keep the following in section 3.2: Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Kurt D. Zeilenga proposed to remove both paragraphs, if I understood him correctly. Thanks, Simon From owner-ietf-sasl Fri Oct 1 16:12:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NCDIK063905; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91NCD8q063904; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NCDNS063896 for ; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91NC7Zv068806; Fri, 1 Oct 2004 23:12:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 16:12:05 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@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: Simon, Note that the text I offer is not a direct replacement for Section 3.2. Additional work, including moving key imperatives from the existing 3.2 to other sections, would have to be undertaken. At 02:05 PM 10/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> While SASL mechanisms specify the form of credentials >> used to authenticating users and SASL application >> profiles specify the form of authorization identities >> transferred as part of authentication exchange, the >> precise form(s) of the authentication identities (used >> within the server in its verifications, or otherwise) >> and the precise form(s) of the authorization identities >> (used in making authorization decisions, or otherwise) is >> beyond the scope of the SASL and this specification. This may need some slight rewording. The intent is for the mechanism specification to detail how to verify the credentials and for the application protocol profile to specify the precise form of the authorization identity (within the Unicode restrict) but to make it clear that there are many uses of these identities which SASL simply doesn't not control. >I'm worried by how this new text interact with string normalization >like SASLPrep. I presume the existing recommendations here will remain. >To me, it sounds as if the above leave the precise >form of authentication/authorization identities up to either, or both, >of application profiles and mechanisms. The precise form of the credentials is a mechanism detail. The mechanism generally details how the credentials are to be verified. The precise form of the authorization identity is, excepting the Unicode restriction, is a application protocol detail. Other uses of identities are outside the scope of SASL. >For comparison, here is part of the old text: > > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. Though I think this needs to be slightly reworded, I agree with the intent of the statement to say that protocol profiles should leave of aspects of credentials and their verification to the mechanism. However, this in no way implies that an application protocol specification, or its implementations, cannot detail the form of authentication identity the application protocol (or implementation) might use otherwise. For instance, an application protocol specification could detail how to represent authentication identities in an identity assumption authorization policy. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). > >Read in contrast to each other, this seem like a major design change. > >Instead, I propose to clarify the terminology. I think you propose a major design change. From owner-ietf-sasl Fri Oct 1 16:25:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NPsu0065555; Fri, 1 Oct 2004 16:25:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91NPsAb065554; Fri, 1 Oct 2004 16:25:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NPrBa065548 for ; Fri, 1 Oct 2004 16:25:53 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDWmk-0006iS-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Sat, 02 Oct 2004 01:25:32 +0200 Lines: 13 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/v3LJ3jCN8CLzghBvWRYkQ2Kb+0= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > Simon, > > Note that the text I offer is not a direct replacement for > Section 3.2. Additional work, including moving key > imperatives from the existing 3.2 to other sections, would > have to be undertaken. OK, I must have misread your initial post then. Thanks, Simon From owner-ietf-sasl Fri Oct 1 18:49:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i921nTvA072491; Fri, 1 Oct 2004 18:49:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i921nTmx072490; Fri, 1 Oct 2004 18:49:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from Gate2-sandiego.nmci.navy.mil (gate2-sandiego.nmci.navy.mil [138.163.0.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i921nPkH072479 for ; Fri, 1 Oct 2004 18:49:25 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: from nawesdnims04.nmci.navy.mil by Gate2-sandiego.nmci.navy.mil via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Sat, 2 Oct 2004 01:49:32 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: from mail pickup service by NAWESDNIEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC; Fri, 1 Oct 2004 18:47:51 -0700 Received: from nawesdnifw06.nmci.navy.mil ([10.0.0.38]) by NAWESDNIEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Oct 2004 15:53:09 -0700 Received: from Nawesdnims01.nmci.navy.mil by nawesdnifw06.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.0.10.60]) with ESMTP; Fri, 1 Oct 2004 22:53:09 +0000 Received: from nawesdnifw03c.nmci.navy.mil (nawesdnifw03c.nmci.navy.mil [10.0.0.163]) by nawesdnims01.nadsuswe.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id i91MmgJ09107 for ; Fri, 1 Oct 2004 22:48:42 GMT Received: from above.proper.com ([208.184.76.39]) by nawesdnifw03c.nmci.navy.mil via smtpd (for [10.0.0.166]) with ESMTP; Fri, 1 Oct 2004 22:53:08 +0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McWYt061399; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91McWIo061398; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McT4j061390 for ; Fri, 1 Oct 2004 15:38:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 434F9E004F; Fri, 1 Oct 2004 18:38:33 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> From: Sam Hartman Date: Fri, 01 Oct 2004 18:38:33 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 01 Oct 2004 23:05:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Archive: List-ID: List-Unsubscribe: X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-OriginalArrivalTime: 01 Oct 2004 22:53:09.0356 (UTC) FILETIME=[6C038AC0:01C4A809] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> "Kurt D. Zeilenga" writes: >> While SASL mechanisms specify the form of credentials used to >> authenticating users and SASL application profiles specify the >> form of authorization identities transferred as part of >> authentication exchange, the precise form(s) of the >> authentication identities (used within the server in its >> verifications, or otherwise) and the precise form(s) of the >> authorization identities (used in making authorization >> decisions, or otherwise) is beyond the scope of the SASL and >> this specification. Simon> I'm worried by how this new text interact with string Simon> normalization like SASLPrep. To me, it sounds as if the Simon> above leave the precise form of Simon> authentication/authorization identities up to either, or Simon> both, of application profiles and mechanisms. Is that a Simon> correct interpretation? The consensus of this working group is that the mechanism must transport the requested authorization identity so that all unicode code points are preserved. I.E. the mechanism can use any bijective transformation it desires; transforms like utf8-encode are assumed to be bijective on the set of unicode code points. Trying to be a bit more clear, mechanisms choose the encoding, but must preserve the unicode code points given to them by the protocol. The authentication identity is completely a matter for the mechanism; it may (and often should) normalize it. The normalization and interpretation of the requested authorization identity is a protocol matter. --Sam From owner-ietf-sasl Fri Oct 1 22:02:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252w7G083996; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9252wSA083994; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252vOB083966; Fri, 1 Oct 2004 22:02:57 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d216-232-212-223.bchsia.telus.net (d216-232-212-223.bchsia.telus.net [216.232.212.223]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9252sWc034166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 23:02:56 -0600 (MDT) Date: Fri, 01 Oct 2004 22:02:54 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org Subject: CRAMing for last call Message-ID: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Now that 2222bis is close to reality, I would like to push the final version of CRAM out as well. The two documents should be able to go through together, (I hope) making life easier for the RFC editor. I have some non-substantive editorial changes that will make the document a bit easier to read, but these are not show stoppers. I think all of the last round of comments are addressed in the current draft. If not, I would like to hear from people, soon. I would also like to solicit a few additional examples from anyone who has implemented CRAM in other than IMAP. Finally, we need to address the issue of the MD5 "break." I have held off from commenting on this issue until the community has seen explicit evidence of the attack, and the implications of it. At this point, I don't know if the document deserves a writeup on the attack. Theory abounds, but I haven't yet seen a practical attack that works in the general case. We should at the least make mention of what has been discussed, and point to the literature, but I don't think the document deserves to discuss all the possible attacks. This doesn't mean to discourage anyone from contributing text to the Security Considerations section (please do). The IMAP-EXT list has had recent discussion that points out the ambiguity of searching for the space (SP) separator (between the user id and the digest) as being the rightmost SP, so I will strengthen that text. Any other comments should come forth soon as I would like to run out the final draft at the end of next week (Oct. 8) if I can. Cheers, --lyndon (editor) From owner-ietf-sasl Sat Oct 2 11:52:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iquk2048414; Sat, 2 Oct 2004 11:52:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92IquqC048413; Sat, 2 Oct 2004 11:52:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iqqgx048406 for ; Sat, 2 Oct 2004 11:52:53 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id CFC98160099; Sat, 2 Oct 2004 14:52:59 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> From: Sam Hartman Date: Sat, 02 Oct 2004 14:52:58 -0400 In-Reply-To: <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 01 Oct 2004 16:12:05 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> be verified. The precise form of the authorization identity Kurt> is, excepting the Unicode restriction, is a application Kurt> protocol detail. This isn't quite right. The form of the requested authorization identity--the bits that are transferred over the wire--is a mechanism detail. The protocol profile feeds in unicode codepoints and the mechanism decides how those codepoints will appear on the wire. The semantics of these codepoints is what is a protocol detail. --Sam From owner-ietf-sasl Sat Oct 2 11:58:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92IwtOq048630; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92IwtD4048627; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iwssm048615; Sat, 2 Oct 2004 11:58:54 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C22AAE004F; Sat, 2 Oct 2004 14:58:59 -0400 (EDT) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org Subject: Re: CRAMing for last call References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> From: Sam Hartman Date: Sat, 02 Oct 2004 14:58:59 -0400 In-Reply-To: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> (Lyndon Nerenberg's message of "Fri, 01 Oct 2004 22:02:54 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> Finally, we need to address the issue of the MD5 "break." Lyndon> I have held off from commenting on this issue until the Lyndon> community has seen explicit evidence of the attack, and Lyndon> the implications of it. At this point, I don't know if the Lyndon> document deserves a writeup on the attack. Theory abounds, Lyndon> but I haven't yet seen a practical attack that works in Lyndon> the general case. We should at the least make mention of Lyndon> what has been discussed, and point to the literature, but Lyndon> I don't think the document deserves to discuss all the Lyndon> possible attacks. This doesn't mean to discourage anyone Lyndon> from contributing text to the Security Considerations Lyndon> section (please do). The security area seems to believe that hmac-md5 is still OK, at least for now. Especially since cram-md5 does not require much structure for the challenge, we should discuss the issue in the security considerations section. Will you need agenda time at the next meeting? If so, can you give an estimate of how much and what we want to cover? Thanks, --Sam From owner-ietf-sasl Sat Oct 2 12:27:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JRwgL050442; Sat, 2 Oct 2004 12:27:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92JRwZV050441; Sat, 2 Oct 2004 12:27:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JRuIC050432 for ; Sat, 2 Oct 2004 12:27:56 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i92JRoZv073801; Sat, 2 Oct 2004 19:27:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041002121256.0419c878@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 02 Oct 2004 12:27:46 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Simon Josefsson , ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@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:52 AM 10/2/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> be verified. The precise form of the authorization identity > Kurt> is, excepting the Unicode restriction, is a application > Kurt> protocol detail. > > >This isn't quite right. By "form" above, I am referring to the shape of the Unicode string and not the encoding of that Unicode string. The shape (Kerberos principal, LDAP DN, LDAP authzid, email address, etc.) of the string is an application protocol matter, its encoding (UTF-8, UTF-32, other) is a mechanism matter. >The form of the requested authorization >identity--the bits that are transferred over the wire--is a mechanism >detail. The protocol profile feeds in unicode codepoints and the >mechanism decides how those codepoints will appear on the wire. The >semantics of these codepoints is what is a protocol detail. From owner-ietf-sasl Tue Oct 5 05:59:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Cxeax010837; Tue, 5 Oct 2004 05:59:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95CxeWk010836; Tue, 5 Oct 2004 05:59:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95CxcQv010827 for ; Tue, 5 Oct 2004 05:59:39 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CEoum-0000Z2-SN for ietf-sasl@imc.org; Tue, 05 Oct 2004 14:59:37 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CEoue-0007l9-Ej; Tue, 05 Oct 2004 14:59:28 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CEoud-0002CQ-00; Tue, 5 Oct 2004 14:59:27 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 5 Oct 2004 14:59:27 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Fixes to my previous comments, and comments to the rest of the draft. I wrote: > Subject: rfc2222bis-08 comments >> 3.2. Authorization and authentication identities >> 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. > (...) > Please clarify that the authorization ID is checked during the > authentication (as section 3.2.1 says). And local policy is used to > either derive the authorization identity or check it. Sorry, s/check(ed)/authorize(d)/ is probably better. >> Any normalization of the authentication identity is defined by a >> particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. Or rather, the protocol or its implementation may do that. >> 3.3. Security layers >> Note that all SASL mechanisms that are unable to negotiate a security >> layer automatically select no security layer. > > Without checking up the 'selects no security layer' thread, I still > can't tell if this says that such a mechanism cancels an old security > layer or if it says that it doesn't affect it. I'll check that later, > unless someone replies first. ...and Section 6.3 clarified it, now that I have gotten that far. ================================================================ > 3. Authentication mechanisms > sasl-mech = 1*20mech-char > mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE > ; mech-char is restricted to "A"-"Z", "0"-"9", "-", > ; and "_" from ASCII character set. In most standards, tokens like sasl-mech cannot start with a hyphen; often they must start with a letter. Prevents problems e.g. with programs that are overeager about extracting command line arguments, or utilities which notice token-like strings in general without an exact idea of what kind of token it is (e.g. click&cut&paste). Is there any reason sasl-mech is different? > 4. Protocol profile requirements > Note that an additional data with success can't be empty. I suggest "Note that if additional data is sent with success, it can't be empty." to clarify that one can send success without additional data. At least that's what I assume it means. The sentence as quoted above confused me: I could see no reason why one must always send additional data with success:-) > 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. That uppercase "MAY" gives the impression that this is the only other option: It may not a more lax stringprep profile, or an entirely different way to prepare. > 5. Mechanism profile guidelines > 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 MUST fail the authentication exchange. I expect preparation of an empty string should not fail, so: s/results in/turns a non-empty string into/. > 6.1. Client sends data first > 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.) Then protocols that support an initial response must be clear on how to distinguish an absent initial response from a present but empty initial response. I expect their protocol profiles must also specify whether or not the protocol _can_ distinguish the two, so the mechanism can tell whether or not to send empty initial responses. Protocol example: A line-oriented protocol similar to SMTP where the client sends commands with space-separated arguments, and servers strip trailing spaces from client command lines. Mechanism example: EXTERNAL with authorization ID = empty string. > 6.2. Server returns success with 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. I don't quite understand. I would have thought that if an attacker can do that, he can also wait for the final client response and then start accessing the server, pretending to be the client. Maybe that just shows my ignorance of the subject, but many other readers will be equally ignorant. > 7. The EXTERNAL mechanism > The client sends a single message containing the UTF-8 encoding of > the authorization identity. The message may be empty. s/message/response/ the first time, s/message/authorization identity/ the second time? See my comments above about empty initial response. > Appendix C. Changes since RFC 2222 > The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has > been removed. I just noticed that has no pointer to the definition of the KERBEROS_V5 mechanism. Its registration only lists a person (Simon Josefsson). The same is true for some other mechanisms. Why is that? -- Hallvard From owner-ietf-sasl Tue Oct 5 07:33:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EXBkb019243; Tue, 5 Oct 2004 07:33:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95EXBff019242; Tue, 5 Oct 2004 07:33:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EXAd9019229 for ; Tue, 5 Oct 2004 07:33:10 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CEqNI-00028W-HZ; Tue, 05 Oct 2004 16:33:08 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CEqNE-0000wR-5a; Tue, 05 Oct 2004 16:33:04 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CEqNC-0002Ps-00; Tue, 5 Oct 2004 16:33:02 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> References: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 5 Oct 2004 16:33:02 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >>> Abstract >> >>> The Simple Authentication and Security Layer (SASL) is a framework >>> for providing authentication and data security services in >>> connection-oriented protocols via replaceable >> >>authentication > > The sentence might be more clear if worded: > The Simple Authentication and Security Layer (SASL) is > a framework for providing authentication and data security > services via replaceable mechanisms to connection-oriented > protocols. I don't think so; it looks a little strange to have the 'to...' after the 'via...'. Maybe s/in/to/ would improve the original sentence. I've asked a coworker what he thought the Abstract meant: He got it more or less right, but was somewhat vague about it and thought it was a bit hard to get. He did not think my suggested extra words would make a difference. -- Hallvard From owner-ietf-sasl Sun Oct 10 15:42:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AMg31s006769; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9AMg3FA006768; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-FORTY-THREE.MIT.EDU [18.187.6.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AMg30J006761 for ; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 94B1F168025; Sun, 10 Oct 2004 18:42:10 -0400 (EDT) To: ietf-sasl@imc.org Subject: Making forward progress From: Sam Hartman Date: Sun, 10 Oct 2004 18:42:10 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've seen no objections to Kurt's new summary of the identities issue nor to his proposed text for section 3. I think we should move forward with that change. Alexey, how much help do you need dealing with implications of this change for the rest of the document? Also, are there ny of Hallvard's comments that you have questions about or that you believe require more WG discussion? --Sam From owner-ietf-sasl Tue Oct 12 06:30:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CDUnPA033640; Tue, 12 Oct 2004 06:30:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CDUnPv033639; Tue, 12 Oct 2004 06:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CDUlAJ033632 for ; Tue, 12 Oct 2004 06:30:48 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 14:30:52 +0100 Message-ID: <416BDC8C.8060906@isode.com> Date: Tue, 12 Oct 2004 14:30:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Making forward progress References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: >I've seen no objections to Kurt's new summary of the identities issue >nor to his proposed text for section 3. I think we should move >forward with that change. > > Sounds good. >Alexey, how much help do you need dealing with implications of this >change for the rest of the document? > > I will need somebody's help to review my changes once I am done. >Also, are there any of Hallvard's comments that you have questions >about or that you believe require more WG discussion? > > I haven't looked very attentively, but at this time I think most issues/questions are straightforward. Let me cautiously promise to have another revision by October 25. Cautiously, because I need to submit 3 more documents in other WGs by the same date. Alexey From owner-ietf-sasl Tue Oct 12 08:52:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFqAFn047576; Tue, 12 Oct 2004 08:52:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CFqADW047575; Tue, 12 Oct 2004 08:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFq8rk047566 for ; Tue, 12 Oct 2004 08:52:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 16:52:10 +0100 Message-ID: <416BFDAA.3090507@isode.com> Date: Tue, 12 Oct 2004 16:52:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040303010201000505010401" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------040303010201000505010401 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>3. Authentication mechanisms >> >> sasl-mech = 1*20mech-char >> mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE >> ; mech-char is restricted to "A"-"Z", "0"-"9", "-", >> ; and "_" from ASCII character set. >> >> > >In most standards, tokens like sasl-mech cannot start with a hyphen; >often they must start with a letter. Prevents problems e.g. with >programs that are overeager about extracting command line arguments, or >utilities which notice token-like strings in general without an exact >idea of what kind of token it is (e.g. click&cut&paste). Is there any >reason sasl-mech is different? > I see your point, but at this time I would rather not change this. Just in case somebody has designed and deployed a mechanism that starts with "_" or "-". >>4. Protocol profile requirements >> >> >> Note that an additional data with success can't be empty. >> > >I suggest > "Note that if additional data is sent with success, it can't be empty." >to clarify that one can send success without additional data. At least >that's what I assume it means. The sentence as quoted above confused >me: I could see no reason why one must always send additional data with >success:-) > Ok and fixed. >> 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. >> >> > >That uppercase "MAY" gives the impression that this is the only other >option: It may not a more lax stringprep profile, or an entirely >different way to prepare. > This MAY is just fine according to [KEYWORDS] (RFC 2119). I am not sure how this can be improved. The reason for having the MAY is to emphasize that this is actually considered a reasonable thing to do. >>5. Mechanism profile guidelines >> >> 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 MUST fail the authentication exchange. >> >> > >I expect preparation of an empty string should not fail, so: >s/results in/turns a non-empty string into/. > > This text is talking about authentication identities and passwords. I am not sure whether the empty string should be allowed. >>6.1. Client sends data first >> >> >> 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.) >> >> > >Then protocols that support an initial response must be clear on how to >distinguish an absent initial response from a present but empty initial >response. I expect their protocol profiles must also specify whether or >not the protocol _can_ distinguish the two, so the mechanism can tell >whether or not to send empty initial responses. > This is described in Section 4, bullet # 2. > >Protocol example: A line-oriented protocol similar to SMTP where the >client sends commands with space-separated arguments, and servers strip >trailing spaces from client command lines. > >Mechanism example: EXTERNAL with authorization ID = empty string. > > > >>6.2. Server returns success with 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. >> >> > >I don't quite understand. I would have thought that if an attacker can >do that, he can also wait for the final client response and then start >accessing the server, pretending to be the client. Maybe that just >shows my ignorance of the subject, but many other readers will be >equally ignorant. > What you are saying might be true, but I don't think it is relevant for the section you've quoted. By the time the server has sent a fake (or wrong) "additional data with success", it is too late: the client has already provided its credentials to the server. >>7. The EXTERNAL mechanism >> >> >> The client sends a single message containing the UTF-8 encoding of >> the authorization identity. The message may be empty. >> >> > >s/message/response/ the first time, >s/message/authorization identity/ the second time? > > I actually prefer to keep the informal term message here. >See my comments above about empty initial response. > > >>Appendix C. Changes since RFC 2222 >> >> >> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >> been removed. >> > >I just noticed that >has no pointer to the definition of the KERBEROS_V5 mechanism. Its >registration only lists a person (Simon Josefsson). The same is true >for some other mechanisms. Why is that? > There is no reference, because there is no RFC. I think one can ask IANA to add one. Alexey --------------040303010201000505010401 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
3.    Authentication mechanisms    
   sasl-mech    = 1*20mech-char
   mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
                  ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
                  ; and "_" from ASCII character set.
    

In most standards, tokens like sasl-mech cannot start with a hyphen;
often they must start with a letter.  Prevents problems e.g. with
programs that are overeager about extracting command line arguments, or
utilities which notice token-like strings in general without an exact
idea of what kind of token it is (e.g. click&cut&paste).  Is there any
reason sasl-mech is different?
I see your point, but at this time I would rather not change this. Just in case somebody has designed and deployed a mechanism that starts with "_" or "-". 
4.    Protocol profile requirements
    
   Note that an additional data with success can't be empty. 

I suggest
  "Note that if additional data is sent with success, it can't be empty."
to clarify that one can send success without additional data.  At least
that's what I assume it means.  The sentence as quoted above confused
me: I could see no reason why one must always send additional data with
success:-)
Ok and fixed. 
   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.
    

That uppercase "MAY" gives the impression that this is the only other
option:  It may not a more lax stringprep profile, or an entirely
different way to prepare.
This MAY is just fine according to [KEYWORDS] (RFC 2119).
I am not sure how this can be improved.

The reason for having the MAY is to emphasize that this is actually considered a reasonable thing to do.
5.    Mechanism profile guidelines    
   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 MUST fail the authentication exchange.
    

I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
This text is talking about authentication identities and passwords. I am not sure whether the empty string should be allowed. 
6.1.  Client sends data first
    
   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.)
    

Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.
This is described in Section 4, bullet # 2.

Protocol example: A line-oriented protocol similar to SMTP where the
client sends commands with space-separated arguments, and servers strip
trailing spaces from client command lines.

Mechanism example: EXTERNAL with authorization ID = empty string.

  
6.2.  Server returns success with 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.
    

I don't quite understand.  I would have thought that if an attacker can
do that, he can also wait for the final client response and then start
accessing the server, pretending to be the client.  Maybe that just
shows my ignorance of the subject, but many other readers will be
equally ignorant.
What you are saying might be true, but I don't think it is relevant for the section you've quoted. By the time the server has sent a fake (or wrong) "additional data with success", it is too late: the client has already provided its credentials to the server. 
7.    The EXTERNAL mechanism
    
   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
    

s/message/response/ the first time,
s/message/authorization identity/ the second time?
I actually prefer to keep the informal term message here.
See my comments above about empty initial response.
  
Appendix C. Changes since RFC 2222
    
   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.    

I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?
There is no reference, because there is no RFC. I think one can ask IANA to add one.

Alexey

--------------040303010201000505010401-- From owner-ietf-sasl Tue Oct 12 10:12:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHCqSH056492; Tue, 12 Oct 2004 10:12:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CHCqfX056491; Tue, 12 Oct 2004 10:12:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CHCoa9056480 for ; Tue, 12 Oct 2004 10:12:51 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa04450; 12 Oct 2004 13:12 EDT Date: Tue, 12 Oct 2004 13:12:51 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <107890000.1097601171@minbar.fac.cs.cmu.edu> In-Reply-To: <416BFDAA.3090507@isode.com> References: <416BFDAA.3090507@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 Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov wrote: > Hallvard B Furuseth wrote: > >>> 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. >>> >>> >> >> That uppercase "MAY" gives the impression that this is the only other >> option: It may not a more lax stringprep profile, or an entirely >> different way to prepare. >> > This MAY is just fine according to [KEYWORDS] (RFC 2119). > I am not sure how this can be improved. > > The reason for having the MAY is to emphasize that this is actually > considered a reasonable thing to do. Try this: Profiles MAY use a stringprep profile other than SASLprep, or none at all. >>> 6.2. Server returns success with 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. >>> >>> >> >> I don't quite understand. I would have thought that if an attacker can >> do that, he can also wait for the final client response and then start >> accessing the server, pretending to be the client. Maybe that just >> shows my ignorance of the subject, but many other readers will be >> equally ignorant. >> > What you are saying might be true, but I don't think it is relevant for > the section you've quoted. By the time the server has sent a fake (or > wrong) "additional data with success", it is too late: the client has > already provided its credentials to the server. But the same is true even if you don't support "additional data with success". By the time the server sends the last data, the client has _still_ already sent its credentials to the server. In either case the client cannot abort the exchange, because the MitM attacker simply won't forward that part. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Tue Oct 12 10:39:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHdCq8058886; Tue, 12 Oct 2004 10:39:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CHdCZ4058885; Tue, 12 Oct 2004 10:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHdBNd058879 for ; Tue, 12 Oct 2004 10:39:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 18:39:18 +0100 Message-ID: <416C16C5.3090809@isode.com> Date: Tue, 12 Oct 2004 18:39:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> In-Reply-To: <107890000.1097601171@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov > wrote: > >> Hallvard B Furuseth wrote: >> >>>> 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. >>> >>> >>> That uppercase "MAY" gives the impression that this is the only other >>> option: It may not a more lax stringprep profile, or an entirely >>> different way to prepare. >>> >> This MAY is just fine according to [KEYWORDS] (RFC 2119). >> I am not sure how this can be improved. >> >> The reason for having the MAY is to emphasize that this is actually >> considered a reasonable thing to do. > > Try this: > > Profiles MAY use a stringprep profile other than SASLprep, or none at > all. I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep + additional restrictions) is a common case. >>>> 6.2. Server returns success with 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. >>> >>> I don't quite understand. I would have thought that if an attacker can >>> do that, he can also wait for the final client response and then start >>> accessing the server, pretending to be the client. Maybe that just >>> shows my ignorance of the subject, but many other readers will be >>> equally ignorant. >>> >> What you are saying might be true, but I don't think it is relevant for >> the section you've quoted. By the time the server has sent a fake (or >> wrong) "additional data with success", it is too late: the client has >> already provided its credentials to the server. > > But the same is true even if you don't support "additional data with > success". By the time the server sends the last data, the client has > _still_ already sent its credentials to the server. In either case > the client cannot abort the exchange, because the MitM attacker simply > won't forward that part. I agree with you. The point of the paragraph is to say that with additional data with success the client is *not able* to abort SASL exchange, thus it has to disconnect. From owner-ietf-sasl Tue Oct 12 11:17:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIHRAc062083; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CIHR0O062082; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIHQNt062076 for ; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D5034E0053; Tue, 12 Oct 2004 14:17:58 -0400 (EDT) To: Jeffrey Hutzelman Cc: Alexey Melnikov , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Tue, 12 Oct 2004 14:17:58 -0400 In-Reply-To: <107890000.1097601171@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 12 Oct 2004 13:12:51 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Jeffrey> Melnikov Jeffrey> wrote: >> Hallvard B Furuseth wrote: >>>> 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. >>>> >>>> >>> That uppercase "MAY" gives the impression that this is the >>> only other option: It may not a more lax stringprep profile, >>> or an entirely different way to prepare. >>> >> This MAY is just fine according to [KEYWORDS] (RFC 2119). I am >> not sure how this can be improved. >> >> The reason for having the MAY is to emphasize that this is >> actually considered a reasonable thing to do. Jeffrey> Try this: Jeffrey> Profiles MAY use a stringprep profile other than Jeffrey> SASLprep, or none at all. I prefer the text currently in the draft to your proposed text. From owner-ietf-sasl Tue Oct 12 14:39:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLdA4o080187; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CLdAIZ080186; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLd9Lo080174 for ; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CHUMW-0006sq-Jv; Tue, 12 Oct 2004 23:39:16 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHUMR-0007Qe-OK; Tue, 12 Oct 2004 23:39:11 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHUMO-0005aB-00; Tue, 12 Oct 2004 23:39:08 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416BFDAA.3090507@isode.com> References: <416BFDAA.3090507@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 12 Oct 2004 23:39:08 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>> 3. Authentication mechanisms >>> >>> sasl-mech = 1*20mech-char >>> mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE >>> ; mech-char is restricted to "A"-"Z", "0"-"9", "-", >>> ; and "_" from ASCII character set. >> >> In most standards, tokens like sasl-mech cannot start with a hyphen; >> often they must start with a letter. Prevents problems e.g. with >> programs that are overeager about extracting command line arguments, or >> utilities which notice token-like strings in general without an exact >> idea of what kind of token it is (e.g. click&cut&paste). Is there any >> reason sasl-mech is different? >> > I see your point, but at this time I would rather not change this. Just > in case somebody has designed and deployed a mechanism that starts with > "_" or "-". OK. >>> 5. Mechanism profile guidelines >>> >>> 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 MUST fail the authentication exchange. >> >> I expect preparation of an empty string should not fail, so: >> s/results in/turns a non-empty string into/. > > This text is talking about authentication identities and passwords. I am > not sure whether the empty string should be allowed. I can see nothing which forbids it, neither in rfc2222 nor 2222bis. I have certainly set empty passwords on Unix boxes (off the net); if there is a SASL library which allows empty passwords then I assume people have found use for them with SASL too. I expect an empty authentication IDs would be messier, unless the authorization ID which is derived from that ID is non-empty. >>> 6.1. Client sends data first >>> >>> 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.) >> >> Then protocols that support an initial response must be clear on how to >> distinguish an absent initial response from a present but empty initial >> response. I expect their protocol profiles must also specify whether or >> not the protocol _can_ distinguish the two, so the mechanism can tell >> whether or not to send empty initial responses. >> > This is described in Section 4, bullet # 2. No... First, it's only a SHOULD: If the protocol allows for the initial response, the protocol profile SHOULD also describe how an empty initial response is encoded. Second, if that sentence is intended to address this issue, I can think of two different things it can imply in order to do so. It is not at all clear to me that it means either: 1) "If the protocol profile does not say how an initial response is encoded, then empty but present initial responses are not supported." 2) If you s/SHOULD/MUST/: "If initial responses are supported, then it MUST be possible to send an empty initial response which can be distinguished from no initial response." >>> 7. The EXTERNAL mechanism >>> >>> The client sends a single message containing the UTF-8 encoding of >>> the authorization identity. The message may be empty. >> >> s/message/response/ the first time, >> s/message/authorization identity/ the second time? > > I actually prefer to keep the informal term message here. Well, I'll see how empty initial responses turn out... >> See my comments above about empty initial response. >>> Appendix C. Changes since RFC 2222 >>> >>> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >>> been removed. >> >> I just noticed that >> has no pointer to the definition of the KERBEROS_V5 mechanism. Its >> registration only lists a person (Simon Josefsson). The same is true >> for some other mechanisms. Why is that? > > There is no reference, because there is no RFC. I think one can ask IANA > to add one. If there is a standard or "official document" or something for a mechanism, RFC or not, my vote is to at least mention it. When I'm walking through standards and definitions of something I'm working with, it's always annoying when there is suddenly no reference to where to go from there. As with Kerberos5, Googling around will often find competing texts that may or may not be or reflect the "official" standard. Or I can ask (if I knows where), but then I have to sit and wait for someone to answer, and sometimes there is no telling how reliable the respondent is. -- Hallvard From owner-ietf-sasl Tue Oct 12 14:49:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLnY0K080772; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CLnYqb080771; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLnXIN080763 for ; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CHUWc-0002Qv-N6; Tue, 12 Oct 2004 23:49:42 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHUWZ-0006sr-Th; Tue, 12 Oct 2004 23:49:39 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHUWZ-0005bk-00; Tue, 12 Oct 2004 23:49:39 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416C16C5.3090809@isode.com> References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 12 Oct 2004 23:49:39 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Jeffrey Hutzelman wrote: >> wrote: >>>Hallvard B Furuseth wrote: >>> >>>>> 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. >>>> >>>> That uppercase "MAY" gives the impression that this is the only other >>>> option: It may not a more lax stringprep profile, or an entirely >>>> different way to prepare. >>>> >>> This MAY is just fine according to [KEYWORDS] (RFC 2119). >>> I am not sure how this can be improved. >>> >>> The reason for having the MAY is to emphasize that this is actually >>> considered a reasonable thing to do. >> >> Try this: >> >> Profiles MAY use a stringprep profile other than SASLprep, or none at >> all. > > I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep > + additional restrictions) is a common case. Profiles whose (...) SHOULD use SASLPrep or a stricter stringprep profile, but MAY use other stringprep profiles or none at all? From owner-ietf-sasl Tue Oct 12 15:38:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CMcui7084034; Tue, 12 Oct 2004 15:38:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CMcu5G084033; Tue, 12 Oct 2004 15:38:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CMcsC2084027 for ; Tue, 12 Oct 2004 15:38:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 748BDE0053; Tue, 12 Oct 2004 18:39:24 -0400 (EDT) To: Hallvard B Furuseth Cc: Alexey Melnikov , Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> From: Sam Hartman Date: Tue, 12 Oct 2004 18:39:24 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Tue, 12 Oct 2004 23:49:39 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not really sure it's OK for a protocol to use no stringprep profile at all. Especially for an IETF protocol I'm not sure I can think of situations where the right technical solution would not involve stringprep of some kind. From owner-ietf-sasl Wed Oct 13 01:07:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D87qA5089691; Wed, 13 Oct 2004 01:07:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D87qGm089690; Wed, 13 Oct 2004 01:07:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D87o5n089652 for ; Wed, 13 Oct 2004 01:07:51 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHeAy-00040L-KV for ietf-sasl@imc.org; Wed, 13 Oct 2004 10:08:01 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHeAf-0007ms-Rt; Wed, 13 Oct 2004 10:07:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHeAf-0007Kc-00; Wed, 13 Oct 2004 10:07:41 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis Appendix C Date: Wed, 13 Oct 2004 10:07:41 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Appendix C (Changes since RFC 2222) includes an extract of changes between various rfc2222/rfc2222bis versions, rather than just changes since RFC 2222. Examples: Replaced UTF-8 ABNF with the reference to the UTF-8 document. RFC 2222 did not refer to UTF-8 at all. OTOH, the new UTF-8 MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned. Replaced "buffers of security encoded data" with "buffers of protected data" for clarity. That first phrase does not occur in rfc2222. Made requirement to verify that an authorization identity is correct by performing SASLprep a SHOULD, instead of a MUST. rfc2222 does not contain a single MUST. And if that SHOULD is the one in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is correct, not that the ID itself is correct. Another detail: The "SKEY" mechanism described in RFC 2222 is obsolete and has been removed. It has been replaced by the OTP mechanism [SASL-OTP]. This is the only mention of [SASL-OTP] outside of the References section. Is that intentional? -- Hallvard From owner-ietf-sasl Wed Oct 13 02:56:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9uXab028557; Wed, 13 Oct 2004 02:56:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D9uXY6028556; Wed, 13 Oct 2004 02:56:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9uVxa028537 for ; Wed, 13 Oct 2004 02:56:32 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 10:56:43 +0100 Message-ID: <416CFBDA.8000707@isode.com> Date: Wed, 13 Oct 2004 10:56:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000907060501040307020905" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------000907060501040307020905 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>>>6.1. Client sends data first >>>> >>>> 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.) >>>> >>>> >>>Then protocols that support an initial response must be clear on how to >>>distinguish an absent initial response from a present but empty initial >>>response. I expect their protocol profiles must also specify whether or >>>not the protocol _can_ distinguish the two, so the mechanism can tell >>>whether or not to send empty initial responses. >>> >>> >> This is described in Section 4, bullet # 2. >> >> > >No... First, it's only a SHOULD: > > If the protocol allows for the initial response, the protocol profile > SHOULD also describe how an empty initial response is encoded. > > I've already changed SHOULD to MUST. This issue was raised during WGLC. >Second, if that sentence is intended to address this issue, I can think >of two different things it can imply in order to do so. It is not at >all clear to me that it means either: > >1) "If the protocol profile does not say how an initial response is > encoded, then empty but present initial responses are not supported." > > >2) If you s/SHOULD/MUST/: "If initial responses are supported, then it > MUST be possible to send an empty initial response which can be > distinguished from no initial response." > > The intention was to say #2. I am not aware of any protocol profile that supports initial response, but doesn't allow for it being empty. >>>>7. The EXTERNAL mechanism >>>> >>>> The client sends a single message containing the UTF-8 encoding of >>>> the authorization identity. The message may be empty. >>>> >>>> >>>s/message/response/ the first time, >>>s/message/authorization identity/ the second time? >>> >>> >> I actually prefer to keep the informal term message here. >> >> > >Well, I'll see how empty initial responses turn out... > > >>>See my comments above about empty initial response. >>> >>> >>>>Appendix C. Changes since RFC 2222 >>>> >>>> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >>>> been removed. >>>> >>>> >>>I just noticed that >>>has no pointer to the definition of the KERBEROS_V5 mechanism. Its >>>registration only lists a person (Simon Josefsson). The same is true >>>for some other mechanisms. Why is that? >>> >>> >> There is no reference, because there is no RFC. I think one can ask IANA >> to add one. >> >> > >If there is a standard or "official document" or something for a >mechanism, RFC or not, my vote is to at least mention it. When I'm >walking through standards and definitions of something I'm working with, >it's always annoying when there is suddenly no reference to where to go >from there. As with Kerberos5, Googling around will often find >competing texts that may or may not be or reflect the "official" >standard. Or I can ask (if I knows where), but then I have to sit and >wait for someone to answer, and sometimes there is no telling how >reliable the respondent is. > > For KERBEROS_V5 registration you need to send a email to Simon, he is the authoritative source of information. It would be even better if you ask him to update the registration. Alexey --------------000907060501040307020905 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
6.1.  Client sends data first

   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.)
        
Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.
      
 This is described in Section 4, bullet # 2.
    

No...  First, it's only a SHOULD:

   If the protocol allows for the initial response, the protocol profile
   SHOULD also describe how an empty initial response is encoded.
I've already changed SHOULD to MUST. This issue was raised during WGLC.
Second, if that sentence is intended to address this issue, I can think
of two different things it can imply in order to do so.  It is not at
all clear to me that it means either:

1) "If the protocol profile does not say how an initial response is
   encoded, then empty but present initial responses are not supported."
  
2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
   MUST be possible to send an empty initial response which can be
   distinguished from no initial response."
The intention was to say #2. I am not aware of any protocol profile that supports initial response, but doesn't allow for it being empty.
7.    The EXTERNAL mechanism

   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
        
s/message/response/ the first time,
s/message/authorization identity/ the second time?
      
 I actually prefer to keep the informal term message here.
    

Well, I'll see how empty initial responses turn out...
  
See my comments above about empty initial response.
      
Appendix C. Changes since RFC 2222

   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.   
        
I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?
      
 There is no reference, because there is no RFC. I think one can ask IANA
 to add one.
    

If there is a standard or "official document" or something for a
mechanism, RFC or not, my vote is to at least mention it.  When I'm
walking through standards and definitions of something I'm working with,
it's always annoying when there is suddenly no reference to where to go
from there.  As with Kerberos5, Googling around will often find
competing texts that may or may not be or reflect the "official"
standard.  Or I can ask (if I knows where), but then I have to sit and
wait for someone to answer, and sometimes there is no telling how
reliable the respondent is.
For KERBEROS_V5 registration you need to send a email to Simon, he is the authoritative source of information. It would be even better if you ask him to update the registration.

Alexey

--------------000907060501040307020905-- From owner-ietf-sasl Wed Oct 13 03:27:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DARPn4041920; Wed, 13 Oct 2004 03:27:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DARPwi041919; Wed, 13 Oct 2004 03:27:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DAROoP041901 for ; Wed, 13 Oct 2004 03:27:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 11:27:37 +0100 Message-ID: <416D0318.2080103@isode.com> Date: Wed, 13 Oct 2004 11:27:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >I think Appendix C (Changes since RFC 2222) includes an extract of >changes between various rfc2222/rfc2222bis versions, rather than just >changes since RFC 2222. > That is correct. Question to the WG: should I clean up the Appendix C or should I wait till the document is approved for publication? >[...] > >Another detail: > > The "SKEY" mechanism described in RFC 2222 is obsolete and has been > removed. It has been replaced by the OTP mechanism [SASL-OTP]. > >This is the only mention of [SASL-OTP] outside of the References >section. Is that intentional? > > [SASL-OTP] is mentioned in 10.2 (Informative references). From owner-ietf-sasl Wed Oct 13 07:11:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEB43p082754; Wed, 13 Oct 2004 07:11:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEB4Iv082753; Wed, 13 Oct 2004 07:11:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEB2S5082746 for ; Wed, 13 Oct 2004 07:11:03 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06405; 13 Oct 2004 10:11 EDT Date: Wed, 13 Oct 2004 10:11:13 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Hallvard B Furuseth cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <445910000.1097676673@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@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 Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman wrote: > > I'm not really sure it's OK for a protocol to use no stringprep > profile at all. > > Especially for an IETF protocol I'm not sure I can think of situations > where the right technical solution would not involve stringprep of > some kind. What an application's SASL profile says about the form and preparation of authorization names will always depend on what the application protocol does in a broader sense. For applications which use some sort of string for identity and authorization, the SASL profile should specify use of the same string, with the same behaviours and semantics. That means if the application does not use stringprep on authorization ID's used, say, in manipulating ACL's, then it should not use it on SASL authorization ID's either. Also, I can think of a scenario in which the right solution does not involve any form of stringprep. Consider an application which does identity and access control using UUID's rather than strings. I do not believe there is anything in SASL that would prevent this use. I agree that when applications use strings to identify users, they should use some form of stringprep. I agree that in many such cases, it would be appropriate to use SASLprep rather than constructing a separate stringprep profile for that application. However, mandating the use of stringprep in application protocols is out of scope for this working group, and I believe that it is more important that SASL authorization ID's have the same semantics as those used elsewhere in the application than that they have the same semantics as other strings used in SASL. -- Jeff From owner-ietf-sasl Wed Oct 13 07:14:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEEJul083204; Wed, 13 Oct 2004 07:14:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEEJbi083203; Wed, 13 Oct 2004 07:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEEH90083197 for ; Wed, 13 Oct 2004 07:14:18 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06409; 13 Oct 2004 10:14 EDT Date: Wed, 13 Oct 2004 10:14:27 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C Message-ID: <446620000.1097676867@minbar.fac.cs.cmu.edu> In-Reply-To: <416D0318.2080103@isode.com> References: <416D0318.2080103@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, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: > > Hallvard B Furuseth wrote: > >> I think Appendix C (Changes since RFC 2222) includes an extract of >> changes between various rfc2222/rfc2222bis versions, rather than just >> changes since RFC 2222. >> > That is correct. > > Question to the WG: should I clean up the Appendix C or should I wait > till the document is approved for publication? This section is essentially a changelog. Normally, such sections are intended for use during the development of a document, and carry a note to the RFC-Editor asking that they be removed prior to publication. I think that would be the apporpriate thing to do in this case. -- Jeff From owner-ietf-sasl Wed Oct 13 07:17:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEHG8A083552; Wed, 13 Oct 2004 07:17:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEHGiu083551; Wed, 13 Oct 2004 07:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEHFUS083544 for ; Wed, 13 Oct 2004 07:17:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 15:17:27 +0100 Message-ID: <416D38F6.6070403@isode.com> Date: Wed, 13 Oct 2004 15:17:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> In-Reply-To: <446620000.1097676867@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov > wrote: > >> Hallvard B Furuseth wrote: >> >>> I think Appendix C (Changes since RFC 2222) includes an extract of >>> changes between various rfc2222/rfc2222bis versions, rather than just >>> changes since RFC 2222. >> >> That is correct. >> >> Question to the WG: should I clean up the Appendix C or should I wait >> till the document is approved for publication? > > This section is essentially a changelog. Yes. > Normally, such sections are intended for use during the development of > a document, and carry a note to the RFC-Editor asking that they be > removed prior to publication. I think that would be the apporpriate > thing to do in this case. I disagree. I find such section quite useful when one has to quickly find out about changes since an older RFC. From owner-ietf-sasl Wed Oct 13 07:22:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEMcMa084326; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEMc2n084325; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEMbGc084318 for ; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06416; 13 Oct 2004 10:22 EDT Date: Wed, 13 Oct 2004 10:22:48 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth , Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <452140000.1097677368@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@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 Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth wrote: > If there is a standard or "official document" or something for a > mechanism, RFC or not, my vote is to at least mention it. In the case of KERBEROS_V5, there is not. There may be an internet-draft, though I expect it has expired by now if Simon is not still actively working on the mechanism. Internet-drafts are by their nature ephemeral and therefore do not make stable references. Published RFC's may not contain references to internet-drafts. > When I'm > walking through standards and definitions of something I'm working with, > it's always annoying when there is suddenly no reference to where to go > from there. It is not necessary, appropriate, or even possible for the SASL base document to include an exhaustive list of SASL mechanisms. This is hardly the first "framework" document to include support for multiple mechanisms, and the normal practice is to make reference to specific mechanisms only when they are REQUIRED or RECOMMENDED, or when such a reference is needed to illustrate a concept described in the framework. It is worth noting that as with any "framework" defined by the IETF, there _is_ an exhaustive list of all mechanisms, which is maintained by the IANA. IANA registries generally include a pointer to a contact person and/or to a published specification, if there is one. There is no "official" standard KERBEROS_V5 mechanism. I refer you to the following paragraph, which appears as part of the boilerplate at the top of every internet-draft: 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''. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Wed Oct 13 07:42:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEge2I086965; Wed, 13 Oct 2004 07:42:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEgeY7086964; Wed, 13 Oct 2004 07:42:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEgdc4086957 for ; Wed, 13 Oct 2004 07:42:39 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 39309767A4; Wed, 13 Oct 2004 10:42:39 -0400 (EDT) To: Jeffrey Hutzelman Cc: Hallvard B Furuseth , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> <445910000.1097676673@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 13 Oct 2004 10:42:38 -0400 In-Reply-To: <445910000.1097676673@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 13 Oct 2004 10:11:13 -0400") Message-ID: <871xg27k81.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman Jeffrey> wrote: >> I'm not really sure it's OK for a protocol to use no >> stringprep profile at all. >> >> Especially for an IETF protocol I'm not sure I can think of >> situations where the right technical solution would not involve >> stringprep of some kind. Jeffrey> What an application's SASL profile says about the form Jeffrey> and preparation of authorization names will always depend Jeffrey> on what the application protocol does in a broader sense. Jeffrey> For applications which use some sort of string for Jeffrey> identity and authorization, the SASL profile should Jeffrey> specify use of the same string, with the same behaviours Jeffrey> and semantics. That means if the application does not Jeffrey> use stringprep on authorization ID's used, say, in Jeffrey> manipulating ACL's, then it should not use it on SASL Jeffrey> authorization ID's either. Jeffrey> Also, I can think of a scenario in which the right Jeffrey> solution does not involve any form of stringprep. Jeffrey> Consider an application which does identity and access Jeffrey> control using UUID's rather than strings. I do not Jeffrey> believe there is anything in SASL that would prevent this Jeffrey> use. True. But what you can do is somewhat constrained by the IESG for standards-track documents. I believe that MAY use no stringprep is technically true but is also too strong of a statement. --Sam From owner-ietf-sasl Wed Oct 13 08:08:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DF8RKo090282; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DF8Rjv090281; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DF8Qpo090263 for ; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHkk1-000266-DJ; Wed, 13 Oct 2004 17:08:38 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHkjy-0000ha-0a; Wed, 13 Oct 2004 17:08:34 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHkjx-0000Wt-00; Wed, 13 Oct 2004 17:08:33 +0200 From: Hallvard B Furuseth Message-Id: To: Jeffrey Hutzelman Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <452140000.1097677368@minbar.fac.cs.cmu.edu> References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Oct 2004 17:08:33 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: >On Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth > wrote: > >> (...internet-draft KERBEROS_V5...) >> >> When I'm >> walking through standards and definitions of something I'm working with, >> it's always annoying when there is suddenly no reference to where to go >> from there. > > It is not necessary, appropriate, or even possible for the SASL base > document to include an exhaustive list of SASL mechanisms. You have lost the context. I was talking about a reference - formal or informal - in the IANA registry, not rfc2222bis. But back to rfc2222bis: > There is no "official" standard KERBEROS_V5 mechanism. Then it seems strange to me to remove KERBEROS_V4 without further comment when there is no standard replacement - in particular since SASL was born around Kerberos and S/Key, according to the mailinglist archive. I suggest to add a purely informational sentence or two about why this was done and that an informal Kerberos5 exists. And if V4- support was removed because of a security flaw in that version, warn that one really shouldn't keep support for it. (Maybe the same applies to S/Key, but I know even less about that than about Kerberos.) -- Hallvard From owner-ietf-sasl Wed Oct 13 08:19:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFJJXr092391; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFJJ7I092390; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DFJIdn092383 for ; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06459; 13 Oct 2004 11:19 EDT Date: Wed, 13 Oct 2004 11:19:04 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <490070000.1097680744@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> 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, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth wrote: > But back to rfc2222bis: > >> There is no "official" standard KERBEROS_V5 mechanism. > > Then it seems strange to me to remove KERBEROS_V4 without further > comment when there is no standard replacement Note that there is a distinct difference between SASL mechanisms and the underlying authentication technology. The SASL KERBEROS_V4 mechanism is obsolete because the underlying technology is obsolete. It is worth noting that Kerberos V4 is not and never has been an IETF standard. If you want to use Kerberos V5 with SASL, the mechanism you are looking for is named 'GSSAPI'. It is described in draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI" refers specifically to GSS krb5). By contrast, the KERBEROS_V4 mechanism was defined _in the SASL base document_, which is why it is mentioned in the changelog. -- Jeff From owner-ietf-sasl Wed Oct 13 08:33:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFXwJi094465; Wed, 13 Oct 2004 08:33:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFXwVS094463; Wed, 13 Oct 2004 08:33:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFXvZ3094445 for ; Wed, 13 Oct 2004 08:33:57 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHl8l-0000OY-CK; Wed, 13 Oct 2004 17:34:11 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHl8i-0003iL-2D; Wed, 13 Oct 2004 17:34:08 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHl8h-0000bf-00; Wed, 13 Oct 2004 17:34:07 +0200 From: Hallvard B Furuseth Message-Id: To: Jeffrey Hutzelman Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <490070000.1097680744@minbar.fac.cs.cmu.edu> References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> <490070000.1097680744@minbar.fac.cs.cmu.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Oct 2004 17:34:07 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: >On Wednesday, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth > wrote: >>But back to rfc2222bis: >> >>> There is no "official" standard KERBEROS_V5 mechanism. >> >> Then it seems strange to me to remove KERBEROS_V4 without further >> comment when there is no standard replacement > > Note that there is a distinct difference between SASL mechanisms and > the underlying authentication technology. The SASL KERBEROS_V4 > mechanism is obsolete because the underlying technology is obsolete. > It is worth noting that Kerberos V4 is not and never has been an IETF > standard. > > If you want to use Kerberos V5 with SASL, the mechanism you are > looking for is named 'GSSAPI'. It is described in > draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms > based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI" > refers specifically to GSS krb5). OK. Still, it might still be worth mentioning this the draft. I expect what you say is well known to someone who comes to SASL via Kerberos, but it would not be known to someone (like me) who comes to Kerberos via SASL. OTOH, if such a brief sentence could not be sufficiently helpful to a 'kerberos newbie' for there to be any point to it, forget it. -- Hallvard From owner-ietf-sasl Wed Oct 13 08:48:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFmu6q096335; Wed, 13 Oct 2004 08:48:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFmuLa096334; Wed, 13 Oct 2004 08:48:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFmtRZ096328 for ; Wed, 13 Oct 2004 08:48:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9DFnAZv046359; Wed, 13 Oct 2004 15:49:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 08:50:02 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis Appendix C Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <416D38F6.6070403@isode.com> References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@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 07:17 AM 10/13/2004, Alexey Melnikov wrote: >Jeffrey Hutzelman wrote: > >>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: >> >>>Hallvard B Furuseth wrote: >>> >>>>I think Appendix C (Changes since RFC 2222) includes an extract of >>>>changes between various rfc2222/rfc2222bis versions, rather than just >>>>changes since RFC 2222. >>> >>>That is correct. >>> >>>Question to the WG: should I clean up the Appendix C or should I wait >>>till the document is approved for publication? As the WG must review and reach consensus as to content of Appendix before it submitted to the AD for consideration, it should be cleaned up now. >>This section is essentially a changelog. > >Yes. When I think of an I-D changelog, I think of a log of changes between each revision of the I-D. This is not that. >>Normally, such sections are intended for use during the development of a document, and carry a note to the RFC-Editor asking that they be removed prior to publication. If this appendix were a log of changes between each revision of the I-D, I would agree. But this appendix is not that. It is summary of changes made to RFC 2222. >>I think that would be the apporpriate thing to do in this case. > >I disagree. I find such section quite useful when one has to quickly find out about changes since an older RFC. Yes. The purpose of this section is to provide useful information to the reader of the RFC regarding changes since RFC 2222. Kurt From owner-ietf-sasl Wed Oct 13 09:23:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGNBPF000425; Wed, 13 Oct 2004 09:23:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DGNBSa000424; Wed, 13 Oct 2004 09:23:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGN9ef000418 for ; Wed, 13 Oct 2004 09:23:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 17:23:15 +0100 Message-ID: <416D5672.4010506@isode.com> Date: Wed, 13 Oct 2004 17:23:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@isode.com> <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> Content-Type: multipart/alternative; boundary="------------010105090404090300040408" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------010105090404090300040408 Content-type: text/plain; charset="us-ascii" Kurt D. Zeilenga wrote: >At 07:17 AM 10/13/2004, Alexey Melnikov wrote: > > >>Jeffrey Hutzelman wrote: >> >> >>>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: >>> >>> >>>>Hallvard B Furuseth wrote: >>>> >>>> >>>>>I think Appendix C (Changes since RFC 2222) includes an extract of >>>>>changes between various rfc2222/rfc2222bis versions, rather than just >>>>>changes since RFC 2222. >>>>> >>>>> >>>>That is correct. >>>> >>>>Question to the WG: should I clean up the Appendix C or should I wait >>>>till the document is approved for publication? >>>> >>>> > >As the WG must review and reach consensus as to content of >Appendix before it submitted to the AD for consideration, >it should be cleaned up now. > > Ok. The more precise questions are: 1). Do we want to keep it (the answer I got so far is "yes") 2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication. >>>This section is essentially a changelog. >>> >>> >>Yes. >> >> > >When I think of an I-D changelog, I think of a log of changes >between each revision of the I-D. This is not that. > > In practice it is kind of "in between". I was updating it each time a major change was done, but each change was only recorded once (even if multiple revisions had to deal with the same change). Alexey --------------010105090404090300040408 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Kurt D. Zeilenga wrote:
At 07:17 AM 10/13/2004, Alexey Melnikov wrote:
  
Jeffrey Hutzelman wrote:
    
On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov <Alexey.Melnikov@isode.com> wrote:
      
Hallvard B Furuseth wrote:
        
I think Appendix C (Changes since RFC 2222) includes an extract of
changes between various rfc2222/rfc2222bis versions, rather than just
changes since RFC 2222.
          
That is correct.

Question to the WG: should I clean up the Appendix C or should I wait
till the document is approved for publication?
        

As the WG must review and reach consensus as to content of
Appendix before it submitted to the AD for consideration,
it should be cleaned up now.
Ok.

The more precise questions are:
1). Do we want to keep it (the answer I got so far is "yes")
2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication.
This section is essentially a changelog.
      
Yes.
    

When I think of an I-D changelog, I think of a log of changes
between each revision of the I-D.  This is not that.
In practice it is kind of "in between". I was updating it each time a major change was done, but each change was only recorded once (even if multiple revisions had to deal with the same change).

Alexey

--------------010105090404090300040408-- From owner-ietf-sasl Wed Oct 13 09:42:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGggIp003005; Wed, 13 Oct 2004 09:42:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DGggVu003004; Wed, 13 Oct 2004 09:42:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGgfad002995 for ; Wed, 13 Oct 2004 09:42:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9DGgxZv046723; Wed, 13 Oct 2004 16:42:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013092648.02d02a10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 09:43:51 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis Appendix C Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <416D5672.4010506@isode.com> References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@isode.com> <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> <416D5672.4010506@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 09:23 AM 10/13/2004, Alexey Melnikov wrote: >The more precise questions are: >1). Do we want to keep it (the answer I got so far is "yes") Yes. When revising an existing RFC, it is generally appropriate to summarize the changes made. This information is quite useful to readers of the new RFC, especially to those who implemented the existing RFC. >2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication. First, if such a list is maintained, it must be maintained separately from the above summary. Anways, (as you note) such a list would not be subject to WG review as it would be removed prior to publication. Though some WG find such lists useful, they are certainly not necessary. Given that this document is already through WG last call, I don't see how such a list could be useful to the WG or during subsequent IETF and IESG review. Personally, I think our energy would be better spent ensuring the summary of changes since RFC 2222 was of good quality. So, no. Kurt From owner-ietf-sasl Wed Oct 13 10:18:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHIQS3008951; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DHIQV3008950; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHIPpv008941 for ; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 18:18:23 +0100 Message-ID: <416D635D.4090105@isode.com> Date: Wed, 13 Oct 2004 18:18:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >RFC 2222 did not refer to UTF-8 at all. OTOH, the new UTF-8 >MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned. > > Replaced "buffers of security encoded data" with "buffers of > protected data" for clarity. > > This should read: Replaced "buffers of cipher-text" with "buffers of protected data" for clarity. >That first phrase does not occur in rfc2222. > > Made requirement to verify that an authorization identity is correct > by performing SASLprep a SHOULD, instead of a MUST. > > I've changed this to: Made requirement to verify that an authorization identity is correct by performing SASLprep. Is this better? >rfc2222 does not contain a single MUST. And if that SHOULD is the one >in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is >correct, not that the ID itself is correct. > > From owner-ietf-sasl Wed Oct 13 16:41:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNfD3Y062421; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DNfDal062420; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.mundophp.info ([65.98.66.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNfDZM062414 for ; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) (envelope-from correo@sevein.com) Received: from jesus.sevein.red (4.Red-217-125-56.pooles.rima-tde.net [217.125.56.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mundophp.info (Postfix) with ESMTP id EB0B75363 for ; Thu, 14 Oct 2004 01:41:32 +0200 (CEST) Date: Thu, 14 Oct 2004 01:41:24 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) To: ietf-sasl@imc.org Subject: Fw: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Message-ID: <20041014014124.05ed8f8a@jesus.sevein.red> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I am a Linux user who is trying to configure his own server in Internet= to give services like www, smtp, imap and that stuff. I have been trying t= o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi= th rimap to auth users against courier-imap (and authdaemond agains MySQL). But I thought that it could be better to configure sasl to connect directly= to authdaemond socket. I tried it. But I got this error (always): [postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou= rier authdaemond: Connection refused My configuration files: /etc/sasl/smtpd.conf ^^^^^^^^^^^^^^^^^^^^ pwcheck_method: authdaemond authdaemon_path: /var/lib/courier-imap/authdaemon/socket mech_list: plain login log_level: 7 ls -li /var/lib/courier-imap/authdaemon/socket=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae= mon/socket Moreover, I did this because I though about the Postfix chroot: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri= er-imap/authdaemon/socket I always restart Postfix when I make changes. Gentoo Linux courier-imap-3.0.7 cyrus-sasl-2.1.19-r1 (with authdaemond support) postfix-2.1.3 Do you know what could I do? I am tired of the same! --=20 Jes=FAs Garc=EDa Crespo (aka Sevein) http://www.sevein.com correo@sevein.com GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBbb0qjm2pe+LbF+gRAkw8AJ40rran0f8VTpuqz6DHqpVKnZXsQQCeO5Y+ v1eTceKe0smJlt1sX9Kk/Kk= =yucx -----END PGP SIGNATURE----- --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T-- From owner-ietf-sasl Wed Oct 13 16:36:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNawxJ061789; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DNawxs061788; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.mundophp.info ([65.98.66.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNavZv061782 for ; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) (envelope-from correo@sevein.com) Received: from jesus.sevein.red (4.Red-217-125-56.pooles.rima-tde.net [217.125.56.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mundophp.info (Postfix) with ESMTP id 66D105363 for ; Thu, 14 Oct 2004 01:37:17 +0200 (CEST) Date: Thu, 14 Oct 2004 01:37:10 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) To: ietf-sasl@vpnc.org Subject: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Message-ID: <20041014013710.69560630@jesus.sevein.red> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I am a Linux user who is trying to configure his own server in Internet= to give services like www, smtp, imap and that stuff. I have been trying t= o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi= th rimap to auth users against courier-imap (and authdaemond agains MySQL). But I thought that it could be better to configure sasl to connect directly= to authdaemond socket. I tried it. But I got this error (always): [postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou= rier authdaemond: Connection refused My configuration files: /etc/sasl/smtpd.conf ^^^^^^^^^^^^^^^^^^^^ pwcheck_method: authdaemond authdaemon_path: /var/lib/courier-imap/authdaemon/socket mech_list: plain login log_level: 7 ls -li /var/lib/courier-imap/authdaemon/socket=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae= mon/socket Moreover, I did this because I though about the Postfix chroot: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri= er-imap/authdaemon/socket I always restart Postfix when I make changes. Gentoo Linux courier-imap-3.0.7 cyrus-sasl-2.1.19-r1 (with authdaemond support) postfix-2.1.3 Do you know what could I do? I am tired of the same! --=20 Jes=FAs Garc=EDa Crespo (aka Sevein) http://www.sevein.com correo@sevein.com GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBbbwrjm2pe+LbF+gRAgDuAJ9B6gbh33E5sWkCNJJGei7b4+0NrwCdGWH5 bNigMOZVe14WiiwdQrMIJok= =F28/ -----END PGP SIGNATURE----- --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p-- From owner-ietf-sasl Wed Oct 13 17:02:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E02QbS065062; Wed, 13 Oct 2004 17:02:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E02Qe5065061; Wed, 13 Oct 2004 17:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E02PFX065054 for ; Wed, 13 Oct 2004 17:02:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9E02fZv048950; Thu, 14 Oct 2004 00:02:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013165411.02d58a48@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 17:03:33 -0700 To: =?iso-8859-1?Q?Jes=FAs?= =?iso-8859-1?Q?_Garc=EDa?= Crespo (aka Sevein) From: "Kurt D. Zeilenga" Subject: Re: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Cc: ietf-sasl@vpnc.org In-Reply-To: <20041014013710.69560630@jesus.sevein.red> References: <20041014013710.69560630@jesus.sevein.red> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9E02QFX065055 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please note that this list is for discussing the standardization of SASL and, in particular, undertaking the work of the IETF SASL WG . Your post is off-topic here. Issues specific to any particular SASL implementation should be directed to forums specific to that implementation. From your message, I gather you are using the Cyrus SASL implementation. Hence, I suggest you direct your comments to: Information regarding how to subscribe to this list is available at: http://asg.web.cmu.edu/sasl/#mailinglists Thanks, Kurt - IETF SASL WG co-chair At 04:37 PM 10/13/2004, aka Sevein wrote: >Hi! I am a Linux user who is trying to configure his own server in Internet to give services like www, smtp, imap and that stuff. I have been trying to do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd with rimap to auth users against courier-imap (and authdaemond agains MySQL). > >But I thought that it could be better to configure sasl to connect directly to authdaemond socket. I tried it. But I got this error (always): > >[postfix/smtpd] warning: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused > >My configuration files: > >/etc/sasl/smtpd.conf >^^^^^^^^^^^^^^^^^^^^ >pwcheck_method: authdaemond >authdaemon_path: /var/lib/courier-imap/authdaemon/socket >mech_list: plain login >log_level: 7 > >ls -li /var/lib/courier-imap/authdaemon/socket >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdaemon/socket > >Moreover, I did this because I though about the Postfix chroot: >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ > >ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/courier-imap/authdaemon/socket > >I always restart Postfix when I make changes. > > >Gentoo Linux >courier-imap-3.0.7 >cyrus-sasl-2.1.19-r1 (with authdaemond support) >postfix-2.1.3 > >Do you know what could I do? I am tired of the same! > > >-- >Jesús García Crespo (aka Sevein) >http://www.sevein.com >correo@sevein.com > >GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) > > From owner-ietf-sasl Thu Oct 14 02:34:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E9YOeN023822; Thu, 14 Oct 2004 02:34:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E9YObv023821; Thu, 14 Oct 2004 02:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E9YNjV023798 for ; Thu, 14 Oct 2004 02:34:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 10:33:53 +0100 Message-ID: <416D9CD6.8010309@isode.com> Date: Wed, 13 Oct 2004 22:23:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060000090909080107050306" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------060000090909080107050306 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>>>5. Mechanism profile guidelines >>>> >>>> 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 MUST fail the authentication exchange. >>>> >>>> >>>I expect preparation of an empty string should not fail, so: >>>s/results in/turns a non-empty string into/. >>> >>> >> This text is talking about authentication identities and passwords. I am >> not sure whether the empty string should be allowed. >> >> > >I can see nothing which forbids it, neither in rfc2222 nor 2222bis. > >I have certainly set empty passwords on Unix boxes (off the net); if >there is a SASL library which allows empty passwords then I assume >people have found use for them with SASL too. > >I expect an empty authentication IDs would be messier, unless the >authorization ID which is derived from that ID is non-empty. > > > Ok, I have done the proposed change. Can anybody suggest a better wording? --------------060000090909080107050306 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
5.    Mechanism profile guidelines   

   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 MUST fail the authentication exchange.
        
I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
      
 This text is talking about authentication identities and passwords. I am
 not sure whether the empty string should be allowed.
    

I can see nothing which forbids it, neither in rfc2222 nor 2222bis.

I have certainly set empty passwords on Unix boxes (off the net); if
there is a SASL library which allows empty passwords then I assume
people have found use for them with SASL too.

I expect an empty authentication IDs would be messier, unless the
authorization ID which is derived from that ID is non-empty.
Ok, I have done the proposed change. Can anybody suggest a better wording?

--------------060000090909080107050306-- From owner-ietf-sasl Thu Oct 14 15:51:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EMpPHg069070; Thu, 14 Oct 2004 15:51:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EMpPwe069069; Thu, 14 Oct 2004 15:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EMpNNX069048 for ; Thu, 14 Oct 2004 15:51:24 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CIERP-0000gX-GF for ietf-sasl@imc.org; Fri, 15 Oct 2004 00:51:23 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIERN-0002iS-67; Fri, 15 Oct 2004 00:51:21 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIERM-0005El-00; Fri, 15 Oct 2004 00:51:20 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 00:51:20 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > 1) Re-keying of security layers > SASL mechanisms that support re-keying SHOULD: > - indicate that re-keying is or will be needed immediately; > - provide re-keying messages or transparently include re-keying > messages in the security layers; the latter can happen without > application involvement, but only as long as the application is > engaged in timely bidirectional exchanges with its peer. > > The chairs believes the WG supports addition of this text. Please also explain what 're-keying' and 'timely bidirectional exchanges' are. (I'm guessing that re-keying is a SASL layer's equivalent of TLS ciphersuite renegotiation, but I don't know. I don't know if I would have thought of that if I did not know of TLS. I have no idea how a protocol or implementation can know that a peer will be engage in anything 'timely'. I'm not sure what exactly 'bidirectional exchanges' are either, but from the context my guess would be that if one peer chooses to send a message, the other is expected to notice and send a response, and do so before sending (or also reading?) anything else on the connection.) > 4) Channel Binding > Nico (...) suggest security consideration > text that clients using SASL over TLS should verify > the server's TLS identity to prevent MITM attacks. > He also suggested (...) > > The chairs conclude that the WG supports the former > suggestion but not the latter. Unless just that literal text will be used (except for expanding "MITM"): Note that the draft does not explain what channel bindings are, so either explain or avoid the term. -- Hallvard From owner-ietf-sasl Thu Oct 14 17:26:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0Q3AO080886; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F0Q3IQ080885; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0Q2hh080867 for ; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CIFv3-00030U-Je for ietf-sasl@imc.org; Fri, 15 Oct 2004 02:26:05 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIFv1-0005lo-U0; Fri, 15 Oct 2004 02:26:03 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIFv0-0005Qo-00; Fri, 15 Oct 2004 02:26:02 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: EXTERNAL description Date: Fri, 15 Oct 2004 02:26:02 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 7. The EXTERNAL mechanism > The client sends a single message containing the UTF-8 encoding of > the Maybe add 'requested'? > authorization identity. The message may be empty. The form of the > authorization identity is further restricted by the application-level > protocol's SASL profile. s/is further/may be/. (Further restricted than what? Being empty?:-) Though I'd move that last sentence to the last paragraph (below) so all handling of the authorization identity is in one place. These paragraphs can be shortened a bit now that 'authentication identities' have been introduced: > The server uses information, external to SASL, to determine whether > the client is permitted to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > server indicates failure. The server uses information external to SASL to determine the authentication identity and whether the authentication is to succeed. It then indicates completion or failure of the authentication exchange. > 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. If the requested authorization identity is empty, the authorization identity is to be derived from the authentication identity. -- Hallvard From owner-ietf-sasl Thu Oct 14 17:47:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0lhjN084566; Thu, 14 Oct 2004 17:47:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F0lhLs084565; Thu, 14 Oct 2004 17:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0le7k084555 for ; Thu, 14 Oct 2004 17:47:41 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CIGFz-0006UV-PM; Fri, 15 Oct 2004 02:47:43 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIGFx-0002P9-1J; Fri, 15 Oct 2004 02:47:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIGFw-0005VT-00; Fri, 15 Oct 2004 02:47:40 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C In-Reply-To: <416D635D.4090105@isode.com> References: <416D635D.4090105@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 02:47:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >> Made requirement to verify that an authorization identity is correct >> by performing SASLprep a SHOULD, instead of a MUST. > > I've changed this to: > > Made requirement to verify that an authorization identity is correct > by performing SASLprep. > > Is this better? No, because it's not a requirement:-) Anyway, I think this paragraph can simply be deleted, since it's just part of the 'I-D revision history'. The appendix already covers SASLprep as RFC history: Added text about SASLprep for authentication identities and passwords. Described where SASLprep preparation should take place. -- Hallvard From owner-ietf-sasl Thu Oct 14 18:19:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F1Jj8x089679; Thu, 14 Oct 2004 18:19:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F1JjEi089678; Thu, 14 Oct 2004 18:19:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F1Jilv089671 for ; Thu, 14 Oct 2004 18:19:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CIGl1-0004ZZ-6l; Fri, 15 Oct 2004 03:19:47 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIGky-0003Mv-AG; Fri, 15 Oct 2004 03:19:44 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIGkw-0005Z7-00; Fri, 15 Oct 2004 03:19:42 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis In-Reply-To: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 03:19:42 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > 3.2 Identity Concepts > The client provides its credentials and, optionally, a > string representing the requested authorization identity > as part of the SASL exchange. > When this string is not > provided, the client is requesting to act as the identity > associated with the credentials (e.g., the user is > requesting to act as the authentication identity). No, authentication identity may not even have a syntax which is valid for an authorization identity. The client is requesting that the authorization identity is derived from the authentication identity. Also, I suggest /not provided/omitted or empty/. > The server is responsible for verifying the user's > credentials and verifying that the user is able to > act as the authorization identity. s/user('s)/authentication identity('s)/. s/able/allowed/. > A SASL exchange > is successful if and only if both of these verifications > are successful. Security layer negotiation can also fail. Or something can just plain break a specification. > While SASL mechanisms specify the form of credentials > used to authenticating users and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange, the This sentence needs to be broken up. SASL mechanisms specify the form of credentials used to authenticating users, and SASL application profiles specify the form of authorization identities transferred as part of authentication exchange. However, the > precise form(s) and semantics > of the authentication identities (used > within the server in its verifications, or otherwise) > and the precise form(s) and semantics > of the authorization identities > (used in making authorization decisions, or otherwise) is > beyond the scope of the SASL and this specification. > In > some circumstances, the precise identity forms used > outside of the SASL exchange may be dictated by other > specifications. For instance, the authorization policy > specification for an application protocol may dictate the > precise form that an authorization identity is to be > represented in the authorization policy. Or the protocol profile may specify that authorization identities are to be checked e.g. in a case-insensitive manner. Finally, what is the word 'application' doing here? What is an 'application profile'? Or an 'application protocol' as opposed to a protocol'? -- Hallvard From owner-ietf-sasl Thu Oct 14 19:09:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F29P98095492; Thu, 14 Oct 2004 19:09:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F29PN9095491; Thu, 14 Oct 2004 19:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F29O3N095479 for ; Thu, 14 Oct 2004 19:09:24 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9F29RZv056489; Fri, 15 Oct 2004 02:09:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Oct 2004 19:10:17 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@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 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> 3.2 Identity Concepts > >> The client provides its credentials and, optionally, a >> string representing the requested authorization identity >> as part of the SASL exchange. > >> When this string is not >> provided, the client is requesting to act as the identity >> associated with the credentials (e.g., the user is >> requesting to act as the authentication identity). > >No, authentication identity may not even have a syntax which is valid >for an authorization identity. An identity can be represented in many different ways. Here I am using the terms "authentication identity" and "authorization identity" conceptional, and generally without regards to how they might be represented at any given time or place. When I referred to a "string representing the requested authorization identity", I referred to a particular representation of an identity. But when I said, "the client is requesting to act as the [authentication identity]", I didn't talk about how that identity would be represented. >The client is requesting that the >authorization identity is derived from the authentication identity. Conceptionally, the client is requesting the act as the identity associated with credentials. This identity might have many different representations. >Also, I suggest /not provided/omitted or empty/. > >> The server is responsible for verifying the user's >> credentials and verifying that the user is able to >> act as the authorization identity. > >s/user('s)/authentication identity('s)/. Since authentication identity is defined here as being the identity associated the credentials, would be effective saying: s/user's credentials/credentials of the identity associated with the credentials/ >s/able/allowed/. Okay. >> A SASL exchange >> is successful if and only if both of these verifications >> are successful. > >Security layer negotiation can also fail. >Or something can just plain break a specification. It may be better to reverse the statement: A SASL exchange fails if either (or both) of these verifications fails. >> While SASL mechanisms specify the form of credentials >> used to authenticating users and SASL application >> profiles specify the form of authorization identities >> transferred as part of authentication exchange, the I note that s/SASL mechanisms specify/SASL mechanism specifications describe/, s/profiles specify/profiles describe/. That is, we need to be careful not to use the term "mechanism" to refer to a mechanism's specification. >This sentence needs to be broken up. > > SASL mechanisms specify the form of credentials > used to authenticating users, and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange. > However, the Noting my above note would apply here as well, I think this suggestion is a good one. >> precise form(s) > > and semantics > >> of the authentication identities (used >> within the server in its verifications, or otherwise) >> and the precise form(s) > > and semantics I have some concern here. In particular, the mechanism specification may cover some authentication identity semantics. Or, as you note below, the application profile may detail matching semantics. I think talking adding "and semantics" will just confuse things. >> of the authorization identities >> (used in making authorization decisions, or otherwise) is >> beyond the scope of the SASL and this specification. > >> In >> some circumstances, the precise identity forms used >> outside of the SASL exchange may be dictated by other >> specifications. For instance, the authorization policy >> specification for an application protocol may dictate the >> precise form that an authorization identity is to be >> represented in the authorization policy. > >Or the protocol profile may specify that authorization identities >are to be checked e.g. in a case-insensitive manner. > >Finally, what is the word 'application' doing here? What is an >'application profile'? Or an 'application protocol' as opposed to a >protocol'? I mean application-level protocol. I generally find the bare use of the term 'protocol' to be somewhat unclear. I rather quality the term with 'application-level'. However, that likely should be done consistently or not at all. From owner-ietf-sasl Fri Oct 15 02:21:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F9Le8k036264; Fri, 15 Oct 2004 02:21:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F9Lei4036263; Fri, 15 Oct 2004 02:21:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F9LcvC036238 for ; Fri, 15 Oct 2004 02:21:39 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 15 Oct 2004 10:21:35 +0100 Message-ID: <416F969D.3060703@isode.com> Date: Fri, 15 Oct 2004 10:21:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D635D.4090105@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050904030104050703090604" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------050904030104050703090604 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>> Made requirement to verify that an authorization identity is correct >>> by performing SASLprep a SHOULD, instead of a MUST. >>> >>> >>I've changed this to: >> >> Made requirement to verify that an authorization identity is correct >> by performing SASLprep. >> >>Is this better? >> >> > >No, because it's not a requirement:-) > Fine, but see below. > Anyway, I think this paragraph can >simply be deleted, since it's just part of the 'I-D revision history'. >The appendix already covers SASLprep as RFC history: > > Added text about SASLprep for authentication identities and > passwords. Described where SASLprep preparation should take place. > > This doesn't cover authorization identities. --------------050904030104050703090604 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
Alexey Melnikov writes:
  
  Made requirement to verify that an authorization identity is correct
  by performing SASLprep a SHOULD, instead of a MUST.
      
I've changed this to:

   Made requirement to verify that an authorization identity is correct
   by performing SASLprep.

Is this better?
    

No, because it's not a requirement:-)
Fine, but see below.
 Anyway, I think this paragraph can
simply be deleted, since it's just part of the 'I-D revision history'.
The appendix already covers SASLprep as RFC history:

   Added text about SASLprep for authentication identities and
   passwords.  Described where SASLprep preparation should take place.
This doesn't cover authorization identities.

--------------050904030104050703090604-- From owner-ietf-sasl Thu Oct 21 05:26:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LCQ2sT067990; Thu, 21 Oct 2004 05:26:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LCQ29Z067989; Thu, 21 Oct 2004 05:26:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LCQ0s6067948 for ; Thu, 21 Oct 2004 05:26:01 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 13:25:45 +0100 Message-ID: <4177AAC9.8080606@isode.com> Date: Thu, 21 Oct 2004 13:25:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: Some editorial changes to RFC2222bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard has suggested to change "mechanism specific"/"protocol specific" to "mechanism-specific"/"protocol-specific". If you have any opinion on this (or maybe you know what is the right way), please let me know by the end of Friday. Alexey From owner-ietf-sasl Thu Oct 21 06:39:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDdjdi085938; Thu, 21 Oct 2004 06:39:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDdjNN085937; Thu, 21 Oct 2004 06:39:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDdhSc085902 for ; Thu, 21 Oct 2004 06:39:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CKdAK-0005cO-Pi; Thu, 21 Oct 2004 15:39:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKdA9-0003jR-OV; Thu, 21 Oct 2004 15:39:29 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKdA9-0006Eb-00; Thu, 21 Oct 2004 15:39:29 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis In-Reply-To: <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 15:39:29 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry about the late replies; I thought I had addressed this. Kurt D. Zeilenga writes: >At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>> 3.2 Identity Concepts >> >>> The client provides its credentials and, optionally, a >>> string representing the requested authorization identity >>> as part of the SASL exchange. >> >>> When this string is not >>> provided, the client is requesting to act as the identity >>> associated with the credentials (e.g., the user is >>> requesting to act as the authentication identity). >> >>No, authentication identity may not even have a syntax which is valid >>for an authorization identity. > > An identity can be represented in many different ways. > Here I am using the terms "authentication identity" > and "authorization identity" conceptional, and > generally without regards to how they might be represented > at any given time or place. When I referred to a "string > representing the requested authorization identity", I > referred to a particular representation of an identity. > But when I said, "the client is requesting to act as the > [authentication identity]", I didn't talk about how that > identity would be represented. > >>The client is requesting that the >>authorization identity is derived from the authentication identity. > > Conceptionally, the client is requesting the act as the > identity associated with credentials. This identity > might have many different representations. I hadn't quite caught on to the 'conceptual' part, but it seems rather confusing to have the same names for 'conceptual' and 'represented' identities. But even so, authorization identities and authentication identities seem to me to be 'conceptually' different types of entities; defined by different standards and used in different ways. So whether we talk of conceptual or represented identities, I'd still prefer to say that the authorization id is derived from the authentication id rather than it is the authentication id. >>Also, I suggest /not provided/omitted or empty/. >> >>> The server is responsible for verifying the user's >>> credentials and verifying that the user is able to >>> act as the authorization identity. >> >>s/user('s)/authentication identity('s)/. > > Since authentication identity is defined here as > being the identity associated the credentials, would > be effective saying: > s/user's credentials/credentials of the identity > associated with the credentials/ Well, I'd still like to get rid of that 'user'. 'User' is used elsewhere as merely one kind of identity. Maybe s/user's credentials/presented credentials/, or s/users's credentials/credentials/, s/user/authentication identity/? >>> A SASL exchange >>> is successful if and only if both of these verifications >>> are successful. >> >>Security layer negotiation can also fail. >>Or something can just plain break a specification. > > It may be better to reverse the statement: > A SASL exchange fails if either (or both) of these > verifications fails. Yes. >> However, the > > Noting my above note would apply here as well, I think > this suggestion is a good one. > >>> precise form(s) >> >> and semantics >> >>> of the authentication identities (used >>> within the server in its verifications, or otherwise) >>> and the precise form(s) >> >> and semantics > > I have some concern here. In particular, the mechanism > specification may cover some authentication identity > semantics. Or, as you note below, the application > profile may detail matching semantics. I think talking > adding "and semantics" will just confuse things. Well, what I wanted to address was what I mentioned in my original review: > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. That's a bit misleading from the protocol's point of view. From discussions elsewhere I gather the protocol may normalize the ID as it pleases for its own use, including when it locates the server-side secret matching the authentication ID, as long as this does not affect the ID which the authentication mechanism sees. Your text doesn't seem to be clear on that. >>> In >>> some circumstances, the precise identity forms used >>> outside of the SASL exchange may be dictated by other >>> specifications. For instance, the authorization policy >>> specification for an application protocol may dictate the >>> precise form that an authorization identity is to be >>> represented in the authorization policy. >> >>Or the protocol profile may specify that authorization identities >>are to be checked e.g. in a case-insensitive manner. >> >>Finally, what is the word 'application' doing here? What is an >>'application profile'? Or an 'application protocol' as opposed to a >>protocol'? > > I mean application-level protocol. I generally find the > bare use of the term 'protocol' to be somewhat unclear. > I rather quality the term with 'application-level'. However, > that likely should be done consistently or not at all. Do you mean the OSI model application layer? If so, it needs a reference to the OSI model. If not, I'm still not sure what you mean. BTW, I notice that there are several other uses of 'application' in rfc2222bis which I'm not quite sure of, now that it's bought up. Also, I would have thought SASL could be used at the presentation layer as well. -- Hallvard From owner-ietf-sasl Thu Oct 21 06:44:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDi4qh087168; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDi4S9087167; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDi3KQ087142 for ; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CKdEY-00071Y-Lq; Thu, 21 Oct 2004 15:44:02 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKdEV-0004JJ-1q; Thu, 21 Oct 2004 15:43:59 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKdEU-0006Fx-00; Thu, 21 Oct 2004 15:43:58 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416CFBDA.8000707@isode.com> References: <416BFDAA.3090507@isode.com> <416CFBDA.8000707@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 15:43:58 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>>>>6.1. Client sends data first >>>>> >>>>> 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.) >>>>> >>>>> >>>>Then protocols that support an initial response must be clear on how to >>>>distinguish an absent initial response from a present but empty initial >>>>response. I expect their protocol profiles must also specify whether or >>>>not the protocol _can_ distinguish the two, so the mechanism can tell >>>>whether or not to send empty initial responses. >>>> >>>> >>> This is described in Section 4, bullet # 2. >> >>No... First, it's only a SHOULD: >> >> If the protocol allows for the initial response, the protocol profile >> SHOULD also describe how an empty initial response is encoded. >> > I've already changed SHOULD to MUST. This issue was raised during WGLC. > >>Second, if that sentence is intended to address this issue, I can think >>of two different things it can imply in order to do so. It is not at >>all clear to me that it means either: >> >>1) "If the protocol profile does not say how an initial response is >> encoded, then empty but present initial responses are not supported." >> >>2) If you s/SHOULD/MUST/: "If initial responses are supported, then it >> MUST be possible to send an empty initial response which can be >> distinguished from no initial response." > > The intention was to say #2. I am not aware of any protocol profile that > supports initial response, but doesn't allow for it being empty. Me neither, which is why I used an imaginary example. But I've just realized that your answer opens for a third possibility: Protocols that do allow empty initial responses, but not absent initial responses. (Again, an SMTP-like protocol which strips trailing whitespace could be an example.) -- Hallvard From owner-ietf-sasl Thu Oct 21 06:51:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDppbR089047; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDppMj089046; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDpo7f089039 for ; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 14:51:51 +0100 Message-ID: <4177BEF7.6050604@isode.com> Date: Thu, 21 Oct 2004 14:51:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@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: Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > > >>1) Re-keying of security layers >> >> SASL mechanisms that support re-keying SHOULD: >> - indicate that re-keying is or will be needed immediately; >> - provide re-keying messages or transparently include re-keying >> messages in the security layers; the latter can happen without >> application involvement, but only as long as the application is >> engaged in timely bidirectional exchanges with its peer. >> >>The chairs believes the WG supports addition of this text. >> > >Please also explain what 're-keying' and 'timely bidirectional >exchanges' are. > >(I'm guessing that re-keying is a SASL layer's equivalent of TLS >ciphersuite renegotiation, but I don't know. > Correct me if I am wrong, but I understand rekeying as "renegotiation of the signing/encrypting key". But I agree with you, those two terms must be explained. And I am not sure I can give a good definition for 'timely bidirectional exchange' > I don't know if I would >have thought of that if I did not know of TLS. I have no idea how a >protocol or implementation can know that a peer will be engage in >anything 'timely'. I'm not sure what exactly 'bidirectional exchanges' >are either, but from the context my guess would be that if one peer >chooses to send a message, the other is expected to notice and send a >response, and do so before sending (or also reading?) anything else on >the connection.) > > Alexey From owner-ietf-sasl Thu Oct 21 07:36:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LEaGBk001179; Thu, 21 Oct 2004 07:36:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LEaGaF001178; Thu, 21 Oct 2004 07:36:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LEaFiN001172 for ; Thu, 21 Oct 2004 07:36:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 15:36:09 +0100 Message-ID: <4177C959.2060205@isode.com> Date: Thu, 21 Oct 2004 15:36:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <6.1.2.0.0.20041001102809.04165318@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: Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > > >>At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >> >> >>>>Abstract >>>> >>>> >>>> The Simple Authentication and Security Layer (SASL) is a framework >>>> for providing authentication and data security services in >>>> connection-oriented protocols via replaceable >>>> >>>> >>>authentication >>> >>> >>The sentence might be more clear if worded: >> The Simple Authentication and Security Layer (SASL) is >> a framework for providing authentication and data security >> services via replaceable mechanisms to connection-oriented >> protocols. >> >> > >I don't think so; it looks a little strange to have the 'to...' after >the 'via...'. Maybe s/in/to/ would improve the original sentence. > >I've asked a coworker what he thought the Abstract meant: He got it more >or less right, but was somewhat vague about it and thought it was a bit >hard to get. He did not think my suggested extra words would make a >difference. > > Unless somebody objects, I am leaving the sentence as is. Alexey From owner-ietf-sasl Thu Oct 21 08:23:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFN8p7014230; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LFN8KX014229; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFN7LX014211 for ; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 16:23:08 +0100 Message-ID: <4177D45C.2050404@isode.com> Date: Thu, 21 Oct 2004 16:23:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >>3.1. Authentication protocol exchange >> >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. >> > >I don't think so. It's the protocol which conducts the _exchange_, >and (below) which transmits anything. > What about A SASL mechanism is responsible for conducting an authentication exchange. ? The mechanism is clearly "conducting" the exchange, but the protocols carries it. >[...] > >> The mechanism MUST preserve Unicode codepoint when transferring >> authorization identity (e.g. the mechanism cann't apply any form of >> normalization). >> > >The () part does not seem say the same as the preceding sentence: 'when >transferring...' sounds like only the client-side part of the mechanism >must preserve the ID, while the () sounds like the server side also must >preserve it. The text in () only talks about transfer (actually it also applies to hashing and other similar uses). For the purposes of looking up credentials, access control, etc. the server can do as it pleases. This is out of scope for SASL. Alexey From owner-ietf-sasl Thu Oct 21 08:47:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFlt1F021033; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LFltN0021032; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFlsJQ021026 for ; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 16:47:54 +0100 Message-ID: <4177DA2A.8040702@isode.com> Date: Thu, 21 Oct 2004 16:47:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >>7. The EXTERNAL mechanism >> >> The client sends a single message containing the UTF-8 encoding of >> the >> >> > >Maybe add 'requested'? > Using "requested" here is Ok, IMHO. >> authorization identity. The message may be empty. The form of the >> authorization identity is further restricted by the application-level >> protocol's SASL profile. >> >> > >s/is further/may be/. (Further restricted than what? Being empty?:-) > Ok. >Though I'd move that last sentence to the last paragraph (below) so all >handling of the authorization identity is in one place. > >These paragraphs can be shortened a bit now that 'authentication >identities' have been introduced: > > >> The server uses information, external to SASL, to determine whether >> the client is permitted to authenticate as the authorization >> identity. If the client is so authorized, the server indicates >> successful completion of the authentication exchange; otherwise the >> server indicates failure. >> >> > > The server uses information external to SASL to determine the > authentication identity and whether the authentication is to > succeed. > Although this implies the same thing (if you take into consideration implied authorization step), I would prefer the original text. > It then indicates completion or failure of the > authentication exchange. > Here is the latest text for SASL EXTERNAL. This is not exactly what you've asked, but let me know what you think: The mechanism name associated with external authentication is "EXTERNAL". The client sends a single message containing the UTF-8 encoding of the requested authorization identity. The message may be empty. The form of the authorization identity may be restricted by the application protocol's SASL profile. The server uses information, external to SASL, to determine whether the client is permitted to act as the authorization identity. (If the requested authorization identity is empty, the authorization identity is to be derived from authentication credentials which exist in the system that is providing the external authentication.) If the client is permitted to do so, the server indicates successful completion of the authentication exchange; otherwise the server indicates failure. The system providing this external information may be, for example, IPSec [IPSec] or TLS [TLS]. 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. Alexey From owner-ietf-sasl Thu Oct 21 10:22:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHMeja044404; Thu, 21 Oct 2004 10:22:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LHMeFV044403; Thu, 21 Oct 2004 10:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHMcZm044385 for ; Thu, 21 Oct 2004 10:22:39 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CKge7-0005OL-7A; Thu, 21 Oct 2004 19:22:39 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKge3-000491-M7; Thu, 21 Oct 2004 19:22:35 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKge3-0006qg-00; Thu, 21 Oct 2004 19:22:35 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description In-Reply-To: <4177DA2A.8040702@isode.com> References: <4177DA2A.8040702@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 19:22:35 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>>7. The EXTERNAL mechanism >> The server uses information external to SASL to determine the >> authentication identity and whether the authentication is to >> succeed. > > Although this implies the same thing (if you take into consideration > implied authorization step), I would prefer the original text. Well, SASL mechanisms are now supposed to set an authentication identity, but EXTERNAL in the original or in your form doesn't. (I wish I'd realized that before posting.) OTOH, mixing rfc2222's paragraph 5 (authz id) into paragraph 3 was very nice, and my text should not have lost the 'system' doing authentication. If I mix your text and mine a bit, does this cover all bases? Some system external to SASL must authenticate the client. If that succeeds, the server determines the authentication identity from information from this system. If the requested authorization identity is empty, the authorization identity is derived from the authentication identity. The server determines if the authentication identity is allowed to act as the authorization identity. Finally, it indicates completion or failure of the authentication exchange. Or replace the last sentence with If all that succeeds, the server indicates successful completion of the authentication exchange; otherwise it indicates failure. Sigh. And this started with trying to make the text _shorter_:-) -- Hallvard From owner-ietf-sasl Thu Oct 21 11:40:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LIeCsj063549; Thu, 21 Oct 2004 11:40:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LIeCgZ063548; Thu, 21 Oct 2004 11:40:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LIeAoi063515 for ; Thu, 21 Oct 2004 11:40:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LIeCZv011400; Thu, 21 Oct 2004 18:40:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021105009.030324a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 11:40:50 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@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 06:39 AM 10/21/2004, Hallvard B Furuseth wrote: >Sorry about the late replies; I thought I had addressed this. > >Kurt D. Zeilenga writes: >>At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>> 3.2 Identity Concepts >>> >>>> The client provides its credentials and, optionally, a >>>> string representing the requested authorization identity >>>> as part of the SASL exchange. >>> >>>> When this string is not >>>> provided, the client is requesting to act as the identity >>>> associated with the credentials (e.g., the user is >>>> requesting to act as the authentication identity). >>> >>>No, authentication identity may not even have a syntax which is valid >>>for an authorization identity. >> >> An identity can be represented in many different ways. >> Here I am using the terms "authentication identity" >> and "authorization identity" conceptional, and >> generally without regards to how they might be represented >> at any given time or place. When I referred to a "string >> representing the requested authorization identity", I >> referred to a particular representation of an identity. >> But when I said, "the client is requesting to act as the >> [authentication identity]", I didn't talk about how that >> identity would be represented. >> >>>The client is requesting that the >>>authorization identity is derived from the authentication identity. >> >> Conceptionally, the client is requesting the act as the >> identity associated with credentials. This identity >> might have many different representations. > >I hadn't quite caught on to the 'conceptual' part, but it seems rather >confusing to have the same names for 'conceptual' and 'represented' >identities. Would it help if the conceptional discussion was moved to the Introduction? The problem is that, in the SASL framework, no identity representation may be explicitly transferred. However, regardless of what's transferred. >But even so, authorization identities and authentication identities seem >to me to be 'conceptually' different types of entities; I disagree. An identity (authorization or authentication) refers to a human or application entity. The qualification, authorization or authentication, refers not to kind of entity, but to the usage of the identity. >defined by >different standards and used in different ways. So whether we talk of >conceptual or represented identities, I'd still prefer to say that the >authorization id is derived from the authentication id rather than it is >the authentication id. The 'derived' language is problematic. Consider the authorization identity (and when its explicitly transferred). A user wishes to act as some other user that it identifies as some particular identity. The user enters a representation of that identity to the client which then, knowing the application protocol requirements, translates the user provided identity string into form required by the application protocol specification. Then the server might take this form and translate it some other representation of the identity to make identity assumption policy decision, and then do some other translation of the representation of the identity to produce the identity representation actually used to make authorization decisions. Regardless of the identity abstraction (DN, Kerberos principle, etc.) and the encoding of values of that abstraction (LDAPDN, DER DN, GSER DN, DCE DN) used here and there, there is conceptional one authorization identity. For instance, consider an LDAP client which offers an input dialog allowing the user to input a character string representing the desired authorization identity and a indicator of the format of that string. The user inputs the string "kurt@example.com" and selects the form identifier marked "user name". The LDAP client, knowing the requirements of the LDAP's SASL profile, takes this information and constructs the string "u:kurt@example.com" and transfers it as the authorization identity string in some mechanism (say EXTERNAL). The server needs to determine whether the user associated with the credentials is authorized to act as "u:kurt@example.com", but the server's identity assumption policy subsystem happens to requires identities to represented as email addresses with the domain part in upper case. So, the server produces the string "kurt@EXAMPLE.COM" and feeds this (and other information) to the identity assumption policy subsystem. Assuming success, the server now needs to produce an representation suitable for use in making authorization decisions. That subsystem might happen to require identities to be presented as DER encoded DNs. So the server somehow produces that. And in the actual policy, maybe DNs are presented using the LDAP DN string format. That is, one identity concept in authorization identity: the identity to act as with multiple identity representations. If we were to try to name each of distinct identity representations of the authorization identities that were likely evident in any application (both client and server) use of SASL, things will get confused. Developers will start to think that the form of the identity transferred on the wire is the actual form used elsewhere and, in particular, used in making authorization decisions. That is not necessarily so. For instance, I know of no LDAP server implementation that uses the particular form of authorization identity required by LDAP SASL profile in making authorization decisions. They all map the LDAP authzId string (even if the dnAuthzid variant is used) to some other format, such as an LDAP DN string. Kurt >>>Also, I suggest /not provided/omitted or empty/. >>> >>>> The server is responsible for verifying the user's >>>> credentials and verifying that the user is able to >>>> act as the authorization identity. >>> >>>s/user('s)/authentication identity('s)/. >> >> Since authentication identity is defined here as >> being the identity associated the credentials, would >> be effective saying: >> s/user's credentials/credentials of the identity >> associated with the credentials/ > >Well, I'd still like to get rid of that 'user'. 'User' is used >elsewhere as merely one kind of identity. >Maybe s/user's credentials/presented credentials/, >or s/users's credentials/credentials/, s/user/authentication identity/? > >>>> A SASL exchange >>>> is successful if and only if both of these verifications >>>> are successful. >>> >>>Security layer negotiation can also fail. >>>Or something can just plain break a specification. >> >> It may be better to reverse the statement: >> A SASL exchange fails if either (or both) of these >> verifications fails. > >Yes. > >>> However, the >> >> Noting my above note would apply here as well, I think >> this suggestion is a good one. >> >>>> precise form(s) >>> >>> and semantics >>> >>>> of the authentication identities (used >>>> within the server in its verifications, or otherwise) >>>> and the precise form(s) >>> >>> and semantics >> >> I have some concern here. In particular, the mechanism >> specification may cover some authentication identity >> semantics. Or, as you note below, the application >> profile may detail matching semantics. I think talking >> adding "and semantics" will just confuse things. > >Well, what I wanted to address was what I mentioned in my original review: > > > Any normalization of the authentication identity is defined by a > > particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. > >Your text doesn't seem to be clear on that. > >>>> In >>>> some circumstances, the precise identity forms used >>>> outside of the SASL exchange may be dictated by other >>>> specifications. For instance, the authorization policy >>>> specification for an application protocol may dictate the >>>> precise form that an authorization identity is to be >>>> represented in the authorization policy. >>> >>>Or the protocol profile may specify that authorization identities >>>are to be checked e.g. in a case-insensitive manner. >>> >>>Finally, what is the word 'application' doing here? What is an >>>'application profile'? Or an 'application protocol' as opposed to a >>>protocol'? >> >> I mean application-level protocol. I generally find the >> bare use of the term 'protocol' to be somewhat unclear. >> I rather quality the term with 'application-level'. However, >> that likely should be done consistently or not at all. > >Do you mean the OSI model application layer? If so, it needs a >reference to the OSI model. If not, I'm still not sure what you mean. >BTW, I notice that there are several other uses of 'application' in >rfc2222bis which I'm not quite sure of, now that it's bought up. > >Also, I would have thought SASL could be used at the presentation layer >as well. > >-- >Hallvard From owner-ietf-sasl Thu Oct 21 13:10:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LKAffB085710; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LKAf3Q085709; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LKAfZd085703 for ; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LKAjZv011965; Thu, 21 Oct 2004 20:10:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021125032.03004908@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 13:11:23 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <6.1.2.0.0.20041021105009.030324a8@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:03 PM 10/21/2004, Hallvard B Furuseth wrote: >I'll be reading this - and the draft - later, but first: > >Kurt D. Zeilenga writes: >> The problem is that, in the SASL framework, no identity >> representation may be explicitly transferred. However, >> regardless of what's transferred. > >That last sentence seems to have been truncated. I think I was going to note that regardless of identity abstract (DN,Kerberos principal,other) and encoding (for DNs: RFC 2253 string, RFC 2829 authzid, DCE DN format, base64 of the DER encoding, other) used in transfer, the transferred value refers to some identity. Later, that identity may be represented using other abstractions and/or encodings. If we talk conceptually, we can say the authorization identity value input of the user, the value transferred by the SASL mechanism, the value used in determining whether the user associated with the credentials may act as specified identity, the value used in making authorization identities, and the values used in specifying identity assumption and/or authorization policies are all refer to the same identity, the identity to act as, the authorization identity. If, however, we talk in terms of how this and other identity concept is represented here and there, we'll have to come up with numerous terms and over-specify the details of identity management. Most of the details of identity management are simply beyond the scope of the SASL framework. Kurt From owner-ietf-sasl Thu Oct 21 15:26:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LMQWNM018284; Thu, 21 Oct 2004 15:26:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LMQWot018283; Thu, 21 Oct 2004 15:26:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9LMQV9i018277 for ; Thu, 21 Oct 2004 15:26:31 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa01779; 21 Oct 2004 18:25 EDT Date: Thu, 21 Oct 2004 18:25:53 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth , "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis Message-ID: <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@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 Thursday, October 21, 2004 15:39:29 +0200 Hallvard B Furuseth wrote: >>> No, authentication identity may not even have a syntax which is valid >>> for an authorization identity. >>> [...] >>> The client is requesting that the >>> authorization identity is derived from the authentication identity. >> >> Conceptionally, the client is requesting the act as the >> identity associated with credentials. This identity >> might have many different representations. > > [...] > But even so, authorization identities and authentication identities seem > to me to be 'conceptually' different types of entities; defined by > different standards and used in different ways. So whether we talk of > conceptual or represented identities, I'd still prefer to say that the > authorization id is derived from the authentication id rather than it is > the authentication id. Agree. Use the "is derived from" language; it's less likely to confuse people into thinking in terms of blindly copying strings around. >>> s/user('s)/authentication identity('s)/. >> >> Since authentication identity is defined here as >> being the identity associated the credentials, would >> be effective saying: >> s/user's credentials/credentials of the identity >> associated with the credentials/ > > Well, I'd still like to get rid of that 'user'. 'User' is used > elsewhere as merely one kind of identity. > Maybe s/user's credentials/presented credentials/, > or s/users's credentials/credentials/, s/user/authentication identity/? s/user/client/ and be done with it. > Well, what I wanted to address was what I mentioned in my original review: > > > Any normalization of the authentication identity is defined by a > > particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. > > Your text doesn't seem to be clear on that. The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism; the protocol has no say in the matter. All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent. A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID. These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy. > Do you mean the OSI model application layer? No; he's using the term in a generic sense and there does not need to be a reference to the OSI model, which in any case is only of limited use. For example, if you look, you'll find that SASL does not correspond to any layer in the OSI model. The distinction here is between SASL-using protocols (most of which are, in fact, "application" protocols in the narrower sense) as opposed to SASL itself or the underlying authentication mechanisms, all of which are also "protocols" in the generic sense. The use of the phrase "application protocol" in this sense is common in discussions about security frameworks, and should not cause confusion. In fact, I agree with Kurt that the use of the unqualified term "protocol" is confusing in this document, because in a document which defines a framework consisting of N+M+1 protocol components, the term is highly ambiguous, our definition notwithstanding. However, I also agree that we need consistent usage throughout the document. Either use "application protocol" everywhere, or not at all. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Thu Oct 21 16:13:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LNDFIm028747; Thu, 21 Oct 2004 16:13:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LNDFvc028746; Thu, 21 Oct 2004 16:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LNDEIt028739 for ; Thu, 21 Oct 2004 16:13:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LNDIZv012879; Thu, 21 Oct 2004 23:13:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 16:13:56 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: >The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism; If you were to say the syntax and semantics of any authentication identity information carried in the exchange is specified by the mechanism's specification, I would agree. But, without that qualification, I would have to disagree. For instance, an application protocol can certainly detail how authentication identities are to represented in identity-assumption policy information carried by the protocol, and associated semantics. >All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent. From the perspective of the SASL framework, yes. >A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID. Which requires may involve deriving an authentication ID from credential information. It is not appropriate to assume the particular form of authentication identity in the credentials, are the form used to establish this authorization identity. For instance, consider EXTERNAL with TLS X.509 authentication. The authentication identity might be the subject DN, or it might be viewed as being one of the altSubjNames, or something derived from this (and possible other stuff). >These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy. And possible aspects of the application-level protocol specification. For instance, it is reasonable for an application-level protocol specification to specify how mechanism-specific authentication identity forms relate to protocol-specific authentication forms, as necessary say to detail how mechanism-specific credentials (or associated policies) are to managed using the application-level protocol. Of course, an application-level protocol specification detailing such things should not unnecessarily preclude use of the mechanisms not explicitly discussed in the application-level protocol specification. Kurt From owner-ietf-sasl Fri Oct 22 06:29:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MDTtSR037202; Fri, 22 Oct 2004 06:29:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MDTt6P037201; Fri, 22 Oct 2004 06:29:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MDTsrN037168 for ; Fri, 22 Oct 2004 06:29:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 22 Oct 2004 14:29:44 +0100 Message-ID: <41790B48.5060500@isode.com> Date: Fri, 22 Oct 2004 14:29:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >> Well, what I wanted to address was what I mentioned in my original >> review: >> >> > Any normalization of the authentication identity is defined by a >> > particular SASL mechanism, the protocol profile doesn't >> influence it. >> >> That's a bit misleading from the protocol's point of view. From >> discussions elsewhere I gather the protocol may normalize the ID as it >> pleases for its own use, including when it locates the server-side >> secret matching the authentication ID, as long as this does not affect >> the ID which the authentication mechanism sees. >> >> Your text doesn't seem to be clear on that. > > The syntax and semantics of authentication ID's are determined > entirely by the authentication mechanism; the protocol has no say in > the matter. All mechanisms are protocol-independent, and all protocol > profiles are mechanism-independent. > > A particular _implementation_ must be able to perform the > authorization check (can this authid use the requested autzid) and > must be able to derive an authorization ID from an authentication ID. > These operations depend on both the mechanism and protocol profile in > use, and their details are deliberately left to the implementation and > to local policy. Do I need to change anything in the document? From owner-ietf-sasl Fri Oct 22 07:55:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MEtoix053117; Fri, 22 Oct 2004 07:55:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MEtokI053116; Fri, 22 Oct 2004 07:55:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MEtnHj053110 for ; Fri, 22 Oct 2004 07:55:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 22 Oct 2004 15:55:43 +0100 Message-ID: <41791F6F.3060802@isode.com> Date: Fri, 22 Oct 2004 15:55:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description References: <4177DA2A.8040702@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > >>Hallvard B Furuseth wrote: >> >>>>7. The EXTERNAL mechanism >>>> >>>> >>> The server uses information external to SASL to determine the >>> authentication identity and whether the authentication is to >>> succeed. >>> >>> >>Although this implies the same thing (if you take into consideration >>implied authorization step), I would prefer the original text. >> >> > >[...] > >If I mix your text and mine a bit, does this cover all bases? > > Some system external to SASL must authenticate the client. If that > succeeds, the server determines the authentication identity from > information from this system. If the requested authorization identity > is empty, the authorization identity is derived from the > authentication identity. The server determines if the authentication > identity is allowed to act as the authorization identity. Finally, it > indicates completion or failure of the authentication exchange. > >Or replace the last sentence with > > If all that succeeds, the server indicates successful completion of > the authentication exchange; otherwise it indicates failure. > That would work for me. > > Sigh. And this started with trying to make the text _shorter_:-) > It usually does :-). > > > From owner-ietf-sasl Fri Oct 22 13:57:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MKv4bb008227; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MKv49P008226; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MKv3hY008218 for ; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03522; 22 Oct 2004 16:56 EDT Date: Fri, 22 Oct 2004 16:56:52 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis Message-ID: <1128140000.1098478612@minbar.fac.cs.cmu.edu> In-Reply-To: <41790B48.5060500@isode.com> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <41790B48.5060500@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, October 22, 2004 14:29:44 +0100 Alexey Melnikov wrote: >> The syntax and semantics of authentication ID's are determined >> entirely by the authentication mechanism; the protocol has no say in >> the matter. All mechanisms are protocol-independent, and all protocol >> profiles are mechanism-independent. >> >> A particular _implementation_ must be able to perform the >> authorization check (can this authid use the requested autzid) and >> must be able to derive an authorization ID from an authentication ID. >> These operations depend on both the mechanism and protocol profile in >> use, and their details are deliberately left to the implementation and >> to local policy. > > Do I need to change anything in the document? I'll answer a narrower question... I'm not proposing any change to the document in relation to this item. I was simply trying to clarify what looked like a point of confusion in the ongoing discussion. -- Jeff From owner-ietf-sasl Sat Oct 23 13:10:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKA3LS056979; Sat, 23 Oct 2004 13:10:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKA3br056976; Sat, 23 Oct 2004 13:10:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKA13g056960 for ; Sat, 23 Oct 2004 13:10:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:09:56 +0100 Message-ID: <417A9F61.4000702@isode.com> Date: Sat, 23 Oct 2004 19:13:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>>> s/user('s)/authentication identity('s)/. >>> >>> Since authentication identity is defined here as >>> being the identity associated the credentials, would >>> be effective saying: >>> s/user's credentials/credentials of the identity >>> associated with the credentials/ >> >> Well, I'd still like to get rid of that 'user'. 'User' is used >> elsewhere as merely one kind of identity. >> Maybe s/user's credentials/presented credentials/, >> or s/users's credentials/credentials/, s/user/authentication identity/? > > s/user/client/ and be done with it. I've done the change. From owner-ietf-sasl Sat Oct 23 13:12:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKCGGA057584; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKCG6A057583; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKCFGn057574 for ; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:12:15 +0100 Message-ID: <417AB985.4090607@isode.com> Date: Sat, 23 Oct 2004 21:05:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> In-Reply-To: <417AB364.6050503@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Kurt D. Zeilenga wrote: > >> 1) Re-keying of security layers >> Nico indicated that the I-D did not discuss Re-keying of >> security layers and suggested text in this area be added. >> The WG discussed a number of specific suggestions in this >> area, with the following text being the last version >> submitted for WG consideration: >> SASL mechanisms that support re-keying SHOULD: >> - indicate that re-keying is or will be needed immediately; >> - provide re-keying messages or transparently include re-keying >> messages in the security layers; the latter can happen without >> application involvement, but only as long as the application is >> engaged in timely bidirectional exchanges with its peer. > > After rereading this text multiple times it is clear to me that either > the text is [partially] redundant, or I don't understand what it is > trying to say (or maybe both). > > 1). "indicate that re-keying is or will be needed immediately". > The first question I have after reading this sentence is "how?" > Because SASL framework doesn't have any control channel or out-of-band > mechanism, the only answer to this question is "by transparently > including re-keying messages in the security layer". But this is a > part of what the subsequent sentence is saying!? > > 2). "provide re-keying messages or transparently include re-keying > messages in the security layers;" > > I think this sentence specifies requirements on SASL APIs and I am not > sure whether RFC2222bis is the proper place for that. > > I also assume that "provide re-keying messages" is not the same thing > as "transparently include re-keying messages in the security layers". > I think the former is trying to say that the SASL API should be able > to signal to the application that rekeying is (or will be shortly) > needed, once a rekeying message is received. It also tries to say that > the application should be able to say to SASL API: "send rekeying > request now". > > The latter is trying to say that the SASL API doesn't have to expose > re-keying messages to the application, it should generate/process them > automatically. Having said that, here is a draft variant of the text I propose: A SASL mechanism supports re-keying if it is able to generate/process messages that request immediate re-keying and it is able to carry out re-keying exchange. (a single message that does both is Ok) SASL mechanisms that support re-keying MAY also be able to indicate that re-keying will be needed in the future. A re-keying exchange can be conducted transparently by the mechanism, or the mechanism should be able to provide/accept re-keying messages to/from the application. The former can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. From owner-ietf-sasl Sat Oct 23 13:10:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKAlMA057171; Sat, 23 Oct 2004 13:10:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKAlAB057170; Sat, 23 Oct 2004 13:10:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKAkUg057163 for ; Sat, 23 Oct 2004 13:10:46 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:10:42 +0100 Message-ID: <417AA29B.7010103@isode.com> Date: Sat, 23 Oct 2004 19:27:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >>[nothing in the abstract says that's the kind of mechanisms it is >>talking about.] >> > >Mechanisms provide authentication and data security services >to connection-oriented protocols through the SASL framework. > IMHO, this just follows from: The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. So I think nothing has to be added/changed. >>The same change would be nice in the Introduction section, though of >>course the diagram there helps. >> >>Personally I would also have found an asymmetric definition easier to >>relate to: SASL defines a common interface to authentication mechanisms >>for protocols. (Is that the right way to put it?) But maybe that's not >>at all the view SASL intends to convey. Is the protocol profile the >>common interface to protocols for authentication mechanisms? >> >> > >The "protocol profile" is the part of the protocol's >technical specification which details how it makes use >of the SASL framework. > > The Introduction section currently have the following paragraph: To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions. If the use of a security layer is negotiated, that security layer is inserted between the protocol and the connection. Section 4 ("Protocol profile requirements") profiles the requirements that a protocol specification must fulfill to make use of SASL. I've added the following sentence to the end: A SASL protocol profile is a part of the protocol specification that satisfies the requirements of Section 4. Comments? Alexey From owner-ietf-sasl Sat Oct 23 13:11:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKBgb3057425; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKBgPi057422; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKBfef057406 for ; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:11:39 +0100 Message-ID: <417AB364.6050503@isode.com> Date: Sat, 23 Oct 2004 20:39:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@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: >1) Re-keying of security layers > >Nico indicated that the I-D did not discuss Re-keying of >security layers and suggested text in this area be added. >The WG discussed a number of specific suggestions in this >area, with the following text being the last version >submitted for WG consideration: > SASL mechanisms that support re-keying SHOULD: > - indicate that re-keying is or will be needed immediately; > - provide re-keying messages or transparently include re-keying > messages in the security layers; the latter can happen without > application involvement, but only as long as the application is > engaged in timely bidirectional exchanges with its peer. > After rereading this text multiple times it is clear to me that either the text is [partially] redundant, or I don't understand what it is trying to say (or maybe both). 1). "indicate that re-keying is or will be needed immediately". The first question I have after reading this sentence is "how?" Because SASL framework doesn't have any control channel or out-of-band mechanism, the only answer to this question is "by transparently including re-keying messages in the security layer". But this is a part of what the subsequent sentence is saying!? 2). "provide re-keying messages or transparently include re-keying messages in the security layers;" I think this sentence specifies requirements on SASL APIs and I am not sure whether RFC2222bis is the proper place for that. I also assume that "provide re-keying messages" is not the same thing as "transparently include re-keying messages in the security layers". I think the former is trying to say that the SASL API should be able to signal to the application that rekeying is (or will be shortly) needed, once a rekeying message is received. It also tries to say that the application should be able to say to SASL API: "send rekeying request now". The latter is trying to say that the SASL API doesn't have to expose re-keying messages to the application, it should generate/process them automatically. >The chairs believes the WG supports addition of this text. > > > From owner-ietf-sasl Sat Oct 23 16:24:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NNOp0o002318; Sat, 23 Oct 2004 16:24:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NNOpWp002317; Sat, 23 Oct 2004 16:24:51 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NNOmEx002235 for ; Sat, 23 Oct 2004 16:24:49 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CLVFd-0003cz-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Making forward progress Date: Sun, 24 Oct 2004 01:24:22 +0200 Lines: 33 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:ignQ0G4Dj5sxyEDyi7FGWkbOcpg= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I've seen no objections to Kurt's new summary of the identities issue > nor to his proposed text for section 3. I raised some issues with the new summary in: http://thread.gmane.org/gmane.ietf.sasl/1687 There were additional discussion, even some disagreement on (what I perceive as) terminology issues. I proposed a change to the proposed new text, to which Kurt acknowledged that his proposed text was not a direct replacement, and that further work was needed. Has there been a more recent proposal? I cannot seem to find it. > I think we should move forward with that change. For the record, I again object to removing the paragraphs below, at this late stage. Kurt's new summary appear, to me, to propose to remove them. The paragraphs could be reworded for clarity, as they are critical in getting the boundaries between normalization procedures in an implementation. But I have yet to see any argument to why they are technically wrong, and should be removed. Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Thanks, Simon From owner-ietf-sasl Sat Oct 23 17:22:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O0Md7l014347; Sat, 23 Oct 2004 17:22:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O0MdMp014346; Sat, 23 Oct 2004 17:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O0Mc9k014336 for ; Sat, 23 Oct 2004 17:22:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9O0MVZv031144; Sun, 24 Oct 2004 00:22:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041023170532.0301e1e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 23 Oct 2004 17:23:05 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Making forward progress Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:24 PM 10/23/2004, Simon Josefsson wrote: >Sam Hartman writes: > >> I've seen no objections to Kurt's new summary of the identities issue >> nor to his proposed text for section 3. > >I raised some issues with the new summary in: > >http://thread.gmane.org/gmane.ietf.sasl/1687 > >There were additional discussion, even some disagreement on (what I >perceive as) terminology issues. I proposed a change to the proposed >new text, to which Kurt acknowledged that his proposed text was not a >direct replacement, and that further work was needed. Has there been >a more recent proposal? I cannot seem to find it. > >> I think we should move forward with that change. > >For the record, I again object to removing the paragraphs below, at >this late stage. Kurt's new summary appear, to me, to propose to >remove them. I believe I posted a clarification that it was not my intent to suggest these statements be removed. At the time I submitted the suggested text, I presumed they would placed elsewhere in the specification. At this time, I think the majority of my "identity concept" text should be placed in an introductory section. Additionally, these statements need some clarification (as I indicated in follow-ups). >The paragraphs could be reworded for clarity, as they >are critical in getting the boundaries between normalization >procedures in an implementation. But I have yet to see any argument >to why they are technically wrong, and should be removed. Because I don't believe anyone has argued that they should be removed. > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. This statement needs to be clarified. In particular, the intent here is that the mechanism specification is solely responsible for stating how any authentication identity information is transferred as part of the exchange. However, the mechanism specification does not necessarily have any responsibility for stating how authentication identity information is represented elsewhere. For instance, an application protocol specification is free to define how authentication identities appearing in an identity-assumption policy statement are to be normalized. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). > >Thanks, >Simon From owner-ietf-sasl Sun Oct 24 06:18:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODIi6j085960; Sun, 24 Oct 2004 06:18:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ODIict085959; Sun, 24 Oct 2004 06:18:44 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODIe4F085947 for ; Sun, 24 Oct 2004 06:18:41 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CLiGn-0000WE-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Making forward progress Date: Sun, 24 Oct 2004 15:18:22 +0200 Lines: 41 Message-ID: References: <6.1.2.0.0.20041023170532.0301e1e0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:JfSljjmgLX14oVcphSilJMk1kXg= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:24 PM 10/23/2004, Simon Josefsson wrote: > >>Sam Hartman writes: >> >>> I've seen no objections to Kurt's new summary of the identities issue >>> nor to his proposed text for section 3. >> >>I raised some issues with the new summary in: >> >>http://thread.gmane.org/gmane.ietf.sasl/1687 >> >>There were additional discussion, even some disagreement on (what I >>perceive as) terminology issues. I proposed a change to the proposed >>new text, to which Kurt acknowledged that his proposed text was not a >>direct replacement, and that further work was needed. Has there been >>a more recent proposal? I cannot seem to find it. >> >>> I think we should move forward with that change. >> >>For the record, I again object to removing the paragraphs below, at >>this late stage. Kurt's new summary appear, to me, to propose to >>remove them. > > I believe I posted a clarification that it was not my intent > to suggest these statements be removed. At the time I > submitted the suggested text, I presumed they would placed > elsewhere in the specification. > > At this time, I think the majority of my "identity concept" > text should be placed in an introductory section. > > Additionally, these statements need some clarification > (as I indicated in follow-ups). Thanks. I was confused by the resolution to move forward with a change that had not yet been fleshed out. Regards, Simon From owner-ietf-sasl Sun Oct 24 06:53:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODrpTm093075; Sun, 24 Oct 2004 06:53:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ODrpa2093074; Sun, 24 Oct 2004 06:53:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODrorb093068 for ; Sun, 24 Oct 2004 06:53:50 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 24 Oct 2004 14:53:52 +0100 Message-ID: <417ACB03.4090302@isode.com> Date: Sat, 23 Oct 2004 22:20:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Sam Hartman , SASL WG Subject: Life of a security layer and error handling (was Re: Summary of 2222bis WGLC) References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041021182216.030c5238@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: [I am CCing my reply to the mailing list as discuss. I believe I've quoted enough context.] Kurt D. Zeilenga wrote: >> >>> 2). The following text is in the Security Considerations >> >>> section (as per off the list discussion with Nico): >> >>> >> >>> The secure or administratively permitted lifetimes of SASL >> >>> mechanisms' security layers are finite. Cryptographic keys >> >>> weaken as they are used and as time passes; the more time >> >>> and/or ciphertext that a cryptanalyst has after the first use >> >>> of the a key, the easier it is for the cryptanalyst to mount >> >>> attacks on the key. >> >>> >> >>> Administrative limits on security layers lifetime may take the >> >>> form of time limits expressed in x.509 certificates, Kerberos >> >>> V tickets, or in directories, and are often desired. >> >>> >> >>> In practice one likely effect of administrative security >> >>> layers lifetime limits is that applications may find that >> >>> security layers stop working in the middle of application >> >>> protocol operation, such as, perhaps, during large data >> >>> transfers. >> >>> >> >>> SASL does not provide for re-keying. SASL mechanisms may; all >> >>> future SASL mechanisms that provide security layers SHOULD >> >>> provide for re-keying. >> >>> >> >> See above comments regarding this recommendation. >> >> >> Alexey> You have to be more specific than that. I think the first >> Alexey> paragraph should stay, as it explains why rekeying is >> Alexey> needed. It should probably be reworded to state this >> Alexey> explicitly. I think the second paragraph should stay as >> Alexey> well, although I am not so sure. The third paragraph >> Alexey> should be dropped. The last paragraph should stay, >> Alexey> although it will have to be reworded (and maybe drop >> Alexey> SHOULD?). >> >>What's wrong with the third paragraph? It does tell you the >>application writer that life may be annoying, but I believe that is a >>practical statement of reality. >> > >A problem I see with the third paragraph is that it attempts to >redefine the lifetime of the layer. A layers life lasts until >either a) a new layer is installed or b) the connection closes. >There no way that a layer's life can end otherwise. If the >mechanism is no longer able to generate buffers, the connection >must be closed. It is impossible to re-key or to install a new >layer without generating buffers to accomplish that re-keying >or installation. > >This should be made clear in the document. I agree. Section 3.3 had the following sentence: 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)). I've added "or underlying connection is closed" to the text in the parentheses. >>I hope to convince mechanism designers/implementers not to have mechanisms fail mid transfer, but some mechanisms today do fail that way. >> > >SASL doesn't allow anything else. If the mechanism is not >able to produce a buffer, the connection must be closed. >That can happen anywhere within the application protocol >stream. > >This should be made clear as well. If the mechanism layer >failure results in termination of the connection. While at >the protocol and SASL layers, that termination is abrupt, >implementations should attempt to gracefully close lower >level layers (such as TLS and TCP). > Agreed. I've changed the existing text in 3.3: Once the security layer is in effect the protocol stream is processed by the security layer into buffers of protected data. Each buffer of protected 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. To: Once the security layer is in effect the protocol stream is processed by the security layer into buffers of protected data. If the security layer is not able to produce a buffer, the connection MUST be closed. If the security layer is not able to decode a received buffer, the connection MUST be closed. In both cases the underlying connection SHOULD be closed gracefully. (Inserted 3 sentences here and broke the paragraph into 2). Each buffer of protected 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 buffer. ... (I've dropped the word "following" in the last sentence.) Alexey From owner-ietf-sasl Sun Oct 24 09:16:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OGG3rL026099; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OGG34p026098; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OGG2Ip026092 for ; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id B6FEE16004F; Sun, 24 Oct 2004 12:16:19 -0400 (EDT) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> From: Sam Hartman Date: Sun, 24 Oct 2004 12:16:19 -0400 In-Reply-To: <417ACB03.4090302@isode.com> (Alexey Melnikov's message of "Sat, 23 Oct 2004 22:20:03 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: OK. My interpretation of the third paragraph was that it was saying that a layer might force a connection close. From owner-ietf-sasl Sun Oct 24 14:02:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL2jF3088449; Sun, 24 Oct 2004 14:02:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OL2j9x088448; Sun, 24 Oct 2004 14:02:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL2gqV088439 for ; Sun, 24 Oct 2004 14:02:42 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 5B687E0053; Sun, 24 Oct 2004 17:03:03 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Making forward progress References: From: Sam Hartman Date: Sun, 24 Oct 2004 17:03:03 -0400 In-Reply-To: (Simon Josefsson's message of "Sun, 24 Oct 2004 01:24:22 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> Sam Hartman writes: >> I've seen no objections to Kurt's new summary of the identities >> issue nor to his proposed text for section 3. Simon> I raised some issues with the new summary in: Simon> http://thread.gmane.org/gmane.ietf.sasl/1687 Sorry I was not clear on this. I believed you and Kurt were agreeing with each othe; I still believe that is true after reading the exchange again. --Sam From owner-ietf-sasl Sun Oct 24 14:09:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL9gu7089934; Sun, 24 Oct 2004 14:09:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OL9gat089933; Sun, 24 Oct 2004 14:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL9fdY089924 for ; Sun, 24 Oct 2004 14:09:41 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9OL9mui018443 for ; Sun, 24 Oct 2004 15:09:54 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9OL9mjW009459 for ; Sun, 24 Oct 2004 15:09:48 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9OL9T5i018988; Sun, 24 Oct 2004 16:09:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9OL9OO7018987; Sun, 24 Oct 2004 16:09:24 -0500 (CDT) Date: Sun, 24 Oct 2004 16:09:24 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Sam Hartman , SASL WG Subject: Re: Life of a security layer and error handling (was Re: Summary of 2222bis WGLC) Message-ID: <20041024210924.GF21427@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , "Kurt D. Zeilenga" , Sam Hartman , SASL WG References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417ACB03.4090302@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Where does this leave us w.r.t. re-keying? Will it be possible for future mechanisms or extensions to existing ones to provide for something better than this? Should existing mechanisms' layers expire when the session key material's useful lifetime (in terms of time or use) is exceeded? IMO, SASL must at least point out the key expiration problem and should allow for future mechs/extensions that provide for re-keying. Nico -- From owner-ietf-sasl Sun Oct 24 14:12:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLCugb090536; Sun, 24 Oct 2004 14:12:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLCuI5090535; Sun, 24 Oct 2004 14:12:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLCtDJ090528 for ; Sun, 24 Oct 2004 14:12:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0155AE0053; Sun, 24 Oct 2004 17:13:15 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> From: Sam Hartman Date: Sun, 24 Oct 2004 17:13:15 -0400 In-Reply-To: <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> (Kurt D. Zeilenga's message of "Thu, 21 Oct 2004 16:13:56 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: >> The syntax and semantics of authentication ID's are determined >> entirely by the authentication mechanism; Kurt> If you were to say the syntax and semantics of any Kurt> authentication identity information carried in the exchange Kurt> is specified by the mechanism's specification, I would Kurt> agree. Kurt> But, without that qualification, I would have to disagree. Kurt> For instance, an application protocol can certainly detail Kurt> how authentication identities are to represented in Kurt> identity-assumption policy information carried by the Kurt> protocol, and associated semantics. I agree that they can do so in the sense that if the IESG approved it, it would be a protocol action. Application protocols should not say anything about authentication identities though, because doing so would tie them to a particular mechanism. From owner-ietf-sasl Sun Oct 24 14:17:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLHfqG091657; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLHfnV091656; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLHfJP091650 for ; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9OLHr7q022562 for ; Sun, 24 Oct 2004 14:17:53 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9OLHrjW012122 for ; Sun, 24 Oct 2004 15:17:53 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9OLHYiN018998; Sun, 24 Oct 2004 16:17:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9OLHYcp018997; Sun, 24 Oct 2004 16:17:34 -0500 (CDT) Date: Sun, 24 Oct 2004 16:17:34 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC Message-ID: <20041024211734.GG21427@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417AB364.6050503@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote: > > Kurt D. Zeilenga wrote: > > >1) Re-keying of security layers > > > >Nico indicated that the I-D did not discuss Re-keying of > >security layers and suggested text in this area be added. > >The WG discussed a number of specific suggestions in this > >area, with the following text being the last version > >submitted for WG consideration: > > SASL mechanisms that support re-keying SHOULD: > > - indicate that re-keying is or will be needed immediately; > > - provide re-keying messages or transparently include re-keying > > messages in the security layers; the latter can happen without > > application involvement, but only as long as the application is > > engaged in timely bidirectional exchanges with its peer. > > > After rereading this text multiple times it is clear to me that either > the text is [partially] redundant, or I don't understand what it is > trying to say (or maybe both). > > 1). "indicate that re-keying is or will be needed immediately". > The first question I have after reading this sentence is "how?" Because > SASL framework doesn't have any control channel or out-of-band > mechanism, the only answer to this question is "by transparently > including re-keying messages in the security layer". But this is a part > of what the subsequent sentence is saying!? See below. > 2). "provide re-keying messages or transparently include re-keying > messages in the security layers;" > > I think this sentence specifies requirements on SASL APIs and I am not > sure whether RFC2222bis is the proper place for that. The answer is: by providing interfaces for the purpose of indicating key layer expiration and providing for re-key message exchanges (where mechs support it). Layer expiration, for existing mechs, should be advisory only; for new mechs I think we should insist that it be mandatory. Whether you like it or not it is possible to derive an abstract API from a protocol specification, at least a sufficiently complete and unambiguous spec :) IMO abstract API requirements/recommendations are more than Ok to include in rfc2222bis. The key word there is "abstract." > I also assume that "provide re-keying messages" is not the same thing as > "transparently include re-keying messages in the security layers". Correct. I'm not sure that any existing mechs could do either, but new mechs should definitely provide for the former. > I think the former is trying to say that the SASL API should be able to > signal to the application that rekeying is (or will be shortly) needed, > once a rekeying message is received. It also tries to say that the > application should be able to say to SASL API: "send rekeying request now". Yes. > The latter is trying to say that the SASL API doesn't have to expose > re-keying messages to the application, it should generate/process them > automatically. Yes. This approach is less than ideal. IIRC Sam favors it, at least in that it may be workable in some cases that we care about. Cheers, Nico -- From owner-ietf-sasl Sun Oct 24 14:20:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLKvMS092400; Sun, 24 Oct 2004 14:20:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLKvvU092399; Sun, 24 Oct 2004 14:20:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLKuNP092392 for ; Sun, 24 Oct 2004 14:20:56 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id B5EF9E0053; Sun, 24 Oct 2004 17:21:17 -0400 (EDT) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> From: Sam Hartman Date: Sun, 24 Oct 2004 17:21:17 -0400 In-Reply-To: <20041024210924.GF21427@binky.central.sun.com> (Nicolas Williams's message of "Sun, 24 Oct 2004 16:09:24 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Where does this leave us w.r.t. re-keying? Will it be Nicolas> possible for future mechanisms or extensions to existing Nicolas> ones to provide for something better than this? Yes. If you believe the text does not support future work in this direction please describe. Nicolas> Should Nicolas> existing mechanisms' layers expire when the session key Nicolas> material's useful lifetime (in terms of time or use) is Nicolas> exceeded? I believe that SASL mechanisms should try to avoid expiring the connection when key lifetime is exceeded because doing so creates an unacceptable user experience. There exist mechanisms that will expire though like some implementations of the GSSAPI mechanism. From owner-ietf-sasl Sun Oct 24 18:11:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P1Axpp043068; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P1AxZY043067; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P1Axep043061 for ; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9P1BDNH022514 for ; Sun, 24 Oct 2004 19:11:13 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P1BCjW009414 for ; Sun, 24 Oct 2004 19:11:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9P1Ar12019092 for ; Sun, 24 Oct 2004 20:10:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9P1ArX5019091 for ietf-sasl@imc.org; Sun, 24 Oct 2004 20:10:53 -0500 (CDT) Date: Sun, 24 Oct 2004 20:10:53 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC Message-ID: <20041025011053.GD19142@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041024211734.GG21427@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Oct 24, 2004 at 04:17:34PM -0500, Nicolas Williams wrote: > The answer is: by providing interfaces for the purpose of indicating key > layer expiration and providing for re-key message exchanges (where mechs > support it). Layer expiration, for existing mechs, should be advisory > only; for new mechs I think we should insist that it be mandatory. And, of course, the GSS-API does not provide [yet] for advisory security context expiration, so neither can SASL GSS mechanisms [yet]. It'd be a shame to add advisory security context expiration to the GSS-APIv3 work at KITTEN just for SASL, but perhaps we should. Also, there is a mitigation for this problem: use ciphers that don't require re-keying :) (I'm thinking AES-256 in some counter mode). Nico -- From owner-ietf-sasl Sun Oct 24 19:15:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2FVh5055991; Sun, 24 Oct 2004 19:15:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P2FVYm055990; Sun, 24 Oct 2004 19:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2FUmm055982 for ; Sun, 24 Oct 2004 19:15:30 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9P2FeZv039243; Mon, 25 Oct 2004 02:15:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 24 Oct 2004 19:16:13 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@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 02:13 PM 10/24/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: > >> The syntax and semantics of authentication ID's are determined > >> entirely by the authentication mechanism; > > Kurt> If you were to say the syntax and semantics of any > Kurt> authentication identity information carried in the exchange > Kurt> is specified by the mechanism's specification, I would > Kurt> agree. > > Kurt> But, without that qualification, I would have to disagree. > Kurt> For instance, an application protocol can certainly detail > Kurt> how authentication identities are to represented in > Kurt> identity-assumption policy information carried by the > Kurt> protocol, and associated semantics. > >I agree that they can do so in the sense that if the IESG approved it, >it would be a protocol action. LDAP and IMAP ACLs. What's good is a standardize access control policy if the standard does say how identities used in the authentication exchange relate to identities appearing in the policy? Say an administrative client has created a Kerberos principal for a user and then wants to authorize that user to access an object on an LDAP server. What DN should the administrative client use as the subject of the LDAP access control statement? Without a standard of some kind here, it is not possible to independently develop such a client. >Application protocols should not say >anything about authentication identities though, because doing so >would tie them to a particular mechanism. No, it would require an update of the application protocol specification to state how to manage identities associated with that particular mechanism relate to identities in the application protocol. (This doesn't mean that one cannot use new mechanisms in the protocol in absence of this update, it says that one cannot use certain policy features of that mechanism until its updated to deal with the new mechanism.) Kurt From owner-ietf-sasl Sun Oct 24 19:39:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2dWuw060814; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P2dW7s060813; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2dWt6060807 for ; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9P2dkZv039378; Mon, 25 Oct 2004 02:39:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 24 Oct 2004 19:40:18 -0700 To: Nicolas Williams From: "Kurt D. Zeilenga" Subject: Re: Summary of 2222bis WGLC Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <20041024211734.GG21427@binky.central.sun.com> References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.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: My view on re-keying is that its just another layer security service that a mechanism can offer. In regards to the SASL framework specification, how it does so (on the wire) is something for the mechanism specification to detail. And how an developer of an application protocol provides support for this mechanism is an implementation detail. The framework simply should not concern itself with such details. The design of any SASL API is limited by which mechanism aspects and protocol aspects which were accounted for in the design. If a new mechanism has aspects not previously considered by designers of a particular SASL API, then the designers of that SASL API might want to redesign their API to account for the new aspect... or decide that they simply cannot support that mechanism (or aspect of that mechanism). While we could constraint future mechanisms to currently known aspects, I think that's unwise and counter to character of SASL. At 02:17 PM 10/24/2004, Nicolas Williams wrote: >On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote: >> >> Kurt D. Zeilenga wrote: >> >> >1) Re-keying of security layers >> > >> >Nico indicated that the I-D did not discuss Re-keying of >> >security layers and suggested text in this area be added. >> >The WG discussed a number of specific suggestions in this >> >area, with the following text being the last version >> >submitted for WG consideration: >> > SASL mechanisms that support re-keying SHOULD: >> > - indicate that re-keying is or will be needed immediately; >> > - provide re-keying messages or transparently include re-keying >> > messages in the security layers; the latter can happen without >> > application involvement, but only as long as the application is >> > engaged in timely bidirectional exchanges with its peer. >> > >> After rereading this text multiple times it is clear to me that either >> the text is [partially] redundant, or I don't understand what it is >> trying to say (or maybe both). >> >> 1). "indicate that re-keying is or will be needed immediately". >> The first question I have after reading this sentence is "how?" Because >> SASL framework doesn't have any control channel or out-of-band >> mechanism, the only answer to this question is "by transparently >> including re-keying messages in the security layer". But this is a part >> of what the subsequent sentence is saying!? > >See below. > >> 2). "provide re-keying messages or transparently include re-keying >> messages in the security layers;" >> >> I think this sentence specifies requirements on SASL APIs and I am not >> sure whether RFC2222bis is the proper place for that. > >The answer is: by providing interfaces for the purpose of indicating key >layer expiration and providing for re-key message exchanges (where mechs >support it). Layer expiration, for existing mechs, should be advisory >only; for new mechs I think we should insist that it be mandatory. > >Whether you like it or not it is possible to derive an abstract API from >a protocol specification, at least a sufficiently complete and >unambiguous spec :) > >IMO abstract API requirements/recommendations are more than Ok to >include in rfc2222bis. The key word there is "abstract." > >> I also assume that "provide re-keying messages" is not the same thing as >> "transparently include re-keying messages in the security layers". > >Correct. I'm not sure that any existing mechs could do either, but new >mechs should definitely provide for the former. > >> I think the former is trying to say that the SASL API should be able to >> signal to the application that rekeying is (or will be shortly) needed, >> once a rekeying message is received. It also tries to say that the >> application should be able to say to SASL API: "send rekeying request now". > >Yes. > >> The latter is trying to say that the SASL API doesn't have to expose >> re-keying messages to the application, it should generate/process them >> automatically. > >Yes. This approach is less than ideal. IIRC Sam favors it, at least in >that it may be workable in some cases that we care about. > >Cheers, > >Nico >-- From owner-ietf-sasl Mon Oct 25 03:26:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAQjLN004437; Mon, 25 Oct 2004 03:26:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PAQjVJ004435; Mon, 25 Oct 2004 03:26:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAQiJB004363 for ; Mon, 25 Oct 2004 03:26:44 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 11:26:32 +0100 Message-ID: <417CD4D7.1050406@isode.com> Date: Mon, 25 Oct 2004 11:26:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Nicolas> Should > Nicolas> existing mechanisms' layers expire when the session key > Nicolas> material's useful lifetime (in terms of time or use) is > Nicolas> exceeded? > >I believe that SASL mechanisms should try to avoid expiring the >connection when key lifetime is exceeded because doing so creates an >unacceptable user experience. > I concur. > There exist mechanisms that will expire >though like some implementations of the GSSAPI mechanism. > > Are we talking about GSSAPI in general or a particular implementation of GSSAPI? Imagine that support for re-keying can be done without changing (extending) GSS API. In this case the SASL GSSAPI spec doesn't have to be updated. In which case the following text can be removed from 2222bis: In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. ? (or at least it has to be reworded to talk about "broken" or "old" implementations) Alexey From owner-ietf-sasl Mon Oct 25 03:39:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAdJ3f009184; Mon, 25 Oct 2004 03:39:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PAdJUn009183; Mon, 25 Oct 2004 03:39:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAdIcC009169 for ; Mon, 25 Oct 2004 03:39:18 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 11:39:18 +0100 Message-ID: <417CD7D6.70804@isode.com> Date: Mon, 25 Oct 2004 11:39:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: SASL WG Subject: Re-keying (was Re: Life of a security layer and error handling) References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> In-Reply-To: <417CD4D7.1050406@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Sam Hartman wrote: > >> Nicolas> Should >> Nicolas> existing mechanisms' layers expire when the session key >> Nicolas> material's useful lifetime (in terms of time or use) is >> Nicolas> exceeded? >> >> I believe that SASL mechanisms should try to avoid expiring the >> connection when key lifetime is exceeded because doing so creates an >> unacceptable user experience. > > I concur. > >> There exist mechanisms that will expire >> though like some implementations of the GSSAPI mechanism. > > Are we talking about GSSAPI in general or a particular implementation > of GSSAPI? > > Imagine that support for re-keying can be done without changing > (extending) GSS API. In this case the SASL GSSAPI spec doesn't have to > be updated. > In which case the following text can be removed from 2222bis: > > In practice one likely effect of administrative security layers > lifetime limits is that applications may find that security layers > stop working in the middle of application protocol operation, such > as, perhaps, during large data transfers. > > ? > (or at least it has to be reworded to talk about "broken" or "old" > implementations) I've kept the paragraph for now, here is the latest text about re-keying in Security considerations (as there is very little time before the draft submission deadline, I am going to send the updated 2222bis now): The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. Cryptographic keys weaken as they are used and as time passes; the more time and/or ciphertext that a cryptanalyst has after the first use of the a key, the easier it is for the cryptanalyst to mount attacks on the key. Administrative limits on security layers lifetime may take the form of time limits expressed in x.509 certificates, Kerberos V tickets, or in directories, and are often desired. In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. As the result of this the connection will be closed (see section 3.3), which will result in unpleasant user experience. Re-keying (key renegotiation process) is a way of addressing the weakening of cryptographic keys. SASL framework does not provide for re-keying. SASL mechanisms may; all future SASL mechanisms that provide security layers should provide for re-keying. Applications that wish to re-key SASL security layers where the mechanism does not provide for re-keying should reauthenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for re-keying in the application protocols. See section 6.3. Alexey From owner-ietf-sasl Mon Oct 25 04:18:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PBIGXM025152; Mon, 25 Oct 2004 04:18:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PBIGVe025150; Mon, 25 Oct 2004 04:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PBICIq025112 for ; Mon, 25 Oct 2004 04:18:12 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 12:17:55 +0100 Message-ID: <417CE0E3.2080401@isode.com> Date: Mon, 25 Oct 2004 12:17:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041001155050.0417fbc0@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: >>For comparison, here is part of the old text: >> >> Any normalization of the authentication identity is defined by a >> particular SASL mechanism, the protocol profile doesn't influence it. >> >> > >Though I think this needs to be slightly reworded, I agree >with the intent of the statement to say that protocol >profiles should leave of aspects of credentials and their >verification to the mechanism. However, this in no way >implies that an application protocol specification, or >its implementations, cannot detail the form of authentication >identity the application protocol (or implementation) might >use otherwise. For instance, an application protocol >specification could detail how to represent authentication >identities in an identity assumption authorization policy. > > I've updated the existing sentence as follows (I am still not satisfied with how it looks): Any normalization of the authentication identity (for the purposes of conducting authentication exchange) is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Note, that the mechanism specification doesn't control how authentication identity information is represented elsewhere. I think we need to expand on "elsewhere" part. From owner-ietf-sasl Mon Oct 25 06:24:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDOqb3038457; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDOqZ3038456; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDOqhO038450 for ; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 45AF17681D; Mon, 25 Oct 2004 09:24:48 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> From: Sam Hartman Date: Mon, 25 Oct 2004 09:24:47 -0400 In-Reply-To: <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 24 Oct 2004 19:16:13 -0700") Message-ID: <87lldv9bhc.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: >> Kurt> But, without that qualification, I would have to disagree. Kurt> For instance, an application protocol can certainly detail Kurt> how authentication identities are to represented in Kurt> identity-assumption policy information carried by the Kurt> protocol, and associated semantics. >> I agree that they can do so in the sense that if the IESG >> approved it, it would be a protocol action. Kurt> LDAP and IMAP ACLs. Kurt> What's good is a standardize access control policy if the Kurt> standard does say how identities used in the authentication Kurt> exchange relate to identities appearing in the policy? Kurt> Say an administrative client has created a Kerberos Kurt> principal for a user and then wants to authorize that user Kurt> to access an object on an LDAP server. What DN should the Kurt> administrative client use as the subject of the LDAP access Kurt> control statement? I was thinking too narrowly. --Sam From owner-ietf-sasl Mon Oct 25 06:21:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDLCqk038129; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDLCeh038128; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDLBpG038120 for ; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 0014C7681D; Mon, 25 Oct 2004 09:21:01 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> From: Sam Hartman Date: Mon, 25 Oct 2004 09:21:01 -0400 In-Reply-To: <417CD4D7.1050406@isode.com> (Alexey Melnikov's message of "Mon, 25 Oct 2004 11:26:31 +0100") Message-ID: <87pt379bnm.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Sam Hartman wrote: Nicolas> Should existing mechanisms' layers expire when the Nicolas> session key material's useful lifetime (in terms of time Nicolas> or use) is exceeded? >> I believe that SASL mechanisms should try to avoid expiring >> the connection when key lifetime is exceeded because doing so >> creates an unacceptable user experience. >> Alexey> I concur. >> There exist mechanisms that will expire though like some >> implementations of the GSSAPI mechanism. >> >> Alexey> Are we talking about GSSAPI in general or a particular Alexey> implementation of GSSAPI? We're talking about RFC 1964 and most implementations of that spec. Alexey> Imagine that support for re-keying can be done without Alexey> changing (extending) GSS API. I did. Unfortunately, Nico convinced me that my fantasy had no basis in reality. You cannot guarantee that both parties are sending, which is required for rekeying. ALso, you have bad interactions with gss_wrap_size_limit. Alexey> In this case the SASL GSSAPI Alexey> spec doesn't have to be updated. In which case the Alexey> following text can be removed from 2222bis: Alexey> In practice one likely effect of administrative security Alexey> layers lifetime limits is that applications may find that Alexey> security layers stop working in the middle of application Alexey> protocol operation, such as, perhaps, during large data Alexey> transfers. I agree that implementations that work this way are broken. Nico does not. Nor does the IETF; RFC 1964 mandates this behavior. --Sam From owner-ietf-sasl Mon Oct 25 06:37:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDbFGf039596; Mon, 25 Oct 2004 06:37:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDbFsP039595; Mon, 25 Oct 2004 06:37:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDbDP8039589 for ; Mon, 25 Oct 2004 06:37:14 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 14:37:12 +0100 Message-ID: <417D0188.9020409@isode.com> Date: Mon, 25 Oct 2004 14:37:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> In-Reply-To: <87pt379bnm.fsf@luminous.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Alexey> Imagine that support for re-keying can be done without > Alexey> changing (extending) GSS API. > >I did. Unfortunately, Nico convinced me that my fantasy had no basis >in reality. You cannot guarantee that both parties are sending, which >is required for rekeying. ALso, you have bad interactions with >gss_wrap_size_limit. > > Then we need to update the SASL GSSAPI document (suggestions are welcome). > Alexey> In this case the SASL GSSAPI > Alexey> spec doesn't have to be updated. In which case the > Alexey> following text can be removed from 2222bis: > > Alexey> In practice one likely effect of administrative security > Alexey> layers lifetime limits is that applications may find that > Alexey> security layers stop working in the middle of application > Alexey> protocol operation, such as, perhaps, during large data > Alexey> transfers. > >I agree that implementations that work this way are broken. Nico does >not. Nor does the IETF; RFC 1964 mandates this behavior. > > The paragraph as written may suggest that there is a problem with SASL framework, when there is none. The text has to be rewritten to clarify that. Alexey From owner-ietf-sasl Mon Oct 25 07:11:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PEBtop041904; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PEBte5041903; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PEBtfG041897 for ; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 6AA6F7681D; Mon, 25 Oct 2004 10:11:51 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> From: Sam Hartman Date: Mon, 25 Oct 2004 10:11:51 -0400 In-Reply-To: <417D0188.9020409@isode.com> (Alexey Melnikov's message of "Mon, 25 Oct 2004 14:37:12 +0100") Message-ID: <87vfcy99aw.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Nico and some others would argue there is a problem with the SASL framework: it doesn't support rekeying at the SASL level. It clearly could be changed to do so; we as a a working group have decided not to do so. I think we made that decision for a lot of good reasons. If you want to rework the text, I'd recommend making it be fault-agnostic. Simply describe the effect without trying to claim any of the specs involved are broken. From owner-ietf-sasl Mon Oct 25 09:19:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGJRPK063024; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGJRvM063023; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGJRiC063017 for ; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9PGJU7q017678 for ; Mon, 25 Oct 2004 09:19:30 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PGJTjW015900 for ; Mon, 25 Oct 2004 10:19:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9PGJ8ZV019484; Mon, 25 Oct 2004 11:19:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9PGJ7UR019483; Mon, 25 Oct 2004 11:19:07 -0500 (CDT) Date: Mon, 25 Oct 2004 11:19:07 -0500 From: Nicolas Williams To: Sam Hartman Cc: Alexey Melnikov , SASL WG Subject: Re: Life of a security layer and error handling Message-ID: <20041025161906.GN21427@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Alexey Melnikov , SASL WG References: <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vfcy99aw.fsf@luminous.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman wrote: > > I think Nico and some others would argue there is a problem with the > SASL framework: it doesn't support rekeying at the SASL level. It > clearly could be changed to do so; we as a a working group have > decided not to do so. I think we made that decision for a lot of good > reasons. I agree that existing SASL mechanisms' lack of re-keying support should be grandfathered. Going forward though I see no good reason not to require support for re-keying (or re-key-less ciphers/modes) in new/revised SASL mechanisms, that includes the revised GSS mechs draft. (If SASL were a new proposal today, would a spec w/o re-keying get past WG, IETF and IESG reviews? I rather doubt it.) > If you want to rework the text, I'd recommend making it be > fault-agnostic. Simply describe the effect without trying to claim > any of the specs involved are broken. Heh. But see above. Nico -- From owner-ietf-sasl Mon Oct 25 09:51:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGpY8E070929; Mon, 25 Oct 2004 09:51:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGpYSk070928; Mon, 25 Oct 2004 09:51:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGpXpY070916 for ; Mon, 25 Oct 2004 09:51:33 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C539D168027; Mon, 25 Oct 2004 12:51:45 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> From: Sam Hartman Date: Mon, 25 Oct 2004 12:51:45 -0400 In-Reply-To: <20041025161906.GN21427@binky.central.sun.com> (Nicolas Williams's message of "Mon, 25 Oct 2004 11:19:07 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman Nicolas> wrote: >> I think Nico and some others would argue there is a problem >> with the SASL framework: it doesn't support rekeying at the >> SASL level. It clearly could be changed to do so; we as a a >> working group have decided not to do so. I think we made that >> decision for a lot of good reasons. Nicolas> I agree that existing SASL mechanisms' lack of re-keying Nicolas> support should be grandfathered. Nicolas> Going forward though I see no good reason not to require Nicolas> support for re-keying (or re-key-less ciphers/modes) in Nicolas> new/revised SASL mechanisms, that includes the revised Nicolas> GSS mechs draft. I don't think there is current WG consensus to support something as strong as a requirement. I believe Kurt's summary is consistent with this position. I would certainly encourage you to make sure all new SASL mechanisms support rekeying; I certainly plan to try and do the same. From owner-ietf-sasl Mon Oct 25 10:20:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PHKuBW078791; Mon, 25 Oct 2004 10:20:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PHKu1S078790; Mon, 25 Oct 2004 10:20:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PHKtDe078784 for ; Mon, 25 Oct 2004 10:20:55 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9PHKwNH010457 for ; Mon, 25 Oct 2004 11:20:58 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PHKwjW000574 for ; Mon, 25 Oct 2004 11:20:58 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9PHKbnF019540; Mon, 25 Oct 2004 12:20:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9PHKbJk019539; Mon, 25 Oct 2004 12:20:37 -0500 (CDT) Date: Mon, 25 Oct 2004 12:20:37 -0500 From: Nicolas Williams To: Sam Hartman Cc: Alexey Melnikov , SASL WG Subject: Re: Life of a security layer and error handling Message-ID: <20041025172037.GS21427@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Alexey Melnikov , SASL WG References: <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote: > I don't think there is current WG consensus to support something as > strong as a requirement. Well, yeah, technically it's hard to impose requirements on future protocol work :) I must have been hoping that some verbiage to that effect would make it easier to force the matter later when new mechs/mech revisions come along. But I think you're right. IOW, I will settle for Security Considerations text on this. > I believe Kurt's summary is consistent with this position. > > I would certainly encourage you to make sure all new SASL mechanisms > support rekeying; I certainly plan to try and do the same. Thank you. I will. Nico -- From owner-ietf-sasl Mon Oct 25 11:37:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PIbeJV097613; Mon, 25 Oct 2004 11:37:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PIbdig097612; Mon, 25 Oct 2004 11:37:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PIbcBV097581 for ; Mon, 25 Oct 2004 11:37:39 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9PIbeZv045908; Mon, 25 Oct 2004 18:37:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041025112650.03231a28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 25 Oct 2004 11:38:12 -0700 To: Nicolas Williams From: "Kurt D. Zeilenga" Subject: Re: Life of a security layer and error handling Cc: Sam Hartman , Alexey Melnikov , SASL WG In-Reply-To: <20041025172037.GS21427@binky.central.sun.com> References: <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> <20041025172037.GS21427@binky.central.sun.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:20 AM 10/25/2004, Nicolas Williams wrote: >On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote: >> I don't think there is current WG consensus to support something as >> strong as a requirement. > >Well, yeah, technically it's hard to impose requirements on future >protocol work :) And its even harder to impose a particular kind of solution to a security consideration. Rekeying is a possible solution to a security consideration. It's not the only viable solution to that security consideration. The framework specification should elaborate on the security consideration regarding the life of the layer and leave it to mechanism designers to determine how to best address these issues. It might be okay to suggest the designer consider particular solutions, but I do not think it appropriate to recommend a particular solution be used in all future mechanisms. Kurt From owner-ietf-sasl Mon Oct 25 12:04:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PJ4MbD004185; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PJ4MAA004184; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PJ4LYn004151 for ; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 788E3168027; Mon, 25 Oct 2004 15:04:35 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.com> <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> From: Sam Hartman Date: Mon, 25 Oct 2004 15:04:35 -0400 In-Reply-To: <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 24 Oct 2004 19:40:18 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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 view on re-keying is that its just another layer security Kurt> service that a mechanism can offer. In regards to the SASL Kurt> framework specification, how it does so (on the wire) is Kurt> something for the mechanism specification to detail. And Kurt> how an developer of an application protocol provides support Kurt> for this mechanism is an implementation detail. The Kurt> framework simply should not concern itself with such Kurt> The design of any SASL API is limited by which mechanism Kurt> aspects and protocol aspects which were accounted for in the Kurt> design. If a new mechanism has aspects not previously Kurt> considered by designers of a particular SASL API, then the Kurt> designers of that SASL API might want to redesign their API Kurt> to account for the new aspect... or decide that they simply Kurt> cannot support that mechanism (or aspect of that mechanism). Kurt> While we could constraint future mechanisms to currently Kurt> known aspects, I think that's unwise and counter to Kurt> character of SASL. It's been my experience in other IETF work that it is strongly desirable for framework documents to enumerate the aspects of mechanisms of the framework that are generally applicable at the time the framework document is written. Doing so is useful to API and implementation designers. However I cannot claim today that support for this service (re-keying) is generally available in today's SASL mechanisms. So I agree that this revision of the framework should not concern itself with that service. --Sam From owner-ietf-sasl Tue Oct 26 14:04:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4iAR035779; Tue, 26 Oct 2004 14:04:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL4i8S035778; Tue, 26 Oct 2004 14:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4gVH035772 for ; Tue, 26 Oct 2004 14:04:43 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21555; Tue, 26 Oct 2004 17:04:44 -0400 (EDT) Message-Id: <200410262104.RAA21555@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Tue, 26 Oct 2004 17:04:44 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-05.txt Pages : 9 Date : 2004-10-26 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161223.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 26 14:04:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4QEW035734; Tue, 26 Oct 2004 14:04:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL4QPe035733; Tue, 26 Oct 2004 14:04:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4O35035718 for ; Tue, 26 Oct 2004 14:04:25 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21521; Tue, 26 Oct 2004 17:04:25 -0400 (EDT) Message-Id: <200410262104.RAA21521@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-anon-04.txt Date: Tue, 26 Oct 2004 17:04:25 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Anonymous SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-anon-04.txt Pages : 9 Date : 2004-10-26 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-anon-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-anon-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-anon-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-anon-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161218.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 26 15:55:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMtOpQ058244; Tue, 26 Oct 2004 15:55:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QMtODC058243; Tue, 26 Oct 2004 15:55:24 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMtGYw058200 for ; Tue, 26 Oct 2004 15:55:16 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMaDi-0007u8-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: CRAMing for last call Date: Wed, 27 Oct 2004 00:55:10 +0200 Lines: 70 Message-ID: References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:7HnbOMol+wB6oa5kJXxJLx9Ko/E= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello. Some comments on the latest cram-md5 draft. In this post: http://thread.gmane.org/gmane.ietf.sasl/1457 Kurt suggest to explain why the IANA USAGE field of CRAM-MD5 is LIMITED. I too believe this would be useful, to make readers realize they might want PLAIN+TLS, DIGEST-MD5 or GSSAPI instead. There are a few (minor, mostly editorial) suggestions in Kurt's post that has not been addressed, that I believe make sense. Next, I believe it would be useful to tighten up the language in the following paragraph: The mechanism starts with the server issuing a challenge. The data encoded in the challenge contains a presumptively arbitrary string of random data. I suggest to remove "presumptively arbitrary" and add a reference to RFC 1750 after the word "random". Possibly it could be worded differently, because there is quite some structure in the challenge, not complete random data. I read RFC 2104, but it does not say anything about randomness or structure of the challenge text. It may be useful to find some other reference on the properties of challenge strings in CRAM-MD5, or to ask the CFRG for guidance. Next, there were discussion regarding SASLprep unassigned code points in this thread: http://thread.gmane.org/gmane.ietf.sasl/1342 I agree with Kurt that it should be clarified that the client copy of the user name and shared secret should be defined as query strings. I think this would be achieved by adding after: The client MUST prepare the user name and shared secret strings using the SASLPrep [draft-ietf-sasl-saslprep] profile of the StringPrep [RFC3454] algorithm. the following: The client MUST treat the user name and shared secret string as query strings, consequently unassigned code points should be allowed in the prepared output. The server MUST treat the received user name, and the password (regardless of whether it is in unprepared, prepared or hashed form), as stored strings, and consequently disallow unassigned code points in the prepared output that is used as input to the keyed hash operation. Without such text, there is an ambiguity how to invoke SASLPrep. I believe the text belong in CRAM-MD5, as string preparation is a mechanism issue. It does not seem to belong in SASLPrep or 2222bis. Further, RFC 2279 has been obsoleted by RFC 3629: The resulting values MUST be encoded as UTF-8 [RFC2279] strings. I suggest adding a paragraph break after the previous sentence, and the generic recommendations on storing prepared strings. Next, because CRAM-MD5 do not provide a security layer, it should have a reference to TLS and some security consideration suggesting TLS, or similar, if active attacks or privacy issues are a threat. Compare PLAIN. Finally, RFC 2104 is INFORMATIONAL. Can it be a normative reference? Thanks. From owner-ietf-sasl Tue Oct 26 19:31:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2Vp7t010309; Tue, 26 Oct 2004 19:31:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R2Vp4T010308; Tue, 26 Oct 2004 19:31:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2VoY9010252 for ; Tue, 26 Oct 2004 19:31:50 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9R2VkZv057836 for ; Wed, 27 Oct 2004 02:31:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026192702.0308a5d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 19:32:16 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt In-Reply-To: <200410262104.RAA21521@ietf.org> References: <200410262104.RAA21521@ietf.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: In this revision, aside from editorial changes, the following change was made: - The purpose of the mechanism was clarified. I believe this document should now be progressed to the IESG. Kurt At 02:04 PM 10/26/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : The Anonymous SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-anon-04.txt > Pages : 9 > Date : 2004-10-26 > >It is common practice on the Internet to permit anonymous access to >various services. Traditionally, this has been done with a plain text >password mechanism using 'anonymous' as the user name and optional >trace information, such as an email address, as the password. As >plaintext login commands are not permitted in new IETF protocols, a >new way to provide anonymous login is needed within the context of the >Simple Authentication and Security Layer (SASL) framework. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-anon-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-anon-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-26161218.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-anon-04.txt > > From owner-ietf-sasl Tue Oct 26 19:46:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2k6Gn013685; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R2k6EP013684; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2k5Pi013678 for ; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9R2kCZv057945 for ; Wed, 27 Oct 2004 02:46:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 19:46:42 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt In-Reply-To: <200410262104.RAA21555@ietf.org> References: <200410262104.RAA21555@ietf.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: In this revision, aside from minor editorial changes, the message clarified to be a string of UTF-8 encoded Unicode characters and the use of %x00 for NULL (U+0000) was clarified to be the UTF-8 encoding of the NULL character. I believe this document should now be progressed to the IESG. -- Kurt PS: the double blanklines in the I-D is a new Secretariat'ism which seems to be inflicted on new I-Ds. At 02:04 PM 10/26/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : The Plain SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-plain-05.txt > Pages : 9 > Date : 2004-10-26 > >This document defines a simple clear-text user/password Simple >Authentication and Security Layer (SASL) mechanism called the PLAIN >mechanism. The PLAIN mechanism intended to be used, in combination >with data confidentiality services provided by a lower layer, in >protocols which lack a simple password authentication command. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-plain-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-plain-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-26161223.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-plain-05.txt > > From owner-ietf-sasl Wed Oct 27 02:30:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9Ulgg077558; Wed, 27 Oct 2004 02:30:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9UlDT077557; Wed, 27 Oct 2004 02:30:47 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9UkZ2077539 for ; Wed, 27 Oct 2004 02:30:46 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMk8k-0005AA-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 11:30:34 +0200 Lines: 23 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:v0Tq52Rg8FxsYAYq6YR3k1Vb2UY= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Why is SHALL used instead of MUST in the paragraph below? Are there known situations where PLAIN will be used without SASLPrep? Why shouldn't a failed string preparation always lead to verification failure? Further, please make it explicit which strings are query strings and which are stored strings, and mention the value of the AllowUnassigned flag for each string using MUST. It seems the intention is that all strings received from the client are query strings, and the password (whether stored in unprepared, prepared or hashed form) is a stored string. If you don't see why this is necessary, I can elaborate. The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. Thanks. From owner-ietf-sasl Wed Oct 27 02:36:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9asIm080585; Wed, 27 Oct 2004 02:36:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9asHc080584; Wed, 27 Oct 2004 02:36:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9arUW080572 for ; Wed, 27 Oct 2004 02:36:53 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMkEg-0005Ou-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt Date: Wed, 27 Oct 2004 11:36:50 +0200 Lines: 15 Message-ID: References: <200410262104.RAA21521@ietf.org> <6.1.2.0.0.20041026192702.0308a5d0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Jhj0urqIfmtxV2f3w+FxW6epL+k= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For what it's worth, I reviewed the document and it looks good to me. A small nit though. The following paragraph The ANONYMOUS mechanism grants access to services and/or resources by anyone. For this reason it should be disabled by default so the administrator can make an explicit decision to enable it. might imply something that wasn't intended. It seems some protocols could be anonymous in nature (think NNTP). Then it wouldn't make sense to require administrators to explicitly enable ANONYMOUS. ANONYMOUS logins to NNTP servers can be meaningful, think of the trace information provided. Thanks. From owner-ietf-sasl Wed Oct 27 03:08:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RA8n4e095870; Wed, 27 Oct 2004 03:08:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RA8na0095868; Wed, 27 Oct 2004 03:08:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RA8mdC095857 for ; Wed, 27 Oct 2004 03:08:48 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id i9RA8bjx000677 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 27 Oct 2004 03:08:37 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i9RA8bjx000677 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=DqG8nxUzrSWL4xp2xCFC3STMLeyrM88ZvgEA2X7brDg4OFeDd5MUfy99er/hf1vAI Ugd2nouS+G3qjLoLM0cgCAhwbDHDgU4rbjKFbYedG4EMtau8EuFXjNydUqJTE3EEZdl okBgD9Vnibz3hr+F+KmywVIIy5lBfFB8uzuEwns= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i9RA8YtM038902; Wed, 27 Oct 2004 03:08:36 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200410271008.i9RA8YtM038902@lab.smi.sendmail.com> To: Simon Josefsson Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt In-reply-to: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> Date: Wed, 27 Oct 2004 03:08:34 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson writes: >Why is SHALL used instead of MUST in the paragraph below? Per RFC 2119, SHALL and MUST have the same meaning: --- 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. --- Philip Guenther From owner-ietf-sasl Wed Oct 27 06:35:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDZsPx062923; Wed, 27 Oct 2004 06:35:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RDZsjU062922; Wed, 27 Oct 2004 06:35:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDZlsn062865 for ; Wed, 27 Oct 2004 06:35:47 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMnxs-00012v-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 15:35:45 +0200 Lines: 18 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <200410271008.i9RA8YtM038902@lab.smi.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:mIZaNd32vnjtOx2B4CKBn3FDtNA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther writes: > Simon Josefsson writes: >>Why is SHALL used instead of MUST in the paragraph below? > > Per RFC 2119, SHALL and MUST have the same meaning: > --- > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > --- Oops, what a thinko. Thanks. Still, making explicit which strings are to be considered query strings and stored strings still seem useful. Sorry, Simon From owner-ietf-sasl Wed Oct 27 11:09:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RI9cHY025280; Wed, 27 Oct 2004 11:09:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RI9cFO025279; Wed, 27 Oct 2004 11:09:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RI9VX2025247 for ; Wed, 27 Oct 2004 11:09:31 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RI9KZv064032; Wed, 27 Oct 2004 18:09:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 11:09:47 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@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 02:30 AM 10/27/2004, Simon Josefsson wrote: >Further, please make it explicit which strings are query strings and >which are stored strings, Personally, I think the current text is sufficiently clear. However, adding: The presented strings are to be regarded as "query" strings [StringPrep]. as the 3rd sentence of the quoted paragraph could further clarify which strings are to regarded as "query" strings. I do not see any ambiguity as to which strings are to be considered "stored" strings. >and mention the value of the AllowUnassigned >flag for each string using MUST. I cannot find the term "AllowUnassigned flag" anywhere in the specification (including normative references). The text does, however, not only says that strings SHALL be prepared in accordance with StringPrep, it describes what that means in regards to unassigned code points and the two classes of strings. >It seems the intention is that all >strings received from the client are query strings, and the password >(whether stored in unprepared, prepared or hashed form) is a stored >string. If you don't see why this is necessary, I can elaborate. > > The presented authentication identity and password strings are not to > be compared directly with stored strings. The server SHALL first > prepare authentication identity and password strings using the > [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of > [StringPrep], unassigned code points may appear in prepared presented > (query) strings but are prohibited in stored strings. If preparation > fails or results in an empty string, verification SHALL fail. If the > server stores only the hash of expected string, the string MUST be > prepared before generation of the hash. > >Thanks. From owner-ietf-sasl Wed Oct 27 11:42:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RIgGLp032185; Wed, 27 Oct 2004 11:42:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RIgGaX032184; Wed, 27 Oct 2004 11:42:16 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RIgBwP032142 for ; Wed, 27 Oct 2004 11:42:11 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMskQ-0004a7-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 20:42:10 +0200 Lines: 22 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Ud3K8wx8XSwuABa0BbPTfWwy0Ak= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>Further, please make it explicit which strings are query strings and >>which are stored strings, > > Personally, I think the current text is sufficiently clear. > However, adding: > The presented strings are to be regarded as "query" > strings [StringPrep]. > as the 3rd sentence of the quoted paragraph could further > clarify which strings are to regarded as "query" strings. > I do not see any ambiguity as to which strings are to > be considered "stored" strings. A password that the server receive from some online external database (i.e., not "stored" locally) could be considered a query string (from the database) into the verification process. From the server's point of view, it is "querying" whether the password it knows is the same as the one provided by the client. So I see an ambiguity. Thanks. From owner-ietf-sasl Wed Oct 27 12:26:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJQjoM041532; Wed, 27 Oct 2004 12:26:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RJQjv2041531; Wed, 27 Oct 2004 12:26:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJQbK8041473 for ; Wed, 27 Oct 2004 12:26:37 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RJQTZv064526; Wed, 27 Oct 2004 19:26:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 12:26:57 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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:42 AM 10/27/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>Further, please make it explicit which strings are query strings and >>>which are stored strings, >> >> Personally, I think the current text is sufficiently clear. >> However, adding: >> The presented strings are to be regarded as "query" >> strings [StringPrep]. >> as the 3rd sentence of the quoted paragraph could further >> clarify which strings are to regarded as "query" strings. >> I do not see any ambiguity as to which strings are to >> be considered "stored" strings. > >A password that the server receive from some online external database >(i.e., not "stored" locally) could be considered a query string (from >the database) into the verification process. From a SASL PLAIN perspective, any such database as to be viewed as part of the server implementation. Whether the database is "internal" or "external" is simply an implementation detail. From this perspective, the password stored is a stored string. It's irrelevant whether the server stores in a local or remote database. (I'm getting a sense of "deja vu" here, didn't we already discuss this issue? If so, is there a particular reason why we should repeat that discussion?) > From the server's point >of view, it is "querying" whether the password it knows is the same as >the one provided by the client. So I see an ambiguity. > >Thanks. It seems you are saying: From the server's point of view, the server is "querying" whether the password the server knows is the same as the one provided by the client. Er, in this case, I think server is "determining" would be a more appropriate verb as its not clear who the server would be querying to do a comparison between the password it knows (e.g., stored string) and the one provided by the client (e.g., the presented string). But as this makes little sense in the context of the above discussion, so you must have meant to say something else. Please clarify. Thanks, Kurt From owner-ietf-sasl Wed Oct 27 14:34:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLYZVl071922; Wed, 27 Oct 2004 14:34:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLYZR3071921; Wed, 27 Oct 2004 14:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLYQpu071862 for ; Wed, 27 Oct 2004 14:34:26 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C8F31178025; Wed, 27 Oct 2004 17:34:29 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> From: Sam Hartman Date: Wed, 27 Oct 2004 17:34:29 -0400 In-Reply-To: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 27 Oct 2004 11:09:47 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >> Further, please make it explicit which strings are query >> strings and which are stored strings, Kurt> Personally, I think the current text is sufficiently clear. Kurt> However, adding: The presented strings are to be regarded as Kurt> "query" strings [StringPrep]. as the 3rd sentence of the Kurt> quoted paragraph could further clarify which strings are to Kurt> regarded as "query" strings. I do not see any ambiguity as Kurt> to which strings are to be considered "stored" strings. In my mind adding this text makes the draft more confusing and does not add anything. It's my opinion that the working group has already reached consensus on this draft. If people believe that the draft does not reflect that consensus, please bring forward that disagreement. However the bar for opening new issues should be very high at this point. --Sam From owner-ietf-sasl Wed Oct 27 14:37:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLbX2b072483; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLbXZw072482; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLbXUJ072475 for ; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 5659C178025; Wed, 27 Oct 2004 17:37:54 -0400 (EDT) To: ietf-sasl@imc.org Subject: Sending anonymous and plain to the IESG Message-Id: <20041027213754.5659C178025@cz.mit.edu> Date: Wed, 27 Oct 2004 17:37:54 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. It's my intent to do an id-nits review on plain and anonymous. Assuming I see no problems I'll send them to the IESG early next week. If there are resaons this should not happen please let me know before then. --Sam From owner-ietf-sasl Wed Oct 27 14:57:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLvNZK077160; Wed, 27 Oct 2004 14:57:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLvNcB077159; Wed, 27 Oct 2004 14:57:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLvM9D077152 for ; Wed, 27 Oct 2004 14:57:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0F879178025; Wed, 27 Oct 2004 17:57:39 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: CRAMing for last call References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> From: Sam Hartman Date: Wed, 27 Oct 2004 17:57:39 -0400 In-Reply-To: (Simon Josefsson's message of "Wed, 27 Oct 2004 00:55:10 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> Finally, RFC 2104 is INFORMATIONAL. Can it be a normative Simon> reference? Yes. Recently a BCP on dealing with this was published. --Sam From owner-ietf-sasl Wed Oct 27 15:04:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM4bVG078370; Wed, 27 Oct 2004 15:04:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RM4bRn078369; Wed, 27 Oct 2004 15:04:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM4a4U078363 for ; Wed, 27 Oct 2004 15:04:36 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id E101F178025; Wed, 27 Oct 2004 18:04:53 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> From: Sam Hartman Date: Wed, 27 Oct 2004 18:04:53 -0400 In-Reply-To: <417AB364.6050503@isode.com> (Alexey Melnikov's message of "Sat, 23 Oct 2004 20:39:16 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> 1). "indicate that re-keying is or will be needed Alexey> immediately". The first question I have after reading Alexey> this sentence is "how?" Because SASL framework doesn't Alexey> have any control channel or out-of-band mechanism, the Alexey> only answer to this question is "by transparently Alexey> including re-keying messages in the security layer". But Alexey> this is a part of what the subsequent sentence is saying!? By returning some status to the application or setting a flag. You can generally tell you need to re-key without sending anything over the wire. --Sam From owner-ietf-sasl Wed Oct 27 15:08:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM8it1079003; Wed, 27 Oct 2004 15:08:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RM8iuU079002; Wed, 27 Oct 2004 15:08:44 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM8gFS078992 for ; Wed, 27 Oct 2004 15:08:43 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMvyJ-0003F6-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Thu, 28 Oct 2004 00:08:43 +0200 Lines: 82 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:XO4jfXh1J93c9S3+sXyTDxTDUyE= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 11:42 AM 10/27/2004, Simon Josefsson wrote: > >>"Kurt D. Zeilenga" writes: >> >>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>Further, please make it explicit which strings are query strings and >>>>which are stored strings, >>> >>> Personally, I think the current text is sufficiently clear. >>> However, adding: >>> The presented strings are to be regarded as "query" >>> strings [StringPrep]. >>> as the 3rd sentence of the quoted paragraph could further >>> clarify which strings are to regarded as "query" strings. >>> I do not see any ambiguity as to which strings are to >>> be considered "stored" strings. >> >>A password that the server receive from some online external database >>(i.e., not "stored" locally) could be considered a query string (from >>the database) into the verification process. > > From a SASL PLAIN perspective, any such database as to be > viewed as part of the server implementation. Whether the > database is "internal" or "external" is simply an > implementation detail. From this perspective, the > password stored is a stored string. It's irrelevant > whether the server stores in a local or remote database. I don't think this follow from the specification. What I am looking for is text that say that the PLAIN server code should treat the local password as a stored string. Currently, it seems to me that you and the PLAIN document only assume that the password can only be viewed as a stored string. It would be better if the document was explicit about it. The problem is rooted in that StringPrep (SASLPrep) do not define in who's view strings should be considered query or stored strings. What is a stored string from one point of view, may be considered a query string from another point of view. So any document using SASLPrep must define which strings are query strings, and which are stored strings. It does not follow implicitly. In lesser words, please modify your proposed sentence into the following and add it: The presented strings are to be regarded as "query" strings [StringPrep], and the local strings as "stored" strings. > (I'm getting a sense of "deja vu" here, didn't we already > discuss this issue? If so, is there a particular reason > why we should repeat that discussion?) I don't recall what the conclusion was of any earlier discussion, if any, and I believe the current document should be improved. >> From the server's point >>of view, it is "querying" whether the password it knows is the same as >>the one provided by the client. So I see an ambiguity. >> >>Thanks. > > It seems you are saying: > From the server's point of view, the server is > "querying" whether the password the server knows > is the same as the one provided by the client. > > Er, in this case, I think server is "determining" would > be a more appropriate verb as its not clear who the > server would be querying to do a comparison between > the password it knows (e.g., stored string) and the one > provided by the client (e.g., the presented string). > > But as this makes little sense in the context of the above > discussion, so you must have meant to say something else. > Please clarify. To my reading, your explanation describe what I mean. Thanks. From owner-ietf-sasl Wed Oct 27 15:50:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RMoYtd087436; Wed, 27 Oct 2004 15:50:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RMoYkx087435; Wed, 27 Oct 2004 15:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RMoSSw087410 for ; Wed, 27 Oct 2004 15:50:28 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RMoKZv066019; Wed, 27 Oct 2004 22:50:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 15:50:48 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@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 03:08 PM 10/27/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> At 11:42 AM 10/27/2004, Simon Josefsson wrote: >> >>>"Kurt D. Zeilenga" writes: >>> >>>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>>Further, please make it explicit which strings are query strings and >>>>>which are stored strings, >>>> >>>> Personally, I think the current text is sufficiently clear. >>>> However, adding: >>>> The presented strings are to be regarded as "query" >>>> strings [StringPrep]. >>>> as the 3rd sentence of the quoted paragraph could further >>>> clarify which strings are to regarded as "query" strings. >>>> I do not see any ambiguity as to which strings are to >>>> be considered "stored" strings. >>> >>>A password that the server receive from some online external database >>>(i.e., not "stored" locally) could be considered a query string (from >>>the database) into the verification process. >> >> From a SASL PLAIN perspective, any such database as to be >> viewed as part of the server implementation. Whether the >> database is "internal" or "external" is simply an >> implementation detail. From this perspective, the >> password stored is a stored string. It's irrelevant >> whether the server stores in a local or remote database. > >I don't think this follow from the specification. It follows from SASL PLAIN being a client/server protocol specification. Everything on side is referred the client. Everything on the other is referred to as the server. The architecture of the client and server are irrelevant to the protocol. It matters not whether the peer is constructed from many components which interact in some way or the peer is constructed as a monolith, because the peers obligations to the other peer is the same regardless. >What I am looking for is text that say that the PLAIN server code >should treat the local password as a stored string. What's a "local password"? >Currently, it >seems to me that you and the PLAIN document only assume that the >password can only be viewed as a stored string. The presented string is compared against a stored string (or equivalent). What the document doesn't say, and shouldn't say, is in which component that comparison is made or in what component of the server stored values are fetched from or any other implementation detail. >It would be better if >the document was explicit about it. > >The problem is rooted in that StringPrep (SASLPrep) do not define in >who's view strings should be considered query or stored strings. Stringprep relies on incorporating specifications to detail their view as to what is to be regarded as a query string and what is to be regarded as a stored string. >What >is a stored string from one point of view, may be considered a query >string from another point of view. So any document using SASLPrep >must define which strings are query strings, and which are stored >strings. It does not follow implicitly. The PLAIN ID does detail what is a query string and a stored string. It uses the term "stored" string repeated. And it uses the term "presented string" in a manner which makes it clear that these are query strings. >In lesser words, please modify your proposed sentence into the >following and add it: > > The presented strings are to be regarded as "query" strings > [StringPrep], and the local strings as "stored" strings. What's a "local" string? And why are why defining it to the same as a "stored string". Now, you could say: stored strings are regarded as "stored" strings [StringPrep], but that is stating the obvious (IMO). >> (I'm getting a sense of "deja vu" here, didn't we already >> discuss this issue? If so, is there a particular reason >> why we should repeat that discussion?) > >I don't recall what the conclusion was of any earlier discussion, if >any, and I believe the current document should be improved. > >>> From the server's point >>>of view, it is "querying" whether the password it knows is the same as >>>the one provided by the client. So I see an ambiguity. >>> >>>Thanks. >> >> It seems you are saying: >> From the server's point of view, the server is >> "querying" whether the password the server knows >> is the same as the one provided by the client. >> >> Er, in this case, I think server is "determining" would >> be a more appropriate verb as its not clear who the >> server would be querying to do a comparison between >> the password it knows (e.g., stored string) and the one >> provided by the client (e.g., the presented string). >> >> But as this makes little sense in the context of the above >> discussion, so you must have meant to say something else. >> Please clarify. > >To my reading, your explanation describe what I mean. From owner-ietf-sasl Wed Oct 27 16:23:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNNrEY095342; Wed, 27 Oct 2004 16:23:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RNNr6r095341; Wed, 27 Oct 2004 16:23:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNNqra095311 for ; Wed, 27 Oct 2004 16:23:52 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id i9RNNoKt066762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Oct 2004 17:23:52 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 27 Oct 2004 16:23:50 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: Re: CRAMing for last call Message-ID: <0BBA60D81C80944C3EE1A73A@peregrin.orthanc.ca> In-Reply-To: References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RNNrra095336 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-10-27 5:57 PM -0400 Sam Hartman wrote: > Simon> Finally, RFC 2104 is INFORMATIONAL. Can it be a normative > Simon> reference? > > Yes. Recently a BCP on dealing with this was published. Don't Panic!â„¢ Due to a seemingly-imminent disk failure on my laptop, I pushed out a preliminary version of the draft (as a backup measure more than anything). There will be another rev after the IETF, containing the editorial changes I've previously alluded to. The references will be fixed as part of that update. (And, I hope, the presentation/stored strings issues.) --lyndon From owner-ietf-sasl Wed Oct 27 16:50:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNo8nC001674; Wed, 27 Oct 2004 16:50:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RNo8KO001673; Wed, 27 Oct 2004 16:50:08 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNo2f6001601 for ; Wed, 27 Oct 2004 16:50:03 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMxYH-0007V3-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Thu, 28 Oct 2004 01:49:56 +0200 Lines: 172 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:mXCHkFFaOa24J2DwNYuf2DzDZGA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 03:08 PM 10/27/2004, Simon Josefsson wrote: > >>"Kurt D. Zeilenga" writes: >> >>> At 11:42 AM 10/27/2004, Simon Josefsson wrote: >>> >>>>"Kurt D. Zeilenga" writes: >>>> >>>>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>>>Further, please make it explicit which strings are query strings and >>>>>>which are stored strings, >>>>> >>>>> Personally, I think the current text is sufficiently clear. >>>>> However, adding: >>>>> The presented strings are to be regarded as "query" >>>>> strings [StringPrep]. >>>>> as the 3rd sentence of the quoted paragraph could further >>>>> clarify which strings are to regarded as "query" strings. >>>>> I do not see any ambiguity as to which strings are to >>>>> be considered "stored" strings. >>>> >>>>A password that the server receive from some online external database >>>>(i.e., not "stored" locally) could be considered a query string (from >>>>the database) into the verification process. >>> >>> From a SASL PLAIN perspective, any such database as to be >>> viewed as part of the server implementation. Whether the >>> database is "internal" or "external" is simply an >>> implementation detail. From this perspective, the >>> password stored is a stored string. It's irrelevant >>> whether the server stores in a local or remote database. >> >>I don't think this follow from the specification. > > It follows from SASL PLAIN being a client/server protocol > specification. Everything on side is referred the client. > Everything on the other is referred to as the server. > The architecture of the client and server are irrelevant > to the protocol. It matters not whether the peer is > constructed from many components which interact in some > way or the peer is constructed as a monolith, because > the peers obligations to the other peer is the same > regardless. > >>What I am looking for is text that say that the PLAIN server code >>should treat the local password as a stored string. > > What's a "local password"? I was trying to come up with a descriptive word for it, but I guess I failed. What I meant by "local password" was the input password that the server end up using, after string preparation, in comparing the password provided by the client. The client provided password is the "presented" password, and the other password is "local" in the server. >>Currently, it >>seems to me that you and the PLAIN document only assume that the >>password can only be viewed as a stored string. > > The presented string is compared against a stored string > (or equivalent). Right. What is missing is that the password should be considered as a stored string from the point of view of SASLPrep too, i.e., unassigned code points are not allowed. > What the document doesn't say, and shouldn't > say, is in which component that comparison is made or > in what component of the server stored values are fetched > from or any other implementation detail. Agreed. >>It would be better if >>the document was explicit about it. >> >>The problem is rooted in that StringPrep (SASLPrep) do not define in >>who's view strings should be considered query or stored strings. > > Stringprep relies on incorporating specifications to detail > their view as to what is to be regarded as a query string > and what is to be regarded as a stored string. Agreed. And that detailing is what I believe could be improved in PLAIN. >>What >>is a stored string from one point of view, may be considered a query >>string from another point of view. So any document using SASLPrep >>must define which strings are query strings, and which are stored >>strings. It does not follow implicitly. > > The PLAIN ID does detail what is a query string and > a stored string. It uses the term "stored" string > repeated. And it uses the term "presented string" > in a manner which makes it clear that these are > query strings. It seems we are agreeing on the intention, but not what the document is saying. >>In lesser words, please modify your proposed sentence into the >>following and add it: >> >> The presented strings are to be regarded as "query" strings >> [StringPrep], and the local strings as "stored" strings. > > What's a "local" string? And why are why defining it to > the same as a "stored string". Now, you could say: > stored strings are regarded as "stored" strings [StringPrep], > but that is stating the obvious (IMO). I think the terminology here is poor. I want to differentiate between the "stored string" in the StringPrep/SASLPrep sense, and the "local password" which the server uses as input to the string preparation, and eventually uses to compare with the presented password. Calling the latter "local password" a "stored string" implicitly assume that SASLprep has already been applied to the string. And that unassigned code points are forbidden in the output. But that cannot be assumed, it is something that must be described by the document. To be more concrete: Here is the part of the document with normative text regarding stored strings: Upon receipt of the message, the server will verify the presented authentication identity (authcid) and password (passwd) with the system authentication database, and verify the authentication credentials permit the client to act as the (presented or derived) authorization identity. If both steps succeed, the user is authenticated. The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. An attempt to modify this into something I believe would be more correct would be: Upon receipt of the message, the server will verify the presented authentication identity (authcid) and password (passwd) with the system authentication database, which contain the "local" password for the authentication identity. Next, the server verify that the authentication credentials permit the client to act as the (presented or derived) authorization identity. If both steps succeed, the user is authenticated. The presented authentication identity and password strings are not to be compared directly with local strings. The server SHALL first prepare authentication identity, presented password, and local password using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in local (stored) strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of the expected password string, the string MUST be prepared, as a stored string, before generation of the hash. Thanks, Simon From owner-ietf-sasl Wed Oct 27 18:17:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S1HrvG020706; Wed, 27 Oct 2004 18:17:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9S1HroQ020705; Wed, 27 Oct 2004 18:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S1HhNi020637 for ; Wed, 27 Oct 2004 18:17:43 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9S1GUZv066714; Thu, 28 Oct 2004 01:16:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027172544.03916390@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 18:16:58 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@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 04:49 PM 10/27/2004, Simon Josefsson wrote: >>>What I am looking for is text that say that the PLAIN server code >>>should treat the local password as a stored string. >> What's a "local password"? >I was trying to come up with a descriptive word for it, I think "stored" is pretty descriptive. >What is missing is that the password should be considered as a >stored string from the point of view of SASLPrep too, i.e., unassigned >code points are not allowed. I guess we'll have to agree to disagree here. I do not believe this is missing from the I-D. I find the paragraph you quoted is quite clear as to which strings are to be considered "query" strings and which are to be considered "stored" strings during string preparation. The I-D also provides pseudo-code and further discussion which reenforces which strings are to be considered "query" strings and which are to be considered "stored" strings during preparation. >>> The presented strings are to be regarded as "query" strings >>> [StringPrep], and the local strings as "stored" strings. >> >> What's a "local" string? And why are why defining it to >> the same as a "stored string". Now, you could say: >> stored strings are regarded as "stored" strings [StringPrep], >> but that is stating the obvious (IMO). >I think the terminology here is poor. "local string" is a poor term. >I want to differentiate between the "stored string" in the >StringPrep/SASLPrep sense, and the "local password" which the server >uses as input to the string preparation, and eventually uses to >compare with the presented password. Such a differentiation will, I think, lead to confusion. I think the text you offer is not better than the current text. I think it it is much worse than the current text. I think the current text is sufficiently clear. >Calling the latter "local password" a "stored string" implicitly >assume that SASLprep has already been applied to the string. And that >unassigned code points are forbidden in the output. But that cannot >be assumed, it is something that must be described by the document. > >To be more concrete: Here is the part of the document with normative >text regarding stored strings: > > Upon receipt of the message, the server will verify the presented > authentication identity (authcid) and password (passwd) with the > system authentication database, and verify the authentication > credentials permit the client to act as the (presented or derived) > authorization identity. If both steps succeed, the user is > authenticated. > > The presented authentication identity and password strings are not to > be compared directly with stored strings. The server SHALL first > prepare authentication identity and password strings using the > [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of > [StringPrep], unassigned code points may appear in prepared presented > (query) strings but are prohibited in stored strings. If preparation > fails or results in an empty string, verification SHALL fail. If the > server stores only the hash of expected string, the string MUST be > prepared before generation of the hash. > >An attempt to modify this into something I believe would be more >correct would be: > > Upon receipt of the message, the server will verify the presented > authentication identity (authcid) and password (passwd) with the > system authentication database, which contain the "local" password > for the authentication identity. What's a local password? Isn't the password shared with the user? Can't the password be stored remotely? And are you only applying the term "local" to the password? Wouldn't there also be a "local" authentication identity string as well. But that said, I also dislike explicitly describing the contents of the system authentication database. > Next, the server verify that the > authentication credentials permit the client to act as the > (presented or derived) authorization identity. If both steps > succeed, the user is authenticated. > > The presented authentication identity and password strings are not > to be compared directly with local strings. The server SHALL first > prepare authentication identity, presented password, and local > password using the [SASLPrep] profile of the [StringPrep] algorithm. > Per Section 7 of [StringPrep], unassigned code points may appear in > prepared presented (query) strings but are prohibited in local > (stored) strings. Is the stored authentication identity string a local string or a query string? Kurt From owner-ietf-sasl Thu Oct 28 08:12:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCicJ063456; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFCirx063455; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFChwa063449 for ; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23743; Thu, 28 Oct 2004 11:12:52 -0400 (EDT) Message-Id: <200410281512.LAA23743@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-04.txt Date: Thu, 28 Oct 2004 11:12:52 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-04.txt Pages : 10 Date : 2004-10-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110352.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Oct 28 08:12:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCZX0063437; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFCZgN063436; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCYCo063426 for ; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23727; Thu, 28 Oct 2004 11:12:43 -0400 (EDT) Message-Id: <200410281512.LAA23727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-09.txt Date: Thu, 28 Oct 2004 11:12:43 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-09.txt Pages : 11 Date : 2004-10-27 The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Oct 28 17:10:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T0AFvI088166; Thu, 28 Oct 2004 17:10:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9T0AFmr088165; Thu, 28 Oct 2004 17:10:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9T0AEnJ088159 for ; Thu, 28 Oct 2004 17:10:14 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30031; 28 Oct 2004 20:10 EDT Date: Thu, 28 Oct 2004 20:10:04 -0400 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Message-ID: <1120700000.1099008604@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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, October 27, 2004 11:09:47 -0700 "Kurt D. Zeilenga" wrote: >> and mention the value of the AllowUnassigned >> flag for each string using MUST. > > I cannot find the term "AllowUnassigned flag" anywhere in > the specification (including normative references). This term was apparently used in some drafts of nameprep, and is referred to in RFC3490 and draft-hoffman-rfc3490bis-02.txt. Unfortunately, those references claim that the term is defined in RFC3491 and draft-hoffman-rfc3491bis-01.txt, respectively, and neither document defines the term. Neither do stringprep or saslprep. This flag was used as a parameter to the preparation algorithm in IDN, to indicate whether unassigned code points are permitted; it is what distinguishes between storage and query strings. The profile defined by SASLprep does make such a distinction, but does not use a formally defined "flag". We should mention in each case whether unassigned code points are permitted (query strings) or not (storage strings). But we should not use a reference to an "AllowUnassigned flag" which our stringprep profile does not have. > The text does, however, not only says that strings SHALL > be prepared in accordance with StringPrep, it describes > what that means in regards to unassigned code points > and the two classes of strings. Then this should be sufficient. -- Jeff From owner-ietf-sasl Fri Oct 29 05:45:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCj72C031352; Fri, 29 Oct 2004 05:45:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TCj7Bj031351; Fri, 29 Oct 2004 05:45:07 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCiw7N031288 for ; Fri, 29 Oct 2004 05:44:59 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CNW7h-0007w9-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Fri, 29 Oct 2004 14:44:48 +0200 Lines: 146 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> <6.1.2.0.0.20041027172544.03916390@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:hwqVxsfayWnFp2Xwp9QIIWXqJbc= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:49 PM 10/27/2004, Simon Josefsson wrote: >>>>What I am looking for is text that say that the PLAIN server code >>>>should treat the local password as a stored string. >>> What's a "local password"? >>I was trying to come up with a descriptive word for it, > > I think "stored" is pretty descriptive. For what is intended here, I disagree. "Stored string" is a StringPrep/SASLPrep term that denote strings that have or will be prepared in a way that disallow unassigned code points in the output. Talking about the strings that PLAIN servers should apply SASLPrep to as "stored strings" does not give any clues which these strings are. That is why I believe PLAIN must say which strings should be considered as "stored strings", in the SASLprep point of view. I don't think this is clear now. >>What is missing is that the password should be considered as a >>stored string from the point of view of SASLPrep too, i.e., unassigned >>code points are not allowed. > > I guess we'll have to agree to disagree here. > > I do not believe this is missing from the I-D. I find the > paragraph you quoted is quite clear as to which strings are > to be considered "query" strings and which are to be considered > "stored" strings during string preparation. The I-D also > provides pseudo-code and further discussion which reenforces > which strings are to be considered "query" strings and which > are to be considered "stored" strings during preparation. The pseudo-code hide all SASLPrep preparation of the "local password" inside FetchPasswordHash, so it is clarified at all, in my opinion. I agree the draft make it clear which strings are "query strings", but I don't think it is clear which strings are "stored strings". >>Calling the latter "local password" a "stored string" implicitly >>assume that SASLprep has already been applied to the string. And that >>unassigned code points are forbidden in the output. But that cannot >>be assumed, it is something that must be described by the document. >> >>To be more concrete: Here is the part of the document with normative >>text regarding stored strings: >> >> Upon receipt of the message, the server will verify the presented >> authentication identity (authcid) and password (passwd) with the >> system authentication database, and verify the authentication >> credentials permit the client to act as the (presented or derived) >> authorization identity. If both steps succeed, the user is >> authenticated. >> >> The presented authentication identity and password strings are not to >> be compared directly with stored strings. The server SHALL first >> prepare authentication identity and password strings using the >> [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of >> [StringPrep], unassigned code points may appear in prepared presented >> (query) strings but are prohibited in stored strings. If preparation >> fails or results in an empty string, verification SHALL fail. If the >> server stores only the hash of expected string, the string MUST be >> prepared before generation of the hash. >> >>An attempt to modify this into something I believe would be more >>correct would be: >> >> Upon receipt of the message, the server will verify the presented >> authentication identity (authcid) and password (passwd) with the >> system authentication database, which contain the "local" password >> for the authentication identity. > > What's a local password? I believe I explained this in my last post. The local password is the password the server has stored for the user, whether in the form of a unprepared UTF-8 string, a SASLPrep prepared string, or a hash of a SASLPrep prepared string. > Isn't the password shared with the user? Right. But the server must have a copy (in some form), to compare with what the user presents. > Can't the password be stored remotely? Of course. But at some point, the server must have access to it, that's why I argue it can be considered "local". If you have a better term, that would be great. > And are you only applying the term "local" to the password? > Wouldn't there also be a "local" authentication identity string as > well. That depend on the implementation. I think most servers implement some form of database that map to . It isn't efficient to prepare every in the database using SASLPrep, to get a "local ", and then compare them with the presented . So instead they look up the client presented string in the database, and hope to find something. > But that said, I also dislike explicitly describing the > contents of the system authentication database. If the term is to mean anything at all, there must be some meaning to what a "system authentication database" is. Describing that it contain and , where the may be in raw, prepared, hashed or other forms that can be used in verifying the client presented data doesn't preclude some design, does it? Currently, the term is used with no definition. >> Next, the server verify that the >> authentication credentials permit the client to act as the >> (presented or derived) authorization identity. If both steps >> succeed, the user is authenticated. >> >> The presented authentication identity and password strings are not >> to be compared directly with local strings. The server SHALL first >> prepare authentication identity, presented password, and local >> password using the [SASLPrep] profile of the [StringPrep] algorithm. >> Per Section 7 of [StringPrep], unassigned code points may appear in >> prepared presented (query) strings but are prohibited in local >> (stored) strings. > > Is the stored authentication identity string a local string or > a query string? It depends on the implementation. I think some implementations take the presented , look it up in a database, and hopefully get a password (in whatever form) back. This assume that the database has been populated with prepared strings with no unassigned code points. Alternatively, if the database store unprepared strings, the implementation may prepare the presented using SASLPrep with no unassigned code points in the output, and then look up that string in the database. Thanks. From owner-ietf-sasl Fri Oct 29 06:05:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TD5Jlf034322; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TD5JdR034321; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TD5IWF034311 for ; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CNWRU-0000yN-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Fri, 29 Oct 2004 15:05:15 +0200 Lines: 29 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <1120700000.1099008604@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:0R0Zq7mtdr69ZaVrKlFMArTGP6I= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > We should mention in each case whether unassigned code points are permitted > (query strings) or not (storage strings). But we should not use a > reference to an "AllowUnassigned flag" which our stringprep profile does > not have. I agree completely. I further believe it is critical that it is clear how to prepare every involved string. Merely referring to SASLPrep is not sufficient. Documents must enforce _how_ SASLPrep is used on each individual input string. I.e., documents have to say whether or not unassigned code points should be permitted in the output or not. >> The text does, however, not only says that strings SHALL be >> prepared in accordance with StringPrep, it describes what that >> means in regards to unassigned code points and the two classes of >> strings. > > Then this should be sufficient. It would, although I appear to disagree with Kurt that the text is not ambiguous about this. I believe my opinion on this should now be clear, and that it is not useful to carry on this discussion. If everyone else who understand the issue believe the documents are clear, then there shouldn't ever be problems with the use of SASLprep in PLAIN, and all will be fine. Thanks. From owner-ietf-sasl Fri Oct 29 08:08:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF80E7009101; Fri, 29 Oct 2004 08:08:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TF808s009098; Fri, 29 Oct 2004 08:08:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF7rKg008858 for ; Fri, 29 Oct 2004 08:07:53 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9TF6eZv079250; Fri, 29 Oct 2004 15:06:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041029075631.03005750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 29 Oct 2004 08:06:44 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> <6.1.2.0.0.20041027172544.03916390@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:44 AM 10/29/2004, Simon Josefsson wrote: >>> Upon receipt of the message, the server will verify the presented >>> authentication identity (authcid) and password (passwd) with the >>> system authentication database, which contain the "local" password >>> for the authentication identity. >> >> What's a local password? >I believe I explained this in my last post. But you didn't explain it in the text that you offered for consideration. My questions in regards to the offered text are written from the point of view of someone who doesn't have any knowledge of your prior comments. That is, my questions are from the point of view of an independent developer reading the offered text as if it was included in PLAIN's TS. It makes no sense to me to say the password in local to the server when that password is clearly shared with the client which presented it. It's not at all obvious that local password are refers to the stored copy of the shared password at the server. Kur From owner-ietf-sasl Fri Oct 29 10:57:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THvERF013718; Fri, 29 Oct 2004 10:57:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9THvEwU013717; Fri, 29 Oct 2004 10:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (mca1f36d0.tmodns.net [208.54.31.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THv2FF013503 for ; Fri, 29 Oct 2004 10:57:05 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0E992E0006; Fri, 29 Oct 2004 13:55:13 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <1120700000.1099008604@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Fri, 29 Oct 2004 13:54:32 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 29 Oct 2004 15:05:15 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> It would, although I appear to disagree with Kurt that the Simon> text is not ambiguous about this. Simon> I believe my opinion on this should now be clear, and that Simon> it is not useful to carry on this discussion. If everyone Simon> else who understand the issue believe the documents are Simon> clear, then there shouldn't ever be problems with the use Simon> of SASLprep in PLAIN, and all will be fine. Speaking as chair, I do not believe there is a working group consensus to reopen this issue. --Sam From owner-ietf-sasl Sun Oct 31 18:43:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA12hDiU058555; Sun, 31 Oct 2004 18:43:13 -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 iA12hDOJ058554; Sun, 31 Oct 2004 18:43:13 -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.9) with ESMTP id iA12hCsL058511 for ; Sun, 31 Oct 2004 18:43:12 -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.11) with ESMTP id iA12hCZv096337 for ; Mon, 1 Nov 2004 02:43:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041031184301.02d62430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 31 Oct 2004 18:43:33 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASL Agenda for IETF#61 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 (SASL) Tuesday, 9 November 2004 1545-1645 =================================== Chairs: Sam Hartman Kurt Zeilenga Agenda: Introductions and Agenda Bashing - Chairs (5 minutes) Review of SASL Base last call - Chairs/Alexey (15 minutes) Digest MD5 (draft--ietf-sasl-rfc2831bis) - Alexey (10 minutes) GSSAPI (draft-ietf-sasl-gssapi) - Alexey (10 minutes) CRAM-MD5 (draft-ietf-sasl-crammd5) - TBD (10 minutes) Open mic - (remaining time) From owner-ietf-sasl Fri Oct 1 06:59:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91DxtP9030106; Fri, 1 Oct 2004 06:59:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Dxtdt030105; Fri, 1 Oct 2004 06:59:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Dxr87030096 for ; Fri, 1 Oct 2004 06:59:54 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CDNwr-0003xT-9d for ietf-sasl@imc.org; Fri, 01 Oct 2004 15:59:49 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CDNwn-0005qc-Dt; Fri, 01 Oct 2004 15:59:45 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CDNwm-0003D0-00; Fri, 1 Oct 2004 15:59:44 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis-08 comments Date: Fri, 1 Oct 2004 15:59:44 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These are rather rather hurried comments, since Kurt said reviews are needed but soon. So I have only made a cursory check if these issues have been discussed before; I don't know how much they would have been delayed if I were to check properly. Sorry about that. > Abstract I had trouble getting into SASL the first time I read the draft - mostly things that did not make sense to me at first, only when I got to a closer explanation later in the draft. I'm beginning to figure out why now, though I'm guessing a bit about what it was I didn't get. Starting with the Abstract: I didn't get that at all, though I don't really see why, given the second paragraph. "So I have a protocol here, and an authentication mechanism there, and somehow if I include SASL, the two will be able to talk to each other. Um...?" It's better now, but I still suggest: > The Simple Authentication and Security Layer (SASL) is a framework > for providing authentication and data security services in > connection-oriented protocols via replaceable authentication [nothing in the abstract says that's the kind of mechanisms it is talking about.] > mechanisms. It > provides structured interface between protocols and such SASL > mechanisms. Or maybe "...and mechanisms that adhere to SASL", but that's probably more wordy than necessary. The same change would be nice in the Introduction section, though of course the diagram there helps. Personally I would also have found an asymmetric definition easier to relate to: SASL defines a common interface to authentication mechanisms for protocols. (Is that the right way to put it?) But maybe that's not at all the view SASL intends to convey. Is the protocol profile the common interface to protocols for authentication mechanisms? > 2. Introduction > The implementors will also need to understand a > specification of a SASL > profile specific to the protocol, > 3.1. Authentication protocol exchange This phrase looks to me like it is about an authentication protocol - i.e. part of SASL - and not the protocol which uses SASL. I don't see anything in the following section to correct that notion. Also, > A SASL mechanism is responsible for conducting an authentication > protocol exchange. I don't think so. It's the protocol which conducts the _exchange_, and (below) which transmits anything. > During the authentication protocol exchange, the mechanism performs I suggest s/performs/can perform/, since not all of them need be done. > authentication, transmits an authorization identity (frequently known > as a userid) from the client to server, This sounds like the authorization identity is independent of the authentication. See below. > 3.2. Authorization and authentication identities > 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. As above. As described, the authorization ID appears not to be part of the 'results produced by the authentication mechanism', only something which is grabbed after completion of the authentication. When I first read about this, I was left wondering when the server checks if the authentication ID has the authorization ID's access. Each time one tries to access something after the authentication? Please clarify that the authorization ID is checked during the authentication (as section 3.2.1 says). And local policy is used to either derive the authorization identity or check it. But it looks a little strange to use that local policy during the exchange if the user provides it, but after the exchange if it is derived. Should both be done during the exchange instead? > 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. I wonder a little why the authorization ID is explicitly said to be provided by the client, when the authentication ID is not. > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. That's a bit misleading from the protocol's point of view. From discussions elsewhere I gather the protocol may normalize the ID as it pleases for its own use, including when it locates the server-side secret matching the authentication ID, as long as this does not affect the ID which the authentication mechanism sees. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). The () part does not seem say the same as the preceding sentence: 'when transferring...' sounds like only the client-side part of the mechanism must preserve the ID, while the () sounds like the server side also must preserve it. > 3.2.1. Authorization identities and proxy authentication > The server SHOULD verify that a received authorization identity is in > the correct form. Protocol 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. In that case there can be authorization IDs which one can only get by sending an empty authorization ID: IDs that are derived from the authentication ID but would be invalid if specified explicitly. Seems strange. > 3.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. But a NUL octet in a multibyte character is OK? (Does not apply to UTF-8, of course.) > 3.3. Security layers > 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. The exact position MUST be defined by > the protocol profile (see section 4 part 5). When does it stop having effect, if the protocol supports multiple authentication? > Note that all SASL mechanisms that are unable to negotiate a security > layer automatically select no security layer. Without checking up the 'selects no security layer' thread, I still can't tell if this says that such a mechanism cancels an old security layer or if it says that it doesn't affect it. I'll check that later, unless someone replies first. -- Hallvard From owner-ietf-sasl Fri Oct 1 07:39:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91EdLFb032699; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91EdL0I032698; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91EdLQr032689 for ; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91EdLZv065770 for ; Fri, 1 Oct 2004 14:39:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001072559.04412a90@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 07:39:20 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis-08 comments In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >These are rather rather hurried comments, since Kurt said reviews are >needed but soon. Thanks for responding to my late request for review! To the WG, Sam and I have some concerns regarding the depth and breadth of the WG review of this I-D. The chairs continue to actively seek additional review. Kurt From owner-ietf-sasl Fri Oct 1 11:09:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I9RiC047225; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91I9RpB047224; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I9ROw047216 for ; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91I9SZv067220 for ; Fri, 1 Oct 2004 18:09:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001085527.044c67c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 09:14:18 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Reconsideration Identity And Authorization Issue (Was: Summary of 2222bis WGLC) In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> References: <6.1.2.0.0.20040924123829.0433b4c8@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:40 PM 9/24/2004, Kurt D. Zeilenga wrote: >5) Identities and Authorization > >Kurt indicated that the I-D use of term "authorization >identity" is confusing and suggested use of different >terms for each distinct use of this term. Jeffery >suggested using the terms: > "authentication identity" to refer to the > identity associated with the users creditials, > "requested identity" to refer to identity > which the user requests to act as, and > "authorization identity" to refer to identity > used by the server in making authorization > decisions. (The latter being derived from > by former two.) > >The chairs conclude the WG supports use of this >suggested terminology. After some lengthy discussions between the Sam, Alexey, and I (with and without our respective chair/editor hats), the chairs have decided to vacate their conclusion regarding this issue and re-open discussion in this area. This post will be followed by a messaging summarizing problems with above terminology choice and offering a way to resolve the underlying terminology problem. Kurt, as SASL co-chair From owner-ietf-sasl Fri Oct 1 11:21:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91ILDdj048000; Fri, 1 Oct 2004 11:21:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91ILDmV047999; Fri, 1 Oct 2004 11:21:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91ILCCJ047988 for ; Fri, 1 Oct 2004 11:21:12 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91ILFZv067280 for ; Fri, 1 Oct 2004 18:21:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 11:21:13 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Identity terminology in 2222bis 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: Historically, there was a bit of hand waving in regards to identities. In trying to nail down what identities are involved in the SASL framework, where each identity comes from and what are they used for, we ended up with 3 identities: - the "authentication identity" to refer to the identity associated with the users credentials, - the "requested identity" to refer to identity which the user requests to act as, and - "authorization identity" to refer to identity used by the server in making authorization decisions. (The latter being derived from by former two.) However, we now face is that what we've historically called an authorization identity is not the precise identity used in making authorization decisions. The amount of 2222bis editing to implement the WGLC conclusion is actually minor in comparison to the impact upon other documents, including most mechanism specifications and application profiles. If it was only 2222bis, I'd be inclined to just bit the bullet and make the terminology changes. But given the broader impact this terminology change would have, we need to consider other approaches to resolving our terminology woes. In particular, I think this can be done by separating how identities are used conceptually from how they are used in practice and, in particular, their form. Below is a 3.2 rewrite which, I think, demonstrates how we can avoid the terminology problem. I do think other portions need work as well, but this should give you reasonable idea of the approach I suggest we take. Comments? -- Kurt (as an individual contributor) 3.2 Identity Concepts Conceptually, SASL framework involves two identities: 1) an identity associated with the authentication credentials (termed the authentication identity), and 2) an identity to act as (termed the authorization identity). The client provides its credentials and, optionally, a string representing the requested authorization identity as part of the SASL exchange. When this string is not provided, the client is requesting to act as the identity associated with the credentials (e.g., the user is requesting to act as the authentication identity). The server is responsible for verifying the user's credentials and verifying that the user is able to act as the authorization identity. A SASL exchange is successful if and only if both of these verifications are successful. While SASL mechanisms specify the form of credentials used to authenticating users and SASL application profiles specify the form of authorization identities transferred as part of authentication exchange, the precise form(s) of the authentication identities (used within the server in its verifications, or otherwise) and the precise form(s) of the authorization identities (used in making authorization decisions, or otherwise) is beyond the scope of the SASL and this specification. In some circumstances, the precise identity forms used outside of the SASL exchange may be dictated by other specifications. For instance, the authorization policy specification for an application protocol may dictate the precise form that an authorization identity is to be represented in the authorization policy. From owner-ietf-sasl Fri Oct 1 11:23:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91INkBq048111; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91INk6n048110; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91INkHI048104 for ; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91INnZv067292; Fri, 1 Oct 2004 18:23:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 11:23:07 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis-08 comments Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a few (initial) comments to inject here and there. At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >> Abstract > >> The Simple Authentication and Security Layer (SASL) is a framework >> for providing authentication and data security services in >> connection-oriented protocols via replaceable > >authentication The sentence might be more clear if worded: The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services via replaceable mechanisms to connection-oriented protocols. >[nothing in the abstract says that's the kind of mechanisms it is >talking about.] Mechanisms provide authentication and data security services to connection-oriented protocols through the SASL framework. >> mechanisms. It >> provides structured interface between protocols and > >such SASL > >> mechanisms. I think its clear that both "protocols" and "mechanisms" refer to those protocols and mechanisms which are utilizing the SASL framework. I don't think either needs to be qualified here. It would seem odd to qualify one and not the other. And as this is the Abstract, we should avoid being too wordy. >Or maybe "...and mechanisms that adhere to SASL", but that's probably >more wordy than necessary. First, you'd have to say s/SASL/SASL technical specification/. But, yes, too wordy. >The same change would be nice in the Introduction section, though of >course the diagram there helps. > >Personally I would also have found an asymmetric definition easier to >relate to: SASL defines a common interface to authentication mechanisms >for protocols. (Is that the right way to put it?) But maybe that's not >at all the view SASL intends to convey. Is the protocol profile the >common interface to protocols for authentication mechanisms? The "protocol profile" is the part of the protocol's technical specification which details how it makes use of the SASL framework. >> 2. Introduction > >> The implementors will also need to understand a >> specification of a > >SASL > >> profile specific to the protocol, > >> 3.1. Authentication protocol exchange > >This phrase looks to me like it is about an authentication protocol - >i.e. part of SASL - and not the protocol which uses SASL. >I don't see anything in the following section to correct that notion. I think the word "protocol' here should be dropped here and elsewhere where we're referring to the mechanism exchange. >Also, > >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. > >I don't think so. It's the protocol which conducts the _exchange_, >and (below) which transmits anything. > >> During the authentication protocol exchange, the mechanism performs > >I suggest s/performs/can perform/, since not all of them need be done. > >> authentication, transmits an authorization identity (frequently known >> as a userid) from the client to server, > >This sounds like the authorization identity is independent of the >authentication. See below. > >> 3.2. Authorization and authentication identities There was some discussion in this area during WGLC. That discussion was recently re-opened. I suggest you read my latest post in this area as well as the WGLC thread. >> 3.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. > >But a NUL octet in a multibyte character is OK? This sentence refers only to specific character, not octets belonging to an encoding of other characters. From owner-ietf-sasl Fri Oct 1 14:06:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91L63tA057281; Fri, 1 Oct 2004 14:06:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91L63cL057280; Fri, 1 Oct 2004 14:06:03 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91L61JI057271 for ; Fri, 1 Oct 2004 14:06:01 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDUbF-000316-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Fri, 01 Oct 2004 23:05:31 +0200 Lines: 46 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:pqbbMshAe7vTm5P+HVrgAxdOyMk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > While SASL mechanisms specify the form of credentials > used to authenticating users and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange, the > precise form(s) of the authentication identities (used > within the server in its verifications, or otherwise) > and the precise form(s) of the authorization identities > (used in making authorization decisions, or otherwise) is > beyond the scope of the SASL and this specification. I'm worried by how this new text interact with string normalization like SASLPrep. To me, it sounds as if the above leave the precise form of authentication/authorization identities up to either, or both, of application profiles and mechanisms. Is that a correct interpretation? If so, the new text would appear to permit, e.g., mechanisms to perform SASLPrep on the authorization identity. And to permit application profiles to apply perform SASLPrep on the authentication identity. Here, SASLPrep could even be some other function, like Unicode NFKC, or SASLPrep2, or some proprietary normalization procedure. For comparison, here is part of the old text: Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Read in contrast to each other, this seem like a major design change. Instead, I propose to clarify the terminology. Further, the requirements on application profile and mechanisms should be specified, and not left "beyond the scope of 2222bis". One concrete approach is to require that, for IETF application profiles and mechanisms, both authentication and authorization identities MUST be SASLPrep strings, and that the SASL library, the application profile, and the mechanism may all perform SASLPrep on the identities. Thanks, Simon From owner-ietf-sasl Fri Oct 1 15:38:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McWYt061399; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91McWIo061398; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McT4j061390 for ; Fri, 1 Oct 2004 15:38:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 434F9E004F; Fri, 1 Oct 2004 18:38:33 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> From: Sam Hartman Date: Fri, 01 Oct 2004 18:38:33 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 01 Oct 2004 23:05:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >> While SASL mechanisms specify the form of credentials used to >> authenticating users and SASL application profiles specify the >> form of authorization identities transferred as part of >> authentication exchange, the precise form(s) of the >> authentication identities (used within the server in its >> verifications, or otherwise) and the precise form(s) of the >> authorization identities (used in making authorization >> decisions, or otherwise) is beyond the scope of the SASL and >> this specification. Simon> I'm worried by how this new text interact with string Simon> normalization like SASLPrep. To me, it sounds as if the Simon> above leave the precise form of Simon> authentication/authorization identities up to either, or Simon> both, of application profiles and mechanisms. Is that a Simon> correct interpretation? The consensus of this working group is that the mechanism must transport the requested authorization identity so that all unicode code points are preserved. I.E. the mechanism can use any bijective transformation it desires; transforms like utf8-encode are assumed to be bijective on the set of unicode code points. Trying to be a bit more clear, mechanisms choose the encoding, but must preserve the unicode code points given to them by the protocol. The authentication identity is completely a matter for the mechanism; it may (and often should) normalize it. The normalization and interpretation of the requested authorization identity is a protocol matter. --Sam From owner-ietf-sasl Fri Oct 1 15:58:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91MwtoH062300; Fri, 1 Oct 2004 15:58:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91MwtBo062299; Fri, 1 Oct 2004 15:58:55 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Mws7d062293 for ; Fri, 1 Oct 2004 15:58:54 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDWMd-000605-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Sat, 02 Oct 2004 00:58:33 +0200 Lines: 27 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:TTdNN5xkyEqxgQU8B6PSnsAdaIk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > The consensus of this working group is that the mechanism must > transport the requested authorization identity so that all unicode > code points are preserved. Then I propose to keep the following in section 3.2: The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Otherwise, I cannot find any normative text reflecting the consensus. > The authentication identity is completely a matter for the mechanism; > it may (and often should) normalize it. Then I propose to keep the following in section 3.2: Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Kurt D. Zeilenga proposed to remove both paragraphs, if I understood him correctly. Thanks, Simon From owner-ietf-sasl Fri Oct 1 16:12:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NCDIK063905; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91NCD8q063904; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NCDNS063896 for ; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91NC7Zv068806; Fri, 1 Oct 2004 23:12:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 16:12:05 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@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: Simon, Note that the text I offer is not a direct replacement for Section 3.2. Additional work, including moving key imperatives from the existing 3.2 to other sections, would have to be undertaken. At 02:05 PM 10/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> While SASL mechanisms specify the form of credentials >> used to authenticating users and SASL application >> profiles specify the form of authorization identities >> transferred as part of authentication exchange, the >> precise form(s) of the authentication identities (used >> within the server in its verifications, or otherwise) >> and the precise form(s) of the authorization identities >> (used in making authorization decisions, or otherwise) is >> beyond the scope of the SASL and this specification. This may need some slight rewording. The intent is for the mechanism specification to detail how to verify the credentials and for the application protocol profile to specify the precise form of the authorization identity (within the Unicode restrict) but to make it clear that there are many uses of these identities which SASL simply doesn't not control. >I'm worried by how this new text interact with string normalization >like SASLPrep. I presume the existing recommendations here will remain. >To me, it sounds as if the above leave the precise >form of authentication/authorization identities up to either, or both, >of application profiles and mechanisms. The precise form of the credentials is a mechanism detail. The mechanism generally details how the credentials are to be verified. The precise form of the authorization identity is, excepting the Unicode restriction, is a application protocol detail. Other uses of identities are outside the scope of SASL. >For comparison, here is part of the old text: > > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. Though I think this needs to be slightly reworded, I agree with the intent of the statement to say that protocol profiles should leave of aspects of credentials and their verification to the mechanism. However, this in no way implies that an application protocol specification, or its implementations, cannot detail the form of authentication identity the application protocol (or implementation) might use otherwise. For instance, an application protocol specification could detail how to represent authentication identities in an identity assumption authorization policy. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). > >Read in contrast to each other, this seem like a major design change. > >Instead, I propose to clarify the terminology. I think you propose a major design change. From owner-ietf-sasl Fri Oct 1 16:25:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NPsu0065555; Fri, 1 Oct 2004 16:25:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91NPsAb065554; Fri, 1 Oct 2004 16:25:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NPrBa065548 for ; Fri, 1 Oct 2004 16:25:53 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDWmk-0006iS-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Sat, 02 Oct 2004 01:25:32 +0200 Lines: 13 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/v3LJ3jCN8CLzghBvWRYkQ2Kb+0= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > Simon, > > Note that the text I offer is not a direct replacement for > Section 3.2. Additional work, including moving key > imperatives from the existing 3.2 to other sections, would > have to be undertaken. OK, I must have misread your initial post then. Thanks, Simon From owner-ietf-sasl Fri Oct 1 18:49:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i921nTvA072491; Fri, 1 Oct 2004 18:49:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i921nTmx072490; Fri, 1 Oct 2004 18:49:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from Gate2-sandiego.nmci.navy.mil (gate2-sandiego.nmci.navy.mil [138.163.0.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i921nPkH072479 for ; Fri, 1 Oct 2004 18:49:25 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: from nawesdnims04.nmci.navy.mil by Gate2-sandiego.nmci.navy.mil via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Sat, 2 Oct 2004 01:49:32 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: from mail pickup service by NAWESDNIEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC; Fri, 1 Oct 2004 18:47:51 -0700 Received: from nawesdnifw06.nmci.navy.mil ([10.0.0.38]) by NAWESDNIEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Oct 2004 15:53:09 -0700 Received: from Nawesdnims01.nmci.navy.mil by nawesdnifw06.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.0.10.60]) with ESMTP; Fri, 1 Oct 2004 22:53:09 +0000 Received: from nawesdnifw03c.nmci.navy.mil (nawesdnifw03c.nmci.navy.mil [10.0.0.163]) by nawesdnims01.nadsuswe.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id i91MmgJ09107 for ; Fri, 1 Oct 2004 22:48:42 GMT Received: from above.proper.com ([208.184.76.39]) by nawesdnifw03c.nmci.navy.mil via smtpd (for [10.0.0.166]) with ESMTP; Fri, 1 Oct 2004 22:53:08 +0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McWYt061399; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91McWIo061398; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McT4j061390 for ; Fri, 1 Oct 2004 15:38:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 434F9E004F; Fri, 1 Oct 2004 18:38:33 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> From: Sam Hartman Date: Fri, 01 Oct 2004 18:38:33 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 01 Oct 2004 23:05:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Archive: List-ID: List-Unsubscribe: X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-OriginalArrivalTime: 01 Oct 2004 22:53:09.0356 (UTC) FILETIME=[6C038AC0:01C4A809] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> "Kurt D. Zeilenga" writes: >> While SASL mechanisms specify the form of credentials used to >> authenticating users and SASL application profiles specify the >> form of authorization identities transferred as part of >> authentication exchange, the precise form(s) of the >> authentication identities (used within the server in its >> verifications, or otherwise) and the precise form(s) of the >> authorization identities (used in making authorization >> decisions, or otherwise) is beyond the scope of the SASL and >> this specification. Simon> I'm worried by how this new text interact with string Simon> normalization like SASLPrep. To me, it sounds as if the Simon> above leave the precise form of Simon> authentication/authorization identities up to either, or Simon> both, of application profiles and mechanisms. Is that a Simon> correct interpretation? The consensus of this working group is that the mechanism must transport the requested authorization identity so that all unicode code points are preserved. I.E. the mechanism can use any bijective transformation it desires; transforms like utf8-encode are assumed to be bijective on the set of unicode code points. Trying to be a bit more clear, mechanisms choose the encoding, but must preserve the unicode code points given to them by the protocol. The authentication identity is completely a matter for the mechanism; it may (and often should) normalize it. The normalization and interpretation of the requested authorization identity is a protocol matter. --Sam From owner-ietf-sasl Fri Oct 1 22:02:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252w7G083996; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9252wSA083994; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252vOB083966; Fri, 1 Oct 2004 22:02:57 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d216-232-212-223.bchsia.telus.net (d216-232-212-223.bchsia.telus.net [216.232.212.223]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9252sWc034166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 23:02:56 -0600 (MDT) Date: Fri, 01 Oct 2004 22:02:54 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org Subject: CRAMing for last call Message-ID: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Now that 2222bis is close to reality, I would like to push the final version of CRAM out as well. The two documents should be able to go through together, (I hope) making life easier for the RFC editor. I have some non-substantive editorial changes that will make the document a bit easier to read, but these are not show stoppers. I think all of the last round of comments are addressed in the current draft. If not, I would like to hear from people, soon. I would also like to solicit a few additional examples from anyone who has implemented CRAM in other than IMAP. Finally, we need to address the issue of the MD5 "break." I have held off from commenting on this issue until the community has seen explicit evidence of the attack, and the implications of it. At this point, I don't know if the document deserves a writeup on the attack. Theory abounds, but I haven't yet seen a practical attack that works in the general case. We should at the least make mention of what has been discussed, and point to the literature, but I don't think the document deserves to discuss all the possible attacks. This doesn't mean to discourage anyone from contributing text to the Security Considerations section (please do). The IMAP-EXT list has had recent discussion that points out the ambiguity of searching for the space (SP) separator (between the user id and the digest) as being the rightmost SP, so I will strengthen that text. Any other comments should come forth soon as I would like to run out the final draft at the end of next week (Oct. 8) if I can. Cheers, --lyndon (editor) From owner-ietf-sasl Sat Oct 2 11:52:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iquk2048414; Sat, 2 Oct 2004 11:52:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92IquqC048413; Sat, 2 Oct 2004 11:52:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iqqgx048406 for ; Sat, 2 Oct 2004 11:52:53 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id CFC98160099; Sat, 2 Oct 2004 14:52:59 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> From: Sam Hartman Date: Sat, 02 Oct 2004 14:52:58 -0400 In-Reply-To: <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 01 Oct 2004 16:12:05 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> be verified. The precise form of the authorization identity Kurt> is, excepting the Unicode restriction, is a application Kurt> protocol detail. This isn't quite right. The form of the requested authorization identity--the bits that are transferred over the wire--is a mechanism detail. The protocol profile feeds in unicode codepoints and the mechanism decides how those codepoints will appear on the wire. The semantics of these codepoints is what is a protocol detail. --Sam From owner-ietf-sasl Sat Oct 2 11:58:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92IwtOq048630; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92IwtD4048627; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iwssm048615; Sat, 2 Oct 2004 11:58:54 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C22AAE004F; Sat, 2 Oct 2004 14:58:59 -0400 (EDT) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org Subject: Re: CRAMing for last call References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> From: Sam Hartman Date: Sat, 02 Oct 2004 14:58:59 -0400 In-Reply-To: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> (Lyndon Nerenberg's message of "Fri, 01 Oct 2004 22:02:54 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> Finally, we need to address the issue of the MD5 "break." Lyndon> I have held off from commenting on this issue until the Lyndon> community has seen explicit evidence of the attack, and Lyndon> the implications of it. At this point, I don't know if the Lyndon> document deserves a writeup on the attack. Theory abounds, Lyndon> but I haven't yet seen a practical attack that works in Lyndon> the general case. We should at the least make mention of Lyndon> what has been discussed, and point to the literature, but Lyndon> I don't think the document deserves to discuss all the Lyndon> possible attacks. This doesn't mean to discourage anyone Lyndon> from contributing text to the Security Considerations Lyndon> section (please do). The security area seems to believe that hmac-md5 is still OK, at least for now. Especially since cram-md5 does not require much structure for the challenge, we should discuss the issue in the security considerations section. Will you need agenda time at the next meeting? If so, can you give an estimate of how much and what we want to cover? Thanks, --Sam From owner-ietf-sasl Sat Oct 2 12:27:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JRwgL050442; Sat, 2 Oct 2004 12:27:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92JRwZV050441; Sat, 2 Oct 2004 12:27:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JRuIC050432 for ; Sat, 2 Oct 2004 12:27:56 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i92JRoZv073801; Sat, 2 Oct 2004 19:27:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041002121256.0419c878@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 02 Oct 2004 12:27:46 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Simon Josefsson , ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@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:52 AM 10/2/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> be verified. The precise form of the authorization identity > Kurt> is, excepting the Unicode restriction, is a application > Kurt> protocol detail. > > >This isn't quite right. By "form" above, I am referring to the shape of the Unicode string and not the encoding of that Unicode string. The shape (Kerberos principal, LDAP DN, LDAP authzid, email address, etc.) of the string is an application protocol matter, its encoding (UTF-8, UTF-32, other) is a mechanism matter. >The form of the requested authorization >identity--the bits that are transferred over the wire--is a mechanism >detail. The protocol profile feeds in unicode codepoints and the >mechanism decides how those codepoints will appear on the wire. The >semantics of these codepoints is what is a protocol detail. From owner-ietf-sasl Tue Oct 5 05:59:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Cxeax010837; Tue, 5 Oct 2004 05:59:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95CxeWk010836; Tue, 5 Oct 2004 05:59:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95CxcQv010827 for ; Tue, 5 Oct 2004 05:59:39 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CEoum-0000Z2-SN for ietf-sasl@imc.org; Tue, 05 Oct 2004 14:59:37 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CEoue-0007l9-Ej; Tue, 05 Oct 2004 14:59:28 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CEoud-0002CQ-00; Tue, 5 Oct 2004 14:59:27 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 5 Oct 2004 14:59:27 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Fixes to my previous comments, and comments to the rest of the draft. I wrote: > Subject: rfc2222bis-08 comments >> 3.2. Authorization and authentication identities >> 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. > (...) > Please clarify that the authorization ID is checked during the > authentication (as section 3.2.1 says). And local policy is used to > either derive the authorization identity or check it. Sorry, s/check(ed)/authorize(d)/ is probably better. >> Any normalization of the authentication identity is defined by a >> particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. Or rather, the protocol or its implementation may do that. >> 3.3. Security layers >> Note that all SASL mechanisms that are unable to negotiate a security >> layer automatically select no security layer. > > Without checking up the 'selects no security layer' thread, I still > can't tell if this says that such a mechanism cancels an old security > layer or if it says that it doesn't affect it. I'll check that later, > unless someone replies first. ...and Section 6.3 clarified it, now that I have gotten that far. ================================================================ > 3. Authentication mechanisms > sasl-mech = 1*20mech-char > mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE > ; mech-char is restricted to "A"-"Z", "0"-"9", "-", > ; and "_" from ASCII character set. In most standards, tokens like sasl-mech cannot start with a hyphen; often they must start with a letter. Prevents problems e.g. with programs that are overeager about extracting command line arguments, or utilities which notice token-like strings in general without an exact idea of what kind of token it is (e.g. click&cut&paste). Is there any reason sasl-mech is different? > 4. Protocol profile requirements > Note that an additional data with success can't be empty. I suggest "Note that if additional data is sent with success, it can't be empty." to clarify that one can send success without additional data. At least that's what I assume it means. The sentence as quoted above confused me: I could see no reason why one must always send additional data with success:-) > 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. That uppercase "MAY" gives the impression that this is the only other option: It may not a more lax stringprep profile, or an entirely different way to prepare. > 5. Mechanism profile guidelines > 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 MUST fail the authentication exchange. I expect preparation of an empty string should not fail, so: s/results in/turns a non-empty string into/. > 6.1. Client sends data first > 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.) Then protocols that support an initial response must be clear on how to distinguish an absent initial response from a present but empty initial response. I expect their protocol profiles must also specify whether or not the protocol _can_ distinguish the two, so the mechanism can tell whether or not to send empty initial responses. Protocol example: A line-oriented protocol similar to SMTP where the client sends commands with space-separated arguments, and servers strip trailing spaces from client command lines. Mechanism example: EXTERNAL with authorization ID = empty string. > 6.2. Server returns success with 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. I don't quite understand. I would have thought that if an attacker can do that, he can also wait for the final client response and then start accessing the server, pretending to be the client. Maybe that just shows my ignorance of the subject, but many other readers will be equally ignorant. > 7. The EXTERNAL mechanism > The client sends a single message containing the UTF-8 encoding of > the authorization identity. The message may be empty. s/message/response/ the first time, s/message/authorization identity/ the second time? See my comments above about empty initial response. > Appendix C. Changes since RFC 2222 > The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has > been removed. I just noticed that has no pointer to the definition of the KERBEROS_V5 mechanism. Its registration only lists a person (Simon Josefsson). The same is true for some other mechanisms. Why is that? -- Hallvard From owner-ietf-sasl Tue Oct 5 07:33:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EXBkb019243; Tue, 5 Oct 2004 07:33:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95EXBff019242; Tue, 5 Oct 2004 07:33:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EXAd9019229 for ; Tue, 5 Oct 2004 07:33:10 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CEqNI-00028W-HZ; Tue, 05 Oct 2004 16:33:08 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CEqNE-0000wR-5a; Tue, 05 Oct 2004 16:33:04 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CEqNC-0002Ps-00; Tue, 5 Oct 2004 16:33:02 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> References: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 5 Oct 2004 16:33:02 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >>> Abstract >> >>> The Simple Authentication and Security Layer (SASL) is a framework >>> for providing authentication and data security services in >>> connection-oriented protocols via replaceable >> >>authentication > > The sentence might be more clear if worded: > The Simple Authentication and Security Layer (SASL) is > a framework for providing authentication and data security > services via replaceable mechanisms to connection-oriented > protocols. I don't think so; it looks a little strange to have the 'to...' after the 'via...'. Maybe s/in/to/ would improve the original sentence. I've asked a coworker what he thought the Abstract meant: He got it more or less right, but was somewhat vague about it and thought it was a bit hard to get. He did not think my suggested extra words would make a difference. -- Hallvard From owner-ietf-sasl Sun Oct 10 15:42:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AMg31s006769; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9AMg3FA006768; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-FORTY-THREE.MIT.EDU [18.187.6.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AMg30J006761 for ; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 94B1F168025; Sun, 10 Oct 2004 18:42:10 -0400 (EDT) To: ietf-sasl@imc.org Subject: Making forward progress From: Sam Hartman Date: Sun, 10 Oct 2004 18:42:10 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've seen no objections to Kurt's new summary of the identities issue nor to his proposed text for section 3. I think we should move forward with that change. Alexey, how much help do you need dealing with implications of this change for the rest of the document? Also, are there ny of Hallvard's comments that you have questions about or that you believe require more WG discussion? --Sam From owner-ietf-sasl Tue Oct 12 06:30:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CDUnPA033640; Tue, 12 Oct 2004 06:30:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CDUnPv033639; Tue, 12 Oct 2004 06:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CDUlAJ033632 for ; Tue, 12 Oct 2004 06:30:48 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 14:30:52 +0100 Message-ID: <416BDC8C.8060906@isode.com> Date: Tue, 12 Oct 2004 14:30:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Making forward progress References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: >I've seen no objections to Kurt's new summary of the identities issue >nor to his proposed text for section 3. I think we should move >forward with that change. > > Sounds good. >Alexey, how much help do you need dealing with implications of this >change for the rest of the document? > > I will need somebody's help to review my changes once I am done. >Also, are there any of Hallvard's comments that you have questions >about or that you believe require more WG discussion? > > I haven't looked very attentively, but at this time I think most issues/questions are straightforward. Let me cautiously promise to have another revision by October 25. Cautiously, because I need to submit 3 more documents in other WGs by the same date. Alexey From owner-ietf-sasl Tue Oct 12 08:52:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFqAFn047576; Tue, 12 Oct 2004 08:52:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CFqADW047575; Tue, 12 Oct 2004 08:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFq8rk047566 for ; Tue, 12 Oct 2004 08:52:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 16:52:10 +0100 Message-ID: <416BFDAA.3090507@isode.com> Date: Tue, 12 Oct 2004 16:52:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040303010201000505010401" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------040303010201000505010401 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>3. Authentication mechanisms >> >> sasl-mech = 1*20mech-char >> mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE >> ; mech-char is restricted to "A"-"Z", "0"-"9", "-", >> ; and "_" from ASCII character set. >> >> > >In most standards, tokens like sasl-mech cannot start with a hyphen; >often they must start with a letter. Prevents problems e.g. with >programs that are overeager about extracting command line arguments, or >utilities which notice token-like strings in general without an exact >idea of what kind of token it is (e.g. click&cut&paste). Is there any >reason sasl-mech is different? > I see your point, but at this time I would rather not change this. Just in case somebody has designed and deployed a mechanism that starts with "_" or "-". >>4. Protocol profile requirements >> >> >> Note that an additional data with success can't be empty. >> > >I suggest > "Note that if additional data is sent with success, it can't be empty." >to clarify that one can send success without additional data. At least >that's what I assume it means. The sentence as quoted above confused >me: I could see no reason why one must always send additional data with >success:-) > Ok and fixed. >> 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. >> >> > >That uppercase "MAY" gives the impression that this is the only other >option: It may not a more lax stringprep profile, or an entirely >different way to prepare. > This MAY is just fine according to [KEYWORDS] (RFC 2119). I am not sure how this can be improved. The reason for having the MAY is to emphasize that this is actually considered a reasonable thing to do. >>5. Mechanism profile guidelines >> >> 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 MUST fail the authentication exchange. >> >> > >I expect preparation of an empty string should not fail, so: >s/results in/turns a non-empty string into/. > > This text is talking about authentication identities and passwords. I am not sure whether the empty string should be allowed. >>6.1. Client sends data first >> >> >> 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.) >> >> > >Then protocols that support an initial response must be clear on how to >distinguish an absent initial response from a present but empty initial >response. I expect their protocol profiles must also specify whether or >not the protocol _can_ distinguish the two, so the mechanism can tell >whether or not to send empty initial responses. > This is described in Section 4, bullet # 2. > >Protocol example: A line-oriented protocol similar to SMTP where the >client sends commands with space-separated arguments, and servers strip >trailing spaces from client command lines. > >Mechanism example: EXTERNAL with authorization ID = empty string. > > > >>6.2. Server returns success with 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. >> >> > >I don't quite understand. I would have thought that if an attacker can >do that, he can also wait for the final client response and then start >accessing the server, pretending to be the client. Maybe that just >shows my ignorance of the subject, but many other readers will be >equally ignorant. > What you are saying might be true, but I don't think it is relevant for the section you've quoted. By the time the server has sent a fake (or wrong) "additional data with success", it is too late: the client has already provided its credentials to the server. >>7. The EXTERNAL mechanism >> >> >> The client sends a single message containing the UTF-8 encoding of >> the authorization identity. The message may be empty. >> >> > >s/message/response/ the first time, >s/message/authorization identity/ the second time? > > I actually prefer to keep the informal term message here. >See my comments above about empty initial response. > > >>Appendix C. Changes since RFC 2222 >> >> >> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >> been removed. >> > >I just noticed that >has no pointer to the definition of the KERBEROS_V5 mechanism. Its >registration only lists a person (Simon Josefsson). The same is true >for some other mechanisms. Why is that? > There is no reference, because there is no RFC. I think one can ask IANA to add one. Alexey --------------040303010201000505010401 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
3.    Authentication mechanisms    
   sasl-mech    = 1*20mech-char
   mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
                  ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
                  ; and "_" from ASCII character set.
    

In most standards, tokens like sasl-mech cannot start with a hyphen;
often they must start with a letter.  Prevents problems e.g. with
programs that are overeager about extracting command line arguments, or
utilities which notice token-like strings in general without an exact
idea of what kind of token it is (e.g. click&cut&paste).  Is there any
reason sasl-mech is different?
I see your point, but at this time I would rather not change this. Just in case somebody has designed and deployed a mechanism that starts with "_" or "-". 
4.    Protocol profile requirements
    
   Note that an additional data with success can't be empty. 

I suggest
  "Note that if additional data is sent with success, it can't be empty."
to clarify that one can send success without additional data.  At least
that's what I assume it means.  The sentence as quoted above confused
me: I could see no reason why one must always send additional data with
success:-)
Ok and fixed. 
   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.
    

That uppercase "MAY" gives the impression that this is the only other
option:  It may not a more lax stringprep profile, or an entirely
different way to prepare.
This MAY is just fine according to [KEYWORDS] (RFC 2119).
I am not sure how this can be improved.

The reason for having the MAY is to emphasize that this is actually considered a reasonable thing to do.
5.    Mechanism profile guidelines    
   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 MUST fail the authentication exchange.
    

I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
This text is talking about authentication identities and passwords. I am not sure whether the empty string should be allowed. 
6.1.  Client sends data first
    
   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.)
    

Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.
This is described in Section 4, bullet # 2.

Protocol example: A line-oriented protocol similar to SMTP where the
client sends commands with space-separated arguments, and servers strip
trailing spaces from client command lines.

Mechanism example: EXTERNAL with authorization ID = empty string.

  
6.2.  Server returns success with 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.
    

I don't quite understand.  I would have thought that if an attacker can
do that, he can also wait for the final client response and then start
accessing the server, pretending to be the client.  Maybe that just
shows my ignorance of the subject, but many other readers will be
equally ignorant.
What you are saying might be true, but I don't think it is relevant for the section you've quoted. By the time the server has sent a fake (or wrong) "additional data with success", it is too late: the client has already provided its credentials to the server. 
7.    The EXTERNAL mechanism
    
   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
    

s/message/response/ the first time,
s/message/authorization identity/ the second time?
I actually prefer to keep the informal term message here.
See my comments above about empty initial response.
  
Appendix C. Changes since RFC 2222
    
   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.    

I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?
There is no reference, because there is no RFC. I think one can ask IANA to add one.

Alexey

--------------040303010201000505010401-- From owner-ietf-sasl Tue Oct 12 10:12:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHCqSH056492; Tue, 12 Oct 2004 10:12:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CHCqfX056491; Tue, 12 Oct 2004 10:12:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CHCoa9056480 for ; Tue, 12 Oct 2004 10:12:51 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa04450; 12 Oct 2004 13:12 EDT Date: Tue, 12 Oct 2004 13:12:51 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <107890000.1097601171@minbar.fac.cs.cmu.edu> In-Reply-To: <416BFDAA.3090507@isode.com> References: <416BFDAA.3090507@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 Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov wrote: > Hallvard B Furuseth wrote: > >>> 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. >>> >>> >> >> That uppercase "MAY" gives the impression that this is the only other >> option: It may not a more lax stringprep profile, or an entirely >> different way to prepare. >> > This MAY is just fine according to [KEYWORDS] (RFC 2119). > I am not sure how this can be improved. > > The reason for having the MAY is to emphasize that this is actually > considered a reasonable thing to do. Try this: Profiles MAY use a stringprep profile other than SASLprep, or none at all. >>> 6.2. Server returns success with 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. >>> >>> >> >> I don't quite understand. I would have thought that if an attacker can >> do that, he can also wait for the final client response and then start >> accessing the server, pretending to be the client. Maybe that just >> shows my ignorance of the subject, but many other readers will be >> equally ignorant. >> > What you are saying might be true, but I don't think it is relevant for > the section you've quoted. By the time the server has sent a fake (or > wrong) "additional data with success", it is too late: the client has > already provided its credentials to the server. But the same is true even if you don't support "additional data with success". By the time the server sends the last data, the client has _still_ already sent its credentials to the server. In either case the client cannot abort the exchange, because the MitM attacker simply won't forward that part. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Tue Oct 12 10:39:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHdCq8058886; Tue, 12 Oct 2004 10:39:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CHdCZ4058885; Tue, 12 Oct 2004 10:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHdBNd058879 for ; Tue, 12 Oct 2004 10:39:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 18:39:18 +0100 Message-ID: <416C16C5.3090809@isode.com> Date: Tue, 12 Oct 2004 18:39:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> In-Reply-To: <107890000.1097601171@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov > wrote: > >> Hallvard B Furuseth wrote: >> >>>> 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. >>> >>> >>> That uppercase "MAY" gives the impression that this is the only other >>> option: It may not a more lax stringprep profile, or an entirely >>> different way to prepare. >>> >> This MAY is just fine according to [KEYWORDS] (RFC 2119). >> I am not sure how this can be improved. >> >> The reason for having the MAY is to emphasize that this is actually >> considered a reasonable thing to do. > > Try this: > > Profiles MAY use a stringprep profile other than SASLprep, or none at > all. I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep + additional restrictions) is a common case. >>>> 6.2. Server returns success with 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. >>> >>> I don't quite understand. I would have thought that if an attacker can >>> do that, he can also wait for the final client response and then start >>> accessing the server, pretending to be the client. Maybe that just >>> shows my ignorance of the subject, but many other readers will be >>> equally ignorant. >>> >> What you are saying might be true, but I don't think it is relevant for >> the section you've quoted. By the time the server has sent a fake (or >> wrong) "additional data with success", it is too late: the client has >> already provided its credentials to the server. > > But the same is true even if you don't support "additional data with > success". By the time the server sends the last data, the client has > _still_ already sent its credentials to the server. In either case > the client cannot abort the exchange, because the MitM attacker simply > won't forward that part. I agree with you. The point of the paragraph is to say that with additional data with success the client is *not able* to abort SASL exchange, thus it has to disconnect. From owner-ietf-sasl Tue Oct 12 11:17:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIHRAc062083; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CIHR0O062082; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIHQNt062076 for ; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D5034E0053; Tue, 12 Oct 2004 14:17:58 -0400 (EDT) To: Jeffrey Hutzelman Cc: Alexey Melnikov , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Tue, 12 Oct 2004 14:17:58 -0400 In-Reply-To: <107890000.1097601171@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 12 Oct 2004 13:12:51 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Jeffrey> Melnikov Jeffrey> wrote: >> Hallvard B Furuseth wrote: >>>> 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. >>>> >>>> >>> That uppercase "MAY" gives the impression that this is the >>> only other option: It may not a more lax stringprep profile, >>> or an entirely different way to prepare. >>> >> This MAY is just fine according to [KEYWORDS] (RFC 2119). I am >> not sure how this can be improved. >> >> The reason for having the MAY is to emphasize that this is >> actually considered a reasonable thing to do. Jeffrey> Try this: Jeffrey> Profiles MAY use a stringprep profile other than Jeffrey> SASLprep, or none at all. I prefer the text currently in the draft to your proposed text. From owner-ietf-sasl Tue Oct 12 14:39:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLdA4o080187; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CLdAIZ080186; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLd9Lo080174 for ; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CHUMW-0006sq-Jv; Tue, 12 Oct 2004 23:39:16 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHUMR-0007Qe-OK; Tue, 12 Oct 2004 23:39:11 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHUMO-0005aB-00; Tue, 12 Oct 2004 23:39:08 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416BFDAA.3090507@isode.com> References: <416BFDAA.3090507@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 12 Oct 2004 23:39:08 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>> 3. Authentication mechanisms >>> >>> sasl-mech = 1*20mech-char >>> mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE >>> ; mech-char is restricted to "A"-"Z", "0"-"9", "-", >>> ; and "_" from ASCII character set. >> >> In most standards, tokens like sasl-mech cannot start with a hyphen; >> often they must start with a letter. Prevents problems e.g. with >> programs that are overeager about extracting command line arguments, or >> utilities which notice token-like strings in general without an exact >> idea of what kind of token it is (e.g. click&cut&paste). Is there any >> reason sasl-mech is different? >> > I see your point, but at this time I would rather not change this. Just > in case somebody has designed and deployed a mechanism that starts with > "_" or "-". OK. >>> 5. Mechanism profile guidelines >>> >>> 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 MUST fail the authentication exchange. >> >> I expect preparation of an empty string should not fail, so: >> s/results in/turns a non-empty string into/. > > This text is talking about authentication identities and passwords. I am > not sure whether the empty string should be allowed. I can see nothing which forbids it, neither in rfc2222 nor 2222bis. I have certainly set empty passwords on Unix boxes (off the net); if there is a SASL library which allows empty passwords then I assume people have found use for them with SASL too. I expect an empty authentication IDs would be messier, unless the authorization ID which is derived from that ID is non-empty. >>> 6.1. Client sends data first >>> >>> 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.) >> >> Then protocols that support an initial response must be clear on how to >> distinguish an absent initial response from a present but empty initial >> response. I expect their protocol profiles must also specify whether or >> not the protocol _can_ distinguish the two, so the mechanism can tell >> whether or not to send empty initial responses. >> > This is described in Section 4, bullet # 2. No... First, it's only a SHOULD: If the protocol allows for the initial response, the protocol profile SHOULD also describe how an empty initial response is encoded. Second, if that sentence is intended to address this issue, I can think of two different things it can imply in order to do so. It is not at all clear to me that it means either: 1) "If the protocol profile does not say how an initial response is encoded, then empty but present initial responses are not supported." 2) If you s/SHOULD/MUST/: "If initial responses are supported, then it MUST be possible to send an empty initial response which can be distinguished from no initial response." >>> 7. The EXTERNAL mechanism >>> >>> The client sends a single message containing the UTF-8 encoding of >>> the authorization identity. The message may be empty. >> >> s/message/response/ the first time, >> s/message/authorization identity/ the second time? > > I actually prefer to keep the informal term message here. Well, I'll see how empty initial responses turn out... >> See my comments above about empty initial response. >>> Appendix C. Changes since RFC 2222 >>> >>> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >>> been removed. >> >> I just noticed that >> has no pointer to the definition of the KERBEROS_V5 mechanism. Its >> registration only lists a person (Simon Josefsson). The same is true >> for some other mechanisms. Why is that? > > There is no reference, because there is no RFC. I think one can ask IANA > to add one. If there is a standard or "official document" or something for a mechanism, RFC or not, my vote is to at least mention it. When I'm walking through standards and definitions of something I'm working with, it's always annoying when there is suddenly no reference to where to go from there. As with Kerberos5, Googling around will often find competing texts that may or may not be or reflect the "official" standard. Or I can ask (if I knows where), but then I have to sit and wait for someone to answer, and sometimes there is no telling how reliable the respondent is. -- Hallvard From owner-ietf-sasl Tue Oct 12 14:49:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLnY0K080772; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CLnYqb080771; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLnXIN080763 for ; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CHUWc-0002Qv-N6; Tue, 12 Oct 2004 23:49:42 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHUWZ-0006sr-Th; Tue, 12 Oct 2004 23:49:39 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHUWZ-0005bk-00; Tue, 12 Oct 2004 23:49:39 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416C16C5.3090809@isode.com> References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 12 Oct 2004 23:49:39 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Jeffrey Hutzelman wrote: >> wrote: >>>Hallvard B Furuseth wrote: >>> >>>>> 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. >>>> >>>> That uppercase "MAY" gives the impression that this is the only other >>>> option: It may not a more lax stringprep profile, or an entirely >>>> different way to prepare. >>>> >>> This MAY is just fine according to [KEYWORDS] (RFC 2119). >>> I am not sure how this can be improved. >>> >>> The reason for having the MAY is to emphasize that this is actually >>> considered a reasonable thing to do. >> >> Try this: >> >> Profiles MAY use a stringprep profile other than SASLprep, or none at >> all. > > I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep > + additional restrictions) is a common case. Profiles whose (...) SHOULD use SASLPrep or a stricter stringprep profile, but MAY use other stringprep profiles or none at all? From owner-ietf-sasl Tue Oct 12 15:38:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CMcui7084034; Tue, 12 Oct 2004 15:38:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CMcu5G084033; Tue, 12 Oct 2004 15:38:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CMcsC2084027 for ; Tue, 12 Oct 2004 15:38:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 748BDE0053; Tue, 12 Oct 2004 18:39:24 -0400 (EDT) To: Hallvard B Furuseth Cc: Alexey Melnikov , Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> From: Sam Hartman Date: Tue, 12 Oct 2004 18:39:24 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Tue, 12 Oct 2004 23:49:39 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not really sure it's OK for a protocol to use no stringprep profile at all. Especially for an IETF protocol I'm not sure I can think of situations where the right technical solution would not involve stringprep of some kind. From owner-ietf-sasl Wed Oct 13 01:07:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D87qA5089691; Wed, 13 Oct 2004 01:07:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D87qGm089690; Wed, 13 Oct 2004 01:07:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D87o5n089652 for ; Wed, 13 Oct 2004 01:07:51 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHeAy-00040L-KV for ietf-sasl@imc.org; Wed, 13 Oct 2004 10:08:01 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHeAf-0007ms-Rt; Wed, 13 Oct 2004 10:07:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHeAf-0007Kc-00; Wed, 13 Oct 2004 10:07:41 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis Appendix C Date: Wed, 13 Oct 2004 10:07:41 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Appendix C (Changes since RFC 2222) includes an extract of changes between various rfc2222/rfc2222bis versions, rather than just changes since RFC 2222. Examples: Replaced UTF-8 ABNF with the reference to the UTF-8 document. RFC 2222 did not refer to UTF-8 at all. OTOH, the new UTF-8 MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned. Replaced "buffers of security encoded data" with "buffers of protected data" for clarity. That first phrase does not occur in rfc2222. Made requirement to verify that an authorization identity is correct by performing SASLprep a SHOULD, instead of a MUST. rfc2222 does not contain a single MUST. And if that SHOULD is the one in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is correct, not that the ID itself is correct. Another detail: The "SKEY" mechanism described in RFC 2222 is obsolete and has been removed. It has been replaced by the OTP mechanism [SASL-OTP]. This is the only mention of [SASL-OTP] outside of the References section. Is that intentional? -- Hallvard From owner-ietf-sasl Wed Oct 13 02:56:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9uXab028557; Wed, 13 Oct 2004 02:56:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D9uXY6028556; Wed, 13 Oct 2004 02:56:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9uVxa028537 for ; Wed, 13 Oct 2004 02:56:32 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 10:56:43 +0100 Message-ID: <416CFBDA.8000707@isode.com> Date: Wed, 13 Oct 2004 10:56:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000907060501040307020905" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------000907060501040307020905 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>>>6.1. Client sends data first >>>> >>>> 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.) >>>> >>>> >>>Then protocols that support an initial response must be clear on how to >>>distinguish an absent initial response from a present but empty initial >>>response. I expect their protocol profiles must also specify whether or >>>not the protocol _can_ distinguish the two, so the mechanism can tell >>>whether or not to send empty initial responses. >>> >>> >> This is described in Section 4, bullet # 2. >> >> > >No... First, it's only a SHOULD: > > If the protocol allows for the initial response, the protocol profile > SHOULD also describe how an empty initial response is encoded. > > I've already changed SHOULD to MUST. This issue was raised during WGLC. >Second, if that sentence is intended to address this issue, I can think >of two different things it can imply in order to do so. It is not at >all clear to me that it means either: > >1) "If the protocol profile does not say how an initial response is > encoded, then empty but present initial responses are not supported." > > >2) If you s/SHOULD/MUST/: "If initial responses are supported, then it > MUST be possible to send an empty initial response which can be > distinguished from no initial response." > > The intention was to say #2. I am not aware of any protocol profile that supports initial response, but doesn't allow for it being empty. >>>>7. The EXTERNAL mechanism >>>> >>>> The client sends a single message containing the UTF-8 encoding of >>>> the authorization identity. The message may be empty. >>>> >>>> >>>s/message/response/ the first time, >>>s/message/authorization identity/ the second time? >>> >>> >> I actually prefer to keep the informal term message here. >> >> > >Well, I'll see how empty initial responses turn out... > > >>>See my comments above about empty initial response. >>> >>> >>>>Appendix C. Changes since RFC 2222 >>>> >>>> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >>>> been removed. >>>> >>>> >>>I just noticed that >>>has no pointer to the definition of the KERBEROS_V5 mechanism. Its >>>registration only lists a person (Simon Josefsson). The same is true >>>for some other mechanisms. Why is that? >>> >>> >> There is no reference, because there is no RFC. I think one can ask IANA >> to add one. >> >> > >If there is a standard or "official document" or something for a >mechanism, RFC or not, my vote is to at least mention it. When I'm >walking through standards and definitions of something I'm working with, >it's always annoying when there is suddenly no reference to where to go >from there. As with Kerberos5, Googling around will often find >competing texts that may or may not be or reflect the "official" >standard. Or I can ask (if I knows where), but then I have to sit and >wait for someone to answer, and sometimes there is no telling how >reliable the respondent is. > > For KERBEROS_V5 registration you need to send a email to Simon, he is the authoritative source of information. It would be even better if you ask him to update the registration. Alexey --------------000907060501040307020905 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
6.1.  Client sends data first

   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.)
        
Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.
      
 This is described in Section 4, bullet # 2.
    

No...  First, it's only a SHOULD:

   If the protocol allows for the initial response, the protocol profile
   SHOULD also describe how an empty initial response is encoded.
I've already changed SHOULD to MUST. This issue was raised during WGLC.
Second, if that sentence is intended to address this issue, I can think
of two different things it can imply in order to do so.  It is not at
all clear to me that it means either:

1) "If the protocol profile does not say how an initial response is
   encoded, then empty but present initial responses are not supported."
  
2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
   MUST be possible to send an empty initial response which can be
   distinguished from no initial response."
The intention was to say #2. I am not aware of any protocol profile that supports initial response, but doesn't allow for it being empty.
7.    The EXTERNAL mechanism

   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
        
s/message/response/ the first time,
s/message/authorization identity/ the second time?
      
 I actually prefer to keep the informal term message here.
    

Well, I'll see how empty initial responses turn out...
  
See my comments above about empty initial response.
      
Appendix C. Changes since RFC 2222

   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.   
        
I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?
      
 There is no reference, because there is no RFC. I think one can ask IANA
 to add one.
    

If there is a standard or "official document" or something for a
mechanism, RFC or not, my vote is to at least mention it.  When I'm
walking through standards and definitions of something I'm working with,
it's always annoying when there is suddenly no reference to where to go
from there.  As with Kerberos5, Googling around will often find
competing texts that may or may not be or reflect the "official"
standard.  Or I can ask (if I knows where), but then I have to sit and
wait for someone to answer, and sometimes there is no telling how
reliable the respondent is.
For KERBEROS_V5 registration you need to send a email to Simon, he is the authoritative source of information. It would be even better if you ask him to update the registration.

Alexey

--------------000907060501040307020905-- From owner-ietf-sasl Wed Oct 13 03:27:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DARPn4041920; Wed, 13 Oct 2004 03:27:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DARPwi041919; Wed, 13 Oct 2004 03:27:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DAROoP041901 for ; Wed, 13 Oct 2004 03:27:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 11:27:37 +0100 Message-ID: <416D0318.2080103@isode.com> Date: Wed, 13 Oct 2004 11:27:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >I think Appendix C (Changes since RFC 2222) includes an extract of >changes between various rfc2222/rfc2222bis versions, rather than just >changes since RFC 2222. > That is correct. Question to the WG: should I clean up the Appendix C or should I wait till the document is approved for publication? >[...] > >Another detail: > > The "SKEY" mechanism described in RFC 2222 is obsolete and has been > removed. It has been replaced by the OTP mechanism [SASL-OTP]. > >This is the only mention of [SASL-OTP] outside of the References >section. Is that intentional? > > [SASL-OTP] is mentioned in 10.2 (Informative references). From owner-ietf-sasl Wed Oct 13 07:11:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEB43p082754; Wed, 13 Oct 2004 07:11:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEB4Iv082753; Wed, 13 Oct 2004 07:11:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEB2S5082746 for ; Wed, 13 Oct 2004 07:11:03 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06405; 13 Oct 2004 10:11 EDT Date: Wed, 13 Oct 2004 10:11:13 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Hallvard B Furuseth cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <445910000.1097676673@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@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 Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman wrote: > > I'm not really sure it's OK for a protocol to use no stringprep > profile at all. > > Especially for an IETF protocol I'm not sure I can think of situations > where the right technical solution would not involve stringprep of > some kind. What an application's SASL profile says about the form and preparation of authorization names will always depend on what the application protocol does in a broader sense. For applications which use some sort of string for identity and authorization, the SASL profile should specify use of the same string, with the same behaviours and semantics. That means if the application does not use stringprep on authorization ID's used, say, in manipulating ACL's, then it should not use it on SASL authorization ID's either. Also, I can think of a scenario in which the right solution does not involve any form of stringprep. Consider an application which does identity and access control using UUID's rather than strings. I do not believe there is anything in SASL that would prevent this use. I agree that when applications use strings to identify users, they should use some form of stringprep. I agree that in many such cases, it would be appropriate to use SASLprep rather than constructing a separate stringprep profile for that application. However, mandating the use of stringprep in application protocols is out of scope for this working group, and I believe that it is more important that SASL authorization ID's have the same semantics as those used elsewhere in the application than that they have the same semantics as other strings used in SASL. -- Jeff From owner-ietf-sasl Wed Oct 13 07:14:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEEJul083204; Wed, 13 Oct 2004 07:14:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEEJbi083203; Wed, 13 Oct 2004 07:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEEH90083197 for ; Wed, 13 Oct 2004 07:14:18 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06409; 13 Oct 2004 10:14 EDT Date: Wed, 13 Oct 2004 10:14:27 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C Message-ID: <446620000.1097676867@minbar.fac.cs.cmu.edu> In-Reply-To: <416D0318.2080103@isode.com> References: <416D0318.2080103@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, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: > > Hallvard B Furuseth wrote: > >> I think Appendix C (Changes since RFC 2222) includes an extract of >> changes between various rfc2222/rfc2222bis versions, rather than just >> changes since RFC 2222. >> > That is correct. > > Question to the WG: should I clean up the Appendix C or should I wait > till the document is approved for publication? This section is essentially a changelog. Normally, such sections are intended for use during the development of a document, and carry a note to the RFC-Editor asking that they be removed prior to publication. I think that would be the apporpriate thing to do in this case. -- Jeff From owner-ietf-sasl Wed Oct 13 07:17:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEHG8A083552; Wed, 13 Oct 2004 07:17:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEHGiu083551; Wed, 13 Oct 2004 07:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEHFUS083544 for ; Wed, 13 Oct 2004 07:17:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 15:17:27 +0100 Message-ID: <416D38F6.6070403@isode.com> Date: Wed, 13 Oct 2004 15:17:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> In-Reply-To: <446620000.1097676867@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov > wrote: > >> Hallvard B Furuseth wrote: >> >>> I think Appendix C (Changes since RFC 2222) includes an extract of >>> changes between various rfc2222/rfc2222bis versions, rather than just >>> changes since RFC 2222. >> >> That is correct. >> >> Question to the WG: should I clean up the Appendix C or should I wait >> till the document is approved for publication? > > This section is essentially a changelog. Yes. > Normally, such sections are intended for use during the development of > a document, and carry a note to the RFC-Editor asking that they be > removed prior to publication. I think that would be the apporpriate > thing to do in this case. I disagree. I find such section quite useful when one has to quickly find out about changes since an older RFC. From owner-ietf-sasl Wed Oct 13 07:22:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEMcMa084326; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEMc2n084325; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEMbGc084318 for ; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06416; 13 Oct 2004 10:22 EDT Date: Wed, 13 Oct 2004 10:22:48 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth , Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <452140000.1097677368@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@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 Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth wrote: > If there is a standard or "official document" or something for a > mechanism, RFC or not, my vote is to at least mention it. In the case of KERBEROS_V5, there is not. There may be an internet-draft, though I expect it has expired by now if Simon is not still actively working on the mechanism. Internet-drafts are by their nature ephemeral and therefore do not make stable references. Published RFC's may not contain references to internet-drafts. > When I'm > walking through standards and definitions of something I'm working with, > it's always annoying when there is suddenly no reference to where to go > from there. It is not necessary, appropriate, or even possible for the SASL base document to include an exhaustive list of SASL mechanisms. This is hardly the first "framework" document to include support for multiple mechanisms, and the normal practice is to make reference to specific mechanisms only when they are REQUIRED or RECOMMENDED, or when such a reference is needed to illustrate a concept described in the framework. It is worth noting that as with any "framework" defined by the IETF, there _is_ an exhaustive list of all mechanisms, which is maintained by the IANA. IANA registries generally include a pointer to a contact person and/or to a published specification, if there is one. There is no "official" standard KERBEROS_V5 mechanism. I refer you to the following paragraph, which appears as part of the boilerplate at the top of every internet-draft: 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''. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Wed Oct 13 07:42:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEge2I086965; Wed, 13 Oct 2004 07:42:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEgeY7086964; Wed, 13 Oct 2004 07:42:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEgdc4086957 for ; Wed, 13 Oct 2004 07:42:39 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 39309767A4; Wed, 13 Oct 2004 10:42:39 -0400 (EDT) To: Jeffrey Hutzelman Cc: Hallvard B Furuseth , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> <445910000.1097676673@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 13 Oct 2004 10:42:38 -0400 In-Reply-To: <445910000.1097676673@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 13 Oct 2004 10:11:13 -0400") Message-ID: <871xg27k81.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman Jeffrey> wrote: >> I'm not really sure it's OK for a protocol to use no >> stringprep profile at all. >> >> Especially for an IETF protocol I'm not sure I can think of >> situations where the right technical solution would not involve >> stringprep of some kind. Jeffrey> What an application's SASL profile says about the form Jeffrey> and preparation of authorization names will always depend Jeffrey> on what the application protocol does in a broader sense. Jeffrey> For applications which use some sort of string for Jeffrey> identity and authorization, the SASL profile should Jeffrey> specify use of the same string, with the same behaviours Jeffrey> and semantics. That means if the application does not Jeffrey> use stringprep on authorization ID's used, say, in Jeffrey> manipulating ACL's, then it should not use it on SASL Jeffrey> authorization ID's either. Jeffrey> Also, I can think of a scenario in which the right Jeffrey> solution does not involve any form of stringprep. Jeffrey> Consider an application which does identity and access Jeffrey> control using UUID's rather than strings. I do not Jeffrey> believe there is anything in SASL that would prevent this Jeffrey> use. True. But what you can do is somewhat constrained by the IESG for standards-track documents. I believe that MAY use no stringprep is technically true but is also too strong of a statement. --Sam From owner-ietf-sasl Wed Oct 13 08:08:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DF8RKo090282; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DF8Rjv090281; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DF8Qpo090263 for ; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHkk1-000266-DJ; Wed, 13 Oct 2004 17:08:38 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHkjy-0000ha-0a; Wed, 13 Oct 2004 17:08:34 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHkjx-0000Wt-00; Wed, 13 Oct 2004 17:08:33 +0200 From: Hallvard B Furuseth Message-Id: To: Jeffrey Hutzelman Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <452140000.1097677368@minbar.fac.cs.cmu.edu> References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Oct 2004 17:08:33 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: >On Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth > wrote: > >> (...internet-draft KERBEROS_V5...) >> >> When I'm >> walking through standards and definitions of something I'm working with, >> it's always annoying when there is suddenly no reference to where to go >> from there. > > It is not necessary, appropriate, or even possible for the SASL base > document to include an exhaustive list of SASL mechanisms. You have lost the context. I was talking about a reference - formal or informal - in the IANA registry, not rfc2222bis. But back to rfc2222bis: > There is no "official" standard KERBEROS_V5 mechanism. Then it seems strange to me to remove KERBEROS_V4 without further comment when there is no standard replacement - in particular since SASL was born around Kerberos and S/Key, according to the mailinglist archive. I suggest to add a purely informational sentence or two about why this was done and that an informal Kerberos5 exists. And if V4- support was removed because of a security flaw in that version, warn that one really shouldn't keep support for it. (Maybe the same applies to S/Key, but I know even less about that than about Kerberos.) -- Hallvard From owner-ietf-sasl Wed Oct 13 08:19:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFJJXr092391; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFJJ7I092390; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DFJIdn092383 for ; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06459; 13 Oct 2004 11:19 EDT Date: Wed, 13 Oct 2004 11:19:04 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <490070000.1097680744@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> 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, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth wrote: > But back to rfc2222bis: > >> There is no "official" standard KERBEROS_V5 mechanism. > > Then it seems strange to me to remove KERBEROS_V4 without further > comment when there is no standard replacement Note that there is a distinct difference between SASL mechanisms and the underlying authentication technology. The SASL KERBEROS_V4 mechanism is obsolete because the underlying technology is obsolete. It is worth noting that Kerberos V4 is not and never has been an IETF standard. If you want to use Kerberos V5 with SASL, the mechanism you are looking for is named 'GSSAPI'. It is described in draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI" refers specifically to GSS krb5). By contrast, the KERBEROS_V4 mechanism was defined _in the SASL base document_, which is why it is mentioned in the changelog. -- Jeff From owner-ietf-sasl Wed Oct 13 08:33:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFXwJi094465; Wed, 13 Oct 2004 08:33:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFXwVS094463; Wed, 13 Oct 2004 08:33:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFXvZ3094445 for ; Wed, 13 Oct 2004 08:33:57 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHl8l-0000OY-CK; Wed, 13 Oct 2004 17:34:11 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHl8i-0003iL-2D; Wed, 13 Oct 2004 17:34:08 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHl8h-0000bf-00; Wed, 13 Oct 2004 17:34:07 +0200 From: Hallvard B Furuseth Message-Id: To: Jeffrey Hutzelman Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <490070000.1097680744@minbar.fac.cs.cmu.edu> References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> <490070000.1097680744@minbar.fac.cs.cmu.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Oct 2004 17:34:07 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: >On Wednesday, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth > wrote: >>But back to rfc2222bis: >> >>> There is no "official" standard KERBEROS_V5 mechanism. >> >> Then it seems strange to me to remove KERBEROS_V4 without further >> comment when there is no standard replacement > > Note that there is a distinct difference between SASL mechanisms and > the underlying authentication technology. The SASL KERBEROS_V4 > mechanism is obsolete because the underlying technology is obsolete. > It is worth noting that Kerberos V4 is not and never has been an IETF > standard. > > If you want to use Kerberos V5 with SASL, the mechanism you are > looking for is named 'GSSAPI'. It is described in > draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms > based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI" > refers specifically to GSS krb5). OK. Still, it might still be worth mentioning this the draft. I expect what you say is well known to someone who comes to SASL via Kerberos, but it would not be known to someone (like me) who comes to Kerberos via SASL. OTOH, if such a brief sentence could not be sufficiently helpful to a 'kerberos newbie' for there to be any point to it, forget it. -- Hallvard From owner-ietf-sasl Wed Oct 13 08:48:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFmu6q096335; Wed, 13 Oct 2004 08:48:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFmuLa096334; Wed, 13 Oct 2004 08:48:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFmtRZ096328 for ; Wed, 13 Oct 2004 08:48:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9DFnAZv046359; Wed, 13 Oct 2004 15:49:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 08:50:02 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis Appendix C Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <416D38F6.6070403@isode.com> References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@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 07:17 AM 10/13/2004, Alexey Melnikov wrote: >Jeffrey Hutzelman wrote: > >>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: >> >>>Hallvard B Furuseth wrote: >>> >>>>I think Appendix C (Changes since RFC 2222) includes an extract of >>>>changes between various rfc2222/rfc2222bis versions, rather than just >>>>changes since RFC 2222. >>> >>>That is correct. >>> >>>Question to the WG: should I clean up the Appendix C or should I wait >>>till the document is approved for publication? As the WG must review and reach consensus as to content of Appendix before it submitted to the AD for consideration, it should be cleaned up now. >>This section is essentially a changelog. > >Yes. When I think of an I-D changelog, I think of a log of changes between each revision of the I-D. This is not that. >>Normally, such sections are intended for use during the development of a document, and carry a note to the RFC-Editor asking that they be removed prior to publication. If this appendix were a log of changes between each revision of the I-D, I would agree. But this appendix is not that. It is summary of changes made to RFC 2222. >>I think that would be the apporpriate thing to do in this case. > >I disagree. I find such section quite useful when one has to quickly find out about changes since an older RFC. Yes. The purpose of this section is to provide useful information to the reader of the RFC regarding changes since RFC 2222. Kurt From owner-ietf-sasl Wed Oct 13 09:23:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGNBPF000425; Wed, 13 Oct 2004 09:23:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DGNBSa000424; Wed, 13 Oct 2004 09:23:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGN9ef000418 for ; Wed, 13 Oct 2004 09:23:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 17:23:15 +0100 Message-ID: <416D5672.4010506@isode.com> Date: Wed, 13 Oct 2004 17:23:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@isode.com> <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> Content-Type: multipart/alternative; boundary="------------010105090404090300040408" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------010105090404090300040408 Content-type: text/plain; charset="us-ascii" Kurt D. Zeilenga wrote: >At 07:17 AM 10/13/2004, Alexey Melnikov wrote: > > >>Jeffrey Hutzelman wrote: >> >> >>>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: >>> >>> >>>>Hallvard B Furuseth wrote: >>>> >>>> >>>>>I think Appendix C (Changes since RFC 2222) includes an extract of >>>>>changes between various rfc2222/rfc2222bis versions, rather than just >>>>>changes since RFC 2222. >>>>> >>>>> >>>>That is correct. >>>> >>>>Question to the WG: should I clean up the Appendix C or should I wait >>>>till the document is approved for publication? >>>> >>>> > >As the WG must review and reach consensus as to content of >Appendix before it submitted to the AD for consideration, >it should be cleaned up now. > > Ok. The more precise questions are: 1). Do we want to keep it (the answer I got so far is "yes") 2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication. >>>This section is essentially a changelog. >>> >>> >>Yes. >> >> > >When I think of an I-D changelog, I think of a log of changes >between each revision of the I-D. This is not that. > > In practice it is kind of "in between". I was updating it each time a major change was done, but each change was only recorded once (even if multiple revisions had to deal with the same change). Alexey --------------010105090404090300040408 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Kurt D. Zeilenga wrote:
At 07:17 AM 10/13/2004, Alexey Melnikov wrote:
  
Jeffrey Hutzelman wrote:
    
On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov <Alexey.Melnikov@isode.com> wrote:
      
Hallvard B Furuseth wrote:
        
I think Appendix C (Changes since RFC 2222) includes an extract of
changes between various rfc2222/rfc2222bis versions, rather than just
changes since RFC 2222.
          
That is correct.

Question to the WG: should I clean up the Appendix C or should I wait
till the document is approved for publication?
        

As the WG must review and reach consensus as to content of
Appendix before it submitted to the AD for consideration,
it should be cleaned up now.
Ok.

The more precise questions are:
1). Do we want to keep it (the answer I got so far is "yes")
2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication.
This section is essentially a changelog.
      
Yes.
    

When I think of an I-D changelog, I think of a log of changes
between each revision of the I-D.  This is not that.
In practice it is kind of "in between". I was updating it each time a major change was done, but each change was only recorded once (even if multiple revisions had to deal with the same change).

Alexey

--------------010105090404090300040408-- From owner-ietf-sasl Wed Oct 13 09:42:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGggIp003005; Wed, 13 Oct 2004 09:42:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DGggVu003004; Wed, 13 Oct 2004 09:42:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGgfad002995 for ; Wed, 13 Oct 2004 09:42:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9DGgxZv046723; Wed, 13 Oct 2004 16:42:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013092648.02d02a10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 09:43:51 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis Appendix C Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <416D5672.4010506@isode.com> References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@isode.com> <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> <416D5672.4010506@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 09:23 AM 10/13/2004, Alexey Melnikov wrote: >The more precise questions are: >1). Do we want to keep it (the answer I got so far is "yes") Yes. When revising an existing RFC, it is generally appropriate to summarize the changes made. This information is quite useful to readers of the new RFC, especially to those who implemented the existing RFC. >2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication. First, if such a list is maintained, it must be maintained separately from the above summary. Anways, (as you note) such a list would not be subject to WG review as it would be removed prior to publication. Though some WG find such lists useful, they are certainly not necessary. Given that this document is already through WG last call, I don't see how such a list could be useful to the WG or during subsequent IETF and IESG review. Personally, I think our energy would be better spent ensuring the summary of changes since RFC 2222 was of good quality. So, no. Kurt From owner-ietf-sasl Wed Oct 13 10:18:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHIQS3008951; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DHIQV3008950; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHIPpv008941 for ; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 18:18:23 +0100 Message-ID: <416D635D.4090105@isode.com> Date: Wed, 13 Oct 2004 18:18:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >RFC 2222 did not refer to UTF-8 at all. OTOH, the new UTF-8 >MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned. > > Replaced "buffers of security encoded data" with "buffers of > protected data" for clarity. > > This should read: Replaced "buffers of cipher-text" with "buffers of protected data" for clarity. >That first phrase does not occur in rfc2222. > > Made requirement to verify that an authorization identity is correct > by performing SASLprep a SHOULD, instead of a MUST. > > I've changed this to: Made requirement to verify that an authorization identity is correct by performing SASLprep. Is this better? >rfc2222 does not contain a single MUST. And if that SHOULD is the one >in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is >correct, not that the ID itself is correct. > > From owner-ietf-sasl Wed Oct 13 16:41:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNfD3Y062421; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DNfDal062420; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.mundophp.info ([65.98.66.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNfDZM062414 for ; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) (envelope-from correo@sevein.com) Received: from jesus.sevein.red (4.Red-217-125-56.pooles.rima-tde.net [217.125.56.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mundophp.info (Postfix) with ESMTP id EB0B75363 for ; Thu, 14 Oct 2004 01:41:32 +0200 (CEST) Date: Thu, 14 Oct 2004 01:41:24 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) To: ietf-sasl@imc.org Subject: Fw: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Message-ID: <20041014014124.05ed8f8a@jesus.sevein.red> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I am a Linux user who is trying to configure his own server in Internet= to give services like www, smtp, imap and that stuff. I have been trying t= o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi= th rimap to auth users against courier-imap (and authdaemond agains MySQL). But I thought that it could be better to configure sasl to connect directly= to authdaemond socket. I tried it. But I got this error (always): [postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou= rier authdaemond: Connection refused My configuration files: /etc/sasl/smtpd.conf ^^^^^^^^^^^^^^^^^^^^ pwcheck_method: authdaemond authdaemon_path: /var/lib/courier-imap/authdaemon/socket mech_list: plain login log_level: 7 ls -li /var/lib/courier-imap/authdaemon/socket=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae= mon/socket Moreover, I did this because I though about the Postfix chroot: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri= er-imap/authdaemon/socket I always restart Postfix when I make changes. Gentoo Linux courier-imap-3.0.7 cyrus-sasl-2.1.19-r1 (with authdaemond support) postfix-2.1.3 Do you know what could I do? I am tired of the same! --=20 Jes=FAs Garc=EDa Crespo (aka Sevein) http://www.sevein.com correo@sevein.com GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBbb0qjm2pe+LbF+gRAkw8AJ40rran0f8VTpuqz6DHqpVKnZXsQQCeO5Y+ v1eTceKe0smJlt1sX9Kk/Kk= =yucx -----END PGP SIGNATURE----- --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T-- From owner-ietf-sasl Wed Oct 13 16:36:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNawxJ061789; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DNawxs061788; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.mundophp.info ([65.98.66.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNavZv061782 for ; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) (envelope-from correo@sevein.com) Received: from jesus.sevein.red (4.Red-217-125-56.pooles.rima-tde.net [217.125.56.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mundophp.info (Postfix) with ESMTP id 66D105363 for ; Thu, 14 Oct 2004 01:37:17 +0200 (CEST) Date: Thu, 14 Oct 2004 01:37:10 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) To: ietf-sasl@vpnc.org Subject: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Message-ID: <20041014013710.69560630@jesus.sevein.red> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I am a Linux user who is trying to configure his own server in Internet= to give services like www, smtp, imap and that stuff. I have been trying t= o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi= th rimap to auth users against courier-imap (and authdaemond agains MySQL). But I thought that it could be better to configure sasl to connect directly= to authdaemond socket. I tried it. But I got this error (always): [postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou= rier authdaemond: Connection refused My configuration files: /etc/sasl/smtpd.conf ^^^^^^^^^^^^^^^^^^^^ pwcheck_method: authdaemond authdaemon_path: /var/lib/courier-imap/authdaemon/socket mech_list: plain login log_level: 7 ls -li /var/lib/courier-imap/authdaemon/socket=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae= mon/socket Moreover, I did this because I though about the Postfix chroot: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri= er-imap/authdaemon/socket I always restart Postfix when I make changes. Gentoo Linux courier-imap-3.0.7 cyrus-sasl-2.1.19-r1 (with authdaemond support) postfix-2.1.3 Do you know what could I do? I am tired of the same! --=20 Jes=FAs Garc=EDa Crespo (aka Sevein) http://www.sevein.com correo@sevein.com GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBbbwrjm2pe+LbF+gRAgDuAJ9B6gbh33E5sWkCNJJGei7b4+0NrwCdGWH5 bNigMOZVe14WiiwdQrMIJok= =F28/ -----END PGP SIGNATURE----- --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p-- From owner-ietf-sasl Wed Oct 13 17:02:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E02QbS065062; Wed, 13 Oct 2004 17:02:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E02Qe5065061; Wed, 13 Oct 2004 17:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E02PFX065054 for ; Wed, 13 Oct 2004 17:02:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9E02fZv048950; Thu, 14 Oct 2004 00:02:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013165411.02d58a48@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 17:03:33 -0700 To: =?iso-8859-1?Q?Jes=FAs?= =?iso-8859-1?Q?_Garc=EDa?= Crespo (aka Sevein) From: "Kurt D. Zeilenga" Subject: Re: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Cc: ietf-sasl@vpnc.org In-Reply-To: <20041014013710.69560630@jesus.sevein.red> References: <20041014013710.69560630@jesus.sevein.red> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9E02QFX065055 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please note that this list is for discussing the standardization of SASL and, in particular, undertaking the work of the IETF SASL WG . Your post is off-topic here. Issues specific to any particular SASL implementation should be directed to forums specific to that implementation. From your message, I gather you are using the Cyrus SASL implementation. Hence, I suggest you direct your comments to: Information regarding how to subscribe to this list is available at: http://asg.web.cmu.edu/sasl/#mailinglists Thanks, Kurt - IETF SASL WG co-chair At 04:37 PM 10/13/2004, aka Sevein wrote: >Hi! I am a Linux user who is trying to configure his own server in Internet to give services like www, smtp, imap and that stuff. I have been trying to do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd with rimap to auth users against courier-imap (and authdaemond agains MySQL). > >But I thought that it could be better to configure sasl to connect directly to authdaemond socket. I tried it. But I got this error (always): > >[postfix/smtpd] warning: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused > >My configuration files: > >/etc/sasl/smtpd.conf >^^^^^^^^^^^^^^^^^^^^ >pwcheck_method: authdaemond >authdaemon_path: /var/lib/courier-imap/authdaemon/socket >mech_list: plain login >log_level: 7 > >ls -li /var/lib/courier-imap/authdaemon/socket >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdaemon/socket > >Moreover, I did this because I though about the Postfix chroot: >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ > >ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/courier-imap/authdaemon/socket > >I always restart Postfix when I make changes. > > >Gentoo Linux >courier-imap-3.0.7 >cyrus-sasl-2.1.19-r1 (with authdaemond support) >postfix-2.1.3 > >Do you know what could I do? I am tired of the same! > > >-- >Jesús García Crespo (aka Sevein) >http://www.sevein.com >correo@sevein.com > >GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) > > From owner-ietf-sasl Thu Oct 14 02:34:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E9YOeN023822; Thu, 14 Oct 2004 02:34:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E9YObv023821; Thu, 14 Oct 2004 02:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E9YNjV023798 for ; Thu, 14 Oct 2004 02:34:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 10:33:53 +0100 Message-ID: <416D9CD6.8010309@isode.com> Date: Wed, 13 Oct 2004 22:23:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060000090909080107050306" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------060000090909080107050306 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>>>5. Mechanism profile guidelines >>>> >>>> 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 MUST fail the authentication exchange. >>>> >>>> >>>I expect preparation of an empty string should not fail, so: >>>s/results in/turns a non-empty string into/. >>> >>> >> This text is talking about authentication identities and passwords. I am >> not sure whether the empty string should be allowed. >> >> > >I can see nothing which forbids it, neither in rfc2222 nor 2222bis. > >I have certainly set empty passwords on Unix boxes (off the net); if >there is a SASL library which allows empty passwords then I assume >people have found use for them with SASL too. > >I expect an empty authentication IDs would be messier, unless the >authorization ID which is derived from that ID is non-empty. > > > Ok, I have done the proposed change. Can anybody suggest a better wording? --------------060000090909080107050306 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
5.    Mechanism profile guidelines   

   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 MUST fail the authentication exchange.
        
I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
      
 This text is talking about authentication identities and passwords. I am
 not sure whether the empty string should be allowed.
    

I can see nothing which forbids it, neither in rfc2222 nor 2222bis.

I have certainly set empty passwords on Unix boxes (off the net); if
there is a SASL library which allows empty passwords then I assume
people have found use for them with SASL too.

I expect an empty authentication IDs would be messier, unless the
authorization ID which is derived from that ID is non-empty.
Ok, I have done the proposed change. Can anybody suggest a better wording?

--------------060000090909080107050306-- From owner-ietf-sasl Thu Oct 14 15:51:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EMpPHg069070; Thu, 14 Oct 2004 15:51:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EMpPwe069069; Thu, 14 Oct 2004 15:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EMpNNX069048 for ; Thu, 14 Oct 2004 15:51:24 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CIERP-0000gX-GF for ietf-sasl@imc.org; Fri, 15 Oct 2004 00:51:23 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIERN-0002iS-67; Fri, 15 Oct 2004 00:51:21 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIERM-0005El-00; Fri, 15 Oct 2004 00:51:20 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 00:51:20 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > 1) Re-keying of security layers > SASL mechanisms that support re-keying SHOULD: > - indicate that re-keying is or will be needed immediately; > - provide re-keying messages or transparently include re-keying > messages in the security layers; the latter can happen without > application involvement, but only as long as the application is > engaged in timely bidirectional exchanges with its peer. > > The chairs believes the WG supports addition of this text. Please also explain what 're-keying' and 'timely bidirectional exchanges' are. (I'm guessing that re-keying is a SASL layer's equivalent of TLS ciphersuite renegotiation, but I don't know. I don't know if I would have thought of that if I did not know of TLS. I have no idea how a protocol or implementation can know that a peer will be engage in anything 'timely'. I'm not sure what exactly 'bidirectional exchanges' are either, but from the context my guess would be that if one peer chooses to send a message, the other is expected to notice and send a response, and do so before sending (or also reading?) anything else on the connection.) > 4) Channel Binding > Nico (...) suggest security consideration > text that clients using SASL over TLS should verify > the server's TLS identity to prevent MITM attacks. > He also suggested (...) > > The chairs conclude that the WG supports the former > suggestion but not the latter. Unless just that literal text will be used (except for expanding "MITM"): Note that the draft does not explain what channel bindings are, so either explain or avoid the term. -- Hallvard From owner-ietf-sasl Thu Oct 14 17:26:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0Q3AO080886; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F0Q3IQ080885; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0Q2hh080867 for ; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CIFv3-00030U-Je for ietf-sasl@imc.org; Fri, 15 Oct 2004 02:26:05 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIFv1-0005lo-U0; Fri, 15 Oct 2004 02:26:03 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIFv0-0005Qo-00; Fri, 15 Oct 2004 02:26:02 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: EXTERNAL description Date: Fri, 15 Oct 2004 02:26:02 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 7. The EXTERNAL mechanism > The client sends a single message containing the UTF-8 encoding of > the Maybe add 'requested'? > authorization identity. The message may be empty. The form of the > authorization identity is further restricted by the application-level > protocol's SASL profile. s/is further/may be/. (Further restricted than what? Being empty?:-) Though I'd move that last sentence to the last paragraph (below) so all handling of the authorization identity is in one place. These paragraphs can be shortened a bit now that 'authentication identities' have been introduced: > The server uses information, external to SASL, to determine whether > the client is permitted to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > server indicates failure. The server uses information external to SASL to determine the authentication identity and whether the authentication is to succeed. It then indicates completion or failure of the authentication exchange. > 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. If the requested authorization identity is empty, the authorization identity is to be derived from the authentication identity. -- Hallvard From owner-ietf-sasl Thu Oct 14 17:47:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0lhjN084566; Thu, 14 Oct 2004 17:47:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F0lhLs084565; Thu, 14 Oct 2004 17:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0le7k084555 for ; Thu, 14 Oct 2004 17:47:41 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CIGFz-0006UV-PM; Fri, 15 Oct 2004 02:47:43 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIGFx-0002P9-1J; Fri, 15 Oct 2004 02:47:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIGFw-0005VT-00; Fri, 15 Oct 2004 02:47:40 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C In-Reply-To: <416D635D.4090105@isode.com> References: <416D635D.4090105@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 02:47:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >> Made requirement to verify that an authorization identity is correct >> by performing SASLprep a SHOULD, instead of a MUST. > > I've changed this to: > > Made requirement to verify that an authorization identity is correct > by performing SASLprep. > > Is this better? No, because it's not a requirement:-) Anyway, I think this paragraph can simply be deleted, since it's just part of the 'I-D revision history'. The appendix already covers SASLprep as RFC history: Added text about SASLprep for authentication identities and passwords. Described where SASLprep preparation should take place. -- Hallvard From owner-ietf-sasl Thu Oct 14 18:19:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F1Jj8x089679; Thu, 14 Oct 2004 18:19:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F1JjEi089678; Thu, 14 Oct 2004 18:19:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F1Jilv089671 for ; Thu, 14 Oct 2004 18:19:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CIGl1-0004ZZ-6l; Fri, 15 Oct 2004 03:19:47 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIGky-0003Mv-AG; Fri, 15 Oct 2004 03:19:44 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIGkw-0005Z7-00; Fri, 15 Oct 2004 03:19:42 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis In-Reply-To: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 03:19:42 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > 3.2 Identity Concepts > The client provides its credentials and, optionally, a > string representing the requested authorization identity > as part of the SASL exchange. > When this string is not > provided, the client is requesting to act as the identity > associated with the credentials (e.g., the user is > requesting to act as the authentication identity). No, authentication identity may not even have a syntax which is valid for an authorization identity. The client is requesting that the authorization identity is derived from the authentication identity. Also, I suggest /not provided/omitted or empty/. > The server is responsible for verifying the user's > credentials and verifying that the user is able to > act as the authorization identity. s/user('s)/authentication identity('s)/. s/able/allowed/. > A SASL exchange > is successful if and only if both of these verifications > are successful. Security layer negotiation can also fail. Or something can just plain break a specification. > While SASL mechanisms specify the form of credentials > used to authenticating users and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange, the This sentence needs to be broken up. SASL mechanisms specify the form of credentials used to authenticating users, and SASL application profiles specify the form of authorization identities transferred as part of authentication exchange. However, the > precise form(s) and semantics > of the authentication identities (used > within the server in its verifications, or otherwise) > and the precise form(s) and semantics > of the authorization identities > (used in making authorization decisions, or otherwise) is > beyond the scope of the SASL and this specification. > In > some circumstances, the precise identity forms used > outside of the SASL exchange may be dictated by other > specifications. For instance, the authorization policy > specification for an application protocol may dictate the > precise form that an authorization identity is to be > represented in the authorization policy. Or the protocol profile may specify that authorization identities are to be checked e.g. in a case-insensitive manner. Finally, what is the word 'application' doing here? What is an 'application profile'? Or an 'application protocol' as opposed to a protocol'? -- Hallvard From owner-ietf-sasl Thu Oct 14 19:09:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F29P98095492; Thu, 14 Oct 2004 19:09:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F29PN9095491; Thu, 14 Oct 2004 19:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F29O3N095479 for ; Thu, 14 Oct 2004 19:09:24 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9F29RZv056489; Fri, 15 Oct 2004 02:09:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Oct 2004 19:10:17 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@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 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> 3.2 Identity Concepts > >> The client provides its credentials and, optionally, a >> string representing the requested authorization identity >> as part of the SASL exchange. > >> When this string is not >> provided, the client is requesting to act as the identity >> associated with the credentials (e.g., the user is >> requesting to act as the authentication identity). > >No, authentication identity may not even have a syntax which is valid >for an authorization identity. An identity can be represented in many different ways. Here I am using the terms "authentication identity" and "authorization identity" conceptional, and generally without regards to how they might be represented at any given time or place. When I referred to a "string representing the requested authorization identity", I referred to a particular representation of an identity. But when I said, "the client is requesting to act as the [authentication identity]", I didn't talk about how that identity would be represented. >The client is requesting that the >authorization identity is derived from the authentication identity. Conceptionally, the client is requesting the act as the identity associated with credentials. This identity might have many different representations. >Also, I suggest /not provided/omitted or empty/. > >> The server is responsible for verifying the user's >> credentials and verifying that the user is able to >> act as the authorization identity. > >s/user('s)/authentication identity('s)/. Since authentication identity is defined here as being the identity associated the credentials, would be effective saying: s/user's credentials/credentials of the identity associated with the credentials/ >s/able/allowed/. Okay. >> A SASL exchange >> is successful if and only if both of these verifications >> are successful. > >Security layer negotiation can also fail. >Or something can just plain break a specification. It may be better to reverse the statement: A SASL exchange fails if either (or both) of these verifications fails. >> While SASL mechanisms specify the form of credentials >> used to authenticating users and SASL application >> profiles specify the form of authorization identities >> transferred as part of authentication exchange, the I note that s/SASL mechanisms specify/SASL mechanism specifications describe/, s/profiles specify/profiles describe/. That is, we need to be careful not to use the term "mechanism" to refer to a mechanism's specification. >This sentence needs to be broken up. > > SASL mechanisms specify the form of credentials > used to authenticating users, and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange. > However, the Noting my above note would apply here as well, I think this suggestion is a good one. >> precise form(s) > > and semantics > >> of the authentication identities (used >> within the server in its verifications, or otherwise) >> and the precise form(s) > > and semantics I have some concern here. In particular, the mechanism specification may cover some authentication identity semantics. Or, as you note below, the application profile may detail matching semantics. I think talking adding "and semantics" will just confuse things. >> of the authorization identities >> (used in making authorization decisions, or otherwise) is >> beyond the scope of the SASL and this specification. > >> In >> some circumstances, the precise identity forms used >> outside of the SASL exchange may be dictated by other >> specifications. For instance, the authorization policy >> specification for an application protocol may dictate the >> precise form that an authorization identity is to be >> represented in the authorization policy. > >Or the protocol profile may specify that authorization identities >are to be checked e.g. in a case-insensitive manner. > >Finally, what is the word 'application' doing here? What is an >'application profile'? Or an 'application protocol' as opposed to a >protocol'? I mean application-level protocol. I generally find the bare use of the term 'protocol' to be somewhat unclear. I rather quality the term with 'application-level'. However, that likely should be done consistently or not at all. From owner-ietf-sasl Fri Oct 15 02:21:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F9Le8k036264; Fri, 15 Oct 2004 02:21:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F9Lei4036263; Fri, 15 Oct 2004 02:21:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F9LcvC036238 for ; Fri, 15 Oct 2004 02:21:39 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 15 Oct 2004 10:21:35 +0100 Message-ID: <416F969D.3060703@isode.com> Date: Fri, 15 Oct 2004 10:21:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D635D.4090105@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050904030104050703090604" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------050904030104050703090604 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>> Made requirement to verify that an authorization identity is correct >>> by performing SASLprep a SHOULD, instead of a MUST. >>> >>> >>I've changed this to: >> >> Made requirement to verify that an authorization identity is correct >> by performing SASLprep. >> >>Is this better? >> >> > >No, because it's not a requirement:-) > Fine, but see below. > Anyway, I think this paragraph can >simply be deleted, since it's just part of the 'I-D revision history'. >The appendix already covers SASLprep as RFC history: > > Added text about SASLprep for authentication identities and > passwords. Described where SASLprep preparation should take place. > > This doesn't cover authorization identities. --------------050904030104050703090604 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
Alexey Melnikov writes:
  
  Made requirement to verify that an authorization identity is correct
  by performing SASLprep a SHOULD, instead of a MUST.
      
I've changed this to:

   Made requirement to verify that an authorization identity is correct
   by performing SASLprep.

Is this better?
    

No, because it's not a requirement:-)
Fine, but see below.
 Anyway, I think this paragraph can
simply be deleted, since it's just part of the 'I-D revision history'.
The appendix already covers SASLprep as RFC history:

   Added text about SASLprep for authentication identities and
   passwords.  Described where SASLprep preparation should take place.
This doesn't cover authorization identities.

--------------050904030104050703090604-- From owner-ietf-sasl Thu Oct 21 05:26:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LCQ2sT067990; Thu, 21 Oct 2004 05:26:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LCQ29Z067989; Thu, 21 Oct 2004 05:26:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LCQ0s6067948 for ; Thu, 21 Oct 2004 05:26:01 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 13:25:45 +0100 Message-ID: <4177AAC9.8080606@isode.com> Date: Thu, 21 Oct 2004 13:25:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: Some editorial changes to RFC2222bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard has suggested to change "mechanism specific"/"protocol specific" to "mechanism-specific"/"protocol-specific". If you have any opinion on this (or maybe you know what is the right way), please let me know by the end of Friday. Alexey From owner-ietf-sasl Thu Oct 21 06:39:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDdjdi085938; Thu, 21 Oct 2004 06:39:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDdjNN085937; Thu, 21 Oct 2004 06:39:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDdhSc085902 for ; Thu, 21 Oct 2004 06:39:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CKdAK-0005cO-Pi; Thu, 21 Oct 2004 15:39:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKdA9-0003jR-OV; Thu, 21 Oct 2004 15:39:29 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKdA9-0006Eb-00; Thu, 21 Oct 2004 15:39:29 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis In-Reply-To: <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 15:39:29 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry about the late replies; I thought I had addressed this. Kurt D. Zeilenga writes: >At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>> 3.2 Identity Concepts >> >>> The client provides its credentials and, optionally, a >>> string representing the requested authorization identity >>> as part of the SASL exchange. >> >>> When this string is not >>> provided, the client is requesting to act as the identity >>> associated with the credentials (e.g., the user is >>> requesting to act as the authentication identity). >> >>No, authentication identity may not even have a syntax which is valid >>for an authorization identity. > > An identity can be represented in many different ways. > Here I am using the terms "authentication identity" > and "authorization identity" conceptional, and > generally without regards to how they might be represented > at any given time or place. When I referred to a "string > representing the requested authorization identity", I > referred to a particular representation of an identity. > But when I said, "the client is requesting to act as the > [authentication identity]", I didn't talk about how that > identity would be represented. > >>The client is requesting that the >>authorization identity is derived from the authentication identity. > > Conceptionally, the client is requesting the act as the > identity associated with credentials. This identity > might have many different representations. I hadn't quite caught on to the 'conceptual' part, but it seems rather confusing to have the same names for 'conceptual' and 'represented' identities. But even so, authorization identities and authentication identities seem to me to be 'conceptually' different types of entities; defined by different standards and used in different ways. So whether we talk of conceptual or represented identities, I'd still prefer to say that the authorization id is derived from the authentication id rather than it is the authentication id. >>Also, I suggest /not provided/omitted or empty/. >> >>> The server is responsible for verifying the user's >>> credentials and verifying that the user is able to >>> act as the authorization identity. >> >>s/user('s)/authentication identity('s)/. > > Since authentication identity is defined here as > being the identity associated the credentials, would > be effective saying: > s/user's credentials/credentials of the identity > associated with the credentials/ Well, I'd still like to get rid of that 'user'. 'User' is used elsewhere as merely one kind of identity. Maybe s/user's credentials/presented credentials/, or s/users's credentials/credentials/, s/user/authentication identity/? >>> A SASL exchange >>> is successful if and only if both of these verifications >>> are successful. >> >>Security layer negotiation can also fail. >>Or something can just plain break a specification. > > It may be better to reverse the statement: > A SASL exchange fails if either (or both) of these > verifications fails. Yes. >> However, the > > Noting my above note would apply here as well, I think > this suggestion is a good one. > >>> precise form(s) >> >> and semantics >> >>> of the authentication identities (used >>> within the server in its verifications, or otherwise) >>> and the precise form(s) >> >> and semantics > > I have some concern here. In particular, the mechanism > specification may cover some authentication identity > semantics. Or, as you note below, the application > profile may detail matching semantics. I think talking > adding "and semantics" will just confuse things. Well, what I wanted to address was what I mentioned in my original review: > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. That's a bit misleading from the protocol's point of view. From discussions elsewhere I gather the protocol may normalize the ID as it pleases for its own use, including when it locates the server-side secret matching the authentication ID, as long as this does not affect the ID which the authentication mechanism sees. Your text doesn't seem to be clear on that. >>> In >>> some circumstances, the precise identity forms used >>> outside of the SASL exchange may be dictated by other >>> specifications. For instance, the authorization policy >>> specification for an application protocol may dictate the >>> precise form that an authorization identity is to be >>> represented in the authorization policy. >> >>Or the protocol profile may specify that authorization identities >>are to be checked e.g. in a case-insensitive manner. >> >>Finally, what is the word 'application' doing here? What is an >>'application profile'? Or an 'application protocol' as opposed to a >>protocol'? > > I mean application-level protocol. I generally find the > bare use of the term 'protocol' to be somewhat unclear. > I rather quality the term with 'application-level'. However, > that likely should be done consistently or not at all. Do you mean the OSI model application layer? If so, it needs a reference to the OSI model. If not, I'm still not sure what you mean. BTW, I notice that there are several other uses of 'application' in rfc2222bis which I'm not quite sure of, now that it's bought up. Also, I would have thought SASL could be used at the presentation layer as well. -- Hallvard From owner-ietf-sasl Thu Oct 21 06:44:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDi4qh087168; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDi4S9087167; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDi3KQ087142 for ; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CKdEY-00071Y-Lq; Thu, 21 Oct 2004 15:44:02 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKdEV-0004JJ-1q; Thu, 21 Oct 2004 15:43:59 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKdEU-0006Fx-00; Thu, 21 Oct 2004 15:43:58 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416CFBDA.8000707@isode.com> References: <416BFDAA.3090507@isode.com> <416CFBDA.8000707@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 15:43:58 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>>>>6.1. Client sends data first >>>>> >>>>> 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.) >>>>> >>>>> >>>>Then protocols that support an initial response must be clear on how to >>>>distinguish an absent initial response from a present but empty initial >>>>response. I expect their protocol profiles must also specify whether or >>>>not the protocol _can_ distinguish the two, so the mechanism can tell >>>>whether or not to send empty initial responses. >>>> >>>> >>> This is described in Section 4, bullet # 2. >> >>No... First, it's only a SHOULD: >> >> If the protocol allows for the initial response, the protocol profile >> SHOULD also describe how an empty initial response is encoded. >> > I've already changed SHOULD to MUST. This issue was raised during WGLC. > >>Second, if that sentence is intended to address this issue, I can think >>of two different things it can imply in order to do so. It is not at >>all clear to me that it means either: >> >>1) "If the protocol profile does not say how an initial response is >> encoded, then empty but present initial responses are not supported." >> >>2) If you s/SHOULD/MUST/: "If initial responses are supported, then it >> MUST be possible to send an empty initial response which can be >> distinguished from no initial response." > > The intention was to say #2. I am not aware of any protocol profile that > supports initial response, but doesn't allow for it being empty. Me neither, which is why I used an imaginary example. But I've just realized that your answer opens for a third possibility: Protocols that do allow empty initial responses, but not absent initial responses. (Again, an SMTP-like protocol which strips trailing whitespace could be an example.) -- Hallvard From owner-ietf-sasl Thu Oct 21 06:51:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDppbR089047; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDppMj089046; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDpo7f089039 for ; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 14:51:51 +0100 Message-ID: <4177BEF7.6050604@isode.com> Date: Thu, 21 Oct 2004 14:51:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@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: Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > > >>1) Re-keying of security layers >> >> SASL mechanisms that support re-keying SHOULD: >> - indicate that re-keying is or will be needed immediately; >> - provide re-keying messages or transparently include re-keying >> messages in the security layers; the latter can happen without >> application involvement, but only as long as the application is >> engaged in timely bidirectional exchanges with its peer. >> >>The chairs believes the WG supports addition of this text. >> > >Please also explain what 're-keying' and 'timely bidirectional >exchanges' are. > >(I'm guessing that re-keying is a SASL layer's equivalent of TLS >ciphersuite renegotiation, but I don't know. > Correct me if I am wrong, but I understand rekeying as "renegotiation of the signing/encrypting key". But I agree with you, those two terms must be explained. And I am not sure I can give a good definition for 'timely bidirectional exchange' > I don't know if I would >have thought of that if I did not know of TLS. I have no idea how a >protocol or implementation can know that a peer will be engage in >anything 'timely'. I'm not sure what exactly 'bidirectional exchanges' >are either, but from the context my guess would be that if one peer >chooses to send a message, the other is expected to notice and send a >response, and do so before sending (or also reading?) anything else on >the connection.) > > Alexey From owner-ietf-sasl Thu Oct 21 07:36:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LEaGBk001179; Thu, 21 Oct 2004 07:36:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LEaGaF001178; Thu, 21 Oct 2004 07:36:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LEaFiN001172 for ; Thu, 21 Oct 2004 07:36:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 15:36:09 +0100 Message-ID: <4177C959.2060205@isode.com> Date: Thu, 21 Oct 2004 15:36:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <6.1.2.0.0.20041001102809.04165318@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: Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > > >>At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >> >> >>>>Abstract >>>> >>>> >>>> The Simple Authentication and Security Layer (SASL) is a framework >>>> for providing authentication and data security services in >>>> connection-oriented protocols via replaceable >>>> >>>> >>>authentication >>> >>> >>The sentence might be more clear if worded: >> The Simple Authentication and Security Layer (SASL) is >> a framework for providing authentication and data security >> services via replaceable mechanisms to connection-oriented >> protocols. >> >> > >I don't think so; it looks a little strange to have the 'to...' after >the 'via...'. Maybe s/in/to/ would improve the original sentence. > >I've asked a coworker what he thought the Abstract meant: He got it more >or less right, but was somewhat vague about it and thought it was a bit >hard to get. He did not think my suggested extra words would make a >difference. > > Unless somebody objects, I am leaving the sentence as is. Alexey From owner-ietf-sasl Thu Oct 21 08:23:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFN8p7014230; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LFN8KX014229; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFN7LX014211 for ; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 16:23:08 +0100 Message-ID: <4177D45C.2050404@isode.com> Date: Thu, 21 Oct 2004 16:23:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >>3.1. Authentication protocol exchange >> >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. >> > >I don't think so. It's the protocol which conducts the _exchange_, >and (below) which transmits anything. > What about A SASL mechanism is responsible for conducting an authentication exchange. ? The mechanism is clearly "conducting" the exchange, but the protocols carries it. >[...] > >> The mechanism MUST preserve Unicode codepoint when transferring >> authorization identity (e.g. the mechanism cann't apply any form of >> normalization). >> > >The () part does not seem say the same as the preceding sentence: 'when >transferring...' sounds like only the client-side part of the mechanism >must preserve the ID, while the () sounds like the server side also must >preserve it. The text in () only talks about transfer (actually it also applies to hashing and other similar uses). For the purposes of looking up credentials, access control, etc. the server can do as it pleases. This is out of scope for SASL. Alexey From owner-ietf-sasl Thu Oct 21 08:47:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFlt1F021033; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LFltN0021032; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFlsJQ021026 for ; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 16:47:54 +0100 Message-ID: <4177DA2A.8040702@isode.com> Date: Thu, 21 Oct 2004 16:47:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >>7. The EXTERNAL mechanism >> >> The client sends a single message containing the UTF-8 encoding of >> the >> >> > >Maybe add 'requested'? > Using "requested" here is Ok, IMHO. >> authorization identity. The message may be empty. The form of the >> authorization identity is further restricted by the application-level >> protocol's SASL profile. >> >> > >s/is further/may be/. (Further restricted than what? Being empty?:-) > Ok. >Though I'd move that last sentence to the last paragraph (below) so all >handling of the authorization identity is in one place. > >These paragraphs can be shortened a bit now that 'authentication >identities' have been introduced: > > >> The server uses information, external to SASL, to determine whether >> the client is permitted to authenticate as the authorization >> identity. If the client is so authorized, the server indicates >> successful completion of the authentication exchange; otherwise the >> server indicates failure. >> >> > > The server uses information external to SASL to determine the > authentication identity and whether the authentication is to > succeed. > Although this implies the same thing (if you take into consideration implied authorization step), I would prefer the original text. > It then indicates completion or failure of the > authentication exchange. > Here is the latest text for SASL EXTERNAL. This is not exactly what you've asked, but let me know what you think: The mechanism name associated with external authentication is "EXTERNAL". The client sends a single message containing the UTF-8 encoding of the requested authorization identity. The message may be empty. The form of the authorization identity may be restricted by the application protocol's SASL profile. The server uses information, external to SASL, to determine whether the client is permitted to act as the authorization identity. (If the requested authorization identity is empty, the authorization identity is to be derived from authentication credentials which exist in the system that is providing the external authentication.) If the client is permitted to do so, the server indicates successful completion of the authentication exchange; otherwise the server indicates failure. The system providing this external information may be, for example, IPSec [IPSec] or TLS [TLS]. 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. Alexey From owner-ietf-sasl Thu Oct 21 10:22:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHMeja044404; Thu, 21 Oct 2004 10:22:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LHMeFV044403; Thu, 21 Oct 2004 10:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHMcZm044385 for ; Thu, 21 Oct 2004 10:22:39 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CKge7-0005OL-7A; Thu, 21 Oct 2004 19:22:39 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKge3-000491-M7; Thu, 21 Oct 2004 19:22:35 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKge3-0006qg-00; Thu, 21 Oct 2004 19:22:35 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description In-Reply-To: <4177DA2A.8040702@isode.com> References: <4177DA2A.8040702@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 19:22:35 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>>7. The EXTERNAL mechanism >> The server uses information external to SASL to determine the >> authentication identity and whether the authentication is to >> succeed. > > Although this implies the same thing (if you take into consideration > implied authorization step), I would prefer the original text. Well, SASL mechanisms are now supposed to set an authentication identity, but EXTERNAL in the original or in your form doesn't. (I wish I'd realized that before posting.) OTOH, mixing rfc2222's paragraph 5 (authz id) into paragraph 3 was very nice, and my text should not have lost the 'system' doing authentication. If I mix your text and mine a bit, does this cover all bases? Some system external to SASL must authenticate the client. If that succeeds, the server determines the authentication identity from information from this system. If the requested authorization identity is empty, the authorization identity is derived from the authentication identity. The server determines if the authentication identity is allowed to act as the authorization identity. Finally, it indicates completion or failure of the authentication exchange. Or replace the last sentence with If all that succeeds, the server indicates successful completion of the authentication exchange; otherwise it indicates failure. Sigh. And this started with trying to make the text _shorter_:-) -- Hallvard From owner-ietf-sasl Thu Oct 21 11:40:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LIeCsj063549; Thu, 21 Oct 2004 11:40:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LIeCgZ063548; Thu, 21 Oct 2004 11:40:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LIeAoi063515 for ; Thu, 21 Oct 2004 11:40:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LIeCZv011400; Thu, 21 Oct 2004 18:40:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021105009.030324a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 11:40:50 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@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 06:39 AM 10/21/2004, Hallvard B Furuseth wrote: >Sorry about the late replies; I thought I had addressed this. > >Kurt D. Zeilenga writes: >>At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>> 3.2 Identity Concepts >>> >>>> The client provides its credentials and, optionally, a >>>> string representing the requested authorization identity >>>> as part of the SASL exchange. >>> >>>> When this string is not >>>> provided, the client is requesting to act as the identity >>>> associated with the credentials (e.g., the user is >>>> requesting to act as the authentication identity). >>> >>>No, authentication identity may not even have a syntax which is valid >>>for an authorization identity. >> >> An identity can be represented in many different ways. >> Here I am using the terms "authentication identity" >> and "authorization identity" conceptional, and >> generally without regards to how they might be represented >> at any given time or place. When I referred to a "string >> representing the requested authorization identity", I >> referred to a particular representation of an identity. >> But when I said, "the client is requesting to act as the >> [authentication identity]", I didn't talk about how that >> identity would be represented. >> >>>The client is requesting that the >>>authorization identity is derived from the authentication identity. >> >> Conceptionally, the client is requesting the act as the >> identity associated with credentials. This identity >> might have many different representations. > >I hadn't quite caught on to the 'conceptual' part, but it seems rather >confusing to have the same names for 'conceptual' and 'represented' >identities. Would it help if the conceptional discussion was moved to the Introduction? The problem is that, in the SASL framework, no identity representation may be explicitly transferred. However, regardless of what's transferred. >But even so, authorization identities and authentication identities seem >to me to be 'conceptually' different types of entities; I disagree. An identity (authorization or authentication) refers to a human or application entity. The qualification, authorization or authentication, refers not to kind of entity, but to the usage of the identity. >defined by >different standards and used in different ways. So whether we talk of >conceptual or represented identities, I'd still prefer to say that the >authorization id is derived from the authentication id rather than it is >the authentication id. The 'derived' language is problematic. Consider the authorization identity (and when its explicitly transferred). A user wishes to act as some other user that it identifies as some particular identity. The user enters a representation of that identity to the client which then, knowing the application protocol requirements, translates the user provided identity string into form required by the application protocol specification. Then the server might take this form and translate it some other representation of the identity to make identity assumption policy decision, and then do some other translation of the representation of the identity to produce the identity representation actually used to make authorization decisions. Regardless of the identity abstraction (DN, Kerberos principle, etc.) and the encoding of values of that abstraction (LDAPDN, DER DN, GSER DN, DCE DN) used here and there, there is conceptional one authorization identity. For instance, consider an LDAP client which offers an input dialog allowing the user to input a character string representing the desired authorization identity and a indicator of the format of that string. The user inputs the string "kurt@example.com" and selects the form identifier marked "user name". The LDAP client, knowing the requirements of the LDAP's SASL profile, takes this information and constructs the string "u:kurt@example.com" and transfers it as the authorization identity string in some mechanism (say EXTERNAL). The server needs to determine whether the user associated with the credentials is authorized to act as "u:kurt@example.com", but the server's identity assumption policy subsystem happens to requires identities to represented as email addresses with the domain part in upper case. So, the server produces the string "kurt@EXAMPLE.COM" and feeds this (and other information) to the identity assumption policy subsystem. Assuming success, the server now needs to produce an representation suitable for use in making authorization decisions. That subsystem might happen to require identities to be presented as DER encoded DNs. So the server somehow produces that. And in the actual policy, maybe DNs are presented using the LDAP DN string format. That is, one identity concept in authorization identity: the identity to act as with multiple identity representations. If we were to try to name each of distinct identity representations of the authorization identities that were likely evident in any application (both client and server) use of SASL, things will get confused. Developers will start to think that the form of the identity transferred on the wire is the actual form used elsewhere and, in particular, used in making authorization decisions. That is not necessarily so. For instance, I know of no LDAP server implementation that uses the particular form of authorization identity required by LDAP SASL profile in making authorization decisions. They all map the LDAP authzId string (even if the dnAuthzid variant is used) to some other format, such as an LDAP DN string. Kurt >>>Also, I suggest /not provided/omitted or empty/. >>> >>>> The server is responsible for verifying the user's >>>> credentials and verifying that the user is able to >>>> act as the authorization identity. >>> >>>s/user('s)/authentication identity('s)/. >> >> Since authentication identity is defined here as >> being the identity associated the credentials, would >> be effective saying: >> s/user's credentials/credentials of the identity >> associated with the credentials/ > >Well, I'd still like to get rid of that 'user'. 'User' is used >elsewhere as merely one kind of identity. >Maybe s/user's credentials/presented credentials/, >or s/users's credentials/credentials/, s/user/authentication identity/? > >>>> A SASL exchange >>>> is successful if and only if both of these verifications >>>> are successful. >>> >>>Security layer negotiation can also fail. >>>Or something can just plain break a specification. >> >> It may be better to reverse the statement: >> A SASL exchange fails if either (or both) of these >> verifications fails. > >Yes. > >>> However, the >> >> Noting my above note would apply here as well, I think >> this suggestion is a good one. >> >>>> precise form(s) >>> >>> and semantics >>> >>>> of the authentication identities (used >>>> within the server in its verifications, or otherwise) >>>> and the precise form(s) >>> >>> and semantics >> >> I have some concern here. In particular, the mechanism >> specification may cover some authentication identity >> semantics. Or, as you note below, the application >> profile may detail matching semantics. I think talking >> adding "and semantics" will just confuse things. > >Well, what I wanted to address was what I mentioned in my original review: > > > Any normalization of the authentication identity is defined by a > > particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. > >Your text doesn't seem to be clear on that. > >>>> In >>>> some circumstances, the precise identity forms used >>>> outside of the SASL exchange may be dictated by other >>>> specifications. For instance, the authorization policy >>>> specification for an application protocol may dictate the >>>> precise form that an authorization identity is to be >>>> represented in the authorization policy. >>> >>>Or the protocol profile may specify that authorization identities >>>are to be checked e.g. in a case-insensitive manner. >>> >>>Finally, what is the word 'application' doing here? What is an >>>'application profile'? Or an 'application protocol' as opposed to a >>>protocol'? >> >> I mean application-level protocol. I generally find the >> bare use of the term 'protocol' to be somewhat unclear. >> I rather quality the term with 'application-level'. However, >> that likely should be done consistently or not at all. > >Do you mean the OSI model application layer? If so, it needs a >reference to the OSI model. If not, I'm still not sure what you mean. >BTW, I notice that there are several other uses of 'application' in >rfc2222bis which I'm not quite sure of, now that it's bought up. > >Also, I would have thought SASL could be used at the presentation layer >as well. > >-- >Hallvard From owner-ietf-sasl Thu Oct 21 13:10:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LKAffB085710; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LKAf3Q085709; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LKAfZd085703 for ; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LKAjZv011965; Thu, 21 Oct 2004 20:10:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021125032.03004908@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 13:11:23 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <6.1.2.0.0.20041021105009.030324a8@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:03 PM 10/21/2004, Hallvard B Furuseth wrote: >I'll be reading this - and the draft - later, but first: > >Kurt D. Zeilenga writes: >> The problem is that, in the SASL framework, no identity >> representation may be explicitly transferred. However, >> regardless of what's transferred. > >That last sentence seems to have been truncated. I think I was going to note that regardless of identity abstract (DN,Kerberos principal,other) and encoding (for DNs: RFC 2253 string, RFC 2829 authzid, DCE DN format, base64 of the DER encoding, other) used in transfer, the transferred value refers to some identity. Later, that identity may be represented using other abstractions and/or encodings. If we talk conceptually, we can say the authorization identity value input of the user, the value transferred by the SASL mechanism, the value used in determining whether the user associated with the credentials may act as specified identity, the value used in making authorization identities, and the values used in specifying identity assumption and/or authorization policies are all refer to the same identity, the identity to act as, the authorization identity. If, however, we talk in terms of how this and other identity concept is represented here and there, we'll have to come up with numerous terms and over-specify the details of identity management. Most of the details of identity management are simply beyond the scope of the SASL framework. Kurt From owner-ietf-sasl Thu Oct 21 15:26:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LMQWNM018284; Thu, 21 Oct 2004 15:26:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LMQWot018283; Thu, 21 Oct 2004 15:26:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9LMQV9i018277 for ; Thu, 21 Oct 2004 15:26:31 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa01779; 21 Oct 2004 18:25 EDT Date: Thu, 21 Oct 2004 18:25:53 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth , "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis Message-ID: <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@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 Thursday, October 21, 2004 15:39:29 +0200 Hallvard B Furuseth wrote: >>> No, authentication identity may not even have a syntax which is valid >>> for an authorization identity. >>> [...] >>> The client is requesting that the >>> authorization identity is derived from the authentication identity. >> >> Conceptionally, the client is requesting the act as the >> identity associated with credentials. This identity >> might have many different representations. > > [...] > But even so, authorization identities and authentication identities seem > to me to be 'conceptually' different types of entities; defined by > different standards and used in different ways. So whether we talk of > conceptual or represented identities, I'd still prefer to say that the > authorization id is derived from the authentication id rather than it is > the authentication id. Agree. Use the "is derived from" language; it's less likely to confuse people into thinking in terms of blindly copying strings around. >>> s/user('s)/authentication identity('s)/. >> >> Since authentication identity is defined here as >> being the identity associated the credentials, would >> be effective saying: >> s/user's credentials/credentials of the identity >> associated with the credentials/ > > Well, I'd still like to get rid of that 'user'. 'User' is used > elsewhere as merely one kind of identity. > Maybe s/user's credentials/presented credentials/, > or s/users's credentials/credentials/, s/user/authentication identity/? s/user/client/ and be done with it. > Well, what I wanted to address was what I mentioned in my original review: > > > Any normalization of the authentication identity is defined by a > > particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. > > Your text doesn't seem to be clear on that. The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism; the protocol has no say in the matter. All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent. A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID. These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy. > Do you mean the OSI model application layer? No; he's using the term in a generic sense and there does not need to be a reference to the OSI model, which in any case is only of limited use. For example, if you look, you'll find that SASL does not correspond to any layer in the OSI model. The distinction here is between SASL-using protocols (most of which are, in fact, "application" protocols in the narrower sense) as opposed to SASL itself or the underlying authentication mechanisms, all of which are also "protocols" in the generic sense. The use of the phrase "application protocol" in this sense is common in discussions about security frameworks, and should not cause confusion. In fact, I agree with Kurt that the use of the unqualified term "protocol" is confusing in this document, because in a document which defines a framework consisting of N+M+1 protocol components, the term is highly ambiguous, our definition notwithstanding. However, I also agree that we need consistent usage throughout the document. Either use "application protocol" everywhere, or not at all. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Thu Oct 21 16:13:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LNDFIm028747; Thu, 21 Oct 2004 16:13:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LNDFvc028746; Thu, 21 Oct 2004 16:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LNDEIt028739 for ; Thu, 21 Oct 2004 16:13:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LNDIZv012879; Thu, 21 Oct 2004 23:13:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 16:13:56 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: >The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism; If you were to say the syntax and semantics of any authentication identity information carried in the exchange is specified by the mechanism's specification, I would agree. But, without that qualification, I would have to disagree. For instance, an application protocol can certainly detail how authentication identities are to represented in identity-assumption policy information carried by the protocol, and associated semantics. >All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent. From the perspective of the SASL framework, yes. >A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID. Which requires may involve deriving an authentication ID from credential information. It is not appropriate to assume the particular form of authentication identity in the credentials, are the form used to establish this authorization identity. For instance, consider EXTERNAL with TLS X.509 authentication. The authentication identity might be the subject DN, or it might be viewed as being one of the altSubjNames, or something derived from this (and possible other stuff). >These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy. And possible aspects of the application-level protocol specification. For instance, it is reasonable for an application-level protocol specification to specify how mechanism-specific authentication identity forms relate to protocol-specific authentication forms, as necessary say to detail how mechanism-specific credentials (or associated policies) are to managed using the application-level protocol. Of course, an application-level protocol specification detailing such things should not unnecessarily preclude use of the mechanisms not explicitly discussed in the application-level protocol specification. Kurt From owner-ietf-sasl Fri Oct 22 06:29:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MDTtSR037202; Fri, 22 Oct 2004 06:29:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MDTt6P037201; Fri, 22 Oct 2004 06:29:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MDTsrN037168 for ; Fri, 22 Oct 2004 06:29:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 22 Oct 2004 14:29:44 +0100 Message-ID: <41790B48.5060500@isode.com> Date: Fri, 22 Oct 2004 14:29:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >> Well, what I wanted to address was what I mentioned in my original >> review: >> >> > Any normalization of the authentication identity is defined by a >> > particular SASL mechanism, the protocol profile doesn't >> influence it. >> >> That's a bit misleading from the protocol's point of view. From >> discussions elsewhere I gather the protocol may normalize the ID as it >> pleases for its own use, including when it locates the server-side >> secret matching the authentication ID, as long as this does not affect >> the ID which the authentication mechanism sees. >> >> Your text doesn't seem to be clear on that. > > The syntax and semantics of authentication ID's are determined > entirely by the authentication mechanism; the protocol has no say in > the matter. All mechanisms are protocol-independent, and all protocol > profiles are mechanism-independent. > > A particular _implementation_ must be able to perform the > authorization check (can this authid use the requested autzid) and > must be able to derive an authorization ID from an authentication ID. > These operations depend on both the mechanism and protocol profile in > use, and their details are deliberately left to the implementation and > to local policy. Do I need to change anything in the document? From owner-ietf-sasl Fri Oct 22 07:55:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MEtoix053117; Fri, 22 Oct 2004 07:55:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MEtokI053116; Fri, 22 Oct 2004 07:55:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MEtnHj053110 for ; Fri, 22 Oct 2004 07:55:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 22 Oct 2004 15:55:43 +0100 Message-ID: <41791F6F.3060802@isode.com> Date: Fri, 22 Oct 2004 15:55:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description References: <4177DA2A.8040702@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > >>Hallvard B Furuseth wrote: >> >>>>7. The EXTERNAL mechanism >>>> >>>> >>> The server uses information external to SASL to determine the >>> authentication identity and whether the authentication is to >>> succeed. >>> >>> >>Although this implies the same thing (if you take into consideration >>implied authorization step), I would prefer the original text. >> >> > >[...] > >If I mix your text and mine a bit, does this cover all bases? > > Some system external to SASL must authenticate the client. If that > succeeds, the server determines the authentication identity from > information from this system. If the requested authorization identity > is empty, the authorization identity is derived from the > authentication identity. The server determines if the authentication > identity is allowed to act as the authorization identity. Finally, it > indicates completion or failure of the authentication exchange. > >Or replace the last sentence with > > If all that succeeds, the server indicates successful completion of > the authentication exchange; otherwise it indicates failure. > That would work for me. > > Sigh. And this started with trying to make the text _shorter_:-) > It usually does :-). > > > From owner-ietf-sasl Fri Oct 22 13:57:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MKv4bb008227; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MKv49P008226; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MKv3hY008218 for ; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03522; 22 Oct 2004 16:56 EDT Date: Fri, 22 Oct 2004 16:56:52 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis Message-ID: <1128140000.1098478612@minbar.fac.cs.cmu.edu> In-Reply-To: <41790B48.5060500@isode.com> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <41790B48.5060500@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, October 22, 2004 14:29:44 +0100 Alexey Melnikov wrote: >> The syntax and semantics of authentication ID's are determined >> entirely by the authentication mechanism; the protocol has no say in >> the matter. All mechanisms are protocol-independent, and all protocol >> profiles are mechanism-independent. >> >> A particular _implementation_ must be able to perform the >> authorization check (can this authid use the requested autzid) and >> must be able to derive an authorization ID from an authentication ID. >> These operations depend on both the mechanism and protocol profile in >> use, and their details are deliberately left to the implementation and >> to local policy. > > Do I need to change anything in the document? I'll answer a narrower question... I'm not proposing any change to the document in relation to this item. I was simply trying to clarify what looked like a point of confusion in the ongoing discussion. -- Jeff From owner-ietf-sasl Sat Oct 23 13:10:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKA3LS056979; Sat, 23 Oct 2004 13:10:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKA3br056976; Sat, 23 Oct 2004 13:10:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKA13g056960 for ; Sat, 23 Oct 2004 13:10:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:09:56 +0100 Message-ID: <417A9F61.4000702@isode.com> Date: Sat, 23 Oct 2004 19:13:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>>> s/user('s)/authentication identity('s)/. >>> >>> Since authentication identity is defined here as >>> being the identity associated the credentials, would >>> be effective saying: >>> s/user's credentials/credentials of the identity >>> associated with the credentials/ >> >> Well, I'd still like to get rid of that 'user'. 'User' is used >> elsewhere as merely one kind of identity. >> Maybe s/user's credentials/presented credentials/, >> or s/users's credentials/credentials/, s/user/authentication identity/? > > s/user/client/ and be done with it. I've done the change. From owner-ietf-sasl Sat Oct 23 13:12:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKCGGA057584; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKCG6A057583; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKCFGn057574 for ; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:12:15 +0100 Message-ID: <417AB985.4090607@isode.com> Date: Sat, 23 Oct 2004 21:05:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> In-Reply-To: <417AB364.6050503@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Kurt D. Zeilenga wrote: > >> 1) Re-keying of security layers >> Nico indicated that the I-D did not discuss Re-keying of >> security layers and suggested text in this area be added. >> The WG discussed a number of specific suggestions in this >> area, with the following text being the last version >> submitted for WG consideration: >> SASL mechanisms that support re-keying SHOULD: >> - indicate that re-keying is or will be needed immediately; >> - provide re-keying messages or transparently include re-keying >> messages in the security layers; the latter can happen without >> application involvement, but only as long as the application is >> engaged in timely bidirectional exchanges with its peer. > > After rereading this text multiple times it is clear to me that either > the text is [partially] redundant, or I don't understand what it is > trying to say (or maybe both). > > 1). "indicate that re-keying is or will be needed immediately". > The first question I have after reading this sentence is "how?" > Because SASL framework doesn't have any control channel or out-of-band > mechanism, the only answer to this question is "by transparently > including re-keying messages in the security layer". But this is a > part of what the subsequent sentence is saying!? > > 2). "provide re-keying messages or transparently include re-keying > messages in the security layers;" > > I think this sentence specifies requirements on SASL APIs and I am not > sure whether RFC2222bis is the proper place for that. > > I also assume that "provide re-keying messages" is not the same thing > as "transparently include re-keying messages in the security layers". > I think the former is trying to say that the SASL API should be able > to signal to the application that rekeying is (or will be shortly) > needed, once a rekeying message is received. It also tries to say that > the application should be able to say to SASL API: "send rekeying > request now". > > The latter is trying to say that the SASL API doesn't have to expose > re-keying messages to the application, it should generate/process them > automatically. Having said that, here is a draft variant of the text I propose: A SASL mechanism supports re-keying if it is able to generate/process messages that request immediate re-keying and it is able to carry out re-keying exchange. (a single message that does both is Ok) SASL mechanisms that support re-keying MAY also be able to indicate that re-keying will be needed in the future. A re-keying exchange can be conducted transparently by the mechanism, or the mechanism should be able to provide/accept re-keying messages to/from the application. The former can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. From owner-ietf-sasl Sat Oct 23 13:10:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKAlMA057171; Sat, 23 Oct 2004 13:10:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKAlAB057170; Sat, 23 Oct 2004 13:10:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKAkUg057163 for ; Sat, 23 Oct 2004 13:10:46 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:10:42 +0100 Message-ID: <417AA29B.7010103@isode.com> Date: Sat, 23 Oct 2004 19:27:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >>[nothing in the abstract says that's the kind of mechanisms it is >>talking about.] >> > >Mechanisms provide authentication and data security services >to connection-oriented protocols through the SASL framework. > IMHO, this just follows from: The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. So I think nothing has to be added/changed. >>The same change would be nice in the Introduction section, though of >>course the diagram there helps. >> >>Personally I would also have found an asymmetric definition easier to >>relate to: SASL defines a common interface to authentication mechanisms >>for protocols. (Is that the right way to put it?) But maybe that's not >>at all the view SASL intends to convey. Is the protocol profile the >>common interface to protocols for authentication mechanisms? >> >> > >The "protocol profile" is the part of the protocol's >technical specification which details how it makes use >of the SASL framework. > > The Introduction section currently have the following paragraph: To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions. If the use of a security layer is negotiated, that security layer is inserted between the protocol and the connection. Section 4 ("Protocol profile requirements") profiles the requirements that a protocol specification must fulfill to make use of SASL. I've added the following sentence to the end: A SASL protocol profile is a part of the protocol specification that satisfies the requirements of Section 4. Comments? Alexey From owner-ietf-sasl Sat Oct 23 13:11:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKBgb3057425; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKBgPi057422; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKBfef057406 for ; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:11:39 +0100 Message-ID: <417AB364.6050503@isode.com> Date: Sat, 23 Oct 2004 20:39:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@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: >1) Re-keying of security layers > >Nico indicated that the I-D did not discuss Re-keying of >security layers and suggested text in this area be added. >The WG discussed a number of specific suggestions in this >area, with the following text being the last version >submitted for WG consideration: > SASL mechanisms that support re-keying SHOULD: > - indicate that re-keying is or will be needed immediately; > - provide re-keying messages or transparently include re-keying > messages in the security layers; the latter can happen without > application involvement, but only as long as the application is > engaged in timely bidirectional exchanges with its peer. > After rereading this text multiple times it is clear to me that either the text is [partially] redundant, or I don't understand what it is trying to say (or maybe both). 1). "indicate that re-keying is or will be needed immediately". The first question I have after reading this sentence is "how?" Because SASL framework doesn't have any control channel or out-of-band mechanism, the only answer to this question is "by transparently including re-keying messages in the security layer". But this is a part of what the subsequent sentence is saying!? 2). "provide re-keying messages or transparently include re-keying messages in the security layers;" I think this sentence specifies requirements on SASL APIs and I am not sure whether RFC2222bis is the proper place for that. I also assume that "provide re-keying messages" is not the same thing as "transparently include re-keying messages in the security layers". I think the former is trying to say that the SASL API should be able to signal to the application that rekeying is (or will be shortly) needed, once a rekeying message is received. It also tries to say that the application should be able to say to SASL API: "send rekeying request now". The latter is trying to say that the SASL API doesn't have to expose re-keying messages to the application, it should generate/process them automatically. >The chairs believes the WG supports addition of this text. > > > From owner-ietf-sasl Sat Oct 23 16:24:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NNOp0o002318; Sat, 23 Oct 2004 16:24:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NNOpWp002317; Sat, 23 Oct 2004 16:24:51 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NNOmEx002235 for ; Sat, 23 Oct 2004 16:24:49 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CLVFd-0003cz-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Making forward progress Date: Sun, 24 Oct 2004 01:24:22 +0200 Lines: 33 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:ignQ0G4Dj5sxyEDyi7FGWkbOcpg= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I've seen no objections to Kurt's new summary of the identities issue > nor to his proposed text for section 3. I raised some issues with the new summary in: http://thread.gmane.org/gmane.ietf.sasl/1687 There were additional discussion, even some disagreement on (what I perceive as) terminology issues. I proposed a change to the proposed new text, to which Kurt acknowledged that his proposed text was not a direct replacement, and that further work was needed. Has there been a more recent proposal? I cannot seem to find it. > I think we should move forward with that change. For the record, I again object to removing the paragraphs below, at this late stage. Kurt's new summary appear, to me, to propose to remove them. The paragraphs could be reworded for clarity, as they are critical in getting the boundaries between normalization procedures in an implementation. But I have yet to see any argument to why they are technically wrong, and should be removed. Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Thanks, Simon From owner-ietf-sasl Sat Oct 23 17:22:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O0Md7l014347; Sat, 23 Oct 2004 17:22:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O0MdMp014346; Sat, 23 Oct 2004 17:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O0Mc9k014336 for ; Sat, 23 Oct 2004 17:22:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9O0MVZv031144; Sun, 24 Oct 2004 00:22:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041023170532.0301e1e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 23 Oct 2004 17:23:05 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Making forward progress Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:24 PM 10/23/2004, Simon Josefsson wrote: >Sam Hartman writes: > >> I've seen no objections to Kurt's new summary of the identities issue >> nor to his proposed text for section 3. > >I raised some issues with the new summary in: > >http://thread.gmane.org/gmane.ietf.sasl/1687 > >There were additional discussion, even some disagreement on (what I >perceive as) terminology issues. I proposed a change to the proposed >new text, to which Kurt acknowledged that his proposed text was not a >direct replacement, and that further work was needed. Has there been >a more recent proposal? I cannot seem to find it. > >> I think we should move forward with that change. > >For the record, I again object to removing the paragraphs below, at >this late stage. Kurt's new summary appear, to me, to propose to >remove them. I believe I posted a clarification that it was not my intent to suggest these statements be removed. At the time I submitted the suggested text, I presumed they would placed elsewhere in the specification. At this time, I think the majority of my "identity concept" text should be placed in an introductory section. Additionally, these statements need some clarification (as I indicated in follow-ups). >The paragraphs could be reworded for clarity, as they >are critical in getting the boundaries between normalization >procedures in an implementation. But I have yet to see any argument >to why they are technically wrong, and should be removed. Because I don't believe anyone has argued that they should be removed. > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. This statement needs to be clarified. In particular, the intent here is that the mechanism specification is solely responsible for stating how any authentication identity information is transferred as part of the exchange. However, the mechanism specification does not necessarily have any responsibility for stating how authentication identity information is represented elsewhere. For instance, an application protocol specification is free to define how authentication identities appearing in an identity-assumption policy statement are to be normalized. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). > >Thanks, >Simon From owner-ietf-sasl Sun Oct 24 06:18:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODIi6j085960; Sun, 24 Oct 2004 06:18:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ODIict085959; Sun, 24 Oct 2004 06:18:44 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODIe4F085947 for ; Sun, 24 Oct 2004 06:18:41 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CLiGn-0000WE-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Making forward progress Date: Sun, 24 Oct 2004 15:18:22 +0200 Lines: 41 Message-ID: References: <6.1.2.0.0.20041023170532.0301e1e0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:JfSljjmgLX14oVcphSilJMk1kXg= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:24 PM 10/23/2004, Simon Josefsson wrote: > >>Sam Hartman writes: >> >>> I've seen no objections to Kurt's new summary of the identities issue >>> nor to his proposed text for section 3. >> >>I raised some issues with the new summary in: >> >>http://thread.gmane.org/gmane.ietf.sasl/1687 >> >>There were additional discussion, even some disagreement on (what I >>perceive as) terminology issues. I proposed a change to the proposed >>new text, to which Kurt acknowledged that his proposed text was not a >>direct replacement, and that further work was needed. Has there been >>a more recent proposal? I cannot seem to find it. >> >>> I think we should move forward with that change. >> >>For the record, I again object to removing the paragraphs below, at >>this late stage. Kurt's new summary appear, to me, to propose to >>remove them. > > I believe I posted a clarification that it was not my intent > to suggest these statements be removed. At the time I > submitted the suggested text, I presumed they would placed > elsewhere in the specification. > > At this time, I think the majority of my "identity concept" > text should be placed in an introductory section. > > Additionally, these statements need some clarification > (as I indicated in follow-ups). Thanks. I was confused by the resolution to move forward with a change that had not yet been fleshed out. Regards, Simon From owner-ietf-sasl Sun Oct 24 06:53:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODrpTm093075; Sun, 24 Oct 2004 06:53:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ODrpa2093074; Sun, 24 Oct 2004 06:53:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODrorb093068 for ; Sun, 24 Oct 2004 06:53:50 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 24 Oct 2004 14:53:52 +0100 Message-ID: <417ACB03.4090302@isode.com> Date: Sat, 23 Oct 2004 22:20:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Sam Hartman , SASL WG Subject: Life of a security layer and error handling (was Re: Summary of 2222bis WGLC) References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041021182216.030c5238@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: [I am CCing my reply to the mailing list as discuss. I believe I've quoted enough context.] Kurt D. Zeilenga wrote: >> >>> 2). The following text is in the Security Considerations >> >>> section (as per off the list discussion with Nico): >> >>> >> >>> The secure or administratively permitted lifetimes of SASL >> >>> mechanisms' security layers are finite. Cryptographic keys >> >>> weaken as they are used and as time passes; the more time >> >>> and/or ciphertext that a cryptanalyst has after the first use >> >>> of the a key, the easier it is for the cryptanalyst to mount >> >>> attacks on the key. >> >>> >> >>> Administrative limits on security layers lifetime may take the >> >>> form of time limits expressed in x.509 certificates, Kerberos >> >>> V tickets, or in directories, and are often desired. >> >>> >> >>> In practice one likely effect of administrative security >> >>> layers lifetime limits is that applications may find that >> >>> security layers stop working in the middle of application >> >>> protocol operation, such as, perhaps, during large data >> >>> transfers. >> >>> >> >>> SASL does not provide for re-keying. SASL mechanisms may; all >> >>> future SASL mechanisms that provide security layers SHOULD >> >>> provide for re-keying. >> >>> >> >> See above comments regarding this recommendation. >> >> >> Alexey> You have to be more specific than that. I think the first >> Alexey> paragraph should stay, as it explains why rekeying is >> Alexey> needed. It should probably be reworded to state this >> Alexey> explicitly. I think the second paragraph should stay as >> Alexey> well, although I am not so sure. The third paragraph >> Alexey> should be dropped. The last paragraph should stay, >> Alexey> although it will have to be reworded (and maybe drop >> Alexey> SHOULD?). >> >>What's wrong with the third paragraph? It does tell you the >>application writer that life may be annoying, but I believe that is a >>practical statement of reality. >> > >A problem I see with the third paragraph is that it attempts to >redefine the lifetime of the layer. A layers life lasts until >either a) a new layer is installed or b) the connection closes. >There no way that a layer's life can end otherwise. If the >mechanism is no longer able to generate buffers, the connection >must be closed. It is impossible to re-key or to install a new >layer without generating buffers to accomplish that re-keying >or installation. > >This should be made clear in the document. I agree. Section 3.3 had the following sentence: 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)). I've added "or underlying connection is closed" to the text in the parentheses. >>I hope to convince mechanism designers/implementers not to have mechanisms fail mid transfer, but some mechanisms today do fail that way. >> > >SASL doesn't allow anything else. If the mechanism is not >able to produce a buffer, the connection must be closed. >That can happen anywhere within the application protocol >stream. > >This should be made clear as well. If the mechanism layer >failure results in termination of the connection. While at >the protocol and SASL layers, that termination is abrupt, >implementations should attempt to gracefully close lower >level layers (such as TLS and TCP). > Agreed. I've changed the existing text in 3.3: Once the security layer is in effect the protocol stream is processed by the security layer into buffers of protected data. Each buffer of protected 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. To: Once the security layer is in effect the protocol stream is processed by the security layer into buffers of protected data. If the security layer is not able to produce a buffer, the connection MUST be closed. If the security layer is not able to decode a received buffer, the connection MUST be closed. In both cases the underlying connection SHOULD be closed gracefully. (Inserted 3 sentences here and broke the paragraph into 2). Each buffer of protected 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 buffer. ... (I've dropped the word "following" in the last sentence.) Alexey From owner-ietf-sasl Sun Oct 24 09:16:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OGG3rL026099; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OGG34p026098; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OGG2Ip026092 for ; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id B6FEE16004F; Sun, 24 Oct 2004 12:16:19 -0400 (EDT) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> From: Sam Hartman Date: Sun, 24 Oct 2004 12:16:19 -0400 In-Reply-To: <417ACB03.4090302@isode.com> (Alexey Melnikov's message of "Sat, 23 Oct 2004 22:20:03 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: OK. My interpretation of the third paragraph was that it was saying that a layer might force a connection close. From owner-ietf-sasl Sun Oct 24 14:02:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL2jF3088449; Sun, 24 Oct 2004 14:02:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OL2j9x088448; Sun, 24 Oct 2004 14:02:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL2gqV088439 for ; Sun, 24 Oct 2004 14:02:42 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 5B687E0053; Sun, 24 Oct 2004 17:03:03 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Making forward progress References: From: Sam Hartman Date: Sun, 24 Oct 2004 17:03:03 -0400 In-Reply-To: (Simon Josefsson's message of "Sun, 24 Oct 2004 01:24:22 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> Sam Hartman writes: >> I've seen no objections to Kurt's new summary of the identities >> issue nor to his proposed text for section 3. Simon> I raised some issues with the new summary in: Simon> http://thread.gmane.org/gmane.ietf.sasl/1687 Sorry I was not clear on this. I believed you and Kurt were agreeing with each othe; I still believe that is true after reading the exchange again. --Sam From owner-ietf-sasl Sun Oct 24 14:09:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL9gu7089934; Sun, 24 Oct 2004 14:09:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OL9gat089933; Sun, 24 Oct 2004 14:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL9fdY089924 for ; Sun, 24 Oct 2004 14:09:41 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9OL9mui018443 for ; Sun, 24 Oct 2004 15:09:54 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9OL9mjW009459 for ; Sun, 24 Oct 2004 15:09:48 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9OL9T5i018988; Sun, 24 Oct 2004 16:09:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9OL9OO7018987; Sun, 24 Oct 2004 16:09:24 -0500 (CDT) Date: Sun, 24 Oct 2004 16:09:24 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Sam Hartman , SASL WG Subject: Re: Life of a security layer and error handling (was Re: Summary of 2222bis WGLC) Message-ID: <20041024210924.GF21427@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , "Kurt D. Zeilenga" , Sam Hartman , SASL WG References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417ACB03.4090302@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Where does this leave us w.r.t. re-keying? Will it be possible for future mechanisms or extensions to existing ones to provide for something better than this? Should existing mechanisms' layers expire when the session key material's useful lifetime (in terms of time or use) is exceeded? IMO, SASL must at least point out the key expiration problem and should allow for future mechs/extensions that provide for re-keying. Nico -- From owner-ietf-sasl Sun Oct 24 14:12:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLCugb090536; Sun, 24 Oct 2004 14:12:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLCuI5090535; Sun, 24 Oct 2004 14:12:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLCtDJ090528 for ; Sun, 24 Oct 2004 14:12:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0155AE0053; Sun, 24 Oct 2004 17:13:15 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> From: Sam Hartman Date: Sun, 24 Oct 2004 17:13:15 -0400 In-Reply-To: <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> (Kurt D. Zeilenga's message of "Thu, 21 Oct 2004 16:13:56 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: >> The syntax and semantics of authentication ID's are determined >> entirely by the authentication mechanism; Kurt> If you were to say the syntax and semantics of any Kurt> authentication identity information carried in the exchange Kurt> is specified by the mechanism's specification, I would Kurt> agree. Kurt> But, without that qualification, I would have to disagree. Kurt> For instance, an application protocol can certainly detail Kurt> how authentication identities are to represented in Kurt> identity-assumption policy information carried by the Kurt> protocol, and associated semantics. I agree that they can do so in the sense that if the IESG approved it, it would be a protocol action. Application protocols should not say anything about authentication identities though, because doing so would tie them to a particular mechanism. From owner-ietf-sasl Sun Oct 24 14:17:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLHfqG091657; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLHfnV091656; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLHfJP091650 for ; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9OLHr7q022562 for ; Sun, 24 Oct 2004 14:17:53 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9OLHrjW012122 for ; Sun, 24 Oct 2004 15:17:53 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9OLHYiN018998; Sun, 24 Oct 2004 16:17:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9OLHYcp018997; Sun, 24 Oct 2004 16:17:34 -0500 (CDT) Date: Sun, 24 Oct 2004 16:17:34 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC Message-ID: <20041024211734.GG21427@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417AB364.6050503@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote: > > Kurt D. Zeilenga wrote: > > >1) Re-keying of security layers > > > >Nico indicated that the I-D did not discuss Re-keying of > >security layers and suggested text in this area be added. > >The WG discussed a number of specific suggestions in this > >area, with the following text being the last version > >submitted for WG consideration: > > SASL mechanisms that support re-keying SHOULD: > > - indicate that re-keying is or will be needed immediately; > > - provide re-keying messages or transparently include re-keying > > messages in the security layers; the latter can happen without > > application involvement, but only as long as the application is > > engaged in timely bidirectional exchanges with its peer. > > > After rereading this text multiple times it is clear to me that either > the text is [partially] redundant, or I don't understand what it is > trying to say (or maybe both). > > 1). "indicate that re-keying is or will be needed immediately". > The first question I have after reading this sentence is "how?" Because > SASL framework doesn't have any control channel or out-of-band > mechanism, the only answer to this question is "by transparently > including re-keying messages in the security layer". But this is a part > of what the subsequent sentence is saying!? See below. > 2). "provide re-keying messages or transparently include re-keying > messages in the security layers;" > > I think this sentence specifies requirements on SASL APIs and I am not > sure whether RFC2222bis is the proper place for that. The answer is: by providing interfaces for the purpose of indicating key layer expiration and providing for re-key message exchanges (where mechs support it). Layer expiration, for existing mechs, should be advisory only; for new mechs I think we should insist that it be mandatory. Whether you like it or not it is possible to derive an abstract API from a protocol specification, at least a sufficiently complete and unambiguous spec :) IMO abstract API requirements/recommendations are more than Ok to include in rfc2222bis. The key word there is "abstract." > I also assume that "provide re-keying messages" is not the same thing as > "transparently include re-keying messages in the security layers". Correct. I'm not sure that any existing mechs could do either, but new mechs should definitely provide for the former. > I think the former is trying to say that the SASL API should be able to > signal to the application that rekeying is (or will be shortly) needed, > once a rekeying message is received. It also tries to say that the > application should be able to say to SASL API: "send rekeying request now". Yes. > The latter is trying to say that the SASL API doesn't have to expose > re-keying messages to the application, it should generate/process them > automatically. Yes. This approach is less than ideal. IIRC Sam favors it, at least in that it may be workable in some cases that we care about. Cheers, Nico -- From owner-ietf-sasl Sun Oct 24 14:20:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLKvMS092400; Sun, 24 Oct 2004 14:20:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLKvvU092399; Sun, 24 Oct 2004 14:20:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLKuNP092392 for ; Sun, 24 Oct 2004 14:20:56 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id B5EF9E0053; Sun, 24 Oct 2004 17:21:17 -0400 (EDT) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> From: Sam Hartman Date: Sun, 24 Oct 2004 17:21:17 -0400 In-Reply-To: <20041024210924.GF21427@binky.central.sun.com> (Nicolas Williams's message of "Sun, 24 Oct 2004 16:09:24 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Where does this leave us w.r.t. re-keying? Will it be Nicolas> possible for future mechanisms or extensions to existing Nicolas> ones to provide for something better than this? Yes. If you believe the text does not support future work in this direction please describe. Nicolas> Should Nicolas> existing mechanisms' layers expire when the session key Nicolas> material's useful lifetime (in terms of time or use) is Nicolas> exceeded? I believe that SASL mechanisms should try to avoid expiring the connection when key lifetime is exceeded because doing so creates an unacceptable user experience. There exist mechanisms that will expire though like some implementations of the GSSAPI mechanism. From owner-ietf-sasl Sun Oct 24 18:11:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P1Axpp043068; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P1AxZY043067; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P1Axep043061 for ; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9P1BDNH022514 for ; Sun, 24 Oct 2004 19:11:13 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P1BCjW009414 for ; Sun, 24 Oct 2004 19:11:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9P1Ar12019092 for ; Sun, 24 Oct 2004 20:10:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9P1ArX5019091 for ietf-sasl@imc.org; Sun, 24 Oct 2004 20:10:53 -0500 (CDT) Date: Sun, 24 Oct 2004 20:10:53 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC Message-ID: <20041025011053.GD19142@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041024211734.GG21427@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Oct 24, 2004 at 04:17:34PM -0500, Nicolas Williams wrote: > The answer is: by providing interfaces for the purpose of indicating key > layer expiration and providing for re-key message exchanges (where mechs > support it). Layer expiration, for existing mechs, should be advisory > only; for new mechs I think we should insist that it be mandatory. And, of course, the GSS-API does not provide [yet] for advisory security context expiration, so neither can SASL GSS mechanisms [yet]. It'd be a shame to add advisory security context expiration to the GSS-APIv3 work at KITTEN just for SASL, but perhaps we should. Also, there is a mitigation for this problem: use ciphers that don't require re-keying :) (I'm thinking AES-256 in some counter mode). Nico -- From owner-ietf-sasl Sun Oct 24 19:15:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2FVh5055991; Sun, 24 Oct 2004 19:15:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P2FVYm055990; Sun, 24 Oct 2004 19:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2FUmm055982 for ; Sun, 24 Oct 2004 19:15:30 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9P2FeZv039243; Mon, 25 Oct 2004 02:15:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 24 Oct 2004 19:16:13 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@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 02:13 PM 10/24/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: > >> The syntax and semantics of authentication ID's are determined > >> entirely by the authentication mechanism; > > Kurt> If you were to say the syntax and semantics of any > Kurt> authentication identity information carried in the exchange > Kurt> is specified by the mechanism's specification, I would > Kurt> agree. > > Kurt> But, without that qualification, I would have to disagree. > Kurt> For instance, an application protocol can certainly detail > Kurt> how authentication identities are to represented in > Kurt> identity-assumption policy information carried by the > Kurt> protocol, and associated semantics. > >I agree that they can do so in the sense that if the IESG approved it, >it would be a protocol action. LDAP and IMAP ACLs. What's good is a standardize access control policy if the standard does say how identities used in the authentication exchange relate to identities appearing in the policy? Say an administrative client has created a Kerberos principal for a user and then wants to authorize that user to access an object on an LDAP server. What DN should the administrative client use as the subject of the LDAP access control statement? Without a standard of some kind here, it is not possible to independently develop such a client. >Application protocols should not say >anything about authentication identities though, because doing so >would tie them to a particular mechanism. No, it would require an update of the application protocol specification to state how to manage identities associated with that particular mechanism relate to identities in the application protocol. (This doesn't mean that one cannot use new mechanisms in the protocol in absence of this update, it says that one cannot use certain policy features of that mechanism until its updated to deal with the new mechanism.) Kurt From owner-ietf-sasl Sun Oct 24 19:39:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2dWuw060814; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P2dW7s060813; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2dWt6060807 for ; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9P2dkZv039378; Mon, 25 Oct 2004 02:39:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 24 Oct 2004 19:40:18 -0700 To: Nicolas Williams From: "Kurt D. Zeilenga" Subject: Re: Summary of 2222bis WGLC Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <20041024211734.GG21427@binky.central.sun.com> References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.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: My view on re-keying is that its just another layer security service that a mechanism can offer. In regards to the SASL framework specification, how it does so (on the wire) is something for the mechanism specification to detail. And how an developer of an application protocol provides support for this mechanism is an implementation detail. The framework simply should not concern itself with such details. The design of any SASL API is limited by which mechanism aspects and protocol aspects which were accounted for in the design. If a new mechanism has aspects not previously considered by designers of a particular SASL API, then the designers of that SASL API might want to redesign their API to account for the new aspect... or decide that they simply cannot support that mechanism (or aspect of that mechanism). While we could constraint future mechanisms to currently known aspects, I think that's unwise and counter to character of SASL. At 02:17 PM 10/24/2004, Nicolas Williams wrote: >On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote: >> >> Kurt D. Zeilenga wrote: >> >> >1) Re-keying of security layers >> > >> >Nico indicated that the I-D did not discuss Re-keying of >> >security layers and suggested text in this area be added. >> >The WG discussed a number of specific suggestions in this >> >area, with the following text being the last version >> >submitted for WG consideration: >> > SASL mechanisms that support re-keying SHOULD: >> > - indicate that re-keying is or will be needed immediately; >> > - provide re-keying messages or transparently include re-keying >> > messages in the security layers; the latter can happen without >> > application involvement, but only as long as the application is >> > engaged in timely bidirectional exchanges with its peer. >> > >> After rereading this text multiple times it is clear to me that either >> the text is [partially] redundant, or I don't understand what it is >> trying to say (or maybe both). >> >> 1). "indicate that re-keying is or will be needed immediately". >> The first question I have after reading this sentence is "how?" Because >> SASL framework doesn't have any control channel or out-of-band >> mechanism, the only answer to this question is "by transparently >> including re-keying messages in the security layer". But this is a part >> of what the subsequent sentence is saying!? > >See below. > >> 2). "provide re-keying messages or transparently include re-keying >> messages in the security layers;" >> >> I think this sentence specifies requirements on SASL APIs and I am not >> sure whether RFC2222bis is the proper place for that. > >The answer is: by providing interfaces for the purpose of indicating key >layer expiration and providing for re-key message exchanges (where mechs >support it). Layer expiration, for existing mechs, should be advisory >only; for new mechs I think we should insist that it be mandatory. > >Whether you like it or not it is possible to derive an abstract API from >a protocol specification, at least a sufficiently complete and >unambiguous spec :) > >IMO abstract API requirements/recommendations are more than Ok to >include in rfc2222bis. The key word there is "abstract." > >> I also assume that "provide re-keying messages" is not the same thing as >> "transparently include re-keying messages in the security layers". > >Correct. I'm not sure that any existing mechs could do either, but new >mechs should definitely provide for the former. > >> I think the former is trying to say that the SASL API should be able to >> signal to the application that rekeying is (or will be shortly) needed, >> once a rekeying message is received. It also tries to say that the >> application should be able to say to SASL API: "send rekeying request now". > >Yes. > >> The latter is trying to say that the SASL API doesn't have to expose >> re-keying messages to the application, it should generate/process them >> automatically. > >Yes. This approach is less than ideal. IIRC Sam favors it, at least in >that it may be workable in some cases that we care about. > >Cheers, > >Nico >-- From owner-ietf-sasl Mon Oct 25 03:26:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAQjLN004437; Mon, 25 Oct 2004 03:26:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PAQjVJ004435; Mon, 25 Oct 2004 03:26:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAQiJB004363 for ; Mon, 25 Oct 2004 03:26:44 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 11:26:32 +0100 Message-ID: <417CD4D7.1050406@isode.com> Date: Mon, 25 Oct 2004 11:26:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Nicolas> Should > Nicolas> existing mechanisms' layers expire when the session key > Nicolas> material's useful lifetime (in terms of time or use) is > Nicolas> exceeded? > >I believe that SASL mechanisms should try to avoid expiring the >connection when key lifetime is exceeded because doing so creates an >unacceptable user experience. > I concur. > There exist mechanisms that will expire >though like some implementations of the GSSAPI mechanism. > > Are we talking about GSSAPI in general or a particular implementation of GSSAPI? Imagine that support for re-keying can be done without changing (extending) GSS API. In this case the SASL GSSAPI spec doesn't have to be updated. In which case the following text can be removed from 2222bis: In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. ? (or at least it has to be reworded to talk about "broken" or "old" implementations) Alexey From owner-ietf-sasl Mon Oct 25 03:39:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAdJ3f009184; Mon, 25 Oct 2004 03:39:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PAdJUn009183; Mon, 25 Oct 2004 03:39:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAdIcC009169 for ; Mon, 25 Oct 2004 03:39:18 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 11:39:18 +0100 Message-ID: <417CD7D6.70804@isode.com> Date: Mon, 25 Oct 2004 11:39:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: SASL WG Subject: Re-keying (was Re: Life of a security layer and error handling) References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> In-Reply-To: <417CD4D7.1050406@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Sam Hartman wrote: > >> Nicolas> Should >> Nicolas> existing mechanisms' layers expire when the session key >> Nicolas> material's useful lifetime (in terms of time or use) is >> Nicolas> exceeded? >> >> I believe that SASL mechanisms should try to avoid expiring the >> connection when key lifetime is exceeded because doing so creates an >> unacceptable user experience. > > I concur. > >> There exist mechanisms that will expire >> though like some implementations of the GSSAPI mechanism. > > Are we talking about GSSAPI in general or a particular implementation > of GSSAPI? > > Imagine that support for re-keying can be done without changing > (extending) GSS API. In this case the SASL GSSAPI spec doesn't have to > be updated. > In which case the following text can be removed from 2222bis: > > In practice one likely effect of administrative security layers > lifetime limits is that applications may find that security layers > stop working in the middle of application protocol operation, such > as, perhaps, during large data transfers. > > ? > (or at least it has to be reworded to talk about "broken" or "old" > implementations) I've kept the paragraph for now, here is the latest text about re-keying in Security considerations (as there is very little time before the draft submission deadline, I am going to send the updated 2222bis now): The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. Cryptographic keys weaken as they are used and as time passes; the more time and/or ciphertext that a cryptanalyst has after the first use of the a key, the easier it is for the cryptanalyst to mount attacks on the key. Administrative limits on security layers lifetime may take the form of time limits expressed in x.509 certificates, Kerberos V tickets, or in directories, and are often desired. In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. As the result of this the connection will be closed (see section 3.3), which will result in unpleasant user experience. Re-keying (key renegotiation process) is a way of addressing the weakening of cryptographic keys. SASL framework does not provide for re-keying. SASL mechanisms may; all future SASL mechanisms that provide security layers should provide for re-keying. Applications that wish to re-key SASL security layers where the mechanism does not provide for re-keying should reauthenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for re-keying in the application protocols. See section 6.3. Alexey From owner-ietf-sasl Mon Oct 25 04:18:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PBIGXM025152; Mon, 25 Oct 2004 04:18:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PBIGVe025150; Mon, 25 Oct 2004 04:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PBICIq025112 for ; Mon, 25 Oct 2004 04:18:12 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 12:17:55 +0100 Message-ID: <417CE0E3.2080401@isode.com> Date: Mon, 25 Oct 2004 12:17:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041001155050.0417fbc0@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: >>For comparison, here is part of the old text: >> >> Any normalization of the authentication identity is defined by a >> particular SASL mechanism, the protocol profile doesn't influence it. >> >> > >Though I think this needs to be slightly reworded, I agree >with the intent of the statement to say that protocol >profiles should leave of aspects of credentials and their >verification to the mechanism. However, this in no way >implies that an application protocol specification, or >its implementations, cannot detail the form of authentication >identity the application protocol (or implementation) might >use otherwise. For instance, an application protocol >specification could detail how to represent authentication >identities in an identity assumption authorization policy. > > I've updated the existing sentence as follows (I am still not satisfied with how it looks): Any normalization of the authentication identity (for the purposes of conducting authentication exchange) is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Note, that the mechanism specification doesn't control how authentication identity information is represented elsewhere. I think we need to expand on "elsewhere" part. From owner-ietf-sasl Mon Oct 25 06:24:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDOqb3038457; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDOqZ3038456; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDOqhO038450 for ; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 45AF17681D; Mon, 25 Oct 2004 09:24:48 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> From: Sam Hartman Date: Mon, 25 Oct 2004 09:24:47 -0400 In-Reply-To: <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 24 Oct 2004 19:16:13 -0700") Message-ID: <87lldv9bhc.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: >> Kurt> But, without that qualification, I would have to disagree. Kurt> For instance, an application protocol can certainly detail Kurt> how authentication identities are to represented in Kurt> identity-assumption policy information carried by the Kurt> protocol, and associated semantics. >> I agree that they can do so in the sense that if the IESG >> approved it, it would be a protocol action. Kurt> LDAP and IMAP ACLs. Kurt> What's good is a standardize access control policy if the Kurt> standard does say how identities used in the authentication Kurt> exchange relate to identities appearing in the policy? Kurt> Say an administrative client has created a Kerberos Kurt> principal for a user and then wants to authorize that user Kurt> to access an object on an LDAP server. What DN should the Kurt> administrative client use as the subject of the LDAP access Kurt> control statement? I was thinking too narrowly. --Sam From owner-ietf-sasl Mon Oct 25 06:21:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDLCqk038129; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDLCeh038128; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDLBpG038120 for ; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 0014C7681D; Mon, 25 Oct 2004 09:21:01 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> From: Sam Hartman Date: Mon, 25 Oct 2004 09:21:01 -0400 In-Reply-To: <417CD4D7.1050406@isode.com> (Alexey Melnikov's message of "Mon, 25 Oct 2004 11:26:31 +0100") Message-ID: <87pt379bnm.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Sam Hartman wrote: Nicolas> Should existing mechanisms' layers expire when the Nicolas> session key material's useful lifetime (in terms of time Nicolas> or use) is exceeded? >> I believe that SASL mechanisms should try to avoid expiring >> the connection when key lifetime is exceeded because doing so >> creates an unacceptable user experience. >> Alexey> I concur. >> There exist mechanisms that will expire though like some >> implementations of the GSSAPI mechanism. >> >> Alexey> Are we talking about GSSAPI in general or a particular Alexey> implementation of GSSAPI? We're talking about RFC 1964 and most implementations of that spec. Alexey> Imagine that support for re-keying can be done without Alexey> changing (extending) GSS API. I did. Unfortunately, Nico convinced me that my fantasy had no basis in reality. You cannot guarantee that both parties are sending, which is required for rekeying. ALso, you have bad interactions with gss_wrap_size_limit. Alexey> In this case the SASL GSSAPI Alexey> spec doesn't have to be updated. In which case the Alexey> following text can be removed from 2222bis: Alexey> In practice one likely effect of administrative security Alexey> layers lifetime limits is that applications may find that Alexey> security layers stop working in the middle of application Alexey> protocol operation, such as, perhaps, during large data Alexey> transfers. I agree that implementations that work this way are broken. Nico does not. Nor does the IETF; RFC 1964 mandates this behavior. --Sam From owner-ietf-sasl Mon Oct 25 06:37:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDbFGf039596; Mon, 25 Oct 2004 06:37:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDbFsP039595; Mon, 25 Oct 2004 06:37:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDbDP8039589 for ; Mon, 25 Oct 2004 06:37:14 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 14:37:12 +0100 Message-ID: <417D0188.9020409@isode.com> Date: Mon, 25 Oct 2004 14:37:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> In-Reply-To: <87pt379bnm.fsf@luminous.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Alexey> Imagine that support for re-keying can be done without > Alexey> changing (extending) GSS API. > >I did. Unfortunately, Nico convinced me that my fantasy had no basis >in reality. You cannot guarantee that both parties are sending, which >is required for rekeying. ALso, you have bad interactions with >gss_wrap_size_limit. > > Then we need to update the SASL GSSAPI document (suggestions are welcome). > Alexey> In this case the SASL GSSAPI > Alexey> spec doesn't have to be updated. In which case the > Alexey> following text can be removed from 2222bis: > > Alexey> In practice one likely effect of administrative security > Alexey> layers lifetime limits is that applications may find that > Alexey> security layers stop working in the middle of application > Alexey> protocol operation, such as, perhaps, during large data > Alexey> transfers. > >I agree that implementations that work this way are broken. Nico does >not. Nor does the IETF; RFC 1964 mandates this behavior. > > The paragraph as written may suggest that there is a problem with SASL framework, when there is none. The text has to be rewritten to clarify that. Alexey From owner-ietf-sasl Mon Oct 25 07:11:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PEBtop041904; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PEBte5041903; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PEBtfG041897 for ; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 6AA6F7681D; Mon, 25 Oct 2004 10:11:51 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> From: Sam Hartman Date: Mon, 25 Oct 2004 10:11:51 -0400 In-Reply-To: <417D0188.9020409@isode.com> (Alexey Melnikov's message of "Mon, 25 Oct 2004 14:37:12 +0100") Message-ID: <87vfcy99aw.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Nico and some others would argue there is a problem with the SASL framework: it doesn't support rekeying at the SASL level. It clearly could be changed to do so; we as a a working group have decided not to do so. I think we made that decision for a lot of good reasons. If you want to rework the text, I'd recommend making it be fault-agnostic. Simply describe the effect without trying to claim any of the specs involved are broken. From owner-ietf-sasl Mon Oct 25 09:19:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGJRPK063024; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGJRvM063023; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGJRiC063017 for ; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9PGJU7q017678 for ; Mon, 25 Oct 2004 09:19:30 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PGJTjW015900 for ; Mon, 25 Oct 2004 10:19:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9PGJ8ZV019484; Mon, 25 Oct 2004 11:19:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9PGJ7UR019483; Mon, 25 Oct 2004 11:19:07 -0500 (CDT) Date: Mon, 25 Oct 2004 11:19:07 -0500 From: Nicolas Williams To: Sam Hartman Cc: Alexey Melnikov , SASL WG Subject: Re: Life of a security layer and error handling Message-ID: <20041025161906.GN21427@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Alexey Melnikov , SASL WG References: <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vfcy99aw.fsf@luminous.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman wrote: > > I think Nico and some others would argue there is a problem with the > SASL framework: it doesn't support rekeying at the SASL level. It > clearly could be changed to do so; we as a a working group have > decided not to do so. I think we made that decision for a lot of good > reasons. I agree that existing SASL mechanisms' lack of re-keying support should be grandfathered. Going forward though I see no good reason not to require support for re-keying (or re-key-less ciphers/modes) in new/revised SASL mechanisms, that includes the revised GSS mechs draft. (If SASL were a new proposal today, would a spec w/o re-keying get past WG, IETF and IESG reviews? I rather doubt it.) > If you want to rework the text, I'd recommend making it be > fault-agnostic. Simply describe the effect without trying to claim > any of the specs involved are broken. Heh. But see above. Nico -- From owner-ietf-sasl Mon Oct 25 09:51:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGpY8E070929; Mon, 25 Oct 2004 09:51:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGpYSk070928; Mon, 25 Oct 2004 09:51:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGpXpY070916 for ; Mon, 25 Oct 2004 09:51:33 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C539D168027; Mon, 25 Oct 2004 12:51:45 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> From: Sam Hartman Date: Mon, 25 Oct 2004 12:51:45 -0400 In-Reply-To: <20041025161906.GN21427@binky.central.sun.com> (Nicolas Williams's message of "Mon, 25 Oct 2004 11:19:07 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman Nicolas> wrote: >> I think Nico and some others would argue there is a problem >> with the SASL framework: it doesn't support rekeying at the >> SASL level. It clearly could be changed to do so; we as a a >> working group have decided not to do so. I think we made that >> decision for a lot of good reasons. Nicolas> I agree that existing SASL mechanisms' lack of re-keying Nicolas> support should be grandfathered. Nicolas> Going forward though I see no good reason not to require Nicolas> support for re-keying (or re-key-less ciphers/modes) in Nicolas> new/revised SASL mechanisms, that includes the revised Nicolas> GSS mechs draft. I don't think there is current WG consensus to support something as strong as a requirement. I believe Kurt's summary is consistent with this position. I would certainly encourage you to make sure all new SASL mechanisms support rekeying; I certainly plan to try and do the same. From owner-ietf-sasl Mon Oct 25 10:20:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PHKuBW078791; Mon, 25 Oct 2004 10:20:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PHKu1S078790; Mon, 25 Oct 2004 10:20:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PHKtDe078784 for ; Mon, 25 Oct 2004 10:20:55 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9PHKwNH010457 for ; Mon, 25 Oct 2004 11:20:58 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PHKwjW000574 for ; Mon, 25 Oct 2004 11:20:58 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9PHKbnF019540; Mon, 25 Oct 2004 12:20:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9PHKbJk019539; Mon, 25 Oct 2004 12:20:37 -0500 (CDT) Date: Mon, 25 Oct 2004 12:20:37 -0500 From: Nicolas Williams To: Sam Hartman Cc: Alexey Melnikov , SASL WG Subject: Re: Life of a security layer and error handling Message-ID: <20041025172037.GS21427@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Alexey Melnikov , SASL WG References: <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote: > I don't think there is current WG consensus to support something as > strong as a requirement. Well, yeah, technically it's hard to impose requirements on future protocol work :) I must have been hoping that some verbiage to that effect would make it easier to force the matter later when new mechs/mech revisions come along. But I think you're right. IOW, I will settle for Security Considerations text on this. > I believe Kurt's summary is consistent with this position. > > I would certainly encourage you to make sure all new SASL mechanisms > support rekeying; I certainly plan to try and do the same. Thank you. I will. Nico -- From owner-ietf-sasl Mon Oct 25 11:37:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PIbeJV097613; Mon, 25 Oct 2004 11:37:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PIbdig097612; Mon, 25 Oct 2004 11:37:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PIbcBV097581 for ; Mon, 25 Oct 2004 11:37:39 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9PIbeZv045908; Mon, 25 Oct 2004 18:37:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041025112650.03231a28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 25 Oct 2004 11:38:12 -0700 To: Nicolas Williams From: "Kurt D. Zeilenga" Subject: Re: Life of a security layer and error handling Cc: Sam Hartman , Alexey Melnikov , SASL WG In-Reply-To: <20041025172037.GS21427@binky.central.sun.com> References: <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> <20041025172037.GS21427@binky.central.sun.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:20 AM 10/25/2004, Nicolas Williams wrote: >On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote: >> I don't think there is current WG consensus to support something as >> strong as a requirement. > >Well, yeah, technically it's hard to impose requirements on future >protocol work :) And its even harder to impose a particular kind of solution to a security consideration. Rekeying is a possible solution to a security consideration. It's not the only viable solution to that security consideration. The framework specification should elaborate on the security consideration regarding the life of the layer and leave it to mechanism designers to determine how to best address these issues. It might be okay to suggest the designer consider particular solutions, but I do not think it appropriate to recommend a particular solution be used in all future mechanisms. Kurt From owner-ietf-sasl Mon Oct 25 12:04:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PJ4MbD004185; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PJ4MAA004184; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PJ4LYn004151 for ; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 788E3168027; Mon, 25 Oct 2004 15:04:35 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.com> <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> From: Sam Hartman Date: Mon, 25 Oct 2004 15:04:35 -0400 In-Reply-To: <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 24 Oct 2004 19:40:18 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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 view on re-keying is that its just another layer security Kurt> service that a mechanism can offer. In regards to the SASL Kurt> framework specification, how it does so (on the wire) is Kurt> something for the mechanism specification to detail. And Kurt> how an developer of an application protocol provides support Kurt> for this mechanism is an implementation detail. The Kurt> framework simply should not concern itself with such Kurt> The design of any SASL API is limited by which mechanism Kurt> aspects and protocol aspects which were accounted for in the Kurt> design. If a new mechanism has aspects not previously Kurt> considered by designers of a particular SASL API, then the Kurt> designers of that SASL API might want to redesign their API Kurt> to account for the new aspect... or decide that they simply Kurt> cannot support that mechanism (or aspect of that mechanism). Kurt> While we could constraint future mechanisms to currently Kurt> known aspects, I think that's unwise and counter to Kurt> character of SASL. It's been my experience in other IETF work that it is strongly desirable for framework documents to enumerate the aspects of mechanisms of the framework that are generally applicable at the time the framework document is written. Doing so is useful to API and implementation designers. However I cannot claim today that support for this service (re-keying) is generally available in today's SASL mechanisms. So I agree that this revision of the framework should not concern itself with that service. --Sam From owner-ietf-sasl Tue Oct 26 14:04:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4iAR035779; Tue, 26 Oct 2004 14:04:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL4i8S035778; Tue, 26 Oct 2004 14:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4gVH035772 for ; Tue, 26 Oct 2004 14:04:43 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21555; Tue, 26 Oct 2004 17:04:44 -0400 (EDT) Message-Id: <200410262104.RAA21555@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Tue, 26 Oct 2004 17:04:44 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-05.txt Pages : 9 Date : 2004-10-26 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161223.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 26 14:04:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4QEW035734; Tue, 26 Oct 2004 14:04:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL4QPe035733; Tue, 26 Oct 2004 14:04:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4O35035718 for ; Tue, 26 Oct 2004 14:04:25 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21521; Tue, 26 Oct 2004 17:04:25 -0400 (EDT) Message-Id: <200410262104.RAA21521@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-anon-04.txt Date: Tue, 26 Oct 2004 17:04:25 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Anonymous SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-anon-04.txt Pages : 9 Date : 2004-10-26 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-anon-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-anon-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-anon-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-anon-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161218.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 26 15:55:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMtOpQ058244; Tue, 26 Oct 2004 15:55:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QMtODC058243; Tue, 26 Oct 2004 15:55:24 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMtGYw058200 for ; Tue, 26 Oct 2004 15:55:16 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMaDi-0007u8-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: CRAMing for last call Date: Wed, 27 Oct 2004 00:55:10 +0200 Lines: 70 Message-ID: References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:7HnbOMol+wB6oa5kJXxJLx9Ko/E= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello. Some comments on the latest cram-md5 draft. In this post: http://thread.gmane.org/gmane.ietf.sasl/1457 Kurt suggest to explain why the IANA USAGE field of CRAM-MD5 is LIMITED. I too believe this would be useful, to make readers realize they might want PLAIN+TLS, DIGEST-MD5 or GSSAPI instead. There are a few (minor, mostly editorial) suggestions in Kurt's post that has not been addressed, that I believe make sense. Next, I believe it would be useful to tighten up the language in the following paragraph: The mechanism starts with the server issuing a challenge. The data encoded in the challenge contains a presumptively arbitrary string of random data. I suggest to remove "presumptively arbitrary" and add a reference to RFC 1750 after the word "random". Possibly it could be worded differently, because there is quite some structure in the challenge, not complete random data. I read RFC 2104, but it does not say anything about randomness or structure of the challenge text. It may be useful to find some other reference on the properties of challenge strings in CRAM-MD5, or to ask the CFRG for guidance. Next, there were discussion regarding SASLprep unassigned code points in this thread: http://thread.gmane.org/gmane.ietf.sasl/1342 I agree with Kurt that it should be clarified that the client copy of the user name and shared secret should be defined as query strings. I think this would be achieved by adding after: The client MUST prepare the user name and shared secret strings using the SASLPrep [draft-ietf-sasl-saslprep] profile of the StringPrep [RFC3454] algorithm. the following: The client MUST treat the user name and shared secret string as query strings, consequently unassigned code points should be allowed in the prepared output. The server MUST treat the received user name, and the password (regardless of whether it is in unprepared, prepared or hashed form), as stored strings, and consequently disallow unassigned code points in the prepared output that is used as input to the keyed hash operation. Without such text, there is an ambiguity how to invoke SASLPrep. I believe the text belong in CRAM-MD5, as string preparation is a mechanism issue. It does not seem to belong in SASLPrep or 2222bis. Further, RFC 2279 has been obsoleted by RFC 3629: The resulting values MUST be encoded as UTF-8 [RFC2279] strings. I suggest adding a paragraph break after the previous sentence, and the generic recommendations on storing prepared strings. Next, because CRAM-MD5 do not provide a security layer, it should have a reference to TLS and some security consideration suggesting TLS, or similar, if active attacks or privacy issues are a threat. Compare PLAIN. Finally, RFC 2104 is INFORMATIONAL. Can it be a normative reference? Thanks. From owner-ietf-sasl Tue Oct 26 19:31:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2Vp7t010309; Tue, 26 Oct 2004 19:31:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R2Vp4T010308; Tue, 26 Oct 2004 19:31:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2VoY9010252 for ; Tue, 26 Oct 2004 19:31:50 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9R2VkZv057836 for ; Wed, 27 Oct 2004 02:31:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026192702.0308a5d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 19:32:16 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt In-Reply-To: <200410262104.RAA21521@ietf.org> References: <200410262104.RAA21521@ietf.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: In this revision, aside from editorial changes, the following change was made: - The purpose of the mechanism was clarified. I believe this document should now be progressed to the IESG. Kurt At 02:04 PM 10/26/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : The Anonymous SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-anon-04.txt > Pages : 9 > Date : 2004-10-26 > >It is common practice on the Internet to permit anonymous access to >various services. Traditionally, this has been done with a plain text >password mechanism using 'anonymous' as the user name and optional >trace information, such as an email address, as the password. As >plaintext login commands are not permitted in new IETF protocols, a >new way to provide anonymous login is needed within the context of the >Simple Authentication and Security Layer (SASL) framework. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-anon-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-anon-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-26161218.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-anon-04.txt > > From owner-ietf-sasl Tue Oct 26 19:46:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2k6Gn013685; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R2k6EP013684; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2k5Pi013678 for ; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9R2kCZv057945 for ; Wed, 27 Oct 2004 02:46:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 19:46:42 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt In-Reply-To: <200410262104.RAA21555@ietf.org> References: <200410262104.RAA21555@ietf.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: In this revision, aside from minor editorial changes, the message clarified to be a string of UTF-8 encoded Unicode characters and the use of %x00 for NULL (U+0000) was clarified to be the UTF-8 encoding of the NULL character. I believe this document should now be progressed to the IESG. -- Kurt PS: the double blanklines in the I-D is a new Secretariat'ism which seems to be inflicted on new I-Ds. At 02:04 PM 10/26/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : The Plain SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-plain-05.txt > Pages : 9 > Date : 2004-10-26 > >This document defines a simple clear-text user/password Simple >Authentication and Security Layer (SASL) mechanism called the PLAIN >mechanism. The PLAIN mechanism intended to be used, in combination >with data confidentiality services provided by a lower layer, in >protocols which lack a simple password authentication command. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-plain-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-plain-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-26161223.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-plain-05.txt > > From owner-ietf-sasl Wed Oct 27 02:30:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9Ulgg077558; Wed, 27 Oct 2004 02:30:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9UlDT077557; Wed, 27 Oct 2004 02:30:47 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9UkZ2077539 for ; Wed, 27 Oct 2004 02:30:46 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMk8k-0005AA-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 11:30:34 +0200 Lines: 23 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:v0Tq52Rg8FxsYAYq6YR3k1Vb2UY= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Why is SHALL used instead of MUST in the paragraph below? Are there known situations where PLAIN will be used without SASLPrep? Why shouldn't a failed string preparation always lead to verification failure? Further, please make it explicit which strings are query strings and which are stored strings, and mention the value of the AllowUnassigned flag for each string using MUST. It seems the intention is that all strings received from the client are query strings, and the password (whether stored in unprepared, prepared or hashed form) is a stored string. If you don't see why this is necessary, I can elaborate. The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. Thanks. From owner-ietf-sasl Wed Oct 27 02:36:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9asIm080585; Wed, 27 Oct 2004 02:36:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9asHc080584; Wed, 27 Oct 2004 02:36:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9arUW080572 for ; Wed, 27 Oct 2004 02:36:53 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMkEg-0005Ou-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt Date: Wed, 27 Oct 2004 11:36:50 +0200 Lines: 15 Message-ID: References: <200410262104.RAA21521@ietf.org> <6.1.2.0.0.20041026192702.0308a5d0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Jhj0urqIfmtxV2f3w+FxW6epL+k= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For what it's worth, I reviewed the document and it looks good to me. A small nit though. The following paragraph The ANONYMOUS mechanism grants access to services and/or resources by anyone. For this reason it should be disabled by default so the administrator can make an explicit decision to enable it. might imply something that wasn't intended. It seems some protocols could be anonymous in nature (think NNTP). Then it wouldn't make sense to require administrators to explicitly enable ANONYMOUS. ANONYMOUS logins to NNTP servers can be meaningful, think of the trace information provided. Thanks. From owner-ietf-sasl Wed Oct 27 03:08:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RA8n4e095870; Wed, 27 Oct 2004 03:08:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RA8na0095868; Wed, 27 Oct 2004 03:08:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RA8mdC095857 for ; Wed, 27 Oct 2004 03:08:48 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id i9RA8bjx000677 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 27 Oct 2004 03:08:37 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i9RA8bjx000677 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=DqG8nxUzrSWL4xp2xCFC3STMLeyrM88ZvgEA2X7brDg4OFeDd5MUfy99er/hf1vAI Ugd2nouS+G3qjLoLM0cgCAhwbDHDgU4rbjKFbYedG4EMtau8EuFXjNydUqJTE3EEZdl okBgD9Vnibz3hr+F+KmywVIIy5lBfFB8uzuEwns= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i9RA8YtM038902; Wed, 27 Oct 2004 03:08:36 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200410271008.i9RA8YtM038902@lab.smi.sendmail.com> To: Simon Josefsson Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt In-reply-to: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> Date: Wed, 27 Oct 2004 03:08:34 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson writes: >Why is SHALL used instead of MUST in the paragraph below? Per RFC 2119, SHALL and MUST have the same meaning: --- 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. --- Philip Guenther From owner-ietf-sasl Wed Oct 27 06:35:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDZsPx062923; Wed, 27 Oct 2004 06:35:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RDZsjU062922; Wed, 27 Oct 2004 06:35:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDZlsn062865 for ; Wed, 27 Oct 2004 06:35:47 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMnxs-00012v-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 15:35:45 +0200 Lines: 18 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <200410271008.i9RA8YtM038902@lab.smi.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:mIZaNd32vnjtOx2B4CKBn3FDtNA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther writes: > Simon Josefsson writes: >>Why is SHALL used instead of MUST in the paragraph below? > > Per RFC 2119, SHALL and MUST have the same meaning: > --- > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > --- Oops, what a thinko. Thanks. Still, making explicit which strings are to be considered query strings and stored strings still seem useful. Sorry, Simon From owner-ietf-sasl Wed Oct 27 11:09:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RI9cHY025280; Wed, 27 Oct 2004 11:09:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RI9cFO025279; Wed, 27 Oct 2004 11:09:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RI9VX2025247 for ; Wed, 27 Oct 2004 11:09:31 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RI9KZv064032; Wed, 27 Oct 2004 18:09:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 11:09:47 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@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 02:30 AM 10/27/2004, Simon Josefsson wrote: >Further, please make it explicit which strings are query strings and >which are stored strings, Personally, I think the current text is sufficiently clear. However, adding: The presented strings are to be regarded as "query" strings [StringPrep]. as the 3rd sentence of the quoted paragraph could further clarify which strings are to regarded as "query" strings. I do not see any ambiguity as to which strings are to be considered "stored" strings. >and mention the value of the AllowUnassigned >flag for each string using MUST. I cannot find the term "AllowUnassigned flag" anywhere in the specification (including normative references). The text does, however, not only says that strings SHALL be prepared in accordance with StringPrep, it describes what that means in regards to unassigned code points and the two classes of strings. >It seems the intention is that all >strings received from the client are query strings, and the password >(whether stored in unprepared, prepared or hashed form) is a stored >string. If you don't see why this is necessary, I can elaborate. > > The presented authentication identity and password strings are not to > be compared directly with stored strings. The server SHALL first > prepare authentication identity and password strings using the > [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of > [StringPrep], unassigned code points may appear in prepared presented > (query) strings but are prohibited in stored strings. If preparation > fails or results in an empty string, verification SHALL fail. If the > server stores only the hash of expected string, the string MUST be > prepared before generation of the hash. > >Thanks. From owner-ietf-sasl Wed Oct 27 11:42:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RIgGLp032185; Wed, 27 Oct 2004 11:42:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RIgGaX032184; Wed, 27 Oct 2004 11:42:16 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RIgBwP032142 for ; Wed, 27 Oct 2004 11:42:11 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMskQ-0004a7-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 20:42:10 +0200 Lines: 22 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Ud3K8wx8XSwuABa0BbPTfWwy0Ak= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>Further, please make it explicit which strings are query strings and >>which are stored strings, > > Personally, I think the current text is sufficiently clear. > However, adding: > The presented strings are to be regarded as "query" > strings [StringPrep]. > as the 3rd sentence of the quoted paragraph could further > clarify which strings are to regarded as "query" strings. > I do not see any ambiguity as to which strings are to > be considered "stored" strings. A password that the server receive from some online external database (i.e., not "stored" locally) could be considered a query string (from the database) into the verification process. From the server's point of view, it is "querying" whether the password it knows is the same as the one provided by the client. So I see an ambiguity. Thanks. From owner-ietf-sasl Wed Oct 27 12:26:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJQjoM041532; Wed, 27 Oct 2004 12:26:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RJQjv2041531; Wed, 27 Oct 2004 12:26:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJQbK8041473 for ; Wed, 27 Oct 2004 12:26:37 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RJQTZv064526; Wed, 27 Oct 2004 19:26:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 12:26:57 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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:42 AM 10/27/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>Further, please make it explicit which strings are query strings and >>>which are stored strings, >> >> Personally, I think the current text is sufficiently clear. >> However, adding: >> The presented strings are to be regarded as "query" >> strings [StringPrep]. >> as the 3rd sentence of the quoted paragraph could further >> clarify which strings are to regarded as "query" strings. >> I do not see any ambiguity as to which strings are to >> be considered "stored" strings. > >A password that the server receive from some online external database >(i.e., not "stored" locally) could be considered a query string (from >the database) into the verification process. From a SASL PLAIN perspective, any such database as to be viewed as part of the server implementation. Whether the database is "internal" or "external" is simply an implementation detail. From this perspective, the password stored is a stored string. It's irrelevant whether the server stores in a local or remote database. (I'm getting a sense of "deja vu" here, didn't we already discuss this issue? If so, is there a particular reason why we should repeat that discussion?) > From the server's point >of view, it is "querying" whether the password it knows is the same as >the one provided by the client. So I see an ambiguity. > >Thanks. It seems you are saying: From the server's point of view, the server is "querying" whether the password the server knows is the same as the one provided by the client. Er, in this case, I think server is "determining" would be a more appropriate verb as its not clear who the server would be querying to do a comparison between the password it knows (e.g., stored string) and the one provided by the client (e.g., the presented string). But as this makes little sense in the context of the above discussion, so you must have meant to say something else. Please clarify. Thanks, Kurt From owner-ietf-sasl Wed Oct 27 14:34:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLYZVl071922; Wed, 27 Oct 2004 14:34:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLYZR3071921; Wed, 27 Oct 2004 14:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLYQpu071862 for ; Wed, 27 Oct 2004 14:34:26 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C8F31178025; Wed, 27 Oct 2004 17:34:29 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> From: Sam Hartman Date: Wed, 27 Oct 2004 17:34:29 -0400 In-Reply-To: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 27 Oct 2004 11:09:47 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >> Further, please make it explicit which strings are query >> strings and which are stored strings, Kurt> Personally, I think the current text is sufficiently clear. Kurt> However, adding: The presented strings are to be regarded as Kurt> "query" strings [StringPrep]. as the 3rd sentence of the Kurt> quoted paragraph could further clarify which strings are to Kurt> regarded as "query" strings. I do not see any ambiguity as Kurt> to which strings are to be considered "stored" strings. In my mind adding this text makes the draft more confusing and does not add anything. It's my opinion that the working group has already reached consensus on this draft. If people believe that the draft does not reflect that consensus, please bring forward that disagreement. However the bar for opening new issues should be very high at this point. --Sam From owner-ietf-sasl Wed Oct 27 14:37:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLbX2b072483; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLbXZw072482; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLbXUJ072475 for ; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 5659C178025; Wed, 27 Oct 2004 17:37:54 -0400 (EDT) To: ietf-sasl@imc.org Subject: Sending anonymous and plain to the IESG Message-Id: <20041027213754.5659C178025@cz.mit.edu> Date: Wed, 27 Oct 2004 17:37:54 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. It's my intent to do an id-nits review on plain and anonymous. Assuming I see no problems I'll send them to the IESG early next week. If there are resaons this should not happen please let me know before then. --Sam From owner-ietf-sasl Wed Oct 27 14:57:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLvNZK077160; Wed, 27 Oct 2004 14:57:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLvNcB077159; Wed, 27 Oct 2004 14:57:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLvM9D077152 for ; Wed, 27 Oct 2004 14:57:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0F879178025; Wed, 27 Oct 2004 17:57:39 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: CRAMing for last call References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> From: Sam Hartman Date: Wed, 27 Oct 2004 17:57:39 -0400 In-Reply-To: (Simon Josefsson's message of "Wed, 27 Oct 2004 00:55:10 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> Finally, RFC 2104 is INFORMATIONAL. Can it be a normative Simon> reference? Yes. Recently a BCP on dealing with this was published. --Sam From owner-ietf-sasl Wed Oct 27 15:04:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM4bVG078370; Wed, 27 Oct 2004 15:04:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RM4bRn078369; Wed, 27 Oct 2004 15:04:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM4a4U078363 for ; Wed, 27 Oct 2004 15:04:36 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id E101F178025; Wed, 27 Oct 2004 18:04:53 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> From: Sam Hartman Date: Wed, 27 Oct 2004 18:04:53 -0400 In-Reply-To: <417AB364.6050503@isode.com> (Alexey Melnikov's message of "Sat, 23 Oct 2004 20:39:16 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> 1). "indicate that re-keying is or will be needed Alexey> immediately". The first question I have after reading Alexey> this sentence is "how?" Because SASL framework doesn't Alexey> have any control channel or out-of-band mechanism, the Alexey> only answer to this question is "by transparently Alexey> including re-keying messages in the security layer". But Alexey> this is a part of what the subsequent sentence is saying!? By returning some status to the application or setting a flag. You can generally tell you need to re-key without sending anything over the wire. --Sam From owner-ietf-sasl Wed Oct 27 15:08:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM8it1079003; Wed, 27 Oct 2004 15:08:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RM8iuU079002; Wed, 27 Oct 2004 15:08:44 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM8gFS078992 for ; Wed, 27 Oct 2004 15:08:43 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMvyJ-0003F6-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Thu, 28 Oct 2004 00:08:43 +0200 Lines: 82 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:XO4jfXh1J93c9S3+sXyTDxTDUyE= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 11:42 AM 10/27/2004, Simon Josefsson wrote: > >>"Kurt D. Zeilenga" writes: >> >>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>Further, please make it explicit which strings are query strings and >>>>which are stored strings, >>> >>> Personally, I think the current text is sufficiently clear. >>> However, adding: >>> The presented strings are to be regarded as "query" >>> strings [StringPrep]. >>> as the 3rd sentence of the quoted paragraph could further >>> clarify which strings are to regarded as "query" strings. >>> I do not see any ambiguity as to which strings are to >>> be considered "stored" strings. >> >>A password that the server receive from some online external database >>(i.e., not "stored" locally) could be considered a query string (from >>the database) into the verification process. > > From a SASL PLAIN perspective, any such database as to be > viewed as part of the server implementation. Whether the > database is "internal" or "external" is simply an > implementation detail. From this perspective, the > password stored is a stored string. It's irrelevant > whether the server stores in a local or remote database. I don't think this follow from the specification. What I am looking for is text that say that the PLAIN server code should treat the local password as a stored string. Currently, it seems to me that you and the PLAIN document only assume that the password can only be viewed as a stored string. It would be better if the document was explicit about it. The problem is rooted in that StringPrep (SASLPrep) do not define in who's view strings should be considered query or stored strings. What is a stored string from one point of view, may be considered a query string from another point of view. So any document using SASLPrep must define which strings are query strings, and which are stored strings. It does not follow implicitly. In lesser words, please modify your proposed sentence into the following and add it: The presented strings are to be regarded as "query" strings [StringPrep], and the local strings as "stored" strings. > (I'm getting a sense of "deja vu" here, didn't we already > discuss this issue? If so, is there a particular reason > why we should repeat that discussion?) I don't recall what the conclusion was of any earlier discussion, if any, and I believe the current document should be improved. >> From the server's point >>of view, it is "querying" whether the password it knows is the same as >>the one provided by the client. So I see an ambiguity. >> >>Thanks. > > It seems you are saying: > From the server's point of view, the server is > "querying" whether the password the server knows > is the same as the one provided by the client. > > Er, in this case, I think server is "determining" would > be a more appropriate verb as its not clear who the > server would be querying to do a comparison between > the password it knows (e.g., stored string) and the one > provided by the client (e.g., the presented string). > > But as this makes little sense in the context of the above > discussion, so you must have meant to say something else. > Please clarify. To my reading, your explanation describe what I mean. Thanks. From owner-ietf-sasl Wed Oct 27 15:50:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RMoYtd087436; Wed, 27 Oct 2004 15:50:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RMoYkx087435; Wed, 27 Oct 2004 15:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RMoSSw087410 for ; Wed, 27 Oct 2004 15:50:28 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RMoKZv066019; Wed, 27 Oct 2004 22:50:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 15:50:48 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@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 03:08 PM 10/27/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> At 11:42 AM 10/27/2004, Simon Josefsson wrote: >> >>>"Kurt D. Zeilenga" writes: >>> >>>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>>Further, please make it explicit which strings are query strings and >>>>>which are stored strings, >>>> >>>> Personally, I think the current text is sufficiently clear. >>>> However, adding: >>>> The presented strings are to be regarded as "query" >>>> strings [StringPrep]. >>>> as the 3rd sentence of the quoted paragraph could further >>>> clarify which strings are to regarded as "query" strings. >>>> I do not see any ambiguity as to which strings are to >>>> be considered "stored" strings. >>> >>>A password that the server receive from some online external database >>>(i.e., not "stored" locally) could be considered a query string (from >>>the database) into the verification process. >> >> From a SASL PLAIN perspective, any such database as to be >> viewed as part of the server implementation. Whether the >> database is "internal" or "external" is simply an >> implementation detail. From this perspective, the >> password stored is a stored string. It's irrelevant >> whether the server stores in a local or remote database. > >I don't think this follow from the specification. It follows from SASL PLAIN being a client/server protocol specification. Everything on side is referred the client. Everything on the other is referred to as the server. The architecture of the client and server are irrelevant to the protocol. It matters not whether the peer is constructed from many components which interact in some way or the peer is constructed as a monolith, because the peers obligations to the other peer is the same regardless. >What I am looking for is text that say that the PLAIN server code >should treat the local password as a stored string. What's a "local password"? >Currently, it >seems to me that you and the PLAIN document only assume that the >password can only be viewed as a stored string. The presented string is compared against a stored string (or equivalent). What the document doesn't say, and shouldn't say, is in which component that comparison is made or in what component of the server stored values are fetched from or any other implementation detail. >It would be better if >the document was explicit about it. > >The problem is rooted in that StringPrep (SASLPrep) do not define in >who's view strings should be considered query or stored strings. Stringprep relies on incorporating specifications to detail their view as to what is to be regarded as a query string and what is to be regarded as a stored string. >What >is a stored string from one point of view, may be considered a query >string from another point of view. So any document using SASLPrep >must define which strings are query strings, and which are stored >strings. It does not follow implicitly. The PLAIN ID does detail what is a query string and a stored string. It uses the term "stored" string repeated. And it uses the term "presented string" in a manner which makes it clear that these are query strings. >In lesser words, please modify your proposed sentence into the >following and add it: > > The presented strings are to be regarded as "query" strings > [StringPrep], and the local strings as "stored" strings. What's a "local" string? And why are why defining it to the same as a "stored string". Now, you could say: stored strings are regarded as "stored" strings [StringPrep], but that is stating the obvious (IMO). >> (I'm getting a sense of "deja vu" here, didn't we already >> discuss this issue? If so, is there a particular reason >> why we should repeat that discussion?) > >I don't recall what the conclusion was of any earlier discussion, if >any, and I believe the current document should be improved. > >>> From the server's point >>>of view, it is "querying" whether the password it knows is the same as >>>the one provided by the client. So I see an ambiguity. >>> >>>Thanks. >> >> It seems you are saying: >> From the server's point of view, the server is >> "querying" whether the password the server knows >> is the same as the one provided by the client. >> >> Er, in this case, I think server is "determining" would >> be a more appropriate verb as its not clear who the >> server would be querying to do a comparison between >> the password it knows (e.g., stored string) and the one >> provided by the client (e.g., the presented string). >> >> But as this makes little sense in the context of the above >> discussion, so you must have meant to say something else. >> Please clarify. > >To my reading, your explanation describe what I mean. From owner-ietf-sasl Wed Oct 27 16:23:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNNrEY095342; Wed, 27 Oct 2004 16:23:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RNNr6r095341; Wed, 27 Oct 2004 16:23:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNNqra095311 for ; Wed, 27 Oct 2004 16:23:52 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id i9RNNoKt066762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Oct 2004 17:23:52 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 27 Oct 2004 16:23:50 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: Re: CRAMing for last call Message-ID: <0BBA60D81C80944C3EE1A73A@peregrin.orthanc.ca> In-Reply-To: References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RNNrra095336 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-10-27 5:57 PM -0400 Sam Hartman wrote: > Simon> Finally, RFC 2104 is INFORMATIONAL. Can it be a normative > Simon> reference? > > Yes. Recently a BCP on dealing with this was published. Don't Panic!â„¢ Due to a seemingly-imminent disk failure on my laptop, I pushed out a preliminary version of the draft (as a backup measure more than anything). There will be another rev after the IETF, containing the editorial changes I've previously alluded to. The references will be fixed as part of that update. (And, I hope, the presentation/stored strings issues.) --lyndon From owner-ietf-sasl Wed Oct 27 16:50:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNo8nC001674; Wed, 27 Oct 2004 16:50:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RNo8KO001673; Wed, 27 Oct 2004 16:50:08 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNo2f6001601 for ; Wed, 27 Oct 2004 16:50:03 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMxYH-0007V3-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Thu, 28 Oct 2004 01:49:56 +0200 Lines: 172 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:mXCHkFFaOa24J2DwNYuf2DzDZGA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 03:08 PM 10/27/2004, Simon Josefsson wrote: > >>"Kurt D. Zeilenga" writes: >> >>> At 11:42 AM 10/27/2004, Simon Josefsson wrote: >>> >>>>"Kurt D. Zeilenga" writes: >>>> >>>>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>>>Further, please make it explicit which strings are query strings and >>>>>>which are stored strings, >>>>> >>>>> Personally, I think the current text is sufficiently clear. >>>>> However, adding: >>>>> The presented strings are to be regarded as "query" >>>>> strings [StringPrep]. >>>>> as the 3rd sentence of the quoted paragraph could further >>>>> clarify which strings are to regarded as "query" strings. >>>>> I do not see any ambiguity as to which strings are to >>>>> be considered "stored" strings. >>>> >>>>A password that the server receive from some online external database >>>>(i.e., not "stored" locally) could be considered a query string (from >>>>the database) into the verification process. >>> >>> From a SASL PLAIN perspective, any such database as to be >>> viewed as part of the server implementation. Whether the >>> database is "internal" or "external" is simply an >>> implementation detail. From this perspective, the >>> password stored is a stored string. It's irrelevant >>> whether the server stores in a local or remote database. >> >>I don't think this follow from the specification. > > It follows from SASL PLAIN being a client/server protocol > specification. Everything on side is referred the client. > Everything on the other is referred to as the server. > The architecture of the client and server are irrelevant > to the protocol. It matters not whether the peer is > constructed from many components which interact in some > way or the peer is constructed as a monolith, because > the peers obligations to the other peer is the same > regardless. > >>What I am looking for is text that say that the PLAIN server code >>should treat the local password as a stored string. > > What's a "local password"? I was trying to come up with a descriptive word for it, but I guess I failed. What I meant by "local password" was the input password that the server end up using, after string preparation, in comparing the password provided by the client. The client provided password is the "presented" password, and the other password is "local" in the server. >>Currently, it >>seems to me that you and the PLAIN document only assume that the >>password can only be viewed as a stored string. > > The presented string is compared against a stored string > (or equivalent). Right. What is missing is that the password should be considered as a stored string from the point of view of SASLPrep too, i.e., unassigned code points are not allowed. > What the document doesn't say, and shouldn't > say, is in which component that comparison is made or > in what component of the server stored values are fetched > from or any other implementation detail. Agreed. >>It would be better if >>the document was explicit about it. >> >>The problem is rooted in that StringPrep (SASLPrep) do not define in >>who's view strings should be considered query or stored strings. > > Stringprep relies on incorporating specifications to detail > their view as to what is to be regarded as a query string > and what is to be regarded as a stored string. Agreed. And that detailing is what I believe could be improved in PLAIN. >>What >>is a stored string from one point of view, may be considered a query >>string from another point of view. So any document using SASLPrep >>must define which strings are query strings, and which are stored >>strings. It does not follow implicitly. > > The PLAIN ID does detail what is a query string and > a stored string. It uses the term "stored" string > repeated. And it uses the term "presented string" > in a manner which makes it clear that these are > query strings. It seems we are agreeing on the intention, but not what the document is saying. >>In lesser words, please modify your proposed sentence into the >>following and add it: >> >> The presented strings are to be regarded as "query" strings >> [StringPrep], and the local strings as "stored" strings. > > What's a "local" string? And why are why defining it to > the same as a "stored string". Now, you could say: > stored strings are regarded as "stored" strings [StringPrep], > but that is stating the obvious (IMO). I think the terminology here is poor. I want to differentiate between the "stored string" in the StringPrep/SASLPrep sense, and the "local password" which the server uses as input to the string preparation, and eventually uses to compare with the presented password. Calling the latter "local password" a "stored string" implicitly assume that SASLprep has already been applied to the string. And that unassigned code points are forbidden in the output. But that cannot be assumed, it is something that must be described by the document. To be more concrete: Here is the part of the document with normative text regarding stored strings: Upon receipt of the message, the server will verify the presented authentication identity (authcid) and password (passwd) with the system authentication database, and verify the authentication credentials permit the client to act as the (presented or derived) authorization identity. If both steps succeed, the user is authenticated. The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. An attempt to modify this into something I believe would be more correct would be: Upon receipt of the message, the server will verify the presented authentication identity (authcid) and password (passwd) with the system authentication database, which contain the "local" password for the authentication identity. Next, the server verify that the authentication credentials permit the client to act as the (presented or derived) authorization identity. If both steps succeed, the user is authenticated. The presented authentication identity and password strings are not to be compared directly with local strings. The server SHALL first prepare authentication identity, presented password, and local password using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in local (stored) strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of the expected password string, the string MUST be prepared, as a stored string, before generation of the hash. Thanks, Simon From owner-ietf-sasl Wed Oct 27 18:17:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S1HrvG020706; Wed, 27 Oct 2004 18:17:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9S1HroQ020705; Wed, 27 Oct 2004 18:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S1HhNi020637 for ; Wed, 27 Oct 2004 18:17:43 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9S1GUZv066714; Thu, 28 Oct 2004 01:16:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027172544.03916390@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 18:16:58 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@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 04:49 PM 10/27/2004, Simon Josefsson wrote: >>>What I am looking for is text that say that the PLAIN server code >>>should treat the local password as a stored string. >> What's a "local password"? >I was trying to come up with a descriptive word for it, I think "stored" is pretty descriptive. >What is missing is that the password should be considered as a >stored string from the point of view of SASLPrep too, i.e., unassigned >code points are not allowed. I guess we'll have to agree to disagree here. I do not believe this is missing from the I-D. I find the paragraph you quoted is quite clear as to which strings are to be considered "query" strings and which are to be considered "stored" strings during string preparation. The I-D also provides pseudo-code and further discussion which reenforces which strings are to be considered "query" strings and which are to be considered "stored" strings during preparation. >>> The presented strings are to be regarded as "query" strings >>> [StringPrep], and the local strings as "stored" strings. >> >> What's a "local" string? And why are why defining it to >> the same as a "stored string". Now, you could say: >> stored strings are regarded as "stored" strings [StringPrep], >> but that is stating the obvious (IMO). >I think the terminology here is poor. "local string" is a poor term. >I want to differentiate between the "stored string" in the >StringPrep/SASLPrep sense, and the "local password" which the server >uses as input to the string preparation, and eventually uses to >compare with the presented password. Such a differentiation will, I think, lead to confusion. I think the text you offer is not better than the current text. I think it it is much worse than the current text. I think the current text is sufficiently clear. >Calling the latter "local password" a "stored string" implicitly >assume that SASLprep has already been applied to the string. And that >unassigned code points are forbidden in the output. But that cannot >be assumed, it is something that must be described by the document. > >To be more concrete: Here is the part of the document with normative >text regarding stored strings: > > Upon receipt of the message, the server will verify the presented > authentication identity (authcid) and password (passwd) with the > system authentication database, and verify the authentication > credentials permit the client to act as the (presented or derived) > authorization identity. If both steps succeed, the user is > authenticated. > > The presented authentication identity and password strings are not to > be compared directly with stored strings. The server SHALL first > prepare authentication identity and password strings using the > [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of > [StringPrep], unassigned code points may appear in prepared presented > (query) strings but are prohibited in stored strings. If preparation > fails or results in an empty string, verification SHALL fail. If the > server stores only the hash of expected string, the string MUST be > prepared before generation of the hash. > >An attempt to modify this into something I believe would be more >correct would be: > > Upon receipt of the message, the server will verify the presented > authentication identity (authcid) and password (passwd) with the > system authentication database, which contain the "local" password > for the authentication identity. What's a local password? Isn't the password shared with the user? Can't the password be stored remotely? And are you only applying the term "local" to the password? Wouldn't there also be a "local" authentication identity string as well. But that said, I also dislike explicitly describing the contents of the system authentication database. > Next, the server verify that the > authentication credentials permit the client to act as the > (presented or derived) authorization identity. If both steps > succeed, the user is authenticated. > > The presented authentication identity and password strings are not > to be compared directly with local strings. The server SHALL first > prepare authentication identity, presented password, and local > password using the [SASLPrep] profile of the [StringPrep] algorithm. > Per Section 7 of [StringPrep], unassigned code points may appear in > prepared presented (query) strings but are prohibited in local > (stored) strings. Is the stored authentication identity string a local string or a query string? Kurt From owner-ietf-sasl Thu Oct 28 08:12:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCicJ063456; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFCirx063455; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFChwa063449 for ; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23743; Thu, 28 Oct 2004 11:12:52 -0400 (EDT) Message-Id: <200410281512.LAA23743@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-04.txt Date: Thu, 28 Oct 2004 11:12:52 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-04.txt Pages : 10 Date : 2004-10-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110352.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Oct 28 08:12:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCZX0063437; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFCZgN063436; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCYCo063426 for ; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23727; Thu, 28 Oct 2004 11:12:43 -0400 (EDT) Message-Id: <200410281512.LAA23727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-09.txt Date: Thu, 28 Oct 2004 11:12:43 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-09.txt Pages : 11 Date : 2004-10-27 The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Oct 28 17:10:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T0AFvI088166; Thu, 28 Oct 2004 17:10:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9T0AFmr088165; Thu, 28 Oct 2004 17:10:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9T0AEnJ088159 for ; Thu, 28 Oct 2004 17:10:14 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30031; 28 Oct 2004 20:10 EDT Date: Thu, 28 Oct 2004 20:10:04 -0400 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Message-ID: <1120700000.1099008604@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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, October 27, 2004 11:09:47 -0700 "Kurt D. Zeilenga" wrote: >> and mention the value of the AllowUnassigned >> flag for each string using MUST. > > I cannot find the term "AllowUnassigned flag" anywhere in > the specification (including normative references). This term was apparently used in some drafts of nameprep, and is referred to in RFC3490 and draft-hoffman-rfc3490bis-02.txt. Unfortunately, those references claim that the term is defined in RFC3491 and draft-hoffman-rfc3491bis-01.txt, respectively, and neither document defines the term. Neither do stringprep or saslprep. This flag was used as a parameter to the preparation algorithm in IDN, to indicate whether unassigned code points are permitted; it is what distinguishes between storage and query strings. The profile defined by SASLprep does make such a distinction, but does not use a formally defined "flag". We should mention in each case whether unassigned code points are permitted (query strings) or not (storage strings). But we should not use a reference to an "AllowUnassigned flag" which our stringprep profile does not have. > The text does, however, not only says that strings SHALL > be prepared in accordance with StringPrep, it describes > what that means in regards to unassigned code points > and the two classes of strings. Then this should be sufficient. -- Jeff From owner-ietf-sasl Fri Oct 29 05:45:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCj72C031352; Fri, 29 Oct 2004 05:45:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TCj7Bj031351; Fri, 29 Oct 2004 05:45:07 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCiw7N031288 for ; Fri, 29 Oct 2004 05:44:59 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CNW7h-0007w9-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Fri, 29 Oct 2004 14:44:48 +0200 Lines: 146 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> <6.1.2.0.0.20041027172544.03916390@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:hwqVxsfayWnFp2Xwp9QIIWXqJbc= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:49 PM 10/27/2004, Simon Josefsson wrote: >>>>What I am looking for is text that say that the PLAIN server code >>>>should treat the local password as a stored string. >>> What's a "local password"? >>I was trying to come up with a descriptive word for it, > > I think "stored" is pretty descriptive. For what is intended here, I disagree. "Stored string" is a StringPrep/SASLPrep term that denote strings that have or will be prepared in a way that disallow unassigned code points in the output. Talking about the strings that PLAIN servers should apply SASLPrep to as "stored strings" does not give any clues which these strings are. That is why I believe PLAIN must say which strings should be considered as "stored strings", in the SASLprep point of view. I don't think this is clear now. >>What is missing is that the password should be considered as a >>stored string from the point of view of SASLPrep too, i.e., unassigned >>code points are not allowed. > > I guess we'll have to agree to disagree here. > > I do not believe this is missing from the I-D. I find the > paragraph you quoted is quite clear as to which strings are > to be considered "query" strings and which are to be considered > "stored" strings during string preparation. The I-D also > provides pseudo-code and further discussion which reenforces > which strings are to be considered "query" strings and which > are to be considered "stored" strings during preparation. The pseudo-code hide all SASLPrep preparation of the "local password" inside FetchPasswordHash, so it is clarified at all, in my opinion. I agree the draft make it clear which strings are "query strings", but I don't think it is clear which strings are "stored strings". >>Calling the latter "local password" a "stored string" implicitly >>assume that SASLprep has already been applied to the string. And that >>unassigned code points are forbidden in the output. But that cannot >>be assumed, it is something that must be described by the document. >> >>To be more concrete: Here is the part of the document with normative >>text regarding stored strings: >> >> Upon receipt of the message, the server will verify the presented >> authentication identity (authcid) and password (passwd) with the >> system authentication database, and verify the authentication >> credentials permit the client to act as the (presented or derived) >> authorization identity. If both steps succeed, the user is >> authenticated. >> >> The presented authentication identity and password strings are not to >> be compared directly with stored strings. The server SHALL first >> prepare authentication identity and password strings using the >> [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of >> [StringPrep], unassigned code points may appear in prepared presented >> (query) strings but are prohibited in stored strings. If preparation >> fails or results in an empty string, verification SHALL fail. If the >> server stores only the hash of expected string, the string MUST be >> prepared before generation of the hash. >> >>An attempt to modify this into something I believe would be more >>correct would be: >> >> Upon receipt of the message, the server will verify the presented >> authentication identity (authcid) and password (passwd) with the >> system authentication database, which contain the "local" password >> for the authentication identity. > > What's a local password? I believe I explained this in my last post. The local password is the password the server has stored for the user, whether in the form of a unprepared UTF-8 string, a SASLPrep prepared string, or a hash of a SASLPrep prepared string. > Isn't the password shared with the user? Right. But the server must have a copy (in some form), to compare with what the user presents. > Can't the password be stored remotely? Of course. But at some point, the server must have access to it, that's why I argue it can be considered "local". If you have a better term, that would be great. > And are you only applying the term "local" to the password? > Wouldn't there also be a "local" authentication identity string as > well. That depend on the implementation. I think most servers implement some form of database that map to . It isn't efficient to prepare every in the database using SASLPrep, to get a "local ", and then compare them with the presented . So instead they look up the client presented string in the database, and hope to find something. > But that said, I also dislike explicitly describing the > contents of the system authentication database. If the term is to mean anything at all, there must be some meaning to what a "system authentication database" is. Describing that it contain and , where the may be in raw, prepared, hashed or other forms that can be used in verifying the client presented data doesn't preclude some design, does it? Currently, the term is used with no definition. >> Next, the server verify that the >> authentication credentials permit the client to act as the >> (presented or derived) authorization identity. If both steps >> succeed, the user is authenticated. >> >> The presented authentication identity and password strings are not >> to be compared directly with local strings. The server SHALL first >> prepare authentication identity, presented password, and local >> password using the [SASLPrep] profile of the [StringPrep] algorithm. >> Per Section 7 of [StringPrep], unassigned code points may appear in >> prepared presented (query) strings but are prohibited in local >> (stored) strings. > > Is the stored authentication identity string a local string or > a query string? It depends on the implementation. I think some implementations take the presented , look it up in a database, and hopefully get a password (in whatever form) back. This assume that the database has been populated with prepared strings with no unassigned code points. Alternatively, if the database store unprepared strings, the implementation may prepare the presented using SASLPrep with no unassigned code points in the output, and then look up that string in the database. Thanks. From owner-ietf-sasl Fri Oct 29 06:05:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TD5Jlf034322; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TD5JdR034321; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TD5IWF034311 for ; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CNWRU-0000yN-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Fri, 29 Oct 2004 15:05:15 +0200 Lines: 29 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <1120700000.1099008604@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:0R0Zq7mtdr69ZaVrKlFMArTGP6I= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > We should mention in each case whether unassigned code points are permitted > (query strings) or not (storage strings). But we should not use a > reference to an "AllowUnassigned flag" which our stringprep profile does > not have. I agree completely. I further believe it is critical that it is clear how to prepare every involved string. Merely referring to SASLPrep is not sufficient. Documents must enforce _how_ SASLPrep is used on each individual input string. I.e., documents have to say whether or not unassigned code points should be permitted in the output or not. >> The text does, however, not only says that strings SHALL be >> prepared in accordance with StringPrep, it describes what that >> means in regards to unassigned code points and the two classes of >> strings. > > Then this should be sufficient. It would, although I appear to disagree with Kurt that the text is not ambiguous about this. I believe my opinion on this should now be clear, and that it is not useful to carry on this discussion. If everyone else who understand the issue believe the documents are clear, then there shouldn't ever be problems with the use of SASLprep in PLAIN, and all will be fine. Thanks. From owner-ietf-sasl Fri Oct 29 08:08:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF80E7009101; Fri, 29 Oct 2004 08:08:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TF808s009098; Fri, 29 Oct 2004 08:08:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF7rKg008858 for ; Fri, 29 Oct 2004 08:07:53 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9TF6eZv079250; Fri, 29 Oct 2004 15:06:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041029075631.03005750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 29 Oct 2004 08:06:44 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> <6.1.2.0.0.20041027172544.03916390@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:44 AM 10/29/2004, Simon Josefsson wrote: >>> Upon receipt of the message, the server will verify the presented >>> authentication identity (authcid) and password (passwd) with the >>> system authentication database, which contain the "local" password >>> for the authentication identity. >> >> What's a local password? >I believe I explained this in my last post. But you didn't explain it in the text that you offered for consideration. My questions in regards to the offered text are written from the point of view of someone who doesn't have any knowledge of your prior comments. That is, my questions are from the point of view of an independent developer reading the offered text as if it was included in PLAIN's TS. It makes no sense to me to say the password in local to the server when that password is clearly shared with the client which presented it. It's not at all obvious that local password are refers to the stored copy of the shared password at the server. Kur From owner-ietf-sasl Fri Oct 29 10:57:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THvERF013718; Fri, 29 Oct 2004 10:57:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9THvEwU013717; Fri, 29 Oct 2004 10:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (mca1f36d0.tmodns.net [208.54.31.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THv2FF013503 for ; Fri, 29 Oct 2004 10:57:05 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0E992E0006; Fri, 29 Oct 2004 13:55:13 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <1120700000.1099008604@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Fri, 29 Oct 2004 13:54:32 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 29 Oct 2004 15:05:15 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> It would, although I appear to disagree with Kurt that the Simon> text is not ambiguous about this. Simon> I believe my opinion on this should now be clear, and that Simon> it is not useful to carry on this discussion. If everyone Simon> else who understand the issue believe the documents are Simon> clear, then there shouldn't ever be problems with the use Simon> of SASLprep in PLAIN, and all will be fine. Speaking as chair, I do not believe there is a working group consensus to reopen this issue. --Sam From owner-ietf-sasl Sun Oct 31 18:43:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA12hDiU058555; Sun, 31 Oct 2004 18:43:13 -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 iA12hDOJ058554; Sun, 31 Oct 2004 18:43:13 -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.9) with ESMTP id iA12hCsL058511 for ; Sun, 31 Oct 2004 18:43:12 -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.11) with ESMTP id iA12hCZv096337 for ; Mon, 1 Nov 2004 02:43:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041031184301.02d62430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 31 Oct 2004 18:43:33 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASL Agenda for IETF#61 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 (SASL) Tuesday, 9 November 2004 1545-1645 =================================== Chairs: Sam Hartman Kurt Zeilenga Agenda: Introductions and Agenda Bashing - Chairs (5 minutes) Review of SASL Base last call - Chairs/Alexey (15 minutes) Digest MD5 (draft--ietf-sasl-rfc2831bis) - Alexey (10 minutes) GSSAPI (draft-ietf-sasl-gssapi) - Alexey (10 minutes) CRAM-MD5 (draft-ietf-sasl-crammd5) - TBD (10 minutes) Open mic - (remaining time) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA12hDiU058555; Sun, 31 Oct 2004 18:43:13 -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 iA12hDOJ058554; Sun, 31 Oct 2004 18:43:13 -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.9) with ESMTP id iA12hCsL058511 for ; Sun, 31 Oct 2004 18:43:12 -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.11) with ESMTP id iA12hCZv096337 for ; Mon, 1 Nov 2004 02:43:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041031184301.02d62430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 31 Oct 2004 18:43:33 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASL Agenda for IETF#61 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 (SASL) Tuesday, 9 November 2004 1545-1645 =================================== Chairs: Sam Hartman Kurt Zeilenga Agenda: Introductions and Agenda Bashing - Chairs (5 minutes) Review of SASL Base last call - Chairs/Alexey (15 minutes) Digest MD5 (draft--ietf-sasl-rfc2831bis) - Alexey (10 minutes) GSSAPI (draft-ietf-sasl-gssapi) - Alexey (10 minutes) CRAM-MD5 (draft-ietf-sasl-crammd5) - TBD (10 minutes) Open mic - (remaining time) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THvERF013718; Fri, 29 Oct 2004 10:57:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9THvEwU013717; Fri, 29 Oct 2004 10:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (mca1f36d0.tmodns.net [208.54.31.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THv2FF013503 for ; Fri, 29 Oct 2004 10:57:05 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0E992E0006; Fri, 29 Oct 2004 13:55:13 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <1120700000.1099008604@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Fri, 29 Oct 2004 13:54:32 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 29 Oct 2004 15:05:15 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> It would, although I appear to disagree with Kurt that the Simon> text is not ambiguous about this. Simon> I believe my opinion on this should now be clear, and that Simon> it is not useful to carry on this discussion. If everyone Simon> else who understand the issue believe the documents are Simon> clear, then there shouldn't ever be problems with the use Simon> of SASLprep in PLAIN, and all will be fine. Speaking as chair, I do not believe there is a working group consensus to reopen this issue. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF80E7009101; Fri, 29 Oct 2004 08:08:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TF808s009098; Fri, 29 Oct 2004 08:08:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF7rKg008858 for ; Fri, 29 Oct 2004 08:07:53 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9TF6eZv079250; Fri, 29 Oct 2004 15:06:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041029075631.03005750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 29 Oct 2004 08:06:44 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> <6.1.2.0.0.20041027172544.03916390@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:44 AM 10/29/2004, Simon Josefsson wrote: >>> Upon receipt of the message, the server will verify the presented >>> authentication identity (authcid) and password (passwd) with the >>> system authentication database, which contain the "local" password >>> for the authentication identity. >> >> What's a local password? >I believe I explained this in my last post. But you didn't explain it in the text that you offered for consideration. My questions in regards to the offered text are written from the point of view of someone who doesn't have any knowledge of your prior comments. That is, my questions are from the point of view of an independent developer reading the offered text as if it was included in PLAIN's TS. It makes no sense to me to say the password in local to the server when that password is clearly shared with the client which presented it. It's not at all obvious that local password are refers to the stored copy of the shared password at the server. Kur Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TD5Jlf034322; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TD5JdR034321; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TD5IWF034311 for ; Fri, 29 Oct 2004 06:05:19 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CNWRU-0000yN-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 15:05:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Fri, 29 Oct 2004 15:05:15 +0200 Lines: 29 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <1120700000.1099008604@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:0R0Zq7mtdr69ZaVrKlFMArTGP6I= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > We should mention in each case whether unassigned code points are permitted > (query strings) or not (storage strings). But we should not use a > reference to an "AllowUnassigned flag" which our stringprep profile does > not have. I agree completely. I further believe it is critical that it is clear how to prepare every involved string. Merely referring to SASLPrep is not sufficient. Documents must enforce _how_ SASLPrep is used on each individual input string. I.e., documents have to say whether or not unassigned code points should be permitted in the output or not. >> The text does, however, not only says that strings SHALL be >> prepared in accordance with StringPrep, it describes what that >> means in regards to unassigned code points and the two classes of >> strings. > > Then this should be sufficient. It would, although I appear to disagree with Kurt that the text is not ambiguous about this. I believe my opinion on this should now be clear, and that it is not useful to carry on this discussion. If everyone else who understand the issue believe the documents are clear, then there shouldn't ever be problems with the use of SASLprep in PLAIN, and all will be fine. Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCj72C031352; Fri, 29 Oct 2004 05:45:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TCj7Bj031351; Fri, 29 Oct 2004 05:45:07 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCiw7N031288 for ; Fri, 29 Oct 2004 05:44:59 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CNW7h-0007w9-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 14:44:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Fri, 29 Oct 2004 14:44:48 +0200 Lines: 146 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> <6.1.2.0.0.20041027172544.03916390@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:hwqVxsfayWnFp2Xwp9QIIWXqJbc= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:49 PM 10/27/2004, Simon Josefsson wrote: >>>>What I am looking for is text that say that the PLAIN server code >>>>should treat the local password as a stored string. >>> What's a "local password"? >>I was trying to come up with a descriptive word for it, > > I think "stored" is pretty descriptive. For what is intended here, I disagree. "Stored string" is a StringPrep/SASLPrep term that denote strings that have or will be prepared in a way that disallow unassigned code points in the output. Talking about the strings that PLAIN servers should apply SASLPrep to as "stored strings" does not give any clues which these strings are. That is why I believe PLAIN must say which strings should be considered as "stored strings", in the SASLprep point of view. I don't think this is clear now. >>What is missing is that the password should be considered as a >>stored string from the point of view of SASLPrep too, i.e., unassigned >>code points are not allowed. > > I guess we'll have to agree to disagree here. > > I do not believe this is missing from the I-D. I find the > paragraph you quoted is quite clear as to which strings are > to be considered "query" strings and which are to be considered > "stored" strings during string preparation. The I-D also > provides pseudo-code and further discussion which reenforces > which strings are to be considered "query" strings and which > are to be considered "stored" strings during preparation. The pseudo-code hide all SASLPrep preparation of the "local password" inside FetchPasswordHash, so it is clarified at all, in my opinion. I agree the draft make it clear which strings are "query strings", but I don't think it is clear which strings are "stored strings". >>Calling the latter "local password" a "stored string" implicitly >>assume that SASLprep has already been applied to the string. And that >>unassigned code points are forbidden in the output. But that cannot >>be assumed, it is something that must be described by the document. >> >>To be more concrete: Here is the part of the document with normative >>text regarding stored strings: >> >> Upon receipt of the message, the server will verify the presented >> authentication identity (authcid) and password (passwd) with the >> system authentication database, and verify the authentication >> credentials permit the client to act as the (presented or derived) >> authorization identity. If both steps succeed, the user is >> authenticated. >> >> The presented authentication identity and password strings are not to >> be compared directly with stored strings. The server SHALL first >> prepare authentication identity and password strings using the >> [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of >> [StringPrep], unassigned code points may appear in prepared presented >> (query) strings but are prohibited in stored strings. If preparation >> fails or results in an empty string, verification SHALL fail. If the >> server stores only the hash of expected string, the string MUST be >> prepared before generation of the hash. >> >>An attempt to modify this into something I believe would be more >>correct would be: >> >> Upon receipt of the message, the server will verify the presented >> authentication identity (authcid) and password (passwd) with the >> system authentication database, which contain the "local" password >> for the authentication identity. > > What's a local password? I believe I explained this in my last post. The local password is the password the server has stored for the user, whether in the form of a unprepared UTF-8 string, a SASLPrep prepared string, or a hash of a SASLPrep prepared string. > Isn't the password shared with the user? Right. But the server must have a copy (in some form), to compare with what the user presents. > Can't the password be stored remotely? Of course. But at some point, the server must have access to it, that's why I argue it can be considered "local". If you have a better term, that would be great. > And are you only applying the term "local" to the password? > Wouldn't there also be a "local" authentication identity string as > well. That depend on the implementation. I think most servers implement some form of database that map to . It isn't efficient to prepare every in the database using SASLPrep, to get a "local ", and then compare them with the presented . So instead they look up the client presented string in the database, and hope to find something. > But that said, I also dislike explicitly describing the > contents of the system authentication database. If the term is to mean anything at all, there must be some meaning to what a "system authentication database" is. Describing that it contain and , where the may be in raw, prepared, hashed or other forms that can be used in verifying the client presented data doesn't preclude some design, does it? Currently, the term is used with no definition. >> Next, the server verify that the >> authentication credentials permit the client to act as the >> (presented or derived) authorization identity. If both steps >> succeed, the user is authenticated. >> >> The presented authentication identity and password strings are not >> to be compared directly with local strings. The server SHALL first >> prepare authentication identity, presented password, and local >> password using the [SASLPrep] profile of the [StringPrep] algorithm. >> Per Section 7 of [StringPrep], unassigned code points may appear in >> prepared presented (query) strings but are prohibited in local >> (stored) strings. > > Is the stored authentication identity string a local string or > a query string? It depends on the implementation. I think some implementations take the presented , look it up in a database, and hopefully get a password (in whatever form) back. This assume that the database has been populated with prepared strings with no unassigned code points. Alternatively, if the database store unprepared strings, the implementation may prepare the presented using SASLPrep with no unassigned code points in the output, and then look up that string in the database. Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T0AFvI088166; Thu, 28 Oct 2004 17:10:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9T0AFmr088165; Thu, 28 Oct 2004 17:10:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9T0AEnJ088159 for ; Thu, 28 Oct 2004 17:10:14 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30031; 28 Oct 2004 20:10 EDT Date: Thu, 28 Oct 2004 20:10:04 -0400 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Message-ID: <1120700000.1099008604@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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, October 27, 2004 11:09:47 -0700 "Kurt D. Zeilenga" wrote: >> and mention the value of the AllowUnassigned >> flag for each string using MUST. > > I cannot find the term "AllowUnassigned flag" anywhere in > the specification (including normative references). This term was apparently used in some drafts of nameprep, and is referred to in RFC3490 and draft-hoffman-rfc3490bis-02.txt. Unfortunately, those references claim that the term is defined in RFC3491 and draft-hoffman-rfc3491bis-01.txt, respectively, and neither document defines the term. Neither do stringprep or saslprep. This flag was used as a parameter to the preparation algorithm in IDN, to indicate whether unassigned code points are permitted; it is what distinguishes between storage and query strings. The profile defined by SASLprep does make such a distinction, but does not use a formally defined "flag". We should mention in each case whether unassigned code points are permitted (query strings) or not (storage strings). But we should not use a reference to an "AllowUnassigned flag" which our stringprep profile does not have. > The text does, however, not only says that strings SHALL > be prepared in accordance with StringPrep, it describes > what that means in regards to unassigned code points > and the two classes of strings. Then this should be sufficient. -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCicJ063456; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFCirx063455; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFChwa063449 for ; Thu, 28 Oct 2004 08:12:44 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23743; Thu, 28 Oct 2004 11:12:52 -0400 (EDT) Message-Id: <200410281512.LAA23743@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-04.txt Date: Thu, 28 Oct 2004 11:12:52 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-04.txt Pages : 10 Date : 2004-10-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110352.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCZX0063437; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFCZgN063436; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFCYCo063426 for ; Thu, 28 Oct 2004 08:12:35 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23727; Thu, 28 Oct 2004 11:12:43 -0400 (EDT) Message-Id: <200410281512.LAA23727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-09.txt Date: Thu, 28 Oct 2004 11:12:43 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-09.txt Pages : 11 Date : 2004-10-27 The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110347.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S1HrvG020706; Wed, 27 Oct 2004 18:17:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9S1HroQ020705; Wed, 27 Oct 2004 18:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S1HhNi020637 for ; Wed, 27 Oct 2004 18:17:43 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9S1GUZv066714; Thu, 28 Oct 2004 01:16:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027172544.03916390@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 18:16:58 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@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 04:49 PM 10/27/2004, Simon Josefsson wrote: >>>What I am looking for is text that say that the PLAIN server code >>>should treat the local password as a stored string. >> What's a "local password"? >I was trying to come up with a descriptive word for it, I think "stored" is pretty descriptive. >What is missing is that the password should be considered as a >stored string from the point of view of SASLPrep too, i.e., unassigned >code points are not allowed. I guess we'll have to agree to disagree here. I do not believe this is missing from the I-D. I find the paragraph you quoted is quite clear as to which strings are to be considered "query" strings and which are to be considered "stored" strings during string preparation. The I-D also provides pseudo-code and further discussion which reenforces which strings are to be considered "query" strings and which are to be considered "stored" strings during preparation. >>> The presented strings are to be regarded as "query" strings >>> [StringPrep], and the local strings as "stored" strings. >> >> What's a "local" string? And why are why defining it to >> the same as a "stored string". Now, you could say: >> stored strings are regarded as "stored" strings [StringPrep], >> but that is stating the obvious (IMO). >I think the terminology here is poor. "local string" is a poor term. >I want to differentiate between the "stored string" in the >StringPrep/SASLPrep sense, and the "local password" which the server >uses as input to the string preparation, and eventually uses to >compare with the presented password. Such a differentiation will, I think, lead to confusion. I think the text you offer is not better than the current text. I think it it is much worse than the current text. I think the current text is sufficiently clear. >Calling the latter "local password" a "stored string" implicitly >assume that SASLprep has already been applied to the string. And that >unassigned code points are forbidden in the output. But that cannot >be assumed, it is something that must be described by the document. > >To be more concrete: Here is the part of the document with normative >text regarding stored strings: > > Upon receipt of the message, the server will verify the presented > authentication identity (authcid) and password (passwd) with the > system authentication database, and verify the authentication > credentials permit the client to act as the (presented or derived) > authorization identity. If both steps succeed, the user is > authenticated. > > The presented authentication identity and password strings are not to > be compared directly with stored strings. The server SHALL first > prepare authentication identity and password strings using the > [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of > [StringPrep], unassigned code points may appear in prepared presented > (query) strings but are prohibited in stored strings. If preparation > fails or results in an empty string, verification SHALL fail. If the > server stores only the hash of expected string, the string MUST be > prepared before generation of the hash. > >An attempt to modify this into something I believe would be more >correct would be: > > Upon receipt of the message, the server will verify the presented > authentication identity (authcid) and password (passwd) with the > system authentication database, which contain the "local" password > for the authentication identity. What's a local password? Isn't the password shared with the user? Can't the password be stored remotely? And are you only applying the term "local" to the password? Wouldn't there also be a "local" authentication identity string as well. But that said, I also dislike explicitly describing the contents of the system authentication database. > Next, the server verify that the > authentication credentials permit the client to act as the > (presented or derived) authorization identity. If both steps > succeed, the user is authenticated. > > The presented authentication identity and password strings are not > to be compared directly with local strings. The server SHALL first > prepare authentication identity, presented password, and local > password using the [SASLPrep] profile of the [StringPrep] algorithm. > Per Section 7 of [StringPrep], unassigned code points may appear in > prepared presented (query) strings but are prohibited in local > (stored) strings. Is the stored authentication identity string a local string or a query string? Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNo8nC001674; Wed, 27 Oct 2004 16:50:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RNo8KO001673; Wed, 27 Oct 2004 16:50:08 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNo2f6001601 for ; Wed, 27 Oct 2004 16:50:03 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMxYH-0007V3-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 01:50:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Thu, 28 Oct 2004 01:49:56 +0200 Lines: 172 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> <6.1.2.0.0.20041027152519.037425d8@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:mXCHkFFaOa24J2DwNYuf2DzDZGA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 03:08 PM 10/27/2004, Simon Josefsson wrote: > >>"Kurt D. Zeilenga" writes: >> >>> At 11:42 AM 10/27/2004, Simon Josefsson wrote: >>> >>>>"Kurt D. Zeilenga" writes: >>>> >>>>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>>>Further, please make it explicit which strings are query strings and >>>>>>which are stored strings, >>>>> >>>>> Personally, I think the current text is sufficiently clear. >>>>> However, adding: >>>>> The presented strings are to be regarded as "query" >>>>> strings [StringPrep]. >>>>> as the 3rd sentence of the quoted paragraph could further >>>>> clarify which strings are to regarded as "query" strings. >>>>> I do not see any ambiguity as to which strings are to >>>>> be considered "stored" strings. >>>> >>>>A password that the server receive from some online external database >>>>(i.e., not "stored" locally) could be considered a query string (from >>>>the database) into the verification process. >>> >>> From a SASL PLAIN perspective, any such database as to be >>> viewed as part of the server implementation. Whether the >>> database is "internal" or "external" is simply an >>> implementation detail. From this perspective, the >>> password stored is a stored string. It's irrelevant >>> whether the server stores in a local or remote database. >> >>I don't think this follow from the specification. > > It follows from SASL PLAIN being a client/server protocol > specification. Everything on side is referred the client. > Everything on the other is referred to as the server. > The architecture of the client and server are irrelevant > to the protocol. It matters not whether the peer is > constructed from many components which interact in some > way or the peer is constructed as a monolith, because > the peers obligations to the other peer is the same > regardless. > >>What I am looking for is text that say that the PLAIN server code >>should treat the local password as a stored string. > > What's a "local password"? I was trying to come up with a descriptive word for it, but I guess I failed. What I meant by "local password" was the input password that the server end up using, after string preparation, in comparing the password provided by the client. The client provided password is the "presented" password, and the other password is "local" in the server. >>Currently, it >>seems to me that you and the PLAIN document only assume that the >>password can only be viewed as a stored string. > > The presented string is compared against a stored string > (or equivalent). Right. What is missing is that the password should be considered as a stored string from the point of view of SASLPrep too, i.e., unassigned code points are not allowed. > What the document doesn't say, and shouldn't > say, is in which component that comparison is made or > in what component of the server stored values are fetched > from or any other implementation detail. Agreed. >>It would be better if >>the document was explicit about it. >> >>The problem is rooted in that StringPrep (SASLPrep) do not define in >>who's view strings should be considered query or stored strings. > > Stringprep relies on incorporating specifications to detail > their view as to what is to be regarded as a query string > and what is to be regarded as a stored string. Agreed. And that detailing is what I believe could be improved in PLAIN. >>What >>is a stored string from one point of view, may be considered a query >>string from another point of view. So any document using SASLPrep >>must define which strings are query strings, and which are stored >>strings. It does not follow implicitly. > > The PLAIN ID does detail what is a query string and > a stored string. It uses the term "stored" string > repeated. And it uses the term "presented string" > in a manner which makes it clear that these are > query strings. It seems we are agreeing on the intention, but not what the document is saying. >>In lesser words, please modify your proposed sentence into the >>following and add it: >> >> The presented strings are to be regarded as "query" strings >> [StringPrep], and the local strings as "stored" strings. > > What's a "local" string? And why are why defining it to > the same as a "stored string". Now, you could say: > stored strings are regarded as "stored" strings [StringPrep], > but that is stating the obvious (IMO). I think the terminology here is poor. I want to differentiate between the "stored string" in the StringPrep/SASLPrep sense, and the "local password" which the server uses as input to the string preparation, and eventually uses to compare with the presented password. Calling the latter "local password" a "stored string" implicitly assume that SASLprep has already been applied to the string. And that unassigned code points are forbidden in the output. But that cannot be assumed, it is something that must be described by the document. To be more concrete: Here is the part of the document with normative text regarding stored strings: Upon receipt of the message, the server will verify the presented authentication identity (authcid) and password (passwd) with the system authentication database, and verify the authentication credentials permit the client to act as the (presented or derived) authorization identity. If both steps succeed, the user is authenticated. The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. An attempt to modify this into something I believe would be more correct would be: Upon receipt of the message, the server will verify the presented authentication identity (authcid) and password (passwd) with the system authentication database, which contain the "local" password for the authentication identity. Next, the server verify that the authentication credentials permit the client to act as the (presented or derived) authorization identity. If both steps succeed, the user is authenticated. The presented authentication identity and password strings are not to be compared directly with local strings. The server SHALL first prepare authentication identity, presented password, and local password using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in local (stored) strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of the expected password string, the string MUST be prepared, as a stored string, before generation of the hash. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNNrEY095342; Wed, 27 Oct 2004 16:23:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RNNr6r095341; Wed, 27 Oct 2004 16:23:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RNNqra095311 for ; Wed, 27 Oct 2004 16:23:52 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id i9RNNoKt066762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Oct 2004 17:23:52 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 27 Oct 2004 16:23:50 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: Re: CRAMing for last call Message-ID: <0BBA60D81C80944C3EE1A73A@peregrin.orthanc.ca> In-Reply-To: References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RNNrra095336 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-10-27 5:57 PM -0400 Sam Hartman wrote: > Simon> Finally, RFC 2104 is INFORMATIONAL. Can it be a normative > Simon> reference? > > Yes. Recently a BCP on dealing with this was published. Don't Panic!â„¢ Due to a seemingly-imminent disk failure on my laptop, I pushed out a preliminary version of the draft (as a backup measure more than anything). There will be another rev after the IETF, containing the editorial changes I've previously alluded to. The references will be fixed as part of that update. (And, I hope, the presentation/stored strings issues.) --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RMoYtd087436; Wed, 27 Oct 2004 15:50:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RMoYkx087435; Wed, 27 Oct 2004 15:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RMoSSw087410 for ; Wed, 27 Oct 2004 15:50:28 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RMoKZv066019; Wed, 27 Oct 2004 22:50:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027152519.037425d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 15:50:48 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@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 03:08 PM 10/27/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> At 11:42 AM 10/27/2004, Simon Josefsson wrote: >> >>>"Kurt D. Zeilenga" writes: >>> >>>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>>Further, please make it explicit which strings are query strings and >>>>>which are stored strings, >>>> >>>> Personally, I think the current text is sufficiently clear. >>>> However, adding: >>>> The presented strings are to be regarded as "query" >>>> strings [StringPrep]. >>>> as the 3rd sentence of the quoted paragraph could further >>>> clarify which strings are to regarded as "query" strings. >>>> I do not see any ambiguity as to which strings are to >>>> be considered "stored" strings. >>> >>>A password that the server receive from some online external database >>>(i.e., not "stored" locally) could be considered a query string (from >>>the database) into the verification process. >> >> From a SASL PLAIN perspective, any such database as to be >> viewed as part of the server implementation. Whether the >> database is "internal" or "external" is simply an >> implementation detail. From this perspective, the >> password stored is a stored string. It's irrelevant >> whether the server stores in a local or remote database. > >I don't think this follow from the specification. It follows from SASL PLAIN being a client/server protocol specification. Everything on side is referred the client. Everything on the other is referred to as the server. The architecture of the client and server are irrelevant to the protocol. It matters not whether the peer is constructed from many components which interact in some way or the peer is constructed as a monolith, because the peers obligations to the other peer is the same regardless. >What I am looking for is text that say that the PLAIN server code >should treat the local password as a stored string. What's a "local password"? >Currently, it >seems to me that you and the PLAIN document only assume that the >password can only be viewed as a stored string. The presented string is compared against a stored string (or equivalent). What the document doesn't say, and shouldn't say, is in which component that comparison is made or in what component of the server stored values are fetched from or any other implementation detail. >It would be better if >the document was explicit about it. > >The problem is rooted in that StringPrep (SASLPrep) do not define in >who's view strings should be considered query or stored strings. Stringprep relies on incorporating specifications to detail their view as to what is to be regarded as a query string and what is to be regarded as a stored string. >What >is a stored string from one point of view, may be considered a query >string from another point of view. So any document using SASLPrep >must define which strings are query strings, and which are stored >strings. It does not follow implicitly. The PLAIN ID does detail what is a query string and a stored string. It uses the term "stored" string repeated. And it uses the term "presented string" in a manner which makes it clear that these are query strings. >In lesser words, please modify your proposed sentence into the >following and add it: > > The presented strings are to be regarded as "query" strings > [StringPrep], and the local strings as "stored" strings. What's a "local" string? And why are why defining it to the same as a "stored string". Now, you could say: stored strings are regarded as "stored" strings [StringPrep], but that is stating the obvious (IMO). >> (I'm getting a sense of "deja vu" here, didn't we already >> discuss this issue? If so, is there a particular reason >> why we should repeat that discussion?) > >I don't recall what the conclusion was of any earlier discussion, if >any, and I believe the current document should be improved. > >>> From the server's point >>>of view, it is "querying" whether the password it knows is the same as >>>the one provided by the client. So I see an ambiguity. >>> >>>Thanks. >> >> It seems you are saying: >> From the server's point of view, the server is >> "querying" whether the password the server knows >> is the same as the one provided by the client. >> >> Er, in this case, I think server is "determining" would >> be a more appropriate verb as its not clear who the >> server would be querying to do a comparison between >> the password it knows (e.g., stored string) and the one >> provided by the client (e.g., the presented string). >> >> But as this makes little sense in the context of the above >> discussion, so you must have meant to say something else. >> Please clarify. > >To my reading, your explanation describe what I mean. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM8it1079003; Wed, 27 Oct 2004 15:08:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RM8iuU079002; Wed, 27 Oct 2004 15:08:44 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM8gFS078992 for ; Wed, 27 Oct 2004 15:08:43 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMvyJ-0003F6-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Oct 2004 00:08:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Thu, 28 Oct 2004 00:08:43 +0200 Lines: 82 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> <6.1.2.0.0.20041027122606.032cad30@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:XO4jfXh1J93c9S3+sXyTDxTDUyE= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 11:42 AM 10/27/2004, Simon Josefsson wrote: > >>"Kurt D. Zeilenga" writes: >> >>> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>>Further, please make it explicit which strings are query strings and >>>>which are stored strings, >>> >>> Personally, I think the current text is sufficiently clear. >>> However, adding: >>> The presented strings are to be regarded as "query" >>> strings [StringPrep]. >>> as the 3rd sentence of the quoted paragraph could further >>> clarify which strings are to regarded as "query" strings. >>> I do not see any ambiguity as to which strings are to >>> be considered "stored" strings. >> >>A password that the server receive from some online external database >>(i.e., not "stored" locally) could be considered a query string (from >>the database) into the verification process. > > From a SASL PLAIN perspective, any such database as to be > viewed as part of the server implementation. Whether the > database is "internal" or "external" is simply an > implementation detail. From this perspective, the > password stored is a stored string. It's irrelevant > whether the server stores in a local or remote database. I don't think this follow from the specification. What I am looking for is text that say that the PLAIN server code should treat the local password as a stored string. Currently, it seems to me that you and the PLAIN document only assume that the password can only be viewed as a stored string. It would be better if the document was explicit about it. The problem is rooted in that StringPrep (SASLPrep) do not define in who's view strings should be considered query or stored strings. What is a stored string from one point of view, may be considered a query string from another point of view. So any document using SASLPrep must define which strings are query strings, and which are stored strings. It does not follow implicitly. In lesser words, please modify your proposed sentence into the following and add it: The presented strings are to be regarded as "query" strings [StringPrep], and the local strings as "stored" strings. > (I'm getting a sense of "deja vu" here, didn't we already > discuss this issue? If so, is there a particular reason > why we should repeat that discussion?) I don't recall what the conclusion was of any earlier discussion, if any, and I believe the current document should be improved. >> From the server's point >>of view, it is "querying" whether the password it knows is the same as >>the one provided by the client. So I see an ambiguity. >> >>Thanks. > > It seems you are saying: > From the server's point of view, the server is > "querying" whether the password the server knows > is the same as the one provided by the client. > > Er, in this case, I think server is "determining" would > be a more appropriate verb as its not clear who the > server would be querying to do a comparison between > the password it knows (e.g., stored string) and the one > provided by the client (e.g., the presented string). > > But as this makes little sense in the context of the above > discussion, so you must have meant to say something else. > Please clarify. To my reading, your explanation describe what I mean. Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM4bVG078370; Wed, 27 Oct 2004 15:04:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RM4bRn078369; Wed, 27 Oct 2004 15:04:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RM4a4U078363 for ; Wed, 27 Oct 2004 15:04:36 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id E101F178025; Wed, 27 Oct 2004 18:04:53 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> From: Sam Hartman Date: Wed, 27 Oct 2004 18:04:53 -0400 In-Reply-To: <417AB364.6050503@isode.com> (Alexey Melnikov's message of "Sat, 23 Oct 2004 20:39:16 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> 1). "indicate that re-keying is or will be needed Alexey> immediately". The first question I have after reading Alexey> this sentence is "how?" Because SASL framework doesn't Alexey> have any control channel or out-of-band mechanism, the Alexey> only answer to this question is "by transparently Alexey> including re-keying messages in the security layer". But Alexey> this is a part of what the subsequent sentence is saying!? By returning some status to the application or setting a flag. You can generally tell you need to re-key without sending anything over the wire. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLvNZK077160; Wed, 27 Oct 2004 14:57:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLvNcB077159; Wed, 27 Oct 2004 14:57:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLvM9D077152 for ; Wed, 27 Oct 2004 14:57:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0F879178025; Wed, 27 Oct 2004 17:57:39 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: CRAMing for last call References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> From: Sam Hartman Date: Wed, 27 Oct 2004 17:57:39 -0400 In-Reply-To: (Simon Josefsson's message of "Wed, 27 Oct 2004 00:55:10 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> Finally, RFC 2104 is INFORMATIONAL. Can it be a normative Simon> reference? Yes. Recently a BCP on dealing with this was published. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLbX2b072483; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLbXZw072482; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLbXUJ072475 for ; Wed, 27 Oct 2004 14:37:33 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 5659C178025; Wed, 27 Oct 2004 17:37:54 -0400 (EDT) To: ietf-sasl@imc.org Subject: Sending anonymous and plain to the IESG Message-Id: <20041027213754.5659C178025@cz.mit.edu> Date: Wed, 27 Oct 2004 17:37:54 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. It's my intent to do an id-nits review on plain and anonymous. Assuming I see no problems I'll send them to the IESG early next week. If there are resaons this should not happen please let me know before then. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLYZVl071922; Wed, 27 Oct 2004 14:34:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLYZR3071921; Wed, 27 Oct 2004 14:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RLYQpu071862 for ; Wed, 27 Oct 2004 14:34:26 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C8F31178025; Wed, 27 Oct 2004 17:34:29 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> From: Sam Hartman Date: Wed, 27 Oct 2004 17:34:29 -0400 In-Reply-To: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 27 Oct 2004 11:09:47 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >> Further, please make it explicit which strings are query >> strings and which are stored strings, Kurt> Personally, I think the current text is sufficiently clear. Kurt> However, adding: The presented strings are to be regarded as Kurt> "query" strings [StringPrep]. as the 3rd sentence of the Kurt> quoted paragraph could further clarify which strings are to Kurt> regarded as "query" strings. I do not see any ambiguity as Kurt> to which strings are to be considered "stored" strings. In my mind adding this text makes the draft more confusing and does not add anything. It's my opinion that the working group has already reached consensus on this draft. If people believe that the draft does not reflect that consensus, please bring forward that disagreement. However the bar for opening new issues should be very high at this point. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJQjoM041532; Wed, 27 Oct 2004 12:26:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RJQjv2041531; Wed, 27 Oct 2004 12:26:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJQbK8041473 for ; Wed, 27 Oct 2004 12:26:37 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RJQTZv064526; Wed, 27 Oct 2004 19:26:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027122606.032cad30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 12:26:57 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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:42 AM 10/27/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>>Further, please make it explicit which strings are query strings and >>>which are stored strings, >> >> Personally, I think the current text is sufficiently clear. >> However, adding: >> The presented strings are to be regarded as "query" >> strings [StringPrep]. >> as the 3rd sentence of the quoted paragraph could further >> clarify which strings are to regarded as "query" strings. >> I do not see any ambiguity as to which strings are to >> be considered "stored" strings. > >A password that the server receive from some online external database >(i.e., not "stored" locally) could be considered a query string (from >the database) into the verification process. From a SASL PLAIN perspective, any such database as to be viewed as part of the server implementation. Whether the database is "internal" or "external" is simply an implementation detail. From this perspective, the password stored is a stored string. It's irrelevant whether the server stores in a local or remote database. (I'm getting a sense of "deja vu" here, didn't we already discuss this issue? If so, is there a particular reason why we should repeat that discussion?) > From the server's point >of view, it is "querying" whether the password it knows is the same as >the one provided by the client. So I see an ambiguity. > >Thanks. It seems you are saying: From the server's point of view, the server is "querying" whether the password the server knows is the same as the one provided by the client. Er, in this case, I think server is "determining" would be a more appropriate verb as its not clear who the server would be querying to do a comparison between the password it knows (e.g., stored string) and the one provided by the client (e.g., the presented string). But as this makes little sense in the context of the above discussion, so you must have meant to say something else. Please clarify. Thanks, Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RIgGLp032185; Wed, 27 Oct 2004 11:42:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RIgGaX032184; Wed, 27 Oct 2004 11:42:16 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RIgBwP032142 for ; Wed, 27 Oct 2004 11:42:11 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMskQ-0004a7-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 20:42:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 20:42:10 +0200 Lines: 22 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <6.1.2.0.0.20041027103607.033ba308@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Ud3K8wx8XSwuABa0BbPTfWwy0Ak= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 02:30 AM 10/27/2004, Simon Josefsson wrote: >>Further, please make it explicit which strings are query strings and >>which are stored strings, > > Personally, I think the current text is sufficiently clear. > However, adding: > The presented strings are to be regarded as "query" > strings [StringPrep]. > as the 3rd sentence of the quoted paragraph could further > clarify which strings are to regarded as "query" strings. > I do not see any ambiguity as to which strings are to > be considered "stored" strings. A password that the server receive from some online external database (i.e., not "stored" locally) could be considered a query string (from the database) into the verification process. From the server's point of view, it is "querying" whether the password it knows is the same as the one provided by the client. So I see an ambiguity. Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RI9cHY025280; Wed, 27 Oct 2004 11:09:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RI9cFO025279; Wed, 27 Oct 2004 11:09:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RI9VX2025247 for ; Wed, 27 Oct 2004 11:09:31 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RI9KZv064032; Wed, 27 Oct 2004 18:09:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027103607.033ba308@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 11:09:47 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@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 02:30 AM 10/27/2004, Simon Josefsson wrote: >Further, please make it explicit which strings are query strings and >which are stored strings, Personally, I think the current text is sufficiently clear. However, adding: The presented strings are to be regarded as "query" strings [StringPrep]. as the 3rd sentence of the quoted paragraph could further clarify which strings are to regarded as "query" strings. I do not see any ambiguity as to which strings are to be considered "stored" strings. >and mention the value of the AllowUnassigned >flag for each string using MUST. I cannot find the term "AllowUnassigned flag" anywhere in the specification (including normative references). The text does, however, not only says that strings SHALL be prepared in accordance with StringPrep, it describes what that means in regards to unassigned code points and the two classes of strings. >It seems the intention is that all >strings received from the client are query strings, and the password >(whether stored in unprepared, prepared or hashed form) is a stored >string. If you don't see why this is necessary, I can elaborate. > > The presented authentication identity and password strings are not to > be compared directly with stored strings. The server SHALL first > prepare authentication identity and password strings using the > [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of > [StringPrep], unassigned code points may appear in prepared presented > (query) strings but are prohibited in stored strings. If preparation > fails or results in an empty string, verification SHALL fail. If the > server stores only the hash of expected string, the string MUST be > prepared before generation of the hash. > >Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDZsPx062923; Wed, 27 Oct 2004 06:35:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RDZsjU062922; Wed, 27 Oct 2004 06:35:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDZlsn062865 for ; Wed, 27 Oct 2004 06:35:47 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMnxs-00012v-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 15:35:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 15:35:45 +0200 Lines: 18 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> <200410271008.i9RA8YtM038902@lab.smi.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:mIZaNd32vnjtOx2B4CKBn3FDtNA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther writes: > Simon Josefsson writes: >>Why is SHALL used instead of MUST in the paragraph below? > > Per RFC 2119, SHALL and MUST have the same meaning: > --- > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > --- Oops, what a thinko. Thanks. Still, making explicit which strings are to be considered query strings and stored strings still seem useful. Sorry, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RA8n4e095870; Wed, 27 Oct 2004 03:08:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RA8na0095868; Wed, 27 Oct 2004 03:08:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RA8mdC095857 for ; Wed, 27 Oct 2004 03:08:48 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id i9RA8bjx000677 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 27 Oct 2004 03:08:37 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i9RA8bjx000677 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=DqG8nxUzrSWL4xp2xCFC3STMLeyrM88ZvgEA2X7brDg4OFeDd5MUfy99er/hf1vAI Ugd2nouS+G3qjLoLM0cgCAhwbDHDgU4rbjKFbYedG4EMtau8EuFXjNydUqJTE3EEZdl okBgD9Vnibz3hr+F+KmywVIIy5lBfFB8uzuEwns= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i9RA8YtM038902; Wed, 27 Oct 2004 03:08:36 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200410271008.i9RA8YtM038902@lab.smi.sendmail.com> To: Simon Josefsson Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt In-reply-to: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> Date: Wed, 27 Oct 2004 03:08:34 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson writes: >Why is SHALL used instead of MUST in the paragraph below? Per RFC 2119, SHALL and MUST have the same meaning: --- 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. --- Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9asIm080585; Wed, 27 Oct 2004 02:36:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9asHc080584; Wed, 27 Oct 2004 02:36:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9arUW080572 for ; Wed, 27 Oct 2004 02:36:53 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMkEg-0005Ou-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:36:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt Date: Wed, 27 Oct 2004 11:36:50 +0200 Lines: 15 Message-ID: References: <200410262104.RAA21521@ietf.org> <6.1.2.0.0.20041026192702.0308a5d0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Jhj0urqIfmtxV2f3w+FxW6epL+k= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For what it's worth, I reviewed the document and it looks good to me. A small nit though. The following paragraph The ANONYMOUS mechanism grants access to services and/or resources by anyone. For this reason it should be disabled by default so the administrator can make an explicit decision to enable it. might imply something that wasn't intended. It seems some protocols could be anonymous in nature (think NNTP). Then it wouldn't make sense to require administrators to explicitly enable ANONYMOUS. ANONYMOUS logins to NNTP servers can be meaningful, think of the trace information provided. Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9Ulgg077558; Wed, 27 Oct 2004 02:30:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9UlDT077557; Wed, 27 Oct 2004 02:30:47 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9UkZ2077539 for ; Wed, 27 Oct 2004 02:30:46 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMk8k-0005AA-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 11:30:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Wed, 27 Oct 2004 11:30:34 +0200 Lines: 23 Message-ID: References: <200410262104.RAA21555@ietf.org> <6.1.2.0.0.20041026193243.0308cd18@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:v0Tq52Rg8FxsYAYq6YR3k1Vb2UY= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Why is SHALL used instead of MUST in the paragraph below? Are there known situations where PLAIN will be used without SASLPrep? Why shouldn't a failed string preparation always lead to verification failure? Further, please make it explicit which strings are query strings and which are stored strings, and mention the value of the AllowUnassigned flag for each string using MUST. It seems the intention is that all strings received from the client are query strings, and the password (whether stored in unprepared, prepared or hashed form) is a stored string. If you don't see why this is necessary, I can elaborate. The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 of [StringPrep], unassigned code points may appear in prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2k6Gn013685; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R2k6EP013684; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2k5Pi013678 for ; Tue, 26 Oct 2004 19:46:06 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9R2kCZv057945 for ; Wed, 27 Oct 2004 02:46:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026193243.0308cd18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 19:46:42 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt In-Reply-To: <200410262104.RAA21555@ietf.org> References: <200410262104.RAA21555@ietf.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: In this revision, aside from minor editorial changes, the message clarified to be a string of UTF-8 encoded Unicode characters and the use of %x00 for NULL (U+0000) was clarified to be the UTF-8 encoding of the NULL character. I believe this document should now be progressed to the IESG. -- Kurt PS: the double blanklines in the I-D is a new Secretariat'ism which seems to be inflicted on new I-Ds. At 02:04 PM 10/26/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : The Plain SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-plain-05.txt > Pages : 9 > Date : 2004-10-26 > >This document defines a simple clear-text user/password Simple >Authentication and Security Layer (SASL) mechanism called the PLAIN >mechanism. The PLAIN mechanism intended to be used, in combination >with data confidentiality services provided by a lower layer, in >protocols which lack a simple password authentication command. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-plain-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-plain-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-26161223.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-plain-05.txt > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2Vp7t010309; Tue, 26 Oct 2004 19:31:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R2Vp4T010308; Tue, 26 Oct 2004 19:31:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2VoY9010252 for ; Tue, 26 Oct 2004 19:31:50 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9R2VkZv057836 for ; Wed, 27 Oct 2004 02:31:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026192702.0308a5d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 19:32:16 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt In-Reply-To: <200410262104.RAA21521@ietf.org> References: <200410262104.RAA21521@ietf.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: In this revision, aside from editorial changes, the following change was made: - The purpose of the mechanism was clarified. I believe this document should now be progressed to the IESG. Kurt At 02:04 PM 10/26/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : The Anonymous SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-anon-04.txt > Pages : 9 > Date : 2004-10-26 > >It is common practice on the Internet to permit anonymous access to >various services. Traditionally, this has been done with a plain text >password mechanism using 'anonymous' as the user name and optional >trace information, such as an email address, as the password. As >plaintext login commands are not permitted in new IETF protocols, a >new way to provide anonymous login is needed within the context of the >Simple Authentication and Security Layer (SASL) framework. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-anon-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-anon-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-26161218.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-anon-04.txt > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMtOpQ058244; Tue, 26 Oct 2004 15:55:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QMtODC058243; Tue, 26 Oct 2004 15:55:24 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMtGYw058200 for ; Tue, 26 Oct 2004 15:55:16 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMaDi-0007u8-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 00:55:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: CRAMing for last call Date: Wed, 27 Oct 2004 00:55:10 +0200 Lines: 70 Message-ID: References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:7HnbOMol+wB6oa5kJXxJLx9Ko/E= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello. Some comments on the latest cram-md5 draft. In this post: http://thread.gmane.org/gmane.ietf.sasl/1457 Kurt suggest to explain why the IANA USAGE field of CRAM-MD5 is LIMITED. I too believe this would be useful, to make readers realize they might want PLAIN+TLS, DIGEST-MD5 or GSSAPI instead. There are a few (minor, mostly editorial) suggestions in Kurt's post that has not been addressed, that I believe make sense. Next, I believe it would be useful to tighten up the language in the following paragraph: The mechanism starts with the server issuing a challenge. The data encoded in the challenge contains a presumptively arbitrary string of random data. I suggest to remove "presumptively arbitrary" and add a reference to RFC 1750 after the word "random". Possibly it could be worded differently, because there is quite some structure in the challenge, not complete random data. I read RFC 2104, but it does not say anything about randomness or structure of the challenge text. It may be useful to find some other reference on the properties of challenge strings in CRAM-MD5, or to ask the CFRG for guidance. Next, there were discussion regarding SASLprep unassigned code points in this thread: http://thread.gmane.org/gmane.ietf.sasl/1342 I agree with Kurt that it should be clarified that the client copy of the user name and shared secret should be defined as query strings. I think this would be achieved by adding after: The client MUST prepare the user name and shared secret strings using the SASLPrep [draft-ietf-sasl-saslprep] profile of the StringPrep [RFC3454] algorithm. the following: The client MUST treat the user name and shared secret string as query strings, consequently unassigned code points should be allowed in the prepared output. The server MUST treat the received user name, and the password (regardless of whether it is in unprepared, prepared or hashed form), as stored strings, and consequently disallow unassigned code points in the prepared output that is used as input to the keyed hash operation. Without such text, there is an ambiguity how to invoke SASLPrep. I believe the text belong in CRAM-MD5, as string preparation is a mechanism issue. It does not seem to belong in SASLPrep or 2222bis. Further, RFC 2279 has been obsoleted by RFC 3629: The resulting values MUST be encoded as UTF-8 [RFC2279] strings. I suggest adding a paragraph break after the previous sentence, and the generic recommendations on storing prepared strings. Next, because CRAM-MD5 do not provide a security layer, it should have a reference to TLS and some security consideration suggesting TLS, or similar, if active attacks or privacy issues are a threat. Compare PLAIN. Finally, RFC 2104 is INFORMATIONAL. Can it be a normative reference? Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4iAR035779; Tue, 26 Oct 2004 14:04:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL4i8S035778; Tue, 26 Oct 2004 14:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4gVH035772 for ; Tue, 26 Oct 2004 14:04:43 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21555; Tue, 26 Oct 2004 17:04:44 -0400 (EDT) Message-Id: <200410262104.RAA21555@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-05.txt Date: Tue, 26 Oct 2004 17:04:44 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-05.txt Pages : 9 Date : 2004-10-26 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161223.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4QEW035734; Tue, 26 Oct 2004 14:04:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL4QPe035733; Tue, 26 Oct 2004 14:04:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL4O35035718 for ; Tue, 26 Oct 2004 14:04:25 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21521; Tue, 26 Oct 2004 17:04:25 -0400 (EDT) Message-Id: <200410262104.RAA21521@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-anon-04.txt Date: Tue, 26 Oct 2004 17:04:25 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Anonymous SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-anon-04.txt Pages : 9 Date : 2004-10-26 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-anon-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-anon-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-anon-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-anon-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161218.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PJ4MbD004185; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PJ4MAA004184; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PJ4LYn004151 for ; Mon, 25 Oct 2004 12:04:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 788E3168027; Mon, 25 Oct 2004 15:04:35 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.com> <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> From: Sam Hartman Date: Mon, 25 Oct 2004 15:04:35 -0400 In-Reply-To: <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 24 Oct 2004 19:40:18 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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 view on re-keying is that its just another layer security Kurt> service that a mechanism can offer. In regards to the SASL Kurt> framework specification, how it does so (on the wire) is Kurt> something for the mechanism specification to detail. And Kurt> how an developer of an application protocol provides support Kurt> for this mechanism is an implementation detail. The Kurt> framework simply should not concern itself with such Kurt> The design of any SASL API is limited by which mechanism Kurt> aspects and protocol aspects which were accounted for in the Kurt> design. If a new mechanism has aspects not previously Kurt> considered by designers of a particular SASL API, then the Kurt> designers of that SASL API might want to redesign their API Kurt> to account for the new aspect... or decide that they simply Kurt> cannot support that mechanism (or aspect of that mechanism). Kurt> While we could constraint future mechanisms to currently Kurt> known aspects, I think that's unwise and counter to Kurt> character of SASL. It's been my experience in other IETF work that it is strongly desirable for framework documents to enumerate the aspects of mechanisms of the framework that are generally applicable at the time the framework document is written. Doing so is useful to API and implementation designers. However I cannot claim today that support for this service (re-keying) is generally available in today's SASL mechanisms. So I agree that this revision of the framework should not concern itself with that service. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PIbeJV097613; Mon, 25 Oct 2004 11:37:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PIbdig097612; Mon, 25 Oct 2004 11:37:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PIbcBV097581 for ; Mon, 25 Oct 2004 11:37:39 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9PIbeZv045908; Mon, 25 Oct 2004 18:37:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041025112650.03231a28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 25 Oct 2004 11:38:12 -0700 To: Nicolas Williams From: "Kurt D. Zeilenga" Subject: Re: Life of a security layer and error handling Cc: Sam Hartman , Alexey Melnikov , SASL WG In-Reply-To: <20041025172037.GS21427@binky.central.sun.com> References: <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> <20041025172037.GS21427@binky.central.sun.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:20 AM 10/25/2004, Nicolas Williams wrote: >On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote: >> I don't think there is current WG consensus to support something as >> strong as a requirement. > >Well, yeah, technically it's hard to impose requirements on future >protocol work :) And its even harder to impose a particular kind of solution to a security consideration. Rekeying is a possible solution to a security consideration. It's not the only viable solution to that security consideration. The framework specification should elaborate on the security consideration regarding the life of the layer and leave it to mechanism designers to determine how to best address these issues. It might be okay to suggest the designer consider particular solutions, but I do not think it appropriate to recommend a particular solution be used in all future mechanisms. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PHKuBW078791; Mon, 25 Oct 2004 10:20:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PHKu1S078790; Mon, 25 Oct 2004 10:20:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PHKtDe078784 for ; Mon, 25 Oct 2004 10:20:55 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9PHKwNH010457 for ; Mon, 25 Oct 2004 11:20:58 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PHKwjW000574 for ; Mon, 25 Oct 2004 11:20:58 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9PHKbnF019540; Mon, 25 Oct 2004 12:20:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9PHKbJk019539; Mon, 25 Oct 2004 12:20:37 -0500 (CDT) Date: Mon, 25 Oct 2004 12:20:37 -0500 From: Nicolas Williams To: Sam Hartman Cc: Alexey Melnikov , SASL WG Subject: Re: Life of a security layer and error handling Message-ID: <20041025172037.GS21427@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Alexey Melnikov , SASL WG References: <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote: > I don't think there is current WG consensus to support something as > strong as a requirement. Well, yeah, technically it's hard to impose requirements on future protocol work :) I must have been hoping that some verbiage to that effect would make it easier to force the matter later when new mechs/mech revisions come along. But I think you're right. IOW, I will settle for Security Considerations text on this. > I believe Kurt's summary is consistent with this position. > > I would certainly encourage you to make sure all new SASL mechanisms > support rekeying; I certainly plan to try and do the same. Thank you. I will. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGpY8E070929; Mon, 25 Oct 2004 09:51:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGpYSk070928; Mon, 25 Oct 2004 09:51:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGpXpY070916 for ; Mon, 25 Oct 2004 09:51:33 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C539D168027; Mon, 25 Oct 2004 12:51:45 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> <20041025161906.GN21427@binky.central.sun.com> From: Sam Hartman Date: Mon, 25 Oct 2004 12:51:45 -0400 In-Reply-To: <20041025161906.GN21427@binky.central.sun.com> (Nicolas Williams's message of "Mon, 25 Oct 2004 11:19:07 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman Nicolas> wrote: >> I think Nico and some others would argue there is a problem >> with the SASL framework: it doesn't support rekeying at the >> SASL level. It clearly could be changed to do so; we as a a >> working group have decided not to do so. I think we made that >> decision for a lot of good reasons. Nicolas> I agree that existing SASL mechanisms' lack of re-keying Nicolas> support should be grandfathered. Nicolas> Going forward though I see no good reason not to require Nicolas> support for re-keying (or re-key-less ciphers/modes) in Nicolas> new/revised SASL mechanisms, that includes the revised Nicolas> GSS mechs draft. I don't think there is current WG consensus to support something as strong as a requirement. I believe Kurt's summary is consistent with this position. I would certainly encourage you to make sure all new SASL mechanisms support rekeying; I certainly plan to try and do the same. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGJRPK063024; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGJRvM063023; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGJRiC063017 for ; Mon, 25 Oct 2004 09:19:27 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9PGJU7q017678 for ; Mon, 25 Oct 2004 09:19:30 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PGJTjW015900 for ; Mon, 25 Oct 2004 10:19:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9PGJ8ZV019484; Mon, 25 Oct 2004 11:19:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9PGJ7UR019483; Mon, 25 Oct 2004 11:19:07 -0500 (CDT) Date: Mon, 25 Oct 2004 11:19:07 -0500 From: Nicolas Williams To: Sam Hartman Cc: Alexey Melnikov , SASL WG Subject: Re: Life of a security layer and error handling Message-ID: <20041025161906.GN21427@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Alexey Melnikov , SASL WG References: <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> <87vfcy99aw.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vfcy99aw.fsf@luminous.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman wrote: > > I think Nico and some others would argue there is a problem with the > SASL framework: it doesn't support rekeying at the SASL level. It > clearly could be changed to do so; we as a a working group have > decided not to do so. I think we made that decision for a lot of good > reasons. I agree that existing SASL mechanisms' lack of re-keying support should be grandfathered. Going forward though I see no good reason not to require support for re-keying (or re-key-less ciphers/modes) in new/revised SASL mechanisms, that includes the revised GSS mechs draft. (If SASL were a new proposal today, would a spec w/o re-keying get past WG, IETF and IESG reviews? I rather doubt it.) > If you want to rework the text, I'd recommend making it be > fault-agnostic. Simply describe the effect without trying to claim > any of the specs involved are broken. Heh. But see above. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PEBtop041904; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PEBte5041903; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PEBtfG041897 for ; Mon, 25 Oct 2004 07:11:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 6AA6F7681D; Mon, 25 Oct 2004 10:11:51 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> <417D0188.9020409@isode.com> From: Sam Hartman Date: Mon, 25 Oct 2004 10:11:51 -0400 In-Reply-To: <417D0188.9020409@isode.com> (Alexey Melnikov's message of "Mon, 25 Oct 2004 14:37:12 +0100") Message-ID: <87vfcy99aw.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Nico and some others would argue there is a problem with the SASL framework: it doesn't support rekeying at the SASL level. It clearly could be changed to do so; we as a a working group have decided not to do so. I think we made that decision for a lot of good reasons. If you want to rework the text, I'd recommend making it be fault-agnostic. Simply describe the effect without trying to claim any of the specs involved are broken. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDbFGf039596; Mon, 25 Oct 2004 06:37:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDbFsP039595; Mon, 25 Oct 2004 06:37:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDbDP8039589 for ; Mon, 25 Oct 2004 06:37:14 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 14:37:12 +0100 Message-ID: <417D0188.9020409@isode.com> Date: Mon, 25 Oct 2004 14:37:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> <87pt379bnm.fsf@luminous.mit.edu> In-Reply-To: <87pt379bnm.fsf@luminous.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Alexey> Imagine that support for re-keying can be done without > Alexey> changing (extending) GSS API. > >I did. Unfortunately, Nico convinced me that my fantasy had no basis >in reality. You cannot guarantee that both parties are sending, which >is required for rekeying. ALso, you have bad interactions with >gss_wrap_size_limit. > > Then we need to update the SASL GSSAPI document (suggestions are welcome). > Alexey> In this case the SASL GSSAPI > Alexey> spec doesn't have to be updated. In which case the > Alexey> following text can be removed from 2222bis: > > Alexey> In practice one likely effect of administrative security > Alexey> layers lifetime limits is that applications may find that > Alexey> security layers stop working in the middle of application > Alexey> protocol operation, such as, perhaps, during large data > Alexey> transfers. > >I agree that implementations that work this way are broken. Nico does >not. Nor does the IETF; RFC 1964 mandates this behavior. > > The paragraph as written may suggest that there is a problem with SASL framework, when there is none. The text has to be rewritten to clarify that. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDOqb3038457; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDOqZ3038456; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDOqhO038450 for ; Mon, 25 Oct 2004 06:24:52 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 45AF17681D; Mon, 25 Oct 2004 09:24:48 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> From: Sam Hartman Date: Mon, 25 Oct 2004 09:24:47 -0400 In-Reply-To: <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 24 Oct 2004 19:16:13 -0700") Message-ID: <87lldv9bhc.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: >> Kurt> But, without that qualification, I would have to disagree. Kurt> For instance, an application protocol can certainly detail Kurt> how authentication identities are to represented in Kurt> identity-assumption policy information carried by the Kurt> protocol, and associated semantics. >> I agree that they can do so in the sense that if the IESG >> approved it, it would be a protocol action. Kurt> LDAP and IMAP ACLs. Kurt> What's good is a standardize access control policy if the Kurt> standard does say how identities used in the authentication Kurt> exchange relate to identities appearing in the policy? Kurt> Say an administrative client has created a Kerberos Kurt> principal for a user and then wants to authorize that user Kurt> to access an object on an LDAP server. What DN should the Kurt> administrative client use as the subject of the LDAP access Kurt> control statement? I was thinking too narrowly. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDLCqk038129; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDLCeh038128; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDLBpG038120 for ; Mon, 25 Oct 2004 06:21:12 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 0014C7681D; Mon, 25 Oct 2004 09:21:01 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> From: Sam Hartman Date: Mon, 25 Oct 2004 09:21:01 -0400 In-Reply-To: <417CD4D7.1050406@isode.com> (Alexey Melnikov's message of "Mon, 25 Oct 2004 11:26:31 +0100") Message-ID: <87pt379bnm.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Sam Hartman wrote: Nicolas> Should existing mechanisms' layers expire when the Nicolas> session key material's useful lifetime (in terms of time Nicolas> or use) is exceeded? >> I believe that SASL mechanisms should try to avoid expiring >> the connection when key lifetime is exceeded because doing so >> creates an unacceptable user experience. >> Alexey> I concur. >> There exist mechanisms that will expire though like some >> implementations of the GSSAPI mechanism. >> >> Alexey> Are we talking about GSSAPI in general or a particular Alexey> implementation of GSSAPI? We're talking about RFC 1964 and most implementations of that spec. Alexey> Imagine that support for re-keying can be done without Alexey> changing (extending) GSS API. I did. Unfortunately, Nico convinced me that my fantasy had no basis in reality. You cannot guarantee that both parties are sending, which is required for rekeying. ALso, you have bad interactions with gss_wrap_size_limit. Alexey> In this case the SASL GSSAPI Alexey> spec doesn't have to be updated. In which case the Alexey> following text can be removed from 2222bis: Alexey> In practice one likely effect of administrative security Alexey> layers lifetime limits is that applications may find that Alexey> security layers stop working in the middle of application Alexey> protocol operation, such as, perhaps, during large data Alexey> transfers. I agree that implementations that work this way are broken. Nico does not. Nor does the IETF; RFC 1964 mandates this behavior. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PBIGXM025152; Mon, 25 Oct 2004 04:18:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PBIGVe025150; Mon, 25 Oct 2004 04:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PBICIq025112 for ; Mon, 25 Oct 2004 04:18:12 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 12:17:55 +0100 Message-ID: <417CE0E3.2080401@isode.com> Date: Mon, 25 Oct 2004 12:17:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041001155050.0417fbc0@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: >>For comparison, here is part of the old text: >> >> Any normalization of the authentication identity is defined by a >> particular SASL mechanism, the protocol profile doesn't influence it. >> >> > >Though I think this needs to be slightly reworded, I agree >with the intent of the statement to say that protocol >profiles should leave of aspects of credentials and their >verification to the mechanism. However, this in no way >implies that an application protocol specification, or >its implementations, cannot detail the form of authentication >identity the application protocol (or implementation) might >use otherwise. For instance, an application protocol >specification could detail how to represent authentication >identities in an identity assumption authorization policy. > > I've updated the existing sentence as follows (I am still not satisfied with how it looks): Any normalization of the authentication identity (for the purposes of conducting authentication exchange) is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Note, that the mechanism specification doesn't control how authentication identity information is represented elsewhere. I think we need to expand on "elsewhere" part. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAdJ3f009184; Mon, 25 Oct 2004 03:39:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PAdJUn009183; Mon, 25 Oct 2004 03:39:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAdIcC009169 for ; Mon, 25 Oct 2004 03:39:18 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 11:39:18 +0100 Message-ID: <417CD7D6.70804@isode.com> Date: Mon, 25 Oct 2004 11:39:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: SASL WG Subject: Re-keying (was Re: Life of a security layer and error handling) References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> <417CD4D7.1050406@isode.com> In-Reply-To: <417CD4D7.1050406@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Sam Hartman wrote: > >> Nicolas> Should >> Nicolas> existing mechanisms' layers expire when the session key >> Nicolas> material's useful lifetime (in terms of time or use) is >> Nicolas> exceeded? >> >> I believe that SASL mechanisms should try to avoid expiring the >> connection when key lifetime is exceeded because doing so creates an >> unacceptable user experience. > > I concur. > >> There exist mechanisms that will expire >> though like some implementations of the GSSAPI mechanism. > > Are we talking about GSSAPI in general or a particular implementation > of GSSAPI? > > Imagine that support for re-keying can be done without changing > (extending) GSS API. In this case the SASL GSSAPI spec doesn't have to > be updated. > In which case the following text can be removed from 2222bis: > > In practice one likely effect of administrative security layers > lifetime limits is that applications may find that security layers > stop working in the middle of application protocol operation, such > as, perhaps, during large data transfers. > > ? > (or at least it has to be reworded to talk about "broken" or "old" > implementations) I've kept the paragraph for now, here is the latest text about re-keying in Security considerations (as there is very little time before the draft submission deadline, I am going to send the updated 2222bis now): The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. Cryptographic keys weaken as they are used and as time passes; the more time and/or ciphertext that a cryptanalyst has after the first use of the a key, the easier it is for the cryptanalyst to mount attacks on the key. Administrative limits on security layers lifetime may take the form of time limits expressed in x.509 certificates, Kerberos V tickets, or in directories, and are often desired. In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. As the result of this the connection will be closed (see section 3.3), which will result in unpleasant user experience. Re-keying (key renegotiation process) is a way of addressing the weakening of cryptographic keys. SASL framework does not provide for re-keying. SASL mechanisms may; all future SASL mechanisms that provide security layers should provide for re-keying. Applications that wish to re-key SASL security layers where the mechanism does not provide for re-keying should reauthenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for re-keying in the application protocols. See section 6.3. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAQjLN004437; Mon, 25 Oct 2004 03:26:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PAQjVJ004435; Mon, 25 Oct 2004 03:26:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PAQiJB004363 for ; Mon, 25 Oct 2004 03:26:44 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 25 Oct 2004 11:26:32 +0100 Message-ID: <417CD4D7.1050406@isode.com> Date: Mon, 25 Oct 2004 11:26:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Nicolas> Should > Nicolas> existing mechanisms' layers expire when the session key > Nicolas> material's useful lifetime (in terms of time or use) is > Nicolas> exceeded? > >I believe that SASL mechanisms should try to avoid expiring the >connection when key lifetime is exceeded because doing so creates an >unacceptable user experience. > I concur. > There exist mechanisms that will expire >though like some implementations of the GSSAPI mechanism. > > Are we talking about GSSAPI in general or a particular implementation of GSSAPI? Imagine that support for re-keying can be done without changing (extending) GSS API. In this case the SASL GSSAPI spec doesn't have to be updated. In which case the following text can be removed from 2222bis: In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. ? (or at least it has to be reworded to talk about "broken" or "old" implementations) Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2dWuw060814; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P2dW7s060813; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2dWt6060807 for ; Sun, 24 Oct 2004 19:39:32 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9P2dkZv039378; Mon, 25 Oct 2004 02:39:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041024192613.02e2e5c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 24 Oct 2004 19:40:18 -0700 To: Nicolas Williams From: "Kurt D. Zeilenga" Subject: Re: Summary of 2222bis WGLC Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <20041024211734.GG21427@binky.central.sun.com> References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.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: My view on re-keying is that its just another layer security service that a mechanism can offer. In regards to the SASL framework specification, how it does so (on the wire) is something for the mechanism specification to detail. And how an developer of an application protocol provides support for this mechanism is an implementation detail. The framework simply should not concern itself with such details. The design of any SASL API is limited by which mechanism aspects and protocol aspects which were accounted for in the design. If a new mechanism has aspects not previously considered by designers of a particular SASL API, then the designers of that SASL API might want to redesign their API to account for the new aspect... or decide that they simply cannot support that mechanism (or aspect of that mechanism). While we could constraint future mechanisms to currently known aspects, I think that's unwise and counter to character of SASL. At 02:17 PM 10/24/2004, Nicolas Williams wrote: >On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote: >> >> Kurt D. Zeilenga wrote: >> >> >1) Re-keying of security layers >> > >> >Nico indicated that the I-D did not discuss Re-keying of >> >security layers and suggested text in this area be added. >> >The WG discussed a number of specific suggestions in this >> >area, with the following text being the last version >> >submitted for WG consideration: >> > SASL mechanisms that support re-keying SHOULD: >> > - indicate that re-keying is or will be needed immediately; >> > - provide re-keying messages or transparently include re-keying >> > messages in the security layers; the latter can happen without >> > application involvement, but only as long as the application is >> > engaged in timely bidirectional exchanges with its peer. >> > >> After rereading this text multiple times it is clear to me that either >> the text is [partially] redundant, or I don't understand what it is >> trying to say (or maybe both). >> >> 1). "indicate that re-keying is or will be needed immediately". >> The first question I have after reading this sentence is "how?" Because >> SASL framework doesn't have any control channel or out-of-band >> mechanism, the only answer to this question is "by transparently >> including re-keying messages in the security layer". But this is a part >> of what the subsequent sentence is saying!? > >See below. > >> 2). "provide re-keying messages or transparently include re-keying >> messages in the security layers;" >> >> I think this sentence specifies requirements on SASL APIs and I am not >> sure whether RFC2222bis is the proper place for that. > >The answer is: by providing interfaces for the purpose of indicating key >layer expiration and providing for re-key message exchanges (where mechs >support it). Layer expiration, for existing mechs, should be advisory >only; for new mechs I think we should insist that it be mandatory. > >Whether you like it or not it is possible to derive an abstract API from >a protocol specification, at least a sufficiently complete and >unambiguous spec :) > >IMO abstract API requirements/recommendations are more than Ok to >include in rfc2222bis. The key word there is "abstract." > >> I also assume that "provide re-keying messages" is not the same thing as >> "transparently include re-keying messages in the security layers". > >Correct. I'm not sure that any existing mechs could do either, but new >mechs should definitely provide for the former. > >> I think the former is trying to say that the SASL API should be able to >> signal to the application that rekeying is (or will be shortly) needed, >> once a rekeying message is received. It also tries to say that the >> application should be able to say to SASL API: "send rekeying request now". > >Yes. > >> The latter is trying to say that the SASL API doesn't have to expose >> re-keying messages to the application, it should generate/process them >> automatically. > >Yes. This approach is less than ideal. IIRC Sam favors it, at least in >that it may be workable in some cases that we care about. > >Cheers, > >Nico >-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2FVh5055991; Sun, 24 Oct 2004 19:15:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P2FVYm055990; Sun, 24 Oct 2004 19:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2FUmm055982 for ; Sun, 24 Oct 2004 19:15:30 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9P2FeZv039243; Mon, 25 Oct 2004 02:15:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041024183023.02ddf620@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 24 Oct 2004 19:16:13 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@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 02:13 PM 10/24/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: > >> The syntax and semantics of authentication ID's are determined > >> entirely by the authentication mechanism; > > Kurt> If you were to say the syntax and semantics of any > Kurt> authentication identity information carried in the exchange > Kurt> is specified by the mechanism's specification, I would > Kurt> agree. > > Kurt> But, without that qualification, I would have to disagree. > Kurt> For instance, an application protocol can certainly detail > Kurt> how authentication identities are to represented in > Kurt> identity-assumption policy information carried by the > Kurt> protocol, and associated semantics. > >I agree that they can do so in the sense that if the IESG approved it, >it would be a protocol action. LDAP and IMAP ACLs. What's good is a standardize access control policy if the standard does say how identities used in the authentication exchange relate to identities appearing in the policy? Say an administrative client has created a Kerberos principal for a user and then wants to authorize that user to access an object on an LDAP server. What DN should the administrative client use as the subject of the LDAP access control statement? Without a standard of some kind here, it is not possible to independently develop such a client. >Application protocols should not say >anything about authentication identities though, because doing so >would tie them to a particular mechanism. No, it would require an update of the application protocol specification to state how to manage identities associated with that particular mechanism relate to identities in the application protocol. (This doesn't mean that one cannot use new mechanisms in the protocol in absence of this update, it says that one cannot use certain policy features of that mechanism until its updated to deal with the new mechanism.) Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P1Axpp043068; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P1AxZY043067; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P1Axep043061 for ; Sun, 24 Oct 2004 18:10:59 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9P1BDNH022514 for ; Sun, 24 Oct 2004 19:11:13 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P1BCjW009414 for ; Sun, 24 Oct 2004 19:11:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9P1Ar12019092 for ; Sun, 24 Oct 2004 20:10:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9P1ArX5019091 for ietf-sasl@imc.org; Sun, 24 Oct 2004 20:10:53 -0500 (CDT) Date: Sun, 24 Oct 2004 20:10:53 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC Message-ID: <20041025011053.GD19142@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> <20041024211734.GG21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041024211734.GG21427@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Oct 24, 2004 at 04:17:34PM -0500, Nicolas Williams wrote: > The answer is: by providing interfaces for the purpose of indicating key > layer expiration and providing for re-key message exchanges (where mechs > support it). Layer expiration, for existing mechs, should be advisory > only; for new mechs I think we should insist that it be mandatory. And, of course, the GSS-API does not provide [yet] for advisory security context expiration, so neither can SASL GSS mechanisms [yet]. It'd be a shame to add advisory security context expiration to the GSS-APIv3 work at KITTEN just for SASL, but perhaps we should. Also, there is a mitigation for this problem: use ciphers that don't require re-keying :) (I'm thinking AES-256 in some counter mode). Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLKvMS092400; Sun, 24 Oct 2004 14:20:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLKvvU092399; Sun, 24 Oct 2004 14:20:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLKuNP092392 for ; Sun, 24 Oct 2004 14:20:56 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id B5EF9E0053; Sun, 24 Oct 2004 17:21:17 -0400 (EDT) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> <20041024210924.GF21427@binky.central.sun.com> From: Sam Hartman Date: Sun, 24 Oct 2004 17:21:17 -0400 In-Reply-To: <20041024210924.GF21427@binky.central.sun.com> (Nicolas Williams's message of "Sun, 24 Oct 2004 16:09:24 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Where does this leave us w.r.t. re-keying? Will it be Nicolas> possible for future mechanisms or extensions to existing Nicolas> ones to provide for something better than this? Yes. If you believe the text does not support future work in this direction please describe. Nicolas> Should Nicolas> existing mechanisms' layers expire when the session key Nicolas> material's useful lifetime (in terms of time or use) is Nicolas> exceeded? I believe that SASL mechanisms should try to avoid expiring the connection when key lifetime is exceeded because doing so creates an unacceptable user experience. There exist mechanisms that will expire though like some implementations of the GSSAPI mechanism. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLHfqG091657; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLHfnV091656; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLHfJP091650 for ; Sun, 24 Oct 2004 14:17:41 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9OLHr7q022562 for ; Sun, 24 Oct 2004 14:17:53 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9OLHrjW012122 for ; Sun, 24 Oct 2004 15:17:53 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9OLHYiN018998; Sun, 24 Oct 2004 16:17:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9OLHYcp018997; Sun, 24 Oct 2004 16:17:34 -0500 (CDT) Date: Sun, 24 Oct 2004 16:17:34 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC Message-ID: <20041024211734.GG21427@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417AB364.6050503@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote: > > Kurt D. Zeilenga wrote: > > >1) Re-keying of security layers > > > >Nico indicated that the I-D did not discuss Re-keying of > >security layers and suggested text in this area be added. > >The WG discussed a number of specific suggestions in this > >area, with the following text being the last version > >submitted for WG consideration: > > SASL mechanisms that support re-keying SHOULD: > > - indicate that re-keying is or will be needed immediately; > > - provide re-keying messages or transparently include re-keying > > messages in the security layers; the latter can happen without > > application involvement, but only as long as the application is > > engaged in timely bidirectional exchanges with its peer. > > > After rereading this text multiple times it is clear to me that either > the text is [partially] redundant, or I don't understand what it is > trying to say (or maybe both). > > 1). "indicate that re-keying is or will be needed immediately". > The first question I have after reading this sentence is "how?" Because > SASL framework doesn't have any control channel or out-of-band > mechanism, the only answer to this question is "by transparently > including re-keying messages in the security layer". But this is a part > of what the subsequent sentence is saying!? See below. > 2). "provide re-keying messages or transparently include re-keying > messages in the security layers;" > > I think this sentence specifies requirements on SASL APIs and I am not > sure whether RFC2222bis is the proper place for that. The answer is: by providing interfaces for the purpose of indicating key layer expiration and providing for re-key message exchanges (where mechs support it). Layer expiration, for existing mechs, should be advisory only; for new mechs I think we should insist that it be mandatory. Whether you like it or not it is possible to derive an abstract API from a protocol specification, at least a sufficiently complete and unambiguous spec :) IMO abstract API requirements/recommendations are more than Ok to include in rfc2222bis. The key word there is "abstract." > I also assume that "provide re-keying messages" is not the same thing as > "transparently include re-keying messages in the security layers". Correct. I'm not sure that any existing mechs could do either, but new mechs should definitely provide for the former. > I think the former is trying to say that the SASL API should be able to > signal to the application that rekeying is (or will be shortly) needed, > once a rekeying message is received. It also tries to say that the > application should be able to say to SASL API: "send rekeying request now". Yes. > The latter is trying to say that the SASL API doesn't have to expose > re-keying messages to the application, it should generate/process them > automatically. Yes. This approach is less than ideal. IIRC Sam favors it, at least in that it may be workable in some cases that we care about. Cheers, Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLCugb090536; Sun, 24 Oct 2004 14:12:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLCuI5090535; Sun, 24 Oct 2004 14:12:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLCtDJ090528 for ; Sun, 24 Oct 2004 14:12:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 0155AE0053; Sun, 24 Oct 2004 17:13:15 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> From: Sam Hartman Date: Sun, 24 Oct 2004 17:13:15 -0400 In-Reply-To: <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> (Kurt D. Zeilenga's message of "Thu, 21 Oct 2004 16:13:56 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: >> The syntax and semantics of authentication ID's are determined >> entirely by the authentication mechanism; Kurt> If you were to say the syntax and semantics of any Kurt> authentication identity information carried in the exchange Kurt> is specified by the mechanism's specification, I would Kurt> agree. Kurt> But, without that qualification, I would have to disagree. Kurt> For instance, an application protocol can certainly detail Kurt> how authentication identities are to represented in Kurt> identity-assumption policy information carried by the Kurt> protocol, and associated semantics. I agree that they can do so in the sense that if the IESG approved it, it would be a protocol action. Application protocols should not say anything about authentication identities though, because doing so would tie them to a particular mechanism. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL9gu7089934; Sun, 24 Oct 2004 14:09:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OL9gat089933; Sun, 24 Oct 2004 14:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL9fdY089924 for ; Sun, 24 Oct 2004 14:09:41 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9OL9mui018443 for ; Sun, 24 Oct 2004 15:09:54 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9OL9mjW009459 for ; Sun, 24 Oct 2004 15:09:48 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9OL9T5i018988; Sun, 24 Oct 2004 16:09:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9OL9OO7018987; Sun, 24 Oct 2004 16:09:24 -0500 (CDT) Date: Sun, 24 Oct 2004 16:09:24 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Sam Hartman , SASL WG Subject: Re: Life of a security layer and error handling (was Re: Summary of 2222bis WGLC) Message-ID: <20041024210924.GF21427@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , "Kurt D. Zeilenga" , Sam Hartman , SASL WG References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417ACB03.4090302@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Where does this leave us w.r.t. re-keying? Will it be possible for future mechanisms or extensions to existing ones to provide for something better than this? Should existing mechanisms' layers expire when the session key material's useful lifetime (in terms of time or use) is exceeded? IMO, SASL must at least point out the key expiration problem and should allow for future mechs/extensions that provide for re-keying. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL2jF3088449; Sun, 24 Oct 2004 14:02:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OL2j9x088448; Sun, 24 Oct 2004 14:02:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OL2gqV088439 for ; Sun, 24 Oct 2004 14:02:42 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 5B687E0053; Sun, 24 Oct 2004 17:03:03 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Making forward progress References: From: Sam Hartman Date: Sun, 24 Oct 2004 17:03:03 -0400 In-Reply-To: (Simon Josefsson's message of "Sun, 24 Oct 2004 01:24:22 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> Sam Hartman writes: >> I've seen no objections to Kurt's new summary of the identities >> issue nor to his proposed text for section 3. Simon> I raised some issues with the new summary in: Simon> http://thread.gmane.org/gmane.ietf.sasl/1687 Sorry I was not clear on this. I believed you and Kurt were agreeing with each othe; I still believe that is true after reading the exchange again. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OGG3rL026099; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OGG34p026098; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-SIXTY-FOUR.MIT.EDU [18.187.6.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OGG2Ip026092 for ; Sun, 24 Oct 2004 09:16:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id B6FEE16004F; Sun, 24 Oct 2004 12:16:19 -0400 (EDT) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , SASL WG Subject: Re: Life of a security layer and error handling References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> <417ACB03.4090302@isode.com> From: Sam Hartman Date: Sun, 24 Oct 2004 12:16:19 -0400 In-Reply-To: <417ACB03.4090302@isode.com> (Alexey Melnikov's message of "Sat, 23 Oct 2004 22:20:03 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: OK. My interpretation of the third paragraph was that it was saying that a layer might force a connection close. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODrpTm093075; Sun, 24 Oct 2004 06:53:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ODrpa2093074; Sun, 24 Oct 2004 06:53:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODrorb093068 for ; Sun, 24 Oct 2004 06:53:50 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 24 Oct 2004 14:53:52 +0100 Message-ID: <417ACB03.4090302@isode.com> Date: Sat, 23 Oct 2004 22:20:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Sam Hartman , SASL WG Subject: Life of a security layer and error handling (was Re: Summary of 2222bis WGLC) References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <416D2794.2030707@isode.com> <6.1.2.0.0.20041014170350.02d5c760@127.0.0.1> <4177B3B7.1010201@isode.com> <6.1.2.0.0.20041021182216.030c5238@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041021182216.030c5238@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: [I am CCing my reply to the mailing list as discuss. I believe I've quoted enough context.] Kurt D. Zeilenga wrote: >> >>> 2). The following text is in the Security Considerations >> >>> section (as per off the list discussion with Nico): >> >>> >> >>> The secure or administratively permitted lifetimes of SASL >> >>> mechanisms' security layers are finite. Cryptographic keys >> >>> weaken as they are used and as time passes; the more time >> >>> and/or ciphertext that a cryptanalyst has after the first use >> >>> of the a key, the easier it is for the cryptanalyst to mount >> >>> attacks on the key. >> >>> >> >>> Administrative limits on security layers lifetime may take the >> >>> form of time limits expressed in x.509 certificates, Kerberos >> >>> V tickets, or in directories, and are often desired. >> >>> >> >>> In practice one likely effect of administrative security >> >>> layers lifetime limits is that applications may find that >> >>> security layers stop working in the middle of application >> >>> protocol operation, such as, perhaps, during large data >> >>> transfers. >> >>> >> >>> SASL does not provide for re-keying. SASL mechanisms may; all >> >>> future SASL mechanisms that provide security layers SHOULD >> >>> provide for re-keying. >> >>> >> >> See above comments regarding this recommendation. >> >> >> Alexey> You have to be more specific than that. I think the first >> Alexey> paragraph should stay, as it explains why rekeying is >> Alexey> needed. It should probably be reworded to state this >> Alexey> explicitly. I think the second paragraph should stay as >> Alexey> well, although I am not so sure. The third paragraph >> Alexey> should be dropped. The last paragraph should stay, >> Alexey> although it will have to be reworded (and maybe drop >> Alexey> SHOULD?). >> >>What's wrong with the third paragraph? It does tell you the >>application writer that life may be annoying, but I believe that is a >>practical statement of reality. >> > >A problem I see with the third paragraph is that it attempts to >redefine the lifetime of the layer. A layers life lasts until >either a) a new layer is installed or b) the connection closes. >There no way that a layer's life can end otherwise. If the >mechanism is no longer able to generate buffers, the connection >must be closed. It is impossible to re-key or to install a new >layer without generating buffers to accomplish that re-keying >or installation. > >This should be made clear in the document. I agree. Section 3.3 had the following sentence: 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)). I've added "or underlying connection is closed" to the text in the parentheses. >>I hope to convince mechanism designers/implementers not to have mechanisms fail mid transfer, but some mechanisms today do fail that way. >> > >SASL doesn't allow anything else. If the mechanism is not >able to produce a buffer, the connection must be closed. >That can happen anywhere within the application protocol >stream. > >This should be made clear as well. If the mechanism layer >failure results in termination of the connection. While at >the protocol and SASL layers, that termination is abrupt, >implementations should attempt to gracefully close lower >level layers (such as TLS and TCP). > Agreed. I've changed the existing text in 3.3: Once the security layer is in effect the protocol stream is processed by the security layer into buffers of protected data. Each buffer of protected 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. To: Once the security layer is in effect the protocol stream is processed by the security layer into buffers of protected data. If the security layer is not able to produce a buffer, the connection MUST be closed. If the security layer is not able to decode a received buffer, the connection MUST be closed. In both cases the underlying connection SHOULD be closed gracefully. (Inserted 3 sentences here and broke the paragraph into 2). Each buffer of protected 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 buffer. ... (I've dropped the word "following" in the last sentence.) Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODIi6j085960; Sun, 24 Oct 2004 06:18:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ODIict085959; Sun, 24 Oct 2004 06:18:44 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODIe4F085947 for ; Sun, 24 Oct 2004 06:18:41 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CLiGn-0000WE-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 15:18:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Making forward progress Date: Sun, 24 Oct 2004 15:18:22 +0200 Lines: 41 Message-ID: References: <6.1.2.0.0.20041023170532.0301e1e0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:JfSljjmgLX14oVcphSilJMk1kXg= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:24 PM 10/23/2004, Simon Josefsson wrote: > >>Sam Hartman writes: >> >>> I've seen no objections to Kurt's new summary of the identities issue >>> nor to his proposed text for section 3. >> >>I raised some issues with the new summary in: >> >>http://thread.gmane.org/gmane.ietf.sasl/1687 >> >>There were additional discussion, even some disagreement on (what I >>perceive as) terminology issues. I proposed a change to the proposed >>new text, to which Kurt acknowledged that his proposed text was not a >>direct replacement, and that further work was needed. Has there been >>a more recent proposal? I cannot seem to find it. >> >>> I think we should move forward with that change. >> >>For the record, I again object to removing the paragraphs below, at >>this late stage. Kurt's new summary appear, to me, to propose to >>remove them. > > I believe I posted a clarification that it was not my intent > to suggest these statements be removed. At the time I > submitted the suggested text, I presumed they would placed > elsewhere in the specification. > > At this time, I think the majority of my "identity concept" > text should be placed in an introductory section. > > Additionally, these statements need some clarification > (as I indicated in follow-ups). Thanks. I was confused by the resolution to move forward with a change that had not yet been fleshed out. Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O0Md7l014347; Sat, 23 Oct 2004 17:22:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O0MdMp014346; Sat, 23 Oct 2004 17:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O0Mc9k014336 for ; Sat, 23 Oct 2004 17:22:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9O0MVZv031144; Sun, 24 Oct 2004 00:22:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041023170532.0301e1e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 23 Oct 2004 17:23:05 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Making forward progress Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:24 PM 10/23/2004, Simon Josefsson wrote: >Sam Hartman writes: > >> I've seen no objections to Kurt's new summary of the identities issue >> nor to his proposed text for section 3. > >I raised some issues with the new summary in: > >http://thread.gmane.org/gmane.ietf.sasl/1687 > >There were additional discussion, even some disagreement on (what I >perceive as) terminology issues. I proposed a change to the proposed >new text, to which Kurt acknowledged that his proposed text was not a >direct replacement, and that further work was needed. Has there been >a more recent proposal? I cannot seem to find it. > >> I think we should move forward with that change. > >For the record, I again object to removing the paragraphs below, at >this late stage. Kurt's new summary appear, to me, to propose to >remove them. I believe I posted a clarification that it was not my intent to suggest these statements be removed. At the time I submitted the suggested text, I presumed they would placed elsewhere in the specification. At this time, I think the majority of my "identity concept" text should be placed in an introductory section. Additionally, these statements need some clarification (as I indicated in follow-ups). >The paragraphs could be reworded for clarity, as they >are critical in getting the boundaries between normalization >procedures in an implementation. But I have yet to see any argument >to why they are technically wrong, and should be removed. Because I don't believe anyone has argued that they should be removed. > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. This statement needs to be clarified. In particular, the intent here is that the mechanism specification is solely responsible for stating how any authentication identity information is transferred as part of the exchange. However, the mechanism specification does not necessarily have any responsibility for stating how authentication identity information is represented elsewhere. For instance, an application protocol specification is free to define how authentication identities appearing in an identity-assumption policy statement are to be normalized. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). > >Thanks, >Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NNOp0o002318; Sat, 23 Oct 2004 16:24:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NNOpWp002317; Sat, 23 Oct 2004 16:24:51 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NNOmEx002235 for ; Sat, 23 Oct 2004 16:24:49 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CLVFd-0003cz-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Oct 2004 01:24:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Making forward progress Date: Sun, 24 Oct 2004 01:24:22 +0200 Lines: 33 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:ignQ0G4Dj5sxyEDyi7FGWkbOcpg= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I've seen no objections to Kurt's new summary of the identities issue > nor to his proposed text for section 3. I raised some issues with the new summary in: http://thread.gmane.org/gmane.ietf.sasl/1687 There were additional discussion, even some disagreement on (what I perceive as) terminology issues. I proposed a change to the proposed new text, to which Kurt acknowledged that his proposed text was not a direct replacement, and that further work was needed. Has there been a more recent proposal? I cannot seem to find it. > I think we should move forward with that change. For the record, I again object to removing the paragraphs below, at this late stage. Kurt's new summary appear, to me, to propose to remove them. The paragraphs could be reworded for clarity, as they are critical in getting the boundaries between normalization procedures in an implementation. But I have yet to see any argument to why they are technically wrong, and should be removed. Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKCGGA057584; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKCG6A057583; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKCFGn057574 for ; Sat, 23 Oct 2004 13:12:16 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:12:15 +0100 Message-ID: <417AB985.4090607@isode.com> Date: Sat, 23 Oct 2004 21:05:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> <417AB364.6050503@isode.com> In-Reply-To: <417AB364.6050503@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Kurt D. Zeilenga wrote: > >> 1) Re-keying of security layers >> Nico indicated that the I-D did not discuss Re-keying of >> security layers and suggested text in this area be added. >> The WG discussed a number of specific suggestions in this >> area, with the following text being the last version >> submitted for WG consideration: >> SASL mechanisms that support re-keying SHOULD: >> - indicate that re-keying is or will be needed immediately; >> - provide re-keying messages or transparently include re-keying >> messages in the security layers; the latter can happen without >> application involvement, but only as long as the application is >> engaged in timely bidirectional exchanges with its peer. > > After rereading this text multiple times it is clear to me that either > the text is [partially] redundant, or I don't understand what it is > trying to say (or maybe both). > > 1). "indicate that re-keying is or will be needed immediately". > The first question I have after reading this sentence is "how?" > Because SASL framework doesn't have any control channel or out-of-band > mechanism, the only answer to this question is "by transparently > including re-keying messages in the security layer". But this is a > part of what the subsequent sentence is saying!? > > 2). "provide re-keying messages or transparently include re-keying > messages in the security layers;" > > I think this sentence specifies requirements on SASL APIs and I am not > sure whether RFC2222bis is the proper place for that. > > I also assume that "provide re-keying messages" is not the same thing > as "transparently include re-keying messages in the security layers". > I think the former is trying to say that the SASL API should be able > to signal to the application that rekeying is (or will be shortly) > needed, once a rekeying message is received. It also tries to say that > the application should be able to say to SASL API: "send rekeying > request now". > > The latter is trying to say that the SASL API doesn't have to expose > re-keying messages to the application, it should generate/process them > automatically. Having said that, here is a draft variant of the text I propose: A SASL mechanism supports re-keying if it is able to generate/process messages that request immediate re-keying and it is able to carry out re-keying exchange. (a single message that does both is Ok) SASL mechanisms that support re-keying MAY also be able to indicate that re-keying will be needed in the future. A re-keying exchange can be conducted transparently by the mechanism, or the mechanism should be able to provide/accept re-keying messages to/from the application. The former can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKBgb3057425; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKBgPi057422; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKBfef057406 for ; Sat, 23 Oct 2004 13:11:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:11:39 +0100 Message-ID: <417AB364.6050503@isode.com> Date: Sat, 23 Oct 2004 20:39:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@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: >1) Re-keying of security layers > >Nico indicated that the I-D did not discuss Re-keying of >security layers and suggested text in this area be added. >The WG discussed a number of specific suggestions in this >area, with the following text being the last version >submitted for WG consideration: > SASL mechanisms that support re-keying SHOULD: > - indicate that re-keying is or will be needed immediately; > - provide re-keying messages or transparently include re-keying > messages in the security layers; the latter can happen without > application involvement, but only as long as the application is > engaged in timely bidirectional exchanges with its peer. > After rereading this text multiple times it is clear to me that either the text is [partially] redundant, or I don't understand what it is trying to say (or maybe both). 1). "indicate that re-keying is or will be needed immediately". The first question I have after reading this sentence is "how?" Because SASL framework doesn't have any control channel or out-of-band mechanism, the only answer to this question is "by transparently including re-keying messages in the security layer". But this is a part of what the subsequent sentence is saying!? 2). "provide re-keying messages or transparently include re-keying messages in the security layers;" I think this sentence specifies requirements on SASL APIs and I am not sure whether RFC2222bis is the proper place for that. I also assume that "provide re-keying messages" is not the same thing as "transparently include re-keying messages in the security layers". I think the former is trying to say that the SASL API should be able to signal to the application that rekeying is (or will be shortly) needed, once a rekeying message is received. It also tries to say that the application should be able to say to SASL API: "send rekeying request now". The latter is trying to say that the SASL API doesn't have to expose re-keying messages to the application, it should generate/process them automatically. >The chairs believes the WG supports addition of this text. > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKAlMA057171; Sat, 23 Oct 2004 13:10:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKAlAB057170; Sat, 23 Oct 2004 13:10:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKAkUg057163 for ; Sat, 23 Oct 2004 13:10:46 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:10:42 +0100 Message-ID: <417AA29B.7010103@isode.com> Date: Sat, 23 Oct 2004 19:27:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >>[nothing in the abstract says that's the kind of mechanisms it is >>talking about.] >> > >Mechanisms provide authentication and data security services >to connection-oriented protocols through the SASL framework. > IMHO, this just follows from: The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. So I think nothing has to be added/changed. >>The same change would be nice in the Introduction section, though of >>course the diagram there helps. >> >>Personally I would also have found an asymmetric definition easier to >>relate to: SASL defines a common interface to authentication mechanisms >>for protocols. (Is that the right way to put it?) But maybe that's not >>at all the view SASL intends to convey. Is the protocol profile the >>common interface to protocols for authentication mechanisms? >> >> > >The "protocol profile" is the part of the protocol's >technical specification which details how it makes use >of the SASL framework. > > The Introduction section currently have the following paragraph: To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions. If the use of a security layer is negotiated, that security layer is inserted between the protocol and the connection. Section 4 ("Protocol profile requirements") profiles the requirements that a protocol specification must fulfill to make use of SASL. I've added the following sentence to the end: A SASL protocol profile is a part of the protocol specification that satisfies the requirements of Section 4. Comments? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKA3LS056979; Sat, 23 Oct 2004 13:10:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NKA3br056976; Sat, 23 Oct 2004 13:10:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NKA13g056960 for ; Sat, 23 Oct 2004 13:10:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:09:56 +0100 Message-ID: <417A9F61.4000702@isode.com> Date: Sat, 23 Oct 2004 19:13:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>>> s/user('s)/authentication identity('s)/. >>> >>> Since authentication identity is defined here as >>> being the identity associated the credentials, would >>> be effective saying: >>> s/user's credentials/credentials of the identity >>> associated with the credentials/ >> >> Well, I'd still like to get rid of that 'user'. 'User' is used >> elsewhere as merely one kind of identity. >> Maybe s/user's credentials/presented credentials/, >> or s/users's credentials/credentials/, s/user/authentication identity/? > > s/user/client/ and be done with it. I've done the change. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MKv4bb008227; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MKv49P008226; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MKv3hY008218 for ; Fri, 22 Oct 2004 13:57:04 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03522; 22 Oct 2004 16:56 EDT Date: Fri, 22 Oct 2004 16:56:52 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis Message-ID: <1128140000.1098478612@minbar.fac.cs.cmu.edu> In-Reply-To: <41790B48.5060500@isode.com> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> <41790B48.5060500@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, October 22, 2004 14:29:44 +0100 Alexey Melnikov wrote: >> The syntax and semantics of authentication ID's are determined >> entirely by the authentication mechanism; the protocol has no say in >> the matter. All mechanisms are protocol-independent, and all protocol >> profiles are mechanism-independent. >> >> A particular _implementation_ must be able to perform the >> authorization check (can this authid use the requested autzid) and >> must be able to derive an authorization ID from an authentication ID. >> These operations depend on both the mechanism and protocol profile in >> use, and their details are deliberately left to the implementation and >> to local policy. > > Do I need to change anything in the document? I'll answer a narrower question... I'm not proposing any change to the document in relation to this item. I was simply trying to clarify what looked like a point of confusion in the ongoing discussion. -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MEtoix053117; Fri, 22 Oct 2004 07:55:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MEtokI053116; Fri, 22 Oct 2004 07:55:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MEtnHj053110 for ; Fri, 22 Oct 2004 07:55:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 22 Oct 2004 15:55:43 +0100 Message-ID: <41791F6F.3060802@isode.com> Date: Fri, 22 Oct 2004 15:55:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description References: <4177DA2A.8040702@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > >>Hallvard B Furuseth wrote: >> >>>>7. The EXTERNAL mechanism >>>> >>>> >>> The server uses information external to SASL to determine the >>> authentication identity and whether the authentication is to >>> succeed. >>> >>> >>Although this implies the same thing (if you take into consideration >>implied authorization step), I would prefer the original text. >> >> > >[...] > >If I mix your text and mine a bit, does this cover all bases? > > Some system external to SASL must authenticate the client. If that > succeeds, the server determines the authentication identity from > information from this system. If the requested authorization identity > is empty, the authorization identity is derived from the > authentication identity. The server determines if the authentication > identity is allowed to act as the authorization identity. Finally, it > indicates completion or failure of the authentication exchange. > >Or replace the last sentence with > > If all that succeeds, the server indicates successful completion of > the authentication exchange; otherwise it indicates failure. > That would work for me. > > Sigh. And this started with trying to make the text _shorter_:-) > It usually does :-). > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MDTtSR037202; Fri, 22 Oct 2004 06:29:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MDTt6P037201; Fri, 22 Oct 2004 06:29:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MDTsrN037168 for ; Fri, 22 Oct 2004 06:29:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 22 Oct 2004 14:29:44 +0100 Message-ID: <41790B48.5060500@isode.com> Date: Fri, 22 Oct 2004 14:29:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >> Well, what I wanted to address was what I mentioned in my original >> review: >> >> > Any normalization of the authentication identity is defined by a >> > particular SASL mechanism, the protocol profile doesn't >> influence it. >> >> That's a bit misleading from the protocol's point of view. From >> discussions elsewhere I gather the protocol may normalize the ID as it >> pleases for its own use, including when it locates the server-side >> secret matching the authentication ID, as long as this does not affect >> the ID which the authentication mechanism sees. >> >> Your text doesn't seem to be clear on that. > > The syntax and semantics of authentication ID's are determined > entirely by the authentication mechanism; the protocol has no say in > the matter. All mechanisms are protocol-independent, and all protocol > profiles are mechanism-independent. > > A particular _implementation_ must be able to perform the > authorization check (can this authid use the requested autzid) and > must be able to derive an authorization ID from an authentication ID. > These operations depend on both the mechanism and protocol profile in > use, and their details are deliberately left to the implementation and > to local policy. Do I need to change anything in the document? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LNDFIm028747; Thu, 21 Oct 2004 16:13:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LNDFvc028746; Thu, 21 Oct 2004 16:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LNDEIt028739 for ; Thu, 21 Oct 2004 16:13:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LNDIZv012879; Thu, 21 Oct 2004 23:13:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021154451.02e16530@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 16:13:56 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <896140000.1098397553@minbar.fac.cs.cmu.edu> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <896140000.1098397553@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote: >The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism; If you were to say the syntax and semantics of any authentication identity information carried in the exchange is specified by the mechanism's specification, I would agree. But, without that qualification, I would have to disagree. For instance, an application protocol can certainly detail how authentication identities are to represented in identity-assumption policy information carried by the protocol, and associated semantics. >All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent. From the perspective of the SASL framework, yes. >A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID. Which requires may involve deriving an authentication ID from credential information. It is not appropriate to assume the particular form of authentication identity in the credentials, are the form used to establish this authorization identity. For instance, consider EXTERNAL with TLS X.509 authentication. The authentication identity might be the subject DN, or it might be viewed as being one of the altSubjNames, or something derived from this (and possible other stuff). >These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy. And possible aspects of the application-level protocol specification. For instance, it is reasonable for an application-level protocol specification to specify how mechanism-specific authentication identity forms relate to protocol-specific authentication forms, as necessary say to detail how mechanism-specific credentials (or associated policies) are to managed using the application-level protocol. Of course, an application-level protocol specification detailing such things should not unnecessarily preclude use of the mechanisms not explicitly discussed in the application-level protocol specification. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LMQWNM018284; Thu, 21 Oct 2004 15:26:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LMQWot018283; Thu, 21 Oct 2004 15:26:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9LMQV9i018277 for ; Thu, 21 Oct 2004 15:26:31 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa01779; 21 Oct 2004 18:25 EDT Date: Thu, 21 Oct 2004 18:25:53 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth , "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis Message-ID: <896140000.1098397553@minbar.fac.cs.cmu.edu> In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@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 Thursday, October 21, 2004 15:39:29 +0200 Hallvard B Furuseth wrote: >>> No, authentication identity may not even have a syntax which is valid >>> for an authorization identity. >>> [...] >>> The client is requesting that the >>> authorization identity is derived from the authentication identity. >> >> Conceptionally, the client is requesting the act as the >> identity associated with credentials. This identity >> might have many different representations. > > [...] > But even so, authorization identities and authentication identities seem > to me to be 'conceptually' different types of entities; defined by > different standards and used in different ways. So whether we talk of > conceptual or represented identities, I'd still prefer to say that the > authorization id is derived from the authentication id rather than it is > the authentication id. Agree. Use the "is derived from" language; it's less likely to confuse people into thinking in terms of blindly copying strings around. >>> s/user('s)/authentication identity('s)/. >> >> Since authentication identity is defined here as >> being the identity associated the credentials, would >> be effective saying: >> s/user's credentials/credentials of the identity >> associated with the credentials/ > > Well, I'd still like to get rid of that 'user'. 'User' is used > elsewhere as merely one kind of identity. > Maybe s/user's credentials/presented credentials/, > or s/users's credentials/credentials/, s/user/authentication identity/? s/user/client/ and be done with it. > Well, what I wanted to address was what I mentioned in my original review: > > > Any normalization of the authentication identity is defined by a > > particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. > > Your text doesn't seem to be clear on that. The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism; the protocol has no say in the matter. All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent. A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID. These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy. > Do you mean the OSI model application layer? No; he's using the term in a generic sense and there does not need to be a reference to the OSI model, which in any case is only of limited use. For example, if you look, you'll find that SASL does not correspond to any layer in the OSI model. The distinction here is between SASL-using protocols (most of which are, in fact, "application" protocols in the narrower sense) as opposed to SASL itself or the underlying authentication mechanisms, all of which are also "protocols" in the generic sense. The use of the phrase "application protocol" in this sense is common in discussions about security frameworks, and should not cause confusion. In fact, I agree with Kurt that the use of the unqualified term "protocol" is confusing in this document, because in a document which defines a framework consisting of N+M+1 protocol components, the term is highly ambiguous, our definition notwithstanding. However, I also agree that we need consistent usage throughout the document. Either use "application protocol" everywhere, or not at all. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LKAffB085710; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LKAf3Q085709; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LKAfZd085703 for ; Thu, 21 Oct 2004 13:10:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LKAjZv011965; Thu, 21 Oct 2004 20:10:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021125032.03004908@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 13:11:23 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> <6.1.2.0.0.20041021105009.030324a8@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:03 PM 10/21/2004, Hallvard B Furuseth wrote: >I'll be reading this - and the draft - later, but first: > >Kurt D. Zeilenga writes: >> The problem is that, in the SASL framework, no identity >> representation may be explicitly transferred. However, >> regardless of what's transferred. > >That last sentence seems to have been truncated. I think I was going to note that regardless of identity abstract (DN,Kerberos principal,other) and encoding (for DNs: RFC 2253 string, RFC 2829 authzid, DCE DN format, base64 of the DER encoding, other) used in transfer, the transferred value refers to some identity. Later, that identity may be represented using other abstractions and/or encodings. If we talk conceptually, we can say the authorization identity value input of the user, the value transferred by the SASL mechanism, the value used in determining whether the user associated with the credentials may act as specified identity, the value used in making authorization identities, and the values used in specifying identity assumption and/or authorization policies are all refer to the same identity, the identity to act as, the authorization identity. If, however, we talk in terms of how this and other identity concept is represented here and there, we'll have to come up with numerous terms and over-specify the details of identity management. Most of the details of identity management are simply beyond the scope of the SASL framework. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LIeCsj063549; Thu, 21 Oct 2004 11:40:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LIeCgZ063548; Thu, 21 Oct 2004 11:40:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LIeAoi063515 for ; Thu, 21 Oct 2004 11:40:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LIeCZv011400; Thu, 21 Oct 2004 18:40:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021105009.030324a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 11:40:50 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@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 06:39 AM 10/21/2004, Hallvard B Furuseth wrote: >Sorry about the late replies; I thought I had addressed this. > >Kurt D. Zeilenga writes: >>At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>> 3.2 Identity Concepts >>> >>>> The client provides its credentials and, optionally, a >>>> string representing the requested authorization identity >>>> as part of the SASL exchange. >>> >>>> When this string is not >>>> provided, the client is requesting to act as the identity >>>> associated with the credentials (e.g., the user is >>>> requesting to act as the authentication identity). >>> >>>No, authentication identity may not even have a syntax which is valid >>>for an authorization identity. >> >> An identity can be represented in many different ways. >> Here I am using the terms "authentication identity" >> and "authorization identity" conceptional, and >> generally without regards to how they might be represented >> at any given time or place. When I referred to a "string >> representing the requested authorization identity", I >> referred to a particular representation of an identity. >> But when I said, "the client is requesting to act as the >> [authentication identity]", I didn't talk about how that >> identity would be represented. >> >>>The client is requesting that the >>>authorization identity is derived from the authentication identity. >> >> Conceptionally, the client is requesting the act as the >> identity associated with credentials. This identity >> might have many different representations. > >I hadn't quite caught on to the 'conceptual' part, but it seems rather >confusing to have the same names for 'conceptual' and 'represented' >identities. Would it help if the conceptional discussion was moved to the Introduction? The problem is that, in the SASL framework, no identity representation may be explicitly transferred. However, regardless of what's transferred. >But even so, authorization identities and authentication identities seem >to me to be 'conceptually' different types of entities; I disagree. An identity (authorization or authentication) refers to a human or application entity. The qualification, authorization or authentication, refers not to kind of entity, but to the usage of the identity. >defined by >different standards and used in different ways. So whether we talk of >conceptual or represented identities, I'd still prefer to say that the >authorization id is derived from the authentication id rather than it is >the authentication id. The 'derived' language is problematic. Consider the authorization identity (and when its explicitly transferred). A user wishes to act as some other user that it identifies as some particular identity. The user enters a representation of that identity to the client which then, knowing the application protocol requirements, translates the user provided identity string into form required by the application protocol specification. Then the server might take this form and translate it some other representation of the identity to make identity assumption policy decision, and then do some other translation of the representation of the identity to produce the identity representation actually used to make authorization decisions. Regardless of the identity abstraction (DN, Kerberos principle, etc.) and the encoding of values of that abstraction (LDAPDN, DER DN, GSER DN, DCE DN) used here and there, there is conceptional one authorization identity. For instance, consider an LDAP client which offers an input dialog allowing the user to input a character string representing the desired authorization identity and a indicator of the format of that string. The user inputs the string "kurt@example.com" and selects the form identifier marked "user name". The LDAP client, knowing the requirements of the LDAP's SASL profile, takes this information and constructs the string "u:kurt@example.com" and transfers it as the authorization identity string in some mechanism (say EXTERNAL). The server needs to determine whether the user associated with the credentials is authorized to act as "u:kurt@example.com", but the server's identity assumption policy subsystem happens to requires identities to represented as email addresses with the domain part in upper case. So, the server produces the string "kurt@EXAMPLE.COM" and feeds this (and other information) to the identity assumption policy subsystem. Assuming success, the server now needs to produce an representation suitable for use in making authorization decisions. That subsystem might happen to require identities to be presented as DER encoded DNs. So the server somehow produces that. And in the actual policy, maybe DNs are presented using the LDAP DN string format. That is, one identity concept in authorization identity: the identity to act as with multiple identity representations. If we were to try to name each of distinct identity representations of the authorization identities that were likely evident in any application (both client and server) use of SASL, things will get confused. Developers will start to think that the form of the identity transferred on the wire is the actual form used elsewhere and, in particular, used in making authorization decisions. That is not necessarily so. For instance, I know of no LDAP server implementation that uses the particular form of authorization identity required by LDAP SASL profile in making authorization decisions. They all map the LDAP authzId string (even if the dnAuthzid variant is used) to some other format, such as an LDAP DN string. Kurt >>>Also, I suggest /not provided/omitted or empty/. >>> >>>> The server is responsible for verifying the user's >>>> credentials and verifying that the user is able to >>>> act as the authorization identity. >>> >>>s/user('s)/authentication identity('s)/. >> >> Since authentication identity is defined here as >> being the identity associated the credentials, would >> be effective saying: >> s/user's credentials/credentials of the identity >> associated with the credentials/ > >Well, I'd still like to get rid of that 'user'. 'User' is used >elsewhere as merely one kind of identity. >Maybe s/user's credentials/presented credentials/, >or s/users's credentials/credentials/, s/user/authentication identity/? > >>>> A SASL exchange >>>> is successful if and only if both of these verifications >>>> are successful. >>> >>>Security layer negotiation can also fail. >>>Or something can just plain break a specification. >> >> It may be better to reverse the statement: >> A SASL exchange fails if either (or both) of these >> verifications fails. > >Yes. > >>> However, the >> >> Noting my above note would apply here as well, I think >> this suggestion is a good one. >> >>>> precise form(s) >>> >>> and semantics >>> >>>> of the authentication identities (used >>>> within the server in its verifications, or otherwise) >>>> and the precise form(s) >>> >>> and semantics >> >> I have some concern here. In particular, the mechanism >> specification may cover some authentication identity >> semantics. Or, as you note below, the application >> profile may detail matching semantics. I think talking >> adding "and semantics" will just confuse things. > >Well, what I wanted to address was what I mentioned in my original review: > > > Any normalization of the authentication identity is defined by a > > particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. > >Your text doesn't seem to be clear on that. > >>>> In >>>> some circumstances, the precise identity forms used >>>> outside of the SASL exchange may be dictated by other >>>> specifications. For instance, the authorization policy >>>> specification for an application protocol may dictate the >>>> precise form that an authorization identity is to be >>>> represented in the authorization policy. >>> >>>Or the protocol profile may specify that authorization identities >>>are to be checked e.g. in a case-insensitive manner. >>> >>>Finally, what is the word 'application' doing here? What is an >>>'application profile'? Or an 'application protocol' as opposed to a >>>protocol'? >> >> I mean application-level protocol. I generally find the >> bare use of the term 'protocol' to be somewhat unclear. >> I rather quality the term with 'application-level'. However, >> that likely should be done consistently or not at all. > >Do you mean the OSI model application layer? If so, it needs a >reference to the OSI model. If not, I'm still not sure what you mean. >BTW, I notice that there are several other uses of 'application' in >rfc2222bis which I'm not quite sure of, now that it's bought up. > >Also, I would have thought SASL could be used at the presentation layer >as well. > >-- >Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHMeja044404; Thu, 21 Oct 2004 10:22:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LHMeFV044403; Thu, 21 Oct 2004 10:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHMcZm044385 for ; Thu, 21 Oct 2004 10:22:39 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CKge7-0005OL-7A; Thu, 21 Oct 2004 19:22:39 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKge3-000491-M7; Thu, 21 Oct 2004 19:22:35 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKge3-0006qg-00; Thu, 21 Oct 2004 19:22:35 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description In-Reply-To: <4177DA2A.8040702@isode.com> References: <4177DA2A.8040702@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 19:22:35 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>>7. The EXTERNAL mechanism >> The server uses information external to SASL to determine the >> authentication identity and whether the authentication is to >> succeed. > > Although this implies the same thing (if you take into consideration > implied authorization step), I would prefer the original text. Well, SASL mechanisms are now supposed to set an authentication identity, but EXTERNAL in the original or in your form doesn't. (I wish I'd realized that before posting.) OTOH, mixing rfc2222's paragraph 5 (authz id) into paragraph 3 was very nice, and my text should not have lost the 'system' doing authentication. If I mix your text and mine a bit, does this cover all bases? Some system external to SASL must authenticate the client. If that succeeds, the server determines the authentication identity from information from this system. If the requested authorization identity is empty, the authorization identity is derived from the authentication identity. The server determines if the authentication identity is allowed to act as the authorization identity. Finally, it indicates completion or failure of the authentication exchange. Or replace the last sentence with If all that succeeds, the server indicates successful completion of the authentication exchange; otherwise it indicates failure. Sigh. And this started with trying to make the text _shorter_:-) -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFlt1F021033; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LFltN0021032; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFlsJQ021026 for ; Thu, 21 Oct 2004 08:47:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 16:47:54 +0100 Message-ID: <4177DA2A.8040702@isode.com> Date: Thu, 21 Oct 2004 16:47:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: EXTERNAL description References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >>7. The EXTERNAL mechanism >> >> The client sends a single message containing the UTF-8 encoding of >> the >> >> > >Maybe add 'requested'? > Using "requested" here is Ok, IMHO. >> authorization identity. The message may be empty. The form of the >> authorization identity is further restricted by the application-level >> protocol's SASL profile. >> >> > >s/is further/may be/. (Further restricted than what? Being empty?:-) > Ok. >Though I'd move that last sentence to the last paragraph (below) so all >handling of the authorization identity is in one place. > >These paragraphs can be shortened a bit now that 'authentication >identities' have been introduced: > > >> The server uses information, external to SASL, to determine whether >> the client is permitted to authenticate as the authorization >> identity. If the client is so authorized, the server indicates >> successful completion of the authentication exchange; otherwise the >> server indicates failure. >> >> > > The server uses information external to SASL to determine the > authentication identity and whether the authentication is to > succeed. > Although this implies the same thing (if you take into consideration implied authorization step), I would prefer the original text. > It then indicates completion or failure of the > authentication exchange. > Here is the latest text for SASL EXTERNAL. This is not exactly what you've asked, but let me know what you think: The mechanism name associated with external authentication is "EXTERNAL". The client sends a single message containing the UTF-8 encoding of the requested authorization identity. The message may be empty. The form of the authorization identity may be restricted by the application protocol's SASL profile. The server uses information, external to SASL, to determine whether the client is permitted to act as the authorization identity. (If the requested authorization identity is empty, the authorization identity is to be derived from authentication credentials which exist in the system that is providing the external authentication.) If the client is permitted to do so, the server indicates successful completion of the authentication exchange; otherwise the server indicates failure. The system providing this external information may be, for example, IPSec [IPSec] or TLS [TLS]. 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. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFN8p7014230; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LFN8KX014229; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LFN7LX014211 for ; Thu, 21 Oct 2004 08:23:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 16:23:08 +0100 Message-ID: <4177D45C.2050404@isode.com> Date: Thu, 21 Oct 2004 16:23:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >>3.1. Authentication protocol exchange >> >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. >> > >I don't think so. It's the protocol which conducts the _exchange_, >and (below) which transmits anything. > What about A SASL mechanism is responsible for conducting an authentication exchange. ? The mechanism is clearly "conducting" the exchange, but the protocols carries it. >[...] > >> The mechanism MUST preserve Unicode codepoint when transferring >> authorization identity (e.g. the mechanism cann't apply any form of >> normalization). >> > >The () part does not seem say the same as the preceding sentence: 'when >transferring...' sounds like only the client-side part of the mechanism >must preserve the ID, while the () sounds like the server side also must >preserve it. The text in () only talks about transfer (actually it also applies to hashing and other similar uses). For the purposes of looking up credentials, access control, etc. the server can do as it pleases. This is out of scope for SASL. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LEaGBk001179; Thu, 21 Oct 2004 07:36:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LEaGaF001178; Thu, 21 Oct 2004 07:36:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LEaFiN001172 for ; Thu, 21 Oct 2004 07:36:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 15:36:09 +0100 Message-ID: <4177C959.2060205@isode.com> Date: Thu, 21 Oct 2004 15:36:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <6.1.2.0.0.20041001102809.04165318@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: Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > > >>At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >> >> >>>>Abstract >>>> >>>> >>>> The Simple Authentication and Security Layer (SASL) is a framework >>>> for providing authentication and data security services in >>>> connection-oriented protocols via replaceable >>>> >>>> >>>authentication >>> >>> >>The sentence might be more clear if worded: >> The Simple Authentication and Security Layer (SASL) is >> a framework for providing authentication and data security >> services via replaceable mechanisms to connection-oriented >> protocols. >> >> > >I don't think so; it looks a little strange to have the 'to...' after >the 'via...'. Maybe s/in/to/ would improve the original sentence. > >I've asked a coworker what he thought the Abstract meant: He got it more >or less right, but was somewhat vague about it and thought it was a bit >hard to get. He did not think my suggested extra words would make a >difference. > > Unless somebody objects, I am leaving the sentence as is. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDppbR089047; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDppMj089046; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDpo7f089039 for ; Thu, 21 Oct 2004 06:51:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 14:51:51 +0100 Message-ID: <4177BEF7.6050604@isode.com> Date: Thu, 21 Oct 2004 14:51:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC References: <6.1.2.0.0.20040924123829.0433b4c8@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: Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > > >>1) Re-keying of security layers >> >> SASL mechanisms that support re-keying SHOULD: >> - indicate that re-keying is or will be needed immediately; >> - provide re-keying messages or transparently include re-keying >> messages in the security layers; the latter can happen without >> application involvement, but only as long as the application is >> engaged in timely bidirectional exchanges with its peer. >> >>The chairs believes the WG supports addition of this text. >> > >Please also explain what 're-keying' and 'timely bidirectional >exchanges' are. > >(I'm guessing that re-keying is a SASL layer's equivalent of TLS >ciphersuite renegotiation, but I don't know. > Correct me if I am wrong, but I understand rekeying as "renegotiation of the signing/encrypting key". But I agree with you, those two terms must be explained. And I am not sure I can give a good definition for 'timely bidirectional exchange' > I don't know if I would >have thought of that if I did not know of TLS. I have no idea how a >protocol or implementation can know that a peer will be engage in >anything 'timely'. I'm not sure what exactly 'bidirectional exchanges' >are either, but from the context my guess would be that if one peer >chooses to send a message, the other is expected to notice and send a >response, and do so before sending (or also reading?) anything else on >the connection.) > > Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDi4qh087168; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDi4S9087167; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDi3KQ087142 for ; Thu, 21 Oct 2004 06:44:04 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CKdEY-00071Y-Lq; Thu, 21 Oct 2004 15:44:02 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKdEV-0004JJ-1q; Thu, 21 Oct 2004 15:43:59 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKdEU-0006Fx-00; Thu, 21 Oct 2004 15:43:58 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416CFBDA.8000707@isode.com> References: <416BFDAA.3090507@isode.com> <416CFBDA.8000707@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 15:43:58 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>>>>6.1. Client sends data first >>>>> >>>>> 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.) >>>>> >>>>> >>>>Then protocols that support an initial response must be clear on how to >>>>distinguish an absent initial response from a present but empty initial >>>>response. I expect their protocol profiles must also specify whether or >>>>not the protocol _can_ distinguish the two, so the mechanism can tell >>>>whether or not to send empty initial responses. >>>> >>>> >>> This is described in Section 4, bullet # 2. >> >>No... First, it's only a SHOULD: >> >> If the protocol allows for the initial response, the protocol profile >> SHOULD also describe how an empty initial response is encoded. >> > I've already changed SHOULD to MUST. This issue was raised during WGLC. > >>Second, if that sentence is intended to address this issue, I can think >>of two different things it can imply in order to do so. It is not at >>all clear to me that it means either: >> >>1) "If the protocol profile does not say how an initial response is >> encoded, then empty but present initial responses are not supported." >> >>2) If you s/SHOULD/MUST/: "If initial responses are supported, then it >> MUST be possible to send an empty initial response which can be >> distinguished from no initial response." > > The intention was to say #2. I am not aware of any protocol profile that > supports initial response, but doesn't allow for it being empty. Me neither, which is why I used an imaginary example. But I've just realized that your answer opens for a third possibility: Protocols that do allow empty initial responses, but not absent initial responses. (Again, an SMTP-like protocol which strips trailing whitespace could be an example.) -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDdjdi085938; Thu, 21 Oct 2004 06:39:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LDdjNN085937; Thu, 21 Oct 2004 06:39:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LDdhSc085902 for ; Thu, 21 Oct 2004 06:39:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CKdAK-0005cO-Pi; Thu, 21 Oct 2004 15:39:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CKdA9-0003jR-OV; Thu, 21 Oct 2004 15:39:29 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CKdA9-0006Eb-00; Thu, 21 Oct 2004 15:39:29 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis In-Reply-To: <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 21 Oct 2004 15:39:29 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry about the late replies; I thought I had addressed this. Kurt D. Zeilenga writes: >At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>> 3.2 Identity Concepts >> >>> The client provides its credentials and, optionally, a >>> string representing the requested authorization identity >>> as part of the SASL exchange. >> >>> When this string is not >>> provided, the client is requesting to act as the identity >>> associated with the credentials (e.g., the user is >>> requesting to act as the authentication identity). >> >>No, authentication identity may not even have a syntax which is valid >>for an authorization identity. > > An identity can be represented in many different ways. > Here I am using the terms "authentication identity" > and "authorization identity" conceptional, and > generally without regards to how they might be represented > at any given time or place. When I referred to a "string > representing the requested authorization identity", I > referred to a particular representation of an identity. > But when I said, "the client is requesting to act as the > [authentication identity]", I didn't talk about how that > identity would be represented. > >>The client is requesting that the >>authorization identity is derived from the authentication identity. > > Conceptionally, the client is requesting the act as the > identity associated with credentials. This identity > might have many different representations. I hadn't quite caught on to the 'conceptual' part, but it seems rather confusing to have the same names for 'conceptual' and 'represented' identities. But even so, authorization identities and authentication identities seem to me to be 'conceptually' different types of entities; defined by different standards and used in different ways. So whether we talk of conceptual or represented identities, I'd still prefer to say that the authorization id is derived from the authentication id rather than it is the authentication id. >>Also, I suggest /not provided/omitted or empty/. >> >>> The server is responsible for verifying the user's >>> credentials and verifying that the user is able to >>> act as the authorization identity. >> >>s/user('s)/authentication identity('s)/. > > Since authentication identity is defined here as > being the identity associated the credentials, would > be effective saying: > s/user's credentials/credentials of the identity > associated with the credentials/ Well, I'd still like to get rid of that 'user'. 'User' is used elsewhere as merely one kind of identity. Maybe s/user's credentials/presented credentials/, or s/users's credentials/credentials/, s/user/authentication identity/? >>> A SASL exchange >>> is successful if and only if both of these verifications >>> are successful. >> >>Security layer negotiation can also fail. >>Or something can just plain break a specification. > > It may be better to reverse the statement: > A SASL exchange fails if either (or both) of these > verifications fails. Yes. >> However, the > > Noting my above note would apply here as well, I think > this suggestion is a good one. > >>> precise form(s) >> >> and semantics >> >>> of the authentication identities (used >>> within the server in its verifications, or otherwise) >>> and the precise form(s) >> >> and semantics > > I have some concern here. In particular, the mechanism > specification may cover some authentication identity > semantics. Or, as you note below, the application > profile may detail matching semantics. I think talking > adding "and semantics" will just confuse things. Well, what I wanted to address was what I mentioned in my original review: > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. That's a bit misleading from the protocol's point of view. From discussions elsewhere I gather the protocol may normalize the ID as it pleases for its own use, including when it locates the server-side secret matching the authentication ID, as long as this does not affect the ID which the authentication mechanism sees. Your text doesn't seem to be clear on that. >>> In >>> some circumstances, the precise identity forms used >>> outside of the SASL exchange may be dictated by other >>> specifications. For instance, the authorization policy >>> specification for an application protocol may dictate the >>> precise form that an authorization identity is to be >>> represented in the authorization policy. >> >>Or the protocol profile may specify that authorization identities >>are to be checked e.g. in a case-insensitive manner. >> >>Finally, what is the word 'application' doing here? What is an >>'application profile'? Or an 'application protocol' as opposed to a >>protocol'? > > I mean application-level protocol. I generally find the > bare use of the term 'protocol' to be somewhat unclear. > I rather quality the term with 'application-level'. However, > that likely should be done consistently or not at all. Do you mean the OSI model application layer? If so, it needs a reference to the OSI model. If not, I'm still not sure what you mean. BTW, I notice that there are several other uses of 'application' in rfc2222bis which I'm not quite sure of, now that it's bought up. Also, I would have thought SASL could be used at the presentation layer as well. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LCQ2sT067990; Thu, 21 Oct 2004 05:26:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LCQ29Z067989; Thu, 21 Oct 2004 05:26:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LCQ0s6067948 for ; Thu, 21 Oct 2004 05:26:01 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 21 Oct 2004 13:25:45 +0100 Message-ID: <4177AAC9.8080606@isode.com> Date: Thu, 21 Oct 2004 13:25:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: Some editorial changes to RFC2222bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard has suggested to change "mechanism specific"/"protocol specific" to "mechanism-specific"/"protocol-specific". If you have any opinion on this (or maybe you know what is the right way), please let me know by the end of Friday. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F9Le8k036264; Fri, 15 Oct 2004 02:21:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F9Lei4036263; Fri, 15 Oct 2004 02:21:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F9LcvC036238 for ; Fri, 15 Oct 2004 02:21:39 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 15 Oct 2004 10:21:35 +0100 Message-ID: <416F969D.3060703@isode.com> Date: Fri, 15 Oct 2004 10:21:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D635D.4090105@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050904030104050703090604" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------050904030104050703090604 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>> Made requirement to verify that an authorization identity is correct >>> by performing SASLprep a SHOULD, instead of a MUST. >>> >>> >>I've changed this to: >> >> Made requirement to verify that an authorization identity is correct >> by performing SASLprep. >> >>Is this better? >> >> > >No, because it's not a requirement:-) > Fine, but see below. > Anyway, I think this paragraph can >simply be deleted, since it's just part of the 'I-D revision history'. >The appendix already covers SASLprep as RFC history: > > Added text about SASLprep for authentication identities and > passwords. Described where SASLprep preparation should take place. > > This doesn't cover authorization identities. --------------050904030104050703090604 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
Alexey Melnikov writes:
  
  Made requirement to verify that an authorization identity is correct
  by performing SASLprep a SHOULD, instead of a MUST.
      
I've changed this to:

   Made requirement to verify that an authorization identity is correct
   by performing SASLprep.

Is this better?
    

No, because it's not a requirement:-)
Fine, but see below.
 Anyway, I think this paragraph can
simply be deleted, since it's just part of the 'I-D revision history'.
The appendix already covers SASLprep as RFC history:

   Added text about SASLprep for authentication identities and
   passwords.  Described where SASLprep preparation should take place.
This doesn't cover authorization identities.

--------------050904030104050703090604-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F29P98095492; Thu, 14 Oct 2004 19:09:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F29PN9095491; Thu, 14 Oct 2004 19:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F29O3N095479 for ; Thu, 14 Oct 2004 19:09:24 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9F29RZv056489; Fri, 15 Oct 2004 02:09:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041014182949.02d34360@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Oct 2004 19:10:17 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@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 06:19 PM 10/14/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> 3.2 Identity Concepts > >> The client provides its credentials and, optionally, a >> string representing the requested authorization identity >> as part of the SASL exchange. > >> When this string is not >> provided, the client is requesting to act as the identity >> associated with the credentials (e.g., the user is >> requesting to act as the authentication identity). > >No, authentication identity may not even have a syntax which is valid >for an authorization identity. An identity can be represented in many different ways. Here I am using the terms "authentication identity" and "authorization identity" conceptional, and generally without regards to how they might be represented at any given time or place. When I referred to a "string representing the requested authorization identity", I referred to a particular representation of an identity. But when I said, "the client is requesting to act as the [authentication identity]", I didn't talk about how that identity would be represented. >The client is requesting that the >authorization identity is derived from the authentication identity. Conceptionally, the client is requesting the act as the identity associated with credentials. This identity might have many different representations. >Also, I suggest /not provided/omitted or empty/. > >> The server is responsible for verifying the user's >> credentials and verifying that the user is able to >> act as the authorization identity. > >s/user('s)/authentication identity('s)/. Since authentication identity is defined here as being the identity associated the credentials, would be effective saying: s/user's credentials/credentials of the identity associated with the credentials/ >s/able/allowed/. Okay. >> A SASL exchange >> is successful if and only if both of these verifications >> are successful. > >Security layer negotiation can also fail. >Or something can just plain break a specification. It may be better to reverse the statement: A SASL exchange fails if either (or both) of these verifications fails. >> While SASL mechanisms specify the form of credentials >> used to authenticating users and SASL application >> profiles specify the form of authorization identities >> transferred as part of authentication exchange, the I note that s/SASL mechanisms specify/SASL mechanism specifications describe/, s/profiles specify/profiles describe/. That is, we need to be careful not to use the term "mechanism" to refer to a mechanism's specification. >This sentence needs to be broken up. > > SASL mechanisms specify the form of credentials > used to authenticating users, and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange. > However, the Noting my above note would apply here as well, I think this suggestion is a good one. >> precise form(s) > > and semantics > >> of the authentication identities (used >> within the server in its verifications, or otherwise) >> and the precise form(s) > > and semantics I have some concern here. In particular, the mechanism specification may cover some authentication identity semantics. Or, as you note below, the application profile may detail matching semantics. I think talking adding "and semantics" will just confuse things. >> of the authorization identities >> (used in making authorization decisions, or otherwise) is >> beyond the scope of the SASL and this specification. > >> In >> some circumstances, the precise identity forms used >> outside of the SASL exchange may be dictated by other >> specifications. For instance, the authorization policy >> specification for an application protocol may dictate the >> precise form that an authorization identity is to be >> represented in the authorization policy. > >Or the protocol profile may specify that authorization identities >are to be checked e.g. in a case-insensitive manner. > >Finally, what is the word 'application' doing here? What is an >'application profile'? Or an 'application protocol' as opposed to a >protocol'? I mean application-level protocol. I generally find the bare use of the term 'protocol' to be somewhat unclear. I rather quality the term with 'application-level'. However, that likely should be done consistently or not at all. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F1Jj8x089679; Thu, 14 Oct 2004 18:19:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F1JjEi089678; Thu, 14 Oct 2004 18:19:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F1Jilv089671 for ; Thu, 14 Oct 2004 18:19:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CIGl1-0004ZZ-6l; Fri, 15 Oct 2004 03:19:47 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIGky-0003Mv-AG; Fri, 15 Oct 2004 03:19:44 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIGkw-0005Z7-00; Fri, 15 Oct 2004 03:19:42 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis In-Reply-To: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 03:19:42 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > 3.2 Identity Concepts > The client provides its credentials and, optionally, a > string representing the requested authorization identity > as part of the SASL exchange. > When this string is not > provided, the client is requesting to act as the identity > associated with the credentials (e.g., the user is > requesting to act as the authentication identity). No, authentication identity may not even have a syntax which is valid for an authorization identity. The client is requesting that the authorization identity is derived from the authentication identity. Also, I suggest /not provided/omitted or empty/. > The server is responsible for verifying the user's > credentials and verifying that the user is able to > act as the authorization identity. s/user('s)/authentication identity('s)/. s/able/allowed/. > A SASL exchange > is successful if and only if both of these verifications > are successful. Security layer negotiation can also fail. Or something can just plain break a specification. > While SASL mechanisms specify the form of credentials > used to authenticating users and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange, the This sentence needs to be broken up. SASL mechanisms specify the form of credentials used to authenticating users, and SASL application profiles specify the form of authorization identities transferred as part of authentication exchange. However, the > precise form(s) and semantics > of the authentication identities (used > within the server in its verifications, or otherwise) > and the precise form(s) and semantics > of the authorization identities > (used in making authorization decisions, or otherwise) is > beyond the scope of the SASL and this specification. > In > some circumstances, the precise identity forms used > outside of the SASL exchange may be dictated by other > specifications. For instance, the authorization policy > specification for an application protocol may dictate the > precise form that an authorization identity is to be > represented in the authorization policy. Or the protocol profile may specify that authorization identities are to be checked e.g. in a case-insensitive manner. Finally, what is the word 'application' doing here? What is an 'application profile'? Or an 'application protocol' as opposed to a protocol'? -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0lhjN084566; Thu, 14 Oct 2004 17:47:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F0lhLs084565; Thu, 14 Oct 2004 17:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0le7k084555 for ; Thu, 14 Oct 2004 17:47:41 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CIGFz-0006UV-PM; Fri, 15 Oct 2004 02:47:43 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIGFx-0002P9-1J; Fri, 15 Oct 2004 02:47:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIGFw-0005VT-00; Fri, 15 Oct 2004 02:47:40 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C In-Reply-To: <416D635D.4090105@isode.com> References: <416D635D.4090105@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 02:47:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >> Made requirement to verify that an authorization identity is correct >> by performing SASLprep a SHOULD, instead of a MUST. > > I've changed this to: > > Made requirement to verify that an authorization identity is correct > by performing SASLprep. > > Is this better? No, because it's not a requirement:-) Anyway, I think this paragraph can simply be deleted, since it's just part of the 'I-D revision history'. The appendix already covers SASLprep as RFC history: Added text about SASLprep for authentication identities and passwords. Described where SASLprep preparation should take place. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0Q3AO080886; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F0Q3IQ080885; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0Q2hh080867 for ; Thu, 14 Oct 2004 17:26:03 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CIFv3-00030U-Je for ietf-sasl@imc.org; Fri, 15 Oct 2004 02:26:05 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIFv1-0005lo-U0; Fri, 15 Oct 2004 02:26:03 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIFv0-0005Qo-00; Fri, 15 Oct 2004 02:26:02 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: EXTERNAL description Date: Fri, 15 Oct 2004 02:26:02 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 7. The EXTERNAL mechanism > The client sends a single message containing the UTF-8 encoding of > the Maybe add 'requested'? > authorization identity. The message may be empty. The form of the > authorization identity is further restricted by the application-level > protocol's SASL profile. s/is further/may be/. (Further restricted than what? Being empty?:-) Though I'd move that last sentence to the last paragraph (below) so all handling of the authorization identity is in one place. These paragraphs can be shortened a bit now that 'authentication identities' have been introduced: > The server uses information, external to SASL, to determine whether > the client is permitted to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > server indicates failure. The server uses information external to SASL to determine the authentication identity and whether the authentication is to succeed. It then indicates completion or failure of the authentication exchange. > 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. If the requested authorization identity is empty, the authorization identity is to be derived from the authentication identity. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EMpPHg069070; Thu, 14 Oct 2004 15:51:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EMpPwe069069; Thu, 14 Oct 2004 15:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EMpNNX069048 for ; Thu, 14 Oct 2004 15:51:24 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CIERP-0000gX-GF for ietf-sasl@imc.org; Fri, 15 Oct 2004 00:51:23 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CIERN-0002iS-67; Fri, 15 Oct 2004 00:51:21 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CIERM-0005El-00; Fri, 15 Oct 2004 00:51:20 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: Summary of 2222bis WGLC In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> References: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 15 Oct 2004 00:51:20 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: > 1) Re-keying of security layers > SASL mechanisms that support re-keying SHOULD: > - indicate that re-keying is or will be needed immediately; > - provide re-keying messages or transparently include re-keying > messages in the security layers; the latter can happen without > application involvement, but only as long as the application is > engaged in timely bidirectional exchanges with its peer. > > The chairs believes the WG supports addition of this text. Please also explain what 're-keying' and 'timely bidirectional exchanges' are. (I'm guessing that re-keying is a SASL layer's equivalent of TLS ciphersuite renegotiation, but I don't know. I don't know if I would have thought of that if I did not know of TLS. I have no idea how a protocol or implementation can know that a peer will be engage in anything 'timely'. I'm not sure what exactly 'bidirectional exchanges' are either, but from the context my guess would be that if one peer chooses to send a message, the other is expected to notice and send a response, and do so before sending (or also reading?) anything else on the connection.) > 4) Channel Binding > Nico (...) suggest security consideration > text that clients using SASL over TLS should verify > the server's TLS identity to prevent MITM attacks. > He also suggested (...) > > The chairs conclude that the WG supports the former > suggestion but not the latter. Unless just that literal text will be used (except for expanding "MITM"): Note that the draft does not explain what channel bindings are, so either explain or avoid the term. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E9YOeN023822; Thu, 14 Oct 2004 02:34:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E9YObv023821; Thu, 14 Oct 2004 02:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E9YNjV023798 for ; Thu, 14 Oct 2004 02:34:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 10:33:53 +0100 Message-ID: <416D9CD6.8010309@isode.com> Date: Wed, 13 Oct 2004 22:23:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060000090909080107050306" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------060000090909080107050306 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>>>5. Mechanism profile guidelines >>>> >>>> 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 MUST fail the authentication exchange. >>>> >>>> >>>I expect preparation of an empty string should not fail, so: >>>s/results in/turns a non-empty string into/. >>> >>> >> This text is talking about authentication identities and passwords. I am >> not sure whether the empty string should be allowed. >> >> > >I can see nothing which forbids it, neither in rfc2222 nor 2222bis. > >I have certainly set empty passwords on Unix boxes (off the net); if >there is a SASL library which allows empty passwords then I assume >people have found use for them with SASL too. > >I expect an empty authentication IDs would be messier, unless the >authorization ID which is derived from that ID is non-empty. > > > Ok, I have done the proposed change. Can anybody suggest a better wording? --------------060000090909080107050306 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
5.    Mechanism profile guidelines   

   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 MUST fail the authentication exchange.
        
I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
      
 This text is talking about authentication identities and passwords. I am
 not sure whether the empty string should be allowed.
    

I can see nothing which forbids it, neither in rfc2222 nor 2222bis.

I have certainly set empty passwords on Unix boxes (off the net); if
there is a SASL library which allows empty passwords then I assume
people have found use for them with SASL too.

I expect an empty authentication IDs would be messier, unless the
authorization ID which is derived from that ID is non-empty.
Ok, I have done the proposed change. Can anybody suggest a better wording?

--------------060000090909080107050306-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E02QbS065062; Wed, 13 Oct 2004 17:02:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E02Qe5065061; Wed, 13 Oct 2004 17:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E02PFX065054 for ; Wed, 13 Oct 2004 17:02:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9E02fZv048950; Thu, 14 Oct 2004 00:02:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013165411.02d58a48@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 17:03:33 -0700 To: =?iso-8859-1?Q?Jes=FAs?= =?iso-8859-1?Q?_Garc=EDa?= Crespo (aka Sevein) From: "Kurt D. Zeilenga" Subject: Re: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Cc: ietf-sasl@vpnc.org In-Reply-To: <20041014013710.69560630@jesus.sevein.red> References: <20041014013710.69560630@jesus.sevein.red> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9E02QFX065055 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please note that this list is for discussing the standardization of SASL and, in particular, undertaking the work of the IETF SASL WG . Your post is off-topic here. Issues specific to any particular SASL implementation should be directed to forums specific to that implementation. From your message, I gather you are using the Cyrus SASL implementation. Hence, I suggest you direct your comments to: Information regarding how to subscribe to this list is available at: http://asg.web.cmu.edu/sasl/#mailinglists Thanks, Kurt - IETF SASL WG co-chair At 04:37 PM 10/13/2004, aka Sevein wrote: >Hi! I am a Linux user who is trying to configure his own server in Internet to give services like www, smtp, imap and that stuff. I have been trying to do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd with rimap to auth users against courier-imap (and authdaemond agains MySQL). > >But I thought that it could be better to configure sasl to connect directly to authdaemond socket. I tried it. But I got this error (always): > >[postfix/smtpd] warning: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused > >My configuration files: > >/etc/sasl/smtpd.conf >^^^^^^^^^^^^^^^^^^^^ >pwcheck_method: authdaemond >authdaemon_path: /var/lib/courier-imap/authdaemon/socket >mech_list: plain login >log_level: 7 > >ls -li /var/lib/courier-imap/authdaemon/socket >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdaemon/socket > >Moreover, I did this because I though about the Postfix chroot: >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ > >ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/courier-imap/authdaemon/socket > >I always restart Postfix when I make changes. > > >Gentoo Linux >courier-imap-3.0.7 >cyrus-sasl-2.1.19-r1 (with authdaemond support) >postfix-2.1.3 > >Do you know what could I do? I am tired of the same! > > >-- >Jesús García Crespo (aka Sevein) >http://www.sevein.com >correo@sevein.com > >GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNfD3Y062421; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DNfDal062420; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.mundophp.info ([65.98.66.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNfDZM062414 for ; Wed, 13 Oct 2004 16:41:13 -0700 (PDT) (envelope-from correo@sevein.com) Received: from jesus.sevein.red (4.Red-217-125-56.pooles.rima-tde.net [217.125.56.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mundophp.info (Postfix) with ESMTP id EB0B75363 for ; Thu, 14 Oct 2004 01:41:32 +0200 (CEST) Date: Thu, 14 Oct 2004 01:41:24 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) To: ietf-sasl@imc.org Subject: Fw: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Message-ID: <20041014014124.05ed8f8a@jesus.sevein.red> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I am a Linux user who is trying to configure his own server in Internet= to give services like www, smtp, imap and that stuff. I have been trying t= o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi= th rimap to auth users against courier-imap (and authdaemond agains MySQL). But I thought that it could be better to configure sasl to connect directly= to authdaemond socket. I tried it. But I got this error (always): [postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou= rier authdaemond: Connection refused My configuration files: /etc/sasl/smtpd.conf ^^^^^^^^^^^^^^^^^^^^ pwcheck_method: authdaemond authdaemon_path: /var/lib/courier-imap/authdaemon/socket mech_list: plain login log_level: 7 ls -li /var/lib/courier-imap/authdaemon/socket=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae= mon/socket Moreover, I did this because I though about the Postfix chroot: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri= er-imap/authdaemon/socket I always restart Postfix when I make changes. Gentoo Linux courier-imap-3.0.7 cyrus-sasl-2.1.19-r1 (with authdaemond support) postfix-2.1.3 Do you know what could I do? I am tired of the same! --=20 Jes=FAs Garc=EDa Crespo (aka Sevein) http://www.sevein.com correo@sevein.com GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBbb0qjm2pe+LbF+gRAkw8AJ40rran0f8VTpuqz6DHqpVKnZXsQQCeO5Y+ v1eTceKe0smJlt1sX9Kk/Kk= =yucx -----END PGP SIGNATURE----- --Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNawxJ061789; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DNawxs061788; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.mundophp.info ([65.98.66.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DNavZv061782 for ; Wed, 13 Oct 2004 16:36:58 -0700 (PDT) (envelope-from correo@sevein.com) Received: from jesus.sevein.red (4.Red-217-125-56.pooles.rima-tde.net [217.125.56.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mundophp.info (Postfix) with ESMTP id 66D105363 for ; Thu, 14 Oct 2004 01:37:17 +0200 (CEST) Date: Thu, 14 Oct 2004 01:37:10 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) To: ietf-sasl@vpnc.org Subject: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused Message-ID: <20041014013710.69560630@jesus.sevein.red> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I am a Linux user who is trying to configure his own server in Internet= to give services like www, smtp, imap and that stuff. I have been trying t= o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi= th rimap to auth users against courier-imap (and authdaemond agains MySQL). But I thought that it could be better to configure sasl to connect directly= to authdaemond socket. I tried it. But I got this error (always): [postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou= rier authdaemond: Connection refused My configuration files: /etc/sasl/smtpd.conf ^^^^^^^^^^^^^^^^^^^^ pwcheck_method: authdaemond authdaemon_path: /var/lib/courier-imap/authdaemon/socket mech_list: plain login log_level: 7 ls -li /var/lib/courier-imap/authdaemon/socket=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 114898 srwxrwxrwx 1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae= mon/socket Moreover, I did this because I though about the Postfix chroot: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/ ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri= er-imap/authdaemon/socket I always restart Postfix when I make changes. Gentoo Linux courier-imap-3.0.7 cyrus-sasl-2.1.19-r1 (with authdaemond support) postfix-2.1.3 Do you know what could I do? I am tired of the same! --=20 Jes=FAs Garc=EDa Crespo (aka Sevein) http://www.sevein.com correo@sevein.com GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org) --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBbbwrjm2pe+LbF+gRAgDuAJ9B6gbh33E5sWkCNJJGei7b4+0NrwCdGWH5 bNigMOZVe14WiiwdQrMIJok= =F28/ -----END PGP SIGNATURE----- --Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHIQS3008951; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DHIQV3008950; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHIPpv008941 for ; Wed, 13 Oct 2004 10:18:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 18:18:23 +0100 Message-ID: <416D635D.4090105@isode.com> Date: Wed, 13 Oct 2004 18:18:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >RFC 2222 did not refer to UTF-8 at all. OTOH, the new UTF-8 >MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned. > > Replaced "buffers of security encoded data" with "buffers of > protected data" for clarity. > > This should read: Replaced "buffers of cipher-text" with "buffers of protected data" for clarity. >That first phrase does not occur in rfc2222. > > Made requirement to verify that an authorization identity is correct > by performing SASLprep a SHOULD, instead of a MUST. > > I've changed this to: Made requirement to verify that an authorization identity is correct by performing SASLprep. Is this better? >rfc2222 does not contain a single MUST. And if that SHOULD is the one >in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is >correct, not that the ID itself is correct. > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGggIp003005; Wed, 13 Oct 2004 09:42:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DGggVu003004; Wed, 13 Oct 2004 09:42:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGgfad002995 for ; Wed, 13 Oct 2004 09:42:41 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9DGgxZv046723; Wed, 13 Oct 2004 16:42:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013092648.02d02a10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 09:43:51 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis Appendix C Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <416D5672.4010506@isode.com> References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@isode.com> <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> <416D5672.4010506@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 09:23 AM 10/13/2004, Alexey Melnikov wrote: >The more precise questions are: >1). Do we want to keep it (the answer I got so far is "yes") Yes. When revising an existing RFC, it is generally appropriate to summarize the changes made. This information is quite useful to readers of the new RFC, especially to those who implemented the existing RFC. >2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication. First, if such a list is maintained, it must be maintained separately from the above summary. Anways, (as you note) such a list would not be subject to WG review as it would be removed prior to publication. Though some WG find such lists useful, they are certainly not necessary. Given that this document is already through WG last call, I don't see how such a list could be useful to the WG or during subsequent IETF and IESG review. Personally, I think our energy would be better spent ensuring the summary of changes since RFC 2222 was of good quality. So, no. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGNBPF000425; Wed, 13 Oct 2004 09:23:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DGNBSa000424; Wed, 13 Oct 2004 09:23:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGN9ef000418 for ; Wed, 13 Oct 2004 09:23:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 17:23:15 +0100 Message-ID: <416D5672.4010506@isode.com> Date: Wed, 13 Oct 2004 17:23:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@isode.com> <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> Content-Type: multipart/alternative; boundary="------------010105090404090300040408" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------010105090404090300040408 Content-type: text/plain; charset="us-ascii" Kurt D. Zeilenga wrote: >At 07:17 AM 10/13/2004, Alexey Melnikov wrote: > > >>Jeffrey Hutzelman wrote: >> >> >>>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: >>> >>> >>>>Hallvard B Furuseth wrote: >>>> >>>> >>>>>I think Appendix C (Changes since RFC 2222) includes an extract of >>>>>changes between various rfc2222/rfc2222bis versions, rather than just >>>>>changes since RFC 2222. >>>>> >>>>> >>>>That is correct. >>>> >>>>Question to the WG: should I clean up the Appendix C or should I wait >>>>till the document is approved for publication? >>>> >>>> > >As the WG must review and reach consensus as to content of >Appendix before it submitted to the AD for consideration, >it should be cleaned up now. > > Ok. The more precise questions are: 1). Do we want to keep it (the answer I got so far is "yes") 2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication. >>>This section is essentially a changelog. >>> >>> >>Yes. >> >> > >When I think of an I-D changelog, I think of a log of changes >between each revision of the I-D. This is not that. > > In practice it is kind of "in between". I was updating it each time a major change was done, but each change was only recorded once (even if multiple revisions had to deal with the same change). Alexey --------------010105090404090300040408 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Kurt D. Zeilenga wrote:
At 07:17 AM 10/13/2004, Alexey Melnikov wrote:
  
Jeffrey Hutzelman wrote:
    
On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov <Alexey.Melnikov@isode.com> wrote:
      
Hallvard B Furuseth wrote:
        
I think Appendix C (Changes since RFC 2222) includes an extract of
changes between various rfc2222/rfc2222bis versions, rather than just
changes since RFC 2222.
          
That is correct.

Question to the WG: should I clean up the Appendix C or should I wait
till the document is approved for publication?
        

As the WG must review and reach consensus as to content of
Appendix before it submitted to the AD for consideration,
it should be cleaned up now.
Ok.

The more precise questions are:
1). Do we want to keep it (the answer I got so far is "yes")
2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication.
This section is essentially a changelog.
      
Yes.
    

When I think of an I-D changelog, I think of a log of changes
between each revision of the I-D.  This is not that.
In practice it is kind of "in between". I was updating it each time a major change was done, but each change was only recorded once (even if multiple revisions had to deal with the same change).

Alexey

--------------010105090404090300040408-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFmu6q096335; Wed, 13 Oct 2004 08:48:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFmuLa096334; Wed, 13 Oct 2004 08:48:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFmtRZ096328 for ; Wed, 13 Oct 2004 08:48:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9DFnAZv046359; Wed, 13 Oct 2004 15:49:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041013084105.02e6c7b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Oct 2004 08:50:02 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis Appendix C Cc: Jeffrey Hutzelman , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <416D38F6.6070403@isode.com> References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> <416D38F6.6070403@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 07:17 AM 10/13/2004, Alexey Melnikov wrote: >Jeffrey Hutzelman wrote: > >>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: >> >>>Hallvard B Furuseth wrote: >>> >>>>I think Appendix C (Changes since RFC 2222) includes an extract of >>>>changes between various rfc2222/rfc2222bis versions, rather than just >>>>changes since RFC 2222. >>> >>>That is correct. >>> >>>Question to the WG: should I clean up the Appendix C or should I wait >>>till the document is approved for publication? As the WG must review and reach consensus as to content of Appendix before it submitted to the AD for consideration, it should be cleaned up now. >>This section is essentially a changelog. > >Yes. When I think of an I-D changelog, I think of a log of changes between each revision of the I-D. This is not that. >>Normally, such sections are intended for use during the development of a document, and carry a note to the RFC-Editor asking that they be removed prior to publication. If this appendix were a log of changes between each revision of the I-D, I would agree. But this appendix is not that. It is summary of changes made to RFC 2222. >>I think that would be the apporpriate thing to do in this case. > >I disagree. I find such section quite useful when one has to quickly find out about changes since an older RFC. Yes. The purpose of this section is to provide useful information to the reader of the RFC regarding changes since RFC 2222. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFXwJi094465; Wed, 13 Oct 2004 08:33:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFXwVS094463; Wed, 13 Oct 2004 08:33:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFXvZ3094445 for ; Wed, 13 Oct 2004 08:33:57 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHl8l-0000OY-CK; Wed, 13 Oct 2004 17:34:11 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHl8i-0003iL-2D; Wed, 13 Oct 2004 17:34:08 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHl8h-0000bf-00; Wed, 13 Oct 2004 17:34:07 +0200 From: Hallvard B Furuseth Message-Id: To: Jeffrey Hutzelman Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <490070000.1097680744@minbar.fac.cs.cmu.edu> References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> <490070000.1097680744@minbar.fac.cs.cmu.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Oct 2004 17:34:07 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: >On Wednesday, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth > wrote: >>But back to rfc2222bis: >> >>> There is no "official" standard KERBEROS_V5 mechanism. >> >> Then it seems strange to me to remove KERBEROS_V4 without further >> comment when there is no standard replacement > > Note that there is a distinct difference between SASL mechanisms and > the underlying authentication technology. The SASL KERBEROS_V4 > mechanism is obsolete because the underlying technology is obsolete. > It is worth noting that Kerberos V4 is not and never has been an IETF > standard. > > If you want to use Kerberos V5 with SASL, the mechanism you are > looking for is named 'GSSAPI'. It is described in > draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms > based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI" > refers specifically to GSS krb5). OK. Still, it might still be worth mentioning this the draft. I expect what you say is well known to someone who comes to SASL via Kerberos, but it would not be known to someone (like me) who comes to Kerberos via SASL. OTOH, if such a brief sentence could not be sufficiently helpful to a 'kerberos newbie' for there to be any point to it, forget it. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFJJXr092391; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DFJJ7I092390; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DFJIdn092383 for ; Wed, 13 Oct 2004 08:19:19 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06459; 13 Oct 2004 11:19 EDT Date: Wed, 13 Oct 2004 11:19:04 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <490070000.1097680744@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> 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, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth wrote: > But back to rfc2222bis: > >> There is no "official" standard KERBEROS_V5 mechanism. > > Then it seems strange to me to remove KERBEROS_V4 without further > comment when there is no standard replacement Note that there is a distinct difference between SASL mechanisms and the underlying authentication technology. The SASL KERBEROS_V4 mechanism is obsolete because the underlying technology is obsolete. It is worth noting that Kerberos V4 is not and never has been an IETF standard. If you want to use Kerberos V5 with SASL, the mechanism you are looking for is named 'GSSAPI'. It is described in draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI" refers specifically to GSS krb5). By contrast, the KERBEROS_V4 mechanism was defined _in the SASL base document_, which is why it is mentioned in the changelog. -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DF8RKo090282; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DF8Rjv090281; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DF8Qpo090263 for ; Wed, 13 Oct 2004 08:08:27 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHkk1-000266-DJ; Wed, 13 Oct 2004 17:08:38 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHkjy-0000ha-0a; Wed, 13 Oct 2004 17:08:34 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHkjx-0000Wt-00; Wed, 13 Oct 2004 17:08:33 +0200 From: Hallvard B Furuseth Message-Id: To: Jeffrey Hutzelman Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <452140000.1097677368@minbar.fac.cs.cmu.edu> References: <416BFDAA.3090507@isode.com> <452140000.1097677368@minbar.fac.cs.cmu.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Oct 2004 17:08:33 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: >On Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth > wrote: > >> (...internet-draft KERBEROS_V5...) >> >> When I'm >> walking through standards and definitions of something I'm working with, >> it's always annoying when there is suddenly no reference to where to go >> from there. > > It is not necessary, appropriate, or even possible for the SASL base > document to include an exhaustive list of SASL mechanisms. You have lost the context. I was talking about a reference - formal or informal - in the IANA registry, not rfc2222bis. But back to rfc2222bis: > There is no "official" standard KERBEROS_V5 mechanism. Then it seems strange to me to remove KERBEROS_V4 without further comment when there is no standard replacement - in particular since SASL was born around Kerberos and S/Key, according to the mailinglist archive. I suggest to add a purely informational sentence or two about why this was done and that an informal Kerberos5 exists. And if V4- support was removed because of a security flaw in that version, warn that one really shouldn't keep support for it. (Maybe the same applies to S/Key, but I know even less about that than about Kerberos.) -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEge2I086965; Wed, 13 Oct 2004 07:42:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEgeY7086964; Wed, 13 Oct 2004 07:42:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEgdc4086957 for ; Wed, 13 Oct 2004 07:42:39 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 39309767A4; Wed, 13 Oct 2004 10:42:39 -0400 (EDT) To: Jeffrey Hutzelman Cc: Hallvard B Furuseth , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> <445910000.1097676673@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 13 Oct 2004 10:42:38 -0400 In-Reply-To: <445910000.1097676673@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 13 Oct 2004 10:11:13 -0400") Message-ID: <871xg27k81.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman Jeffrey> wrote: >> I'm not really sure it's OK for a protocol to use no >> stringprep profile at all. >> >> Especially for an IETF protocol I'm not sure I can think of >> situations where the right technical solution would not involve >> stringprep of some kind. Jeffrey> What an application's SASL profile says about the form Jeffrey> and preparation of authorization names will always depend Jeffrey> on what the application protocol does in a broader sense. Jeffrey> For applications which use some sort of string for Jeffrey> identity and authorization, the SASL profile should Jeffrey> specify use of the same string, with the same behaviours Jeffrey> and semantics. That means if the application does not Jeffrey> use stringprep on authorization ID's used, say, in Jeffrey> manipulating ACL's, then it should not use it on SASL Jeffrey> authorization ID's either. Jeffrey> Also, I can think of a scenario in which the right Jeffrey> solution does not involve any form of stringprep. Jeffrey> Consider an application which does identity and access Jeffrey> control using UUID's rather than strings. I do not Jeffrey> believe there is anything in SASL that would prevent this Jeffrey> use. True. But what you can do is somewhat constrained by the IESG for standards-track documents. I believe that MAY use no stringprep is technically true but is also too strong of a statement. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEMcMa084326; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEMc2n084325; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEMbGc084318 for ; Wed, 13 Oct 2004 07:22:38 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06416; 13 Oct 2004 10:22 EDT Date: Wed, 13 Oct 2004 10:22:48 -0400 From: Jeffrey Hutzelman To: Hallvard B Furuseth , Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <452140000.1097677368@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@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 Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth wrote: > If there is a standard or "official document" or something for a > mechanism, RFC or not, my vote is to at least mention it. In the case of KERBEROS_V5, there is not. There may be an internet-draft, though I expect it has expired by now if Simon is not still actively working on the mechanism. Internet-drafts are by their nature ephemeral and therefore do not make stable references. Published RFC's may not contain references to internet-drafts. > When I'm > walking through standards and definitions of something I'm working with, > it's always annoying when there is suddenly no reference to where to go > from there. It is not necessary, appropriate, or even possible for the SASL base document to include an exhaustive list of SASL mechanisms. This is hardly the first "framework" document to include support for multiple mechanisms, and the normal practice is to make reference to specific mechanisms only when they are REQUIRED or RECOMMENDED, or when such a reference is needed to illustrate a concept described in the framework. It is worth noting that as with any "framework" defined by the IETF, there _is_ an exhaustive list of all mechanisms, which is maintained by the IANA. IANA registries generally include a pointer to a contact person and/or to a published specification, if there is one. There is no "official" standard KERBEROS_V5 mechanism. I refer you to the following paragraph, which appears as part of the boilerplate at the top of every internet-draft: 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''. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEHG8A083552; Wed, 13 Oct 2004 07:17:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEHGiu083551; Wed, 13 Oct 2004 07:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEHFUS083544 for ; Wed, 13 Oct 2004 07:17:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 15:17:27 +0100 Message-ID: <416D38F6.6070403@isode.com> Date: Wed, 13 Oct 2004 15:17:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: <416D0318.2080103@isode.com> <446620000.1097676867@minbar.fac.cs.cmu.edu> In-Reply-To: <446620000.1097676867@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov > wrote: > >> Hallvard B Furuseth wrote: >> >>> I think Appendix C (Changes since RFC 2222) includes an extract of >>> changes between various rfc2222/rfc2222bis versions, rather than just >>> changes since RFC 2222. >> >> That is correct. >> >> Question to the WG: should I clean up the Appendix C or should I wait >> till the document is approved for publication? > > This section is essentially a changelog. Yes. > Normally, such sections are intended for use during the development of > a document, and carry a note to the RFC-Editor asking that they be > removed prior to publication. I think that would be the apporpriate > thing to do in this case. I disagree. I find such section quite useful when one has to quickly find out about changes since an older RFC. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEEJul083204; Wed, 13 Oct 2004 07:14:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEEJbi083203; Wed, 13 Oct 2004 07:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEEH90083197 for ; Wed, 13 Oct 2004 07:14:18 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06409; 13 Oct 2004 10:14 EDT Date: Wed, 13 Oct 2004 10:14:27 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C Message-ID: <446620000.1097676867@minbar.fac.cs.cmu.edu> In-Reply-To: <416D0318.2080103@isode.com> References: <416D0318.2080103@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, October 13, 2004 11:27:36 +0100 Alexey Melnikov wrote: > > Hallvard B Furuseth wrote: > >> I think Appendix C (Changes since RFC 2222) includes an extract of >> changes between various rfc2222/rfc2222bis versions, rather than just >> changes since RFC 2222. >> > That is correct. > > Question to the WG: should I clean up the Appendix C or should I wait > till the document is approved for publication? This section is essentially a changelog. Normally, such sections are intended for use during the development of a document, and carry a note to the RFC-Editor asking that they be removed prior to publication. I think that would be the apporpriate thing to do in this case. -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEB43p082754; Wed, 13 Oct 2004 07:11:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEB4Iv082753; Wed, 13 Oct 2004 07:11:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DEB2S5082746 for ; Wed, 13 Oct 2004 07:11:03 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06405; 13 Oct 2004 10:11 EDT Date: Wed, 13 Oct 2004 10:11:13 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Hallvard B Furuseth cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <445910000.1097676673@minbar.fac.cs.cmu.edu> In-Reply-To: References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@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 Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman wrote: > > I'm not really sure it's OK for a protocol to use no stringprep > profile at all. > > Especially for an IETF protocol I'm not sure I can think of situations > where the right technical solution would not involve stringprep of > some kind. What an application's SASL profile says about the form and preparation of authorization names will always depend on what the application protocol does in a broader sense. For applications which use some sort of string for identity and authorization, the SASL profile should specify use of the same string, with the same behaviours and semantics. That means if the application does not use stringprep on authorization ID's used, say, in manipulating ACL's, then it should not use it on SASL authorization ID's either. Also, I can think of a scenario in which the right solution does not involve any form of stringprep. Consider an application which does identity and access control using UUID's rather than strings. I do not believe there is anything in SASL that would prevent this use. I agree that when applications use strings to identify users, they should use some form of stringprep. I agree that in many such cases, it would be appropriate to use SASLprep rather than constructing a separate stringprep profile for that application. However, mandating the use of stringprep in application protocols is out of scope for this working group, and I believe that it is more important that SASL authorization ID's have the same semantics as those used elsewhere in the application than that they have the same semantics as other strings used in SASL. -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DARPn4041920; Wed, 13 Oct 2004 03:27:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DARPwi041919; Wed, 13 Oct 2004 03:27:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DAROoP041901 for ; Wed, 13 Oct 2004 03:27:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 11:27:37 +0100 Message-ID: <416D0318.2080103@isode.com> Date: Wed, 13 Oct 2004 11:27:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis Appendix C References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >I think Appendix C (Changes since RFC 2222) includes an extract of >changes between various rfc2222/rfc2222bis versions, rather than just >changes since RFC 2222. > That is correct. Question to the WG: should I clean up the Appendix C or should I wait till the document is approved for publication? >[...] > >Another detail: > > The "SKEY" mechanism described in RFC 2222 is obsolete and has been > removed. It has been replaced by the OTP mechanism [SASL-OTP]. > >This is the only mention of [SASL-OTP] outside of the References >section. Is that intentional? > > [SASL-OTP] is mentioned in 10.2 (Informative references). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9uXab028557; Wed, 13 Oct 2004 02:56:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D9uXY6028556; Wed, 13 Oct 2004 02:56:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9uVxa028537 for ; Wed, 13 Oct 2004 02:56:32 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 13 Oct 2004 10:56:43 +0100 Message-ID: <416CFBDA.8000707@isode.com> Date: Wed, 13 Oct 2004 10:56:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000907060501040307020905" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------000907060501040307020905 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>>>6.1. Client sends data first >>>> >>>> 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.) >>>> >>>> >>>Then protocols that support an initial response must be clear on how to >>>distinguish an absent initial response from a present but empty initial >>>response. I expect their protocol profiles must also specify whether or >>>not the protocol _can_ distinguish the two, so the mechanism can tell >>>whether or not to send empty initial responses. >>> >>> >> This is described in Section 4, bullet # 2. >> >> > >No... First, it's only a SHOULD: > > If the protocol allows for the initial response, the protocol profile > SHOULD also describe how an empty initial response is encoded. > > I've already changed SHOULD to MUST. This issue was raised during WGLC. >Second, if that sentence is intended to address this issue, I can think >of two different things it can imply in order to do so. It is not at >all clear to me that it means either: > >1) "If the protocol profile does not say how an initial response is > encoded, then empty but present initial responses are not supported." > > >2) If you s/SHOULD/MUST/: "If initial responses are supported, then it > MUST be possible to send an empty initial response which can be > distinguished from no initial response." > > The intention was to say #2. I am not aware of any protocol profile that supports initial response, but doesn't allow for it being empty. >>>>7. The EXTERNAL mechanism >>>> >>>> The client sends a single message containing the UTF-8 encoding of >>>> the authorization identity. The message may be empty. >>>> >>>> >>>s/message/response/ the first time, >>>s/message/authorization identity/ the second time? >>> >>> >> I actually prefer to keep the informal term message here. >> >> > >Well, I'll see how empty initial responses turn out... > > >>>See my comments above about empty initial response. >>> >>> >>>>Appendix C. Changes since RFC 2222 >>>> >>>> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >>>> been removed. >>>> >>>> >>>I just noticed that >>>has no pointer to the definition of the KERBEROS_V5 mechanism. Its >>>registration only lists a person (Simon Josefsson). The same is true >>>for some other mechanisms. Why is that? >>> >>> >> There is no reference, because there is no RFC. I think one can ask IANA >> to add one. >> >> > >If there is a standard or "official document" or something for a >mechanism, RFC or not, my vote is to at least mention it. When I'm >walking through standards and definitions of something I'm working with, >it's always annoying when there is suddenly no reference to where to go >from there. As with Kerberos5, Googling around will often find >competing texts that may or may not be or reflect the "official" >standard. Or I can ask (if I knows where), but then I have to sit and >wait for someone to answer, and sometimes there is no telling how >reliable the respondent is. > > For KERBEROS_V5 registration you need to send a email to Simon, he is the authoritative source of information. It would be even better if you ask him to update the registration. Alexey --------------000907060501040307020905 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
6.1.  Client sends data first

   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.)
        
Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.
      
 This is described in Section 4, bullet # 2.
    

No...  First, it's only a SHOULD:

   If the protocol allows for the initial response, the protocol profile
   SHOULD also describe how an empty initial response is encoded.
I've already changed SHOULD to MUST. This issue was raised during WGLC.
Second, if that sentence is intended to address this issue, I can think
of two different things it can imply in order to do so.  It is not at
all clear to me that it means either:

1) "If the protocol profile does not say how an initial response is
   encoded, then empty but present initial responses are not supported."
  
2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
   MUST be possible to send an empty initial response which can be
   distinguished from no initial response."
The intention was to say #2. I am not aware of any protocol profile that supports initial response, but doesn't allow for it being empty.
7.    The EXTERNAL mechanism

   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
        
s/message/response/ the first time,
s/message/authorization identity/ the second time?
      
 I actually prefer to keep the informal term message here.
    

Well, I'll see how empty initial responses turn out...
  
See my comments above about empty initial response.
      
Appendix C. Changes since RFC 2222

   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.   
        
I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?
      
 There is no reference, because there is no RFC. I think one can ask IANA
 to add one.
    

If there is a standard or "official document" or something for a
mechanism, RFC or not, my vote is to at least mention it.  When I'm
walking through standards and definitions of something I'm working with,
it's always annoying when there is suddenly no reference to where to go
from there.  As with Kerberos5, Googling around will often find
competing texts that may or may not be or reflect the "official"
standard.  Or I can ask (if I knows where), but then I have to sit and
wait for someone to answer, and sometimes there is no telling how
reliable the respondent is.
For KERBEROS_V5 registration you need to send a email to Simon, he is the authoritative source of information. It would be even better if you ask him to update the registration.

Alexey

--------------000907060501040307020905-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D87qA5089691; Wed, 13 Oct 2004 01:07:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D87qGm089690; Wed, 13 Oct 2004 01:07:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D87o5n089652 for ; Wed, 13 Oct 2004 01:07:51 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CHeAy-00040L-KV for ietf-sasl@imc.org; Wed, 13 Oct 2004 10:08:01 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHeAf-0007ms-Rt; Wed, 13 Oct 2004 10:07:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHeAf-0007Kc-00; Wed, 13 Oct 2004 10:07:41 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis Appendix C Date: Wed, 13 Oct 2004 10:07:41 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Appendix C (Changes since RFC 2222) includes an extract of changes between various rfc2222/rfc2222bis versions, rather than just changes since RFC 2222. Examples: Replaced UTF-8 ABNF with the reference to the UTF-8 document. RFC 2222 did not refer to UTF-8 at all. OTOH, the new UTF-8 MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned. Replaced "buffers of security encoded data" with "buffers of protected data" for clarity. That first phrase does not occur in rfc2222. Made requirement to verify that an authorization identity is correct by performing SASLprep a SHOULD, instead of a MUST. rfc2222 does not contain a single MUST. And if that SHOULD is the one in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is correct, not that the ID itself is correct. Another detail: The "SKEY" mechanism described in RFC 2222 is obsolete and has been removed. It has been replaced by the OTP mechanism [SASL-OTP]. This is the only mention of [SASL-OTP] outside of the References section. Is that intentional? -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CMcui7084034; Tue, 12 Oct 2004 15:38:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CMcu5G084033; Tue, 12 Oct 2004 15:38:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CMcsC2084027 for ; Tue, 12 Oct 2004 15:38:55 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 748BDE0053; Tue, 12 Oct 2004 18:39:24 -0400 (EDT) To: Hallvard B Furuseth Cc: Alexey Melnikov , Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> From: Sam Hartman Date: Tue, 12 Oct 2004 18:39:24 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Tue, 12 Oct 2004 23:49:39 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not really sure it's OK for a protocol to use no stringprep profile at all. Especially for an IETF protocol I'm not sure I can think of situations where the right technical solution would not involve stringprep of some kind. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLnY0K080772; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CLnYqb080771; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLnXIN080763 for ; Tue, 12 Oct 2004 14:49:34 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CHUWc-0002Qv-N6; Tue, 12 Oct 2004 23:49:42 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHUWZ-0006sr-Th; Tue, 12 Oct 2004 23:49:39 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHUWZ-0005bk-00; Tue, 12 Oct 2004 23:49:39 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416C16C5.3090809@isode.com> References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> <416C16C5.3090809@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 12 Oct 2004 23:49:39 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Jeffrey Hutzelman wrote: >> wrote: >>>Hallvard B Furuseth wrote: >>> >>>>> 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. >>>> >>>> That uppercase "MAY" gives the impression that this is the only other >>>> option: It may not a more lax stringprep profile, or an entirely >>>> different way to prepare. >>>> >>> This MAY is just fine according to [KEYWORDS] (RFC 2119). >>> I am not sure how this can be improved. >>> >>> The reason for having the MAY is to emphasize that this is actually >>> considered a reasonable thing to do. >> >> Try this: >> >> Profiles MAY use a stringprep profile other than SASLprep, or none at >> all. > > I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep > + additional restrictions) is a common case. Profiles whose (...) SHOULD use SASLPrep or a stricter stringprep profile, but MAY use other stringprep profiles or none at all? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLdA4o080187; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CLdAIZ080186; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CLd9Lo080174 for ; Tue, 12 Oct 2004 14:39:10 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CHUMW-0006sq-Jv; Tue, 12 Oct 2004 23:39:16 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CHUMR-0007Qe-OK; Tue, 12 Oct 2004 23:39:11 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CHUMO-0005aB-00; Tue, 12 Oct 2004 23:39:08 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <416BFDAA.3090507@isode.com> References: <416BFDAA.3090507@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 12 Oct 2004 23:39:08 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>> 3. Authentication mechanisms >>> >>> sasl-mech = 1*20mech-char >>> mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE >>> ; mech-char is restricted to "A"-"Z", "0"-"9", "-", >>> ; and "_" from ASCII character set. >> >> In most standards, tokens like sasl-mech cannot start with a hyphen; >> often they must start with a letter. Prevents problems e.g. with >> programs that are overeager about extracting command line arguments, or >> utilities which notice token-like strings in general without an exact >> idea of what kind of token it is (e.g. click&cut&paste). Is there any >> reason sasl-mech is different? >> > I see your point, but at this time I would rather not change this. Just > in case somebody has designed and deployed a mechanism that starts with > "_" or "-". OK. >>> 5. Mechanism profile guidelines >>> >>> 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 MUST fail the authentication exchange. >> >> I expect preparation of an empty string should not fail, so: >> s/results in/turns a non-empty string into/. > > This text is talking about authentication identities and passwords. I am > not sure whether the empty string should be allowed. I can see nothing which forbids it, neither in rfc2222 nor 2222bis. I have certainly set empty passwords on Unix boxes (off the net); if there is a SASL library which allows empty passwords then I assume people have found use for them with SASL too. I expect an empty authentication IDs would be messier, unless the authorization ID which is derived from that ID is non-empty. >>> 6.1. Client sends data first >>> >>> 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.) >> >> Then protocols that support an initial response must be clear on how to >> distinguish an absent initial response from a present but empty initial >> response. I expect their protocol profiles must also specify whether or >> not the protocol _can_ distinguish the two, so the mechanism can tell >> whether or not to send empty initial responses. >> > This is described in Section 4, bullet # 2. No... First, it's only a SHOULD: If the protocol allows for the initial response, the protocol profile SHOULD also describe how an empty initial response is encoded. Second, if that sentence is intended to address this issue, I can think of two different things it can imply in order to do so. It is not at all clear to me that it means either: 1) "If the protocol profile does not say how an initial response is encoded, then empty but present initial responses are not supported." 2) If you s/SHOULD/MUST/: "If initial responses are supported, then it MUST be possible to send an empty initial response which can be distinguished from no initial response." >>> 7. The EXTERNAL mechanism >>> >>> The client sends a single message containing the UTF-8 encoding of >>> the authorization identity. The message may be empty. >> >> s/message/response/ the first time, >> s/message/authorization identity/ the second time? > > I actually prefer to keep the informal term message here. Well, I'll see how empty initial responses turn out... >> See my comments above about empty initial response. >>> Appendix C. Changes since RFC 2222 >>> >>> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >>> been removed. >> >> I just noticed that >> has no pointer to the definition of the KERBEROS_V5 mechanism. Its >> registration only lists a person (Simon Josefsson). The same is true >> for some other mechanisms. Why is that? > > There is no reference, because there is no RFC. I think one can ask IANA > to add one. If there is a standard or "official document" or something for a mechanism, RFC or not, my vote is to at least mention it. When I'm walking through standards and definitions of something I'm working with, it's always annoying when there is suddenly no reference to where to go from there. As with Kerberos5, Googling around will often find competing texts that may or may not be or reflect the "official" standard. Or I can ask (if I knows where), but then I have to sit and wait for someone to answer, and sometimes there is no telling how reliable the respondent is. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIHRAc062083; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CIHR0O062082; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIHQNt062076 for ; Tue, 12 Oct 2004 11:17:27 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D5034E0053; Tue, 12 Oct 2004 14:17:58 -0400 (EDT) To: Jeffrey Hutzelman Cc: Alexey Melnikov , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Tue, 12 Oct 2004 14:17:58 -0400 In-Reply-To: <107890000.1097601171@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 12 Oct 2004 13:12:51 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Jeffrey> Melnikov Jeffrey> wrote: >> Hallvard B Furuseth wrote: >>>> 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. >>>> >>>> >>> That uppercase "MAY" gives the impression that this is the >>> only other option: It may not a more lax stringprep profile, >>> or an entirely different way to prepare. >>> >> This MAY is just fine according to [KEYWORDS] (RFC 2119). I am >> not sure how this can be improved. >> >> The reason for having the MAY is to emphasize that this is >> actually considered a reasonable thing to do. Jeffrey> Try this: Jeffrey> Profiles MAY use a stringprep profile other than Jeffrey> SASLprep, or none at all. I prefer the text currently in the draft to your proposed text. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHdCq8058886; Tue, 12 Oct 2004 10:39:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CHdCZ4058885; Tue, 12 Oct 2004 10:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHdBNd058879 for ; Tue, 12 Oct 2004 10:39:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 18:39:18 +0100 Message-ID: <416C16C5.3090809@isode.com> Date: Tue, 12 Oct 2004 18:39:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jeffrey Hutzelman CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: <416BFDAA.3090507@isode.com> <107890000.1097601171@minbar.fac.cs.cmu.edu> In-Reply-To: <107890000.1097601171@minbar.fac.cs.cmu.edu> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: > On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov > wrote: > >> Hallvard B Furuseth wrote: >> >>>> 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. >>> >>> >>> That uppercase "MAY" gives the impression that this is the only other >>> option: It may not a more lax stringprep profile, or an entirely >>> different way to prepare. >>> >> This MAY is just fine according to [KEYWORDS] (RFC 2119). >> I am not sure how this can be improved. >> >> The reason for having the MAY is to emphasize that this is actually >> considered a reasonable thing to do. > > Try this: > > Profiles MAY use a stringprep profile other than SASLprep, or none at > all. I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep + additional restrictions) is a common case. >>>> 6.2. Server returns success with 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. >>> >>> I don't quite understand. I would have thought that if an attacker can >>> do that, he can also wait for the final client response and then start >>> accessing the server, pretending to be the client. Maybe that just >>> shows my ignorance of the subject, but many other readers will be >>> equally ignorant. >>> >> What you are saying might be true, but I don't think it is relevant for >> the section you've quoted. By the time the server has sent a fake (or >> wrong) "additional data with success", it is too late: the client has >> already provided its credentials to the server. > > But the same is true even if you don't support "additional data with > success". By the time the server sends the last data, the client has > _still_ already sent its credentials to the server. In either case > the client cannot abort the exchange, because the MitM attacker simply > won't forward that part. I agree with you. The point of the paragraph is to say that with additional data with success the client is *not able* to abort SASL exchange, thus it has to disconnect. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHCqSH056492; Tue, 12 Oct 2004 10:12:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CHCqfX056491; Tue, 12 Oct 2004 10:12:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CHCoa9056480 for ; Tue, 12 Oct 2004 10:12:51 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa04450; 12 Oct 2004 13:12 EDT Date: Tue, 12 Oct 2004 13:12:51 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Hallvard B Furuseth cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments Message-ID: <107890000.1097601171@minbar.fac.cs.cmu.edu> In-Reply-To: <416BFDAA.3090507@isode.com> References: <416BFDAA.3090507@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 Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov wrote: > Hallvard B Furuseth wrote: > >>> 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. >>> >>> >> >> That uppercase "MAY" gives the impression that this is the only other >> option: It may not a more lax stringprep profile, or an entirely >> different way to prepare. >> > This MAY is just fine according to [KEYWORDS] (RFC 2119). > I am not sure how this can be improved. > > The reason for having the MAY is to emphasize that this is actually > considered a reasonable thing to do. Try this: Profiles MAY use a stringprep profile other than SASLprep, or none at all. >>> 6.2. Server returns success with 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. >>> >>> >> >> I don't quite understand. I would have thought that if an attacker can >> do that, he can also wait for the final client response and then start >> accessing the server, pretending to be the client. Maybe that just >> shows my ignorance of the subject, but many other readers will be >> equally ignorant. >> > What you are saying might be true, but I don't think it is relevant for > the section you've quoted. By the time the server has sent a fake (or > wrong) "additional data with success", it is too late: the client has > already provided its credentials to the server. But the same is true even if you don't support "additional data with success". By the time the server sends the last data, the client has _still_ already sent its credentials to the server. In either case the client cannot abort the exchange, because the MitM attacker simply won't forward that part. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFqAFn047576; Tue, 12 Oct 2004 08:52:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CFqADW047575; Tue, 12 Oct 2004 08:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFq8rk047566 for ; Tue, 12 Oct 2004 08:52:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 16:52:10 +0100 Message-ID: <416BFDAA.3090507@isode.com> Date: Tue, 12 Oct 2004 16:52:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040303010201000505010401" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------040303010201000505010401 Content-type: text/plain; charset="us-ascii" Hallvard B Furuseth wrote: >>3. Authentication mechanisms >> >> sasl-mech = 1*20mech-char >> mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE >> ; mech-char is restricted to "A"-"Z", "0"-"9", "-", >> ; and "_" from ASCII character set. >> >> > >In most standards, tokens like sasl-mech cannot start with a hyphen; >often they must start with a letter. Prevents problems e.g. with >programs that are overeager about extracting command line arguments, or >utilities which notice token-like strings in general without an exact >idea of what kind of token it is (e.g. click&cut&paste). Is there any >reason sasl-mech is different? > I see your point, but at this time I would rather not change this. Just in case somebody has designed and deployed a mechanism that starts with "_" or "-". >>4. Protocol profile requirements >> >> >> Note that an additional data with success can't be empty. >> > >I suggest > "Note that if additional data is sent with success, it can't be empty." >to clarify that one can send success without additional data. At least >that's what I assume it means. The sentence as quoted above confused >me: I could see no reason why one must always send additional data with >success:-) > Ok and fixed. >> 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. >> >> > >That uppercase "MAY" gives the impression that this is the only other >option: It may not a more lax stringprep profile, or an entirely >different way to prepare. > This MAY is just fine according to [KEYWORDS] (RFC 2119). I am not sure how this can be improved. The reason for having the MAY is to emphasize that this is actually considered a reasonable thing to do. >>5. Mechanism profile guidelines >> >> 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 MUST fail the authentication exchange. >> >> > >I expect preparation of an empty string should not fail, so: >s/results in/turns a non-empty string into/. > > This text is talking about authentication identities and passwords. I am not sure whether the empty string should be allowed. >>6.1. Client sends data first >> >> >> 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.) >> >> > >Then protocols that support an initial response must be clear on how to >distinguish an absent initial response from a present but empty initial >response. I expect their protocol profiles must also specify whether or >not the protocol _can_ distinguish the two, so the mechanism can tell >whether or not to send empty initial responses. > This is described in Section 4, bullet # 2. > >Protocol example: A line-oriented protocol similar to SMTP where the >client sends commands with space-separated arguments, and servers strip >trailing spaces from client command lines. > >Mechanism example: EXTERNAL with authorization ID = empty string. > > > >>6.2. Server returns success with 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. >> >> > >I don't quite understand. I would have thought that if an attacker can >do that, he can also wait for the final client response and then start >accessing the server, pretending to be the client. Maybe that just >shows my ignorance of the subject, but many other readers will be >equally ignorant. > What you are saying might be true, but I don't think it is relevant for the section you've quoted. By the time the server has sent a fake (or wrong) "additional data with success", it is too late: the client has already provided its credentials to the server. >>7. The EXTERNAL mechanism >> >> >> The client sends a single message containing the UTF-8 encoding of >> the authorization identity. The message may be empty. >> >> > >s/message/response/ the first time, >s/message/authorization identity/ the second time? > > I actually prefer to keep the informal term message here. >See my comments above about empty initial response. > > >>Appendix C. Changes since RFC 2222 >> >> >> The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has >> been removed. >> > >I just noticed that >has no pointer to the definition of the KERBEROS_V5 mechanism. Its >registration only lists a person (Simon Josefsson). The same is true >for some other mechanisms. Why is that? > There is no reference, because there is no RFC. I think one can ask IANA to add one. Alexey --------------040303010201000505010401 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Hallvard B Furuseth wrote:
3.    Authentication mechanisms    
   sasl-mech    = 1*20mech-char
   mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
                  ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
                  ; and "_" from ASCII character set.
    

In most standards, tokens like sasl-mech cannot start with a hyphen;
often they must start with a letter.  Prevents problems e.g. with
programs that are overeager about extracting command line arguments, or
utilities which notice token-like strings in general without an exact
idea of what kind of token it is (e.g. click&cut&paste).  Is there any
reason sasl-mech is different?
I see your point, but at this time I would rather not change this. Just in case somebody has designed and deployed a mechanism that starts with "_" or "-". 
4.    Protocol profile requirements
    
   Note that an additional data with success can't be empty. 

I suggest
  "Note that if additional data is sent with success, it can't be empty."
to clarify that one can send success without additional data.  At least
that's what I assume it means.  The sentence as quoted above confused
me: I could see no reason why one must always send additional data with
success:-)
Ok and fixed. 
   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.
    

That uppercase "MAY" gives the impression that this is the only other
option:  It may not a more lax stringprep profile, or an entirely
different way to prepare.
This MAY is just fine according to [KEYWORDS] (RFC 2119).
I am not sure how this can be improved.

The reason for having the MAY is to emphasize that this is actually considered a reasonable thing to do.
5.    Mechanism profile guidelines    
   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 MUST fail the authentication exchange.
    

I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
This text is talking about authentication identities and passwords. I am not sure whether the empty string should be allowed. 
6.1.  Client sends data first
    
   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.)
    

Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.
This is described in Section 4, bullet # 2.

Protocol example: A line-oriented protocol similar to SMTP where the
client sends commands with space-separated arguments, and servers strip
trailing spaces from client command lines.

Mechanism example: EXTERNAL with authorization ID = empty string.

  
6.2.  Server returns success with 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.
    

I don't quite understand.  I would have thought that if an attacker can
do that, he can also wait for the final client response and then start
accessing the server, pretending to be the client.  Maybe that just
shows my ignorance of the subject, but many other readers will be
equally ignorant.
What you are saying might be true, but I don't think it is relevant for the section you've quoted. By the time the server has sent a fake (or wrong) "additional data with success", it is too late: the client has already provided its credentials to the server. 
7.    The EXTERNAL mechanism
    
   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
    

s/message/response/ the first time,
s/message/authorization identity/ the second time?
I actually prefer to keep the informal term message here.
See my comments above about empty initial response.
  
Appendix C. Changes since RFC 2222
    
   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.    

I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?
There is no reference, because there is no RFC. I think one can ask IANA to add one.

Alexey

--------------040303010201000505010401-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CDUnPA033640; Tue, 12 Oct 2004 06:30:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CDUnPv033639; Tue, 12 Oct 2004 06:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CDUlAJ033632 for ; Tue, 12 Oct 2004 06:30:48 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Oct 2004 14:30:52 +0100 Message-ID: <416BDC8C.8060906@isode.com> Date: Tue, 12 Oct 2004 14:30:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Making forward progress References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: >I've seen no objections to Kurt's new summary of the identities issue >nor to his proposed text for section 3. I think we should move >forward with that change. > > Sounds good. >Alexey, how much help do you need dealing with implications of this >change for the rest of the document? > > I will need somebody's help to review my changes once I am done. >Also, are there any of Hallvard's comments that you have questions >about or that you believe require more WG discussion? > > I haven't looked very attentively, but at this time I think most issues/questions are straightforward. Let me cautiously promise to have another revision by October 25. Cautiously, because I need to submit 3 more documents in other WGs by the same date. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AMg31s006769; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9AMg3FA006768; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-FORTY-THREE.MIT.EDU [18.187.6.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AMg30J006761 for ; Sun, 10 Oct 2004 15:42:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 94B1F168025; Sun, 10 Oct 2004 18:42:10 -0400 (EDT) To: ietf-sasl@imc.org Subject: Making forward progress From: Sam Hartman Date: Sun, 10 Oct 2004 18:42:10 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've seen no objections to Kurt's new summary of the identities issue nor to his proposed text for section 3. I think we should move forward with that change. Alexey, how much help do you need dealing with implications of this change for the rest of the document? Also, are there ny of Hallvard's comments that you have questions about or that you believe require more WG discussion? --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EXBkb019243; Tue, 5 Oct 2004 07:33:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95EXBff019242; Tue, 5 Oct 2004 07:33:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EXAd9019229 for ; Tue, 5 Oct 2004 07:33:10 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CEqNI-00028W-HZ; Tue, 05 Oct 2004 16:33:08 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CEqNE-0000wR-5a; Tue, 05 Oct 2004 16:33:04 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CEqNC-0002Ps-00; Tue, 5 Oct 2004 16:33:02 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> References: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 5 Oct 2004 16:33:02 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >>> Abstract >> >>> The Simple Authentication and Security Layer (SASL) is a framework >>> for providing authentication and data security services in >>> connection-oriented protocols via replaceable >> >>authentication > > The sentence might be more clear if worded: > The Simple Authentication and Security Layer (SASL) is > a framework for providing authentication and data security > services via replaceable mechanisms to connection-oriented > protocols. I don't think so; it looks a little strange to have the 'to...' after the 'via...'. Maybe s/in/to/ would improve the original sentence. I've asked a coworker what he thought the Abstract meant: He got it more or less right, but was somewhat vague about it and thought it was a bit hard to get. He did not think my suggested extra words would make a difference. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Cxeax010837; Tue, 5 Oct 2004 05:59:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95CxeWk010836; Tue, 5 Oct 2004 05:59:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95CxcQv010827 for ; Tue, 5 Oct 2004 05:59:39 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CEoum-0000Z2-SN for ietf-sasl@imc.org; Tue, 05 Oct 2004 14:59:37 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CEoue-0007l9-Ej; Tue, 05 Oct 2004 14:59:28 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CEoud-0002CQ-00; Tue, 5 Oct 2004 14:59:27 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: rfc2222bis-08 comments In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 5 Oct 2004 14:59:27 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Fixes to my previous comments, and comments to the rest of the draft. I wrote: > Subject: rfc2222bis-08 comments >> 3.2. Authorization and authentication identities >> 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. > (...) > Please clarify that the authorization ID is checked during the > authentication (as section 3.2.1 says). And local policy is used to > either derive the authorization identity or check it. Sorry, s/check(ed)/authorize(d)/ is probably better. >> Any normalization of the authentication identity is defined by a >> particular SASL mechanism, the protocol profile doesn't influence it. > > That's a bit misleading from the protocol's point of view. From > discussions elsewhere I gather the protocol may normalize the ID as it > pleases for its own use, including when it locates the server-side > secret matching the authentication ID, as long as this does not affect > the ID which the authentication mechanism sees. Or rather, the protocol or its implementation may do that. >> 3.3. Security layers >> Note that all SASL mechanisms that are unable to negotiate a security >> layer automatically select no security layer. > > Without checking up the 'selects no security layer' thread, I still > can't tell if this says that such a mechanism cancels an old security > layer or if it says that it doesn't affect it. I'll check that later, > unless someone replies first. ...and Section 6.3 clarified it, now that I have gotten that far. ================================================================ > 3. Authentication mechanisms > sasl-mech = 1*20mech-char > mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE > ; mech-char is restricted to "A"-"Z", "0"-"9", "-", > ; and "_" from ASCII character set. In most standards, tokens like sasl-mech cannot start with a hyphen; often they must start with a letter. Prevents problems e.g. with programs that are overeager about extracting command line arguments, or utilities which notice token-like strings in general without an exact idea of what kind of token it is (e.g. click&cut&paste). Is there any reason sasl-mech is different? > 4. Protocol profile requirements > Note that an additional data with success can't be empty. I suggest "Note that if additional data is sent with success, it can't be empty." to clarify that one can send success without additional data. At least that's what I assume it means. The sentence as quoted above confused me: I could see no reason why one must always send additional data with success:-) > 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. That uppercase "MAY" gives the impression that this is the only other option: It may not a more lax stringprep profile, or an entirely different way to prepare. > 5. Mechanism profile guidelines > 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 MUST fail the authentication exchange. I expect preparation of an empty string should not fail, so: s/results in/turns a non-empty string into/. > 6.1. Client sends data first > 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.) Then protocols that support an initial response must be clear on how to distinguish an absent initial response from a present but empty initial response. I expect their protocol profiles must also specify whether or not the protocol _can_ distinguish the two, so the mechanism can tell whether or not to send empty initial responses. Protocol example: A line-oriented protocol similar to SMTP where the client sends commands with space-separated arguments, and servers strip trailing spaces from client command lines. Mechanism example: EXTERNAL with authorization ID = empty string. > 6.2. Server returns success with 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. I don't quite understand. I would have thought that if an attacker can do that, he can also wait for the final client response and then start accessing the server, pretending to be the client. Maybe that just shows my ignorance of the subject, but many other readers will be equally ignorant. > 7. The EXTERNAL mechanism > The client sends a single message containing the UTF-8 encoding of > the authorization identity. The message may be empty. s/message/response/ the first time, s/message/authorization identity/ the second time? See my comments above about empty initial response. > Appendix C. Changes since RFC 2222 > The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has > been removed. I just noticed that has no pointer to the definition of the KERBEROS_V5 mechanism. Its registration only lists a person (Simon Josefsson). The same is true for some other mechanisms. Why is that? -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JRwgL050442; Sat, 2 Oct 2004 12:27:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92JRwZV050441; Sat, 2 Oct 2004 12:27:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JRuIC050432 for ; Sat, 2 Oct 2004 12:27:56 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i92JRoZv073801; Sat, 2 Oct 2004 19:27:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041002121256.0419c878@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 02 Oct 2004 12:27:46 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: Simon Josefsson , ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@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:52 AM 10/2/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> be verified. The precise form of the authorization identity > Kurt> is, excepting the Unicode restriction, is a application > Kurt> protocol detail. > > >This isn't quite right. By "form" above, I am referring to the shape of the Unicode string and not the encoding of that Unicode string. The shape (Kerberos principal, LDAP DN, LDAP authzid, email address, etc.) of the string is an application protocol matter, its encoding (UTF-8, UTF-32, other) is a mechanism matter. >The form of the requested authorization >identity--the bits that are transferred over the wire--is a mechanism >detail. The protocol profile feeds in unicode codepoints and the >mechanism decides how those codepoints will appear on the wire. The >semantics of these codepoints is what is a protocol detail. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92IwtOq048630; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92IwtD4048627; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iwssm048615; Sat, 2 Oct 2004 11:58:54 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id C22AAE004F; Sat, 2 Oct 2004 14:58:59 -0400 (EDT) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org Subject: Re: CRAMing for last call References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> From: Sam Hartman Date: Sat, 02 Oct 2004 14:58:59 -0400 In-Reply-To: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> (Lyndon Nerenberg's message of "Fri, 01 Oct 2004 22:02:54 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> Finally, we need to address the issue of the MD5 "break." Lyndon> I have held off from commenting on this issue until the Lyndon> community has seen explicit evidence of the attack, and Lyndon> the implications of it. At this point, I don't know if the Lyndon> document deserves a writeup on the attack. Theory abounds, Lyndon> but I haven't yet seen a practical attack that works in Lyndon> the general case. We should at the least make mention of Lyndon> what has been discussed, and point to the literature, but Lyndon> I don't think the document deserves to discuss all the Lyndon> possible attacks. This doesn't mean to discourage anyone Lyndon> from contributing text to the Security Considerations Lyndon> section (please do). The security area seems to believe that hmac-md5 is still OK, at least for now. Especially since cram-md5 does not require much structure for the challenge, we should discuss the issue in the security considerations section. Will you need agenda time at the next meeting? If so, can you give an estimate of how much and what we want to cover? Thanks, --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iquk2048414; Sat, 2 Oct 2004 11:52:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92IquqC048413; Sat, 2 Oct 2004 11:52:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iqqgx048406 for ; Sat, 2 Oct 2004 11:52:53 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id CFC98160099; Sat, 2 Oct 2004 14:52:59 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> From: Sam Hartman Date: Sat, 02 Oct 2004 14:52:58 -0400 In-Reply-To: <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 01 Oct 2004 16:12:05 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> be verified. The precise form of the authorization identity Kurt> is, excepting the Unicode restriction, is a application Kurt> protocol detail. This isn't quite right. The form of the requested authorization identity--the bits that are transferred over the wire--is a mechanism detail. The protocol profile feeds in unicode codepoints and the mechanism decides how those codepoints will appear on the wire. The semantics of these codepoints is what is a protocol detail. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252w7G083996; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9252wSA083994; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252vOB083966; Fri, 1 Oct 2004 22:02:57 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d216-232-212-223.bchsia.telus.net (d216-232-212-223.bchsia.telus.net [216.232.212.223]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9252sWc034166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 23:02:56 -0600 (MDT) Date: Fri, 01 Oct 2004 22:02:54 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org Subject: CRAMing for last call Message-ID: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Now that 2222bis is close to reality, I would like to push the final version of CRAM out as well. The two documents should be able to go through together, (I hope) making life easier for the RFC editor. I have some non-substantive editorial changes that will make the document a bit easier to read, but these are not show stoppers. I think all of the last round of comments are addressed in the current draft. If not, I would like to hear from people, soon. I would also like to solicit a few additional examples from anyone who has implemented CRAM in other than IMAP. Finally, we need to address the issue of the MD5 "break." I have held off from commenting on this issue until the community has seen explicit evidence of the attack, and the implications of it. At this point, I don't know if the document deserves a writeup on the attack. Theory abounds, but I haven't yet seen a practical attack that works in the general case. We should at the least make mention of what has been discussed, and point to the literature, but I don't think the document deserves to discuss all the possible attacks. This doesn't mean to discourage anyone from contributing text to the Security Considerations section (please do). The IMAP-EXT list has had recent discussion that points out the ambiguity of searching for the space (SP) separator (between the user id and the digest) as being the rightmost SP, so I will strengthen that text. Any other comments should come forth soon as I would like to run out the final draft at the end of next week (Oct. 8) if I can. Cheers, --lyndon (editor) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i921nTvA072491; Fri, 1 Oct 2004 18:49:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i921nTmx072490; Fri, 1 Oct 2004 18:49:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from Gate2-sandiego.nmci.navy.mil (gate2-sandiego.nmci.navy.mil [138.163.0.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i921nPkH072479 for ; Fri, 1 Oct 2004 18:49:25 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: from nawesdnims04.nmci.navy.mil by Gate2-sandiego.nmci.navy.mil via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Sat, 2 Oct 2004 01:49:32 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: from mail pickup service by NAWESDNIEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC; Fri, 1 Oct 2004 18:47:51 -0700 Received: from nawesdnifw06.nmci.navy.mil ([10.0.0.38]) by NAWESDNIEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Oct 2004 15:53:09 -0700 Received: from Nawesdnims01.nmci.navy.mil by nawesdnifw06.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.0.10.60]) with ESMTP; Fri, 1 Oct 2004 22:53:09 +0000 Received: from nawesdnifw03c.nmci.navy.mil (nawesdnifw03c.nmci.navy.mil [10.0.0.163]) by nawesdnims01.nadsuswe.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id i91MmgJ09107 for ; Fri, 1 Oct 2004 22:48:42 GMT Received: from above.proper.com ([208.184.76.39]) by nawesdnifw03c.nmci.navy.mil via smtpd (for [10.0.0.166]) with ESMTP; Fri, 1 Oct 2004 22:53:08 +0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McWYt061399; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91McWIo061398; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McT4j061390 for ; Fri, 1 Oct 2004 15:38:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 434F9E004F; Fri, 1 Oct 2004 18:38:33 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> From: Sam Hartman Date: Fri, 01 Oct 2004 18:38:33 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 01 Oct 2004 23:05:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Archive: List-ID: List-Unsubscribe: X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-OriginalArrivalTime: 01 Oct 2004 22:53:09.0356 (UTC) FILETIME=[6C038AC0:01C4A809] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> "Kurt D. Zeilenga" writes: >> While SASL mechanisms specify the form of credentials used to >> authenticating users and SASL application profiles specify the >> form of authorization identities transferred as part of >> authentication exchange, the precise form(s) of the >> authentication identities (used within the server in its >> verifications, or otherwise) and the precise form(s) of the >> authorization identities (used in making authorization >> decisions, or otherwise) is beyond the scope of the SASL and >> this specification. Simon> I'm worried by how this new text interact with string Simon> normalization like SASLPrep. To me, it sounds as if the Simon> above leave the precise form of Simon> authentication/authorization identities up to either, or Simon> both, of application profiles and mechanisms. Is that a Simon> correct interpretation? The consensus of this working group is that the mechanism must transport the requested authorization identity so that all unicode code points are preserved. I.E. the mechanism can use any bijective transformation it desires; transforms like utf8-encode are assumed to be bijective on the set of unicode code points. Trying to be a bit more clear, mechanisms choose the encoding, but must preserve the unicode code points given to them by the protocol. The authentication identity is completely a matter for the mechanism; it may (and often should) normalize it. The normalization and interpretation of the requested authorization identity is a protocol matter. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NPsu0065555; Fri, 1 Oct 2004 16:25:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91NPsAb065554; Fri, 1 Oct 2004 16:25:54 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NPrBa065548 for ; Fri, 1 Oct 2004 16:25:53 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDWmk-0006iS-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 01:25:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Sat, 02 Oct 2004 01:25:32 +0200 Lines: 13 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> <6.1.2.0.0.20041001155050.0417fbc0@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/v3LJ3jCN8CLzghBvWRYkQ2Kb+0= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > Simon, > > Note that the text I offer is not a direct replacement for > Section 3.2. Additional work, including moving key > imperatives from the existing 3.2 to other sections, would > have to be undertaken. OK, I must have misread your initial post then. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NCDIK063905; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91NCD8q063904; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91NCDNS063896 for ; Fri, 1 Oct 2004 16:12:13 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91NC7Zv068806; Fri, 1 Oct 2004 23:12:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001155050.0417fbc0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 16:12:05 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Identity terminology in 2222bis Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20041001110956.0451db58@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: Simon, Note that the text I offer is not a direct replacement for Section 3.2. Additional work, including moving key imperatives from the existing 3.2 to other sections, would have to be undertaken. At 02:05 PM 10/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> While SASL mechanisms specify the form of credentials >> used to authenticating users and SASL application >> profiles specify the form of authorization identities >> transferred as part of authentication exchange, the >> precise form(s) of the authentication identities (used >> within the server in its verifications, or otherwise) >> and the precise form(s) of the authorization identities >> (used in making authorization decisions, or otherwise) is >> beyond the scope of the SASL and this specification. This may need some slight rewording. The intent is for the mechanism specification to detail how to verify the credentials and for the application protocol profile to specify the precise form of the authorization identity (within the Unicode restrict) but to make it clear that there are many uses of these identities which SASL simply doesn't not control. >I'm worried by how this new text interact with string normalization >like SASLPrep. I presume the existing recommendations here will remain. >To me, it sounds as if the above leave the precise >form of authentication/authorization identities up to either, or both, >of application profiles and mechanisms. The precise form of the credentials is a mechanism detail. The mechanism generally details how the credentials are to be verified. The precise form of the authorization identity is, excepting the Unicode restriction, is a application protocol detail. Other uses of identities are outside the scope of SASL. >For comparison, here is part of the old text: > > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. Though I think this needs to be slightly reworded, I agree with the intent of the statement to say that protocol profiles should leave of aspects of credentials and their verification to the mechanism. However, this in no way implies that an application protocol specification, or its implementations, cannot detail the form of authentication identity the application protocol (or implementation) might use otherwise. For instance, an application protocol specification could detail how to represent authentication identities in an identity assumption authorization policy. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). > >Read in contrast to each other, this seem like a major design change. > >Instead, I propose to clarify the terminology. I think you propose a major design change. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91MwtoH062300; Fri, 1 Oct 2004 15:58:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91MwtBo062299; Fri, 1 Oct 2004 15:58:55 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Mws7d062293 for ; Fri, 1 Oct 2004 15:58:54 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDWMd-000605-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 00:58:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Sat, 02 Oct 2004 00:58:33 +0200 Lines: 27 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:TTdNN5xkyEqxgQU8B6PSnsAdaIk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > The consensus of this working group is that the mechanism must > transport the requested authorization identity so that all unicode > code points are preserved. Then I propose to keep the following in section 3.2: The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Otherwise, I cannot find any normative text reflecting the consensus. > The authentication identity is completely a matter for the mechanism; > it may (and often should) normalize it. Then I propose to keep the following in section 3.2: Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. Kurt D. Zeilenga proposed to remove both paragraphs, if I understood him correctly. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McWYt061399; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91McWIo061398; Fri, 1 Oct 2004 15:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91McT4j061390 for ; Fri, 1 Oct 2004 15:38:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 434F9E004F; Fri, 1 Oct 2004 18:38:33 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Identity terminology in 2222bis References: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> From: Sam Hartman Date: Fri, 01 Oct 2004 18:38:33 -0400 In-Reply-To: (Simon Josefsson's message of "Fri, 01 Oct 2004 23:05:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: >> While SASL mechanisms specify the form of credentials used to >> authenticating users and SASL application profiles specify the >> form of authorization identities transferred as part of >> authentication exchange, the precise form(s) of the >> authentication identities (used within the server in its >> verifications, or otherwise) and the precise form(s) of the >> authorization identities (used in making authorization >> decisions, or otherwise) is beyond the scope of the SASL and >> this specification. Simon> I'm worried by how this new text interact with string Simon> normalization like SASLPrep. To me, it sounds as if the Simon> above leave the precise form of Simon> authentication/authorization identities up to either, or Simon> both, of application profiles and mechanisms. Is that a Simon> correct interpretation? The consensus of this working group is that the mechanism must transport the requested authorization identity so that all unicode code points are preserved. I.E. the mechanism can use any bijective transformation it desires; transforms like utf8-encode are assumed to be bijective on the set of unicode code points. Trying to be a bit more clear, mechanisms choose the encoding, but must preserve the unicode code points given to them by the protocol. The authentication identity is completely a matter for the mechanism; it may (and often should) normalize it. The normalization and interpretation of the requested authorization identity is a protocol matter. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91L63tA057281; Fri, 1 Oct 2004 14:06:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91L63cL057280; Fri, 1 Oct 2004 14:06:03 -0700 (PDT) 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.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91L61JI057271 for ; Fri, 1 Oct 2004 14:06:01 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDUbF-000316-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Oct 2004 23:05:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Identity terminology in 2222bis Date: Fri, 01 Oct 2004 23:05:31 +0200 Lines: 46 Message-ID: References: <6.1.2.0.0.20041001110956.0451db58@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: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:pqbbMshAe7vTm5P+HVrgAxdOyMk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > While SASL mechanisms specify the form of credentials > used to authenticating users and SASL application > profiles specify the form of authorization identities > transferred as part of authentication exchange, the > precise form(s) of the authentication identities (used > within the server in its verifications, or otherwise) > and the precise form(s) of the authorization identities > (used in making authorization decisions, or otherwise) is > beyond the scope of the SASL and this specification. I'm worried by how this new text interact with string normalization like SASLPrep. To me, it sounds as if the above leave the precise form of authentication/authorization identities up to either, or both, of application profiles and mechanisms. Is that a correct interpretation? If so, the new text would appear to permit, e.g., mechanisms to perform SASLPrep on the authorization identity. And to permit application profiles to apply perform SASLPrep on the authentication identity. Here, SASLPrep could even be some other function, like Unicode NFKC, or SASLPrep2, or some proprietary normalization procedure. For comparison, here is part of the old text: Any normalization of the authentication identity is defined by a particular SASL mechanism, the protocol profile doesn't influence it. The mechanism MUST preserve Unicode codepoint when transferring authorization identity (e.g. the mechanism cann't apply any form of normalization). Read in contrast to each other, this seem like a major design change. Instead, I propose to clarify the terminology. Further, the requirements on application profile and mechanisms should be specified, and not left "beyond the scope of 2222bis". One concrete approach is to require that, for IETF application profiles and mechanisms, both authentication and authorization identities MUST be SASLPrep strings, and that the SASL library, the application profile, and the mechanism may all perform SASLPrep on the identities. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91INkBq048111; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91INk6n048110; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91INkHI048104 for ; Fri, 1 Oct 2004 11:23:46 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91INnZv067292; Fri, 1 Oct 2004 18:23:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001102809.04165318@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 11:23:07 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis-08 comments Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a few (initial) comments to inject here and there. At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >> Abstract > >> The Simple Authentication and Security Layer (SASL) is a framework >> for providing authentication and data security services in >> connection-oriented protocols via replaceable > >authentication The sentence might be more clear if worded: The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services via replaceable mechanisms to connection-oriented protocols. >[nothing in the abstract says that's the kind of mechanisms it is >talking about.] Mechanisms provide authentication and data security services to connection-oriented protocols through the SASL framework. >> mechanisms. It >> provides structured interface between protocols and > >such SASL > >> mechanisms. I think its clear that both "protocols" and "mechanisms" refer to those protocols and mechanisms which are utilizing the SASL framework. I don't think either needs to be qualified here. It would seem odd to qualify one and not the other. And as this is the Abstract, we should avoid being too wordy. >Or maybe "...and mechanisms that adhere to SASL", but that's probably >more wordy than necessary. First, you'd have to say s/SASL/SASL technical specification/. But, yes, too wordy. >The same change would be nice in the Introduction section, though of >course the diagram there helps. > >Personally I would also have found an asymmetric definition easier to >relate to: SASL defines a common interface to authentication mechanisms >for protocols. (Is that the right way to put it?) But maybe that's not >at all the view SASL intends to convey. Is the protocol profile the >common interface to protocols for authentication mechanisms? The "protocol profile" is the part of the protocol's technical specification which details how it makes use of the SASL framework. >> 2. Introduction > >> The implementors will also need to understand a >> specification of a > >SASL > >> profile specific to the protocol, > >> 3.1. Authentication protocol exchange > >This phrase looks to me like it is about an authentication protocol - >i.e. part of SASL - and not the protocol which uses SASL. >I don't see anything in the following section to correct that notion. I think the word "protocol' here should be dropped here and elsewhere where we're referring to the mechanism exchange. >Also, > >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. > >I don't think so. It's the protocol which conducts the _exchange_, >and (below) which transmits anything. > >> During the authentication protocol exchange, the mechanism performs > >I suggest s/performs/can perform/, since not all of them need be done. > >> authentication, transmits an authorization identity (frequently known >> as a userid) from the client to server, > >This sounds like the authorization identity is independent of the >authentication. See below. > >> 3.2. Authorization and authentication identities There was some discussion in this area during WGLC. That discussion was recently re-opened. I suggest you read my latest post in this area as well as the WGLC thread. >> 3.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. > >But a NUL octet in a multibyte character is OK? This sentence refers only to specific character, not octets belonging to an encoding of other characters. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91ILDdj048000; Fri, 1 Oct 2004 11:21:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91ILDmV047999; Fri, 1 Oct 2004 11:21:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91ILCCJ047988 for ; Fri, 1 Oct 2004 11:21:12 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91ILFZv067280 for ; Fri, 1 Oct 2004 18:21:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001110956.0451db58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 11:21:13 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Identity terminology in 2222bis 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: Historically, there was a bit of hand waving in regards to identities. In trying to nail down what identities are involved in the SASL framework, where each identity comes from and what are they used for, we ended up with 3 identities: - the "authentication identity" to refer to the identity associated with the users credentials, - the "requested identity" to refer to identity which the user requests to act as, and - "authorization identity" to refer to identity used by the server in making authorization decisions. (The latter being derived from by former two.) However, we now face is that what we've historically called an authorization identity is not the precise identity used in making authorization decisions. The amount of 2222bis editing to implement the WGLC conclusion is actually minor in comparison to the impact upon other documents, including most mechanism specifications and application profiles. If it was only 2222bis, I'd be inclined to just bit the bullet and make the terminology changes. But given the broader impact this terminology change would have, we need to consider other approaches to resolving our terminology woes. In particular, I think this can be done by separating how identities are used conceptually from how they are used in practice and, in particular, their form. Below is a 3.2 rewrite which, I think, demonstrates how we can avoid the terminology problem. I do think other portions need work as well, but this should give you reasonable idea of the approach I suggest we take. Comments? -- Kurt (as an individual contributor) 3.2 Identity Concepts Conceptually, SASL framework involves two identities: 1) an identity associated with the authentication credentials (termed the authentication identity), and 2) an identity to act as (termed the authorization identity). The client provides its credentials and, optionally, a string representing the requested authorization identity as part of the SASL exchange. When this string is not provided, the client is requesting to act as the identity associated with the credentials (e.g., the user is requesting to act as the authentication identity). The server is responsible for verifying the user's credentials and verifying that the user is able to act as the authorization identity. A SASL exchange is successful if and only if both of these verifications are successful. While SASL mechanisms specify the form of credentials used to authenticating users and SASL application profiles specify the form of authorization identities transferred as part of authentication exchange, the precise form(s) of the authentication identities (used within the server in its verifications, or otherwise) and the precise form(s) of the authorization identities (used in making authorization decisions, or otherwise) is beyond the scope of the SASL and this specification. In some circumstances, the precise identity forms used outside of the SASL exchange may be dictated by other specifications. For instance, the authorization policy specification for an application protocol may dictate the precise form that an authorization identity is to be represented in the authorization policy. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I9RiC047225; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91I9RpB047224; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I9ROw047216 for ; Fri, 1 Oct 2004 11:09:27 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91I9SZv067220 for ; Fri, 1 Oct 2004 18:09:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001085527.044c67c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 09:14:18 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Reconsideration Identity And Authorization Issue (Was: Summary of 2222bis WGLC) In-Reply-To: <6.1.2.0.0.20040924123829.0433b4c8@127.0.0.1> References: <6.1.2.0.0.20040924123829.0433b4c8@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:40 PM 9/24/2004, Kurt D. Zeilenga wrote: >5) Identities and Authorization > >Kurt indicated that the I-D use of term "authorization >identity" is confusing and suggested use of different >terms for each distinct use of this term. Jeffery >suggested using the terms: > "authentication identity" to refer to the > identity associated with the users creditials, > "requested identity" to refer to identity > which the user requests to act as, and > "authorization identity" to refer to identity > used by the server in making authorization > decisions. (The latter being derived from > by former two.) > >The chairs conclude the WG supports use of this >suggested terminology. After some lengthy discussions between the Sam, Alexey, and I (with and without our respective chair/editor hats), the chairs have decided to vacate their conclusion regarding this issue and re-open discussion in this area. This post will be followed by a messaging summarizing problems with above terminology choice and offering a way to resolve the underlying terminology problem. Kurt, as SASL co-chair Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91EdLFb032699; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91EdL0I032698; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91EdLQr032689 for ; Fri, 1 Oct 2004 07:39:21 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i91EdLZv065770 for ; Fri, 1 Oct 2004 14:39:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041001072559.04412a90@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 07:39:20 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis-08 comments In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote: >These are rather rather hurried comments, since Kurt said reviews are >needed but soon. Thanks for responding to my late request for review! To the WG, Sam and I have some concerns regarding the depth and breadth of the WG review of this I-D. The chairs continue to actively seek additional review. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91DxtP9030106; Fri, 1 Oct 2004 06:59:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Dxtdt030105; Fri, 1 Oct 2004 06:59:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Dxr87030096 for ; Fri, 1 Oct 2004 06:59:54 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CDNwr-0003xT-9d for ietf-sasl@imc.org; Fri, 01 Oct 2004 15:59:49 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CDNwn-0005qc-Dt; Fri, 01 Oct 2004 15:59:45 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1CDNwm-0003D0-00; Fri, 1 Oct 2004 15:59:44 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis-08 comments Date: Fri, 1 Oct 2004 15:59:44 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These are rather rather hurried comments, since Kurt said reviews are needed but soon. So I have only made a cursory check if these issues have been discussed before; I don't know how much they would have been delayed if I were to check properly. Sorry about that. > Abstract I had trouble getting into SASL the first time I read the draft - mostly things that did not make sense to me at first, only when I got to a closer explanation later in the draft. I'm beginning to figure out why now, though I'm guessing a bit about what it was I didn't get. Starting with the Abstract: I didn't get that at all, though I don't really see why, given the second paragraph. "So I have a protocol here, and an authentication mechanism there, and somehow if I include SASL, the two will be able to talk to each other. Um...?" It's better now, but I still suggest: > The Simple Authentication and Security Layer (SASL) is a framework > for providing authentication and data security services in > connection-oriented protocols via replaceable authentication [nothing in the abstract says that's the kind of mechanisms it is talking about.] > mechanisms. It > provides structured interface between protocols and such SASL > mechanisms. Or maybe "...and mechanisms that adhere to SASL", but that's probably more wordy than necessary. The same change would be nice in the Introduction section, though of course the diagram there helps. Personally I would also have found an asymmetric definition easier to relate to: SASL defines a common interface to authentication mechanisms for protocols. (Is that the right way to put it?) But maybe that's not at all the view SASL intends to convey. Is the protocol profile the common interface to protocols for authentication mechanisms? > 2. Introduction > The implementors will also need to understand a > specification of a SASL > profile specific to the protocol, > 3.1. Authentication protocol exchange This phrase looks to me like it is about an authentication protocol - i.e. part of SASL - and not the protocol which uses SASL. I don't see anything in the following section to correct that notion. Also, > A SASL mechanism is responsible for conducting an authentication > protocol exchange. I don't think so. It's the protocol which conducts the _exchange_, and (below) which transmits anything. > During the authentication protocol exchange, the mechanism performs I suggest s/performs/can perform/, since not all of them need be done. > authentication, transmits an authorization identity (frequently known > as a userid) from the client to server, This sounds like the authorization identity is independent of the authentication. See below. > 3.2. Authorization and authentication identities > 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. As above. As described, the authorization ID appears not to be part of the 'results produced by the authentication mechanism', only something which is grabbed after completion of the authentication. When I first read about this, I was left wondering when the server checks if the authentication ID has the authorization ID's access. Each time one tries to access something after the authentication? Please clarify that the authorization ID is checked during the authentication (as section 3.2.1 says). And local policy is used to either derive the authorization identity or check it. But it looks a little strange to use that local policy during the exchange if the user provides it, but after the exchange if it is derived. Should both be done during the exchange instead? > 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. I wonder a little why the authorization ID is explicitly said to be provided by the client, when the authentication ID is not. > Any normalization of the authentication identity is defined by a > particular SASL mechanism, the protocol profile doesn't influence it. That's a bit misleading from the protocol's point of view. From discussions elsewhere I gather the protocol may normalize the ID as it pleases for its own use, including when it locates the server-side secret matching the authentication ID, as long as this does not affect the ID which the authentication mechanism sees. > The mechanism MUST preserve Unicode codepoint when transferring > authorization identity (e.g. the mechanism cann't apply any form of > normalization). The () part does not seem say the same as the preceding sentence: 'when transferring...' sounds like only the client-side part of the mechanism must preserve the ID, while the () sounds like the server side also must preserve it. > 3.2.1. Authorization identities and proxy authentication > The server SHOULD verify that a received authorization identity is in > the correct form. Protocol 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. In that case there can be authorization IDs which one can only get by sending an empty authorization ID: IDs that are derived from the authentication ID but would be invalid if specified explicitly. Seems strange. > 3.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. But a NUL octet in a multibyte character is OK? (Does not apply to UTF-8, of course.) > 3.3. Security layers > 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. The exact position MUST be defined by > the protocol profile (see section 4 part 5). When does it stop having effect, if the protocol supports multiple authentication? > Note that all SASL mechanisms that are unable to negotiate a security > layer automatically select no security layer. Without checking up the 'selects no security layer' thread, I still can't tell if this says that such a mechanism cancels an old security layer or if it says that it doesn't affect it. I'll check that later, unless someone replies first. -- Hallvard