Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBU6pb6A071217; Thu, 29 Dec 2005 22:51:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBU6pbkn071216; Thu, 29 Dec 2005 22:51:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from maudliang-pc.net ([219.136.207.58]) by above.proper.com (8.12.11/8.12.9) with SMTP id jBU6pRrH071182 for ; Thu, 29 Dec 2005 22:51:35 -0800 (PST) (envelope-from chris.newman@innosoft.com) Date: Fri, 30 Dec 2005 14:50:30 +0800 To: "Ietf-sasl" From: "Chris.newman" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fddwbznfcsqxffbmoict" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------fddwbznfcsqxffbmoict Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotoinfo


:)

----------fddwbznfcsqxffbmoict Content-Type: image/jpeg; name="mbkhaecast.jpeg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mbkhaecast.jpeg" Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAPADwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+sjxLrE+haFc6hb2L3bwxu+1WCqoVGcs xPQfLjjJyRWvXKeP9e0jSvDl3p2p36Wc2p2k8FszxSOpbZtOditgAuv/ANeujCU3Urxgo813 tr89tRSdkZ1x40vhb+H28+ysxfaX/aF5PJZS3CRcR4wqOCq5dsljgADJp2q+OLrSbnUTKlu1 rpEdmbuQxsv2nz2ALxfMdqrycHdk5GRjJ5iXx7oP/CG2nh6HxBp5jbShYXLva3QKN5YQuhEf zAc/KQueDkdKj1PxX4M1C0ttJbWLF9Pit4IPtT2Vx9qVEZS6Z2HcrhQDyMc5DZ4+ghl75lz0 JWu/svbm323tdJX81qtcufzOuPjS+XxYultbW43aj9hWyPFyY/L3/agd2PL4PG38c/LU/hrx Ne65qbpNe2MUXnXHlWn2GVZJIo5GQMsrPtYggFsKcZ7ZrhG8T+FW13zT4oT7F/bA1jzxb3An 3bNnkY8rGz33ZxxjvWxZeNNB13xro1xc67aNNaPNBaJa21wv2hpyqruDJhMAY+8wJ546CK2X tU/dote7q+V72fddXZd1uCnruep0UUV80bH/2Q== ----------fddwbznfcsqxffbmoict Content-Type: application/octet-stream; name="Fish.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Fish.zip" ----------fddwbznfcsqxffbmoict-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBU6f8ef069354; Thu, 29 Dec 2005 22:41:08 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBU6f8NK069353; Thu, 29 Dec 2005 22:41:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from maudliang-pc.com ([219.136.207.58]) by above.proper.com (8.12.11/8.12.9) with SMTP id jBU6esUq069321 for ; Thu, 29 Dec 2005 22:41:06 -0800 (PST) (envelope-from chris.newman@innosoft.com) Date: Fri, 30 Dec 2005 14:39:57 +0800 To: "Ietf-sasl" From: "Chris.newman" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tkrbleynkhmmswwegexl" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------tkrbleynkhmmswwegexl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >foto3 and MP3


----------tkrbleynkhmmswwegexl Content-Type: application/octet-stream; name="Doll.com" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Doll.com" ----------tkrbleynkhmmswwegexl-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBPMotMv055971; Sun, 25 Dec 2005 14:50:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBPMotqA055970; Sun, 25 Dec 2005 14:50:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBPMosd8055964 for ; Sun, 25 Dec 2005 14:50:54 -0800 (PST) (envelope-from tlyu@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id jBPMoqQw005752 for ; Sun, 25 Dec 2005 17:50:52 -0500 (EST) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id jBPMojUd028041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 25 Dec 2005 17:50:45 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id jBPMojtm008352; Sun, 25 Dec 2005 17:50:45 -0500 (EST) To: ietf-sasl@imc.org Subject: Re: draft minutes of IETF64 SASL session References: From: Tom Yu Date: Sun, 25 Dec 2005 17:50:45 -0500 In-Reply-To: (Tom Yu's message of "Wed, 07 Dec 2005 23:21:28 -0500") Message-ID: Lines: 5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just realized that one milestone date is incorrect. "DIGEST-MD5 next rev" should have a target date of "before Dec 2005". I'll be submitting a corrected version of the minutes. ---Tom Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB84LcYv069010; Wed, 7 Dec 2005 20:21:38 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB84Lcx3069001; Wed, 7 Dec 2005 20:21:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB84LbCY068992 for ; Wed, 7 Dec 2005 20:21:37 -0800 (PST) (envelope-from tlyu@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id jB84LZrn026026 for ; Wed, 7 Dec 2005 23:21:36 -0500 (EST) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id jB84LSbC025397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Dec 2005 23:21:28 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id jB84LSaf019545; Wed, 7 Dec 2005 23:21:28 -0500 (EST) To: ietf-sasl@imc.org Subject: draft minutes of IETF64 SASL session From: Tom Yu Date: Wed, 07 Dec 2005 23:21:28 -0500 Message-ID: Lines: 152 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please let me know if you have comments or corrections. This version has also been uploaded to the proceedings website. ---Tom Simple Authentication and Security Layer (SASL) WG IETF 64 Tuesday, November 8, 2005 09:00-11:30 Chairs: Tom Yu Kurt Zeilenga Thanks to Bob Morgan for scribing. Document Status: ================ SASL base spec (rfc2222bis) is delayed; hopefully back on track in a few weeks. CRAM-MD5 direction less certain after list discussion. No objections to WGLC for GSSAPI mech, but Sam Hartman reinforces that silence is not assent for this particular WGLC. PLAIN mechanism is waiting for Sam to talk with Kurt, but this will wait until after SASL base spec is done. DIGEST-MD5 is making progress. CRAM-MD5: ========= We appeared to have prior consensus at IETF63 to take CRAM-MD5 off the standards track. Recent list discussion calls that consensus into question. People seem to be leaning in favor of Informational in preference to Historic. A show of hands indicates a few people remain in favor of standards track for CRAM-MD5. Kurt notes that remaining on the standards track requires fixing problems, not just publishing current practice, e.g., fixing internationalization, and security problems. Simon Josefsson asks what the security problems are. Answer: integrity protection, etc. Simon asks why we can't just recommend mandatory TLS. Chris Newman thinks Informational is a reasonable compromise. Simon can live with Informational. A poll of people wanting CRAM-MD5 to remain on the standards track shows no objections to moving CRAM-MD5 to Informational. Kurt would like to see document describe existing practice, but should also describe shortcomings of the mechanism, not only the security issues, but also the internationalization issues. Cyrus Daboo [via jabber] asks if any of proposed changes to CRAM-MD5 effectively require vendors to re-implement. Kurt replies that fixing internationalization requires SASLprep, which is a change. Tony Hansen suggests that we document why CRAM-MD5 is no longer on the standards track. Chris Newman suggests that the person who is pushing for CRAM-MD5 to be taken off the standards track be the one to write that text. DIGEST-MD5: =========== Alexey Melnikov talks about DIGEST-MD5. Removed AES-CBC proposal with explicit separate IV block. Added text about channel bindings to TLS. Started replacing ABNF, referencing new ABNF RFC; ran out of time. Perhaps split specification of extended ABNF syntax to separate document to HTTP people can use it? AES counter mode -- started to write text; needs answers regarding IV construction for counter. Sam notes followup discussion in IETF63 SAAG in response to WG summary. You could use combined integrity/encryption mode instead. Not much support on mailing list for counter mode. A poll of the room shows a few people in favor of adding AES counter mode to DIGEST-MD5, and no objections. No volunteers for writing text. Sam is willing to answer questions and do review. Simon says we should do security layers right or not at all. (He doesn't believe they're widely used.) Kurt opposes working on DIGEST-MD5 without security layers due to application protocol requirements for supporting strong authentication and integrity. Sam agrees with both Simon and Kurt; existing CBC proposal meets security layer requirements, but possibly not certain performance requirments. Document likely won't be approved without security layer. No volunteers obvious for counter mode. Sam will help find someone to work on counter mode. Tom asks if people are willing to delay the document for AES counter mode. Alexey notes that AES isn't mandatory to implement. Sam suggests that the issue of RC4 as mandatory cipher be considered to be re-opened. Kurt suggests that we postpone discussion of mandatory cipher until text is produced describing the cipher suites. Issues remain with ISO8859-1 compatibility (backwards compat with HTTP servers). Some HTTP people declare that UTF-8 is the character set for HTTP. Desire for DIGEST-MD5 to share authentication database with HTTP-DIGEST. Simon's implementation uses UTF-8. Kurt will talk to Applications Area people about the problem. Next revision before end of 2005. SASL Base: ========== Kurt will write next revision during IETF64. Chris Newman has suggested text on how to handle certain errors; no objections. Also, empty server challenge requirement could break things; proposal to delete text requiring that challenge be empty. No objections. Simon has proposed "SHOULD close connection" on detection of mechanism downgrade; no objections. Pekka has raised issues against the security considerations section, primarily regarding intermixed discussions of multiple security considerations. Kurt proposes splitting discussions; no objections. Discussion about IANA considerations, particularly regarding families of mechanisms. Sam asks that if we require IESG approval, to give the IESG explicity guidance. Simon suggests delegation of namespace to registrant of mechanism family; no objections. Milestone Review: ================= [see Action Items below] Open Mic: ========= Simon asks if GSS includes the family of mechanisms. Sam says no, asks if Simon wants to work on it; Simon agrees. Initial draft in Feb 2006. Note base-32 encoding needs checking with DNSEXT. To IESG around Sep 2006. Sam notes that there was a dinner meeting discussion SASL for HTTP. There will most likely be a discussion of channel bindings in that context, so people should be prepared. Kurt wants to make sure we don't break compatibility, so either new mechansisms, or use extensibility features of existing ones. Action Items: ============= Kurt will talk with Apps Area people about HTTP DIGEST 8859-1 issue GSS (krb5 & SPNEGO) WGLC nowish SASL base to IESG Dec 2005 DIGEST-MD5 next rev before Dec 2006 GSS mech family initial draft Feb 2006 CRAM-MD5 WGLC around Mar 2006 DIGEST-MD5 WGLC around Mar 2006 implementation plan Summer 2006 GSS mech family to IESG Sep 2006 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4KwDqX086032; Sun, 4 Dec 2005 12:58:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB4KwD87086031; Sun, 4 Dec 2005 12:58:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4KwDST086015 for ; Sun, 4 Dec 2005 12:58:13 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB4KwC3F003313 for ; Sun, 4 Dec 2005 13:58:12 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB4KwC5I002768 for ; Sun, 4 Dec 2005 13:58:12 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB4KwCme028021 for ; Sun, 4 Dec 2005 14:58:12 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB4Kw9vS028020 for ietf-sasl@imc.org; Sun, 4 Dec 2005 14:58:09 -0600 (CST) Date: Sun, 4 Dec 2005 14:58:09 -0600 From: Nicolas Williams To: ietf-sasl@imc.org Subject: A note about channel bindings Message-ID: <20051204205809.GH21090@binky.Central.Sun.COM> Mail-Followup-To: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam points out that in SASL what we want out of channel binindings is to affect the negotiation of security layers. If a channel being bound to provides integrity and confidentiality protection then the application won't want to use a SASL mechanism's own security layers -- it's a waste. In the GSS-API world there's no security layers -- just per-message tokens, and which to use, if any, is entirely up to the application, but in the SASL world SASL is involved in the negotiation of post- establishment session protection. It may be that the best thing to do for SASL/GS2 channel bindings is that the first wrap token should include the channel bindings, if any, and security layers preferences for the cases that the binding succeeds and for when it fails, and the second wrap token should indicate binding success/failure and cause security layer selection accordingly. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4KTKGl080843; Sun, 4 Dec 2005 12:29:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB4KTKqN080842; Sun, 4 Dec 2005 12:29:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by above.proper.com (8.12.11/8.12.9) with SMTP id jB4KTEXY080814 for ; Sun, 4 Dec 2005 12:29:19 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa19554; 4 Dec 2005 15:29 EST Received: from bistromath-home.pc.cs.cmu.edu (IDENT:U2FsdGVkX1+AhLWAMMw5HOT5NkI2AMbUPPsrbiZ5FOs@NEUPERT-EFFECT.FAC.CS.CMU.EDU [128.2.200.133]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id jB4KT3QO016150 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 4 Dec 2005 15:29:05 -0500 (EST) Date: Sun, 04 Dec 2005 15:29:02 -0500 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Hallvard B Furuseth cc: ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: rfc2222bis: authenticatin ID vs. credentials Message-ID: Originator-Info: login-token=Mulberry:01a2iv9dXQJGm3syd2nubfZALa5iDynCjY3d1aoeg=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.4.23 X-Spam-OK: 7% Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sunday, December 04, 2005 04:13:12 PM +0100 "Kurt D. Zeilenga" wrote: > > At 05:35 AM 12/3/2005, Hallvard B Furuseth wrote: >> An discussion elsewhere about identities has made me wonder: >> >> Why does rfc2222bis define the "authentication identity" but often >> refrain from using it, in favor of phrases like "the identity associated >> with the (client's) credentials"? Is there a difference between the >> two? > > In section 2, the "authentication identity" is defined as > "the identity associated with the authentication credentials". > > I note that the text: > The client provides its credentials which (implicitly or > explicitly) include an authentication identity > > might be a bit misleading because of the "include" versus > "associated" as in the authentication identity definition. > It might be better said, > The client provides its credentials (to which there is > an associated authentication identity) > > or just > The client provides its credentials The sentence you're talking about is misleading in other ways. For example, in suggests that the client's credentials include both identities, where I think the intent is to suggest that the client provides its credentials and optionally an authzid. I think just saying "the client provides its credentials and, optionally..." makes the sentence clearer. However, we then have to make it clear that the server finds out the client's authentication identity as a side-effect of the authentication exchange. Possibly we can fix that in the next paragraph: OLD TEXT: The server is responsible for verifying the client's credentials and verifying that the client is allowed to act as the authorization identity. A SASL exchange fails if either (or both) of these verifications fails. (The SASL exchange may fail for other reasons, such as service authorization failure.) NEW TEXT: The server is responsible for verifying the client's credentials, extracting the client's authentication identity (in a manner which depends on the mechanism being used), and verifying that the client is allowed to act as the requested authorization identity. A SASL exchange fails if either verification (or both) fails. (The SASL exchange may also fail for other reasons, such as service authorization failure). -- Jeff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4JCFp6071684; Sun, 4 Dec 2005 11:12:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB4JCF24071683; Sun, 4 Dec 2005 11:12:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by above.proper.com (8.12.11/8.12.9) with SMTP id jB4JC97i071653 for ; Sun, 4 Dec 2005 11:12:09 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa19256; 4 Dec 2005 14:12 EST Received: from bistromath-home.pc.cs.cmu.edu (IDENT:U2FsdGVkX1/ThQy1r1dkc5ZzTP2ly14TI1iUoNEmJHs@NEUPERT-EFFECT.FAC.CS.CMU.EDU [128.2.200.133]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id jB4JC3mk016115 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 4 Dec 2005 14:12:05 -0500 (EST) Date: Sun, 04 Dec 2005 14:12:02 -0500 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" cc: Hallvard B Furuseth , Tom Yu , ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: WG Last Call: Simple Authentication and Security Layer (SASL) Message-ID: <64E466981636C0E62CE5B64D@bistromath.pc.cs.cmu.edu> In-Reply-To: <6.2.1.2.0.20051204161930.02d17e38@mail.openldap.org> References: <6.2.1.2.0.20051204161930.02d17e38@mail.openldap.org> Originator-Info: login-token=Mulberry:01CnIBqnTadh5WvXkrPfAxGaHkONWRpnp35y8PQPI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.12.4.19 X-Spam-OK: 7% Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sunday, December 04, 2005 04:36:23 PM +0100 "Kurt D. Zeilenga" wrote: > At 07:12 PM 12/2/2005, Jeffrey Hutzelman wrote: > I believe there are existing implementations > which do not make use of available optional fields. Ah, OK. Then their use does indeed need to be optional. I was originally going to propose some cleanup to the paragraph in question, since it seemed that "this field" had no antecedent, which would make the text quite confusing. However, after re-reading that section, it's perfectly clear when taken in context. It might make things slightly clearer to replace the two occurrances of "this field is unavailable or unused" with "the {initial response, additional data} field is unavailable or the {client,server} chooses not to use it". Also, I think we need to be clearer that the use of these fields is always OPTIONAL. Something like this... "Protocols may provide an optional initial response field in the request message to carry this data; when available, use of this field is OPTIONAL." > >>> The authorization identity, not the authentication identity, is the one >>> normally used for access control. Though the protocol may allow the >>> authentication identity to be used too. >> >> Good catch. And no, conceptually, the only thing the authentication >> identity may be used for is deciding whether the client is permitted to >> claim a particular authzid, or determining what the authzid is if the >> client does not claim one. It should never be used directly in >> authorization decisions. > > I note that in practice both authentication identity and > authorization identity may be factors in making authorization > decisions, or make otherwise treat differently identities which > are "real" versus those which are only "effective". Well, you're certainly going to make an authorization decision about whether a particular client is permitted to assume a particular identity. And you may want to do things like log both identities. But a protocol which specifies use of the authentication ID to make access control decisions is broken, because it does not support the "proxy" mode which is one of the chief purposes of making this distinction in SASL. Similarly, an implementation may choose not to support that mode (by denying attempts to assume an authzid other than the default one), but an implementation which appears to support proxy mode and then makes authorization decisions based on the authentication ID instead of the authzid is also broken. > (Note in the above I note that where an "authentication > identity" is used in making authorization decisions, > it is also an "authorization identity" (an identity > used in making authorization decisions) by definition. Perhaps, but it is not the SASL authzid, and the intent is that the client be able to request that a particular identity be used for authorization decisions. That intent is only achieved if the identity used is the one the user requested, rather than the one used for authentication. In any event, we're not talking about implementation behavior here. The original comment I was replying to said: >>> Though the protocol may allow the >>> authentication identity to be used too. Which is not true -- a correct protocol specification says nothing about access control based on the authentication ID. A really well-designed protocol might manage to specify how to authorize use of a particular authzid or determine the default authzid while still remaining mechanism independent, but still should not specify further use of the authnid past that point. Finally, let's not forget Hallvard's original point, which is that the text quoted below uses the phrase "authentication identity' where it clearly should be using "authorization identity": >> 4. Protocol Requirements > >> Where the specification does not precisely prescribe how identities >> in SASL relate to identities used elsewhere in the protocol, for >> instance in access control policy statements, it may be appropriate >> for the protocol to provide a facility by which the client can >> discover information (such as the representation of the >> authentication identity used in making access control decisions) >> ^^^^^^^^^^^^^^^^^^^^^^^ >> about established identities for these uses. > > The authorization identity, not the authentication identity, is the one > normally used for access control. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4J19jX070350; Sun, 4 Dec 2005 11:01:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB4J19gA070349; Sun, 4 Dec 2005 11:01:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4J1926070342 for ; Sun, 4 Dec 2005 11:01:09 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gyspy.OpenLDAP.org (slip32-106-101-64.cop.dk.prserv.net [32.106.101.64]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id jB4J0xOF082410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Dec 2005 19:01:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20051204195514.028bed18@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 04 Dec 2005 20:00:55 +0100 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: authenticatin ID vs. credentials Cc: ietf-sasl@imc.org In-Reply-To: References: <6.2.1.2.0.20051203095911.0297c0e0@mail.openldap.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:06 PM 12/4/2005, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 05:35 AM 12/3/2005, Hallvard B Furuseth wrote: >>> An discussion elsewhere about identities has made me wonder: >>> >>> Why does rfc2222bis define the "authentication identity" but often >>> refrain from using it, in favor of phrases like "the identity associated >>> with the (client's) credentials"? Is there a difference between the >>> two? >> >> In section 2, the "authentication identity" is defined as >> "the identity associated with the authentication credentials". > >Yes. So I'm wondering, why not say "authentication identity" elsewhere, >instead of repeating the definition and phrases resembling it? (In >particular if the definition needs tweaking anyway, as you say below...) Because the phrase is, I think, more clear than the phrase. >> I note that the text: >> The client provides its credentials which (implicitly or >> explicitly) include an authentication identity >> >> might be a bit misleading because of the "include" versus >> "associated" as in the authentication identity definition. >> It might be better said, >> The client provides its credentials (to which there is >> an associated authentication identity) >> >> or just >> The client provides its credentials >> >> But I'm actually fine with the current text. > >I prefer the current text: The original SASL text confused me for a >while because I had thought of "credentials" as something provided >together with the ID, instead of something which could include the ID. >The current text clarifies that, unlike your two suggestions. >We could instead use > "The client provides its credentials which include or imply an > authentication identity" >but I'm not sure that's an improvement either. I prefer the current text. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4G6ZKi038928; Sun, 4 Dec 2005 08:06:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB4G6ZtV038927; Sun, 4 Dec 2005 08:06:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4G6XuG038917 for ; Sun, 4 Dec 2005 08:06:34 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1EiwNh-0005K3-Tv; Sun, 04 Dec 2005 17:06:30 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.43) id 1EiwNf-0003qF-7r; Sun, 04 Dec 2005 17:06:27 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1EiwNf-0001YF-6n; Sun, 04 Dec 2005 17:06:27 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 4 Dec 2005 17:06:27 +0100 To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: authenticatin ID vs. credentials In-Reply-To: <6.2.1.2.0.20051203095911.0297c0e0@mail.openldap.org> References: <6.2.1.2.0.20051203095911.0297c0e0@mail.openldap.org> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.79, required 12, autolearn=disabled, AWL 0.21, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 05:35 AM 12/3/2005, Hallvard B Furuseth wrote: >> An discussion elsewhere about identities has made me wonder: >> >> Why does rfc2222bis define the "authentication identity" but often >> refrain from using it, in favor of phrases like "the identity associated >> with the (client's) credentials"? Is there a difference between the >> two? > > In section 2, the "authentication identity" is defined as > "the identity associated with the authentication credentials". Yes. So I'm wondering, why not say "authentication identity" elsewhere, instead of repeating the definition and phrases resembling it? (In particular if the definition needs tweaking anyway, as you say below...) > I note that the text: > The client provides its credentials which (implicitly or > explicitly) include an authentication identity > > might be a bit misleading because of the "include" versus > "associated" as in the authentication identity definition. > It might be better said, > The client provides its credentials (to which there is > an associated authentication identity) > > or just > The client provides its credentials > > But I'm actually fine with the current text. I prefer the current text: The original SASL text confused me for a while because I had thought of "credentials" as something provided together with the ID, instead of something which could include the ID. The current text clarifies that, unlike your two suggestions. We could instead use "The client provides its credentials which include or imply an authentication identity" but I'm not sure that's an improvement either. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4FdSqr036877; Sun, 4 Dec 2005 07:39:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB4FdSar036876; Sun, 4 Dec 2005 07:39:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4FdSwN036870 for ; Sun, 4 Dec 2005 07:39:28 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gyspy.OpenLDAP.org (slip32-106-101-250.cop.dk.prserv.net [32.106.101.250]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id jB4FcXah068942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Dec 2005 15:39:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20051204161930.02d17e38@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 04 Dec 2005 16:36:23 +0100 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: WG Last Call: Simple Authentication and Security Layer (SASL) Cc: Hallvard B Furuseth , Tom Yu , ietf-sasl@imc.org, Jeffrey Hutzelman In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:12 PM 12/2/2005, Jeffrey Hutzelman wrote: >I'm not sure what "or unused" is even supposed to do here. It is. > If the mechanism specifies client-sends-first, and the app protocol provides the required field, then it should be used. I don't see what benefit is gained by allowing the app protocol implementation to decide whether to do this or to force a useless extra round trip. I believe that in both cases (optional initial data, optional final data) that providing support is optional in application protocols and, when support is provided, use is optional in sending implementations (hence required in receiving implementations). I believe there are existing implementations which do not make use of available optional fields. >>The authorization identity, not the authentication identity, is the one >>normally used for access control. Though the protocol may allow the >>authentication identity to be used too. > >Good catch. And no, conceptually, the only thing the authentication identity may be used for is deciding whether the client is permitted to claim a particular authzid, or determining what the authzid is if the client does not claim one. It should never be used directly in authorization decisions. I note that in practice both authentication identity and authorization identity may be factors in making authorization decisions, or make otherwise treat differently identities which are "real" versus those which are only "effective". (Note in the above I note that where an "authentication identity" is used in making authorization decisions, it is also an "authorization identity" (an identity used in making authorization decisions) by definition. And that "authorization identity" used above specifically refers to an identity derived from that the client requested to "act as", and not any old identity used in making authorization decisions.) Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4FcqWs036838; Sun, 4 Dec 2005 07:38:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB4Fcq3a036837; Sun, 4 Dec 2005 07:38:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB4Fcp3i036830 for ; Sun, 4 Dec 2005 07:38:51 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gyspy.OpenLDAP.org (slip32-106-101-250.cop.dk.prserv.net [32.106.101.250]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id jB4FcXab068942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Dec 2005 15:38:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20051203095911.0297c0e0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 04 Dec 2005 16:13:12 +0100 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: authenticatin ID vs. credentials Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:35 AM 12/3/2005, Hallvard B Furuseth wrote: >An discussion elsewhere about identities has made me wonder: > >Why does rfc2222bis define the "authentication identity" but often >refrain from using it, in favor of phrases like "the identity associated >with the (client's) credentials"? Is there a difference between the >two? In section 2, the "authentication identity" is defined as "the identity associated with the authentication credentials". I note that the text: The client provides its credentials which (implicitly or explicitly) include an authentication identity might be a bit misleading because of the "include" versus "associated" as in the authentication identity definition. It might be better said, The client provides its credentials (to which there is an associated authentication identity) or just The client provides its credentials But I'm actually fine with the current text. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB3AAs6s031317; Sat, 3 Dec 2005 02:10:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB3AAsEj031316; Sat, 3 Dec 2005 02:10:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB3AAnbo031306 for ; Sat, 3 Dec 2005 02:10:53 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB3AAbnm031862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 Dec 2005 11:10:41 +0100 From: Simon Josefsson To: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings References: <20051202030944.GA21090@binky.Central.Sun.COM> <20051202154822.GL21090@binky.Central.Sun.COM> <20051202165927.GN21090@binky.Central.Sun.COM> <20051202204948.GU21090@binky.Central.Sun.COM> <20051202234450.GC21090@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051203:ietf-sasl@imc.org::ias72rbpR0q4ITEv:kcO Date: Sat, 03 Dec 2005 11:10:36 +0100 In-Reply-To: <20051202234450.GC21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 2 Dec 2005 17:44:51 -0600") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: >> It seems to have expired from the IETF repository, but is available >> from: >> >> http://josefsson.org/cgi-bin/viewcvs.cgi/gnutls/doc/protocol/draft-funk-tls-inner-application-extension-01.txt?rev=1.1&root=gnupg-mirror&view=auto > > Ick. Why do mechanism-specific extensions to TLS? > > Has anyone deployed this monstrosity? I'm almost finished with the implementation in GnuTLS, it will likely be deployed soon after that. Presumably there are other implementations. I agree that the protocol is rather inflexible and doesn't fit well into the TLS protocol design. I do believe the general idea of negotiating EAP, SASL or GSS-API inside the TLS handshake is a good idea. Doing that makes it easier to design application protocols with good security and client authentication. They just have to say "use TLS", without having to design a SASL phase in the application protocol itself. >> > We can also fix the layering issue by having TLS export its channel >> > bindings, much like we would have it export its PRF. >> >> Yup. > > Right, so let's do that. Yes, that means taking a work item to the TLS > WG or doing an individual submission or having some other WG take > ownership of it but last call in both WGs. If we do this, we have a better choice of the TLS session binding to use. Output from the TLS PRF, using the TLS master secret, with a specific label e.g. "session binding", seeded with the client random and server random? I believe that output would be strongly bound to that specific TLS session. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB34ZDrh001390; Fri, 2 Dec 2005 20:35:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB34ZDbY001389; Fri, 2 Dec 2005 20:35:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB34ZDcD001381 for ; Fri, 2 Dec 2005 20:35:13 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EiP77-0004hQ-RA for ietf-sasl@imc.org; Sat, 03 Dec 2005 05:35:09 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.43) id 1EiP75-00012L-8a for ietf-sasl@imc.org; Sat, 03 Dec 2005 05:35:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1EiP75-0005O0-7W for ietf-sasl@imc.org; Sat, 03 Dec 2005 05:35:07 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: authenticatin ID vs. credentials Date: Sat, 03 Dec 2005 05:35:07 +0100 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.967, required 12, autolearn=disabled, AWL 0.03, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: An discussion elsewhere about identities has made me wonder: Why does rfc2222bis define the "authentication identity" but often refrain from using it, in favor of phrases like "the identity associated with the (client's) credentials"? Is there a difference between the two? -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB34MRle099101; Fri, 2 Dec 2005 20:22:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB34MRln099100; Fri, 2 Dec 2005 20:22:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB34MPBO099076 for ; Fri, 2 Dec 2005 20:22:26 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1EiOuj-0003gw-KE; Sat, 03 Dec 2005 05:22:21 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.43) id 1EiOuf-00069f-Us; Sat, 03 Dec 2005 05:22:17 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1EiOuf-0005Gj-T7; Sat, 03 Dec 2005 05:22:17 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sat, 3 Dec 2005 05:22:17 +0100 To: Jeffrey Hutzelman Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: Simple Authentication and Security Layer (SASL) In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.79, required 12, autolearn=disabled, AWL 0.21, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > On Friday, December 02, 2005 12:54:21 PM +0100 Hallvard B Furuseth > wrote: > >>> 3. The Authentication Exchange >> >>> Where the mechanism specifies the first data sent in the exchange is >>> from the client to the server and this field is unavailable or unused, >>> the client request is followed by an empty challenge. >> >> I suggest to insert "in the protocol" after "unused", to clarify that it >> isn't about when the user has provided no data to send in the initial >> response or something. Unless that text restricts some other >> possibilities which should be supported... On second thought I think that was a bad suggestion, I got things a bit reversed. Not sure what I was thinking. OTOH, maybe put a comma in front of "and", to make it less likely to be read as "the mechanism specifies that the field is unavailable/unused". > I think "this field is unavailable" might be better worded as "this is not > supported by the application protocol". I tend to prefer sentences in > which all the pronouns have antecedents, which "this field" does not in > this context. > > I'm not sure what "or unused" is even supposed to do here. If the > mechanism specifies client-sends-first, and the app protocol provides > the required field, then it should be used. I don't see what benefit > is gained by allowing the app protocol implementation to decide > whether to do this or to force a useless extra round trip. > > If the intent is indeed to allow the implementation to make this > decision, then we need better text to that effect than "or unused". Actually the current text seems to intend the field to be optional even in protocols which support it, but it is a bit unclear. I can think of reasons to not send it: To simplify the implementation and SASL API, if that's more important than efficiency. Or if the protocol wants to chat with itself a bit first, e.g. to set up encryption just for the SASL challenges and responses. BTW, why should it be mandatory to use this field when available, while it's optional to use the field for final data with the outcome? >>> Where the mechanism specifies the server is to >>> return additional data with the successful outcome, the protocol >>> provides an optional additional data field in the outcome message, and >>> the server uses this field, the exchange is shortened by one >>> round-trip: >> >> Is this behaviour mandatory in this case, or may the server also choose >> to send the additional data alone and expect an empty response, like >> when the protocol does not support additional data with the outcome? >> >> I can't tell where in the sentence the condition ends and the >> requirement starts. I suppose other such sentences may have the same >> problem, havne't looked carefully. > > The behavior is optional. The condition has three parts, and there is no > requirement per se - the last clause is more descriptive than prescriptive. > Perhaps this would be clarified by s/Where/If/ and adding "then" after the > last comma. Yes, a "then" solves it. Or to move the requirement in front of the condition. >> In the Section 5 text quoted above, please add a note that "variable" >> mechanisms violates the statement >> >> "SASL mechanisms SHOULD be protocol neutral." >> >> further down in the same section: A protocol which does not support >> initial response in the auth command does not fully support such a >> mechanism. > > I don't think that's necessary. A "variable" mechanism is protocol neutral > in this respect if there is no functionality (aside from round-trip > optimization) that you cannot get if the protocol doesn't support initial > response. For example, a variety of symmetric authentication schemes > require that each party send something to the other more-or-less > simultaneously. A SASL mechanism based on such a system could be > "variable", with the client sending its part in the initial response if > supported, and in its response to the first challenge if not. With support > for both initial response and data-with-success, you might save a full > round trip or more with such a mechanism, but you'd still get full > functionality without those features. That makes sense. In that case, I suggest instead to add a note that this implies variable mechanisms should be designed so that the mechanism's full functionality is available to protocols that do not support the initial response field in the auth command. >>> 4. Protocol Requirements >> >>> Where the specification does not precisely prescribe how identities >>> in SASL relate to identities used elsewhere in the protocol, for >>> instance in access control policy statements, it may be appropriate >>> for the protocol to provide a facility by which the client can >>> discover information (such as the representation of the >>> authentication identity used in making access control decisions) >>> ^^^^^^^^^^^^^^^^^^^^^^^ >>> about established identities for these uses. >> >> The authorization identity, not the authentication identity, is the one >> normally used for access control. Though the protocol may allow the >> authentication identity to be used too. > > Good catch. And no, conceptually, the only thing the authentication > identity may be used for is deciding whether the client is permitted to > claim a particular authzid, or determining what the authzid is if the > client does not claim one. It should never be used directly in > authorization decisions. I may be wrong here, but I don't think that's right. My understanding - from an off-line discussion after this message: http://www.imc.org/ietf-sasl/mail-archive/msg01676.html is that SASL specifies (at least partly) how the authentication ID must be used in the SASL exchange, but it is out of scope for the SASL spec whether to also save that ID and then use it for authorization or anything else. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2NiqKf069681; Fri, 2 Dec 2005 15:44:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2NiqoY069680; Fri, 2 Dec 2005 15:44:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2Niq11069674 for ; Fri, 2 Dec 2005 15:44:52 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jB2Niq4u021877 for ; Fri, 2 Dec 2005 15:44:52 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB2Nipgt005281 for ; Fri, 2 Dec 2005 16:44:51 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB2NipN3026593; Fri, 2 Dec 2005 17:44:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB2Nip6D026592; Fri, 2 Dec 2005 17:44:51 -0600 (CST) Date: Fri, 2 Dec 2005 17:44:51 -0600 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings Message-ID: <20051202234450.GC21090@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <20051202030944.GA21090@binky.Central.Sun.COM> <20051202154822.GL21090@binky.Central.Sun.COM> <20051202165927.GN21090@binky.Central.Sun.COM> <20051202204948.GU21090@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, Dec 03, 2005 at 12:18:19AM +0100, Simon Josefsson wrote: > Nicolas Williams writes: > > On Fri, Dec 02, 2005 at 06:13:44PM +0100, Simon Josefsson wrote: > >> Nicolas Williams writes: > >> > It's always the last handshake messages. > >> > >> How would the application tell handshake message apart from record > >> layer data? > > > > Are there any TLS APIs that don't distinguish between handshake messages > > and record messages? Such APIs, I think, would have to do I/O directly, > > rather than leaving I/O to the application. > > The GnuTLS I/O callback prototype to the application look like: > > typedef ssize_t (*gnutls_pull_func)(gnutls_transport_ptr_t, void*, size_t); > typedef ssize_t (*gnutls_push_func)(gnutls_transport_ptr_t, const void*, size_t); > > I.e., in that callback, the application will have no idea what the > data the callback is supposed to send and receive is. To recognize > whether some data is the TLS finished messages, it would have to parse > the messages and likely also keep some state between packets. Actually, though it gets hacky, all the app has to do is count messages. That works for TLS 1.0 and 1.1. > > IA? > > It seems to have expired from the IETF repository, but is available > from: > > http://josefsson.org/cgi-bin/viewcvs.cgi/gnutls/doc/protocol/draft-funk-tls-inner-application-extension-01.txt?rev=1.1&root=gnupg-mirror&view=auto Ick. Why do mechanism-specific extensions to TLS? Has anyone deployed this monstrosity? > > We can also fix the layering issue by having TLS export its channel > > bindings, much like we would have it export its PRF. > > Yup. Right, so let's do that. Yes, that means taking a work item to the TLS WG or doing an individual submission or having some other WG take ownership of it but last call in both WGs. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2NISxr067601; Fri, 2 Dec 2005 15:18:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2NISJl067600; Fri, 2 Dec 2005 15:18:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2NIOnC067592 for ; Fri, 2 Dec 2005 15:18:27 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB2NIKjc015604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 Dec 2005 00:18:20 +0100 From: Simon Josefsson To: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings References: <20051202030944.GA21090@binky.Central.Sun.COM> <20051202154822.GL21090@binky.Central.Sun.COM> <20051202165927.GN21090@binky.Central.Sun.COM> <20051202204948.GU21090@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051202:ietf-sasl@imc.org::QNP8yq4baPeXKqNA:ARU8 Date: Sat, 03 Dec 2005 00:18:19 +0100 In-Reply-To: <20051202204948.GU21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 2 Dec 2005 14:49:48 -0600") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: > On Fri, Dec 02, 2005 at 06:13:44PM +0100, Simon Josefsson wrote: >> Nicolas Williams writes: >> > It's always the last handshake messages. >> >> How would the application tell handshake message apart from record >> layer data? > > Are there any TLS APIs that don't distinguish between handshake messages > and record messages? Such APIs, I think, would have to do I/O directly, > rather than leaving I/O to the application. The GnuTLS I/O callback prototype to the application look like: typedef ssize_t (*gnutls_pull_func)(gnutls_transport_ptr_t, void*, size_t); typedef ssize_t (*gnutls_push_func)(gnutls_transport_ptr_t, const void*, size_t); I.e., in that callback, the application will have no idea what the data the callback is supposed to send and receive is. To recognize whether some data is the TLS finished messages, it would have to parse the messages and likely also keep some state between packets. I'd imagine that the OpenSSL callbacks are similar, but I didn't check. >> > If we decide that some future version of TLS might end handshakes with >> > something other than finished messages (and not suitable for channel >> > binding material) then we can always concatenate *all* the handshake >> > messages. That should certainly do. >> >> TLS/IA behave like that. After the successful TLS handshake, it has >> another authentication phase. I'm not sure, but it may be useful to >> strongly connect the SASL channel binding with not only the particular >> TLS session but also the successful TLS/IA handshake including its >> authentication. TLS/IA describe how to use the TLS PRF to generate >> material for that. > > IA? It seems to have expired from the IETF repository, but is available from: http://josefsson.org/cgi-bin/viewcvs.cgi/gnutls/doc/protocol/draft-funk-tls-inner-application-extension-01.txt?rev=1.1&root=gnupg-mirror&view=auto > We can also fix the layering issue by having TLS export its channel > bindings, much like we would have it export its PRF. Yup. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2KntKu051320; Fri, 2 Dec 2005 12:49:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2KntAo051319; Fri, 2 Dec 2005 12:49:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2KnpPO051312 for ; Fri, 2 Dec 2005 12:49:52 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB2Knp3F012717 for ; Fri, 2 Dec 2005 13:49:51 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB2Knngt019552 for ; Fri, 2 Dec 2005 13:49:51 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB2Knnea026365; Fri, 2 Dec 2005 14:49:49 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB2KnmPX026364; Fri, 2 Dec 2005 14:49:48 -0600 (CST) Date: Fri, 2 Dec 2005 14:49:48 -0600 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings Message-ID: <20051202204948.GU21090@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <20051202030944.GA21090@binky.Central.Sun.COM> <20051202154822.GL21090@binky.Central.Sun.COM> <20051202165927.GN21090@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Dec 02, 2005 at 06:13:44PM +0100, Simon Josefsson wrote: > Nicolas Williams writes: > > It's always the last handshake messages. > > How would the application tell handshake message apart from record > layer data? Are there any TLS APIs that don't distinguish between handshake messages and record messages? Such APIs, I think, would have to do I/O directly, rather than leaving I/O to the application. > It is possible to do, but to me it seem to require adding logic to the > low-level send/recv primitive to make it aware of the upper-level > protocol state, and then also to save the finished messages somewhere > else as well too. It is a layering issue. Yes, it's a layering issue. If TLS exported its PRF we'd not have to do this. > > If we decide that some future version of TLS might end handshakes with > > something other than finished messages (and not suitable for channel > > binding material) then we can always concatenate *all* the handshake > > messages. That should certainly do. > > TLS/IA behave like that. After the successful TLS handshake, it has > another authentication phase. I'm not sure, but it may be useful to > strongly connect the SASL channel binding with not only the particular > TLS session but also the successful TLS/IA handshake including its > authentication. TLS/IA describe how to use the TLS PRF to generate > material for that. IA? > > TLS should demand that its PRF be exposed to applications. > > Agreed. Ok, so let's figure out who cannot use finished messages as channel bindings. We can also fix the layering issue by having TLS export its channel bindings, much like we would have it export its PRF. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2ICxc3036756; Fri, 2 Dec 2005 10:12:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2ICxNl036754; Fri, 2 Dec 2005 10:12:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by above.proper.com (8.12.11/8.12.9) with SMTP id jB2ICvkq036715 for ; Fri, 2 Dec 2005 10:12:59 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa26593; 2 Dec 2005 13:12 EST Received: from bistromath-home.pc.cs.cmu.edu (IDENT:U2FsdGVkX18goV9OfNxTCvZZTRP5DkuQNInjJrVPP2k@NEUPERT-EFFECT.FAC.CS.CMU.EDU [128.2.200.133]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id jB2ICt2u013764 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 2 Dec 2005 13:12:56 -0500 (EST) Date: Fri, 02 Dec 2005 13:12:54 -0500 From: Jeffrey Hutzelman To: Hallvard B Furuseth , Tom Yu cc: ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: WG Last Call: Simple Authentication and Security Layer (SASL) Message-ID: In-Reply-To: References: Originator-Info: login-token=Mulberry:01YEtyB8qz53usluqIk8midve9qTLnf+vNwKBslss=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, December 02, 2005 12:54:21 PM +0100 Hallvard B Furuseth wrote: >> 3. The Authentication Exchange > >> Where the mechanism specifies the first data sent in the exchange is >> from the client to the server and this field is unavailable or unused, >> the client request is followed by an empty challenge. > > I suggest to insert "in the protocol" after "unused", to clarify that it > isn't about when the user has provided no data to send in the initial > response or something. Unless that text restricts some other > possibilities which should be supported... I think "this field is unavailable" might be better worded as "this is not supported by the application protocol". I tend to prefer sentences in which all the pronouns have antecedents, which "this field" does not in this context. I'm not sure what "or unused" is even supposed to do here. If the mechanism specifies client-sends-first, and the app protocol provides the required field, then it should be used. I don't see what benefit is gained by allowing the app protocol implementation to decide whether to do this or to force a useless extra round trip. If the intent is indeed to allow the implementation to make this decision, then we need better text to that effect than "or unused". >> Where the mechanism specifies the server is to >> return additional data with the successful outcome, the protocol >> provides an optional additional data field in the outcome message, and >> the server uses this field, the exchange is shortened by one >> round-trip: > > Is this behaviour mandatory in this case, or may the server also choose > to send the additional data alone and expect an empty response, like > when the protocol does not support additional data with the outcome? > > I can't tell where in the sentence the condition ends and the > requirement starts. I suppose other such sentences may have the same > problem, havne't looked carefully. The behavior is optional. The condition has three parts, and there is no requirement per se - the last clause is more descriptive than prescriptive. Perhaps this would be clarified by s/Where/If/ and adding "then" after the last comma. > > In the Section 5 text quoted above, please add a note that "variable" > mechanisms violates the statement > > "SASL mechanisms SHOULD be protocol neutral." > > further down in the same section: A protocol which does not support > initial response in the auth command does not fully support such a > mechanism. I don't think that's necessary. A "variable" mechanism is protocol neutral in this respect if there is no functionality (aside from round-trip optimization) that you cannot get if the protocol doesn't support initial response. For example, a variety of symmetric authentication schemes require that each party send something to the other more-or-less simultaneously. A SASL mechanism based on such a system could be "variable", with the client sending its part in the initial response if supported, and in its response to the first challenge if not. With support for both initial response and data-with-success, you might save a full round trip or more with such a mechanism, but you'd still get full functionality without those features. >> 4. Protocol Requirements > >> Where the specification does not precisely prescribe how identities >> in SASL relate to identities used elsewhere in the protocol, for >> instance in access control policy statements, it may be appropriate >> for the protocol to provide a facility by which the client can >> discover information (such as the representation of the >> authentication identity used in making access control decisions) >> ^^^^^^^^^^^^^^^^^^^^^^^ >> about established identities for these uses. > > The authorization identity, not the authentication identity, is the one > normally used for access control. Though the protocol may allow the > authentication identity to be used too. Good catch. And no, conceptually, the only thing the authentication identity may be used for is deciding whether the client is permitted to claim a particular authzid, or determining what the authzid is if the client does not claim one. It should never be used directly in authorization decisions. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2HDoAh029417; Fri, 2 Dec 2005 09:13:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2HDoIU029416; Fri, 2 Dec 2005 09:13:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2HDmKF029407 for ; Fri, 2 Dec 2005 09:13:49 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB2HDiuM018681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Dec 2005 18:13:46 +0100 From: Simon Josefsson To: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings References: <20051202030944.GA21090@binky.Central.Sun.COM> <20051202154822.GL21090@binky.Central.Sun.COM> <20051202165927.GN21090@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051202:ietf-sasl@imc.org::RxojR7sHqocTQBLH:7OzT Date: Fri, 02 Dec 2005 18:13:44 +0100 In-Reply-To: <20051202165927.GN21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 2 Dec 2005 10:59:27 -0600") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: > On Fri, Dec 02, 2005 at 05:34:48PM +0100, Simon Josefsson wrote: >> >> Nicolas Williams writes: >> >> > On Fri, Dec 02, 2005 at 11:07:45AM +0100, Simon Josefsson wrote: >> >> Nicolas Williams writes: >> >> > On Thu, Dec 01, 2005 at 10:51:02AM +0100, Simon Josefsson wrote: >> >> >> >> Oh. Interesting. I note that other conceivable channel bindings for >> >> TLS are possible. Extracting the client/server finished messages from >> >> a TLS library is not generally possible. >> > >> > Er, how is extracting the finished messages not generally possible? TLS >> > APIs (OK, OpenSSL's) typically have the app in charge of doing I/O and >> > deal with TLS messages much like the GSS-API deals with its tokens. >> > >> > So apps know that the last message of the handshake exchange >> > sent/received are the finished messages. >> >> How would an application know which messages are the two finished >> messages? > > It's always the last handshake messages. How would the application tell handshake message apart from record layer data? It is possible to do, but to me it seem to require adding logic to the low-level send/recv primitive to make it aware of the upper-level protocol state, and then also to save the finished messages somewhere else as well too. It is a layering issue. >> GnuTLS use the same approach, where the app does the I/O, but it >> doesn't tell the API that the data that is sent is the finished >> message. Determining which data is the finished message in the opaque >> data passed to the application is possible (the application could >> implement a simple TLS parser) but seem ad-hoc to me. > > If we decide that some future version of TLS might end handshakes with > something other than finished messages (and not suitable for channel > binding material) then we can always concatenate *all* the handshake > messages. That should certainly do. TLS/IA behave like that. After the successful TLS handshake, it has another authentication phase. I'm not sure, but it may be useful to strongly connect the SASL channel binding with not only the particular TLS session but also the successful TLS/IA handshake including its authentication. TLS/IA describe how to use the TLS PRF to generate material for that. >> I'm not claiming using the TLS PRF is better; I'm just trying to >> understand how the finished-message-approach was intended to be >> implemented, and comparing it to the alternatives. The TLS PRF can be >> exposed through a public API in TLS implementations, so in general I >> believe it is elegant to use the TLS PRF rather than other parts of >> the TLS handshake. > > TLS should demand that its PRF be exposed to applications. Agreed. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2GxXbx028312; Fri, 2 Dec 2005 08:59:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2GxXbY028311; Fri, 2 Dec 2005 08:59:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2GxTDc028301 for ; Fri, 2 Dec 2005 08:59:29 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jB2GxSdK011151 for ; Fri, 2 Dec 2005 08:59:28 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB2GxRgt008129 for ; Fri, 2 Dec 2005 09:59:28 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB2GxRAm026186; Fri, 2 Dec 2005 10:59:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB2GxRrA026185; Fri, 2 Dec 2005 10:59:27 -0600 (CST) Date: Fri, 2 Dec 2005 10:59:27 -0600 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings Message-ID: <20051202165927.GN21090@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <20051202030944.GA21090@binky.Central.Sun.COM> <20051202154822.GL21090@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Dec 02, 2005 at 05:34:48PM +0100, Simon Josefsson wrote: > > Nicolas Williams writes: > > > On Fri, Dec 02, 2005 at 11:07:45AM +0100, Simon Josefsson wrote: > >> Nicolas Williams writes: > >> > On Thu, Dec 01, 2005 at 10:51:02AM +0100, Simon Josefsson wrote: > >> > >> Oh. Interesting. I note that other conceivable channel bindings for > >> TLS are possible. Extracting the client/server finished messages from > >> a TLS library is not generally possible. > > > > Er, how is extracting the finished messages not generally possible? TLS > > APIs (OK, OpenSSL's) typically have the app in charge of doing I/O and > > deal with TLS messages much like the GSS-API deals with its tokens. > > > > So apps know that the last message of the handshake exchange > > sent/received are the finished messages. > > How would an application know which messages are the two finished > messages? It's always the last handshake messages. > GnuTLS use the same approach, where the app does the I/O, but it > doesn't tell the API that the data that is sent is the finished > message. Determining which data is the finished message in the opaque > data passed to the application is possible (the application could > implement a simple TLS parser) but seem ad-hoc to me. If we decide that some future version of TLS might end handshakes with something other than finished messages (and not suitable for channel binding material) then we can always concatenate *all* the handshake messages. That should certainly do. > I'm not claiming using the TLS PRF is better; I'm just trying to > understand how the finished-message-approach was intended to be > implemented, and comparing it to the alternatives. The TLS PRF can be > exposed through a public API in TLS implementations, so in general I > believe it is elegant to use the TLS PRF rather than other parts of > the TLS handshake. TLS should demand that its PRF be exposed to applications. > >> Ouch. This is a serious problem. Couldn't SASL/GS2 use the > >> pseudo-mechanism to solve this problem, though? Is the channel bind > >> negotiator pseudo-mechanism too inefficient? I'm thinking that we > >> should avoid duplicating work that is already available. > > > > It could. It could also not depend on work that might take a while. > > > > There's two ways: one eschew the GSS channel bindings interface, since > > SASL/GS2 uses wrap tokens, it might as well use those to negotiate and > > exchange channel bindings, or use both, the GSS channel bindings > > interface and the wrap token to the same effect. > > I'll watch the discussion to see if there is any preference for either > approach. The best way to provoke a decision is probably to pick one > approach and update the draft, though.. Indeed. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2GYsJU025629; Fri, 2 Dec 2005 08:34:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2GYspd025628; Fri, 2 Dec 2005 08:34:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2GYqC8025622 for ; Fri, 2 Dec 2005 08:34:53 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB2GYnll014627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Dec 2005 17:34:49 +0100 From: Simon Josefsson To: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings References: <20051202030944.GA21090@binky.Central.Sun.COM> <20051202154822.GL21090@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051202:ietf-sasl@imc.org::G3BI3oX/O5Pp3015:3GsL Date: Fri, 02 Dec 2005 17:34:48 +0100 In-Reply-To: <20051202154822.GL21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 2 Dec 2005 09:48:22 -0600") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: > On Fri, Dec 02, 2005 at 11:07:45AM +0100, Simon Josefsson wrote: >> Nicolas Williams writes: >> > On Thu, Dec 01, 2005 at 10:51:02AM +0100, Simon Josefsson wrote: >> >> Oh. Interesting. I note that other conceivable channel bindings for >> TLS are possible. Extracting the client/server finished messages from >> a TLS library is not generally possible. > > Er, how is extracting the finished messages not generally possible? TLS > APIs (OK, OpenSSL's) typically have the app in charge of doing I/O and > deal with TLS messages much like the GSS-API deals with its tokens. > > So apps know that the last message of the handshake exchange > sent/received are the finished messages. How would an application know which messages are the two finished messages? GnuTLS use the same approach, where the app does the I/O, but it doesn't tell the API that the data that is sent is the finished message. Determining which data is the finished message in the opaque data passed to the application is possible (the application could implement a simple TLS parser) but seem ad-hoc to me. I'm not claiming using the TLS PRF is better; I'm just trying to understand how the finished-message-approach was intended to be implemented, and comparing it to the alternatives. The TLS PRF can be exposed through a public API in TLS implementations, so in general I believe it is elegant to use the TLS PRF rather than other parts of the TLS handshake. >> Ouch. This is a serious problem. Couldn't SASL/GS2 use the >> pseudo-mechanism to solve this problem, though? Is the channel bind >> negotiator pseudo-mechanism too inefficient? I'm thinking that we >> should avoid duplicating work that is already available. > > It could. It could also not depend on work that might take a while. > > There's two ways: one eschew the GSS channel bindings interface, since > SASL/GS2 uses wrap tokens, it might as well use those to negotiate and > exchange channel bindings, or use both, the GSS channel bindings > interface and the wrap token to the same effect. I'll watch the discussion to see if there is any preference for either approach. The best way to provoke a decision is probably to pick one approach and update the draft, though.. Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2FmSeL021726; Fri, 2 Dec 2005 07:48:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2FmSfU021725; Fri, 2 Dec 2005 07:48:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2FmOX6021712 for ; Fri, 2 Dec 2005 07:48:24 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB2FmOD7010200 for ; Fri, 2 Dec 2005 08:48:24 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB2FmN5K019506 for ; Fri, 2 Dec 2005 08:48:24 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB2FmNox025964; Fri, 2 Dec 2005 09:48:23 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB2FmM9e025963; Fri, 2 Dec 2005 09:48:22 -0600 (CST) Date: Fri, 2 Dec 2005 09:48:22 -0600 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings Message-ID: <20051202154822.GL21090@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <20051202030944.GA21090@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Dec 02, 2005 at 11:07:45AM +0100, Simon Josefsson wrote: > Nicolas Williams writes: > > On Thu, Dec 01, 2005 at 10:51:02AM +0100, Simon Josefsson wrote: > > Oh. Interesting. I note that other conceivable channel bindings for > TLS are possible. Extracting the client/server finished messages from > a TLS library is not generally possible. Er, how is extracting the finished messages not generally possible? TLS APIs (OK, OpenSSL's) typically have the app in charge of doing I/O and deal with TLS messages much like the GSS-API deals with its tokens. So apps know that the last message of the handshake exchange sent/received are the finished messages. > Accessing the TLS PRF is not > generally possible, but I believe using this approach would be > cleaner. It would also make sure we are deriving new material used > only for this particular SASL authentication, instead of re-using data > meant for other purposes. We could use the TLS PRF, yes, but not to key GSS-API mechanisms -- there's no function to do that -- only to do channel binding. But since the finished messages are sufficient and I'm sure one can typically get at them... > > The bigger problem is negotiation of use of channel bindings. > > [...] > Ouch. This is a serious problem. Couldn't SASL/GS2 use the > pseudo-mechanism to solve this problem, though? Is the channel bind > negotiator pseudo-mechanism too inefficient? I'm thinking that we > should avoid duplicating work that is already available. It could. It could also not depend on work that might take a while. There's two ways: one eschew the GSS channel bindings interface, since SASL/GS2 uses wrap tokens, it might as well use those to negotiate and exchange channel bindings, or use both, the GSS channel bindings interface and the wrap token to the same effect. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2BxGKe001574; Fri, 2 Dec 2005 03:59:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2BxGE7001573; Fri, 2 Dec 2005 03:59:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2BxFJI001565 for ; Fri, 2 Dec 2005 03:59:15 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1Ei9ZH-0002t8-Rx; Fri, 02 Dec 2005 12:59:12 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.43) id 1Ei9ZD-0005Qe-09; Fri, 02 Dec 2005 12:59:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1Ei9ZC-00026W-VL; Fri, 02 Dec 2005 12:59:06 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 2 Dec 2005 12:59:06 +0100 To: Tom Yu cc: ietf-sasl@imc.org Subject: Re: WG Last Call: Simple Authentication and Security Layer (SASL) In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.008, required 12, autolearn=disabled, AWL -0.01, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: > My comments in this message have not been addrssed - actually, > rfc2222bis-14 made it worse: > >> Subject: rfc2222bis-13: challenges, responses and other messages >> Date: Wed, 16 Nov 2005 23:50:55 +0100 Forgot to include the URL for the full message: http://www.imc.org/ietf-sasl/mail-archive/msg02110.html -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2BsX47001081; Fri, 2 Dec 2005 03:54:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2BsXZI001080; Fri, 2 Dec 2005 03:54:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2BsW6T001067 for ; Fri, 2 Dec 2005 03:54:32 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1Ei9Ui-00025F-B1; Fri, 02 Dec 2005 12:54:28 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.43) id 1Ei9Ub-0004sP-Bn; Fri, 02 Dec 2005 12:54:21 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1Ei9Ub-000230-Ae; Fri, 02 Dec 2005 12:54:21 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 2 Dec 2005 12:54:21 +0100 To: Tom Yu Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: Simple Authentication and Security Layer (SASL) In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.008, required 12, autolearn=disabled, AWL -0.01, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom Yu writes: > Please review this document, and address feedback to the WG mailing > list. This Last Call will expire at 17:00 EST on December 12, 2005. My comments in this message have not been addrssed - actually, rfc2222bis-14 made it worse: > Subject: rfc2222bis-13: challenges, responses and other messages > Date: Wed, 16 Nov 2005 23:50:55 +0100 > > (...) The definitions and uses of challenges, responses, etc seem > unclear or inconsistent. > > I always thought "Initial response" referred to the optional response > sent with the authentication command, and the wordings in sections 3 and > 4 seem to me to say that. rfc2222bis-10 explicitly uses the term that > way. > > However, the example in section 3 uses it to mean just the first > message with client data. (...) Most other text now seems to use that > meaning. > (...) rfc2222bis-14 keeps the texts which uses the second definition, but added some text which uses the first definition: > 5. Mechanism Requirements > a) An indication whether mechanism is client-first, variable, or > server-first. If a SASL mechanism is defined as client-first > and the client does not send an initial response, then the first > server challenge MUST be empty (the EXTERNAL mechanism is an > example of this case). If a SASL mechanism is defined as > variable, then the specification needs to state how the server > behaves when the initial client response is omitted (the > DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case). > If a SASL mechanism is defined as server-first then the client > MUST NOT send an initial client response (the CRAM-MD5 mechanism > [CRAM-MD5] is an example of this case). Other notes: > 3. The Authentication Exchange > Where the mechanism specifies the first data sent in the exchange is > from the client to the server and this field is unavailable or unused, > the client request is followed by an empty challenge. I suggest to insert "in the protocol" after "unused", to clarify that it isn't about when the user has provided no data to send in the initial response or something. Unless that text restricts some other possibilities which should be supported... > Where the mechanism specifies the server is to > return additional data with the successful outcome, the protocol > provides an optional additional data field in the outcome message, and > the server uses this field, the exchange is shortened by one > round-trip: Is this behaviour mandatory in this case, or may the server also choose to send the additional data alone and expect an empty response, like when the protocol does not support additional data with the outcome? I can't tell where in the sentence the condition ends and the requirement starts. I suppose other such sentences may have the same problem, havne't looked carefully. In the Section 5 text quoted above, please add a note that "variable" mechanisms violates the statement "SASL mechanisms SHOULD be protocol neutral." further down in the same section: A protocol which does not support initial response in the auth command does not fully support such a mechanism. Though the mechanism could be defined so that the client may override the first challenge from the server, thus resetting the server back to how it would work if the client had sent the response in the auth command. > 4. Protocol Requirements > Where the specification does not precisely prescribe how identities > in SASL relate to identities used elsewhere in the protocol, for > instance in access control policy statements, it may be appropriate > for the protocol to provide a facility by which the client can > discover information (such as the representation of the > authentication identity used in making access control decisions) > ^^^^^^^^^^^^^^^^^^^^^^^ > about established identities for these uses. The authorization identity, not the authentication identity, is the one normally used for access control. Though the protocol may allow the authentication identity to be used too. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2A7oXd089739; Fri, 2 Dec 2005 02:07:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2A7oh7089738; Fri, 2 Dec 2005 02:07:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2A7nkL089729 for ; Fri, 2 Dec 2005 02:07:49 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB2A7kaC011870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Dec 2005 11:07:46 +0100 From: Simon Josefsson To: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings References: <20051202030944.GA21090@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051202:ietf-sasl@imc.org::7mxDtbL0r7TqkxiT:Ixg0 Date: Fri, 02 Dec 2005 11:07:45 +0100 In-Reply-To: <20051202030944.GA21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 1 Dec 2005 21:09:45 -0600") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: > On Thu, Dec 01, 2005 at 10:51:02AM +0100, Simon Josefsson wrote: >> I started working on text in GS2 that would give guidance on exactly >> what channel binding data to specify when running under TLS. It >> occurred to me that this isn't specific for GS2. DIGEST-MD5 could use >> similar channel binding data guidance. > > For TLS the answer is quite simple: the concatenation of the client and > server finished messages, in that order. > > See: > > draft-ietf-kitten-gssapi-channel-bindings-01.txt > draft-ietf-nfsv4-channel-bindings-03.txt Oh. Interesting. I note that other conceivable channel bindings for TLS are possible. Extracting the client/server finished messages from a TLS library is not generally possible. Accessing the TLS PRF is not generally possible, but I believe using this approach would be cleaner. It would also make sure we are deriving new material used only for this particular SASL authentication, instead of re-using data meant for other purposes. >> I haven't thought through the following completely, but thought I >> should mention it to see if I have hit upon something useful. >> >> Shouldn't the core document specify that if SASL is used below TLS, >> and the SASL mechanism support channel bindings, the channel binding >> must include the TLS session id? > > s/below/above/? > > Anyways, no, TLS session IDs are not strongly bound to TLS channels. Right. >> It could be argued that the channel binding problem is inherent in >> SASL itself, and not specific to any mechanism. That would argue for >> fixing it in the core document. >> >> Other recommendations, for e.g. IPSEC channel bindings could be added >> too, but as far as I know, SASL over IPSEC isn't sufficiently widely >> used to let us make a informed choice. There is also a larger layer >> violation in getting the IPSEC session id into the SASL library, or >> even worse, every SASL mechanism. > > I agree, I think we could generalize the above drafts a bit, so they are > applicable to SASL. See section 4.2 of draft-ietf-nfsv4-channel- > bindings-03.txt. Ah, I see. > The bigger problem is negotiation of use of channel bindings. > > Particularly when it comes to channels for which channel bindings will > be specified later, as opposed to now, or for which channel bindings are > difficult to obtain with existing implementations' interfaces. > > E.g., client uses channel bindings to channel XYZ, the server is unaware > of the channel or can't get bindings for it, so it does not provide > channel bindings to the mechanism --> context establishment fails. > > What we want from channel bindings is: to know whether the binding > succeeded so the app can choose to eschew session protection at the > higher layer. It's OK if channel binding fails but context > establishment succeeds, AS LONG AS the application knows the binding > failed and so can choose how to proceed. > > But the GSS-API doesn't provide this information -- it's all or nothing. > > So in pure GSS-API contexts we'll be resorting to stacking a pseudo- > mechanism whose primary purpose is to indicate willingness to do channel > binding at mechanism negotiation time. But in SASL/GS2 context we can > do better. Ouch. This is a serious problem. Couldn't SASL/GS2 use the pseudo-mechanism to solve this problem, though? Is the channel bind negotiator pseudo-mechanism too inefficient? I'm thinking that we should avoid duplicating work that is already available. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB29qbbX088603; Fri, 2 Dec 2005 01:52:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB29qbv5088602; Fri, 2 Dec 2005 01:52:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB29qZmt088595 for ; Fri, 2 Dec 2005 01:52:36 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB29qPNm010273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2005 10:52:25 +0100 From: Simon Josefsson To: Chris Newman Cc: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings References: <401CDBDBADBC0A76B0E80336@446E7922C82D299DB29D899F> <20051202032152.GB21090@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051202:chris.newman@sun.com::kfie6nMJi2h9fT+k:2xsR X-Hashcash: 1:21:051202:ietf-sasl@imc.org::4r3Va29elm3ADl/x:15+z X-Hashcash: 1:21:051202:chris.newman@sun.com::vWRJmZUBGg5iOPLQ:0duS Date: Fri, 02 Dec 2005 10:52:24 +0100 In-Reply-To: <20051202032152.GB21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 1 Dec 2005 21:21:52 -0600") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: > No, the TLS session ID is not a binding for TLS channels. Right, I don't know what I was thinking. In TLS/IA, which I'm currently implementing, the TLS PRF it used, seeded with the client random and the server random, and a specific label, to generate session specific challenges. If such a challenge is protected by GS2 GSS_Wrap(), it appears to me as if the TLS channel would be bound to the authentication. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB23LsNx046898; Thu, 1 Dec 2005 19:21:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB23LshR046897; Thu, 1 Dec 2005 19:21:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB23Ls8K046881 for ; Thu, 1 Dec 2005 19:21:54 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB23Lr3F015544 for ; Thu, 1 Dec 2005 20:21:53 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB23Lr5K019502 for ; Thu, 1 Dec 2005 20:21:53 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB23LqKx025042; Thu, 1 Dec 2005 21:21:52 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB23Lqsc025041; Thu, 1 Dec 2005 21:21:52 -0600 (CST) Date: Thu, 1 Dec 2005 21:21:52 -0600 From: Nicolas Williams To: Chris Newman Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings Message-ID: <20051202032152.GB21090@binky.Central.Sun.COM> Mail-Followup-To: Chris Newman , Simon Josefsson , ietf-sasl@imc.org References: <401CDBDBADBC0A76B0E80336@446E7922C82D299DB29D899F> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <401CDBDBADBC0A76B0E80336@446E7922C82D299DB29D899F> User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Dec 01, 2005 at 04:53:59PM -0800, Chris Newman wrote: > We need a general model for TLS channel bindings and we need specific > applications of that model to at least the SASL and GSSAPI frameworks as > well as implementations for specific mechanisms within those frameworks. > > Pulling the TLS session id into the SASL/GSSAPI layer has the advantage > that it will work with deployed TLS software. No, the TLS session ID is not a binding for TLS channels. > But if there was a way to > push a key from the SASL/GSSAPI layer down to the TLS layer that may > provide superior functionality, especially if it's designed in a way that > subsequent fast reconnect at the TLS layer can be used to safely recall the > authentication session. Right, that's establishing and keying a TLS layer from a security layer above. This is interesting, very interesting, and part of the HTTP AUTH conversation, but it's different from the more traditional sense of channel binding. Here what we really want is something like GSS_Pseudo_random(), only for SASL, then we can use this function to generate the TLS master secret. Cheers, Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB239pdr046060; Thu, 1 Dec 2005 19:09:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB239pT1046059; Thu, 1 Dec 2005 19:09:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB239nvS046053 for ; Thu, 1 Dec 2005 19:09:49 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jB239n4u026609 for ; Thu, 1 Dec 2005 19:09:49 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB239m5K015198 for ; Thu, 1 Dec 2005 20:09:49 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB239mmr025025; Thu, 1 Dec 2005 21:09:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB239jcK025024; Thu, 1 Dec 2005 21:09:45 -0600 (CST) Date: Thu, 1 Dec 2005 21:09:45 -0600 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Where to specify details of channel bindings Message-ID: <20051202030944.GA21090@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Dec 01, 2005 at 10:51:02AM +0100, Simon Josefsson wrote: > I started working on text in GS2 that would give guidance on exactly > what channel binding data to specify when running under TLS. It > occurred to me that this isn't specific for GS2. DIGEST-MD5 could use > similar channel binding data guidance. For TLS the answer is quite simple: the concatenation of the client and server finished messages, in that order. See: draft-ietf-kitten-gssapi-channel-bindings-01.txt draft-ietf-nfsv4-channel-bindings-03.txt (Note: the text on IPsec channel bindings is way out of date.) > I haven't thought through the following completely, but thought I > should mention it to see if I have hit upon something useful. > > Shouldn't the core document specify that if SASL is used below TLS, > and the SASL mechanism support channel bindings, the channel binding > must include the TLS session id? s/below/above/? Anyways, no, TLS session IDs are not strongly bound to TLS channels. > It could be argued that the channel binding problem is inherent in > SASL itself, and not specific to any mechanism. That would argue for > fixing it in the core document. > > Other recommendations, for e.g. IPSEC channel bindings could be added > too, but as far as I know, SASL over IPSEC isn't sufficiently widely > used to let us make a informed choice. There is also a larger layer > violation in getting the IPSEC session id into the SASL library, or > even worse, every SASL mechanism. I agree, I think we could generalize the above drafts a bit, so they are applicable to SASL. See section 4.2 of draft-ietf-nfsv4-channel- bindings-03.txt. The bigger problem is negotiation of use of channel bindings. Particularly when it comes to channels for which channel bindings will be specified later, as opposed to now, or for which channel bindings are difficult to obtain with existing implementations' interfaces. E.g., client uses channel bindings to channel XYZ, the server is unaware of the channel or can't get bindings for it, so it does not provide channel bindings to the mechanism --> context establishment fails. What we want from channel bindings is: to know whether the binding succeeded so the app can choose to eschew session protection at the higher layer. It's OK if channel binding fails but context establishment succeeds, AS LONG AS the application knows the binding failed and so can choose how to proceed. But the GSS-API doesn't provide this information -- it's all or nothing. So in pure GSS-API contexts we'll be resorting to stacking a pseudo- mechanism whose primary purpose is to indicate willingness to do channel binding at mechanism negotiation time. But in SASL/GS2 context we can do better. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB20rLPw033984; Thu, 1 Dec 2005 16:53:21 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB20rLsY033983; Thu, 1 Dec 2005 16:53:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB20rKJ9033976 for ; Thu, 1 Dec 2005 16:53:20 -0800 (PST) (envelope-from Chris.Newman@Sun.COM) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB20rJD7029715 for ; Thu, 1 Dec 2005 17:53:20 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQU00501IDO0I00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ietf-sasl@imc.org; Thu, 01 Dec 2005 17:53:19 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQU009M6IGSLRB0@mail-amer.sun.com>; Thu, 01 Dec 2005 17:53:19 -0700 (MST) Date: Thu, 01 Dec 2005 16:53:59 -0800 From: Chris Newman Subject: Re: Where to specify details of channel bindings In-reply-to: To: Simon Josefsson , ietf-sasl@imc.org Message-id: <401CDBDBADBC0A76B0E80336@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We need a general model for TLS channel bindings and we need specific applications of that model to at least the SASL and GSSAPI frameworks as well as implementations for specific mechanisms within those frameworks. Pulling the TLS session id into the SASL/GSSAPI layer has the advantage that it will work with deployed TLS software. But if there was a way to push a key from the SASL/GSSAPI layer down to the TLS layer that may provide superior functionality, especially if it's designed in a way that subsequent fast reconnect at the TLS layer can be used to safely recall the authentication session. - Chris Simon Josefsson wrote on 12/1/05 10:51 +0100: > > I started working on text in GS2 that would give guidance on exactly > what channel binding data to specify when running under TLS. It > occurred to me that this isn't specific for GS2. DIGEST-MD5 could use > similar channel binding data guidance. > > I haven't thought through the following completely, but thought I > should mention it to see if I have hit upon something useful. > > Shouldn't the core document specify that if SASL is used below TLS, > and the SASL mechanism support channel bindings, the channel binding > must include the TLS session id? > > It could be argued that the channel binding problem is inherent in > SASL itself, and not specific to any mechanism. That would argue for > fixing it in the core document. > > Other recommendations, for e.g. IPSEC channel bindings could be added > too, but as far as I know, SASL over IPSEC isn't sufficiently widely > used to let us make a informed choice. There is also a larger layer > violation in getting the IPSEC session id into the SASL library, or > even worse, every SASL mechanism. > > Thanks, > Simon > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB20bK5p032786; Thu, 1 Dec 2005 16:37:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB20bKfk032785; Thu, 1 Dec 2005 16:37:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB20bCxC032750 for ; Thu, 1 Dec 2005 16:37:12 -0800 (PST) (envelope-from Chris.Newman@Sun.COM) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB20bC3F001236 for ; Thu, 1 Dec 2005 17:37:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQU00C01HLL2V00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ietf-sasl@imc.org; Thu, 01 Dec 2005 17:37:12 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQU009CSHPXLRB0@mail-amer.sun.com>; Thu, 01 Dec 2005 17:37:12 -0700 (MST) Date: Thu, 01 Dec 2005 16:37:52 -0800 From: Chris Newman Subject: RE: WG Review: draft-ietf-sasl-gssapi-03.txt In-reply-to: <91D7F2CEE3425A4A9D11311D09FCE24611C5D6F8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> To: Paul Leach , "Kurt D. Zeilenga" , Alexey Melnikov Cc: Nicolas Williams , Simon Josefsson , ietf-sasl@imc.org Message-id: <4BD03274E8A232FEB6B862F8@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <91D7F2CEE3425A4A9D11311D09FCE24611C5D6F8@WIN-MSG-10.wingroup.windep loy.ntdev.microsoft.com> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Leach wrote on 11/30/05 16:56 -0800: > As a person who has to implement both straight GSS and SASL, I would > much prefer that I only have to implement one negotiation mechanism, or, > barring that, that my customers usually only have to deploy one > negotiation mechanism. > > Furthermore, SPNEGO protects its negotiations, and as I understand it > the SASL negotiation is not protected. It's my belief that the security gain of protecting the negotiation is less than the security loss from the additional complexity necessary to protect the negotiation. Furthermore, a protected negotiation is never as strong as properly configured security policy on both the client and server. As a result I would prefer we deploy the stronger protection mechanism (good UIs for client and server policy) and not deploy the weaker mechanism (negotiation protection). > Hence, I would prefer to use GSS-SPNEGO as the only negotiation > mechanism where possible. Because the SASL negotiation can piggyback on the application protocol's capability mechanism while GSS-SPNEGO can't, it saves a round-trip which is becoming more important as mobile devices with higher round-trip costs are deployed. It's also simpler and more transparent for application programmers to understand and debug (as opposed to security geeks who are in shorter supply). To me, SPNEGO is an opaque blob while a SASL negotiation is simple and easy to understand. This is also true for almost anyone reading a protocol trace, snoop or tcpdump of a typical application protocol. The need for a customized protocol debugger to convert GSS-SPNEGO to a human readable format is a non-trivial amount of additional complexity throughout the system and makes the security policy less transparent in the process. > Finally, our implementation of GSS-SPNEGO does some extra local > processing, such as determining which mechanisms to use based on whether > usable credentials for the mechanism are available for the two > communicating systems (in addition to just whether an implementation of > the mechanism is available). This sounds important. Can you please elaborate on this issue, specifically what information needs to be exchanged? If we can also piggyback this information on the application protocol capability exchange, that saves a round-trip, and would make it easier for sysadmins to identify and debug credential configuration errors. - Chris Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1E9sMN062819; Thu, 1 Dec 2005 06:09:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB1E9sDP062818; Thu, 1 Dec 2005 06:09:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1E9o18062809 for ; Thu, 1 Dec 2005 06:09:50 -0800 (PST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jB1E9odK007163 for ; Thu, 1 Dec 2005 06:09:50 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB1E9n5K022732 for ; Thu, 1 Dec 2005 07:09:49 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB1E9m4A023047; Thu, 1 Dec 2005 08:09:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB1E9ksg023046; Thu, 1 Dec 2005 08:09:46 -0600 (CST) Date: Thu, 1 Dec 2005 08:09:46 -0600 From: Nicolas Williams To: Simon Josefsson Cc: Paul Leach , "Kurt D. Zeilenga" , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt Message-ID: <20051201140946.GJ21090@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , Paul Leach , "Kurt D. Zeilenga" , Alexey Melnikov , ietf-sasl@imc.org References: <91D7F2CEE3425A4A9D11311D09FCE24611C5D6F8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20051201012448.GC21090@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Dec 01, 2005 at 10:43:02AM +0100, Simon Josefsson wrote: > > a) SASL/GS2 explicitly prohibits SPNEGO > > b) SASL/GS2 provides protection for SASL mech lists > > c) specify a DIGEST-MD5 GSS-API mechanism, deprecate all non-GSS SASL > > mechanisms, and close the SASL mechanism namespace. > > I don't see PLAIN going away soon. > > What's wrong with: > > d) SASL/GS2 prohibit SPNEGO, and does not protect the SASL mech list. > There is another SASL mechanism, say, "SPNEGO" to invoke SPNEGO > that would support channel bindings. I don't get how channel bindings makes the problem go away. Speaking of channel bindings, that will add a bit of complexity to SASL/GS2 unfortunately... The thing about GSS channel bindings is that they're not negotiable -- the two peers have to know a priori that they both will or won't use that feature. What I'm thinking we can do about this is have the initial context token be sent along with any channel bindings used and then have the acceptor, in its wrap token, tell the initiator whether it had provided channel bindings or whether it had used the initiator's [just to make the context go]. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB19hRi9032339; Thu, 1 Dec 2005 01:43:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB19hRFZ032338; Thu, 1 Dec 2005 01:43:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB19hP2R032327 for ; Thu, 1 Dec 2005 01:43:26 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (h14n1c1o1033.bredband.skanova.com [81.225.104.14]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB19hNFI017416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2005 10:43:23 +0100 From: Simon Josefsson To: Paul Leach Cc: "Kurt D. Zeilenga" , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt References: <91D7F2CEE3425A4A9D11311D09FCE24611C5D6F8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20051201012448.GC21090@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051201:ietf-sasl@imc.org::Fo/5mPj2awWBVzXh:0sgZ X-Hashcash: 1:21:051201:paulle@windows.microsoft.com::jhvKmFMKfrhQijMV:2XjH X-Hashcash: 1:21:051201:kurt@openldap.org::0fhmr71bs2EuD6ax:56+a X-Hashcash: 1:21:051201:alexey.melnikov@isode.com::3TM7Ig3aaAuWbje1:G+SB X-Hashcash: 1:21:051201:kurt@openldap.org::uM3WDa6ziwwyG+3v:26rP Date: Thu, 01 Dec 2005 10:43:02 +0100 In-Reply-To: <20051201012448.GC21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 30 Nov 2005 19:24:48 -0600") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=4.9 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, RCVD_IN_DSBL,RCVD_IN_NJABL_DUL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_DUL, RCVD_IN_SORBS_SOCKS autolearn=no version=3.1.0 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: >> While I expect that we will implement whatever is needed for >> interoperability, in many situations we would recommend that the only >> SASL mechanism advertised would be the SPNEGO based one, and let SPNEGO >> do the rest of the negotiation. > > Oh, I too would rather just have GSS-API mechanisms and treat SASL as a > legacy framework that can use GSS mechanisms to get by. This would > require that we design GSS mechanisms at least for the SASL DIGEST-MD5 > mechanism. > > These are our choices: > > a) SASL/GS2 explicitly prohibits SPNEGO > b) SASL/GS2 provides protection for SASL mech lists > c) specify a DIGEST-MD5 GSS-API mechanism, deprecate all non-GSS SASL > mechanisms, and close the SASL mechanism namespace. I don't see PLAIN going away soon. What's wrong with: d) SASL/GS2 prohibit SPNEGO, and does not protect the SASL mech list. There is another SASL mechanism, say, "SPNEGO" to invoke SPNEGO that would support channel bindings. If I understood correctly, this would solve all needs: People who prefer SPNEGO can use that mechanism. People who need a more efficient protocol can use GS2. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB19Xugc031622; Thu, 1 Dec 2005 01:33:56 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB19XuIV031621; Thu, 1 Dec 2005 01:33:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB19Xpi4031606 for ; Thu, 1 Dec 2005 01:33:54 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (h14n1c1o1033.bredband.skanova.com [81.225.104.14]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB19Xfl8016665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2005 10:33:42 +0100 From: Simon Josefsson To: "Paul Leach" Cc: "Nicolas Williams" , , "Kurt D. Zeilenga" , "Alexey Melnikov" Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt References: <91D7F2CEE3425A4A9D11311D09FCE24611C5D6F8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051201:ietf-sasl@imc.org::bbr20bRYNc6sRM1d:0mmb X-Hashcash: 1:21:051201:alexey.melnikov@isode.com::RPrfSJnXio2D+Vu6:0xjj X-Hashcash: 1:21:051201:paulle@windows.microsoft.com::xhbcLhgh8jkMTqC6:94Vo X-Hashcash: 1:21:051201:kurt@openldap.org::YDm21D3kycabYGo3:GRLZ X-Hashcash: 1:21:051201:nicolas.williams@sun.com::LHnYrFioQ/iSslHj:aAM2 X-Hashcash: 1:21:051201:nicolas.williams@sun.com::eMO/oPRFtNYibjgv:85ze X-Hashcash: 1:21:051201:kurt@openldap.org::U3dwErIYgPHz4Wb3:OH4B Date: Thu, 01 Dec 2005 10:33:20 +0100 In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE24611C5D6F8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> (Paul Leach's message of "Wed, 30 Nov 2005 16:56:12 -0800") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=4.7 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, RCVD_IN_DSBL,RCVD_IN_NJABL_DUL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_DUL, RCVD_IN_SORBS_SOCKS autolearn=no version=3.1.0 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Paul Leach" writes: > As a person who has to implement both straight GSS and SASL, I would > much prefer that I only have to implement one negotiation mechanism, or, > barring that, that my customers usually only have to deploy one > negotiation mechanism. Speaking as another implementer of both GSS and SASL, I concur. > Hence, I would prefer to use GSS-SPNEGO as the only negotiation > mechanism where possible. I disagree. I haven't implemented SPNEGO. My customers aren't asking for it. The negotiation done in SASL is sufficient for my needs. Further, I don't see the SASL negotiation going away, and SASL appear to be more widely adopted than SPNEGO. > For the above reasons, I'd prefer that GSS-SPNEGO not be deprecated. Since GSS-SPNEGO has obviously been implemented, I believe it would be useful to publish a document on that protocol. However, SPNEGO doesn't provide channel bindings, so I think it is questionable whether we want to say new users should use it. > (Or perhaps I really should say that I prefer that GS2-SPEGO should > not be deprecated). If we get consensus on the text I proposed, SPNEGO will not be usable under GS2. I believe every GSS-API mechanism that negotiate other mechanisms should have its own SASL mechanism name. It might be useful for you to specify a "SPNEGO" SASL mechanism that uses SPNEGO but also support channel bindings. Or change the GSS-SPNEGO protocol description to support channel bindings. If I recall correctly, SPNEGO generate more round-trips, so there is still some merit in supporting GSS-API mechanisms directly in SASL, without going through SPNEGO. Of course, SPNEGO could be support as well. Thanks, Simon