Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJNO7m2041620; Tue, 19 Dec 2006 16:24:07 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJNO7pd041619; Tue, 19 Dec 2006 16:24:07 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJNO6kM041612 for ; Tue, 19 Dec 2006 16:24:06 -0700 (MST) (envelope-from ldusseault@commerce.net) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 960131880 for ; Tue, 19 Dec 2006 23:24:05 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.32M); Tue, 19 Dec 2006 23:24:05 GMT X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID460kLsXyF4887Xo1 Received: from [192.168.1.101] ([69.181.78.47]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 16:24:04 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) To: ietf-sasl@imc.org Message-Id: <1E59CC0D-7022-4400-BA48-D9D7B427ABEF@commerce.net> Content-Type: multipart/alternative; boundary=Apple-Mail-6--715119330 References: From: Lisa Dusseault Subject: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication Date: Tue, 19 Dec 2006 15:24:01 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Dec 2006 23:24:04.0221 (UTC) FILETIME=[C5C93AD0:01C723C4] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-6--715119330 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI as well Begin forwarded message: > From: Lisa Dusseault > Date: December 19, 2006 3:01:27 PM PST > To: ietf-pop3ext@imc.org > Cc: Rob Siemborski , ams@oryx.com, Alexey > Melnikov , Frank Ellermann > , Arnt Gulbrandsen > Subject: "POP3 SASL Authentication Mechanism" submitted for > publication > > > The authors of "POP3 SASL Authentication Mechanism" (draft- > siemborski-rfc1734bis-07.txt) have submitted it to me for > publication as an individual submission, with the intention that it > go to Proposed Standard. It would obsolete RFC1734 ("POP3 > AUTHentication command") and udpate RFC 2449 ("POP3 Extension > Mechanism"). > > I'm beginning my own personal review, in advance of doing IETF last > call. > > The authors are Rob Siemborski and Abhijit Menon-Sen. They > provided the following summary information: > >> This document is a revision of RFC 1734, which specifies the >> POP3 AUTH >> command, which allows a POP3 client to initiate a SASL >> authentication >> exchange with a POP3 server. >> >> This document is not the result of a WG. >> >> The document has been reviewed by Frank Ellermann, Alexey >> Melnikov, >> Arnt Gulbrandsen. To the best of my knowledge, the majority of >> POP3 >> implementations support this extension already. >> >> > > Any comments on the document, its intended publication status or > current implementation status, are welcome. I'd particularly like > to know if there are other reviewers or any outstanding issues. > > Thanks, > Lisa D. --Apple-Mail-6--715119330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI as = well

Begin forwarded message:

From: = Lisa Dusseault <lisa@osafoundation.org>
Date: December 19, 2006 3:01:27 PM = PST
=
Cc: Rob = Siemborski <robsiemb@google.com>, ams@oryx.com, Alexey Melnikov <alexey.melnikov@isode.com>= ;, Frank Ellermann <nobody@xyzzy.claranet.de>,= Arnt Gulbrandsen <arnt@oryx.com>
Subject: = "POP3 SASL Authentication Mechanism" submitted for = publication

The authors of "POP3 SASL Authentication Mechanism" = (draft-siemborski-rfc1734bis-07.txt) have submitted it to me for = publication as an individual submission, with the intention that it go = to Proposed Standard.=A0 It = would obsolete RFC1734 ("POP3 AUTHentication command") and udpate RFC = 2449 ("POP3 Extension Mechanism").

I'm beginning my own personal = review, in advance of doing IETF last call.

The authors = are Rob Siemborski and Abhijit Menon-Sen.=A0 They provided the following = summary information:
=A0 This document is a revision = of RFC 1734, which specifies the POP3 AUTH
=A0 command, which allows a POP3 = client to initiate a SASL authentication
=A0 exchange with a POP3 = server.

=A0=A0 = This document is not the result of a WG.

=A0=A0 The document has been = reviewed by Frank Ellermann, Alexey Melnikov,
=A0=A0 = Arnt Gulbrandsen. To the best of my knowledge, the majority of = POP3
=A0=A0 implementations support = this extension already.


=

Any comments on the document, its intended = publication status or current implementation status, are welcome.=A0 I'd particularly like to know = if there are other reviewers or any outstanding issues.

Lisa D.
=

= --Apple-Mail-6--715119330-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDFHHZ9058728; Wed, 13 Dec 2006 08:17:17 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDFHHmU058727; Wed, 13 Dec 2006 08:17:17 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ms-smtp-02.rdc-nyc.rr.com (ms-smtp-02.rdc-nyc.rr.com [24.29.109.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDFHF9w058720 for ; Wed, 13 Dec 2006 08:17:16 -0700 (MST) (envelope-from jaltman@secure-endpoints.com) Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBDFHE98022875 for ; Wed, 13 Dec 2006 10:17:14 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000037613.msg for ; Wed, 13 Dec 2006 10:18:28 -0500 Message-ID: <458019CB.30505@secure-endpoints.com> Date: Wed, 13 Dec 2006 10:18:35 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: GS2 update References: <87ods3jgdz.fsf@latte.josefsson.org> <87zmb3merz.fsf@latte.josefsson.org> <87u00tujkw.fsf@latte.josefsson.org> <3A4EBDBA01CB979E5B8D9EFE@sirius.fac.cs.cmu.edu> <885B371E-14C7-471F-9E71-3EA01FE44D5D@josefsson.org> <20061121232917.GL5938@binky.Central.Sun.COM> <87wt5ne7ap.fsf@latte.josefsson.org> <20061122182230.GX5938@binky.Central.Sun.COM> <45649D69.5070709@isode.com> <20061122204021.GZ5938@binky.Central.Sun.COM> In-Reply-To: <20061122204021.GZ5938@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.1.2 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000208070609000300030900" X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Wed, 13 Dec 2006 10:18:28 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: ietf-sasl@imc.org Reply-To: jaltman@secure-endpoints.com X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000208070609000300030900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > There was a good reason for wanting to leave part of the specification > in draft-altman-tls-cb open, but I forget what it was (IIRC it had > something to do with TELNET's use of finished messages with StartTLS). This was the reason. What we agreed to do in San Diego is to make TELNET an exception. The TELNET START-TLS protocol is widely deployed and can't be changed at this point. The spec is simply going to define it own TLS channel bindings and not reference the channel bindings framework. At San Diego it was also agreed that the TLS Channel Bindings specification would remove all choice from applications that refer to the framework. Simon Josefsson wrote: > Otherwise the channel binding document seem stuck on TLS <= 1.1. See > also http://article.gmane.org/gmane.ietf.sasl/2384 This e-mail does not imply that finished messages are being removed from TLS 1.2. What is does imply is that how the finished messages are computed internal to TLS will change in TLS 1.2. This is irrelevant to their use as channel bindings input. ---- TLS channel bindings -01 is being submitted today that removes the ambiguity as to how the channel bindings are formed. Jeffrey Altman --------------ms000208070609000300030900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMTMxNTE4MzZaMCMGCSqGSIb3DQEJBDEWBBS292GJ mwzjF4GwAjrZiDHclOGhmDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAjxzIhTJxOLHce0StC4NSQHIF472IKm3rGfdrCQp32ezuqAkUYft0 IglncNHBDI4DZffZ3fSfZ/J6xhBc9wKuNrZmtqw5xR9tK9Hvk1bo+LxtWDLhjxH6op1QP19Y cVs/9jILMRJPSd0+1cJl7eXz+ethGgW/5nmDOG209jC1ys63XEVxrDmB+rtix3gzMq5jPCtw N+pRz438j41jdn3ULnseOfYIrfYb18y8rwmkTY7AYcrrMJh+OIswxO6pWweKp0b2+mi3uVAA 8x5qUV7+Kv97YL+aP8t7AZyZYF7pEzEfzFZOGGZpMDFKnEinZ/QLH7pFurED3xzeLWGIZzQR 5AAAAAAAAA== --------------ms000208070609000300030900-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7No8uS088582; Thu, 7 Dec 2006 16:50:08 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7No8I5088581; Thu, 7 Dec 2006 16:50:08 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7No7Mw088571 for ; Thu, 7 Dec 2006 16:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 19EC617641; Thu, 7 Dec 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GsT05-0000Ns-MQ; Thu, 07 Dec 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-gs2-04.txt Message-Id: Date: Thu, 07 Dec 2006 18:50:01 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Author(s) : S. Josefsson Filename : draft-ietf-sasl-gs2-04.txt Pages : 32 Date : 2006-12-7 This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous SASL/GSS-API mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports a SASL-specific notion of channel binding. See for more information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-gs2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-gs2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-7152327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-gs2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-gs2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-7152327.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7JnMtK059540; Thu, 7 Dec 2006 12:49:22 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7JnMZw059539; Thu, 7 Dec 2006 12:49:22 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7JnLaD059533 for ; Thu, 7 Dec 2006 12:49:21 -0700 (MST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB7JnKJF027855 for ; Thu, 7 Dec 2006 11:49:21 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB7JnKv3025331 for ; Thu, 7 Dec 2006 12:49:20 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB7JnHxj028837; Thu, 7 Dec 2006 13:49:17 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB7JnG35028836; Thu, 7 Dec 2006 13:49:16 -0600 (CST) Date: Thu, 7 Dec 2006 13:49:16 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Sam Hartman , Tom Yu , ietf-sasl@imc.org Subject: Re: volunteer for text on non-integrity mechanisms in GS2? Message-ID: <20061207194916.GS26175@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Sam Hartman , Tom Yu , ietf-sasl@imc.org References: <65619720652861F48EDC82DB@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65619720652861F48EDC82DB@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Dec 07, 2006 at 01:48:56PM -0500, Jeffrey Hutzelman wrote: > On Wednesday, December 06, 2006 07:17:58 PM -0500 Sam Hartman > wrote: > > >If I have to write the text to get the feature, I will. I'd really > >rather someone else do it though. > > Well, since we're still hashing out in another thread how to provide the > feature and what the constraints are on its design, I think text is > premature. Well, no, most of the text should be the same. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7J7AeU053524; Thu, 7 Dec 2006 12:07:10 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7J7A6p053522; Thu, 7 Dec 2006 12:07:10 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7J77pm053515 for ; Thu, 7 Dec 2006 12:07:08 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id CDF03E0050; Thu, 7 Dec 2006 14:06:57 -0500 (EST) From: Sam Hartman To: Jeffrey Hutzelman Cc: Tom Yu , ietf-sasl@imc.org Subject: Re: volunteer for text on non-integrity mechanisms in GS2? References: <65619720652861F48EDC82DB@sirius.fac.cs.cmu.edu> Date: Thu, 07 Dec 2006 14:06:57 -0500 In-Reply-To: <65619720652861F48EDC82DB@sirius.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 07 Dec 2006 13:48:56 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Wednesday, December 06, 2006 07:17:58 PM -0500 Sam Jeffrey> Hartman Jeffrey> wrote: >> If I have to write the text to get the feature, I will. I'd >> really rather someone else do it though. Jeffrey> Well, since we're still hashing out in another thread how Jeffrey> to provide the feature and what the constraints are on Jeffrey> its design, I think text is premature. Agreed. But I wanted to get a response in under the deadline to the chairs' query. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7In1ch051045; Thu, 7 Dec 2006 11:49:01 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7In1Ae051044; Thu, 7 Dec 2006 11:49:01 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7In0k4051036 for ; Thu, 7 Dec 2006 11:49:00 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id kB7ImuKN018041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Dec 2006 13:48:57 -0500 (EST) Date: Thu, 07 Dec 2006 13:48:56 -0500 From: Jeffrey Hutzelman To: Sam Hartman , Tom Yu cc: ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: volunteer for text on non-integrity mechanisms in GS2? Message-ID: <65619720652861F48EDC82DB@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:014jTIg0ycPfcuf0AEFbL48nmm/65paEFPqfboGLQ=; 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 Wednesday, December 06, 2006 07:17:58 PM -0500 Sam Hartman wrote: > If I have to write the text to get the feature, I will. I'd really > rather someone else do it though. Well, since we're still hashing out in another thread how to provide the feature and what the constraints are on its design, I think text is premature. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7Hn7C6044635; Thu, 7 Dec 2006 10:49:07 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7Hn7IE044634; Thu, 7 Dec 2006 10:49:07 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7Hn59D044626 for ; Thu, 7 Dec 2006 10:49:06 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id kB7HmxXP017979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Dec 2006 12:49:00 -0500 (EST) Date: Thu, 07 Dec 2006 12:48:59 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , Sam Hartman cc: Simon Josefsson , Alexey Melnikov , ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: GS2 update Message-ID: In-Reply-To: <20061207172318.GQ26175@binky.Central.Sun.COM> References: <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> <20061207172318.GQ26175@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01FLiKxn4g/zpgAwJHRza6NasqwfGb7AOBLbgrSjg=; 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 Thursday, December 07, 2006 11:23:18 AM -0600 Nicolas Williams wrote: > Sam's proposal that we substitute the identity function (note: no length > field is needed) for GSS_Wrap() when dealing with non-integrity GS2 > mechs will do, so we can avoid this thread by just accepting it. I have no problem with this approach. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7HNM7g040281; Thu, 7 Dec 2006 10:23:22 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7HNMfx040280; Thu, 7 Dec 2006 10:23:22 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7HNLQ6040260 for ; Thu, 7 Dec 2006 10:23:22 -0700 (MST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB7HNLtg004755 for ; Thu, 7 Dec 2006 09:23:21 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB7HNKg3024300 for ; Thu, 7 Dec 2006 10:23:20 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB7HNIBa028727; Thu, 7 Dec 2006 11:23:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB7HNIuE028726; Thu, 7 Dec 2006 11:23:18 -0600 (CST) Date: Thu, 7 Dec 2006 11:23:18 -0600 From: Nicolas Williams To: Sam Hartman Cc: Jeffrey Hutzelman , Simon Josefsson , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: GS2 update Message-ID: <20061207172318.GQ26175@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Hutzelman , Simon Josefsson , Alexey Melnikov , ietf-sasl@imc.org References: <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> 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: Sam opposes relying on GSS_Wrap() for mechs without integrity protection because it would encourage proliferation of this which means that GSS-API applications have to be more careful to check the context ret_flags rather than assume that GSS_Wrap() will provide at least integrity protection. On the one hand I agree, on the other GSS-API apps already have to be careful about this because RFC2743 allows GSS_Wrap() to provide no protection whatsoever when the context ret_flags indicate neither confidentiality nor integrity protection. Sam's proposal that we substitute the identity function (note: no length field is needed) for GSS_Wrap() when dealing with non-integrity GS2 mechs will do, so we can avoid this thread by just accepting it. Nico -- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7GQudo033918; Thu, 7 Dec 2006 09:26:56 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7GQu9o033917; Thu, 7 Dec 2006 09:26:56 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7GQtqp033911 for ; Thu, 7 Dec 2006 09:26:56 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4E05EE0050; Thu, 7 Dec 2006 11:26:46 -0500 (EST) From: Sam Hartman To: Jeffrey Hutzelman Cc: Nicolas Williams , Simon Josefsson , Alexey Melnikov , Subject: Re: GS2 update References: Date: Thu, 07 Dec 2006 11:26:46 -0500 In-Reply-To: (Jeffrey Hutzelman's message of "Thu, 7 Dec 2006 10:40:47 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Thu, 7 Dec 2006, Nicolas Williams wrote: >> On Wed, Dec 06, 2006 at 07:17:19PM -0500, Sam Hartman wrote: >>> It makes GSS mechanisms significantly harder to design than >>> SASL mechanisms. Jeffrey> How? Why? You have to specify the wrap behavior. I guess significantly is over stating it. >>> Also, I believe that it is undesirable for gss mechanisms that >>> do not support integrity to support gss_wrap. Jeffrey> Why? Because application designers assume that gss_wrap provides integrity and design their applications accordingly. Now, yes this is buggy, but since I don't see significant benefits to gss_wrap for no-integrity mechanisms and I do think it increases the probability of application bugs, we should discourage it. I think though that this is a discussion for kitten not SASL. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7G93kY031865; Thu, 7 Dec 2006 09:09:03 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7G93NM031864; Thu, 7 Dec 2006 09:09:03 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7G91vW031854 for ; Thu, 7 Dec 2006 09:09:03 -0700 (MST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB7G90VE024700 for ; Thu, 7 Dec 2006 08:09:00 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB7G90Sh010369 for ; Thu, 7 Dec 2006 09:09:00 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB7G8wQq028641; Thu, 7 Dec 2006 10:08:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB7G8w8x028640; Thu, 7 Dec 2006 10:08:58 -0600 (CST) Date: Thu, 7 Dec 2006 10:08:58 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Simon Josefsson , Sam Hartman , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: GS2 update Message-ID: <20061207160856.GP26175@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Simon Josefsson , Sam Hartman , Alexey Melnikov , ietf-sasl@imc.org References: <877ix4qcm4.fsf@latte.josefsson.org> 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 07, 2006 at 10:38:24AM -0500, Jeffrey Hutzelman wrote: > On Thu, 7 Dec 2006, Simon Josefsson wrote: > > > I believe that to assume that GSS_Wrap exist in non-integrity > > mechanisms was a clever idea. > > Well, it's only a clever idea if the assumption is usually true. We can't say it's usually true when we have no such standard mechanisms. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7G8SJI031736; Thu, 7 Dec 2006 09:08:28 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7G8St0031735; Thu, 7 Dec 2006 09:08:28 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7G8SlZ031712 for ; Thu, 7 Dec 2006 09:08:28 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C1802E0050; Thu, 7 Dec 2006 11:08:18 -0500 (EST) From: Sam Hartman To: Simon Josefsson Cc: Jeffrey Hutzelman , Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: GS2 can already support non-integrity mechanisms References: <87ods3jgdz.fsf@latte.josefsson.org> <87zmb3merz.fsf@latte.josefsson.org> <87u00tujkw.fsf@latte.josefsson.org> <4564610F.9030305@isode.com> <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> <877ix4qcm4.fsf@latte.josefsson.org> <87y7pkovi3.fsf_-_@latte.josefsson.org> Date: Thu, 07 Dec 2006 11:08:18 -0500 In-Reply-To: <87y7pkovi3.fsf_-_@latte.josefsson.org> (Simon Josefsson's message of "Thu, 07 Dec 2006 11:23:00 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> Simon Josefsson writes: >> I believe that to assume that GSS_Wrap exist in non-integrity >> mechanisms was a clever idea. The approach solve my concerns >> with effectively creating two protocol-paths within GS2. I >> haven't considered all implications, but it seems possible to >> make this happen in GS2 with only a few new paragraphs of text. >> I'm going to look over the document now and see what needs to >> be changed. Simon> I went over the document to look for changes to make this Simon> happen. It seems to me that if you stretch the Simon> interpretation of some parts of the document, but only a Simon> little, non-integrity mechanisms are already supported in Simon> GS2, _if_ the mechanism provide a working GSS_Wrap. There Simon> are some caveats, and there should probably be some minor Simon> text added to clarify things. OK. Then let's add a section to the document saying that if the context comes back without integrity available that rather than calling gss_wrap you use the identity function with a length prefix. It's not much extra work, can be well contained and does not place restrictions on mechanisms. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7G6GFl031504; Thu, 7 Dec 2006 09:06:16 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7G6GJM031503; Thu, 7 Dec 2006 09:06:16 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7G6E9f031492 for ; Thu, 7 Dec 2006 09:06:15 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A2BCFE0050; Thu, 7 Dec 2006 11:06:03 -0500 (EST) From: Sam Hartman To: Jeffrey Hutzelman Cc: Simon Josefsson , Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: GS2 update References: <87ods3jgdz.fsf@latte.josefsson.org> <87zmb3merz.fsf@latte.josefsson.org> <87u00tujkw.fsf@latte.josefsson.org> <4564610F.9030305@isode.com> <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> Date: Thu, 07 Dec 2006 11:06:03 -0500 In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 06 Dec 2006 19:24:08 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Wednesday, December 06, 2006 07:17:19 PM -0500 Sam Jeffrey> Hartman Jeffrey> wrote: >>>>>>> "Simon" == Simon Josefsson writes: >> Simon> However, if we can assume that non-integrity mechanisms Simon> provide GSS_Wrap, that will make the GS2 protocol syntax Simon> the same for both alternatives, and then I have no problem Simon> with supporting those mechanisms in GS2. >> I don't think this is reasonable. It makes GSS mechanisms >> significantly harder to design than SASL mechanisms. Also, I >> believe that it is undesirable for gss mechanisms that do not >> support integrity to support gss_wrap. Jeffrey> Do you think the assumption is invalid, or just that it's Jeffrey> an unreasonable expectation to place on new GSS Jeffrey> mechanisms? I think the assumption is unreasonable *because* it is an undesirable thing for gss mechanisms without integrity to do. People assume that gss_wrap provides integrity. I realize the spec does not guarantee this. But it seems like 1) you don't need a mechanisms-specific format for wrap without integrity 2) If wrap returns an error rather than wrapping without integrity, it is likely that it will prevent application problems. 3) Designing a token format once for sasl gs2 is easier than doing the same work for every mechanism. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7FgbCd028293; Thu, 7 Dec 2006 08:42:37 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7FgbaF028292; Thu, 7 Dec 2006 08:42:37 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB7Fgadi028283 for ; Thu, 7 Dec 2006 08:42:37 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06898; 7 Dec 2006 10:40 EST Date: Thu, 7 Dec 2006 10:40:47 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: Sam Hartman , Simon Josefsson , Alexey Melnikov , Subject: Re: GS2 update In-Reply-To: <20061207150543.GK26175@binky.Central.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 7 Dec 2006, Nicolas Williams wrote: > On Wed, Dec 06, 2006 at 07:17:19PM -0500, Sam Hartman wrote: >> It makes GSS mechanisms >> significantly harder to design than SASL mechanisms. How? Why? >> Also, I believe >> that it is undesirable for gss mechanisms that do not support >> integrity to support gss_wrap. Why? Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7FcpgV027832; Thu, 7 Dec 2006 08:38:51 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7FcpvA027831; Thu, 7 Dec 2006 08:38:51 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB7FcnvY027824 for ; Thu, 7 Dec 2006 08:38:50 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06891; 7 Dec 2006 10:38 EST Date: Thu, 7 Dec 2006 10:38:24 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Simon Josefsson cc: Sam Hartman , Nicolas Williams , Alexey Melnikov , Subject: Re: GS2 update In-Reply-To: <877ix4qcm4.fsf@latte.josefsson.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 7 Dec 2006, Simon Josefsson wrote: > I believe that to assume that GSS_Wrap exist in non-integrity > mechanisms was a clever idea. Well, it's only a clever idea if the assumption is usually true. -- Jeff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7F6fuT021207; Thu, 7 Dec 2006 08:06:41 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7F6fSn021205; Thu, 7 Dec 2006 08:06:41 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7F6d2K021199 for ; Thu, 7 Dec 2006 08:06:39 -0700 (MST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB7F6csD014268 for ; Thu, 7 Dec 2006 08:06:38 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB7F6cUS004766 for ; Thu, 7 Dec 2006 08:06:38 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB7F6bAn028538; Thu, 7 Dec 2006 09:06:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB7F6bwG028537; Thu, 7 Dec 2006 09:06:37 -0600 (CST) Date: Thu, 7 Dec 2006 09:06:37 -0600 From: Nicolas Williams To: Sam Hartman Cc: Tom Yu , ietf-sasl@imc.org Subject: Re: volunteer for text on non-integrity mechanisms in GS2? Message-ID: <20061207150636.GL26175@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Tom Yu , 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 Wed, Dec 06, 2006 at 07:17:58PM -0500, Sam Hartman wrote: > If I have to write the text to get the feature, I will. I'd really > rather someone else do it though. Do you object to the GSS_Wrap approach? Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7F5oPH021151; Thu, 7 Dec 2006 08:05:50 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7F5okb021150; Thu, 7 Dec 2006 08:05:50 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7F5lZJ021127 for ; Thu, 7 Dec 2006 08:05:48 -0700 (MST) (envelope-from nw141292@binky.Central.Sun.COM) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB7F5ltc010776 for ; Thu, 7 Dec 2006 07:05:47 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB7F5kbX004377 for ; Thu, 7 Dec 2006 08:05:47 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB7F5jYn028531; Thu, 7 Dec 2006 09:05:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB7F5hTc028530; Thu, 7 Dec 2006 09:05:43 -0600 (CST) Date: Thu, 7 Dec 2006 09:05:43 -0600 From: Nicolas Williams To: Sam Hartman Cc: Simon Josefsson , Jeffrey Hutzelman , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: GS2 update Message-ID: <20061207150543.GK26175@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Simon Josefsson , Jeffrey Hutzelman , Alexey Melnikov , ietf-sasl@imc.org References: <87u00tujkw.fsf@latte.josefsson.org> <4564610F.9030305@isode.com> <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> 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 Wed, Dec 06, 2006 at 07:17:19PM -0500, Sam Hartman wrote: > >>>>> "Simon" == Simon Josefsson writes: > > Simon> However, if we can assume that non-integrity mechanisms > Simon> provide GSS_Wrap, that will make the GS2 protocol syntax > Simon> the same for both alternatives, and then I have no problem > Simon> with supporting those mechanisms in GS2. > > I don't think this is reasonable. It makes GSS mechanisms > significantly harder to design than SASL mechanisms. Also, I believe > that it is undesirable for gss mechanisms that do not support > integrity to support gss_wrap. I disagree with the second and third sentences above, therefore I disagree with the first. Nico -- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7ANG4s086282; Thu, 7 Dec 2006 03:23:16 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7ANGG3086281; Thu, 7 Dec 2006 03:23:16 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7ANBYl086275 for ; Thu, 7 Dec 2006 03:23:15 -0700 (MST) (envelope-from simon@josefsson.org) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kB7AN0xd007881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Dec 2006 11:23:00 +0100 From: Simon Josefsson To: Jeffrey Hutzelman Cc: Sam Hartman , Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: GS2 can already support non-integrity mechanisms (was: Re: GS2 update) References: <87ods3jgdz.fsf@latte.josefsson.org> <87zmb3merz.fsf@latte.josefsson.org> <87u00tujkw.fsf@latte.josefsson.org> <4564610F.9030305@isode.com> <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> <877ix4qcm4.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061207:alexey.melnikov@isode.com::CTKYUDktPUBjbBgy:2rEY X-Hashcash: 1:22:061207:ietf-sasl@imc.org::k4+fPRRA6d7A5IlS:BVeY X-Hashcash: 1:22:061207:jhutz@cmu.edu::qd8Q2VqEhEh7Ug8p:CVar X-Hashcash: 1:22:061207:nicolas.williams@sun.com::lYNHjHLLtLsVZIgT:Bdnk X-Hashcash: 1:22:061207:hartmans-ietf@mit.edu::RZ6v8/U3xAdZsT/p:OYX/ Date: Thu, 07 Dec 2006 11:23:00 +0100 In-Reply-To: <877ix4qcm4.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu\, 07 Dec 2006 10\:28\:03 +0100") Message-ID: <87y7pkovi3.fsf_-_@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson writes: > I believe that to assume that GSS_Wrap exist in non-integrity > mechanisms was a clever idea. The approach solve my concerns with > effectively creating two protocol-paths within GS2. I haven't > considered all implications, but it seems possible to make this happen > in GS2 with only a few new paragraphs of text. I'm going to look over > the document now and see what needs to be changed. I went over the document to look for changes to make this happen. It seems to me that if you stretch the interpretation of some parts of the document, but only a little, non-integrity mechanisms are already supported in GS2, _if_ the mechanism provide a working GSS_Wrap. There are some caveats, and there should probably be some minor text added to clarify things. Below is a walk-through if the relevant parts of the document related to integrity requirements, and finally a proposal for changes to clarify that GS2 support non-integrity mechanisms with GSS_Wrap. I believe the changes I propose below are sufficient to resolve this issue, under the assumption that GSS_Wrap is supported in relevant non-integrity GSS-API mechanisms. If someone disagree with that assumption, I'd really like for them to write a message similar to this, containing rationale and the proposed changes that are required to implement this feature, with whatever other assumptions they find acceptable. I have to twist my head to begin thinking that non-integrity mechanisms are relevant to GS2, they weren't up until the WGLC. Generally, I'd rather see people who care about an issue do the work, it will result in a better deliverable. [I quote text from the just submitted -04 version, available from http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-04.txt.] In section 4.2.1 it says: When calling the GSS_Init_sec_context the client MUST pass the integ_req_flag of TRUE. If the client intends to request a security layer, it MUST also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE, and a sequence_req_flag of TRUE. If the client will be requesting a security layer providing confidentiality protection, it MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. ... When GSS_Init_sec_context returns GSS_S_COMPLETE, the client MUST examine the context to ensure that it provides a level of protection permitted by the client's security policy. A non-integrity capable GSS-API mechanism does not need to have a problem with that. It can ignore integ_req_flag=TRUE, since it cannot provide integrity, and will return Integ_avail=FALSE. That's ok by RFC 2743 as far as I can see. The application MUST check that this is compatible with its security policy. As long as non-integrity mechanisms are acceptable to the security policy, that will work. There could be some text changes here to permit that applications set integ_req_flag=FALSE, when the application knows that the mechanism (or the credential) won't support integrity. This does not seem strictly required, though, but may be helpful. Section 4.3 says: The Wrap token field MUST NOT be sent or received before the PROT_READY flag is set locally (by GSS_Init_sec_context or Gss_Accept_sec_context), or if the PROT_READY flag is never set, before the context has been fully established. The Wrap token field does not have to be present directly when the PROT_READY flag is set. During any exchange, exactly one Wrap token field is sent in each direction. The input to the GSS_Wrap function MUST follow the format described below. If not exactly one Wrap token is received by the client and by the server, the authentication MUST fail. If PROT_READY is never set by GSS_Init_sec_context or GSS_Accept_sec_context, the flag is implied by successful context negotiation. This is for GSS-API v1 mechanisms that do not support PROT_READY. This may result in a SASL token consisting of a context token length of 0 and a Wrap token. I believe this is slightly inaccurate considering non-integrity mechanisms. PROT_READY won't ever be set, even for a GSS-API v2 mechanisms. However, this does not affect the protocol. The text could be modified to note that there is another reason for PROT_READY to never be set: because the mechanism doesn't support integrity. Section 4.3 also says: The inputs below are passed to GSS_Wrap with conf_flag set to FALSE, and the Wrap token will be the generated output_message. This will work with non-integrity mechanisms with GSS_Wrap support. Generally, the remaining discussions related channel bindings and security layers are all moot if there is no integrity support. That should be explained explicitly somewhere. Here is a list of changes to GS2 that I believe are sufficient to support GSS mechanism that lack integrity support, but does support GSS_Wrap and GSS_Unwrap correctly: * (Optional) Say that GSS_Init_sec_context can be called with Integ_reg_flag=FALSE if the application knows the mechanism or credential won't support integrity. * Clarify in 4.3 that PROT_READY won't be set for mechanisms that doesn't support integrity as well. * Add a new section that discuss non-integrity mechanisms on a general level. I suggest the following: X. Supporting GSS-API mechanisms that do not support integrity Mechanisms that do not support integrity can be used with GS2, but some security features cannot be provided, in particular including channel bindings, security layer and integrity protection of the authorization identity. The requirement on the GSS-API mechanism is that it support GSS_Wrap and GSS_Unwrap. Channel bindings and security layers MUST NOT be negotiated when the GSS-API mechanism do not support integrity. It should also be understood that the authorization identity is not integrity protected. * Add new security consideration to discuss this weakness. I suggest: The security provided by GS2 depends on the security provided by the GSS-API mechanism. If the mechanism do not provide integrity protection, the authorization identity can be replaced by a man in the middle, and channel bindings and security layers cannot be negotiated. Therefor, it is generally recommended against using any GSS-API mechanism that do not support integrity widely on the Internet. Thoughts, comments? /Simon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB79SHlF079119; Thu, 7 Dec 2006 02:28:17 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB79SHiE079118; Thu, 7 Dec 2006 02:28:17 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB79SEdF079107 for ; Thu, 7 Dec 2006 02:28:15 -0700 (MST) (envelope-from simon@josefsson.org) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kB79S3jt031378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Dec 2006 10:28:03 +0100 From: Simon Josefsson To: Jeffrey Hutzelman Cc: Sam Hartman , Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: GS2 update References: <87ods3jgdz.fsf@latte.josefsson.org> <87zmb3merz.fsf@latte.josefsson.org> <87u00tujkw.fsf@latte.josefsson.org> <4564610F.9030305@isode.com> <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061207:ietf-sasl@imc.org::yaAe2+24alQa67y1:E/wI X-Hashcash: 1:22:061207:nicolas.williams@sun.com::WnOCEtK1sThiVG9H:8SZO X-Hashcash: 1:22:061207:alexey.melnikov@isode.com::5wCtEaqaM0jK4o1e:6fYM X-Hashcash: 1:22:061207:jhutz@cmu.edu::cTS4CUbAyUpSDQ28:MPkk X-Hashcash: 1:22:061207:hartmans-ietf@mit.edu::JKAM6+hqsZP0JCKo:bECw Date: Thu, 07 Dec 2006 10:28:03 +0100 In-Reply-To: (Jeffrey Hutzelman's message of "Wed\, 06 Dec 2006 19\:24\:08 -0500") Message-ID: <877ix4qcm4.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > On Wednesday, December 06, 2006 07:17:19 PM -0500 Sam Hartman > wrote: > >>>>>>> "Simon" == Simon Josefsson writes: >> >> Simon> However, if we can assume that non-integrity mechanisms >> Simon> provide GSS_Wrap, that will make the GS2 protocol syntax >> Simon> the same for both alternatives, and then I have no problem >> Simon> with supporting those mechanisms in GS2. >> >> I don't think this is reasonable. It makes GSS mechanisms >> significantly harder to design than SASL mechanisms. Also, I believe >> that it is undesirable for gss mechanisms that do not support >> integrity to support gss_wrap. > > Do you think the assumption is invalid, or just that it's an > unreasonable expectation to place on new GSS mechanisms? > > If you're going to design a new GSS mechanism which does not support integrity, why is it so much to ask that it provide the GSS_Wrap API -- > especially when that can essentially be a no-op? I ask myself the same question. Cannot GSS_Wrap in a GSS mechanism that doesn't support integrity could be the identity function, i.e., just return the buffer that is passed to GSS_Wrap? Is there something broken with that approach? The flags should indicate that neither integrity nor confidentiality were provided. That doesn't seem difficult to implement or to support. I believe that to assume that GSS_Wrap exist in non-integrity mechanisms was a clever idea. The approach solve my concerns with effectively creating two protocol-paths within GS2. I haven't considered all implications, but it seems possible to make this happen in GS2 with only a few new paragraphs of text. I'm going to look over the document now and see what needs to be changed. /Simon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB75JjpO054249; Wed, 6 Dec 2006 22:19:45 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB75JjRn054248; Wed, 6 Dec 2006 22:19:45 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from wip-ectls-mx3.wipro.com (wip-ectls-mx3.wipro.com [203.91.193.23]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB75Jg06054230 for ; Wed, 6 Dec 2006 22:19:44 -0700 (MST) (envelope-from dhairyashil.dilip@wipro.com) Received: from wip-ectls-mx3.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 712F3224467; Thu, 7 Dec 2006 10:49:32 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ectls-mx3.wipro.com (Postfix) with ESMTP id 6166A224435; Thu, 7 Dec 2006 10:49:32 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.167]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:49:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: volunteer for text on non-integrity mechanisms in GS2? Date: Thu, 7 Dec 2006 10:49:31 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: volunteer for text on non-integrity mechanisms in GS2? Thread-Index: AccZmeLrPX5UERIST1eUzKAKo2nIPQAJfyiA From: To: , Cc: X-OriginalArrivalTime: 07 Dec 2006 05:19:32.0077 (UTC) FILETIME=[46CF09D0:01C719BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB75Jj06054243 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would like to take up that one, but someone please guide me on that. -----Original Message----- From: owner-ietf-sasl@mail.imc.org [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Sam Hartman Sent: Thursday, December 07, 2006 5:48 AM To: Tom Yu Cc: ietf-sasl@imc.org Subject: Re: volunteer for text on non-integrity mechanisms in GS2? If I have to write the text to get the feature, I will. I'd really rather someone else do it though. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB70OBP9027122; Wed, 6 Dec 2006 17:24:11 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB70OBgf027121; Wed, 6 Dec 2006 17:24:11 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB70OAQD027115 for ; Wed, 6 Dec 2006 17:24:10 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id kB70O84U016849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Dec 2006 19:24:08 -0500 (EST) Date: Wed, 06 Dec 2006 19:24:08 -0500 From: Jeffrey Hutzelman To: Sam Hartman , Simon Josefsson cc: Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: GS2 update Message-ID: In-Reply-To: References: <87ods3jgdz.fsf@latte.josefsson.org> <87zmb3merz.fsf@latte.josefsson.org> <87u00tujkw.fsf@latte.josefsson.org> <4564610F.9030305@isode.com> <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> Originator-Info: login-token=Mulberry:0127f0gkUfafYnAmwDDjUk8XIpK61i621ILCLnETc=; 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 Wednesday, December 06, 2006 07:17:19 PM -0500 Sam Hartman wrote: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> However, if we can assume that non-integrity mechanisms > Simon> provide GSS_Wrap, that will make the GS2 protocol syntax > Simon> the same for both alternatives, and then I have no problem > Simon> with supporting those mechanisms in GS2. > > I don't think this is reasonable. It makes GSS mechanisms > significantly harder to design than SASL mechanisms. Also, I believe > that it is undesirable for gss mechanisms that do not support > integrity to support gss_wrap. Do you think the assumption is invalid, or just that it's an unreasonable expectation to place on new GSS mechanisms? If you're going to design a new GSS mechanism which does not support integrity, why is it so much to ask that it provide the GSS_Wrap API -- especially when that can essentially be a no-op? -- Jeff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB70I7m2026622; Wed, 6 Dec 2006 17:18:07 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB70I7Ar026621; Wed, 6 Dec 2006 17:18:07 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB70I6nw026614 for ; Wed, 6 Dec 2006 17:18:07 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 33CA9E0050; Wed, 6 Dec 2006 19:17:58 -0500 (EST) From: Sam Hartman To: Tom Yu Cc: ietf-sasl@imc.org Subject: Re: volunteer for text on non-integrity mechanisms in GS2? References: Date: Wed, 06 Dec 2006 19:17:58 -0500 In-Reply-To: (Tom Yu's message of "Wed, 29 Nov 2006 20:51:28 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If I have to write the text to get the feature, I will. I'd really rather someone else do it though. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB70HUwZ026533; Wed, 6 Dec 2006 17:17:30 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB70HU2L026532; Wed, 6 Dec 2006 17:17:30 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB70HTTe026525 for ; Wed, 6 Dec 2006 17:17:29 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4A94BE0050; Wed, 6 Dec 2006 19:17:19 -0500 (EST) From: Sam Hartman To: Simon Josefsson Cc: Jeffrey Hutzelman , Nicolas Williams , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: GS2 update References: <87ods3jgdz.fsf@latte.josefsson.org> <87zmb3merz.fsf@latte.josefsson.org> <87u00tujkw.fsf@latte.josefsson.org> <4564610F.9030305@isode.com> <1164213972.18357.21.camel@localhost.localdomain> <20061122210235.GB5938@binky.Central.Sun.COM> <87odqzcakv.fsf@latte.josefsson.org> <20061127161906.GK5938@binky.Central.Sun.COM> <20061127174654.GH6994@binky.Central.Sun.COM> <8D67319EA0DEFE2AF018BC8B@sirius.fac.cs.cmu.edu> <873b81xeox.fsf@latte.josefsson.org> Date: Wed, 06 Dec 2006 19:17:19 -0500 In-Reply-To: <873b81xeox.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu, 30 Nov 2006 14:10:54 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> However, if we can assume that non-integrity mechanisms Simon> provide GSS_Wrap, that will make the GS2 protocol syntax Simon> the same for both alternatives, and then I have no problem Simon> with supporting those mechanisms in GS2. I don't think this is reasonable. It makes GSS mechanisms significantly harder to design than SASL mechanisms. Also, I believe that it is undesirable for gss mechanisms that do not support integrity to support gss_wrap. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5BlFni078994; Tue, 5 Dec 2006 04:47:15 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5BlFbB078993; Tue, 5 Dec 2006 04:47:15 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5BlC3R078983 for ; Tue, 5 Dec 2006 04:47:13 -0700 (MST) (envelope-from simon@josefsson.org) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kB5BkwQH024799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Dec 2006 12:46:58 +0100 From: Simon Josefsson To: Alexey Melnikov Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: Identifying channel bindings References: <20061122183246.GY5938@binky.Central.Sun.COM> <4564C315.4040007@isode.com> <20061122222816.GE5938@binky.Central.Sun.COM> <4564D193.6080906@isode.com> <20061127161516.GI5938@binky.Central.Sun.COM> <20061127171343.GG6994@binky.Central.Sun.COM> <877ixdxezo.fsf@latte.josefsson.org> <20061130153058.GR5938@binky.Central.Sun.COM> <456F2811.4030507@isode.com> <20061130195718.GA5938@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061205:jhutz@cmu.edu::7OK4PP+/FdM2+QuC:9GuU X-Hashcash: 1:22:061205:ietf-sasl@imc.org::Hd36Yf243jotMrj4:7VYS X-Hashcash: 1:22:061205:alexey.melnikov@isode.com::tFD9OZ0bYsJDdwy7:Ifnm Date: Tue, 05 Dec 2006 12:46:58 +0100 In-Reply-To: <20061130195718.GA5938@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu\, 30 Nov 2006 13\:57\:19 -0600") Message-ID: <874psava31.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 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: > I think the API design issue will be a non-issue in practice. And for > something like the GSS-API, where the is prefix won't make it across > from initiator to acceptor, the interfaces will have to look like what I > suggested anyways, whether you like it or not). I don't think that holds generally -- it seems possible for GSS-API mechanisms to transfer the channel binding to the other end, or at least signal the prefix somehow. Some mechanisms might not support transferring channel binding, or signal the prefix, but it doesn't seem like an inherent problem in GSS-API. > The security reason that Sam proffers is much more interesting because a > broken protocol is much less pleasant than an API that you find > unpleasant. Sure. /Simon