From owner-ietf-sasl Tue Apr 1 02:34:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31AYxJM008519 for ; Tue, 1 Apr 2003 02:34:59 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31AYxQj008518 for ietf-sasl-bks; Tue, 1 Apr 2003 02:34:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31AYvJM008508 for ; Tue, 1 Apr 2003 02:34:57 -0800 (PST) Received: from solomon (a5-p20.syd.fl.net.au [202.181.2.20]) by delenn.fl.net.au (Postfix) with ESMTP id 5D9A8180570 for ; Tue, 1 Apr 2003 20:33:04 +1000 (EST) Content-Type: text/plain; charset="us-ascii" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: SASL Subject: authentication and authorization identities, and passwords in SASL Mechanisms Date: Tue, 1 Apr 2003 21:27:26 +1100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200304012027.29229.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31AYwJM008513 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hello there, can someone calrify the following: 1. why does a SASL Mechanism has to mandate SASLPrep as a needed transformation for authentication identities (usernames) and passwords, in preference to something like: MUST be in Unicode Normalization Form KC [UNICODE-KC] without NUL characters. wouldn't a transformation such as the SASLPrep be part of the SASL Profile itself rather than the Mechanism(s)? 2. what is the consensus on specifying/handling authorization identities for transportation on the wire? is [UNICODE-KC] enough? TIA + cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+iWmO+e1AKnsTRiERAwZNAJ4r/AOu++oWkA3ppSCnjmjWGYyXwwCg6zSh W1bU3OxBgrU8PFNyefvnlWw= =Yob+ -----END PGP SIGNATURE----- From owner-ietf-sasl Tue Apr 1 08:30:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUbJM007672 for ; Tue, 1 Apr 2003 08:30:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31GUbF9007671 for ietf-sasl-bks; Tue, 1 Apr 2003 08:30:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUaJM007666 for ; Tue, 1 Apr 2003 08:30:36 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 35E02152124; Tue, 1 Apr 2003 11:29:56 -0500 (EST) To: raif@fl.net.au Cc: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> From: Sam Hartman Date: Tue, 01 Apr 2003 11:29:56 -0500 In-Reply-To: <200304012027.29229.raif@fl.net.au> ("Raif S. Naffah"'s message of "Tue, 1 Apr 2003 21:27:26 +1100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Raif" == Raif S Naffah writes: Raif> hello there, can someone calrify the following: Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a Raif> needed transformation for authentication identities Raif> (usernames) and passwords, in preference to something like: Raif> MUST be in Unicode Normalization Form KC [UNICODE-KC] Raif> without NUL characters. Please read the stringprep document; it has a good discussion of the elements that go into a stringprep profile and I believe why they are needed. If this is insufficient, please look at old minutes of the IDN working group and their archived mailing list. Note that mechanisms do not need to use the saslprep profile. They need to adopt a stringprep profile that is appropriate for the mechanism in question. For example anonymous uses a much less restrictive profile. Mechanisms using cryptography will tend to need fairly strong canonicalization rules to make sure that usernames and passwords typed with one set of input methods are handled the same when typed with a different set of methods. Raif> wouldn't a transformation such as the SASLPrep be part of Raif> the SASL Profile itself rather than the Mechanism(s)? If by SASL profile, you mean the profile for an application, no. The form of authentication identifiers and other mechanism-specific strings such as passwords is entirely a matter for the mechanism. As an example, Kerberos will mandate a particular stringprep profile for principals and passwords. In order for things to work, the SASL GSSAPI mechanism for Kerberos must use the same stringprep profile. Raif> 2. what is the consensus on specifying/handling Raif> authorization identities for transportation on the wire? is Raif> [UNICODE-KC] enough? The authorization identity is a matter for the application's SASL profile. In many cases, the same constraints will apply to authorization identities as authentication identities. The transformation may end up being server-side rather than client-side, but will likely still be needed. I think we would prefer that application profiles seriously consider the use of saslprep for authorization identifiers, but it is not right for all environments. From owner-ietf-sasl Tue Apr 1 13:28:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LSaJM022837 for ; Tue, 1 Apr 2003 13:28:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LSaKX022836 for ietf-sasl-bks; Tue, 1 Apr 2003 13:28:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.spheniscidae.co.uk (yoda.spheniscidae.co.uk [81.2.79.3]) by above.proper.com (8.12.9/8.11.6) with SMTP id h31LSVJM022831 for ; Tue, 1 Apr 2003 13:28:34 -0800 (PST) Received: (qmail 7618 invoked by uid 1003); 1 Apr 2003 19:41:28 -0000 From: Keith Burdis Reply-To: keith@rucus.ru.ac.za To: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Tue, 1 Apr 2003 20:41:28 +0100 User-Agent: KMail/1.5.1 Cc: Sam Hartman ;, raif@fl.net.au References: <200304012027.29229.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304012041.28164.keith@rucus.ru.ac.za> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's a fun document :-) You have things like: MONGOLIAN TODO SOFT HYPHEN OGHAM SPACE MARK ARABIC END OF AYAH MUSICAL CONTROL CHARACTERS Seriously, this looks to be a reasonable specification for usernames and passwords. Is there any reason why all mechanisms shouldn't use at least this set of restrictions? Why for example, would anonymous use a less restrictive profile? - Keith On Tuesday 01 Apr 2003 17:29, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > > Raif> hello there, can someone calrify the following: > > Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a > Raif> needed transformation for authentication identities > Raif> (usernames) and passwords, in preference to something like: > > Raif> MUST be in Unicode Normalization Form KC [UNICODE-KC] > Raif> without NUL characters. > > Please read the stringprep document; it has a good discussion of the > elements that go into a stringprep profile and I believe why they are > needed. If this is insufficient, please look at old minutes of the > IDN working group and their archived mailing list. > > Note that mechanisms do not need to use the saslprep profile. They > need to adopt a stringprep profile that is appropriate for the > mechanism in question. For example anonymous uses a much less > restrictive profile. > > Mechanisms using cryptography will tend to need fairly strong > canonicalization rules to make sure that usernames and passwords typed > with one set of input methods are handled the same when typed with a > different set of methods. > > Raif> wouldn't a transformation such as the SASLPrep be part of > Raif> the SASL Profile itself rather than the Mechanism(s)? > > If by SASL profile, you mean the profile for an application, no. The > form of authentication identifiers and other mechanism-specific > strings such as passwords is entirely a matter for the mechanism. As > an example, Kerberos will mandate a particular stringprep profile for > principals and passwords. In order for things to work, the SASL > GSSAPI mechanism for Kerberos must use the same stringprep profile. > > > > > Raif> 2. what is the consensus on specifying/handling > Raif> authorization identities for transportation on the wire? is > Raif> [UNICODE-KC] enough? > > > > The authorization identity is a matter for the application's SASL > profile. In many cases, the same constraints will apply to > authorization identities as authentication identities. The > transformation may end up being server-side rather than client-side, > but will likely still be needed. > > I think we would prefer that application profiles seriously consider > the use of saslprep for authorization identifiers, but it is not right > for all environments. From owner-ietf-sasl Tue Apr 1 14:33:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MXDJM024913 for ; Tue, 1 Apr 2003 14:33:13 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31MXDqr024912 for ietf-sasl-bks; Tue, 1 Apr 2003 14:33:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MXBJM024907 for ; Tue, 1 Apr 2003 14:33:12 -0800 (PST) Received: from solomon (a3-p30.syd.fl.net.au [202.181.1.94]) by delenn.fl.net.au (Postfix) with ESMTP id 066ED1807B3; Wed, 2 Apr 2003 08:39:17 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: Sam Hartman Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Wed, 2 Apr 2003 09:33:44 +1100 User-Agent: KMail/1.4.3 Cc: SASL References: <200304012027.29229.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Message-Id: <200304020833.47017.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31MXCJM024909 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Wednesday 02 April 2003 02:29, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > ... > Raif> 2. what is the consensus on specifying/handling > Raif> authorization identities for transportation on the wire? > is Raif> [UNICODE-KC] enough? > > ... > I think we would prefer that application profiles seriously consider > the use of saslprep for authorization identifiers, but it is not > right for all environments. would a sequence of bytes preceded by their count (one additional byte) be enough? cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+ihPJ+e1AKnsTRiERA1uEAJ9S04T3MUhl3pmove989VZ4+zihqQCgv5xL jF8BOOrEJQqTINOcd49Az90= =c1Lz -----END PGP SIGNATURE----- From owner-ietf-sasl Fri Apr 4 11:37:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JbtJM027065 for ; Fri, 4 Apr 2003 11:37:55 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34Jbsgk027064 for ietf-sasl-bks; Fri, 4 Apr 2003 11:37:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JbrJM027055 for ; Fri, 4 Apr 2003 11:37:54 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D94E8152124; Fri, 4 Apr 2003 14:37:18 -0500 (EST) To: minutes@ietf.org Cc: ietf-sasl@imc.org Subject: Minutes for SASL working group at IETF 56 From: Sam Hartman Date: Fri, 04 Apr 2003 14:37:18 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Minutes based on notes from Chris Newman and Sam Hartman. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. From owner-ietf-sasl Fri Apr 4 13:12:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LCfJM004347 for ; Fri, 4 Apr 2003 13:12:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34LCfM3004346 for ietf-sasl-bks; Fri, 4 Apr 2003 13:12:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LCeJM004342 for ; Fri, 4 Apr 2003 13:12:40 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 38EA3152124; Fri, 4 Apr 2003 16:11:56 -0500 (EST) To: raif@fl.net.au Cc: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> <200304020833.47017.raif@fl.net.au> From: Sam Hartman Date: Fri, 04 Apr 2003 16:11:56 -0500 In-Reply-To: <200304020833.47017.raif@fl.net.au> ("Raif S. Naffah"'s message of "Wed, 2 Apr 2003 09:33:44 +1100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Raif" == Raif S Naffah writes: Raif> would a sequence of bytes preceded by their count (one Raif> additional byte) be enough? I don't understand your question. For a sasl mechanism, I think limiting authorization identifiers to 255 bytes would be overly restrictive. For an application profile, sequence of bytes would be an underspecified authorization identifier. From owner-ietf-sasl Fri Apr 4 13:09:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34L9VJM004146 for ; Fri, 4 Apr 2003 13:09:31 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34L9VfJ004145 for ietf-sasl-bks; Fri, 4 Apr 2003 13:09:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34L9UJM004139 for ; Fri, 4 Apr 2003 13:09:30 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 43B16152124; Fri, 4 Apr 2003 16:08:46 -0500 (EST) To: ietf-sasl@imc.org Subject: My concerns about a SRP SASL mechanism Message-Id: <20030404210846.43B16152124@konishi-polis.mit.edu> Date: Fri, 4 Apr 2003 16:08:46 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been asked to clarify my objections to an SRP SASL mechanism. The basic objection is that mechanism designers should write GSSAPI mechanisms not SASL mechanisms unless they have a good reason to do otherwise. If the SRP mechanism was a GSSAPI mechanism then it could be used unmodified within SSH, NFS V4 and other protocols that support GSSAPI for security within the IETF and within other areas. It could also be used with all the protocols that use SASL. If SRP is useful, then people will want to use it with other protocols and so we should try to make sure it is useful with all those protocols. The IETF is busy and reviewing security documents takes time. So we should find the solution that involves minimizing review within the IETF while maximizing the number of situations where the technology is useful. Here are some objections I can see to writing the SRP SASL mechanism in the form of a GSSAPI mechanism: 1) We're almost done with the existing draft. Up until now the document has not received significant review within the IETF. It has not been a work product of a working group and has not been last called before. When a document is submitted to the IETF for the standards track, the IETF receives change control and needs the opportunity to make (potentially significant) changes to the document. 2) GSSAPI libraries are hard to deal with and multi-mechanism GSSAPI support is weak There is no requirement that you use a GSSAPI library or even the GSSAPI within your program to implement a SASL GSSAPI mechanism. You simply need to have a compatible wire encoding, but you can actually implement the mechanism the same as you would implement other SASL mechanisms if you find that an easier implementation choice. Here's roughly what would need to happen to turn a SASL mechanism into a standards track GSSAPI mechanism 1) You need to use the GSSAPI initial context token format. this means you need to include an OID and a bit of header at the beginning of the authentication messages. 2) You need to assign an OID to your mechanism. 3) You may need to think about name formats for principal names a bit. 4) There may be some issues involving out-of-order delivery of messages you need to think about. 5) You should organize the document so it will be clear both to people implementing as a SASL mechanism and as a GSSAPI mechanism. From owner-ietf-sasl Fri Apr 4 16:17:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h350HUJM011501 for ; Fri, 4 Apr 2003 16:17:30 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h350HUxd011500 for ietf-sasl-bks; Fri, 4 Apr 2003 16:17:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.spheniscidae.co.uk (yoda.spheniscidae.co.uk [81.2.79.3]) by above.proper.com (8.12.9/8.11.6) with SMTP id h350HSJM011488 for ; Fri, 4 Apr 2003 16:17:29 -0800 (PST) Received: (qmail 13471 invoked by uid 1003); 5 Apr 2003 01:17:03 -0000 From: Keith Burdis Reply-To: keith@rucus.ru.ac.za To: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism Date: Sat, 5 Apr 2003 01:17:02 +0000 User-Agent: KMail/1.5.1 References: <20030404210846.43B16152124@konishi-polis.mit.edu> In-Reply-To: <20030404210846.43B16152124@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304050117.02990.keith@rucus.ru.ac.za> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday 04 Apr 2003 21:08, Sam Hartman wrote: > I've been asked to clarify my objections to an SRP SASL mechanism. > > The basic objection is that mechanism designers should write GSSAPI > mechanisms not SASL mechanisms unless they have a good reason to do > otherwise. I have no problem with the GSS-API, but it is far from simple. Compare the 85 pages in RFC 2078 with the 16 pages in RFC 2222. The basic question is: why should mechanism designers bother with the complexity of GSS-API when they can design much simpler SASL mechanisms? The reason that SASL came about was because alternatives like the GSS-API were too complicated. I agree that an SRP GSS-API mechanism [1] would be great to have, but that is no reason not to have an SRP SASL mechanism. In our opinion trying to merge the two is not a good idea. > If the SRP mechanism was a GSSAPI mechanism then it could be used > unmodified within SSH, NFS V4 and other protocols that support > GSSAPI for security within the IETF and within other areas. It > could also be used with all the protocols that use SASL. Quite true. > If SRP is useful, then people will want to use it with other protocols > and so we should try to make sure it is useful with all those > protocols. The IETF is busy and reviewing security documents takes > time. So we should find the solution that involves minimizing review > within the IETF while maximizing the number of situations where the > technology is useful. It sounds to me like you are saying that we should not have any other SASL mechanisms other than the SASL GSS-API mechanism. If so, then what is the point of SASL? Is it then just a wrapper for GSS-API? > Here are some objections I can see to writing the SRP SASL mechanism > in the form of a GSSAPI mechanism: > > 1) We're almost done with the existing draft. > > Up until now the document has not received significant review > within the IETF. It has not been a work product of a working > group and has not been last called before. When a document is > submitted to the IETF for the standards track, the IETF receives > change control and needs the opportunity to make (potentially > significant) changes to the document. It is not the product of a working group because someone decided that it wasn't appropriate due to problems with US patents. It has however been discussed on this mailing list on and off for four years. We have no problem with making any changes to the document as long as we feel they are justified. The current document is very different to the orginal version and has benefited significantly from feedback received. > 2) GSSAPI libraries are hard to deal with and multi-mechanism GSSAPI > support is weak > > There is no requirement that you use a GSSAPI library or even the > GSSAPI within your program to implement a SASL GSSAPI mechanism. > You simply need to have a compatible wire encoding, but you can > actually implement the mechanism the same as you would implement > other SASL mechanisms if you find that an easier implementation > choice. It is not really the same as other SASL mechanisms, because there is extra "baggage" included. > Here's roughly what would need to happen to turn a SASL mechanism into > a standards track GSSAPI mechanism > > 1) You need to use the GSSAPI initial context token format. this > means you need to include an OID and a bit of header at the > beginning of the authentication messages. It also means we have to deal with ASN.1: InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech OBJECT IDENTIFIER, innerContextToken ANY DEFINED BY thisMech } This is meaningful for GSS-API, but from an SASL mechanism perspective, this means that we have a bunch of garbage bytes at the beginning of our exchange. > 2) You need to assign an OID to your mechanism. Ok. > 3) You may need to think about name formats for principal names a bit. We don't put any restrictions on name formats, only encodings. > 4) There may be some issues involving out-of-order delivery of > messages you need to think about. In the authentication exchange or in the security layer? > 5) You should organize the document so it will be clear both to people > implementing as a SASL mechanism and as a GSSAPI mechanism. The whole point of SASL is that it is simple. Each of the points above adds complexity to the mechanism. I am not completely dismissing the idea, but I am not convinced that this complexity is justified in the context of what SASL is trying to achieve - simple authentication. - Keith [1] http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt From owner-ietf-sasl Sat Apr 5 06:56:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35EuXJM014991 for ; Sat, 5 Apr 2003 06:56:33 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35EuX2n014990 for ietf-sasl-bks; Sat, 5 Apr 2003 06:56:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35EuVJM014983 for ; Sat, 5 Apr 2003 06:56:32 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E2DE5152124; Sat, 5 Apr 2003 09:55:56 -0500 (EST) To: keith@rucus.ru.ac.za Cc: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism References: <20030404210846.43B16152124@konishi-polis.mit.edu> <200304050117.02990.keith@rucus.ru.ac.za> From: Sam Hartman Date: Sat, 05 Apr 2003 09:55:56 -0500 In-Reply-To: <200304050117.02990.keith@rucus.ru.ac.za> (Keith Burdis's message of "Sat, 5 Apr 2003 01:17:02 +0000") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 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 tried to make this clear at the working group meeting, but it didn't really make it into the minutes. The SRP mechanism is out of scope for this working group, so I am not acting as chair in this discussion. I am acting as an interested party. Should this specification ever become a work item of this working group, I'll find someone else to argue this position so I can be an effective chair.] , >>>>> "Keith" == Keith Burdis writes: Keith> On Friday 04 Apr 2003 21:08, Sam Hartman wrote: >> I've been asked to clarify my objections to an SRP SASL >> mechanism. >> >> The basic objection is that mechanism designers should write >> GSSAPI mechanisms not SASL mechanisms unless they have a good >> reason to do otherwise. Keith> I have no problem with the GSS-API, but it is far from Keith> simple. Compare the 85 pages in RFC 2078 with the 16 pages Keith> in RFC 2222. I think comparing the page counts is a significantly misleading complexity metric. I believe that the complexity of a simple GSSAPI mechanism is not significantly more than the complexity of a simple SASL mechanism with a security layer. There are certainly GSSAPI mechanisms that are more complex than non-GSSAPI SASL mechanisms, but this is not required. Keith> The basic question is: why should mechanism designers Keith> bother with the complexity of GSS-API when they can design Keith> much simpler SASL mechanisms? First, I don't think there is that much more complexity involved. But my primary concern is that review and specification of a technology for multiple protocols is much more expensive than taking the work up front to specify the technology for a framework. Specifying SRP for all the other protocols that use GSSAPI would take more time than doing a SRP GSSAPI mechanism rather than a SASL mechanism. Even if we could reuse significant ideas from the SASL mechanism, doing the work to compare and contrast the results of all the SRP specifications against each other making sure that they worked well together and that there were not bugs introduced as ideas were copied would be significantly greater than the cost of specifying a GSSAPI mechanism now. The only way specifying a SASL mechanism makes sense is if we hope never to have to do the work of specifying a GSSAPI mechanism later or to specify SRP for other protocols that support both GSSAPI and other authentication technology. There are two reasons this might be the case. The first is that SRP might not get enough deployment to matter for those protocols. The second is that SRP is somehow uniquely suited to applications that use SASL but not to current and future protocols that use GSS. If SRP is not going to get enough deployment for future work, then we shouldn't even bother with the SASL mechanism. Specification review effort is very expensive and we're all fairly busy as is. I can't think of a reason why SRP would be more suited to email, directory access, etc than say file sharing or remote login. If you can then I'll certainly reconsider. Keith> The reason that SASL came Keith> about was because alternatives like the GSS-API were too Keith> complicated. I think the complexity being complained about was mostly on the application side--GSSAPI is hard to integrate into a protocol. I don't think the same complexities really exist on the mechanism side. SASL was also important because there exist SASL mechanisms that do not have enough features to be GSS mechanisms. Keith> I agree that an SRP GSS-API mechanism [1] would be great to Keith> have, but that is no reason not to have an SRP SASL Keith> mechanism. I think it is. First, I think the costs of doing both an SRP GSS mechanism and an SRP SASL mechanism are significantly higher than the costs of the GSS mechanism alone. Second, having multiple ways to use SRP in the same protocol will confuse site administrators and users and make configuration more complex. >> If SRP is useful, then people will want to use it with other >> protocols and so we should try to make sure it is useful with >> all those protocols. The IETF is busy and reviewing security >> documents takes time. So we should find the solution that >> involves minimizing review within the IETF while maximizing the >> number of situations where the technology is useful. Keith> It sounds to me like you are saying that we should not have Keith> any other SASL mechanisms other than the SASL GSS-API Keith> mechanism. If so, then what is the point of SASL? Is it Keith> then just a wrapper for GSS-API? I think the point of SASL is to be a convenient way to add authentication to applications. It happens to encapsulate a lot of the GSS complexity that will be the same for all applications. It also provides for mechanisms that are too weak to be GSS mechanisms. Applications should use SASL if they can live within its constraints. Except in some special cases mechanisms should be designed for GSS. >> 2) GSSAPI libraries are hard to deal with and multi-mechanism >> GSSAPI support is weak >> >> There is no requirement that you use a GSSAPI library or even >> the GSSAPI within your program to implement a SASL GSSAPI >> mechanism. You simply need to have a compatible wire encoding, >> but you can actually implement the mechanism the same as you >> would implement other SASL mechanisms if you find that an >> easier implementation choice. Keith> It is not really the same as other SASL mechanisms, because Keith> there is extra "baggage" included. A few extra bytes at the beginning of the context tokens doesn't seem unacceptable. >> Here's roughly what would need to happen to turn a SASL >> mechanism into a standards track GSSAPI mechanism >> >> 1) You need to use the GSSAPI initial context token format. >> this means you need to include an OID and a bit of header at >> the beginning of the authentication messages. Keith> It also means we have to deal with ASN.1: False. The GSSAPI spec defines the context token header both in terms of ASN.1 and in terms of raw bytes. It explicitly states that the raw bytes definition is authoritative. You could choose to use ASN.1 if you like, or you could just emit the context token header for your mechanism, listing it as raw bytes in your specification. >> 4) There may be some issues involving out-of-order delivery of >> messages you need to think about. Keith> In the authentication exchange or in the security layer? security layer. Keith> [1] Keith> http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt From owner-ietf-sasl Sat Apr 5 14:36:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MaiJM008904 for ; Sat, 5 Apr 2003 14:36:44 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35MaiT6008903 for ietf-sasl-bks; Sat, 5 Apr 2003 14:36:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MaeJM008899 for ; Sat, 5 Apr 2003 14:36:43 -0800 (PST) Received: from messagingdirect.com (1Cust241.tnt3.edmonton.ab.da.uu.net [64.10.184.241]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h35Me7V20082; Sat, 5 Apr 2003 15:40:07 -0700 Message-ID: <3E8F4EF3.3AB646CD@messagingdirect.com> Date: Sat, 05 Apr 2003 14:47:31 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism References: <20030404210846.43B16152124@konishi-polis.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Here's roughly what would need to happen to turn a SASL mechanism into > a standards track GSSAPI mechanism > > 1) You need to use the GSSAPI initial context token format. this > means you need to include an OID and a bit of header at the > beginning of the authentication messages. > > 2) You need to assign an OID to your mechanism. > > 3) You may need to think about name formats for principal names a bit. > > 4) There may be some issues involving out-of-order delivery of > messages you need to think about. > > 5) You should organize the document so it will be clear both to people > implementing as a SASL mechanism and as a GSSAPI mechanism. Sam, do you volunteer to write a paragraph that describes a binary representation for the GSSAPI header? If you (or somebody else) do this, we would be done with this discussion. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Sat Apr 5 14:36:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35ManJM008912 for ; Sat, 5 Apr 2003 14:36:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35ManJx008911 for ietf-sasl-bks; Sat, 5 Apr 2003 14:36:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MalJM008907 for ; Sat, 5 Apr 2003 14:36:47 -0800 (PST) Received: from messagingdirect.com (1Cust241.tnt3.edmonton.ab.da.uu.net [64.10.184.241]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h35MdEV20068; Sat, 5 Apr 2003 15:39:16 -0700 Message-ID: <3E8F4DEB.CF1E05C7@messagingdirect.com> Date: Sat, 05 Apr 2003 14:43:07 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: keith@rucus.ru.ac.za CC: SASL , Sam Hartman , raif@fl.net.au Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> <200304012041.28164.keith@rucus.ru.ac.za> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Burdis wrote: > Seriously, this looks to be a reasonable specification for usernames and > passwords. Is there any reason why all mechanisms shouldn't use at least this > set of restrictions? IMHO, all new mechanisms should use the same stringprep profile. > Why for example, would anonymous use a less restrictive > profile? This is required for backward compatibility, as ANONYMOUS allowed for arbitrary text to be passed. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Sat Apr 5 16:27:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h360RvJM012941 for ; Sat, 5 Apr 2003 16:27:57 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h360RvIE012940 for ietf-sasl-bks; Sat, 5 Apr 2003 16:27:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h360RuJM012928 for ; Sat, 5 Apr 2003 16:27:56 -0800 (PST) Received: from solomon (a3-p07.syd.fl.net.au [202.181.1.71]) by delenn.fl.net.au (Postfix) with ESMTP id AAA91180C2B; Sun, 6 Apr 2003 10:29:45 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: Sam Hartman Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Sun, 6 Apr 2003 10:23:33 +1000 User-Agent: KMail/1.4.3 Cc: SASL References: <200304012027.29229.raif@fl.net.au> <200304020833.47017.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Message-Id: <200304061023.35180.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h360RuJM012935 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Saturday 05 April 2003 07:11, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > > Raif> would a sequence of bytes preceded by their count (one > Raif> additional byte) be enough? > > I don't understand your question. For a sasl mechanism, I think > limiting authorization identifiers to 255 bytes would be overly > restrictive. > > For an application profile, sequence of bytes would be an > underspecified authorization identifier. the adoption of StringPrep, within the specifications of a SASL Mechanism, solves the question of required (canonical) transformations for authentication IDs (uersnames) and passwords. this is because as you pointed out --in your last email, and i totally overlooked-- these entities are acquired by the mechanism itself and hence are not within the scope of the Profile. the authorization ID on the other hand, is not acquired by the Mechanism; at least this is my understanding/interpretation of last para in section 4.1 of draft-myers-saslrev-02.txt, which echoes another para in section 3 of RFC-2222: "During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (frequently known as a userid) from the client to server, and negotiates the use of a mechanism-specific security layer." in other words, a Profile hands over an authorization ID (or a callback mechanism to receive it), which it (the Mechanism) then transmits to the peer. my question is on the encoding of this entity as seen by the Mechanism, at that interface point. draft-myers-saslrev-02, section 4.2 reflects discussions we had in this group about this token (authorization ID). it proposes: "An authorization identity is a string of zero or more ISO 10646 [ISO-10646] coded characters. The NULL (U+0000) character is not permitted in authorization identities." my question is about reaching a consensus on a choice and wording for how this entity is passed between the Mechanism and the Profile. if a string of iso-10646 w/o nulls is not an acceptable option would an octet sequence with a length octet be one. if neither are, what other alternatives are there. cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+j3OF+e1AKnsTRiERA0nqAKDWdJjXf9TMTF+NNIL1jkVROjmumQCgheOm 053vd60+E1B+ZZVebhXhhPo= =WWvx -----END PGP SIGNATURE----- From owner-ietf-sasl Mon Apr 7 10:39:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HdtJM019463 for ; Mon, 7 Apr 2003 10:39:55 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37HdtN6019462 for ietf-sasl-bks; Mon, 7 Apr 2003 10:39:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HdrJM019448 for ; Mon, 7 Apr 2003 10:39:54 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 97826152124; Mon, 7 Apr 2003 13:39:20 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> From: Sam Hartman Date: Mon, 07 Apr 2003 13:39:20 -0400 In-Reply-To: <3E89239B.1E03F4FE@messagingdirect.com> (Alexey Melnikov's message of "Mon, 31 Mar 2003 22:28:59 -0700") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 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> We have to be clear that for the protocols that use the Alexey> same format for authentication and authorization ids, Alexey> "authzid" is in UTF-8 and MUST NOT be converted to Alexey> ISO-8859-1 as username/password are. No, authz ID is in whatever format the application says it is. All the base spec seems to say is that it is a string. I would recommend replacing the text I complained about with something that says "The authorization identifier MUST NOT be converted to ISO 8859-1 by this mechanism even if the authentication identifier is converted for compatibility." >> The security discussion seems inadequate. Alexey> Suggestions? I specifically meant the security discussion of the QOP stuff, BTW. From owner-ietf-sasl Tue Apr 8 14:29:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LTbJM017915 for ; Tue, 8 Apr 2003 14:29:38 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38LTbkh017914 for ietf-sasl-bks; Tue, 8 Apr 2003 14:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LTaJM017909 for ; Tue, 8 Apr 2003 14:29:37 -0700 (PDT) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA10991 for ; Tue, 8 Apr 2003 15:29:39 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HD1000XDNNISK@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Tue, 08 Apr 2003 15:28:31 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HD1002CSNN9MZ@mail.sun.net> for ietf-sasl@imc.org; Tue, 08 Apr 2003 15:28:30 -0600 (MDT) Date: Tue, 08 Apr 2003 14:26:59 -0700 From: Chris Newman Subject: SASL API: should sasl_errdetail be human readable or deprecated? To: Alexey Melnikov , Rob Siemborski Cc: ietf-sasl@imc.org Message-id: <2147483647.1049812019@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When I added the sasl_errdetail call to the SASL API, my intent was that it would provide human readable strings intended for IMAP NO and POP -ERR style text response messages, and suitable for display to end-users. The current API spec is too imprecise about the purpose of that function: Given there is already a logging callback in the SASL API, I would argue that sasl_errdetail serves no purpose unless it is intended for end-user consumption. However, the CMU implementation generates cryptic error strings which are not suitable for end-user consumption and which leak security sensitive information (like the distinction between user not found and bad password). That leaves us a choice: 1. Clarify that sasl_errdetail is intended to return error strings suitable to be passed back over protocol and presented to an end-user. This would require clarification to the spec and some changes to the CMU implementation. I am willing to propose the code changes to CMU if there is consensus for this option. 2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error codes as the only way to determine what text messages to pass back to the end-user. Use the logging callback for all detailed error logging. I propose option 1 as the correct choice. My theory is that attempting to enumerate all errors which require different behaviors on the client side is a tractable problem, but attempting to enumerate all errors which are useful to inform the user is not a tractable problem and thus a text string to pass back to the user is important. If there are no objections, I will propose changes to the API spec to Alexey and changes to the CMU implementation to Rob. - Chris From owner-ietf-sasl Tue Apr 8 20:03:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3933fJM004337 for ; Tue, 8 Apr 2003 20:03:41 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3933fdO004336 for ietf-sasl-bks; Tue, 8 Apr 2003 20:03:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3933bJM004332 for ; Tue, 8 Apr 2003 20:03:40 -0700 (PDT) Received: from messagingdirect.com (1Cust234.tnt3.edmonton.ab.da.uu.net [64.10.184.234]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h39370V20454; Tue, 8 Apr 2003 21:07:00 -0600 Message-ID: <3E938D1C.6831BAB1@messagingdirect.com> Date: Tue, 08 Apr 2003 21:01:48 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > >>>>> "Alexey" == Alexey Melnikov writes: > > Alexey> We have to be clear that for the protocols that use the > Alexey> same format for authentication and authorization ids, > Alexey> "authzid" is in UTF-8 and MUST NOT be converted to > Alexey> ISO-8859-1 as username/password are. > > No, authz ID is in whatever format the application says it is. All > the base spec seems to say is that it is a string. > > I would recommend replacing the text I complained about with something > that says "The authorization identifier MUST NOT be converted to ISO > 8859-1 by this mechanism even if the authentication identifier is > converted for compatibility." Ok, I've mostly fixed this. The new text in 2.1.2 looks like: authzid The "authorization ID" directive is optional. If present, and the authenticating user has sufficient privilege, and the server supports it, then after authentication the server will use this identity for making all accesses and access checks. If the client specifies it, and the server does not support it, then the response-value calculated on the server will not match the one calculated on the client and authentication will fail. The authorization identifier MUST NOT be converted to ISO 8859-1 even if the authentication identifier ("username") is converted for compatibility as directed by "charset" directive. The server SHOULD verify the correctness of an authzid. For example, an IMAP [RFC 3501] server will prepare the received authzid using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If preparation of the authzid fails or results in an empty string, the server MUST fail the authentication exchange. === I am not sure whether the last paragraph belongs to this document, or whether it should be moved to the SASL document or profile documents. Personally, I would hate to update each profile document with this text. > >> The security discussion seems inadequate. > > Alexey> Suggestions? > > I specifically meant the security discussion of the QOP stuff, BTW. >>3.6 Man in the Middle ... >>A possible man-in-the-middle attack would be to substitute a weaker qop >>scheme for the one(s) sent by the server; the server will not be able to >>detect this attack. For this reason, the client should always use the >>strongest scheme that it understands from the choices offered, and >>should never choose a scheme that does not meet its minimum >>requirements. Can you suggest any specific changes to this text? Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Wed Apr 9 12:25:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JP2JM016264 for ; Wed, 9 Apr 2003 12:25:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39JP2Qn016263 for ietf-sasl-bks; Wed, 9 Apr 2003 12:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-ONE-NINETY-SEVEN.MIT.EDU [18.187.5.197]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JOxJM016251 for ; Wed, 9 Apr 2003 12:24:59 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 73D4E15226A; Wed, 9 Apr 2003 15:25:01 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 From: Sam Hartman Date: Wed, 09 Apr 2003 15:25:01 -0400 In-Reply-To: <3E938D1C.6831BAB1@messagingdirect.com> (Alexey Melnikov's message of "Tue, 08 Apr 2003 21:01:48 -0600") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> <3E938D1C.6831BAB1@messagingdirect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> === I am not sure whether the last paragraph belongs to Alexey> this document, or whether it should be moved to the SASL Alexey> document or profile documents. Personally, I would hate Alexey> to update each profile document with this text. I think that this goes in the base spec. I'll think about text for the man-in-the-middle case. I'm not really sure what we want to happen. We could recommend that people always mandate integrity protection or confidentiality, but doing so would create interoperability problems. We could recommend that people not use digest-md5, but we should have something to recommend instead. From owner-ietf-sasl Thu Apr 10 11:23:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AINKJM001362 for ; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AINKBQ001361 for ietf-sasl-bks; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tintagel-int.labs.agilent.com (tintagel-ext.labs.agilent.com [192.25.140.108]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AINJJM001357 for ; Thu, 10 Apr 2003 11:23:19 -0700 (PDT) Received: from unicorn.labs.agilent.com (root@unicorn.labs.agilent.com [130.29.252.5]) by tintagel-int.labs.agilent.com (8.12.9/8.12.9/Tintagel Sendmail Config v01.02 2002/10/28) with ESMTP id h3AINLDO015095; Thu, 10 Apr 2003 11:23:21 -0700 (PDT) Received: from alex1.labs.agilent.com (alex1.labs.agilent.com [130.29.252.55]) by unicorn.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3AINKoR021621; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) Received: from 130.29.252.18 by alex1.labs.agilent.com (InterScan E-Mail VirusWall NT); Thu, 10 Apr 2003 11:23:20 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3AINGIT027770; Thu, 10 Apr 2003 11:23:16 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Apr 2003 11:23:16 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Cc: paulle@microsoft.com, chris.newman@INNOSOFT.COM Subject: Comments on 2831 Confidentiality Protection Date: Thu, 10 Apr 2003 11:23:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5" X-Spam-Status: No, hits=-97.7 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF8E.406176BE" ------_=_NextPart_001_01C2FF8E.406176BE Content-Type: text/plain; charset="iso-8859-1" I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC. This requires decryption of the entire message before authentication can be done. RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding. One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done (another form of denial of protection against denial of service, replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406. This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies. See section 2 of the rfc2406. I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406. For purposes of rfc2831, the SPI and next header fields could be defined as zeros. As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection. If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client. -- Glenn glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066 ------_=_NextPart_001_01C2FF8E.406176BE Content-Type: text/html; charset="iso-8859-1"
I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC.   This requires decryption of the entire message before authentication can be done.
 
RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding.  One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done  (another form of denial of protection against denial of service,  replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406.  This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies.  See section 2 of the rfc2406.
 
I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406.  For purposes of rfc2831, the SPI and next header fields could be defined as zeros. 
 
As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection.  If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client.

--
Glenn

glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066

 
------_=_NextPart_001_01C2FF8E.406176BE-- ------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5-- From owner-ietf-sasl Thu Apr 10 12:15:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJFWJM003861 for ; Thu, 10 Apr 2003 12:15:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AJFVLK003859 for ietf-sasl-bks; Thu, 10 Apr 2003 12:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJFQJM003840 for ; Thu, 10 Apr 2003 12:15:26 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA13677 for ; Thu, 10 Apr 2003 13:15:28 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HD500EWG6TR67@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Thu, 10 Apr 2003 13:15:28 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HD5009SP6TOW6@mail.sun.net> for ietf-sasl@imc.org; Thu, 10 Apr 2003 13:15:27 -0600 (MDT) Date: Thu, 10 Apr 2003 12:13:59 -0700 From: Chris Newman Subject: Re: Comments on 2831 Confidentiality Protection In-reply-to: To: glenn_engel@agilent.com Cc: ietf-sasl@imc.org, paulle@microsoft.com Message-id: <2147483647.1049976839@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The correct time to make this comment was prior to the publication of RFC 2831 -- that's the purpose of the last call period. While consistency across the Internet suite is aesthetically attractive and I would have supported this proposal prior to the publication and deployment of RFC 2831, I must oppose this proposal now. There are a number of deployed implementations of RFC 2831, so backwards compatibility and interoperability with the running code would trump the majority of aesthetic and minor technical points. Now if it were determined that the way RC4 is specified in RFC 2831 has a fatal security flaw and can not be fixed without breaking interoperability, then your proposal would merit consideration. But I have yet to hear such a determination. - Chris begin quotation by glenn_engel@agilent.com on 2003/4/10 11:23 -0700: > > I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes > the cipher of the message as well as a catenated HMAC. This requires > decryption of the entire message before authentication can be done. > RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical > encoding. One notable difference is that ESP defines the HMAC to be done on > the encrypted contents so that the message can be authenticated without the > potentially costly cipher being done (another form of denial of protection > against denial of service, replay or man in the middle attacks). Since the > form of the message is so close to ESP, I would suggest utilizing the exact > packet format as defined in RFC2406. This RFC includes the sequence number, > padding, authentication and encryption techniques to assemble a packet with > only slight differences to what 2831 specifies. See section 2 of the > rfc2406. > I would suggest specifying that the Confidentiality Protection for rfc2831 > payload be constructed as described in RFC2406. For purposes of rfc2831, the > SPI and next header fields could be defined as zeros. > As an enhancement consider the following - sInce rfc2831 is connection > oriented the SPI used in ESP/IPSEC is 'implied' by the connection. If UDP > was instead used as the communication medium then the rfc2831 dialog could > still be done pretty much as defined with the addition of an SPI argument > returned to the client. > > -- > Glenn > > glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066 > From owner-ietf-sasl Fri Apr 11 09:42:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGgrJM004773 for ; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BGgrqF004772 for ietf-sasl-bks; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tintagel-int.labs.agilent.com (tintagel-ext.labs.agilent.com [192.25.140.108]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGgpJM004768 for ; Fri, 11 Apr 2003 09:42:52 -0700 (PDT) Received: from thing1.labs.agilent.com (thing1.labs.agilent.com [130.29.252.18]) by tintagel-int.labs.agilent.com (8.12.9/8.12.9/Tintagel Sendmail Config v01.02 2002/10/28) with ESMTP id h3BGgrDO024851 for ; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) Received: from alexbh1.labs.agilent.com (alexbh1.labs.agilent.com [130.29.252.76]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3BGgrhF029857 for ; Fri, 11 Apr 2003 09:42:53 -0700 Received: from 130.29.252.18 by alexbh1.labs.agilent.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 09:42:52 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3BGgpIT029852 for ; Fri, 11 Apr 2003 09:42:51 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Apr 2003 09:42:51 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Subject: RE: Comments on 2831 Confidentiality Protection Date: Fri, 11 Apr 2003 09:42:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-97.7 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The correct time to make this comment was prior to the > publication of RFC 2831 > -- that's the purpose of the last call period. I just stumbled across the rfc Wednesday. When was the last call ? It "would have been" nice to utilize ESP encoding as it addresses other encryption/auth algorithms and would provide a framework for re-using existing IPSEC code in conjunction with SASL. A new draft of ESP includes policy on how to deal with high speed connections where the sequence number can roll over as well as providing protection from traffic flow analysis. By combining the simplicity of Digest Authentication in 2831 and it's nice way of defining keys with ESP a really nice combination would result. -- Glenn From owner-ietf-sasl Fri Apr 11 13:37:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKbrJM017019 for ; Fri, 11 Apr 2003 13:37:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKbr2Y017017 for ietf-sasl-bks; Fri, 11 Apr 2003 13:37:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BKbqJM017010 for ; Fri, 11 Apr 2003 13:37:52 -0700 (PDT) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3BKbeBT033852; Fri, 11 Apr 2003 20:37:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030411133224.02b59958@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Apr 2003 13:35:16 -0700 To: glenn_engel@agilent.com From: "Kurt D. Zeilenga" Subject: RE: Comments on 2831 Confidentiality Protection Cc: ietf-sasl@imc.org In-Reply-To: Mime-Version: 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:42 AM 4/11/2003, glenn_engel@agilent.com wrote: >> The correct time to make this comment was prior to the >> publication of RFC 2831 >> -- that's the purpose of the last call period. > >I just stumbled across the rfc Wednesday. When was the last call ? December 1998. >It "would have been" nice Lot's of things "would have been" nice. We need to focus on resolving clear technical errors and omissions. Kurt From owner-ietf-sasl Fri Apr 11 15:07:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM79JM021765 for ; Fri, 11 Apr 2003 15:07:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BM79XU021764 for ietf-sasl-bks; Fri, 11 Apr 2003 15:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tripod-int.labs.agilent.com (tripod-ext.labs.agilent.com [192.25.140.133]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM78JM021742 for ; Fri, 11 Apr 2003 15:07:08 -0700 (PDT) Received: from thing1.labs.agilent.com (thing1.labs.agilent.com [130.29.252.18]) by tripod-int.labs.agilent.com (8.12.9/8.12.9/Tripod Sendmail Config v01.02 2002/09/24) with ESMTP id h3BM76Dn006688 for ; Fri, 11 Apr 2003 15:07:06 -0700 Received: from alexbh1.labs.agilent.com (alexbh1.labs.agilent.com [130.29.252.76]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3BM76hF005418 for ; Fri, 11 Apr 2003 15:07:06 -0700 Received: from 130.29.252.18 by alexbh1.labs.agilent.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 15:07:06 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3BM75IT005413 for ; Fri, 11 Apr 2003 15:07:05 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Apr 2003 15:07:05 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Subject: RE: Comments on 2831 Confidentiality Protection Date: Fri, 11 Apr 2003 15:07:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-98.5 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >From the information on the SASL website it appears to me that 2831 is currently 'under revision', hence my suggestion to allow use of ESP as an option for encoding the integrity and confidentiality protection. This could easily be done by simply specifying an 'encoding' field in much the same way the ciper is specified. If the intent is to only 'tweak' technical errors then this suggestion is clearly too late. -- Glenn > > > >I just stumbled across the rfc Wednesday. When was the last call ? > > December 1998. > > >It "would have been" nice > > Lot's of things "would have been" nice. > > We need to focus on resolving clear technical errors and omissions. > > Kurt > From owner-ietf-sasl Fri Apr 11 15:40:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BMebJM023943 for ; Fri, 11 Apr 2003 15:40:37 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BMebS2023941 for ietf-sasl-bks; Fri, 11 Apr 2003 15:40:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BMeZJM023932 for ; Fri, 11 Apr 2003 15:40:35 -0700 (PDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 15:40:33 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 15:40:33 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 15:40:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 11 Apr 2003 15:40:32 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 11 Apr 2003 15:40:31 -0700 Content-class: urn:content-classes:message Subject: RE: Comments on draft-ietf-sasl-rfc2831 MIME-Version: 1.0 Date: Fri, 11 Apr 2003 15:40:30 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0043_01C30040.AFC2EC00" x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24601D74AE5@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sasl-rfc2831 Thread-Index: AcL+z3x2CJTiX9IXRpK6xuaWMZyG8ABq3EIA From: "Paul Leach" To: "Sam Hartman" , "Alexey Melnikov" Cc: X-OriginalArrivalTime: 11 Apr 2003 22:40:31.0929 (UTC) FILETIME=[5BE61A90:01C3007B] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C30040.AFC2EC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > -----Original Message----- > From: Sam Hartman [mailto:hartmans@mit.edu] > Sent: Wednesday, April 09, 2003 12:25 PM > To: Alexey Melnikov > Cc: ietf-sasl@imc.org > > > >>>>> "Alexey" == Alexey Melnikov writes: > > > Alexey> === I am not sure whether the last paragraph belongs to > Alexey> this document, or whether it should be moved to the SASL > Alexey> document or profile documents. Personally, I would hate > Alexey> to update each profile document with this text. > > I think that this goes in the base spec. > > > I'll think about text for the man-in-the-middle case. I'm > not really sure what we want to happen. > > We could recommend that people always mandate integrity > protection or confidentiality, but doing so would create > interoperability problems. That's not necessary, as long as both sides only offer or agree to mechanisms that meet their minimum security requirements. I.e., it's not great but not fatal that they don't always agree on the strongest mechanism. Also, using integrity protection on confidentiality does nothing to prevent attacks on QOP, cipher, etc, negotiations. > We could recommend that people not use digest-md5, but we > should have something to recommend instead. > > > ------=_NextPart_000_0043_01C30040.AFC2EC00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIfBjCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBqgwggYRoAMCAQICCi/4jlMA AwApwngwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzAzMTcwMjM4MDla Fw0wMzA2MTUwMjM4MDlaMIGwMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAw DgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENP LUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPO0jr4T GEQuhd6kZ6+6RFJwBhlrERosBDFI0IpHP5k2x7uvLMUZ8o2dLXBsaxcrzEpLfgcSrjiSxnQIYebX 6GY6M31yVsQyXEmfE9T6Sb267pWodlk6+CT0zLJUQqhfeCmyRzy4CiewZ9OpUlcSJ6OGhh4MUmf9 BWAEl16XxUynAgMBAAGjggQrMIIEJzALBgNVHQ8EBAMCB4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYB BAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEAMBMGA1UdJQQMMAoGCCsG AQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phUBgxEwGwYJ KwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1 bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYD VR0OBBYEFClvOqLgDYyfVFb03pkX9/+ozfe3MB8GA1UdIwQYMBaAFIvRzWHx6a+OvJHQQOopv+Yu hUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5UREVWJTIwSVNT VUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0 LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20v TlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hpY2EzLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js MIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPU5UREVWJTIw SVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgGCCsG AQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQSgzKS5j cnQwDQYJKoZIhvcNAQEFBQADgYEAj2sQspSCtU9oLSVBt8cePl0PksH/VXzh85ZqgGieyX6llEXI shmc282W8pmGQ7kChlHXuX1GUHo9PSzyIBjEdA7h833Q/HAUopllZl9DBE2PM21HLOdWOAgE3rrJ s8J9eP1hSzQ4+lQ3Ktsqmo+orYjmfYHhBOw2a7ATAiTvXrgwggbsMIIGVaADAgECAgoghY36AAMA KY7OMA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAM BgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDMwMzE0MDIzODAwWhcN MDMwNTEzMDIzODAwWjCB3TETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1p Y3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4G A1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1F MRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxwYXVsbGVAd2luZG93cy5taWNy b3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw4jrEUKMenSEIizizwXBDjmPa 2YuncW6v0L7D2cydmDRhHWnv9HhYezSCNvqfSg5z32frXyEvKcyDqf2i49kExeznnCthZQ7Ihgs5 XfgZOrr5S2Tzh1a/bdP3/ueCVw7p3M05jfnWXkWyRXXN5ZBaC8bJ4FDbJzvnqVTB1oKMFwIDAQAB o4IEQjCCBD4wCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEE AYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXgCAQAwEwYDVR0lBAwwCgYIKwYB BQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcU AgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29m dC5jb20wHQYDVR0OBBYEFKFuZsO/Y52+l/VSj1QxtebBveYxMB8GA1UdIwQYMBaAFIvRzWHx6a+O vJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5U REVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jv c29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hp Y2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIw Q0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NO PU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQs REM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D ZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMl MjBDQSgzKS5jcnQwDQYJKoZIhvcNAQEFBQADgYEAimqAfBILFHTqZpjy06cpweXt7vsYelrmHCCq KGBnEtiEAEWQfuoEb7FhlaaduDnfJhelzqTj1pOqMIGjgnhRBAIcF+8JvdjU3pgHkaG8bcNFh3xn yXDWrr2JK3LJmIjLC6Mwpn+bzjyAmEC4BMMp0vDnBMON9km1qo4mQ35EKGswgggbMIIHA6ADAgEC AgooxudyAAEAAAA1MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAyMTAx MDE2MzMwMFoXDTA1MTAxMDE2NDMwMFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m dDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0 ZSBXaGljYTIwggG3MIIBKwYHKoZIzjgEATCCAR4CgYEA+hLPe7uYsHmuGUfkITkBqWsGXo22y369 ks09E+EjwAGs24cphaVHqFZ3+KQ/kgyANCvsNSkmut2/hnZPWkk9UQcjEK5rcdNf+j5dUZNld0G/ jH46Ecua3XUpxPL0H7S2mDemwkLib61o41pt37LD8QH0Cg+V0Z0egYEFIY50AuMCFQCYT5Q9snVa 1ekUrZTCYzob/OjrQwKBgGbKD33vFBA+cKvgitrGpSLmxdey9I++KbA79QQXEnACJZLw5S6e+eHs Z3T+xwPlg2RUCxtFgX5c2DJhUKxi6wLUsfwO+g7OrgfPyWD0r/aQDzS/ZKSvgMfUQUzYkbcn0dur frYOT2LxXocBkQD8/yQH38n5wjUuheVa1/Dm5oKYA4GFAAKBgQCiStJWJMhC3tkbRi2OvYYtxyrl tPMOyZR1E5DPWqL15vlw4hhrZheATpyZlMggU4vHps92BvBlICw58FCh9Cgsbe8l5BwawD++PvDO ObOVoiZiwEX05lEUqXsLev9MtKEdcFNAejXrNwIa4sJeFC86yuMmGUq+G9Hl8yY2k4riOaOCBFMw ggRPMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOK+A3DViyDSQURqr+bId3FaJQAfMAsGA1Ud DwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDBAAFMCMGCSsGAQQBgjcVAgQWBBTWUig3WSHjbYXiEmot Y22qaLxrQDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBSIyc2cnDoigOrk LdoVRy/1+8S8mzCCAZkGA1UdHwSCAZAwggGMMIIBiKCCAYSgggGAhoHZbGRhcDovLy9DTj1OVERF ViUyMFNBJTIwUm9vdCUyMENBKDEpLENOPXdoaWNhc2Fyb290Y2EsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZRaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3Js hk9odHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW JTIwU0ElMjBSb290JTIwQ0EoMSkuY3JsMIIB6QYIKwYBBQUHAQEEggHbMIIB1zCByAYIKwYBBQUH MAKGgbtsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGEBggrBgEFBQcwAoZ4aHR0cDovL3doaWNhd2ViLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5t aWNyb3NvZnQuY29tX05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3J0MIGCBggrBgEFBQcwAoZ2 aHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQEFBQADggEBADTCZCUZvE/CF5YX7SiP y/WGMFtXXeCYEr/Y7LSrY5yAL+j4ZKQor7lLfrE7FO9UgGKjfs+LqO0kjxad47041wtArk0e5RXe P0UW0IzZOctur84ke76sqtggFFgCOffLqhY9plCcfVSDpBrngAISXVuhx8oEzptU2UkqcH5ZGmfB vgytdCKe+vStiuVgf5nvEQIej5on2qentxdfMQsXntj2oEFupjmR6J9YV9f43GEWlGuDC1Lou10g 84idAsbaQ+hjxBp8e9NIGPgi5LF1o353R32fU4Oc3ggpGFFiJVKnA/tqgusrcV6ViN0sQftdALar 5PjV25iA2FaXQOR/bpcxggKfMIICmwIBATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCi/4jlMAAwAp wngwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMwNDExMjI0MDMyWjAjBgkqhkiG9w0BCQQxFgQUPK1a7kcKBxBQ6VRH7XEGfCtku/EwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAE MVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEY MBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgoghY36AAMAKY7OMGoGCyqGSIb3DQEJEAILMVugWTBL MQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UE AxMPTlRERVYgSVNTVUUzIENBAgoghY36AAMAKY7OMA0GCSqGSIb3DQEBAQUABIGAYsCIfYl50CGA Dh+piAIsPVedj4M6dP3L0cu7cg8lVreO0yoCW9HTTPvf+SLPgVHRqS7hDLnZADrScCVAxNArHSqI 5vMgAzY0muVi/73rFhoxGfpzCJeN5c9K3xJ4twdlPmmzsKkLlX7Aa6xISu9H+aqJk6K4j3yHSI8B BSGaD+sAAAAAAAA= ------=_NextPart_000_0043_01C30040.AFC2EC00-- From owner-ietf-sasl Mon Apr 14 15:03:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EM3UbP081569 for ; Mon, 14 Apr 2003 15:03:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EM3Ugr081568 for ietf-sasl-bks; Mon, 14 Apr 2003 15:03:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EM3TbP081560 for ; Mon, 14 Apr 2003 15:03:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E772515226A; Mon, 14 Apr 2003 18:03:14 -0400 (EDT) To: glenn_engel@agilent.com Cc: ietf-sasl@imc.org Subject: Re: Comments on 2831 Confidentiality Protection From: Sam Hartman Date: Mon, 14 Apr 2003 18:03:14 -0400 In-Reply-To: (glenn engel's message of "Fri, 11 Apr 2003 15:07:05 -0700") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) 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: >>>>> "glenn" == glenn engel writes: glenn> From the information on the SASL website it appears to me glenn> that 2831 is currently 'under revision', hence my glenn> suggestion to allow use of ESP as an option for encoding glenn> the integrity and confidentiality protection. This could glenn> easily be done by simply specifying an 'encoding' field in glenn> much the same way the ciper is specified. If the intent is glenn> to only 'tweak' technical errors then this suggestion is glenn> clearly too late. The intent is certainly to avoid breaking backward compatibility. Chris's comments suggest that introducing a different encoding for newer ciphers would be unpopular, presumably because it would introduce implementation complexity and increase the complexity of the spec. So, yes, it looks like people believe this change is not worth making, although they agree in an ideal world reuse of technology would be good. From owner-ietf-sasl Sun Apr 20 00:54:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7sat2051871 for ; Sun, 20 Apr 2003 00:54:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K7saGp051870 for ietf-sasl-bks; Sun, 20 Apr 2003 00:54:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7sTt2051839 for ; Sun, 20 Apr 2003 00:54:35 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust115.tnt3.edmonton.ab.da.uu.net [64.10.184.115]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K7v7V30041; Sun, 20 Apr 2003 01:57:08 -0600 Message-ID: <3EA23A5A.B6516BED@messagingdirect.com> Date: Sun, 20 Apr 2003 00:12:43 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Newman CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: SASL API: should sasl_errdetail be human readable or deprecated? References: <2147483647.1049812019@nifty-jr.west.sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris Newman wrote: > When I added the sasl_errdetail call to the SASL API, my intent was that it > would provide human readable strings intended for IMAP NO and POP -ERR style > text response messages, and suitable for display to end-users. > > The current API spec is too imprecise about the purpose of that function: > > > Given there is already a logging callback in the SASL API, I would argue that > sasl_errdetail serves no purpose unless it is intended for end-user > consumption. However, the CMU implementation generates cryptic error strings > which are not suitable for end-user consumption and which leak security > sensitive information (like the distinction between user not found and bad > password). > > That leaves us a choice: > > 1. Clarify that sasl_errdetail is intended to return error strings suitable to > be passed back over protocol and presented to an end-user. This would require > clarification to the spec and some changes to the CMU implementation. I am > willing to propose the code changes to CMU if there is consensus for this > option. > > 2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error > codes as the only way to determine what text messages to pass back to the > end-user. Use the logging callback for all detailed error logging. > > I propose option 1 as the correct choice. My theory is that attempting to > enumerate all errors which require different behaviors on the client side is a > tractable problem, but attempting to enumerate all errors which are useful to > inform the user is not a tractable problem and thus a text string to pass back > to the user is important. > > If there are no objections, I will propose changes to the API spec to Alexey > and changes to the CMU implementation to Rob. I agree with this proposal (and just finished updating the document). Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Wed Apr 23 16:11:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NNBOt2044745 for ; Wed, 23 Apr 2003 16:11:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NNBOrU044744 for ietf-sasl-bks; Wed, 23 Apr 2003 16:11:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NNBNt2044739 for ; Wed, 23 Apr 2003 16:11:23 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost4 [127.0.0.1]) by orthanc.ab.ca (8.12.6p2/8.12.6) with ESMTP id h3NNBPGS053722 for ; Wed, 23 Apr 2003 17:11:25 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200304232311.h3NNBPGS053722@orthanc.ab.ca> From: Lyndon Nerenberg {VE6BBM} To: ietf-sasl@imc.org Subject: CRAM-MD5 implementation limits for Organization: The Frobozz Magic Homing Pigeon Company X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Apr 2003 17:11:25 -0600 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Plain draft specifies that implementations must support at least 255 octets for the and elements. Should we do the same for in CRAM-MD5? --lyndon From owner-ietf-sasl Tue Apr 1 02:34:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31AYxJM008519 for ; Tue, 1 Apr 2003 02:34:59 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31AYxQj008518 for ietf-sasl-bks; Tue, 1 Apr 2003 02:34:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31AYvJM008508 for ; Tue, 1 Apr 2003 02:34:57 -0800 (PST) Received: from solomon (a5-p20.syd.fl.net.au [202.181.2.20]) by delenn.fl.net.au (Postfix) with ESMTP id 5D9A8180570 for ; Tue, 1 Apr 2003 20:33:04 +1000 (EST) Content-Type: text/plain; charset="us-ascii" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: SASL Subject: authentication and authorization identities, and passwords in SASL Mechanisms Date: Tue, 1 Apr 2003 21:27:26 +1100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200304012027.29229.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31AYwJM008513 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hello there, can someone calrify the following: 1. why does a SASL Mechanism has to mandate SASLPrep as a needed transformation for authentication identities (usernames) and passwords, in preference to something like: MUST be in Unicode Normalization Form KC [UNICODE-KC] without NUL characters. wouldn't a transformation such as the SASLPrep be part of the SASL Profile itself rather than the Mechanism(s)? 2. what is the consensus on specifying/handling authorization identities for transportation on the wire? is [UNICODE-KC] enough? TIA + cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+iWmO+e1AKnsTRiERAwZNAJ4r/AOu++oWkA3ppSCnjmjWGYyXwwCg6zSh W1bU3OxBgrU8PFNyefvnlWw= =Yob+ -----END PGP SIGNATURE----- From owner-ietf-sasl Tue Apr 1 08:30:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUbJM007672 for ; Tue, 1 Apr 2003 08:30:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31GUbF9007671 for ietf-sasl-bks; Tue, 1 Apr 2003 08:30:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUaJM007666 for ; Tue, 1 Apr 2003 08:30:36 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 35E02152124; Tue, 1 Apr 2003 11:29:56 -0500 (EST) To: raif@fl.net.au Cc: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> From: Sam Hartman Date: Tue, 01 Apr 2003 11:29:56 -0500 In-Reply-To: <200304012027.29229.raif@fl.net.au> ("Raif S. Naffah"'s message of "Tue, 1 Apr 2003 21:27:26 +1100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Raif" == Raif S Naffah writes: Raif> hello there, can someone calrify the following: Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a Raif> needed transformation for authentication identities Raif> (usernames) and passwords, in preference to something like: Raif> MUST be in Unicode Normalization Form KC [UNICODE-KC] Raif> without NUL characters. Please read the stringprep document; it has a good discussion of the elements that go into a stringprep profile and I believe why they are needed. If this is insufficient, please look at old minutes of the IDN working group and their archived mailing list. Note that mechanisms do not need to use the saslprep profile. They need to adopt a stringprep profile that is appropriate for the mechanism in question. For example anonymous uses a much less restrictive profile. Mechanisms using cryptography will tend to need fairly strong canonicalization rules to make sure that usernames and passwords typed with one set of input methods are handled the same when typed with a different set of methods. Raif> wouldn't a transformation such as the SASLPrep be part of Raif> the SASL Profile itself rather than the Mechanism(s)? If by SASL profile, you mean the profile for an application, no. The form of authentication identifiers and other mechanism-specific strings such as passwords is entirely a matter for the mechanism. As an example, Kerberos will mandate a particular stringprep profile for principals and passwords. In order for things to work, the SASL GSSAPI mechanism for Kerberos must use the same stringprep profile. Raif> 2. what is the consensus on specifying/handling Raif> authorization identities for transportation on the wire? is Raif> [UNICODE-KC] enough? The authorization identity is a matter for the application's SASL profile. In many cases, the same constraints will apply to authorization identities as authentication identities. The transformation may end up being server-side rather than client-side, but will likely still be needed. I think we would prefer that application profiles seriously consider the use of saslprep for authorization identifiers, but it is not right for all environments. From owner-ietf-sasl Tue Apr 1 13:28:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LSaJM022837 for ; Tue, 1 Apr 2003 13:28:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LSaKX022836 for ietf-sasl-bks; Tue, 1 Apr 2003 13:28:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.spheniscidae.co.uk (yoda.spheniscidae.co.uk [81.2.79.3]) by above.proper.com (8.12.9/8.11.6) with SMTP id h31LSVJM022831 for ; Tue, 1 Apr 2003 13:28:34 -0800 (PST) Received: (qmail 7618 invoked by uid 1003); 1 Apr 2003 19:41:28 -0000 From: Keith Burdis Reply-To: keith@rucus.ru.ac.za To: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Tue, 1 Apr 2003 20:41:28 +0100 User-Agent: KMail/1.5.1 Cc: Sam Hartman ;, raif@fl.net.au References: <200304012027.29229.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304012041.28164.keith@rucus.ru.ac.za> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's a fun document :-) You have things like: MONGOLIAN TODO SOFT HYPHEN OGHAM SPACE MARK ARABIC END OF AYAH MUSICAL CONTROL CHARACTERS Seriously, this looks to be a reasonable specification for usernames and passwords. Is there any reason why all mechanisms shouldn't use at least this set of restrictions? Why for example, would anonymous use a less restrictive profile? - Keith On Tuesday 01 Apr 2003 17:29, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > > Raif> hello there, can someone calrify the following: > > Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a > Raif> needed transformation for authentication identities > Raif> (usernames) and passwords, in preference to something like: > > Raif> MUST be in Unicode Normalization Form KC [UNICODE-KC] > Raif> without NUL characters. > > Please read the stringprep document; it has a good discussion of the > elements that go into a stringprep profile and I believe why they are > needed. If this is insufficient, please look at old minutes of the > IDN working group and their archived mailing list. > > Note that mechanisms do not need to use the saslprep profile. They > need to adopt a stringprep profile that is appropriate for the > mechanism in question. For example anonymous uses a much less > restrictive profile. > > Mechanisms using cryptography will tend to need fairly strong > canonicalization rules to make sure that usernames and passwords typed > with one set of input methods are handled the same when typed with a > different set of methods. > > Raif> wouldn't a transformation such as the SASLPrep be part of > Raif> the SASL Profile itself rather than the Mechanism(s)? > > If by SASL profile, you mean the profile for an application, no. The > form of authentication identifiers and other mechanism-specific > strings such as passwords is entirely a matter for the mechanism. As > an example, Kerberos will mandate a particular stringprep profile for > principals and passwords. In order for things to work, the SASL > GSSAPI mechanism for Kerberos must use the same stringprep profile. > > > > > Raif> 2. what is the consensus on specifying/handling > Raif> authorization identities for transportation on the wire? is > Raif> [UNICODE-KC] enough? > > > > The authorization identity is a matter for the application's SASL > profile. In many cases, the same constraints will apply to > authorization identities as authentication identities. The > transformation may end up being server-side rather than client-side, > but will likely still be needed. > > I think we would prefer that application profiles seriously consider > the use of saslprep for authorization identifiers, but it is not right > for all environments. From owner-ietf-sasl Tue Apr 1 14:33:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MXDJM024913 for ; Tue, 1 Apr 2003 14:33:13 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31MXDqr024912 for ietf-sasl-bks; Tue, 1 Apr 2003 14:33:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MXBJM024907 for ; Tue, 1 Apr 2003 14:33:12 -0800 (PST) Received: from solomon (a3-p30.syd.fl.net.au [202.181.1.94]) by delenn.fl.net.au (Postfix) with ESMTP id 066ED1807B3; Wed, 2 Apr 2003 08:39:17 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: Sam Hartman Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Wed, 2 Apr 2003 09:33:44 +1100 User-Agent: KMail/1.4.3 Cc: SASL References: <200304012027.29229.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Message-Id: <200304020833.47017.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31MXCJM024909 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Wednesday 02 April 2003 02:29, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > ... > Raif> 2. what is the consensus on specifying/handling > Raif> authorization identities for transportation on the wire? > is Raif> [UNICODE-KC] enough? > > ... > I think we would prefer that application profiles seriously consider > the use of saslprep for authorization identifiers, but it is not > right for all environments. would a sequence of bytes preceded by their count (one additional byte) be enough? cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+ihPJ+e1AKnsTRiERA1uEAJ9S04T3MUhl3pmove989VZ4+zihqQCgv5xL jF8BOOrEJQqTINOcd49Az90= =c1Lz -----END PGP SIGNATURE----- From owner-ietf-sasl Fri Apr 4 11:37:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JbtJM027065 for ; Fri, 4 Apr 2003 11:37:55 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34Jbsgk027064 for ietf-sasl-bks; Fri, 4 Apr 2003 11:37:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JbrJM027055 for ; Fri, 4 Apr 2003 11:37:54 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D94E8152124; Fri, 4 Apr 2003 14:37:18 -0500 (EST) To: minutes@ietf.org Cc: ietf-sasl@imc.org Subject: Minutes for SASL working group at IETF 56 From: Sam Hartman Date: Fri, 04 Apr 2003 14:37:18 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Minutes based on notes from Chris Newman and Sam Hartman. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. From owner-ietf-sasl Fri Apr 4 13:12:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LCfJM004347 for ; Fri, 4 Apr 2003 13:12:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34LCfM3004346 for ietf-sasl-bks; Fri, 4 Apr 2003 13:12:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LCeJM004342 for ; Fri, 4 Apr 2003 13:12:40 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 38EA3152124; Fri, 4 Apr 2003 16:11:56 -0500 (EST) To: raif@fl.net.au Cc: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> <200304020833.47017.raif@fl.net.au> From: Sam Hartman Date: Fri, 04 Apr 2003 16:11:56 -0500 In-Reply-To: <200304020833.47017.raif@fl.net.au> ("Raif S. Naffah"'s message of "Wed, 2 Apr 2003 09:33:44 +1100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Raif" == Raif S Naffah writes: Raif> would a sequence of bytes preceded by their count (one Raif> additional byte) be enough? I don't understand your question. For a sasl mechanism, I think limiting authorization identifiers to 255 bytes would be overly restrictive. For an application profile, sequence of bytes would be an underspecified authorization identifier. From owner-ietf-sasl Fri Apr 4 13:09:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34L9VJM004146 for ; Fri, 4 Apr 2003 13:09:31 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34L9VfJ004145 for ietf-sasl-bks; Fri, 4 Apr 2003 13:09:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34L9UJM004139 for ; Fri, 4 Apr 2003 13:09:30 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 43B16152124; Fri, 4 Apr 2003 16:08:46 -0500 (EST) To: ietf-sasl@imc.org Subject: My concerns about a SRP SASL mechanism Message-Id: <20030404210846.43B16152124@konishi-polis.mit.edu> Date: Fri, 4 Apr 2003 16:08:46 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been asked to clarify my objections to an SRP SASL mechanism. The basic objection is that mechanism designers should write GSSAPI mechanisms not SASL mechanisms unless they have a good reason to do otherwise. If the SRP mechanism was a GSSAPI mechanism then it could be used unmodified within SSH, NFS V4 and other protocols that support GSSAPI for security within the IETF and within other areas. It could also be used with all the protocols that use SASL. If SRP is useful, then people will want to use it with other protocols and so we should try to make sure it is useful with all those protocols. The IETF is busy and reviewing security documents takes time. So we should find the solution that involves minimizing review within the IETF while maximizing the number of situations where the technology is useful. Here are some objections I can see to writing the SRP SASL mechanism in the form of a GSSAPI mechanism: 1) We're almost done with the existing draft. Up until now the document has not received significant review within the IETF. It has not been a work product of a working group and has not been last called before. When a document is submitted to the IETF for the standards track, the IETF receives change control and needs the opportunity to make (potentially significant) changes to the document. 2) GSSAPI libraries are hard to deal with and multi-mechanism GSSAPI support is weak There is no requirement that you use a GSSAPI library or even the GSSAPI within your program to implement a SASL GSSAPI mechanism. You simply need to have a compatible wire encoding, but you can actually implement the mechanism the same as you would implement other SASL mechanisms if you find that an easier implementation choice. Here's roughly what would need to happen to turn a SASL mechanism into a standards track GSSAPI mechanism 1) You need to use the GSSAPI initial context token format. this means you need to include an OID and a bit of header at the beginning of the authentication messages. 2) You need to assign an OID to your mechanism. 3) You may need to think about name formats for principal names a bit. 4) There may be some issues involving out-of-order delivery of messages you need to think about. 5) You should organize the document so it will be clear both to people implementing as a SASL mechanism and as a GSSAPI mechanism. From owner-ietf-sasl Fri Apr 4 16:17:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h350HUJM011501 for ; Fri, 4 Apr 2003 16:17:30 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h350HUxd011500 for ietf-sasl-bks; Fri, 4 Apr 2003 16:17:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.spheniscidae.co.uk (yoda.spheniscidae.co.uk [81.2.79.3]) by above.proper.com (8.12.9/8.11.6) with SMTP id h350HSJM011488 for ; Fri, 4 Apr 2003 16:17:29 -0800 (PST) Received: (qmail 13471 invoked by uid 1003); 5 Apr 2003 01:17:03 -0000 From: Keith Burdis Reply-To: keith@rucus.ru.ac.za To: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism Date: Sat, 5 Apr 2003 01:17:02 +0000 User-Agent: KMail/1.5.1 References: <20030404210846.43B16152124@konishi-polis.mit.edu> In-Reply-To: <20030404210846.43B16152124@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304050117.02990.keith@rucus.ru.ac.za> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday 04 Apr 2003 21:08, Sam Hartman wrote: > I've been asked to clarify my objections to an SRP SASL mechanism. > > The basic objection is that mechanism designers should write GSSAPI > mechanisms not SASL mechanisms unless they have a good reason to do > otherwise. I have no problem with the GSS-API, but it is far from simple. Compare the 85 pages in RFC 2078 with the 16 pages in RFC 2222. The basic question is: why should mechanism designers bother with the complexity of GSS-API when they can design much simpler SASL mechanisms? The reason that SASL came about was because alternatives like the GSS-API were too complicated. I agree that an SRP GSS-API mechanism [1] would be great to have, but that is no reason not to have an SRP SASL mechanism. In our opinion trying to merge the two is not a good idea. > If the SRP mechanism was a GSSAPI mechanism then it could be used > unmodified within SSH, NFS V4 and other protocols that support > GSSAPI for security within the IETF and within other areas. It > could also be used with all the protocols that use SASL. Quite true. > If SRP is useful, then people will want to use it with other protocols > and so we should try to make sure it is useful with all those > protocols. The IETF is busy and reviewing security documents takes > time. So we should find the solution that involves minimizing review > within the IETF while maximizing the number of situations where the > technology is useful. It sounds to me like you are saying that we should not have any other SASL mechanisms other than the SASL GSS-API mechanism. If so, then what is the point of SASL? Is it then just a wrapper for GSS-API? > Here are some objections I can see to writing the SRP SASL mechanism > in the form of a GSSAPI mechanism: > > 1) We're almost done with the existing draft. > > Up until now the document has not received significant review > within the IETF. It has not been a work product of a working > group and has not been last called before. When a document is > submitted to the IETF for the standards track, the IETF receives > change control and needs the opportunity to make (potentially > significant) changes to the document. It is not the product of a working group because someone decided that it wasn't appropriate due to problems with US patents. It has however been discussed on this mailing list on and off for four years. We have no problem with making any changes to the document as long as we feel they are justified. The current document is very different to the orginal version and has benefited significantly from feedback received. > 2) GSSAPI libraries are hard to deal with and multi-mechanism GSSAPI > support is weak > > There is no requirement that you use a GSSAPI library or even the > GSSAPI within your program to implement a SASL GSSAPI mechanism. > You simply need to have a compatible wire encoding, but you can > actually implement the mechanism the same as you would implement > other SASL mechanisms if you find that an easier implementation > choice. It is not really the same as other SASL mechanisms, because there is extra "baggage" included. > Here's roughly what would need to happen to turn a SASL mechanism into > a standards track GSSAPI mechanism > > 1) You need to use the GSSAPI initial context token format. this > means you need to include an OID and a bit of header at the > beginning of the authentication messages. It also means we have to deal with ASN.1: InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech OBJECT IDENTIFIER, innerContextToken ANY DEFINED BY thisMech } This is meaningful for GSS-API, but from an SASL mechanism perspective, this means that we have a bunch of garbage bytes at the beginning of our exchange. > 2) You need to assign an OID to your mechanism. Ok. > 3) You may need to think about name formats for principal names a bit. We don't put any restrictions on name formats, only encodings. > 4) There may be some issues involving out-of-order delivery of > messages you need to think about. In the authentication exchange or in the security layer? > 5) You should organize the document so it will be clear both to people > implementing as a SASL mechanism and as a GSSAPI mechanism. The whole point of SASL is that it is simple. Each of the points above adds complexity to the mechanism. I am not completely dismissing the idea, but I am not convinced that this complexity is justified in the context of what SASL is trying to achieve - simple authentication. - Keith [1] http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt From owner-ietf-sasl Sat Apr 5 06:56:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35EuXJM014991 for ; Sat, 5 Apr 2003 06:56:33 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35EuX2n014990 for ietf-sasl-bks; Sat, 5 Apr 2003 06:56:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35EuVJM014983 for ; Sat, 5 Apr 2003 06:56:32 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E2DE5152124; Sat, 5 Apr 2003 09:55:56 -0500 (EST) To: keith@rucus.ru.ac.za Cc: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism References: <20030404210846.43B16152124@konishi-polis.mit.edu> <200304050117.02990.keith@rucus.ru.ac.za> From: Sam Hartman Date: Sat, 05 Apr 2003 09:55:56 -0500 In-Reply-To: <200304050117.02990.keith@rucus.ru.ac.za> (Keith Burdis's message of "Sat, 5 Apr 2003 01:17:02 +0000") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 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 tried to make this clear at the working group meeting, but it didn't really make it into the minutes. The SRP mechanism is out of scope for this working group, so I am not acting as chair in this discussion. I am acting as an interested party. Should this specification ever become a work item of this working group, I'll find someone else to argue this position so I can be an effective chair.] , >>>>> "Keith" == Keith Burdis writes: Keith> On Friday 04 Apr 2003 21:08, Sam Hartman wrote: >> I've been asked to clarify my objections to an SRP SASL >> mechanism. >> >> The basic objection is that mechanism designers should write >> GSSAPI mechanisms not SASL mechanisms unless they have a good >> reason to do otherwise. Keith> I have no problem with the GSS-API, but it is far from Keith> simple. Compare the 85 pages in RFC 2078 with the 16 pages Keith> in RFC 2222. I think comparing the page counts is a significantly misleading complexity metric. I believe that the complexity of a simple GSSAPI mechanism is not significantly more than the complexity of a simple SASL mechanism with a security layer. There are certainly GSSAPI mechanisms that are more complex than non-GSSAPI SASL mechanisms, but this is not required. Keith> The basic question is: why should mechanism designers Keith> bother with the complexity of GSS-API when they can design Keith> much simpler SASL mechanisms? First, I don't think there is that much more complexity involved. But my primary concern is that review and specification of a technology for multiple protocols is much more expensive than taking the work up front to specify the technology for a framework. Specifying SRP for all the other protocols that use GSSAPI would take more time than doing a SRP GSSAPI mechanism rather than a SASL mechanism. Even if we could reuse significant ideas from the SASL mechanism, doing the work to compare and contrast the results of all the SRP specifications against each other making sure that they worked well together and that there were not bugs introduced as ideas were copied would be significantly greater than the cost of specifying a GSSAPI mechanism now. The only way specifying a SASL mechanism makes sense is if we hope never to have to do the work of specifying a GSSAPI mechanism later or to specify SRP for other protocols that support both GSSAPI and other authentication technology. There are two reasons this might be the case. The first is that SRP might not get enough deployment to matter for those protocols. The second is that SRP is somehow uniquely suited to applications that use SASL but not to current and future protocols that use GSS. If SRP is not going to get enough deployment for future work, then we shouldn't even bother with the SASL mechanism. Specification review effort is very expensive and we're all fairly busy as is. I can't think of a reason why SRP would be more suited to email, directory access, etc than say file sharing or remote login. If you can then I'll certainly reconsider. Keith> The reason that SASL came Keith> about was because alternatives like the GSS-API were too Keith> complicated. I think the complexity being complained about was mostly on the application side--GSSAPI is hard to integrate into a protocol. I don't think the same complexities really exist on the mechanism side. SASL was also important because there exist SASL mechanisms that do not have enough features to be GSS mechanisms. Keith> I agree that an SRP GSS-API mechanism [1] would be great to Keith> have, but that is no reason not to have an SRP SASL Keith> mechanism. I think it is. First, I think the costs of doing both an SRP GSS mechanism and an SRP SASL mechanism are significantly higher than the costs of the GSS mechanism alone. Second, having multiple ways to use SRP in the same protocol will confuse site administrators and users and make configuration more complex. >> If SRP is useful, then people will want to use it with other >> protocols and so we should try to make sure it is useful with >> all those protocols. The IETF is busy and reviewing security >> documents takes time. So we should find the solution that >> involves minimizing review within the IETF while maximizing the >> number of situations where the technology is useful. Keith> It sounds to me like you are saying that we should not have Keith> any other SASL mechanisms other than the SASL GSS-API Keith> mechanism. If so, then what is the point of SASL? Is it Keith> then just a wrapper for GSS-API? I think the point of SASL is to be a convenient way to add authentication to applications. It happens to encapsulate a lot of the GSS complexity that will be the same for all applications. It also provides for mechanisms that are too weak to be GSS mechanisms. Applications should use SASL if they can live within its constraints. Except in some special cases mechanisms should be designed for GSS. >> 2) GSSAPI libraries are hard to deal with and multi-mechanism >> GSSAPI support is weak >> >> There is no requirement that you use a GSSAPI library or even >> the GSSAPI within your program to implement a SASL GSSAPI >> mechanism. You simply need to have a compatible wire encoding, >> but you can actually implement the mechanism the same as you >> would implement other SASL mechanisms if you find that an >> easier implementation choice. Keith> It is not really the same as other SASL mechanisms, because Keith> there is extra "baggage" included. A few extra bytes at the beginning of the context tokens doesn't seem unacceptable. >> Here's roughly what would need to happen to turn a SASL >> mechanism into a standards track GSSAPI mechanism >> >> 1) You need to use the GSSAPI initial context token format. >> this means you need to include an OID and a bit of header at >> the beginning of the authentication messages. Keith> It also means we have to deal with ASN.1: False. The GSSAPI spec defines the context token header both in terms of ASN.1 and in terms of raw bytes. It explicitly states that the raw bytes definition is authoritative. You could choose to use ASN.1 if you like, or you could just emit the context token header for your mechanism, listing it as raw bytes in your specification. >> 4) There may be some issues involving out-of-order delivery of >> messages you need to think about. Keith> In the authentication exchange or in the security layer? security layer. Keith> [1] Keith> http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt From owner-ietf-sasl Sat Apr 5 14:36:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MaiJM008904 for ; Sat, 5 Apr 2003 14:36:44 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35MaiT6008903 for ietf-sasl-bks; Sat, 5 Apr 2003 14:36:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MaeJM008899 for ; Sat, 5 Apr 2003 14:36:43 -0800 (PST) Received: from messagingdirect.com (1Cust241.tnt3.edmonton.ab.da.uu.net [64.10.184.241]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h35Me7V20082; Sat, 5 Apr 2003 15:40:07 -0700 Message-ID: <3E8F4EF3.3AB646CD@messagingdirect.com> Date: Sat, 05 Apr 2003 14:47:31 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism References: <20030404210846.43B16152124@konishi-polis.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Here's roughly what would need to happen to turn a SASL mechanism into > a standards track GSSAPI mechanism > > 1) You need to use the GSSAPI initial context token format. this > means you need to include an OID and a bit of header at the > beginning of the authentication messages. > > 2) You need to assign an OID to your mechanism. > > 3) You may need to think about name formats for principal names a bit. > > 4) There may be some issues involving out-of-order delivery of > messages you need to think about. > > 5) You should organize the document so it will be clear both to people > implementing as a SASL mechanism and as a GSSAPI mechanism. Sam, do you volunteer to write a paragraph that describes a binary representation for the GSSAPI header? If you (or somebody else) do this, we would be done with this discussion. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Sat Apr 5 14:36:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35ManJM008912 for ; Sat, 5 Apr 2003 14:36:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35ManJx008911 for ietf-sasl-bks; Sat, 5 Apr 2003 14:36:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MalJM008907 for ; Sat, 5 Apr 2003 14:36:47 -0800 (PST) Received: from messagingdirect.com (1Cust241.tnt3.edmonton.ab.da.uu.net [64.10.184.241]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h35MdEV20068; Sat, 5 Apr 2003 15:39:16 -0700 Message-ID: <3E8F4DEB.CF1E05C7@messagingdirect.com> Date: Sat, 05 Apr 2003 14:43:07 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: keith@rucus.ru.ac.za CC: SASL , Sam Hartman , raif@fl.net.au Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> <200304012041.28164.keith@rucus.ru.ac.za> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Burdis wrote: > Seriously, this looks to be a reasonable specification for usernames and > passwords. Is there any reason why all mechanisms shouldn't use at least this > set of restrictions? IMHO, all new mechanisms should use the same stringprep profile. > Why for example, would anonymous use a less restrictive > profile? This is required for backward compatibility, as ANONYMOUS allowed for arbitrary text to be passed. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Sat Apr 5 16:27:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h360RvJM012941 for ; Sat, 5 Apr 2003 16:27:57 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h360RvIE012940 for ietf-sasl-bks; Sat, 5 Apr 2003 16:27:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h360RuJM012928 for ; Sat, 5 Apr 2003 16:27:56 -0800 (PST) Received: from solomon (a3-p07.syd.fl.net.au [202.181.1.71]) by delenn.fl.net.au (Postfix) with ESMTP id AAA91180C2B; Sun, 6 Apr 2003 10:29:45 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: Sam Hartman Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Sun, 6 Apr 2003 10:23:33 +1000 User-Agent: KMail/1.4.3 Cc: SASL References: <200304012027.29229.raif@fl.net.au> <200304020833.47017.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Message-Id: <200304061023.35180.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h360RuJM012935 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Saturday 05 April 2003 07:11, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > > Raif> would a sequence of bytes preceded by their count (one > Raif> additional byte) be enough? > > I don't understand your question. For a sasl mechanism, I think > limiting authorization identifiers to 255 bytes would be overly > restrictive. > > For an application profile, sequence of bytes would be an > underspecified authorization identifier. the adoption of StringPrep, within the specifications of a SASL Mechanism, solves the question of required (canonical) transformations for authentication IDs (uersnames) and passwords. this is because as you pointed out --in your last email, and i totally overlooked-- these entities are acquired by the mechanism itself and hence are not within the scope of the Profile. the authorization ID on the other hand, is not acquired by the Mechanism; at least this is my understanding/interpretation of last para in section 4.1 of draft-myers-saslrev-02.txt, which echoes another para in section 3 of RFC-2222: "During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (frequently known as a userid) from the client to server, and negotiates the use of a mechanism-specific security layer." in other words, a Profile hands over an authorization ID (or a callback mechanism to receive it), which it (the Mechanism) then transmits to the peer. my question is on the encoding of this entity as seen by the Mechanism, at that interface point. draft-myers-saslrev-02, section 4.2 reflects discussions we had in this group about this token (authorization ID). it proposes: "An authorization identity is a string of zero or more ISO 10646 [ISO-10646] coded characters. The NULL (U+0000) character is not permitted in authorization identities." my question is about reaching a consensus on a choice and wording for how this entity is passed between the Mechanism and the Profile. if a string of iso-10646 w/o nulls is not an acceptable option would an octet sequence with a length octet be one. if neither are, what other alternatives are there. cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+j3OF+e1AKnsTRiERA0nqAKDWdJjXf9TMTF+NNIL1jkVROjmumQCgheOm 053vd60+E1B+ZZVebhXhhPo= =WWvx -----END PGP SIGNATURE----- From owner-ietf-sasl Mon Apr 7 10:39:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HdtJM019463 for ; Mon, 7 Apr 2003 10:39:55 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37HdtN6019462 for ietf-sasl-bks; Mon, 7 Apr 2003 10:39:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HdrJM019448 for ; Mon, 7 Apr 2003 10:39:54 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 97826152124; Mon, 7 Apr 2003 13:39:20 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> From: Sam Hartman Date: Mon, 07 Apr 2003 13:39:20 -0400 In-Reply-To: <3E89239B.1E03F4FE@messagingdirect.com> (Alexey Melnikov's message of "Mon, 31 Mar 2003 22:28:59 -0700") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 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> We have to be clear that for the protocols that use the Alexey> same format for authentication and authorization ids, Alexey> "authzid" is in UTF-8 and MUST NOT be converted to Alexey> ISO-8859-1 as username/password are. No, authz ID is in whatever format the application says it is. All the base spec seems to say is that it is a string. I would recommend replacing the text I complained about with something that says "The authorization identifier MUST NOT be converted to ISO 8859-1 by this mechanism even if the authentication identifier is converted for compatibility." >> The security discussion seems inadequate. Alexey> Suggestions? I specifically meant the security discussion of the QOP stuff, BTW. From owner-ietf-sasl Tue Apr 8 14:29:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LTbJM017915 for ; Tue, 8 Apr 2003 14:29:38 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38LTbkh017914 for ietf-sasl-bks; Tue, 8 Apr 2003 14:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LTaJM017909 for ; Tue, 8 Apr 2003 14:29:37 -0700 (PDT) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA10991 for ; Tue, 8 Apr 2003 15:29:39 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HD1000XDNNISK@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Tue, 08 Apr 2003 15:28:31 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HD1002CSNN9MZ@mail.sun.net> for ietf-sasl@imc.org; Tue, 08 Apr 2003 15:28:30 -0600 (MDT) Date: Tue, 08 Apr 2003 14:26:59 -0700 From: Chris Newman Subject: SASL API: should sasl_errdetail be human readable or deprecated? To: Alexey Melnikov , Rob Siemborski Cc: ietf-sasl@imc.org Message-id: <2147483647.1049812019@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When I added the sasl_errdetail call to the SASL API, my intent was that it would provide human readable strings intended for IMAP NO and POP -ERR style text response messages, and suitable for display to end-users. The current API spec is too imprecise about the purpose of that function: Given there is already a logging callback in the SASL API, I would argue that sasl_errdetail serves no purpose unless it is intended for end-user consumption. However, the CMU implementation generates cryptic error strings which are not suitable for end-user consumption and which leak security sensitive information (like the distinction between user not found and bad password). That leaves us a choice: 1. Clarify that sasl_errdetail is intended to return error strings suitable to be passed back over protocol and presented to an end-user. This would require clarification to the spec and some changes to the CMU implementation. I am willing to propose the code changes to CMU if there is consensus for this option. 2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error codes as the only way to determine what text messages to pass back to the end-user. Use the logging callback for all detailed error logging. I propose option 1 as the correct choice. My theory is that attempting to enumerate all errors which require different behaviors on the client side is a tractable problem, but attempting to enumerate all errors which are useful to inform the user is not a tractable problem and thus a text string to pass back to the user is important. If there are no objections, I will propose changes to the API spec to Alexey and changes to the CMU implementation to Rob. - Chris From owner-ietf-sasl Tue Apr 8 20:03:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3933fJM004337 for ; Tue, 8 Apr 2003 20:03:41 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3933fdO004336 for ietf-sasl-bks; Tue, 8 Apr 2003 20:03:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3933bJM004332 for ; Tue, 8 Apr 2003 20:03:40 -0700 (PDT) Received: from messagingdirect.com (1Cust234.tnt3.edmonton.ab.da.uu.net [64.10.184.234]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h39370V20454; Tue, 8 Apr 2003 21:07:00 -0600 Message-ID: <3E938D1C.6831BAB1@messagingdirect.com> Date: Tue, 08 Apr 2003 21:01:48 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > >>>>> "Alexey" == Alexey Melnikov writes: > > Alexey> We have to be clear that for the protocols that use the > Alexey> same format for authentication and authorization ids, > Alexey> "authzid" is in UTF-8 and MUST NOT be converted to > Alexey> ISO-8859-1 as username/password are. > > No, authz ID is in whatever format the application says it is. All > the base spec seems to say is that it is a string. > > I would recommend replacing the text I complained about with something > that says "The authorization identifier MUST NOT be converted to ISO > 8859-1 by this mechanism even if the authentication identifier is > converted for compatibility." Ok, I've mostly fixed this. The new text in 2.1.2 looks like: authzid The "authorization ID" directive is optional. If present, and the authenticating user has sufficient privilege, and the server supports it, then after authentication the server will use this identity for making all accesses and access checks. If the client specifies it, and the server does not support it, then the response-value calculated on the server will not match the one calculated on the client and authentication will fail. The authorization identifier MUST NOT be converted to ISO 8859-1 even if the authentication identifier ("username") is converted for compatibility as directed by "charset" directive. The server SHOULD verify the correctness of an authzid. For example, an IMAP [RFC 3501] server will prepare the received authzid using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If preparation of the authzid fails or results in an empty string, the server MUST fail the authentication exchange. === I am not sure whether the last paragraph belongs to this document, or whether it should be moved to the SASL document or profile documents. Personally, I would hate to update each profile document with this text. > >> The security discussion seems inadequate. > > Alexey> Suggestions? > > I specifically meant the security discussion of the QOP stuff, BTW. >>3.6 Man in the Middle ... >>A possible man-in-the-middle attack would be to substitute a weaker qop >>scheme for the one(s) sent by the server; the server will not be able to >>detect this attack. For this reason, the client should always use the >>strongest scheme that it understands from the choices offered, and >>should never choose a scheme that does not meet its minimum >>requirements. Can you suggest any specific changes to this text? Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Wed Apr 9 12:25:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JP2JM016264 for ; Wed, 9 Apr 2003 12:25:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39JP2Qn016263 for ietf-sasl-bks; Wed, 9 Apr 2003 12:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-ONE-NINETY-SEVEN.MIT.EDU [18.187.5.197]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JOxJM016251 for ; Wed, 9 Apr 2003 12:24:59 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 73D4E15226A; Wed, 9 Apr 2003 15:25:01 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 From: Sam Hartman Date: Wed, 09 Apr 2003 15:25:01 -0400 In-Reply-To: <3E938D1C.6831BAB1@messagingdirect.com> (Alexey Melnikov's message of "Tue, 08 Apr 2003 21:01:48 -0600") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> <3E938D1C.6831BAB1@messagingdirect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> === I am not sure whether the last paragraph belongs to Alexey> this document, or whether it should be moved to the SASL Alexey> document or profile documents. Personally, I would hate Alexey> to update each profile document with this text. I think that this goes in the base spec. I'll think about text for the man-in-the-middle case. I'm not really sure what we want to happen. We could recommend that people always mandate integrity protection or confidentiality, but doing so would create interoperability problems. We could recommend that people not use digest-md5, but we should have something to recommend instead. From owner-ietf-sasl Thu Apr 10 11:23:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AINKJM001362 for ; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AINKBQ001361 for ietf-sasl-bks; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tintagel-int.labs.agilent.com (tintagel-ext.labs.agilent.com [192.25.140.108]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AINJJM001357 for ; Thu, 10 Apr 2003 11:23:19 -0700 (PDT) Received: from unicorn.labs.agilent.com (root@unicorn.labs.agilent.com [130.29.252.5]) by tintagel-int.labs.agilent.com (8.12.9/8.12.9/Tintagel Sendmail Config v01.02 2002/10/28) with ESMTP id h3AINLDO015095; Thu, 10 Apr 2003 11:23:21 -0700 (PDT) Received: from alex1.labs.agilent.com (alex1.labs.agilent.com [130.29.252.55]) by unicorn.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3AINKoR021621; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) Received: from 130.29.252.18 by alex1.labs.agilent.com (InterScan E-Mail VirusWall NT); Thu, 10 Apr 2003 11:23:20 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3AINGIT027770; Thu, 10 Apr 2003 11:23:16 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Apr 2003 11:23:16 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Cc: paulle@microsoft.com, chris.newman@INNOSOFT.COM Subject: Comments on 2831 Confidentiality Protection Date: Thu, 10 Apr 2003 11:23:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5" X-Spam-Status: No, hits=-97.7 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF8E.406176BE" ------_=_NextPart_001_01C2FF8E.406176BE Content-Type: text/plain; charset="iso-8859-1" I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC. This requires decryption of the entire message before authentication can be done. RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding. One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done (another form of denial of protection against denial of service, replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406. This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies. See section 2 of the rfc2406. I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406. For purposes of rfc2831, the SPI and next header fields could be defined as zeros. As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection. If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client. -- Glenn glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066 ------_=_NextPart_001_01C2FF8E.406176BE Content-Type: text/html; charset="iso-8859-1"
I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC.   This requires decryption of the entire message before authentication can be done.
 
RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding.  One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done  (another form of denial of protection against denial of service,  replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406.  This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies.  See section 2 of the rfc2406.
 
I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406.  For purposes of rfc2831, the SPI and next header fields could be defined as zeros. 
 
As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection.  If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client.

--
Glenn

glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066

 
------_=_NextPart_001_01C2FF8E.406176BE-- ------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5-- From owner-ietf-sasl Thu Apr 10 12:15:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJFWJM003861 for ; Thu, 10 Apr 2003 12:15:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AJFVLK003859 for ietf-sasl-bks; Thu, 10 Apr 2003 12:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJFQJM003840 for ; Thu, 10 Apr 2003 12:15:26 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA13677 for ; Thu, 10 Apr 2003 13:15:28 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HD500EWG6TR67@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Thu, 10 Apr 2003 13:15:28 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HD5009SP6TOW6@mail.sun.net> for ietf-sasl@imc.org; Thu, 10 Apr 2003 13:15:27 -0600 (MDT) Date: Thu, 10 Apr 2003 12:13:59 -0700 From: Chris Newman Subject: Re: Comments on 2831 Confidentiality Protection In-reply-to: To: glenn_engel@agilent.com Cc: ietf-sasl@imc.org, paulle@microsoft.com Message-id: <2147483647.1049976839@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The correct time to make this comment was prior to the publication of RFC 2831 -- that's the purpose of the last call period. While consistency across the Internet suite is aesthetically attractive and I would have supported this proposal prior to the publication and deployment of RFC 2831, I must oppose this proposal now. There are a number of deployed implementations of RFC 2831, so backwards compatibility and interoperability with the running code would trump the majority of aesthetic and minor technical points. Now if it were determined that the way RC4 is specified in RFC 2831 has a fatal security flaw and can not be fixed without breaking interoperability, then your proposal would merit consideration. But I have yet to hear such a determination. - Chris begin quotation by glenn_engel@agilent.com on 2003/4/10 11:23 -0700: > > I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes > the cipher of the message as well as a catenated HMAC. This requires > decryption of the entire message before authentication can be done. > RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical > encoding. One notable difference is that ESP defines the HMAC to be done on > the encrypted contents so that the message can be authenticated without the > potentially costly cipher being done (another form of denial of protection > against denial of service, replay or man in the middle attacks). Since the > form of the message is so close to ESP, I would suggest utilizing the exact > packet format as defined in RFC2406. This RFC includes the sequence number, > padding, authentication and encryption techniques to assemble a packet with > only slight differences to what 2831 specifies. See section 2 of the > rfc2406. > I would suggest specifying that the Confidentiality Protection for rfc2831 > payload be constructed as described in RFC2406. For purposes of rfc2831, the > SPI and next header fields could be defined as zeros. > As an enhancement consider the following - sInce rfc2831 is connection > oriented the SPI used in ESP/IPSEC is 'implied' by the connection. If UDP > was instead used as the communication medium then the rfc2831 dialog could > still be done pretty much as defined with the addition of an SPI argument > returned to the client. > > -- > Glenn > > glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066 > From owner-ietf-sasl Fri Apr 11 09:42:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGgrJM004773 for ; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BGgrqF004772 for ietf-sasl-bks; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tintagel-int.labs.agilent.com (tintagel-ext.labs.agilent.com [192.25.140.108]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGgpJM004768 for ; Fri, 11 Apr 2003 09:42:52 -0700 (PDT) Received: from thing1.labs.agilent.com (thing1.labs.agilent.com [130.29.252.18]) by tintagel-int.labs.agilent.com (8.12.9/8.12.9/Tintagel Sendmail Config v01.02 2002/10/28) with ESMTP id h3BGgrDO024851 for ; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) Received: from alexbh1.labs.agilent.com (alexbh1.labs.agilent.com [130.29.252.76]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3BGgrhF029857 for ; Fri, 11 Apr 2003 09:42:53 -0700 Received: from 130.29.252.18 by alexbh1.labs.agilent.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 09:42:52 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3BGgpIT029852 for ; Fri, 11 Apr 2003 09:42:51 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Apr 2003 09:42:51 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Subject: RE: Comments on 2831 Confidentiality Protection Date: Fri, 11 Apr 2003 09:42:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-97.7 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The correct time to make this comment was prior to the > publication of RFC 2831 > -- that's the purpose of the last call period. I just stumbled across the rfc Wednesday. When was the last call ? It "would have been" nice to utilize ESP encoding as it addresses other encryption/auth algorithms and would provide a framework for re-using existing IPSEC code in conjunction with SASL. A new draft of ESP includes policy on how to deal with high speed connections where the sequence number can roll over as well as providing protection from traffic flow analysis. By combining the simplicity of Digest Authentication in 2831 and it's nice way of defining keys with ESP a really nice combination would result. -- Glenn From owner-ietf-sasl Fri Apr 11 13:37:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKbrJM017019 for ; Fri, 11 Apr 2003 13:37:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKbr2Y017017 for ietf-sasl-bks; Fri, 11 Apr 2003 13:37:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BKbqJM017010 for ; Fri, 11 Apr 2003 13:37:52 -0700 (PDT) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3BKbeBT033852; Fri, 11 Apr 2003 20:37:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030411133224.02b59958@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Apr 2003 13:35:16 -0700 To: glenn_engel@agilent.com From: "Kurt D. Zeilenga" Subject: RE: Comments on 2831 Confidentiality Protection Cc: ietf-sasl@imc.org In-Reply-To: Mime-Version: 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:42 AM 4/11/2003, glenn_engel@agilent.com wrote: >> The correct time to make this comment was prior to the >> publication of RFC 2831 >> -- that's the purpose of the last call period. > >I just stumbled across the rfc Wednesday. When was the last call ? December 1998. >It "would have been" nice Lot's of things "would have been" nice. We need to focus on resolving clear technical errors and omissions. Kurt From owner-ietf-sasl Fri Apr 11 15:07:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM79JM021765 for ; Fri, 11 Apr 2003 15:07:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BM79XU021764 for ietf-sasl-bks; Fri, 11 Apr 2003 15:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tripod-int.labs.agilent.com (tripod-ext.labs.agilent.com [192.25.140.133]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM78JM021742 for ; Fri, 11 Apr 2003 15:07:08 -0700 (PDT) Received: from thing1.labs.agilent.com (thing1.labs.agilent.com [130.29.252.18]) by tripod-int.labs.agilent.com (8.12.9/8.12.9/Tripod Sendmail Config v01.02 2002/09/24) with ESMTP id h3BM76Dn006688 for ; Fri, 11 Apr 2003 15:07:06 -0700 Received: from alexbh1.labs.agilent.com (alexbh1.labs.agilent.com [130.29.252.76]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3BM76hF005418 for ; Fri, 11 Apr 2003 15:07:06 -0700 Received: from 130.29.252.18 by alexbh1.labs.agilent.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 15:07:06 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3BM75IT005413 for ; Fri, 11 Apr 2003 15:07:05 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Apr 2003 15:07:05 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Subject: RE: Comments on 2831 Confidentiality Protection Date: Fri, 11 Apr 2003 15:07:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-98.5 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >From the information on the SASL website it appears to me that 2831 is currently 'under revision', hence my suggestion to allow use of ESP as an option for encoding the integrity and confidentiality protection. This could easily be done by simply specifying an 'encoding' field in much the same way the ciper is specified. If the intent is to only 'tweak' technical errors then this suggestion is clearly too late. -- Glenn > > > >I just stumbled across the rfc Wednesday. When was the last call ? > > December 1998. > > >It "would have been" nice > > Lot's of things "would have been" nice. > > We need to focus on resolving clear technical errors and omissions. > > Kurt > From owner-ietf-sasl Fri Apr 11 15:40:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BMebJM023943 for ; Fri, 11 Apr 2003 15:40:37 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BMebS2023941 for ietf-sasl-bks; Fri, 11 Apr 2003 15:40:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BMeZJM023932 for ; Fri, 11 Apr 2003 15:40:35 -0700 (PDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 15:40:33 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 15:40:33 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 15:40:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 11 Apr 2003 15:40:32 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 11 Apr 2003 15:40:31 -0700 Content-class: urn:content-classes:message Subject: RE: Comments on draft-ietf-sasl-rfc2831 MIME-Version: 1.0 Date: Fri, 11 Apr 2003 15:40:30 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0043_01C30040.AFC2EC00" x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24601D74AE5@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sasl-rfc2831 Thread-Index: AcL+z3x2CJTiX9IXRpK6xuaWMZyG8ABq3EIA From: "Paul Leach" To: "Sam Hartman" , "Alexey Melnikov" Cc: X-OriginalArrivalTime: 11 Apr 2003 22:40:31.0929 (UTC) FILETIME=[5BE61A90:01C3007B] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C30040.AFC2EC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > -----Original Message----- > From: Sam Hartman [mailto:hartmans@mit.edu] > Sent: Wednesday, April 09, 2003 12:25 PM > To: Alexey Melnikov > Cc: ietf-sasl@imc.org > > > >>>>> "Alexey" == Alexey Melnikov writes: > > > Alexey> === I am not sure whether the last paragraph belongs to > Alexey> this document, or whether it should be moved to the SASL > Alexey> document or profile documents. Personally, I would hate > Alexey> to update each profile document with this text. > > I think that this goes in the base spec. > > > I'll think about text for the man-in-the-middle case. I'm > not really sure what we want to happen. > > We could recommend that people always mandate integrity > protection or confidentiality, but doing so would create > interoperability problems. That's not necessary, as long as both sides only offer or agree to mechanisms that meet their minimum security requirements. I.e., it's not great but not fatal that they don't always agree on the strongest mechanism. Also, using integrity protection on confidentiality does nothing to prevent attacks on QOP, cipher, etc, negotiations. > We could recommend that people not use digest-md5, but we > should have something to recommend instead. > > > ------=_NextPart_000_0043_01C30040.AFC2EC00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIfBjCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBqgwggYRoAMCAQICCi/4jlMA AwApwngwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzAzMTcwMjM4MDla Fw0wMzA2MTUwMjM4MDlaMIGwMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAw DgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENP LUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPO0jr4T GEQuhd6kZ6+6RFJwBhlrERosBDFI0IpHP5k2x7uvLMUZ8o2dLXBsaxcrzEpLfgcSrjiSxnQIYebX 6GY6M31yVsQyXEmfE9T6Sb267pWodlk6+CT0zLJUQqhfeCmyRzy4CiewZ9OpUlcSJ6OGhh4MUmf9 BWAEl16XxUynAgMBAAGjggQrMIIEJzALBgNVHQ8EBAMCB4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYB BAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEAMBMGA1UdJQQMMAoGCCsG AQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phUBgxEwGwYJ KwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1 bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYD VR0OBBYEFClvOqLgDYyfVFb03pkX9/+ozfe3MB8GA1UdIwQYMBaAFIvRzWHx6a+OvJHQQOopv+Yu hUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5UREVWJTIwSVNT VUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0 LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20v TlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hpY2EzLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js MIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPU5UREVWJTIw SVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgGCCsG AQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQSgzKS5j cnQwDQYJKoZIhvcNAQEFBQADgYEAj2sQspSCtU9oLSVBt8cePl0PksH/VXzh85ZqgGieyX6llEXI shmc282W8pmGQ7kChlHXuX1GUHo9PSzyIBjEdA7h833Q/HAUopllZl9DBE2PM21HLOdWOAgE3rrJ s8J9eP1hSzQ4+lQ3Ktsqmo+orYjmfYHhBOw2a7ATAiTvXrgwggbsMIIGVaADAgECAgoghY36AAMA KY7OMA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAM BgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDMwMzE0MDIzODAwWhcN MDMwNTEzMDIzODAwWjCB3TETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1p Y3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4G A1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1F MRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxwYXVsbGVAd2luZG93cy5taWNy b3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw4jrEUKMenSEIizizwXBDjmPa 2YuncW6v0L7D2cydmDRhHWnv9HhYezSCNvqfSg5z32frXyEvKcyDqf2i49kExeznnCthZQ7Ihgs5 XfgZOrr5S2Tzh1a/bdP3/ueCVw7p3M05jfnWXkWyRXXN5ZBaC8bJ4FDbJzvnqVTB1oKMFwIDAQAB o4IEQjCCBD4wCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEE AYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXgCAQAwEwYDVR0lBAwwCgYIKwYB BQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcU AgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29m dC5jb20wHQYDVR0OBBYEFKFuZsO/Y52+l/VSj1QxtebBveYxMB8GA1UdIwQYMBaAFIvRzWHx6a+O vJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5U REVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jv c29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hp Y2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIw Q0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NO PU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQs REM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D ZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMl MjBDQSgzKS5jcnQwDQYJKoZIhvcNAQEFBQADgYEAimqAfBILFHTqZpjy06cpweXt7vsYelrmHCCq KGBnEtiEAEWQfuoEb7FhlaaduDnfJhelzqTj1pOqMIGjgnhRBAIcF+8JvdjU3pgHkaG8bcNFh3xn yXDWrr2JK3LJmIjLC6Mwpn+bzjyAmEC4BMMp0vDnBMON9km1qo4mQ35EKGswgggbMIIHA6ADAgEC AgooxudyAAEAAAA1MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAyMTAx MDE2MzMwMFoXDTA1MTAxMDE2NDMwMFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m dDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0 ZSBXaGljYTIwggG3MIIBKwYHKoZIzjgEATCCAR4CgYEA+hLPe7uYsHmuGUfkITkBqWsGXo22y369 ks09E+EjwAGs24cphaVHqFZ3+KQ/kgyANCvsNSkmut2/hnZPWkk9UQcjEK5rcdNf+j5dUZNld0G/ jH46Ecua3XUpxPL0H7S2mDemwkLib61o41pt37LD8QH0Cg+V0Z0egYEFIY50AuMCFQCYT5Q9snVa 1ekUrZTCYzob/OjrQwKBgGbKD33vFBA+cKvgitrGpSLmxdey9I++KbA79QQXEnACJZLw5S6e+eHs Z3T+xwPlg2RUCxtFgX5c2DJhUKxi6wLUsfwO+g7OrgfPyWD0r/aQDzS/ZKSvgMfUQUzYkbcn0dur frYOT2LxXocBkQD8/yQH38n5wjUuheVa1/Dm5oKYA4GFAAKBgQCiStJWJMhC3tkbRi2OvYYtxyrl tPMOyZR1E5DPWqL15vlw4hhrZheATpyZlMggU4vHps92BvBlICw58FCh9Cgsbe8l5BwawD++PvDO ObOVoiZiwEX05lEUqXsLev9MtKEdcFNAejXrNwIa4sJeFC86yuMmGUq+G9Hl8yY2k4riOaOCBFMw ggRPMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOK+A3DViyDSQURqr+bId3FaJQAfMAsGA1Ud DwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDBAAFMCMGCSsGAQQBgjcVAgQWBBTWUig3WSHjbYXiEmot Y22qaLxrQDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBSIyc2cnDoigOrk LdoVRy/1+8S8mzCCAZkGA1UdHwSCAZAwggGMMIIBiKCCAYSgggGAhoHZbGRhcDovLy9DTj1OVERF ViUyMFNBJTIwUm9vdCUyMENBKDEpLENOPXdoaWNhc2Fyb290Y2EsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZRaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3Js hk9odHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW JTIwU0ElMjBSb290JTIwQ0EoMSkuY3JsMIIB6QYIKwYBBQUHAQEEggHbMIIB1zCByAYIKwYBBQUH MAKGgbtsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGEBggrBgEFBQcwAoZ4aHR0cDovL3doaWNhd2ViLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5t aWNyb3NvZnQuY29tX05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3J0MIGCBggrBgEFBQcwAoZ2 aHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQEFBQADggEBADTCZCUZvE/CF5YX7SiP y/WGMFtXXeCYEr/Y7LSrY5yAL+j4ZKQor7lLfrE7FO9UgGKjfs+LqO0kjxad47041wtArk0e5RXe P0UW0IzZOctur84ke76sqtggFFgCOffLqhY9plCcfVSDpBrngAISXVuhx8oEzptU2UkqcH5ZGmfB vgytdCKe+vStiuVgf5nvEQIej5on2qentxdfMQsXntj2oEFupjmR6J9YV9f43GEWlGuDC1Lou10g 84idAsbaQ+hjxBp8e9NIGPgi5LF1o353R32fU4Oc3ggpGFFiJVKnA/tqgusrcV6ViN0sQftdALar 5PjV25iA2FaXQOR/bpcxggKfMIICmwIBATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCi/4jlMAAwAp wngwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMwNDExMjI0MDMyWjAjBgkqhkiG9w0BCQQxFgQUPK1a7kcKBxBQ6VRH7XEGfCtku/EwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAE MVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEY MBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgoghY36AAMAKY7OMGoGCyqGSIb3DQEJEAILMVugWTBL MQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UE AxMPTlRERVYgSVNTVUUzIENBAgoghY36AAMAKY7OMA0GCSqGSIb3DQEBAQUABIGAYsCIfYl50CGA Dh+piAIsPVedj4M6dP3L0cu7cg8lVreO0yoCW9HTTPvf+SLPgVHRqS7hDLnZADrScCVAxNArHSqI 5vMgAzY0muVi/73rFhoxGfpzCJeN5c9K3xJ4twdlPmmzsKkLlX7Aa6xISu9H+aqJk6K4j3yHSI8B BSGaD+sAAAAAAAA= ------=_NextPart_000_0043_01C30040.AFC2EC00-- From owner-ietf-sasl Mon Apr 14 15:03:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EM3UbP081569 for ; Mon, 14 Apr 2003 15:03:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EM3Ugr081568 for ietf-sasl-bks; Mon, 14 Apr 2003 15:03:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EM3TbP081560 for ; Mon, 14 Apr 2003 15:03:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E772515226A; Mon, 14 Apr 2003 18:03:14 -0400 (EDT) To: glenn_engel@agilent.com Cc: ietf-sasl@imc.org Subject: Re: Comments on 2831 Confidentiality Protection From: Sam Hartman Date: Mon, 14 Apr 2003 18:03:14 -0400 In-Reply-To: (glenn engel's message of "Fri, 11 Apr 2003 15:07:05 -0700") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) 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: >>>>> "glenn" == glenn engel writes: glenn> From the information on the SASL website it appears to me glenn> that 2831 is currently 'under revision', hence my glenn> suggestion to allow use of ESP as an option for encoding glenn> the integrity and confidentiality protection. This could glenn> easily be done by simply specifying an 'encoding' field in glenn> much the same way the ciper is specified. If the intent is glenn> to only 'tweak' technical errors then this suggestion is glenn> clearly too late. The intent is certainly to avoid breaking backward compatibility. Chris's comments suggest that introducing a different encoding for newer ciphers would be unpopular, presumably because it would introduce implementation complexity and increase the complexity of the spec. So, yes, it looks like people believe this change is not worth making, although they agree in an ideal world reuse of technology would be good. From owner-ietf-sasl Sun Apr 20 00:54:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7sat2051871 for ; Sun, 20 Apr 2003 00:54:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K7saGp051870 for ietf-sasl-bks; Sun, 20 Apr 2003 00:54:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7sTt2051839 for ; Sun, 20 Apr 2003 00:54:35 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust115.tnt3.edmonton.ab.da.uu.net [64.10.184.115]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K7v7V30041; Sun, 20 Apr 2003 01:57:08 -0600 Message-ID: <3EA23A5A.B6516BED@messagingdirect.com> Date: Sun, 20 Apr 2003 00:12:43 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Newman CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: SASL API: should sasl_errdetail be human readable or deprecated? References: <2147483647.1049812019@nifty-jr.west.sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris Newman wrote: > When I added the sasl_errdetail call to the SASL API, my intent was that it > would provide human readable strings intended for IMAP NO and POP -ERR style > text response messages, and suitable for display to end-users. > > The current API spec is too imprecise about the purpose of that function: > > > Given there is already a logging callback in the SASL API, I would argue that > sasl_errdetail serves no purpose unless it is intended for end-user > consumption. However, the CMU implementation generates cryptic error strings > which are not suitable for end-user consumption and which leak security > sensitive information (like the distinction between user not found and bad > password). > > That leaves us a choice: > > 1. Clarify that sasl_errdetail is intended to return error strings suitable to > be passed back over protocol and presented to an end-user. This would require > clarification to the spec and some changes to the CMU implementation. I am > willing to propose the code changes to CMU if there is consensus for this > option. > > 2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error > codes as the only way to determine what text messages to pass back to the > end-user. Use the logging callback for all detailed error logging. > > I propose option 1 as the correct choice. My theory is that attempting to > enumerate all errors which require different behaviors on the client side is a > tractable problem, but attempting to enumerate all errors which are useful to > inform the user is not a tractable problem and thus a text string to pass back > to the user is important. > > If there are no objections, I will propose changes to the API spec to Alexey > and changes to the CMU implementation to Rob. I agree with this proposal (and just finished updating the document). Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Wed Apr 23 16:11:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NNBOt2044745 for ; Wed, 23 Apr 2003 16:11:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NNBOrU044744 for ietf-sasl-bks; Wed, 23 Apr 2003 16:11:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NNBNt2044739 for ; Wed, 23 Apr 2003 16:11:23 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost4 [127.0.0.1]) by orthanc.ab.ca (8.12.6p2/8.12.6) with ESMTP id h3NNBPGS053722 for ; Wed, 23 Apr 2003 17:11:25 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200304232311.h3NNBPGS053722@orthanc.ab.ca> From: Lyndon Nerenberg {VE6BBM} To: ietf-sasl@imc.org Subject: CRAM-MD5 implementation limits for Organization: The Frobozz Magic Homing Pigeon Company X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Apr 2003 17:11:25 -0600 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Plain draft specifies that implementations must support at least 255 octets for the and elements. Should we do the same for in CRAM-MD5? --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NNBOt2044745 for ; Wed, 23 Apr 2003 16:11:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NNBOrU044744 for ietf-sasl-bks; Wed, 23 Apr 2003 16:11:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NNBNt2044739 for ; Wed, 23 Apr 2003 16:11:23 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost4 [127.0.0.1]) by orthanc.ab.ca (8.12.6p2/8.12.6) with ESMTP id h3NNBPGS053722 for ; Wed, 23 Apr 2003 17:11:25 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200304232311.h3NNBPGS053722@orthanc.ab.ca> From: Lyndon Nerenberg {VE6BBM} To: ietf-sasl@imc.org Subject: CRAM-MD5 implementation limits for Organization: The Frobozz Magic Homing Pigeon Company X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Apr 2003 17:11:25 -0600 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Plain draft specifies that implementations must support at least 255 octets for the and elements. Should we do the same for in CRAM-MD5? --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7sat2051871 for ; Sun, 20 Apr 2003 00:54:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K7saGp051870 for ietf-sasl-bks; Sun, 20 Apr 2003 00:54:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K7sTt2051839 for ; Sun, 20 Apr 2003 00:54:35 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust115.tnt3.edmonton.ab.da.uu.net [64.10.184.115]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K7v7V30041; Sun, 20 Apr 2003 01:57:08 -0600 Message-ID: <3EA23A5A.B6516BED@messagingdirect.com> Date: Sun, 20 Apr 2003 00:12:43 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Newman CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: SASL API: should sasl_errdetail be human readable or deprecated? References: <2147483647.1049812019@nifty-jr.west.sun.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris Newman wrote: > When I added the sasl_errdetail call to the SASL API, my intent was that it > would provide human readable strings intended for IMAP NO and POP -ERR style > text response messages, and suitable for display to end-users. > > The current API spec is too imprecise about the purpose of that function: > > > Given there is already a logging callback in the SASL API, I would argue that > sasl_errdetail serves no purpose unless it is intended for end-user > consumption. However, the CMU implementation generates cryptic error strings > which are not suitable for end-user consumption and which leak security > sensitive information (like the distinction between user not found and bad > password). > > That leaves us a choice: > > 1. Clarify that sasl_errdetail is intended to return error strings suitable to > be passed back over protocol and presented to an end-user. This would require > clarification to the spec and some changes to the CMU implementation. I am > willing to propose the code changes to CMU if there is consensus for this > option. > > 2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error > codes as the only way to determine what text messages to pass back to the > end-user. Use the logging callback for all detailed error logging. > > I propose option 1 as the correct choice. My theory is that attempting to > enumerate all errors which require different behaviors on the client side is a > tractable problem, but attempting to enumerate all errors which are useful to > inform the user is not a tractable problem and thus a text string to pass back > to the user is important. > > If there are no objections, I will propose changes to the API spec to Alexey > and changes to the CMU implementation to Rob. I agree with this proposal (and just finished updating the document). Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EM3UbP081569 for ; Mon, 14 Apr 2003 15:03:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EM3Ugr081568 for ietf-sasl-bks; Mon, 14 Apr 2003 15:03:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EM3TbP081560 for ; Mon, 14 Apr 2003 15:03:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E772515226A; Mon, 14 Apr 2003 18:03:14 -0400 (EDT) To: glenn_engel@agilent.com Cc: ietf-sasl@imc.org Subject: Re: Comments on 2831 Confidentiality Protection From: Sam Hartman Date: Mon, 14 Apr 2003 18:03:14 -0400 In-Reply-To: (glenn engel's message of "Fri, 11 Apr 2003 15:07:05 -0700") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) 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: >>>>> "glenn" == glenn engel writes: glenn> From the information on the SASL website it appears to me glenn> that 2831 is currently 'under revision', hence my glenn> suggestion to allow use of ESP as an option for encoding glenn> the integrity and confidentiality protection. This could glenn> easily be done by simply specifying an 'encoding' field in glenn> much the same way the ciper is specified. If the intent is glenn> to only 'tweak' technical errors then this suggestion is glenn> clearly too late. The intent is certainly to avoid breaking backward compatibility. Chris's comments suggest that introducing a different encoding for newer ciphers would be unpopular, presumably because it would introduce implementation complexity and increase the complexity of the spec. So, yes, it looks like people believe this change is not worth making, although they agree in an ideal world reuse of technology would be good. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BMebJM023943 for ; Fri, 11 Apr 2003 15:40:37 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BMebS2023941 for ietf-sasl-bks; Fri, 11 Apr 2003 15:40:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BMeZJM023932 for ; Fri, 11 Apr 2003 15:40:35 -0700 (PDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 15:40:33 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 15:40:33 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 15:40:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 11 Apr 2003 15:40:32 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 11 Apr 2003 15:40:31 -0700 Content-class: urn:content-classes:message Subject: RE: Comments on draft-ietf-sasl-rfc2831 MIME-Version: 1.0 Date: Fri, 11 Apr 2003 15:40:30 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0043_01C30040.AFC2EC00" x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24601D74AE5@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sasl-rfc2831 Thread-Index: AcL+z3x2CJTiX9IXRpK6xuaWMZyG8ABq3EIA From: "Paul Leach" To: "Sam Hartman" , "Alexey Melnikov" Cc: X-OriginalArrivalTime: 11 Apr 2003 22:40:31.0929 (UTC) FILETIME=[5BE61A90:01C3007B] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C30040.AFC2EC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > -----Original Message----- > From: Sam Hartman [mailto:hartmans@mit.edu] > Sent: Wednesday, April 09, 2003 12:25 PM > To: Alexey Melnikov > Cc: ietf-sasl@imc.org > > > >>>>> "Alexey" == Alexey Melnikov writes: > > > Alexey> === I am not sure whether the last paragraph belongs to > Alexey> this document, or whether it should be moved to the SASL > Alexey> document or profile documents. Personally, I would hate > Alexey> to update each profile document with this text. > > I think that this goes in the base spec. > > > I'll think about text for the man-in-the-middle case. I'm > not really sure what we want to happen. > > We could recommend that people always mandate integrity > protection or confidentiality, but doing so would create > interoperability problems. That's not necessary, as long as both sides only offer or agree to mechanisms that meet their minimum security requirements. I.e., it's not great but not fatal that they don't always agree on the strongest mechanism. Also, using integrity protection on confidentiality does nothing to prevent attacks on QOP, cipher, etc, negotiations. > We could recommend that people not use digest-md5, but we > should have something to recommend instead. > > > ------=_NextPart_000_0043_01C30040.AFC2EC00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIfBjCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBqgwggYRoAMCAQICCi/4jlMA AwApwngwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzAzMTcwMjM4MDla Fw0wMzA2MTUwMjM4MDlaMIGwMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAw DgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENP LUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPO0jr4T GEQuhd6kZ6+6RFJwBhlrERosBDFI0IpHP5k2x7uvLMUZ8o2dLXBsaxcrzEpLfgcSrjiSxnQIYebX 6GY6M31yVsQyXEmfE9T6Sb267pWodlk6+CT0zLJUQqhfeCmyRzy4CiewZ9OpUlcSJ6OGhh4MUmf9 BWAEl16XxUynAgMBAAGjggQrMIIEJzALBgNVHQ8EBAMCB4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYB BAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEAMBMGA1UdJQQMMAoGCCsG AQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phUBgxEwGwYJ KwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1 bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYD VR0OBBYEFClvOqLgDYyfVFb03pkX9/+ozfe3MB8GA1UdIwQYMBaAFIvRzWHx6a+OvJHQQOopv+Yu hUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5UREVWJTIwSVNT VUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0 LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20v TlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hpY2EzLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js MIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPU5UREVWJTIw SVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgGCCsG AQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQSgzKS5j cnQwDQYJKoZIhvcNAQEFBQADgYEAj2sQspSCtU9oLSVBt8cePl0PksH/VXzh85ZqgGieyX6llEXI shmc282W8pmGQ7kChlHXuX1GUHo9PSzyIBjEdA7h833Q/HAUopllZl9DBE2PM21HLOdWOAgE3rrJ s8J9eP1hSzQ4+lQ3Ktsqmo+orYjmfYHhBOw2a7ATAiTvXrgwggbsMIIGVaADAgECAgoghY36AAMA KY7OMA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAM BgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDMwMzE0MDIzODAwWhcN MDMwNTEzMDIzODAwWjCB3TETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1p Y3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4G A1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1F MRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxwYXVsbGVAd2luZG93cy5taWNy b3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw4jrEUKMenSEIizizwXBDjmPa 2YuncW6v0L7D2cydmDRhHWnv9HhYezSCNvqfSg5z32frXyEvKcyDqf2i49kExeznnCthZQ7Ihgs5 XfgZOrr5S2Tzh1a/bdP3/ueCVw7p3M05jfnWXkWyRXXN5ZBaC8bJ4FDbJzvnqVTB1oKMFwIDAQAB o4IEQjCCBD4wCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEE AYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXgCAQAwEwYDVR0lBAwwCgYIKwYB BQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcU AgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29m dC5jb20wHQYDVR0OBBYEFKFuZsO/Y52+l/VSj1QxtebBveYxMB8GA1UdIwQYMBaAFIvRzWHx6a+O vJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5U REVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jv c29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hp Y2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIw Q0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NO PU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQs REM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D ZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMl MjBDQSgzKS5jcnQwDQYJKoZIhvcNAQEFBQADgYEAimqAfBILFHTqZpjy06cpweXt7vsYelrmHCCq KGBnEtiEAEWQfuoEb7FhlaaduDnfJhelzqTj1pOqMIGjgnhRBAIcF+8JvdjU3pgHkaG8bcNFh3xn yXDWrr2JK3LJmIjLC6Mwpn+bzjyAmEC4BMMp0vDnBMON9km1qo4mQ35EKGswgggbMIIHA6ADAgEC AgooxudyAAEAAAA1MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAyMTAx MDE2MzMwMFoXDTA1MTAxMDE2NDMwMFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m dDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0 ZSBXaGljYTIwggG3MIIBKwYHKoZIzjgEATCCAR4CgYEA+hLPe7uYsHmuGUfkITkBqWsGXo22y369 ks09E+EjwAGs24cphaVHqFZ3+KQ/kgyANCvsNSkmut2/hnZPWkk9UQcjEK5rcdNf+j5dUZNld0G/ jH46Ecua3XUpxPL0H7S2mDemwkLib61o41pt37LD8QH0Cg+V0Z0egYEFIY50AuMCFQCYT5Q9snVa 1ekUrZTCYzob/OjrQwKBgGbKD33vFBA+cKvgitrGpSLmxdey9I++KbA79QQXEnACJZLw5S6e+eHs Z3T+xwPlg2RUCxtFgX5c2DJhUKxi6wLUsfwO+g7OrgfPyWD0r/aQDzS/ZKSvgMfUQUzYkbcn0dur frYOT2LxXocBkQD8/yQH38n5wjUuheVa1/Dm5oKYA4GFAAKBgQCiStJWJMhC3tkbRi2OvYYtxyrl tPMOyZR1E5DPWqL15vlw4hhrZheATpyZlMggU4vHps92BvBlICw58FCh9Cgsbe8l5BwawD++PvDO ObOVoiZiwEX05lEUqXsLev9MtKEdcFNAejXrNwIa4sJeFC86yuMmGUq+G9Hl8yY2k4riOaOCBFMw ggRPMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOK+A3DViyDSQURqr+bId3FaJQAfMAsGA1Ud DwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDBAAFMCMGCSsGAQQBgjcVAgQWBBTWUig3WSHjbYXiEmot Y22qaLxrQDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBSIyc2cnDoigOrk LdoVRy/1+8S8mzCCAZkGA1UdHwSCAZAwggGMMIIBiKCCAYSgggGAhoHZbGRhcDovLy9DTj1OVERF ViUyMFNBJTIwUm9vdCUyMENBKDEpLENOPXdoaWNhc2Fyb290Y2EsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZRaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3Js hk9odHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW JTIwU0ElMjBSb290JTIwQ0EoMSkuY3JsMIIB6QYIKwYBBQUHAQEEggHbMIIB1zCByAYIKwYBBQUH MAKGgbtsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGEBggrBgEFBQcwAoZ4aHR0cDovL3doaWNhd2ViLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5t aWNyb3NvZnQuY29tX05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3J0MIGCBggrBgEFBQcwAoZ2 aHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQEFBQADggEBADTCZCUZvE/CF5YX7SiP y/WGMFtXXeCYEr/Y7LSrY5yAL+j4ZKQor7lLfrE7FO9UgGKjfs+LqO0kjxad47041wtArk0e5RXe P0UW0IzZOctur84ke76sqtggFFgCOffLqhY9plCcfVSDpBrngAISXVuhx8oEzptU2UkqcH5ZGmfB vgytdCKe+vStiuVgf5nvEQIej5on2qentxdfMQsXntj2oEFupjmR6J9YV9f43GEWlGuDC1Lou10g 84idAsbaQ+hjxBp8e9NIGPgi5LF1o353R32fU4Oc3ggpGFFiJVKnA/tqgusrcV6ViN0sQftdALar 5PjV25iA2FaXQOR/bpcxggKfMIICmwIBATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCi/4jlMAAwAp wngwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMwNDExMjI0MDMyWjAjBgkqhkiG9w0BCQQxFgQUPK1a7kcKBxBQ6VRH7XEGfCtku/EwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAE MVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEY MBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgoghY36AAMAKY7OMGoGCyqGSIb3DQEJEAILMVugWTBL MQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UE AxMPTlRERVYgSVNTVUUzIENBAgoghY36AAMAKY7OMA0GCSqGSIb3DQEBAQUABIGAYsCIfYl50CGA Dh+piAIsPVedj4M6dP3L0cu7cg8lVreO0yoCW9HTTPvf+SLPgVHRqS7hDLnZADrScCVAxNArHSqI 5vMgAzY0muVi/73rFhoxGfpzCJeN5c9K3xJ4twdlPmmzsKkLlX7Aa6xISu9H+aqJk6K4j3yHSI8B BSGaD+sAAAAAAAA= ------=_NextPart_000_0043_01C30040.AFC2EC00-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM79JM021765 for ; Fri, 11 Apr 2003 15:07:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BM79XU021764 for ietf-sasl-bks; Fri, 11 Apr 2003 15:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tripod-int.labs.agilent.com (tripod-ext.labs.agilent.com [192.25.140.133]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM78JM021742 for ; Fri, 11 Apr 2003 15:07:08 -0700 (PDT) Received: from thing1.labs.agilent.com (thing1.labs.agilent.com [130.29.252.18]) by tripod-int.labs.agilent.com (8.12.9/8.12.9/Tripod Sendmail Config v01.02 2002/09/24) with ESMTP id h3BM76Dn006688 for ; Fri, 11 Apr 2003 15:07:06 -0700 Received: from alexbh1.labs.agilent.com (alexbh1.labs.agilent.com [130.29.252.76]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3BM76hF005418 for ; Fri, 11 Apr 2003 15:07:06 -0700 Received: from 130.29.252.18 by alexbh1.labs.agilent.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 15:07:06 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3BM75IT005413 for ; Fri, 11 Apr 2003 15:07:05 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Apr 2003 15:07:05 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Subject: RE: Comments on 2831 Confidentiality Protection Date: Fri, 11 Apr 2003 15:07:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-98.5 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >From the information on the SASL website it appears to me that 2831 is currently 'under revision', hence my suggestion to allow use of ESP as an option for encoding the integrity and confidentiality protection. This could easily be done by simply specifying an 'encoding' field in much the same way the ciper is specified. If the intent is to only 'tweak' technical errors then this suggestion is clearly too late. -- Glenn > > > >I just stumbled across the rfc Wednesday. When was the last call ? > > December 1998. > > >It "would have been" nice > > Lot's of things "would have been" nice. > > We need to focus on resolving clear technical errors and omissions. > > Kurt > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKbrJM017019 for ; Fri, 11 Apr 2003 13:37:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKbr2Y017017 for ietf-sasl-bks; Fri, 11 Apr 2003 13:37:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h3BKbqJM017010 for ; Fri, 11 Apr 2003 13:37:52 -0700 (PDT) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h3BKbeBT033852; Fri, 11 Apr 2003 20:37:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030411133224.02b59958@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Apr 2003 13:35:16 -0700 To: glenn_engel@agilent.com From: "Kurt D. Zeilenga" Subject: RE: Comments on 2831 Confidentiality Protection Cc: ietf-sasl@imc.org In-Reply-To: Mime-Version: 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:42 AM 4/11/2003, glenn_engel@agilent.com wrote: >> The correct time to make this comment was prior to the >> publication of RFC 2831 >> -- that's the purpose of the last call period. > >I just stumbled across the rfc Wednesday. When was the last call ? December 1998. >It "would have been" nice Lot's of things "would have been" nice. We need to focus on resolving clear technical errors and omissions. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGgrJM004773 for ; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BGgrqF004772 for ietf-sasl-bks; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tintagel-int.labs.agilent.com (tintagel-ext.labs.agilent.com [192.25.140.108]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGgpJM004768 for ; Fri, 11 Apr 2003 09:42:52 -0700 (PDT) Received: from thing1.labs.agilent.com (thing1.labs.agilent.com [130.29.252.18]) by tintagel-int.labs.agilent.com (8.12.9/8.12.9/Tintagel Sendmail Config v01.02 2002/10/28) with ESMTP id h3BGgrDO024851 for ; Fri, 11 Apr 2003 09:42:53 -0700 (PDT) Received: from alexbh1.labs.agilent.com (alexbh1.labs.agilent.com [130.29.252.76]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3BGgrhF029857 for ; Fri, 11 Apr 2003 09:42:53 -0700 Received: from 130.29.252.18 by alexbh1.labs.agilent.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 09:42:52 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3BGgpIT029852 for ; Fri, 11 Apr 2003 09:42:51 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Apr 2003 09:42:51 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Subject: RE: Comments on 2831 Confidentiality Protection Date: Fri, 11 Apr 2003 09:42:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-97.7 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The correct time to make this comment was prior to the > publication of RFC 2831 > -- that's the purpose of the last call period. I just stumbled across the rfc Wednesday. When was the last call ? It "would have been" nice to utilize ESP encoding as it addresses other encryption/auth algorithms and would provide a framework for re-using existing IPSEC code in conjunction with SASL. A new draft of ESP includes policy on how to deal with high speed connections where the sequence number can roll over as well as providing protection from traffic flow analysis. By combining the simplicity of Digest Authentication in 2831 and it's nice way of defining keys with ESP a really nice combination would result. -- Glenn Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJFWJM003861 for ; Thu, 10 Apr 2003 12:15:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AJFVLK003859 for ietf-sasl-bks; Thu, 10 Apr 2003 12:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJFQJM003840 for ; Thu, 10 Apr 2003 12:15:26 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA13677 for ; Thu, 10 Apr 2003 13:15:28 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HD500EWG6TR67@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Thu, 10 Apr 2003 13:15:28 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HD5009SP6TOW6@mail.sun.net> for ietf-sasl@imc.org; Thu, 10 Apr 2003 13:15:27 -0600 (MDT) Date: Thu, 10 Apr 2003 12:13:59 -0700 From: Chris Newman Subject: Re: Comments on 2831 Confidentiality Protection In-reply-to: To: glenn_engel@agilent.com Cc: ietf-sasl@imc.org, paulle@microsoft.com Message-id: <2147483647.1049976839@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The correct time to make this comment was prior to the publication of RFC 2831 -- that's the purpose of the last call period. While consistency across the Internet suite is aesthetically attractive and I would have supported this proposal prior to the publication and deployment of RFC 2831, I must oppose this proposal now. There are a number of deployed implementations of RFC 2831, so backwards compatibility and interoperability with the running code would trump the majority of aesthetic and minor technical points. Now if it were determined that the way RC4 is specified in RFC 2831 has a fatal security flaw and can not be fixed without breaking interoperability, then your proposal would merit consideration. But I have yet to hear such a determination. - Chris begin quotation by glenn_engel@agilent.com on 2003/4/10 11:23 -0700: > > I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes > the cipher of the message as well as a catenated HMAC. This requires > decryption of the entire message before authentication can be done. > RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical > encoding. One notable difference is that ESP defines the HMAC to be done on > the encrypted contents so that the message can be authenticated without the > potentially costly cipher being done (another form of denial of protection > against denial of service, replay or man in the middle attacks). Since the > form of the message is so close to ESP, I would suggest utilizing the exact > packet format as defined in RFC2406. This RFC includes the sequence number, > padding, authentication and encryption techniques to assemble a packet with > only slight differences to what 2831 specifies. See section 2 of the > rfc2406. > I would suggest specifying that the Confidentiality Protection for rfc2831 > payload be constructed as described in RFC2406. For purposes of rfc2831, the > SPI and next header fields could be defined as zeros. > As an enhancement consider the following - sInce rfc2831 is connection > oriented the SPI used in ESP/IPSEC is 'implied' by the connection. If UDP > was instead used as the communication medium then the rfc2831 dialog could > still be done pretty much as defined with the addition of an SPI argument > returned to the client. > > -- > Glenn > > glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066 > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AINKJM001362 for ; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AINKBQ001361 for ietf-sasl-bks; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from tintagel-int.labs.agilent.com (tintagel-ext.labs.agilent.com [192.25.140.108]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AINJJM001357 for ; Thu, 10 Apr 2003 11:23:19 -0700 (PDT) Received: from unicorn.labs.agilent.com (root@unicorn.labs.agilent.com [130.29.252.5]) by tintagel-int.labs.agilent.com (8.12.9/8.12.9/Tintagel Sendmail Config v01.02 2002/10/28) with ESMTP id h3AINLDO015095; Thu, 10 Apr 2003 11:23:21 -0700 (PDT) Received: from alex1.labs.agilent.com (alex1.labs.agilent.com [130.29.252.55]) by unicorn.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with SMTP id h3AINKoR021621; Thu, 10 Apr 2003 11:23:20 -0700 (PDT) Received: from 130.29.252.18 by alex1.labs.agilent.com (InterScan E-Mail VirusWall NT); Thu, 10 Apr 2003 11:23:20 -0700 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by thing1.labs.agilent.com (8.12.9/8.12.9/Agilent Labs Mail Hub v 01.02 2002/02/06) with ESMTP id h3AINGIT027770; Thu, 10 Apr 2003 11:23:16 -0700 Received: by ALEX2 with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Apr 2003 11:23:16 -0700 Message-ID: From: glenn_engel@agilent.com To: ietf-sasl@imc.org Cc: paulle@microsoft.com, chris.newman@INNOSOFT.COM Subject: Comments on 2831 Confidentiality Protection Date: Thu, 10 Apr 2003 11:23:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5" X-Spam-Status: No, hits=-97.7 required=5.0 X-Spam-Level: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF8E.406176BE" ------_=_NextPart_001_01C2FF8E.406176BE Content-Type: text/plain; charset="iso-8859-1" I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC. This requires decryption of the entire message before authentication can be done. RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding. One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done (another form of denial of protection against denial of service, replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406. This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies. See section 2 of the rfc2406. I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406. For purposes of rfc2831, the SPI and next header fields could be defined as zeros. As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection. If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client. -- Glenn glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066 ------_=_NextPart_001_01C2FF8E.406176BE Content-Type: text/html; charset="iso-8859-1"
I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC.   This requires decryption of the entire message before authentication can be done.
 
RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding.  One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done  (another form of denial of protection against denial of service,  replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406.  This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies.  See section 2 of the rfc2406.
 
I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406.  For purposes of rfc2831, the SPI and next header fields could be defined as zeros. 
 
As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection.  If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client.

--
Glenn

glenn_engel@agilent.com / Agilent Laboratories / NN7N / 425-335-2066

 
------_=_NextPart_001_01C2FF8E.406176BE-- ------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JP2JM016264 for ; Wed, 9 Apr 2003 12:25:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39JP2Qn016263 for ietf-sasl-bks; Wed, 9 Apr 2003 12:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-ONE-NINETY-SEVEN.MIT.EDU [18.187.5.197]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39JOxJM016251 for ; Wed, 9 Apr 2003 12:24:59 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 73D4E15226A; Wed, 9 Apr 2003 15:25:01 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 From: Sam Hartman Date: Wed, 09 Apr 2003 15:25:01 -0400 In-Reply-To: <3E938D1C.6831BAB1@messagingdirect.com> (Alexey Melnikov's message of "Tue, 08 Apr 2003 21:01:48 -0600") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> <3E938D1C.6831BAB1@messagingdirect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> === I am not sure whether the last paragraph belongs to Alexey> this document, or whether it should be moved to the SASL Alexey> document or profile documents. Personally, I would hate Alexey> to update each profile document with this text. I think that this goes in the base spec. I'll think about text for the man-in-the-middle case. I'm not really sure what we want to happen. We could recommend that people always mandate integrity protection or confidentiality, but doing so would create interoperability problems. We could recommend that people not use digest-md5, but we should have something to recommend instead. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3933fJM004337 for ; Tue, 8 Apr 2003 20:03:41 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3933fdO004336 for ietf-sasl-bks; Tue, 8 Apr 2003 20:03:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3933bJM004332 for ; Tue, 8 Apr 2003 20:03:40 -0700 (PDT) Received: from messagingdirect.com (1Cust234.tnt3.edmonton.ab.da.uu.net [64.10.184.234]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h39370V20454; Tue, 8 Apr 2003 21:07:00 -0600 Message-ID: <3E938D1C.6831BAB1@messagingdirect.com> Date: Tue, 08 Apr 2003 21:01:48 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > >>>>> "Alexey" == Alexey Melnikov writes: > > Alexey> We have to be clear that for the protocols that use the > Alexey> same format for authentication and authorization ids, > Alexey> "authzid" is in UTF-8 and MUST NOT be converted to > Alexey> ISO-8859-1 as username/password are. > > No, authz ID is in whatever format the application says it is. All > the base spec seems to say is that it is a string. > > I would recommend replacing the text I complained about with something > that says "The authorization identifier MUST NOT be converted to ISO > 8859-1 by this mechanism even if the authentication identifier is > converted for compatibility." Ok, I've mostly fixed this. The new text in 2.1.2 looks like: authzid The "authorization ID" directive is optional. If present, and the authenticating user has sufficient privilege, and the server supports it, then after authentication the server will use this identity for making all accesses and access checks. If the client specifies it, and the server does not support it, then the response-value calculated on the server will not match the one calculated on the client and authentication will fail. The authorization identifier MUST NOT be converted to ISO 8859-1 even if the authentication identifier ("username") is converted for compatibility as directed by "charset" directive. The server SHOULD verify the correctness of an authzid. For example, an IMAP [RFC 3501] server will prepare the received authzid using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If preparation of the authzid fails or results in an empty string, the server MUST fail the authentication exchange. === I am not sure whether the last paragraph belongs to this document, or whether it should be moved to the SASL document or profile documents. Personally, I would hate to update each profile document with this text. > >> The security discussion seems inadequate. > > Alexey> Suggestions? > > I specifically meant the security discussion of the QOP stuff, BTW. >>3.6 Man in the Middle ... >>A possible man-in-the-middle attack would be to substitute a weaker qop >>scheme for the one(s) sent by the server; the server will not be able to >>detect this attack. For this reason, the client should always use the >>strongest scheme that it understands from the choices offered, and >>should never choose a scheme that does not meet its minimum >>requirements. Can you suggest any specific changes to this text? Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LTbJM017915 for ; Tue, 8 Apr 2003 14:29:38 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38LTbkh017914 for ietf-sasl-bks; Tue, 8 Apr 2003 14:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LTaJM017909 for ; Tue, 8 Apr 2003 14:29:37 -0700 (PDT) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA10991 for ; Tue, 8 Apr 2003 15:29:39 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HD1000XDNNISK@edgemail1.Central.Sun.COM> for ietf-sasl@imc.org; Tue, 08 Apr 2003 15:28:31 -0600 (MDT) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HD1002CSNN9MZ@mail.sun.net> for ietf-sasl@imc.org; Tue, 08 Apr 2003 15:28:30 -0600 (MDT) Date: Tue, 08 Apr 2003 14:26:59 -0700 From: Chris Newman Subject: SASL API: should sasl_errdetail be human readable or deprecated? To: Alexey Melnikov , Rob Siemborski Cc: ietf-sasl@imc.org Message-id: <2147483647.1049812019@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When I added the sasl_errdetail call to the SASL API, my intent was that it would provide human readable strings intended for IMAP NO and POP -ERR style text response messages, and suitable for display to end-users. The current API spec is too imprecise about the purpose of that function: Given there is already a logging callback in the SASL API, I would argue that sasl_errdetail serves no purpose unless it is intended for end-user consumption. However, the CMU implementation generates cryptic error strings which are not suitable for end-user consumption and which leak security sensitive information (like the distinction between user not found and bad password). That leaves us a choice: 1. Clarify that sasl_errdetail is intended to return error strings suitable to be passed back over protocol and presented to an end-user. This would require clarification to the spec and some changes to the CMU implementation. I am willing to propose the code changes to CMU if there is consensus for this option. 2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error codes as the only way to determine what text messages to pass back to the end-user. Use the logging callback for all detailed error logging. I propose option 1 as the correct choice. My theory is that attempting to enumerate all errors which require different behaviors on the client side is a tractable problem, but attempting to enumerate all errors which are useful to inform the user is not a tractable problem and thus a text string to pass back to the user is important. If there are no objections, I will propose changes to the API spec to Alexey and changes to the CMU implementation to Rob. - Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HdtJM019463 for ; Mon, 7 Apr 2003 10:39:55 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37HdtN6019462 for ietf-sasl-bks; Mon, 7 Apr 2003 10:39:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HdrJM019448 for ; Mon, 7 Apr 2003 10:39:54 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 97826152124; Mon, 7 Apr 2003 13:39:20 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on draft-ietf-sasl-rfc2831 References: <200303251440.JAA16446@tir-na-nogth.mit.edu> <3E89239B.1E03F4FE@messagingdirect.com> From: Sam Hartman Date: Mon, 07 Apr 2003 13:39:20 -0400 In-Reply-To: <3E89239B.1E03F4FE@messagingdirect.com> (Alexey Melnikov's message of "Mon, 31 Mar 2003 22:28:59 -0700") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 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> We have to be clear that for the protocols that use the Alexey> same format for authentication and authorization ids, Alexey> "authzid" is in UTF-8 and MUST NOT be converted to Alexey> ISO-8859-1 as username/password are. No, authz ID is in whatever format the application says it is. All the base spec seems to say is that it is a string. I would recommend replacing the text I complained about with something that says "The authorization identifier MUST NOT be converted to ISO 8859-1 by this mechanism even if the authentication identifier is converted for compatibility." >> The security discussion seems inadequate. Alexey> Suggestions? I specifically meant the security discussion of the QOP stuff, BTW. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h360RvJM012941 for ; Sat, 5 Apr 2003 16:27:57 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h360RvIE012940 for ietf-sasl-bks; Sat, 5 Apr 2003 16:27:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h360RuJM012928 for ; Sat, 5 Apr 2003 16:27:56 -0800 (PST) Received: from solomon (a3-p07.syd.fl.net.au [202.181.1.71]) by delenn.fl.net.au (Postfix) with ESMTP id AAA91180C2B; Sun, 6 Apr 2003 10:29:45 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: Sam Hartman Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Sun, 6 Apr 2003 10:23:33 +1000 User-Agent: KMail/1.4.3 Cc: SASL References: <200304012027.29229.raif@fl.net.au> <200304020833.47017.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Message-Id: <200304061023.35180.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h360RuJM012935 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Saturday 05 April 2003 07:11, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > > Raif> would a sequence of bytes preceded by their count (one > Raif> additional byte) be enough? > > I don't understand your question. For a sasl mechanism, I think > limiting authorization identifiers to 255 bytes would be overly > restrictive. > > For an application profile, sequence of bytes would be an > underspecified authorization identifier. the adoption of StringPrep, within the specifications of a SASL Mechanism, solves the question of required (canonical) transformations for authentication IDs (uersnames) and passwords. this is because as you pointed out --in your last email, and i totally overlooked-- these entities are acquired by the mechanism itself and hence are not within the scope of the Profile. the authorization ID on the other hand, is not acquired by the Mechanism; at least this is my understanding/interpretation of last para in section 4.1 of draft-myers-saslrev-02.txt, which echoes another para in section 3 of RFC-2222: "During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (frequently known as a userid) from the client to server, and negotiates the use of a mechanism-specific security layer." in other words, a Profile hands over an authorization ID (or a callback mechanism to receive it), which it (the Mechanism) then transmits to the peer. my question is on the encoding of this entity as seen by the Mechanism, at that interface point. draft-myers-saslrev-02, section 4.2 reflects discussions we had in this group about this token (authorization ID). it proposes: "An authorization identity is a string of zero or more ISO 10646 [ISO-10646] coded characters. The NULL (U+0000) character is not permitted in authorization identities." my question is about reaching a consensus on a choice and wording for how this entity is passed between the Mechanism and the Profile. if a string of iso-10646 w/o nulls is not an acceptable option would an octet sequence with a length octet be one. if neither are, what other alternatives are there. cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+j3OF+e1AKnsTRiERA0nqAKDWdJjXf9TMTF+NNIL1jkVROjmumQCgheOm 053vd60+E1B+ZZVebhXhhPo= =WWvx -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35ManJM008912 for ; Sat, 5 Apr 2003 14:36:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35ManJx008911 for ietf-sasl-bks; Sat, 5 Apr 2003 14:36:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MalJM008907 for ; Sat, 5 Apr 2003 14:36:47 -0800 (PST) Received: from messagingdirect.com (1Cust241.tnt3.edmonton.ab.da.uu.net [64.10.184.241]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h35MdEV20068; Sat, 5 Apr 2003 15:39:16 -0700 Message-ID: <3E8F4DEB.CF1E05C7@messagingdirect.com> Date: Sat, 05 Apr 2003 14:43:07 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: keith@rucus.ru.ac.za CC: SASL , Sam Hartman , raif@fl.net.au Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> <200304012041.28164.keith@rucus.ru.ac.za> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Burdis wrote: > Seriously, this looks to be a reasonable specification for usernames and > passwords. Is there any reason why all mechanisms shouldn't use at least this > set of restrictions? IMHO, all new mechanisms should use the same stringprep profile. > Why for example, would anonymous use a less restrictive > profile? This is required for backward compatibility, as ANONYMOUS allowed for arbitrary text to be passed. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MaiJM008904 for ; Sat, 5 Apr 2003 14:36:44 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35MaiT6008903 for ietf-sasl-bks; Sat, 5 Apr 2003 14:36:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35MaeJM008899 for ; Sat, 5 Apr 2003 14:36:43 -0800 (PST) Received: from messagingdirect.com (1Cust241.tnt3.edmonton.ab.da.uu.net [64.10.184.241]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h35Me7V20082; Sat, 5 Apr 2003 15:40:07 -0700 Message-ID: <3E8F4EF3.3AB646CD@messagingdirect.com> Date: Sat, 05 Apr 2003 14:47:31 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism References: <20030404210846.43B16152124@konishi-polis.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > Here's roughly what would need to happen to turn a SASL mechanism into > a standards track GSSAPI mechanism > > 1) You need to use the GSSAPI initial context token format. this > means you need to include an OID and a bit of header at the > beginning of the authentication messages. > > 2) You need to assign an OID to your mechanism. > > 3) You may need to think about name formats for principal names a bit. > > 4) There may be some issues involving out-of-order delivery of > messages you need to think about. > > 5) You should organize the document so it will be clear both to people > implementing as a SASL mechanism and as a GSSAPI mechanism. Sam, do you volunteer to write a paragraph that describes a binary representation for the GSSAPI header? If you (or somebody else) do this, we would be done with this discussion. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35EuXJM014991 for ; Sat, 5 Apr 2003 06:56:33 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35EuX2n014990 for ietf-sasl-bks; Sat, 5 Apr 2003 06:56:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35EuVJM014983 for ; Sat, 5 Apr 2003 06:56:32 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E2DE5152124; Sat, 5 Apr 2003 09:55:56 -0500 (EST) To: keith@rucus.ru.ac.za Cc: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism References: <20030404210846.43B16152124@konishi-polis.mit.edu> <200304050117.02990.keith@rucus.ru.ac.za> From: Sam Hartman Date: Sat, 05 Apr 2003 09:55:56 -0500 In-Reply-To: <200304050117.02990.keith@rucus.ru.ac.za> (Keith Burdis's message of "Sat, 5 Apr 2003 01:17:02 +0000") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 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 tried to make this clear at the working group meeting, but it didn't really make it into the minutes. The SRP mechanism is out of scope for this working group, so I am not acting as chair in this discussion. I am acting as an interested party. Should this specification ever become a work item of this working group, I'll find someone else to argue this position so I can be an effective chair.] , >>>>> "Keith" == Keith Burdis writes: Keith> On Friday 04 Apr 2003 21:08, Sam Hartman wrote: >> I've been asked to clarify my objections to an SRP SASL >> mechanism. >> >> The basic objection is that mechanism designers should write >> GSSAPI mechanisms not SASL mechanisms unless they have a good >> reason to do otherwise. Keith> I have no problem with the GSS-API, but it is far from Keith> simple. Compare the 85 pages in RFC 2078 with the 16 pages Keith> in RFC 2222. I think comparing the page counts is a significantly misleading complexity metric. I believe that the complexity of a simple GSSAPI mechanism is not significantly more than the complexity of a simple SASL mechanism with a security layer. There are certainly GSSAPI mechanisms that are more complex than non-GSSAPI SASL mechanisms, but this is not required. Keith> The basic question is: why should mechanism designers Keith> bother with the complexity of GSS-API when they can design Keith> much simpler SASL mechanisms? First, I don't think there is that much more complexity involved. But my primary concern is that review and specification of a technology for multiple protocols is much more expensive than taking the work up front to specify the technology for a framework. Specifying SRP for all the other protocols that use GSSAPI would take more time than doing a SRP GSSAPI mechanism rather than a SASL mechanism. Even if we could reuse significant ideas from the SASL mechanism, doing the work to compare and contrast the results of all the SRP specifications against each other making sure that they worked well together and that there were not bugs introduced as ideas were copied would be significantly greater than the cost of specifying a GSSAPI mechanism now. The only way specifying a SASL mechanism makes sense is if we hope never to have to do the work of specifying a GSSAPI mechanism later or to specify SRP for other protocols that support both GSSAPI and other authentication technology. There are two reasons this might be the case. The first is that SRP might not get enough deployment to matter for those protocols. The second is that SRP is somehow uniquely suited to applications that use SASL but not to current and future protocols that use GSS. If SRP is not going to get enough deployment for future work, then we shouldn't even bother with the SASL mechanism. Specification review effort is very expensive and we're all fairly busy as is. I can't think of a reason why SRP would be more suited to email, directory access, etc than say file sharing or remote login. If you can then I'll certainly reconsider. Keith> The reason that SASL came Keith> about was because alternatives like the GSS-API were too Keith> complicated. I think the complexity being complained about was mostly on the application side--GSSAPI is hard to integrate into a protocol. I don't think the same complexities really exist on the mechanism side. SASL was also important because there exist SASL mechanisms that do not have enough features to be GSS mechanisms. Keith> I agree that an SRP GSS-API mechanism [1] would be great to Keith> have, but that is no reason not to have an SRP SASL Keith> mechanism. I think it is. First, I think the costs of doing both an SRP GSS mechanism and an SRP SASL mechanism are significantly higher than the costs of the GSS mechanism alone. Second, having multiple ways to use SRP in the same protocol will confuse site administrators and users and make configuration more complex. >> If SRP is useful, then people will want to use it with other >> protocols and so we should try to make sure it is useful with >> all those protocols. The IETF is busy and reviewing security >> documents takes time. So we should find the solution that >> involves minimizing review within the IETF while maximizing the >> number of situations where the technology is useful. Keith> It sounds to me like you are saying that we should not have Keith> any other SASL mechanisms other than the SASL GSS-API Keith> mechanism. If so, then what is the point of SASL? Is it Keith> then just a wrapper for GSS-API? I think the point of SASL is to be a convenient way to add authentication to applications. It happens to encapsulate a lot of the GSS complexity that will be the same for all applications. It also provides for mechanisms that are too weak to be GSS mechanisms. Applications should use SASL if they can live within its constraints. Except in some special cases mechanisms should be designed for GSS. >> 2) GSSAPI libraries are hard to deal with and multi-mechanism >> GSSAPI support is weak >> >> There is no requirement that you use a GSSAPI library or even >> the GSSAPI within your program to implement a SASL GSSAPI >> mechanism. You simply need to have a compatible wire encoding, >> but you can actually implement the mechanism the same as you >> would implement other SASL mechanisms if you find that an >> easier implementation choice. Keith> It is not really the same as other SASL mechanisms, because Keith> there is extra "baggage" included. A few extra bytes at the beginning of the context tokens doesn't seem unacceptable. >> Here's roughly what would need to happen to turn a SASL >> mechanism into a standards track GSSAPI mechanism >> >> 1) You need to use the GSSAPI initial context token format. >> this means you need to include an OID and a bit of header at >> the beginning of the authentication messages. Keith> It also means we have to deal with ASN.1: False. The GSSAPI spec defines the context token header both in terms of ASN.1 and in terms of raw bytes. It explicitly states that the raw bytes definition is authoritative. You could choose to use ASN.1 if you like, or you could just emit the context token header for your mechanism, listing it as raw bytes in your specification. >> 4) There may be some issues involving out-of-order delivery of >> messages you need to think about. Keith> In the authentication exchange or in the security layer? security layer. Keith> [1] Keith> http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h350HUJM011501 for ; Fri, 4 Apr 2003 16:17:30 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h350HUxd011500 for ietf-sasl-bks; Fri, 4 Apr 2003 16:17:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.spheniscidae.co.uk (yoda.spheniscidae.co.uk [81.2.79.3]) by above.proper.com (8.12.9/8.11.6) with SMTP id h350HSJM011488 for ; Fri, 4 Apr 2003 16:17:29 -0800 (PST) Received: (qmail 13471 invoked by uid 1003); 5 Apr 2003 01:17:03 -0000 From: Keith Burdis Reply-To: keith@rucus.ru.ac.za To: ietf-sasl@imc.org Subject: Re: My concerns about a SRP SASL mechanism Date: Sat, 5 Apr 2003 01:17:02 +0000 User-Agent: KMail/1.5.1 References: <20030404210846.43B16152124@konishi-polis.mit.edu> In-Reply-To: <20030404210846.43B16152124@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304050117.02990.keith@rucus.ru.ac.za> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday 04 Apr 2003 21:08, Sam Hartman wrote: > I've been asked to clarify my objections to an SRP SASL mechanism. > > The basic objection is that mechanism designers should write GSSAPI > mechanisms not SASL mechanisms unless they have a good reason to do > otherwise. I have no problem with the GSS-API, but it is far from simple. Compare the 85 pages in RFC 2078 with the 16 pages in RFC 2222. The basic question is: why should mechanism designers bother with the complexity of GSS-API when they can design much simpler SASL mechanisms? The reason that SASL came about was because alternatives like the GSS-API were too complicated. I agree that an SRP GSS-API mechanism [1] would be great to have, but that is no reason not to have an SRP SASL mechanism. In our opinion trying to merge the two is not a good idea. > If the SRP mechanism was a GSSAPI mechanism then it could be used > unmodified within SSH, NFS V4 and other protocols that support > GSSAPI for security within the IETF and within other areas. It > could also be used with all the protocols that use SASL. Quite true. > If SRP is useful, then people will want to use it with other protocols > and so we should try to make sure it is useful with all those > protocols. The IETF is busy and reviewing security documents takes > time. So we should find the solution that involves minimizing review > within the IETF while maximizing the number of situations where the > technology is useful. It sounds to me like you are saying that we should not have any other SASL mechanisms other than the SASL GSS-API mechanism. If so, then what is the point of SASL? Is it then just a wrapper for GSS-API? > Here are some objections I can see to writing the SRP SASL mechanism > in the form of a GSSAPI mechanism: > > 1) We're almost done with the existing draft. > > Up until now the document has not received significant review > within the IETF. It has not been a work product of a working > group and has not been last called before. When a document is > submitted to the IETF for the standards track, the IETF receives > change control and needs the opportunity to make (potentially > significant) changes to the document. It is not the product of a working group because someone decided that it wasn't appropriate due to problems with US patents. It has however been discussed on this mailing list on and off for four years. We have no problem with making any changes to the document as long as we feel they are justified. The current document is very different to the orginal version and has benefited significantly from feedback received. > 2) GSSAPI libraries are hard to deal with and multi-mechanism GSSAPI > support is weak > > There is no requirement that you use a GSSAPI library or even the > GSSAPI within your program to implement a SASL GSSAPI mechanism. > You simply need to have a compatible wire encoding, but you can > actually implement the mechanism the same as you would implement > other SASL mechanisms if you find that an easier implementation > choice. It is not really the same as other SASL mechanisms, because there is extra "baggage" included. > Here's roughly what would need to happen to turn a SASL mechanism into > a standards track GSSAPI mechanism > > 1) You need to use the GSSAPI initial context token format. this > means you need to include an OID and a bit of header at the > beginning of the authentication messages. It also means we have to deal with ASN.1: InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech OBJECT IDENTIFIER, innerContextToken ANY DEFINED BY thisMech } This is meaningful for GSS-API, but from an SASL mechanism perspective, this means that we have a bunch of garbage bytes at the beginning of our exchange. > 2) You need to assign an OID to your mechanism. Ok. > 3) You may need to think about name formats for principal names a bit. We don't put any restrictions on name formats, only encodings. > 4) There may be some issues involving out-of-order delivery of > messages you need to think about. In the authentication exchange or in the security layer? > 5) You should organize the document so it will be clear both to people > implementing as a SASL mechanism and as a GSSAPI mechanism. The whole point of SASL is that it is simple. Each of the points above adds complexity to the mechanism. I am not completely dismissing the idea, but I am not convinced that this complexity is justified in the context of what SASL is trying to achieve - simple authentication. - Keith [1] http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LCfJM004347 for ; Fri, 4 Apr 2003 13:12:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34LCfM3004346 for ietf-sasl-bks; Fri, 4 Apr 2003 13:12:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LCeJM004342 for ; Fri, 4 Apr 2003 13:12:40 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 38EA3152124; Fri, 4 Apr 2003 16:11:56 -0500 (EST) To: raif@fl.net.au Cc: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> <200304020833.47017.raif@fl.net.au> From: Sam Hartman Date: Fri, 04 Apr 2003 16:11:56 -0500 In-Reply-To: <200304020833.47017.raif@fl.net.au> ("Raif S. Naffah"'s message of "Wed, 2 Apr 2003 09:33:44 +1100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Raif" == Raif S Naffah writes: Raif> would a sequence of bytes preceded by their count (one Raif> additional byte) be enough? I don't understand your question. For a sasl mechanism, I think limiting authorization identifiers to 255 bytes would be overly restrictive. For an application profile, sequence of bytes would be an underspecified authorization identifier. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34L9VJM004146 for ; Fri, 4 Apr 2003 13:09:31 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34L9VfJ004145 for ietf-sasl-bks; Fri, 4 Apr 2003 13:09:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34L9UJM004139 for ; Fri, 4 Apr 2003 13:09:30 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 43B16152124; Fri, 4 Apr 2003 16:08:46 -0500 (EST) To: ietf-sasl@imc.org Subject: My concerns about a SRP SASL mechanism Message-Id: <20030404210846.43B16152124@konishi-polis.mit.edu> Date: Fri, 4 Apr 2003 16:08:46 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been asked to clarify my objections to an SRP SASL mechanism. The basic objection is that mechanism designers should write GSSAPI mechanisms not SASL mechanisms unless they have a good reason to do otherwise. If the SRP mechanism was a GSSAPI mechanism then it could be used unmodified within SSH, NFS V4 and other protocols that support GSSAPI for security within the IETF and within other areas. It could also be used with all the protocols that use SASL. If SRP is useful, then people will want to use it with other protocols and so we should try to make sure it is useful with all those protocols. The IETF is busy and reviewing security documents takes time. So we should find the solution that involves minimizing review within the IETF while maximizing the number of situations where the technology is useful. Here are some objections I can see to writing the SRP SASL mechanism in the form of a GSSAPI mechanism: 1) We're almost done with the existing draft. Up until now the document has not received significant review within the IETF. It has not been a work product of a working group and has not been last called before. When a document is submitted to the IETF for the standards track, the IETF receives change control and needs the opportunity to make (potentially significant) changes to the document. 2) GSSAPI libraries are hard to deal with and multi-mechanism GSSAPI support is weak There is no requirement that you use a GSSAPI library or even the GSSAPI within your program to implement a SASL GSSAPI mechanism. You simply need to have a compatible wire encoding, but you can actually implement the mechanism the same as you would implement other SASL mechanisms if you find that an easier implementation choice. Here's roughly what would need to happen to turn a SASL mechanism into a standards track GSSAPI mechanism 1) You need to use the GSSAPI initial context token format. this means you need to include an OID and a bit of header at the beginning of the authentication messages. 2) You need to assign an OID to your mechanism. 3) You may need to think about name formats for principal names a bit. 4) There may be some issues involving out-of-order delivery of messages you need to think about. 5) You should organize the document so it will be clear both to people implementing as a SASL mechanism and as a GSSAPI mechanism. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JbtJM027065 for ; Fri, 4 Apr 2003 11:37:55 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34Jbsgk027064 for ietf-sasl-bks; Fri, 4 Apr 2003 11:37:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34JbrJM027055 for ; Fri, 4 Apr 2003 11:37:54 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D94E8152124; Fri, 4 Apr 2003 14:37:18 -0500 (EST) To: minutes@ietf.org Cc: ietf-sasl@imc.org Subject: Minutes for SASL working group at IETF 56 From: Sam Hartman Date: Fri, 04 Apr 2003 14:37:18 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Minutes based on notes from Chris Newman and Sam Hartman. ----- SASL WG IETF 56 San Francisco 1. Base spec -- document editor is non-responsive, will assign new editor. Issue: Is security considerations sufficient to meet IESG review? 2. Anonymous went through WG last call, will fix issues raised during last call, will submit with base spec. Sam Hartman will send a summary of the last call to the working group after reviewing with the editor. 3. Plain/saslprep The main issue is the stringprep profile. More review is required, especially of the profile. Issue: SASLprep profile should deal with user@domain-name syntax issues. IN particular many authentication identifiers and authorization identifiers include domain components. We need to be aware of any differences between nameprep and saslprep and avoid introducing these differences without good reason. Nameprep works on domain labels, while saslprep works on the string as a whole. Applications may mistakenly perform nameprep on input before giving it to SASL. Issue: Want SASLprep and Kerberos prep to use the same namespace. Discussion of authorization names vs authentication names. Larry Greenfield believes that applications will use the same profile for both. Kurt pointed out that LDAP is an example of an application with significantly different requirements for authorization identifiers than authentication identifiers. 3. DIGEST-MD5 issues Alexey is editor draft-ietf-sasl-rfc2831bis three open issues: 1. Whether we want to merge AES cipher? Postpone selection of mandatory-to-implement and adding AES until we have done a security analysis. Security analysis will be posted to the working group list. 2. Add SASLprep. 3. then ready for last call. 4. CRAM-MD5 draft Lyndon is editor 1. add SASLprep, then done. 5. GSSAPI issues 1. Last call the base32 draft, then last call. 2. An editor needs to be selected. 6. Individual submissions Authors of SRP document want to last call it. Issue: Sam Hartman believes it should have structure which included an OID in front so it could be used as a GSSAPI mechanism. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MXDJM024913 for ; Tue, 1 Apr 2003 14:33:13 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31MXDqr024912 for ietf-sasl-bks; Tue, 1 Apr 2003 14:33:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MXBJM024907 for ; Tue, 1 Apr 2003 14:33:12 -0800 (PST) Received: from solomon (a3-p30.syd.fl.net.au [202.181.1.94]) by delenn.fl.net.au (Postfix) with ESMTP id 066ED1807B3; Wed, 2 Apr 2003 08:39:17 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: Sam Hartman Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Wed, 2 Apr 2003 09:33:44 +1100 User-Agent: KMail/1.4.3 Cc: SASL References: <200304012027.29229.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Message-Id: <200304020833.47017.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31MXCJM024909 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Wednesday 02 April 2003 02:29, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > ... > Raif> 2. what is the consensus on specifying/handling > Raif> authorization identities for transportation on the wire? > is Raif> [UNICODE-KC] enough? > > ... > I think we would prefer that application profiles seriously consider > the use of saslprep for authorization identifiers, but it is not > right for all environments. would a sequence of bytes preceded by their count (one additional byte) be enough? cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+ihPJ+e1AKnsTRiERA1uEAJ9S04T3MUhl3pmove989VZ4+zihqQCgv5xL jF8BOOrEJQqTINOcd49Az90= =c1Lz -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LSaJM022837 for ; Tue, 1 Apr 2003 13:28:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LSaKX022836 for ietf-sasl-bks; Tue, 1 Apr 2003 13:28:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.spheniscidae.co.uk (yoda.spheniscidae.co.uk [81.2.79.3]) by above.proper.com (8.12.9/8.11.6) with SMTP id h31LSVJM022831 for ; Tue, 1 Apr 2003 13:28:34 -0800 (PST) Received: (qmail 7618 invoked by uid 1003); 1 Apr 2003 19:41:28 -0000 From: Keith Burdis Reply-To: keith@rucus.ru.ac.za To: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms Date: Tue, 1 Apr 2003 20:41:28 +0100 User-Agent: KMail/1.5.1 Cc: Sam Hartman ;, raif@fl.net.au References: <200304012027.29229.raif@fl.net.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304012041.28164.keith@rucus.ru.ac.za> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's a fun document :-) You have things like: MONGOLIAN TODO SOFT HYPHEN OGHAM SPACE MARK ARABIC END OF AYAH MUSICAL CONTROL CHARACTERS Seriously, this looks to be a reasonable specification for usernames and passwords. Is there any reason why all mechanisms shouldn't use at least this set of restrictions? Why for example, would anonymous use a less restrictive profile? - Keith On Tuesday 01 Apr 2003 17:29, Sam Hartman wrote: > >>>>> "Raif" == Raif S Naffah writes: > > Raif> hello there, can someone calrify the following: > > Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a > Raif> needed transformation for authentication identities > Raif> (usernames) and passwords, in preference to something like: > > Raif> MUST be in Unicode Normalization Form KC [UNICODE-KC] > Raif> without NUL characters. > > Please read the stringprep document; it has a good discussion of the > elements that go into a stringprep profile and I believe why they are > needed. If this is insufficient, please look at old minutes of the > IDN working group and their archived mailing list. > > Note that mechanisms do not need to use the saslprep profile. They > need to adopt a stringprep profile that is appropriate for the > mechanism in question. For example anonymous uses a much less > restrictive profile. > > Mechanisms using cryptography will tend to need fairly strong > canonicalization rules to make sure that usernames and passwords typed > with one set of input methods are handled the same when typed with a > different set of methods. > > Raif> wouldn't a transformation such as the SASLPrep be part of > Raif> the SASL Profile itself rather than the Mechanism(s)? > > If by SASL profile, you mean the profile for an application, no. The > form of authentication identifiers and other mechanism-specific > strings such as passwords is entirely a matter for the mechanism. As > an example, Kerberos will mandate a particular stringprep profile for > principals and passwords. In order for things to work, the SASL > GSSAPI mechanism for Kerberos must use the same stringprep profile. > > > > > Raif> 2. what is the consensus on specifying/handling > Raif> authorization identities for transportation on the wire? is > Raif> [UNICODE-KC] enough? > > > > The authorization identity is a matter for the application's SASL > profile. In many cases, the same constraints will apply to > authorization identities as authentication identities. The > transformation may end up being server-side rather than client-side, > but will likely still be needed. > > I think we would prefer that application profiles seriously consider > the use of saslprep for authorization identifiers, but it is not right > for all environments. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUbJM007672 for ; Tue, 1 Apr 2003 08:30:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31GUbF9007671 for ietf-sasl-bks; Tue, 1 Apr 2003 08:30:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FIVE.MIT.EDU [18.187.6.250]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUaJM007666 for ; Tue, 1 Apr 2003 08:30:36 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 35E02152124; Tue, 1 Apr 2003 11:29:56 -0500 (EST) To: raif@fl.net.au Cc: SASL Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms References: <200304012027.29229.raif@fl.net.au> From: Sam Hartman Date: Tue, 01 Apr 2003 11:29:56 -0500 In-Reply-To: <200304012027.29229.raif@fl.net.au> ("Raif S. Naffah"'s message of "Tue, 1 Apr 2003 21:27:26 +1100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Raif" == Raif S Naffah writes: Raif> hello there, can someone calrify the following: Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a Raif> needed transformation for authentication identities Raif> (usernames) and passwords, in preference to something like: Raif> MUST be in Unicode Normalization Form KC [UNICODE-KC] Raif> without NUL characters. Please read the stringprep document; it has a good discussion of the elements that go into a stringprep profile and I believe why they are needed. If this is insufficient, please look at old minutes of the IDN working group and their archived mailing list. Note that mechanisms do not need to use the saslprep profile. They need to adopt a stringprep profile that is appropriate for the mechanism in question. For example anonymous uses a much less restrictive profile. Mechanisms using cryptography will tend to need fairly strong canonicalization rules to make sure that usernames and passwords typed with one set of input methods are handled the same when typed with a different set of methods. Raif> wouldn't a transformation such as the SASLPrep be part of Raif> the SASL Profile itself rather than the Mechanism(s)? If by SASL profile, you mean the profile for an application, no. The form of authentication identifiers and other mechanism-specific strings such as passwords is entirely a matter for the mechanism. As an example, Kerberos will mandate a particular stringprep profile for principals and passwords. In order for things to work, the SASL GSSAPI mechanism for Kerberos must use the same stringprep profile. Raif> 2. what is the consensus on specifying/handling Raif> authorization identities for transportation on the wire? is Raif> [UNICODE-KC] enough? The authorization identity is a matter for the application's SASL profile. In many cases, the same constraints will apply to authorization identities as authentication identities. The transformation may end up being server-side rather than client-side, but will likely still be needed. I think we would prefer that application profiles seriously consider the use of saslprep for authorization identifiers, but it is not right for all environments. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31AYxJM008519 for ; Tue, 1 Apr 2003 02:34:59 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31AYxQj008518 for ietf-sasl-bks; Tue, 1 Apr 2003 02:34:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-sasl@mail.imc.org using -f Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31AYvJM008508 for ; Tue, 1 Apr 2003 02:34:57 -0800 (PST) Received: from solomon (a5-p20.syd.fl.net.au [202.181.2.20]) by delenn.fl.net.au (Postfix) with ESMTP id 5D9A8180570 for ; Tue, 1 Apr 2003 20:33:04 +1000 (EST) Content-Type: text/plain; charset="us-ascii" From: "Raif S. Naffah" Reply-To: raif@fl.net.au To: SASL Subject: authentication and authorization identities, and passwords in SASL Mechanisms Date: Tue, 1 Apr 2003 21:27:26 +1100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200304012027.29229.raif@fl.net.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31AYwJM008513 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hello there, can someone calrify the following: 1. why does a SASL Mechanism has to mandate SASLPrep as a needed transformation for authentication identities (usernames) and passwords, in preference to something like: MUST be in Unicode Normalization Form KC [UNICODE-KC] without NUL characters. wouldn't a transformation such as the SASLPrep be part of the SASL Profile itself rather than the Mechanism(s)? 2. what is the consensus on specifying/handling authorization identities for transportation on the wire? is [UNICODE-KC] enough? TIA + cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+iWmO+e1AKnsTRiERAwZNAJ4r/AOu++oWkA3ppSCnjmjWGYyXwwCg6zSh W1bU3OxBgrU8PFNyefvnlWw= =Yob+ -----END PGP SIGNATURE-----