From owner-ietf-sasl Mon Jul 5 00:51:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i657pPp3060777; Mon, 5 Jul 2004 00:51:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i657pP1W060776; Mon, 5 Jul 2004 00:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i657pKhs060747 for ; Mon, 5 Jul 2004 00:51:21 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BhOFt-0006W7-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: GSS-API channel bindings Date: Mon, 05 Jul 2004 09:51:09 +0200 Lines: 18 Message-ID: References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:K389zgfsMv5NEvcQ6x6g6U/wlfk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is a requirement that the GSS-API channel bindings are NULL. I'd feel more comfortable if there was a way to somehow make use of channel bindings, to link the authentication to the specific channel. Does anyone have ideas on whether to add this, and if the answer is positive, how it might be done? I understand that the simplest "solution", from the SASL mechanism point of view, might simply be to consider GSS-API mechanisms, that doesn't link gss_wrap/gss_get_mic tokens with one specific authentication, as broken. However, channel bindings are provided by GSS-API to enable applications to close this hole, hence these GSS-API mechanisms can probably not be viewed as broken in general. So it is unfortunate that the SASL wrapping of GSS-API forbid channel bindings. I'd say this warrant a paragraph in the security section, unless the text about channel bindings is loosened up. Thanks, Simon From owner-ietf-sasl Wed Jul 7 14:29:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LTc9K061819; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67LTcOh061818; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LTbqF061812 for ; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 269B5E0051; Wed, 7 Jul 2004 17:29:40 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Final changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <40D7666B.7070001@isode.com> From: Sam Hartman Date: Wed, 07 Jul 2004 17:29:40 -0400 In-Reply-To: <40D7666B.7070001@isode.com> (Alexey Melnikov's message of "Mon, 21 Jun 2004 23:51:23 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Rob Siemborski wrote: >> On Fri, 21 May 2004, Sam Hartman wrote: >>> >> It seems we can handle this cleanly enough if we treat it >>> just >> like the initial response. >>> >>> But is it worth the complexity? IT seems that if we can avoid >>> the introduction of distinguishing the two cases we should do >>> so. >>> >>> >> If it is not worth the complexity (and, really, I can't think >> of any situation where an empty server success data would be >> *useful*-- it just seems that we'd be giving up some level of >> flexibility), then we should just forbid empty success data -- >> this would lead to the less confusion than attributing two >> potential meanings to "no success data". >> >> Alexey> Should I treat "forbid empty success data" as the WG Alexey> consensus on empty versa no data on success? I think so. From owner-ietf-sasl Thu Jul 8 18:40:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691eg2X004846; Thu, 8 Jul 2004 18:40:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i691egn5004845; Thu, 8 Jul 2004 18:40:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691ef2g004838 for ; Thu, 8 Jul 2004 18:40:41 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i691ed9O029629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2004 19:40:42 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 08 Jul 2004 18:40:33 -0700 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: in CRAM-MD5 Message-ID: <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> In-Reply-To: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" wrote: > Why isn't RFC-822 msg-id production here as was done in RFC 2195? > The production below is quite different than a msg-id (in some > ways more restrictive and in other ways less restrictive). > > For compatibility with existing RFC 2195, I think this specification > should simple incorporate (directly or by reference) the msg-id > production previously used. There is a problem here. RFC2822 states: msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] If we reference 822 for , people are going to assume the 2822 definition replaces it. Suddenly we have these [CFWS] tokens muddying things up. The format for the challenge reflects directly on CRAM's birth in an email environment. Since email software already had to deal with generating unique message ids, re-using that code as a source for unique strings made sense at the time. But the important property of the challenge is that it be unique, not that it syntactically resemble a element. So relaxing the formatting requirement to simplify the grammar should be fine, provided the new production does not syntactically invalidate existing implementations. Therefore, I'm proposing that we change the syntax of the challenge to: challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" ; a bracketed string of printing characters, not ; containing embedded "<" or ">" and modify the text to emphasize the importance of generating unique challenges, making reference to the historical behaviour. --lyndon From owner-ietf-sasl Fri Jul 9 12:24:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JOtZ4099646; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69JOt26099645; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JOt4n099635 for ; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i69JOvv4016853; Fri, 9 Jul 2004 19:24:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Jul 2004 12:25:04 -0700 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: in CRAM-MD5 Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:40 PM 7/8/2004, Lyndon Nerenberg wrote: >--On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" wrote: > >>Why isn't RFC-822 msg-id production here as was done in RFC 2195? >>The production below is quite different than a msg-id (in some >>ways more restrictive and in other ways less restrictive). >> >>For compatibility with existing RFC 2195, I think this specification >>should simple incorporate (directly or by reference) the msg-id >>production previously used. > >There is a problem here. RFC2822 states: > > msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] > >If we reference 822 for , people are going to assume the 2822 definition replaces it. Suddenly we have these [CFWS] tokens muddying things up. > >The format for the challenge reflects directly on CRAM's birth in an email environment. Since email software already had to deal with generating unique message ids, re-using that code as a source for unique strings made sense at the time. But the important property of the challenge is that it be unique, not that it syntactically resemble a element. So relaxing the formatting requirement to simplify the grammar should be fine, provided the new production does not syntactically invalidate existing implementations. Therefore, I'm proposing that we change the syntax of the challenge to: > > challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" > ; a bracketed string of printing characters, not > ; containing embedded "<" or ">" > >and modify the text to emphasize the importance of generating unique challenges, making reference to the historical behaviour. Seems reasonable to me. Kurt From owner-ietf-sasl Fri Jul 9 14:13:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LDF3F008303; Fri, 9 Jul 2004 14:13:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69LDFw7008302; Fri, 9 Jul 2004 14:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LD5JF008290 for ; Fri, 9 Jul 2004 14:13:14 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i69LD59O034589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2004 15:13:07 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 09 Jul 2004 14:13:00 -0700 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: in CRAM-MD5 Message-ID: <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> In-Reply-To: <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" wrote: >> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" >> ; a bracketed string of printing characters, not >> ; containing embedded "<" or ">" >> >> and modify the text to emphasize the importance of generating unique >> challenges, making reference to the historical behaviour. > > Seems reasonable to me. Excellent. I've sent version -03 of the draft off for publication. The major changes from -02 are: - reformatted and edited to put it into the style the RFC Editor prefers; - mods as described (explanitory text still to come); - new and updated examples from Simon. It would be useful if someone could contribute an ACAP example (or some other non-IMAP example, and which doesn't base64 encode parts of the exchange); - addressed *most* of Kurt's review comments from his March 10 message to the list. Still to be done: - Changes from RFC2195; - the Abstract and Introduction still need work; - text rational for : uniqueness property and historical behaviour (and probably a short paragraph under Security Considerations). --lyndon From owner-ietf-sasl Mon Jul 12 12:38:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CJc7MW058213; Mon, 12 Jul 2004 12:38:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CJc7x8058212; Mon, 12 Jul 2004 12:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CJc55C058198 for ; Mon, 12 Jul 2004 12:38:06 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05044; Mon, 12 Jul 2004 15:38:07 -0400 (EDT) Message-Id: <200407121938.PAA05044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-03.txt Date: Mon, 12 Jul 2004 15:38:07 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-03.txt Pages : 9 Date : 2004-7-12 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-12143512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-12143512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Jul 15 04:21:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FBLOrN016817; Thu, 15 Jul 2004 04:21:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FBLOiL016816; Thu, 15 Jul 2004 04:21:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.gold.ocn.ne.jp (gold.ocn.ne.jp [222.146.40.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FBLM1b016810 for ; Thu, 15 Jul 2004 04:21:23 -0700 (PDT) (envelope-from nkb@pacific.net.sg) Received: from [10.1.5.20] (pat.polyphony.co.jp [210.254.79.2]) by smtp.gold.ocn.ne.jp (Postfix) with ESMTP id 0A6952AB for ; Thu, 15 Jul 2004 20:21:23 +0900 (JST) Message-ID: <40F668B2.6080801@pacific.net.sg> Date: Thu, 15 Jul 2004 20:21:22 +0900 From: nkb User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Beginner question: can we use SASL over HTTP? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. I'm new to this list. Pardon me if this question is ignorant. I would like to access webpages (e.g. myhome.aspx) that require some form of authentication, s.a. the windows' NTLM authentication. I've written most of the application codes. I'm stuck at not being able to access pages that require authentication, specifically windows NTLM authentication. Before I spend too much time reading into SASL, I was wondering if this is the library that I could use to help me take care of this NTLM authentication to access webpages? Thank you for any pointers. From owner-ietf-sasl Thu Jul 15 10:22:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHMKi2077364; Thu, 15 Jul 2004 10:22:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FHMKph077363; Thu, 15 Jul 2004 10:22:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHMIQh077356 for ; Thu, 15 Jul 2004 10:22:19 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 15 Jul 2004 18:24:44 +0100 Message-ID: <40F6BD45.302@isode.com> Date: Thu, 15 Jul 2004 18:22:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nkb CC: ietf-sasl@imc.org Subject: Re: Beginner question: can we use SASL over HTTP? References: <40F668B2.6080801@pacific.net.sg> In-Reply-To: <40F668B2.6080801@pacific.net.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: nkb wrote: > Hi. > I'm new to this list. Pardon me if this question is ignorant. > > I would like to access webpages (e.g. myhome.aspx) that require some > form of authentication, s.a. the windows' NTLM authentication. I've > written most of the application codes. I'm stuck at not being able to > access pages that require authentication, specifically windows NTLM > authentication. Before I spend too much time reading into SASL, I was > wondering if this is the library that I could use to help me take care > of this NTLM authentication to access webpages? Thank you for any > pointers. The short answer is "no". A longer answer is: there is a draft that describes how to use SASL over HTTP, however it is not implemented by any known browser. If you have more questions on this, send me reply off the mailing list. Regards, Alexey From owner-ietf-sasl Thu Jul 15 11:31:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FIVYFN089623; Thu, 15 Jul 2004 11:31:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FIVYRr089622; Thu, 15 Jul 2004 11:31:34 -0700 (PDT) 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 i6FIVVfF089598 for ; Thu, 15 Jul 2004 11:31:31 -0700 (PDT) (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 i6FIVHJ6002650; Thu, 15 Jul 2004 11:31:17 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i6FIV18X024824; Thu, 15 Jul 2004 12:31:01 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i6FIS7ZJ646312; Thu, 15 Jul 2004 13:28:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i6FIS7qs646311; Thu, 15 Jul 2004 13:28:07 -0500 (CDT) Date: Thu, 15 Jul 2004 13:28:07 -0500 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040715182807.GZ632478@binky.central.sun.com> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jul 05, 2004 at 09:51:09AM +0200, Simon Josefsson wrote: > > There is a requirement that the GSS-API channel bindings are NULL. > I'd feel more comfortable if there was a way to somehow make use of > channel bindings, to link the authentication to the specific channel. > Does anyone have ideas on whether to add this, and if the answer is > positive, how it might be done? 1. Existing GSS-API mechanisms fail to correctly deal with channel bindings. E.g., SPKM is way underspaecified in general, and here specifically; also, the Kerberos V mechanism does not have a way for the acceptor to prove to the initiator that it too has the same channel bindings as the initiator. 2. We're trying to address this through a stackable pseudo-mechanism (CCM-BIND) one of whose purposes is to address this problem. See: draft-ietf-nfsv4-ccm-03.txt 3. The whole subject of channel bindings needs further specification. I'm about to submit a new version of draft-ietf-nfsv4-channel-bindings (-01.txt) that does this and which describes what goes into the channel bindings for SSHv2, TLS and IPsec channels, and then I'll submit draft-williams-gssapi-channel-bindings-00.txt for the KITTEN BoF (and, hopefully, WG), which fills in the details of how to use channel bindings to SSHv2, TLS and IPsec channels with the GSS-API. The deadline for filing new I-Ds has passed though, so this won't get posted to the I-D repository until after this meeting. 4. Given CCM-BIND and the two other drafts it should be possible to use SASL with GSS-API channel bindings; SASL APIs will have to be modified so the application can provide the necessary channel information. 5. I have proposed a set of interfaces for determining the features of GSS mechs, as part of a framework for stackable pseudo-mechanisms, which should help GSS apps avoid having to hardcode mechanism OIDs and information about them (e.g., "channel bindings work well with this mechanism, but not with that one"). See: draft-williams-gssapi-stackable-pseudo-mechs-00.txt As you can see, there's a lot of activity around this topic. > I understand that the simplest "solution", from the SASL mechanism > point of view, might simply be to consider GSS-API mechanisms, that > doesn't link gss_wrap/gss_get_mic tokens with one specific > authentication, as broken. However, channel bindings are provided by > GSS-API to enable applications to close this hole, hence these GSS-API > mechanisms can probably not be viewed as broken in general. So it is > unfortunate that the SASL wrapping of GSS-API forbid channel bindings. > I'd say this warrant a paragraph in the security section, unless the > text about channel bindings is loosened up. The SASL handling of GSS-API mechanisms does need some tweaking, both, in light of the above and to provide for re-keying (GSS-API contexts can expire, after all) by reestablishing GSS security contexts for the principals involved. Cheers, Nico -- From owner-ietf-sasl Fri Jul 16 06:42:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDgd5g067734; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GDgdrd067733; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDgcFw067726 for ; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 16 Jul 2004 14:44:48 +0100 Message-ID: <40F7DB35.4000502@isode.com> Date: Fri, 16 Jul 2004 14:42:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Lyndon Nerenberg CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: in CRAM-MD5 References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> In-Reply-To: <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote: > --On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" > wrote: > >>> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" >>> ; a bracketed string of printing characters, not >>> ; containing embedded "<" or ">" >>> >>> and modify the text to emphasize the importance of generating unique >>> challenges, making reference to the historical behaviour. >> >> Seems reasonable to me. > I am glad about this change, I've been advocating something similar before. Alexey From owner-ietf-sasl Tue Jul 20 17:01:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L01rNW005358; Tue, 20 Jul 2004 17:01:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L01rt8005357; Tue, 20 Jul 2004 17:01:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from PC_hipolito.com (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L01pt2005351 for ; Tue, 20 Jul 2004 17:01:52 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Tue, 20 Jul 2004 19:02:03 -0500 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------majkqzkcezrdrjmmzrse" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------majkqzkcezrdrjmmzrse Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Lovely animals


----------majkqzkcezrdrjmmzrse Content-Type: application/octet-stream; name="Dog.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Dog.scr" ----------majkqzkcezrdrjmmzrse-- From owner-ietf-sasl Wed Jul 21 05:43:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LCh28V078250; Wed, 21 Jul 2004 05:43:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LCh2NO078249; Wed, 21 Jul 2004 05:43:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from komp67.org (yn250.internetdsl.tpnet.pl [80.55.247.250]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6LCh0BR078234 for ; Wed, 21 Jul 2004 05:43:01 -0700 (PDT) (envelope-from jgmyers@netscape.com) Date: Wed, 21 Jul 2004 14:43:00 +0100 To: "Ietf-sasl" From: "Jgmyers" Subject: Protected message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ouyenmooiqtdcfbsrzwy" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------ouyenmooiqtdcfbsrzwy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached file tells everything.


----------ouyenmooiqtdcfbsrzwy Content-Type: application/octet-stream; name="text_document.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="text_document.scr" ----------ouyenmooiqtdcfbsrzwy-- From owner-ietf-sasl Wed Jul 21 09:38:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGcJmN002832; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LGcJPM002831; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-EIGHTY-TWO.MIT.EDU [18.187.6.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGcIm5002825 for ; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 96C90E0052; Wed, 21 Jul 2004 12:38:35 -0400 (EDT) To: ietf-sasl@imc.org Subject: GSSAPI direction Message-Id: <20040721163835.96C90E0052@cz.mit.edu> Date: Wed, 21 Jul 2004 12:38:35 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [This message and for the most part any of my participation in GSSAPI discussions are in the role of a participant not as a WG chair.] I'd like to start a discussion about what direction we want to take with the GSSAPI work. Our charter requires that the work needs to be based on the existing draft. We probably need to at least document the behavior of the GSSAPI (kerberos 5) sasl mechanism. However the current GSSAPI protocol seems to be fairly inefficient. It requires an extra round trip to negotiate the security layers; it does not piggyback this negotiation on the last token. The mechanism will not take advantage of the prot_ready flag to remove a half round trip. I think the GSSAPI sasl mechanism need to be as efficient as we can make them. There are two primary motivations for this. First, I'd like to see GSSAPI HTTP be reasonably fast. Second, I'd like to remove any excuses we can for designing SASL mechanisms instead of GSSAPI mechanisms. Redundancy in security protocols is undesirable. Note that if we do change the gssapi draft in an incompatible manner, we would need to change the prefix of the sasl mechanism names. Note also that changing the gssapi mechanism is more reasonable than the other mechanisms; so far the gssapi mechanism is only an internet draft. There is a description of GSSAPI in RFC 2222 but we're already going to end up being incompatible with that description for everything besides Kerberos. --Sam From owner-ietf-sasl Wed Jul 21 13:10:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LKA6e1022647; Wed, 21 Jul 2004 13:10:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LKA63s022646; Wed, 21 Jul 2004 13:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LKA5bO022640 for ; Wed, 21 Jul 2004 13:10:05 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i6LKAAv4010593 for ; Wed, 21 Jul 2004 20:10:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 21 Jul 2004 13:10:30 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] 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: [with correct Last Call close date --Kdz] This message initiates a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. If after completing your review you find no issues, please indicate so to the chairs. The Last Call period will close on Friday, 13 August 2004. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! Kurt Zeilenga, SASL WG co-chair From owner-ietf-sasl Wed Jul 21 13:08:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LK8KFV022485; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LK8KSS022484; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LK8KvT022473 for ; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i6LK8Lv4010578 for ; Wed, 21 Jul 2004 20:08:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040721130411.04e7dbb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 21 Jul 2004 13:08:42 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt 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: This message initiates a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. If after completing your review you find no issues, please indicate so to the chairs. The Last Call period will close on Friday, 13 September 2003. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! Kurt Zeilenga, SASL WG co-chair From owner-ietf-sasl Wed Jul 21 14:48:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LLmbGJ033471; Wed, 21 Jul 2004 14:48:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LLmbva033470; Wed, 21 Jul 2004 14:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LLmafn033464 for ; Wed, 21 Jul 2004 14:48:36 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6LLkS53000577 for ; Wed, 21 Jul 2004 15:46:28 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i6LLme8X018683 for ; Wed, 21 Jul 2004 15:48:40 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6LLkLRj005246; Wed, 21 Jul 2004 16:46:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6LLkLPc005245; Wed, 21 Jul 2004 16:46:21 -0500 (CDT) Date: Wed, 21 Jul 2004 16:46:21 -0500 From: Nicolas Williams To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040721214621.GX815@binky.central.sun.com> Mail-Followup-To: "Kurt D. Zeilenga" , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > This message initiates a SASL Working Group Last Call on the > document: > > Title: > Simple Authentication and Security Layer (SASL) > > Editor: > A. Melnikov > > Filename: draft-ietf-sasl-rfc2222bis-08.txt Your timing is convenient. I have recently come to realize that neither rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of security layers. Perhaps I'm missing something. It's also pretty clear to me that SASL mechanisms cannot re-key security layers without application involvement (at least if using any SASL APIs that require that the application use per-message/buffer security layer calls). Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely address this by mentioning multiple authentications and replacing old security layers with new ones, which is, almost, exactly how I would expect SASL apps to re-key (see below). I propose the following changes to rfc2222bis: - Explicitly state that there is no security layer re-keying facility. (Alternatively design such a facility and add it to rfc2222bis; I don't like this alternative myself, mostly because it would require updating all the SASL mechanisms to specify re-keying and because either way the application must be involved in the re-keying process, so this alternative buys us nothing.) If re-keying be done by re-authenticating and negotiating new security layers (as in section 6.3 of rfc2222bis) then presumably the authenticated identities should remain the same(!). - Add security considerations text about security layer expiration due to passage of time, use of cryptographic material, administrative policies (e.g., credentials expiration). Consider the text of draft-ietf-secsh-newmodes, for example; the details of layer expiration typically will vary by SASL mechanism, but the underlying rationales (e.g., defense against cryptanalysis) should hold across the board. - Add a requirement that SASL mechanisms provide indications of security layer expiration to applications. Security layer expiration should probably have advisory and mandatory modes (advisory primarily for applications that lack support for re-negotiating security layers). - Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, LDAP) specify how to replace old SASL security layers with new ones. - If section 6.3 was meant for any purpose other than re-keying then please clarify it. For example, if an application authenticates as one identity, then switches to another and re-authenticates, presumably it should not act (or be allowed to, by its peer) on behalf of the first identity while using the second security layer, at least for some mechanisms. Additionally, where IETF documents specify application protocol use of SASL it would be nice to have clarifications/extensions for re-negotiation of SASL security layers -- that is, re-keying. Cheers, Nico -- From owner-ietf-sasl Thu Jul 22 08:44:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFihdF027356; Thu, 22 Jul 2004 08:44:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MFihXU027355; Thu, 22 Jul 2004 08:44:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-EIGHTY-TWO.MIT.EDU [18.187.6.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFig6M027349 for ; Thu, 22 Jul 2004 08:44:42 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id CBEA6E0052; Thu, 22 Jul 2004 11:44:58 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> From: Sam Hartman Date: Thu, 22 Jul 2004 11:44:58 -0400 In-Reply-To: <20040721214621.GX815@binky.central.sun.com> (Nicolas Williams's message of "Wed, 21 Jul 2004 16:46:21 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> - Add security considerations text about security layer Nicolas> expiration due to passage of time, use of cryptographic Nicolas> material, administrative policies (e.g., credentials Nicolas> expiration). Nicolas> Consider the text of draft-ietf-secsh-newmodes, for Nicolas> example; the details of layer expiration typically will Nicolas> vary by SASL mechanism, but the underlying rationales Nicolas> (e.g., defense against cryptanalysis) should hold across Nicolas> the board. Nico has a point. The security ADs seem to care a fair bit about key reuse. Given that the issue has been brought up, I'd expect a discuss if we don't at least address it in security considerations. At a minimum we need to discuss the fact that security layers can exceed their key lifetimes and give guidance to application designers. --Sam From owner-ietf-sasl Thu Jul 22 12:50:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJoFXm047456; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MJoF1d047455; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJoEP4047447 for ; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21425; Thu, 22 Jul 2004 15:50:17 -0400 (EDT) Message-Id: <200407221950.PAA21425@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-10.txt Date: Thu, 22 Jul 2004 15:50:16 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-10.txt Pages : 7 Date : 2004-7-22 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-10.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-saslprep-10.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-saslprep-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Sun Jul 25 15:37:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PMbOap066831; Sun, 25 Jul 2004 15:37:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PMbOmD066830; Sun, 25 Jul 2004 15:37:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PMbM9l066823 for ; Sun, 25 Jul 2004 15:37:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust157.tnt103.lnd4.gbr.da.uu.net [213.116.54.157]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 25 Jul 2004 23:38:11 +0100 Message-ID: <4104263B.2000707@isode.com> Date: Sun, 25 Jul 2004 22:29:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: GSSAPI direction References: <20040721163835.96C90E0052@cz.mit.edu> In-Reply-To: <20040721163835.96C90E0052@cz.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: >[This message and for the most part any of my participation in GSSAPI >discussions are in the role of a participant not as a WG chair.] > >I'd like to start a discussion about what direction we want to take >with the GSSAPI work. Our charter requires that the work needs to be >based on the existing draft. We probably need to at least document >the behavior of the GSSAPI (kerberos 5) sasl mechanism. > > I agree. >However the current GSSAPI protocol seems to be fairly inefficient. >It requires an extra round trip to negotiate the security layers; it >does not piggyback this negotiation on the last token. The mechanism >will not take advantage of the prot_ready flag to remove a half round >trip. > >I think the GSSAPI sasl mechanism need to be as efficient as we can >make them. There are two primary motivations for this. First, I'd >like to see GSSAPI HTTP be reasonably fast. Second, I'd like to >remove any excuses we can for designing SASL mechanisms instead of >GSSAPI mechanisms. Redundancy in security protocols is undesirable. > >Note that if we do change the gssapi draft in an incompatible manner, > > I don't mind the changes you are proposing (at least I agree with their motivation), however this suggestion is a bit late and I would like to point out that there several independent implementations of GSSAPI (Kerberos) mechanism that interoperate well (at least better than DIGEST-MD5). I am afraid that it is not possible to reduce existing 2 round trips in a backward compatible manner. I would be glad if you can prove me wrong. So, if the WG wants to tackle the issue that you've described above, I would suggest that the WG publishes the existing GSSAPI draft as GSSAPI Kerberos-only and designs a new GSSAPIv2 (which works for all GSSAPI mechanisms) in a separate draft. >we would need to change the prefix of the sasl mechanism names. Note >also that changing the gssapi mechanism is more reasonable than the >other mechanisms; so far the gssapi mechanism is only an internet >draft. There is a description of GSSAPI in RFC 2222 but we're already >going to end up being incompatible with that description for >everything besides Kerberos. > Alexey From owner-ietf-sasl Mon Jul 26 01:24:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q8OPPh072340; Mon, 26 Jul 2004 01:24:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q8OPF2072339; Mon, 26 Jul 2004 01:24:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (illegal-drugs.naming-schemes.org [67.65.18.113]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q8OOnk072328 for ; Mon, 26 Jul 2004 01:24:24 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 2FD7DE004C; Mon, 26 Jul 2004 04:24:28 -0400 (EDT) To: ietf-sasl@imc.org Subject: [Sam Hartman] Agenda for SASL at IETF 60 From: Sam Hartman Date: Mon, 26 Jul 2004 04:24:28 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-=-= I'm sorry this hasn't been reviewed here. Kurt, Alexey and I were discussing a proposed agenda and I realized that later today is the deadline for submitting the agenda. Naturally if the consensus of the working group is that we need to discuss something else, we will do so. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 26 Jul 2004 04:22:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by suchdamage.org (Postfix) with ESMTP id 25C0313230 for ; Mon, 26 Jul 2004 04:22:42 -0400 (EDT) Received: from cz.mit.edu (illegal-drugs.naming-schemes.org [67.65.18.113]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i6Q8MagH014036 for ; Mon, 26 Jul 2004 04:22:37 -0400 (EDT) Received: by cz.mit.edu (Postfix, from userid 8042) id 054BFE004C; Mon, 26 Jul 2004 04:22:40 -0400 (EDT) To: kurt@openldap.org, hartmans@mit.edu, agenda@ietf.org Subject: Agenda for SASL at IETF 60 Message-Id: <20040726082240.054BFE004C@cz.mit.edu> Date: Mon, 26 Jul 2004 04:22:40 -0400 (EDT) From: hartmans@MIT.EDU (Sam Hartman) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: MIME-Version: 1.0 Simple AUthentication and Security Layer (SASL) Tuesday, AUgust 3, 2004 1300-1400 =============================================== Agenda: Introductions and Agenda Bashing - chairs (5 minutes) Review of SASL Base last call - Chairs/Alexey (10 minutes) Digest md5 (draft--ietf-sasl-rfc2831bis) - Alexey (15 minutes) GSSAPI (draft-ietf-sasl-gssapi) - Alexey (15 minutes) Cram-md5 (draft-ietf-sasl-crammd5) - (15 minutes) Open mic - (remaining time) --=-=-=-- From owner-ietf-sasl Tue Jul 27 07:42:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REgf3C049825; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6REgfEA049824; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REgfq1049818 for ; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i6REgfCB018968 for ; Tue, 27 Jul 2004 07:42:41 -0700 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i6REged28712 for ; Tue, 27 Jul 2004 07:42:40 -0700 (PDT) Message-Id: <200407271442.i6REged28712@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Liberty SASL-based Authn over SOAP To: ietf-sasl@imc.org From: Jeff.Hodges@KingsMountain.com Reply-to: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jul 2004 07:42:40 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Of possible interest... Liberty ID-WSF Authentication Service Specification http://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.0.pdf Abstract: This specification defines an ID-WSF Authentication Protocol based on a profile of the Simple Authentication and Security Layer (SASL) framework mapped onto ID-* SOAP-bound messages. Next, it defines an ID-WSF Authentication Service Identity Providers may offer, which is based on the authentication protocol. This authentication service enables Web Services Consumers and/or Liberty-enabled User Agents or Devices to authenticate with Identity Providers using various authentication mechanisms and obtain ID-WSF security tokens. Finally, it defines an ID-WSF Single Sign-On Service. This service provides authentication assertions to Web Service Consumers via a profile of the ID-FF Single Sign-On Protocol, enabling Web Service Consumers to interact with ID-FF-based Service Providers. [ID-WSF = "Identity Web Services Framework" ID-FF = "Identity Federation Framework"] Likely helpful... Liberty Glossary, Version 1.3 http://www.projectliberty.org/specs/liberty-glossary-v1.3.pdf Thanks to Alexey for his review in the process of writing this spec. Other specs that the ID-WSF Authn Svc spec depends upon, or is related to (e.g. ID-FF specs) are available at [1]. If folks have any questions about these specs, or Liberty, feel free to drop me a line. thanks, JeffH [1] Liberty Alliance Project - Spec repository http://www.projectliberty.org/specs/ From owner-ietf-sasl Tue Jul 27 07:49:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REnsVl051395; Tue, 27 Jul 2004 07:49:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6REns94051394; Tue, 27 Jul 2004 07:49:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REnrVb051387 for ; Tue, 27 Jul 2004 07:49:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 27 Jul 2004 15:53:20 +0100 Message-ID: <41066B90.9030203@isode.com> Date: Tue, 27 Jul 2004 15:49:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> In-Reply-To: <20040721214621.GX815@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams wrote: >On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > > >>This message initiates a SASL Working Group Last Call on the >>document: >> >>Title: >>Simple Authentication and Security Layer (SASL) >> >>Editor: >>A. Melnikov >> >>Filename: draft-ietf-sasl-rfc2222bis-08.txt >> > >Your timing is convenient. I have recently come to realize that neither >rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of >security layers. Perhaps I'm missing something. > >It's also pretty clear to me that SASL mechanisms cannot re-key security >layers without application involvement (at least if using any SASL APIs >that require that the application use per-message/buffer security layer >calls). > As a developer, I am not sure I agree. At least I can imagine how this can be done automatically. >Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely >address this by mentioning multiple authentications and replacing old >security layers with new ones, which is, almost, exactly how I would >expect SASL apps to re-key (see below). > No, reauthentication is not the same as re-keying. The client may choose to reauthenticate as a different user, for example if the client is some kind of a proxy. >I propose the following changes to rfc2222bis: > > - Explicitly state that there is no security layer re-keying facility. > Yes. But I would like to add instead that "there is no generic security layer re-keying facility", as each SASL mechanism that support a security layer is free to implement own re-keying. > (Alternatively design such a facility and add it to rfc2222bis; I > don't like this alternative myself, mostly because it would require > updating all the SASL mechanisms to specify re-keying and because > either way the application must be involved in the re-keying process, > so this alternative buys us nothing.) > I don't like this either, for the same reasons. > > If re-keying be done by re-authenticating and negotiating new > security layers (as in section 6.3 of rfc2222bis) then presumably the > authenticated identities should remain the same(!). > > - Add security considerations text about security layer expiration due > to passage of time, use of cryptographic material, administrative > policies (e.g., credentials expiration). > > Consider the text of draft-ietf-secsh-newmodes, for example; the > details of layer expiration typically will vary by SASL mechanism, > but the underlying rationales (e.g., defense against cryptanalysis) > should hold across the board. > I would appreciate if you can send some text to me. > > - Add a requirement that SASL mechanisms provide indications of > security layer expiration to applications. > We can't make this a requirement, as support for a security layer is an optional feature of SASL framework. But we can make this as a recommendation. >Security layer expiration > should probably have advisory and mandatory modes (advisory primarily > for applications that lack support for re-negotiating security > layers). > > - Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, > LDAP) specify how to replace old SASL security layers with new ones. > This wouldn't be possible, as not all protocols support reauthentication. > - If section 6.3 was meant for any purpose other than re-keying then > please clarify it. For example, if an application authenticates as > one identity, then switches to another and re-authenticates, > Yes. > presumably it should not act (or be allowed to, by its peer) on > behalf of the first identity while using the second security layer, > at least for some mechanisms. > > Can you suggest some text? >Additionally, where IETF documents specify application protocol use of >SASL it would be nice to have clarifications/extensions for >re-negotiation of SASL security layers -- that is, re-keying. > >Cheers, > >Nico > > From owner-ietf-sasl Tue Jul 27 08:31:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFVXGK061138; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RFVXlX061137; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) 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 i6RFVXmp061126 for ; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) (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 i6RFVSJ6017706 for ; Tue, 27 Jul 2004 08:31:28 -0700 (PDT) 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 i6RFVS4F017836 for ; Tue, 27 Jul 2004 09:31:28 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RFT26U025319; Tue, 27 Jul 2004 10:29:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RFT1RL025318; Tue, 27 Jul 2004 10:29:01 -0500 (CDT) Date: Tue, 27 Jul 2004 10:29:01 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040727152901.GQ815@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> <41066B90.9030203@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41066B90.9030203@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 03:49:52PM +0100, Alexey Melnikov wrote: > Nicolas Williams wrote: > > >On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > > > > > >>This message initiates a SASL Working Group Last Call on the > >>document: > >> > >>Title: > >>Simple Authentication and Security Layer (SASL) > >> > >>Editor: > >>A. Melnikov > >> > >>Filename: draft-ietf-sasl-rfc2222bis-08.txt > >> > > > >Your timing is convenient. I have recently come to realize that neither > >rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of > >security layers. Perhaps I'm missing something. > > > >It's also pretty clear to me that SASL mechanisms cannot re-key security > >layers without application involvement (at least if using any SASL APIs > >that require that the application use per-message/buffer security layer > >calls). > > > As a developer, I am not sure I agree. At least I can imagine how this > can be done automatically. What do you not agree with? The case described in the parenthetical expression above cannot have automatic re-keying without changing the existing APIs. We've been over this, with respect to the GSS-API, at either the old CAT WG list or at the KRB WG list a year or two ago. > >Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely > >address this by mentioning multiple authentications and replacing old > >security layers with new ones, which is, almost, exactly how I would > >expect SASL apps to re-key (see below). > > > No, reauthentication is not the same as re-keying. The client may choose > to reauthenticate as a different user, for example if the client is some > kind of a proxy. RFC2222 and rfc222bis are mighty clear that re-authentication that negotiates new security layers leads to replacement of the old layers with the new ones. Re-authenticate the same identities while negotiating new layers and you've got re-keying. IPsec w/ IKEv1 handles re-keying by establishing brand new SAs (for the same IDs). ONC RPC w/ RPCSEC_GSS (and, therefore, NFS) handles re-keying the same way, namely, by establishing new GSS-API security contexts (for the same names). (This is actually very implicit, rather than explicit, in the RPCSEC_GSS spec; what happens is that a GSS sec. context is needed only for the life of an actual RPC, but RPC apps, like NFS, typically make many RPCs and authorize peers on each call by inspecting the peer's GSS name. Today I would want the spec to be explicit about re-keying. This is, in fact, my attitude to SASL and re-keying.) IPsec w/ IKEv2 can re-key IKE_SAs during their lifetime, but if those expire it reverts to IPsec w/ IKEv1 re-keying behaviour. SSHv2 supports true re-keying, rather than re-keying by re-authentication. But if you use the GSS-API-protected SSHv2 key exchange to re-key SSHv2 connections then you also re-authenticate. I think there's a well established tradition of re-keying by re-authenticating the same identities where possible. > >I propose the following changes to rfc2222bis: > > > >- Explicitly state that there is no security layer re-keying facility. > > > Yes. But I would like to add instead that "there is no generic security > layer re-keying facility", as each SASL mechanism that support a > security layer is free to implement own re-keying. See my note above; some SASL APIs will require changes to support re-keying with such mechanisms. I'm pretty sure that the Cyrus SASL API would, for example. And existing SASL mechanisms do not support re-keying, leaving us with re-keying-by-re-authenticating as the only simple alternative, an alternative for which there is a fine tradition. > >- Add security considerations text about security layer expiration due > > to passage of time, use of cryptographic material, administrative > > policies (e.g., credentials expiration). > > > > Consider the text of draft-ietf-secsh-newmodes, for example; the > > details of layer expiration typically will vary by SASL mechanism, > > but the underlying rationales (e.g., defense against cryptanalysis) > > should hold across the board. > > > I would appreciate if you can send some text to me. Generic text for rfc2222bis? I can do that. > > > >- Add a requirement that SASL mechanisms provide indications of > > security layer expiration to applications. > > > We can't make this a requirement, as support for a security layer is an > optional feature of SASL framework. > But we can make this as a recommendation. Nonsense. You can make this mandatory, for new and revised mechanisms, where security layer support is available. The SASL GSS mechanisms can provide this today, since the GSS-API provides for context expiration. And note that infinite and, possibly, unspecified security layer lifetimes should be legitimate values for security layer expiration. > >Security layer expiration > > should probably have advisory and mandatory modes (advisory primarily > > for applications that lack support for re-negotiating security > > layers). > > > >- Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, > > LDAP) specify how to replace old SASL security layers with new ones. > > > This wouldn't be possible, as not all protocols support reauthentication. But new ones could. It's not at all clear to me that SMTP/SUBMIT don't support re-authentication, for example. I'm not sure whether this WG can clarify that, but it can clarify that _new_ application protocols that use SASL must support re-authentication, and thus re-keying. We can go back and update the application protocol specs where lack of re-authentication/re-keying hurts -- later. First we need rfc2222bis to say something about the matter. > >- If section 6.3 was meant for any purpose other than re-keying then > > please clarify it. For example, if an application authenticates as > > one identity, then switches to another and re-authenticates, > > > Yes. > > > presumably it should not act (or be allowed to, by its peer) on > > behalf of the first identity while using the second security layer, > > at least for some mechanisms. > > > > > Can you suggest some text? No, I cannot. This WG should discuss and come up with this clarification. I can send you text on re-keying, but perhaps we should see where the WG looks to be heading on that matter. Cheers, Nico -- From owner-ietf-sasl Tue Jul 27 08:51:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFpIGJ065417; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RFpI1d065415; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFpI7G065394 for ; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) (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 i6RFpG0R014432 for ; Tue, 27 Jul 2004 08:51:16 -0700 (PDT) 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 i6RFpC4F009355 for ; Tue, 27 Jul 2004 09:51:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RFmlTM025329; Tue, 27 Jul 2004 10:48:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RFmkRW025328; Tue, 27 Jul 2004 10:48:46 -0500 (CDT) Date: Tue, 27 Jul 2004 10:48:46 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040727154846.GM826@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> <41066B90.9030203@isode.com> <20040727152901.GQ815@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040727152901.GQ815@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 10:29:01AM -0500, Nicolas Williams wrote: > But new ones could. It's not at all clear to me that SMTP/SUBMIT don't > support re-authentication, for example. I'm not sure whether this WG > can clarify that, but it can clarify that _new_ application protocols > that use SASL must support re-authentication, and thus re-keying. Actually, rfc2554 is quite clear that it is not possible to re-authenticate in the SMTP/SUBMIT protocols. This is unfortunate. Nico -- From owner-ietf-sasl Tue Jul 27 11:22:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIMfdS099614; Tue, 27 Jul 2004 11:22:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RIMfJJ099613; Tue, 27 Jul 2004 11:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIMdc9099554 for ; Tue, 27 Jul 2004 11:22:40 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i6RIMNs9003667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jul 2004 14:22:26 -0400 (EDT) Message-ID: <41069D5E.9010403@columbia.edu> Date: Tue, 27 Jul 2004 14:22:22 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: Kerberos WG , SASL WG , security-wg@ggf.org, nfsv4@ietf.org, saag@mit.edu Subject: Kitten (Common Authentication Technologies - Next Generation) at IETF 60 X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Common Authentication Technologies Next Generation (Kitten) BOF will be meeting at IETF 60: 1530-1730 Afternoon Sessions II Grande B SEC kitten Kitten (Daughter of CAT) BOF The agenda of the meeting is as follows: _ Kitten BOF Agenda for IETF 60_ * Introduction and Welcome [5 minutes] - Jeffrey Altman * Discussion of the Global Grid Forum GSS requirements [15 minutes] - Doug Engert * Discussion of channel bindings portability issues (C struct et all) [10 minutes] - Sam Hartman * Discussion of GSSAPI naming [15 minutes] - Sam Hartman * Discussion of need for cryptographic channel bindings and CCM [10 minutes] - Nicolas Williams * Discussion of Stackable Psuedo Mechanisms [10 minutes] - Nicolas Williams * Discussion of the SPNEGO issues [10 minutes] - Wyllys Ingersol * Discussion of the C# Bindings for GSSAPI [10 minutes] - Microsoft * Charter discussion [15 minutes] - Jeffrey Altman An introduction to the purpose of the Kitten Working Group and a proposed charter may be found at: http://www.ietf.org/ietf/04aug/kitten.txt We encourage anyone interested in the future of GSSAPI (applications which use GSSAPI or mechanisms implementing GSSAPI); those concerned with authenticated name portability; and those participating in the Cryptographic Channel Bindings work to attend this BOF and participate in the discussions. For the most part the Kitten participants have identified problem areas; have presented some potential incomplete solutions; and there is much work to be done. I hope to see you there. Jeffrey Altman From owner-ietf-sasl Tue Jul 27 11:54:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIsDWT007299; Tue, 27 Jul 2004 11:54:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RIsDAo007298; Tue, 27 Jul 2004 11:54:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIs594007257 for ; Tue, 27 Jul 2004 11:54:10 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BpX5Q-0004Am-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: GSS-API channel bindings Date: Tue, 27 Jul 2004 20:54:01 +0200 Lines: 42 Message-ID: References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:8lfckb0bwOCEgjYbavs0poCWWNE= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: ... > As you can see, there's a lot of activity around this topic. Thanks for this useful overview of activities. >> I understand that the simplest "solution", from the SASL mechanism >> point of view, might simply be to consider GSS-API mechanisms, that >> doesn't link gss_wrap/gss_get_mic tokens with one specific >> authentication, as broken. However, channel bindings are provided by >> GSS-API to enable applications to close this hole, hence these GSS-API >> mechanisms can probably not be viewed as broken in general. So it is >> unfortunate that the SASL wrapping of GSS-API forbid channel bindings. >> I'd say this warrant a paragraph in the security section, unless the >> text about channel bindings is loosened up. > > The SASL handling of GSS-API mechanisms does need some tweaking, both, > in light of the above and to provide for re-keying (GSS-API contexts can > expire, after all) by reestablishing GSS security contexts for the > principals involved. Do you have any thoughts on how to modify the SASL GSSAPI mechanism so it is possible for it to use non-NULL channel bindings automatically? The most simplistic solution is to permit non-NULL channel bindings in the specification, and leave everything up to application protocols. However, that approach require application protocol implementations to tell the SASL library what GSSAPI channel bindings it wants. While this is feasible, perhaps it can be made even better. What I'm trying to understand, is whether the SASL GSSAPI mechanism, by itself, could construct the actual channel binding, and use it at both ends. (Some application might want to provide the channel binding data themselves, so the above should only be a possible default behaviour, in order to bind SASL GSSAPI authentication to a specific channel.) Regards, Simon From owner-ietf-sasl Tue Jul 27 13:23:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RKN0YI028938; Tue, 27 Jul 2004 13:23:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RKN0kB028937; Tue, 27 Jul 2004 13:23:00 -0700 (PDT) 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 i6RKMvnU028909 for ; Tue, 27 Jul 2004 13:22:57 -0700 (PDT) (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 i6RKMuJ6025774 for ; Tue, 27 Jul 2004 13:22:56 -0700 (PDT) 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 i6RKMt4H002427 for ; Tue, 27 Jul 2004 14:22:56 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RKKTSW025770; Tue, 27 Jul 2004 15:20:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RKKSIY025769; Tue, 27 Jul 2004 15:20:28 -0500 (CDT) Date: Tue, 27 Jul 2004 15:20:28 -0500 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040727202028.GW815@binky.central.sun.com> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 08:54:01PM +0200, Simon Josefsson wrote: > > Nicolas Williams writes: > > ... > > As you can see, there's a lot of activity around this topic. > > Thanks for this useful overview of activities. NP. [...] > > The SASL handling of GSS-API mechanisms does need some tweaking, both, > > in light of the above and to provide for re-keying (GSS-API contexts can > > expire, after all) by reestablishing GSS security contexts for the > > principals involved. > > Do you have any thoughts on how to modify the SASL GSSAPI mechanism so > it is possible for it to use non-NULL channel bindings automatically? See the CCM I-D in the NFSv4 WG and my personal I-D on stackable GSS pseudo-mechanisms, which is due to be a WG I-D for KITTEN, if the KITTEN BoF (which will meet this Monday) succeeds. The short answer is that by negotiating the use of CCM-BIND apps also negotiate the use of channel bindings. CCM-BIND is a stackable pseudo-mechanism which is primarily intended for these two purposes: - properly implement channel bindings the (the krb5 and spkm mechs don't) - indicate, in mechanism negotiations, the willingness to use channe bindings Applications shouldn't offer or accept CCM mechanisms in their negotiations if they have no useful channel to bind to. The flip side is that apps SHOULD offer and/or accept CCM mechanisms in their negotiations if they do have such channels and bindings and want to use channel bindings. > The most simplistic solution is to permit non-NULL channel bindings in > the specification, and leave everything up to application protocols. See above. This could work, but, the incomplete channel bindings support in the Kerberos V and SPKM GSS mechanisms, and the additional complexity for application protocols argues for the approach I offer instead, namely to leverage existing mechanism negotiations in application protocols to negotiate the use of channel bindings by using mechanism OIDs which indicate the desire to do so. > However, that approach require application protocol implementations to > tell the SASL library what GSSAPI channel bindings it wants. While > this is feasible, perhaps it can be made even better. And requires changes to the application protocol to properly negotiate the use of channel bindings. The approach I offer does not. > What I'm trying to understand, is whether the SASL GSSAPI mechanism, > by itself, could construct the actual channel binding, and use it at > both ends. No, it cannot, but I have an I-D, which did not make the cutoff for new I-Ds which specifies channel bindings constructor interfaces that make this task easy for application developers. > (Some application might want to provide the channel binding data > themselves, so the above should only be a possible default behaviour, > in order to bind SASL GSSAPI authentication to a specific channel.) Of course. Nico -- From owner-ietf-sasl Thu Jul 29 12:21:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJLBvX090828; Thu, 29 Jul 2004 12:21:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJLBwa090827; Thu, 29 Jul 2004 12:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJL7NE090803 for ; Thu, 29 Jul 2004 12:21:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 29 Jul 2004 20:24:41 +0100 Message-ID: <41094E1C.2050404@isode.com> Date: Thu, 29 Jul 2004 20:21:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: >Do you have any thoughts on how to modify the SASL GSSAPI mechanism so >it is possible for it to use non-NULL channel bindings automatically? > >The most simplistic solution is to permit non-NULL channel bindings in >the specification, and leave everything up to application protocols. > >However, that approach require application protocol implementations to >tell the SASL library what GSSAPI channel bindings it wants. While >this is feasible, perhaps it can be made even better. > >What I'm trying to understand, is whether the SASL GSSAPI mechanism, >by itself, could construct the actual channel binding, and use it at >both ends. > CMU SASL API allows applications to pass IP/port number of the both endpoints to the SASL library. It seems that this is sufficient to construct proper channel binding information? (Just thinking aloud). Also, if either the client or the server end uses non null channel binding and the other end doesn't, will they be able to authenticate? >(Some application might want to provide the channel binding data >themselves, so the above should only be a possible default behaviour, >in order to bind SASL GSSAPI authentication to a specific channel.) > > > > From owner-ietf-sasl Thu Jul 29 12:59:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJx2Ws097435; Thu, 29 Jul 2004 12:59:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJx2Jb097434; Thu, 29 Jul 2004 12:59:02 -0700 (PDT) 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 i6TJx19A097400 for ; Thu, 29 Jul 2004 12:59:01 -0700 (PDT) (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 i6TJx0J6011506 for ; Thu, 29 Jul 2004 12:59:00 -0700 (PDT) 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 i6TJwx4H008836 for ; Thu, 29 Jul 2004 13:59:00 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6TJuWFF003373; Thu, 29 Jul 2004 14:56:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6TJuWQ7003372; Thu, 29 Jul 2004 14:56:32 -0500 (CDT) Date: Thu, 29 Jul 2004 14:56:32 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040729195632.GB896@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> <41094E1C.2050404@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41094E1C.2050404@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jul 29, 2004 at 08:21:00PM +0100, Alexey Melnikov wrote: > > Simon Josefsson wrote: > > >Do you have any thoughts on how to modify the SASL GSSAPI mechanism so > >it is possible for it to use non-NULL channel bindings automatically? > > > >The most simplistic solution is to permit non-NULL channel bindings in > >the specification, and leave everything up to application protocols. > > > >However, that approach require application protocol implementations to > >tell the SASL library what GSSAPI channel bindings it wants. While > >this is feasible, perhaps it can be made even better. > > > >What I'm trying to understand, is whether the SASL GSSAPI mechanism, > >by itself, could construct the actual channel binding, and use it at > >both ends. > > > CMU SASL API allows applications to pass IP/port number of the both > endpoints to the SASL library. It seems that this is sufficient to > construct proper channel binding information? (Just thinking aloud). No, it's not enough because there's no cryptographic binding there, direct or indirect. Throw in authenticated and "latched" IPsec IDs and you've got strong bindings. Or, if you're running over a TLS channel, throw in the TLS finished messages. Or, if you're running over an SSHv2 channel, throw in the SSHv2 session ID. > Also, if either the client or the server end uses non null channel > binding and the other end doesn't, will they be able to authenticate? With the GSS-API? Technically they shouldn't, though the krb5 mech has some warts in this area (I won't describe them here). The point is: GSS-API channel bindings are not negotiated by the GSS mechanisms, so both peers must know a priori that both have or don't have channel bindings. Thus my comments earlier about CCM-BIND and negotiation of the use of GSS mechanisms specifically designed to signal and implement the use of channel bindings. Please see draft-ietf-nfsv4-channel-bindings-02.txt. Nico -- From owner-ietf-sasl Mon Jul 5 00:51:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i657pPp3060777; Mon, 5 Jul 2004 00:51:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i657pP1W060776; Mon, 5 Jul 2004 00:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i657pKhs060747 for ; Mon, 5 Jul 2004 00:51:21 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BhOFt-0006W7-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: GSS-API channel bindings Date: Mon, 05 Jul 2004 09:51:09 +0200 Lines: 18 Message-ID: References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:K389zgfsMv5NEvcQ6x6g6U/wlfk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is a requirement that the GSS-API channel bindings are NULL. I'd feel more comfortable if there was a way to somehow make use of channel bindings, to link the authentication to the specific channel. Does anyone have ideas on whether to add this, and if the answer is positive, how it might be done? I understand that the simplest "solution", from the SASL mechanism point of view, might simply be to consider GSS-API mechanisms, that doesn't link gss_wrap/gss_get_mic tokens with one specific authentication, as broken. However, channel bindings are provided by GSS-API to enable applications to close this hole, hence these GSS-API mechanisms can probably not be viewed as broken in general. So it is unfortunate that the SASL wrapping of GSS-API forbid channel bindings. I'd say this warrant a paragraph in the security section, unless the text about channel bindings is loosened up. Thanks, Simon From owner-ietf-sasl Wed Jul 7 14:29:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LTc9K061819; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67LTcOh061818; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LTbqF061812 for ; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 269B5E0051; Wed, 7 Jul 2004 17:29:40 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Final changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <40D7666B.7070001@isode.com> From: Sam Hartman Date: Wed, 07 Jul 2004 17:29:40 -0400 In-Reply-To: <40D7666B.7070001@isode.com> (Alexey Melnikov's message of "Mon, 21 Jun 2004 23:51:23 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Rob Siemborski wrote: >> On Fri, 21 May 2004, Sam Hartman wrote: >>> >> It seems we can handle this cleanly enough if we treat it >>> just >> like the initial response. >>> >>> But is it worth the complexity? IT seems that if we can avoid >>> the introduction of distinguishing the two cases we should do >>> so. >>> >>> >> If it is not worth the complexity (and, really, I can't think >> of any situation where an empty server success data would be >> *useful*-- it just seems that we'd be giving up some level of >> flexibility), then we should just forbid empty success data -- >> this would lead to the less confusion than attributing two >> potential meanings to "no success data". >> >> Alexey> Should I treat "forbid empty success data" as the WG Alexey> consensus on empty versa no data on success? I think so. From owner-ietf-sasl Thu Jul 8 18:40:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691eg2X004846; Thu, 8 Jul 2004 18:40:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i691egn5004845; Thu, 8 Jul 2004 18:40:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691ef2g004838 for ; Thu, 8 Jul 2004 18:40:41 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i691ed9O029629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2004 19:40:42 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 08 Jul 2004 18:40:33 -0700 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: in CRAM-MD5 Message-ID: <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> In-Reply-To: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" wrote: > Why isn't RFC-822 msg-id production here as was done in RFC 2195? > The production below is quite different than a msg-id (in some > ways more restrictive and in other ways less restrictive). > > For compatibility with existing RFC 2195, I think this specification > should simple incorporate (directly or by reference) the msg-id > production previously used. There is a problem here. RFC2822 states: msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] If we reference 822 for , people are going to assume the 2822 definition replaces it. Suddenly we have these [CFWS] tokens muddying things up. The format for the challenge reflects directly on CRAM's birth in an email environment. Since email software already had to deal with generating unique message ids, re-using that code as a source for unique strings made sense at the time. But the important property of the challenge is that it be unique, not that it syntactically resemble a element. So relaxing the formatting requirement to simplify the grammar should be fine, provided the new production does not syntactically invalidate existing implementations. Therefore, I'm proposing that we change the syntax of the challenge to: challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" ; a bracketed string of printing characters, not ; containing embedded "<" or ">" and modify the text to emphasize the importance of generating unique challenges, making reference to the historical behaviour. --lyndon From owner-ietf-sasl Fri Jul 9 12:24:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JOtZ4099646; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69JOt26099645; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JOt4n099635 for ; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i69JOvv4016853; Fri, 9 Jul 2004 19:24:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Jul 2004 12:25:04 -0700 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: in CRAM-MD5 Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:40 PM 7/8/2004, Lyndon Nerenberg wrote: >--On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" wrote: > >>Why isn't RFC-822 msg-id production here as was done in RFC 2195? >>The production below is quite different than a msg-id (in some >>ways more restrictive and in other ways less restrictive). >> >>For compatibility with existing RFC 2195, I think this specification >>should simple incorporate (directly or by reference) the msg-id >>production previously used. > >There is a problem here. RFC2822 states: > > msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] > >If we reference 822 for , people are going to assume the 2822 definition replaces it. Suddenly we have these [CFWS] tokens muddying things up. > >The format for the challenge reflects directly on CRAM's birth in an email environment. Since email software already had to deal with generating unique message ids, re-using that code as a source for unique strings made sense at the time. But the important property of the challenge is that it be unique, not that it syntactically resemble a element. So relaxing the formatting requirement to simplify the grammar should be fine, provided the new production does not syntactically invalidate existing implementations. Therefore, I'm proposing that we change the syntax of the challenge to: > > challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" > ; a bracketed string of printing characters, not > ; containing embedded "<" or ">" > >and modify the text to emphasize the importance of generating unique challenges, making reference to the historical behaviour. Seems reasonable to me. Kurt From owner-ietf-sasl Fri Jul 9 14:13:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LDF3F008303; Fri, 9 Jul 2004 14:13:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69LDFw7008302; Fri, 9 Jul 2004 14:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LD5JF008290 for ; Fri, 9 Jul 2004 14:13:14 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i69LD59O034589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2004 15:13:07 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 09 Jul 2004 14:13:00 -0700 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: in CRAM-MD5 Message-ID: <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> In-Reply-To: <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" wrote: >> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" >> ; a bracketed string of printing characters, not >> ; containing embedded "<" or ">" >> >> and modify the text to emphasize the importance of generating unique >> challenges, making reference to the historical behaviour. > > Seems reasonable to me. Excellent. I've sent version -03 of the draft off for publication. The major changes from -02 are: - reformatted and edited to put it into the style the RFC Editor prefers; - mods as described (explanitory text still to come); - new and updated examples from Simon. It would be useful if someone could contribute an ACAP example (or some other non-IMAP example, and which doesn't base64 encode parts of the exchange); - addressed *most* of Kurt's review comments from his March 10 message to the list. Still to be done: - Changes from RFC2195; - the Abstract and Introduction still need work; - text rational for : uniqueness property and historical behaviour (and probably a short paragraph under Security Considerations). --lyndon From owner-ietf-sasl Mon Jul 12 12:38:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CJc7MW058213; Mon, 12 Jul 2004 12:38:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CJc7x8058212; Mon, 12 Jul 2004 12:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CJc55C058198 for ; Mon, 12 Jul 2004 12:38:06 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05044; Mon, 12 Jul 2004 15:38:07 -0400 (EDT) Message-Id: <200407121938.PAA05044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-03.txt Date: Mon, 12 Jul 2004 15:38:07 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-03.txt Pages : 9 Date : 2004-7-12 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-12143512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-12143512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Jul 15 04:21:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FBLOrN016817; Thu, 15 Jul 2004 04:21:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FBLOiL016816; Thu, 15 Jul 2004 04:21:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.gold.ocn.ne.jp (gold.ocn.ne.jp [222.146.40.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FBLM1b016810 for ; Thu, 15 Jul 2004 04:21:23 -0700 (PDT) (envelope-from nkb@pacific.net.sg) Received: from [10.1.5.20] (pat.polyphony.co.jp [210.254.79.2]) by smtp.gold.ocn.ne.jp (Postfix) with ESMTP id 0A6952AB for ; Thu, 15 Jul 2004 20:21:23 +0900 (JST) Message-ID: <40F668B2.6080801@pacific.net.sg> Date: Thu, 15 Jul 2004 20:21:22 +0900 From: nkb User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Beginner question: can we use SASL over HTTP? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. I'm new to this list. Pardon me if this question is ignorant. I would like to access webpages (e.g. myhome.aspx) that require some form of authentication, s.a. the windows' NTLM authentication. I've written most of the application codes. I'm stuck at not being able to access pages that require authentication, specifically windows NTLM authentication. Before I spend too much time reading into SASL, I was wondering if this is the library that I could use to help me take care of this NTLM authentication to access webpages? Thank you for any pointers. From owner-ietf-sasl Thu Jul 15 10:22:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHMKi2077364; Thu, 15 Jul 2004 10:22:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FHMKph077363; Thu, 15 Jul 2004 10:22:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHMIQh077356 for ; Thu, 15 Jul 2004 10:22:19 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 15 Jul 2004 18:24:44 +0100 Message-ID: <40F6BD45.302@isode.com> Date: Thu, 15 Jul 2004 18:22:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nkb CC: ietf-sasl@imc.org Subject: Re: Beginner question: can we use SASL over HTTP? References: <40F668B2.6080801@pacific.net.sg> In-Reply-To: <40F668B2.6080801@pacific.net.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: nkb wrote: > Hi. > I'm new to this list. Pardon me if this question is ignorant. > > I would like to access webpages (e.g. myhome.aspx) that require some > form of authentication, s.a. the windows' NTLM authentication. I've > written most of the application codes. I'm stuck at not being able to > access pages that require authentication, specifically windows NTLM > authentication. Before I spend too much time reading into SASL, I was > wondering if this is the library that I could use to help me take care > of this NTLM authentication to access webpages? Thank you for any > pointers. The short answer is "no". A longer answer is: there is a draft that describes how to use SASL over HTTP, however it is not implemented by any known browser. If you have more questions on this, send me reply off the mailing list. Regards, Alexey From owner-ietf-sasl Thu Jul 15 11:31:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FIVYFN089623; Thu, 15 Jul 2004 11:31:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FIVYRr089622; Thu, 15 Jul 2004 11:31:34 -0700 (PDT) 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 i6FIVVfF089598 for ; Thu, 15 Jul 2004 11:31:31 -0700 (PDT) (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 i6FIVHJ6002650; Thu, 15 Jul 2004 11:31:17 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i6FIV18X024824; Thu, 15 Jul 2004 12:31:01 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i6FIS7ZJ646312; Thu, 15 Jul 2004 13:28:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i6FIS7qs646311; Thu, 15 Jul 2004 13:28:07 -0500 (CDT) Date: Thu, 15 Jul 2004 13:28:07 -0500 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040715182807.GZ632478@binky.central.sun.com> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jul 05, 2004 at 09:51:09AM +0200, Simon Josefsson wrote: > > There is a requirement that the GSS-API channel bindings are NULL. > I'd feel more comfortable if there was a way to somehow make use of > channel bindings, to link the authentication to the specific channel. > Does anyone have ideas on whether to add this, and if the answer is > positive, how it might be done? 1. Existing GSS-API mechanisms fail to correctly deal with channel bindings. E.g., SPKM is way underspaecified in general, and here specifically; also, the Kerberos V mechanism does not have a way for the acceptor to prove to the initiator that it too has the same channel bindings as the initiator. 2. We're trying to address this through a stackable pseudo-mechanism (CCM-BIND) one of whose purposes is to address this problem. See: draft-ietf-nfsv4-ccm-03.txt 3. The whole subject of channel bindings needs further specification. I'm about to submit a new version of draft-ietf-nfsv4-channel-bindings (-01.txt) that does this and which describes what goes into the channel bindings for SSHv2, TLS and IPsec channels, and then I'll submit draft-williams-gssapi-channel-bindings-00.txt for the KITTEN BoF (and, hopefully, WG), which fills in the details of how to use channel bindings to SSHv2, TLS and IPsec channels with the GSS-API. The deadline for filing new I-Ds has passed though, so this won't get posted to the I-D repository until after this meeting. 4. Given CCM-BIND and the two other drafts it should be possible to use SASL with GSS-API channel bindings; SASL APIs will have to be modified so the application can provide the necessary channel information. 5. I have proposed a set of interfaces for determining the features of GSS mechs, as part of a framework for stackable pseudo-mechanisms, which should help GSS apps avoid having to hardcode mechanism OIDs and information about them (e.g., "channel bindings work well with this mechanism, but not with that one"). See: draft-williams-gssapi-stackable-pseudo-mechs-00.txt As you can see, there's a lot of activity around this topic. > I understand that the simplest "solution", from the SASL mechanism > point of view, might simply be to consider GSS-API mechanisms, that > doesn't link gss_wrap/gss_get_mic tokens with one specific > authentication, as broken. However, channel bindings are provided by > GSS-API to enable applications to close this hole, hence these GSS-API > mechanisms can probably not be viewed as broken in general. So it is > unfortunate that the SASL wrapping of GSS-API forbid channel bindings. > I'd say this warrant a paragraph in the security section, unless the > text about channel bindings is loosened up. The SASL handling of GSS-API mechanisms does need some tweaking, both, in light of the above and to provide for re-keying (GSS-API contexts can expire, after all) by reestablishing GSS security contexts for the principals involved. Cheers, Nico -- From owner-ietf-sasl Fri Jul 16 06:42:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDgd5g067734; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GDgdrd067733; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDgcFw067726 for ; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 16 Jul 2004 14:44:48 +0100 Message-ID: <40F7DB35.4000502@isode.com> Date: Fri, 16 Jul 2004 14:42:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Lyndon Nerenberg CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: in CRAM-MD5 References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> In-Reply-To: <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote: > --On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" > wrote: > >>> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" >>> ; a bracketed string of printing characters, not >>> ; containing embedded "<" or ">" >>> >>> and modify the text to emphasize the importance of generating unique >>> challenges, making reference to the historical behaviour. >> >> Seems reasonable to me. > I am glad about this change, I've been advocating something similar before. Alexey From owner-ietf-sasl Tue Jul 20 17:01:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L01rNW005358; Tue, 20 Jul 2004 17:01:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L01rt8005357; Tue, 20 Jul 2004 17:01:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from PC_hipolito.com (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L01pt2005351 for ; Tue, 20 Jul 2004 17:01:52 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Tue, 20 Jul 2004 19:02:03 -0500 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------majkqzkcezrdrjmmzrse" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------majkqzkcezrdrjmmzrse Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Lovely animals


----------majkqzkcezrdrjmmzrse Content-Type: application/octet-stream; name="Dog.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Dog.scr" ----------majkqzkcezrdrjmmzrse-- From owner-ietf-sasl Wed Jul 21 05:43:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LCh28V078250; Wed, 21 Jul 2004 05:43:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LCh2NO078249; Wed, 21 Jul 2004 05:43:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from komp67.org (yn250.internetdsl.tpnet.pl [80.55.247.250]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6LCh0BR078234 for ; Wed, 21 Jul 2004 05:43:01 -0700 (PDT) (envelope-from jgmyers@netscape.com) Date: Wed, 21 Jul 2004 14:43:00 +0100 To: "Ietf-sasl" From: "Jgmyers" Subject: Protected message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ouyenmooiqtdcfbsrzwy" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------ouyenmooiqtdcfbsrzwy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached file tells everything.


----------ouyenmooiqtdcfbsrzwy Content-Type: application/octet-stream; name="text_document.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="text_document.scr" ----------ouyenmooiqtdcfbsrzwy-- From owner-ietf-sasl Wed Jul 21 09:38:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGcJmN002832; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LGcJPM002831; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-EIGHTY-TWO.MIT.EDU [18.187.6.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGcIm5002825 for ; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 96C90E0052; Wed, 21 Jul 2004 12:38:35 -0400 (EDT) To: ietf-sasl@imc.org Subject: GSSAPI direction Message-Id: <20040721163835.96C90E0052@cz.mit.edu> Date: Wed, 21 Jul 2004 12:38:35 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [This message and for the most part any of my participation in GSSAPI discussions are in the role of a participant not as a WG chair.] I'd like to start a discussion about what direction we want to take with the GSSAPI work. Our charter requires that the work needs to be based on the existing draft. We probably need to at least document the behavior of the GSSAPI (kerberos 5) sasl mechanism. However the current GSSAPI protocol seems to be fairly inefficient. It requires an extra round trip to negotiate the security layers; it does not piggyback this negotiation on the last token. The mechanism will not take advantage of the prot_ready flag to remove a half round trip. I think the GSSAPI sasl mechanism need to be as efficient as we can make them. There are two primary motivations for this. First, I'd like to see GSSAPI HTTP be reasonably fast. Second, I'd like to remove any excuses we can for designing SASL mechanisms instead of GSSAPI mechanisms. Redundancy in security protocols is undesirable. Note that if we do change the gssapi draft in an incompatible manner, we would need to change the prefix of the sasl mechanism names. Note also that changing the gssapi mechanism is more reasonable than the other mechanisms; so far the gssapi mechanism is only an internet draft. There is a description of GSSAPI in RFC 2222 but we're already going to end up being incompatible with that description for everything besides Kerberos. --Sam From owner-ietf-sasl Wed Jul 21 13:10:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LKA6e1022647; Wed, 21 Jul 2004 13:10:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LKA63s022646; Wed, 21 Jul 2004 13:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LKA5bO022640 for ; Wed, 21 Jul 2004 13:10:05 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i6LKAAv4010593 for ; Wed, 21 Jul 2004 20:10:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 21 Jul 2004 13:10:30 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] 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: [with correct Last Call close date --Kdz] This message initiates a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. If after completing your review you find no issues, please indicate so to the chairs. The Last Call period will close on Friday, 13 August 2004. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! Kurt Zeilenga, SASL WG co-chair From owner-ietf-sasl Wed Jul 21 13:08:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LK8KFV022485; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LK8KSS022484; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LK8KvT022473 for ; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i6LK8Lv4010578 for ; Wed, 21 Jul 2004 20:08:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040721130411.04e7dbb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 21 Jul 2004 13:08:42 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt 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: This message initiates a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. If after completing your review you find no issues, please indicate so to the chairs. The Last Call period will close on Friday, 13 September 2003. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! Kurt Zeilenga, SASL WG co-chair From owner-ietf-sasl Wed Jul 21 14:48:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LLmbGJ033471; Wed, 21 Jul 2004 14:48:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LLmbva033470; Wed, 21 Jul 2004 14:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LLmafn033464 for ; Wed, 21 Jul 2004 14:48:36 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6LLkS53000577 for ; Wed, 21 Jul 2004 15:46:28 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i6LLme8X018683 for ; Wed, 21 Jul 2004 15:48:40 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6LLkLRj005246; Wed, 21 Jul 2004 16:46:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6LLkLPc005245; Wed, 21 Jul 2004 16:46:21 -0500 (CDT) Date: Wed, 21 Jul 2004 16:46:21 -0500 From: Nicolas Williams To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040721214621.GX815@binky.central.sun.com> Mail-Followup-To: "Kurt D. Zeilenga" , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > This message initiates a SASL Working Group Last Call on the > document: > > Title: > Simple Authentication and Security Layer (SASL) > > Editor: > A. Melnikov > > Filename: draft-ietf-sasl-rfc2222bis-08.txt Your timing is convenient. I have recently come to realize that neither rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of security layers. Perhaps I'm missing something. It's also pretty clear to me that SASL mechanisms cannot re-key security layers without application involvement (at least if using any SASL APIs that require that the application use per-message/buffer security layer calls). Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely address this by mentioning multiple authentications and replacing old security layers with new ones, which is, almost, exactly how I would expect SASL apps to re-key (see below). I propose the following changes to rfc2222bis: - Explicitly state that there is no security layer re-keying facility. (Alternatively design such a facility and add it to rfc2222bis; I don't like this alternative myself, mostly because it would require updating all the SASL mechanisms to specify re-keying and because either way the application must be involved in the re-keying process, so this alternative buys us nothing.) If re-keying be done by re-authenticating and negotiating new security layers (as in section 6.3 of rfc2222bis) then presumably the authenticated identities should remain the same(!). - Add security considerations text about security layer expiration due to passage of time, use of cryptographic material, administrative policies (e.g., credentials expiration). Consider the text of draft-ietf-secsh-newmodes, for example; the details of layer expiration typically will vary by SASL mechanism, but the underlying rationales (e.g., defense against cryptanalysis) should hold across the board. - Add a requirement that SASL mechanisms provide indications of security layer expiration to applications. Security layer expiration should probably have advisory and mandatory modes (advisory primarily for applications that lack support for re-negotiating security layers). - Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, LDAP) specify how to replace old SASL security layers with new ones. - If section 6.3 was meant for any purpose other than re-keying then please clarify it. For example, if an application authenticates as one identity, then switches to another and re-authenticates, presumably it should not act (or be allowed to, by its peer) on behalf of the first identity while using the second security layer, at least for some mechanisms. Additionally, where IETF documents specify application protocol use of SASL it would be nice to have clarifications/extensions for re-negotiation of SASL security layers -- that is, re-keying. Cheers, Nico -- From owner-ietf-sasl Thu Jul 22 08:44:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFihdF027356; Thu, 22 Jul 2004 08:44:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MFihXU027355; Thu, 22 Jul 2004 08:44:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-EIGHTY-TWO.MIT.EDU [18.187.6.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFig6M027349 for ; Thu, 22 Jul 2004 08:44:42 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id CBEA6E0052; Thu, 22 Jul 2004 11:44:58 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> From: Sam Hartman Date: Thu, 22 Jul 2004 11:44:58 -0400 In-Reply-To: <20040721214621.GX815@binky.central.sun.com> (Nicolas Williams's message of "Wed, 21 Jul 2004 16:46:21 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> - Add security considerations text about security layer Nicolas> expiration due to passage of time, use of cryptographic Nicolas> material, administrative policies (e.g., credentials Nicolas> expiration). Nicolas> Consider the text of draft-ietf-secsh-newmodes, for Nicolas> example; the details of layer expiration typically will Nicolas> vary by SASL mechanism, but the underlying rationales Nicolas> (e.g., defense against cryptanalysis) should hold across Nicolas> the board. Nico has a point. The security ADs seem to care a fair bit about key reuse. Given that the issue has been brought up, I'd expect a discuss if we don't at least address it in security considerations. At a minimum we need to discuss the fact that security layers can exceed their key lifetimes and give guidance to application designers. --Sam From owner-ietf-sasl Thu Jul 22 12:50:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJoFXm047456; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MJoF1d047455; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJoEP4047447 for ; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21425; Thu, 22 Jul 2004 15:50:17 -0400 (EDT) Message-Id: <200407221950.PAA21425@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-10.txt Date: Thu, 22 Jul 2004 15:50:16 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-10.txt Pages : 7 Date : 2004-7-22 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-10.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-saslprep-10.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-saslprep-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Sun Jul 25 15:37:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PMbOap066831; Sun, 25 Jul 2004 15:37:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PMbOmD066830; Sun, 25 Jul 2004 15:37:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PMbM9l066823 for ; Sun, 25 Jul 2004 15:37:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust157.tnt103.lnd4.gbr.da.uu.net [213.116.54.157]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 25 Jul 2004 23:38:11 +0100 Message-ID: <4104263B.2000707@isode.com> Date: Sun, 25 Jul 2004 22:29:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: GSSAPI direction References: <20040721163835.96C90E0052@cz.mit.edu> In-Reply-To: <20040721163835.96C90E0052@cz.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: >[This message and for the most part any of my participation in GSSAPI >discussions are in the role of a participant not as a WG chair.] > >I'd like to start a discussion about what direction we want to take >with the GSSAPI work. Our charter requires that the work needs to be >based on the existing draft. We probably need to at least document >the behavior of the GSSAPI (kerberos 5) sasl mechanism. > > I agree. >However the current GSSAPI protocol seems to be fairly inefficient. >It requires an extra round trip to negotiate the security layers; it >does not piggyback this negotiation on the last token. The mechanism >will not take advantage of the prot_ready flag to remove a half round >trip. > >I think the GSSAPI sasl mechanism need to be as efficient as we can >make them. There are two primary motivations for this. First, I'd >like to see GSSAPI HTTP be reasonably fast. Second, I'd like to >remove any excuses we can for designing SASL mechanisms instead of >GSSAPI mechanisms. Redundancy in security protocols is undesirable. > >Note that if we do change the gssapi draft in an incompatible manner, > > I don't mind the changes you are proposing (at least I agree with their motivation), however this suggestion is a bit late and I would like to point out that there several independent implementations of GSSAPI (Kerberos) mechanism that interoperate well (at least better than DIGEST-MD5). I am afraid that it is not possible to reduce existing 2 round trips in a backward compatible manner. I would be glad if you can prove me wrong. So, if the WG wants to tackle the issue that you've described above, I would suggest that the WG publishes the existing GSSAPI draft as GSSAPI Kerberos-only and designs a new GSSAPIv2 (which works for all GSSAPI mechanisms) in a separate draft. >we would need to change the prefix of the sasl mechanism names. Note >also that changing the gssapi mechanism is more reasonable than the >other mechanisms; so far the gssapi mechanism is only an internet >draft. There is a description of GSSAPI in RFC 2222 but we're already >going to end up being incompatible with that description for >everything besides Kerberos. > Alexey From owner-ietf-sasl Mon Jul 26 01:24:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q8OPPh072340; Mon, 26 Jul 2004 01:24:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q8OPF2072339; Mon, 26 Jul 2004 01:24:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (illegal-drugs.naming-schemes.org [67.65.18.113]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q8OOnk072328 for ; Mon, 26 Jul 2004 01:24:24 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 2FD7DE004C; Mon, 26 Jul 2004 04:24:28 -0400 (EDT) To: ietf-sasl@imc.org Subject: [Sam Hartman] Agenda for SASL at IETF 60 From: Sam Hartman Date: Mon, 26 Jul 2004 04:24:28 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-=-= I'm sorry this hasn't been reviewed here. Kurt, Alexey and I were discussing a proposed agenda and I realized that later today is the deadline for submitting the agenda. Naturally if the consensus of the working group is that we need to discuss something else, we will do so. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 26 Jul 2004 04:22:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by suchdamage.org (Postfix) with ESMTP id 25C0313230 for ; Mon, 26 Jul 2004 04:22:42 -0400 (EDT) Received: from cz.mit.edu (illegal-drugs.naming-schemes.org [67.65.18.113]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i6Q8MagH014036 for ; Mon, 26 Jul 2004 04:22:37 -0400 (EDT) Received: by cz.mit.edu (Postfix, from userid 8042) id 054BFE004C; Mon, 26 Jul 2004 04:22:40 -0400 (EDT) To: kurt@openldap.org, hartmans@mit.edu, agenda@ietf.org Subject: Agenda for SASL at IETF 60 Message-Id: <20040726082240.054BFE004C@cz.mit.edu> Date: Mon, 26 Jul 2004 04:22:40 -0400 (EDT) From: hartmans@MIT.EDU (Sam Hartman) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: MIME-Version: 1.0 Simple AUthentication and Security Layer (SASL) Tuesday, AUgust 3, 2004 1300-1400 =============================================== Agenda: Introductions and Agenda Bashing - chairs (5 minutes) Review of SASL Base last call - Chairs/Alexey (10 minutes) Digest md5 (draft--ietf-sasl-rfc2831bis) - Alexey (15 minutes) GSSAPI (draft-ietf-sasl-gssapi) - Alexey (15 minutes) Cram-md5 (draft-ietf-sasl-crammd5) - (15 minutes) Open mic - (remaining time) --=-=-=-- From owner-ietf-sasl Tue Jul 27 07:42:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REgf3C049825; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6REgfEA049824; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REgfq1049818 for ; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i6REgfCB018968 for ; Tue, 27 Jul 2004 07:42:41 -0700 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i6REged28712 for ; Tue, 27 Jul 2004 07:42:40 -0700 (PDT) Message-Id: <200407271442.i6REged28712@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Liberty SASL-based Authn over SOAP To: ietf-sasl@imc.org From: Jeff.Hodges@KingsMountain.com Reply-to: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jul 2004 07:42:40 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Of possible interest... Liberty ID-WSF Authentication Service Specification http://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.0.pdf Abstract: This specification defines an ID-WSF Authentication Protocol based on a profile of the Simple Authentication and Security Layer (SASL) framework mapped onto ID-* SOAP-bound messages. Next, it defines an ID-WSF Authentication Service Identity Providers may offer, which is based on the authentication protocol. This authentication service enables Web Services Consumers and/or Liberty-enabled User Agents or Devices to authenticate with Identity Providers using various authentication mechanisms and obtain ID-WSF security tokens. Finally, it defines an ID-WSF Single Sign-On Service. This service provides authentication assertions to Web Service Consumers via a profile of the ID-FF Single Sign-On Protocol, enabling Web Service Consumers to interact with ID-FF-based Service Providers. [ID-WSF = "Identity Web Services Framework" ID-FF = "Identity Federation Framework"] Likely helpful... Liberty Glossary, Version 1.3 http://www.projectliberty.org/specs/liberty-glossary-v1.3.pdf Thanks to Alexey for his review in the process of writing this spec. Other specs that the ID-WSF Authn Svc spec depends upon, or is related to (e.g. ID-FF specs) are available at [1]. If folks have any questions about these specs, or Liberty, feel free to drop me a line. thanks, JeffH [1] Liberty Alliance Project - Spec repository http://www.projectliberty.org/specs/ From owner-ietf-sasl Tue Jul 27 07:49:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REnsVl051395; Tue, 27 Jul 2004 07:49:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6REns94051394; Tue, 27 Jul 2004 07:49:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REnrVb051387 for ; Tue, 27 Jul 2004 07:49:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 27 Jul 2004 15:53:20 +0100 Message-ID: <41066B90.9030203@isode.com> Date: Tue, 27 Jul 2004 15:49:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> In-Reply-To: <20040721214621.GX815@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams wrote: >On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > > >>This message initiates a SASL Working Group Last Call on the >>document: >> >>Title: >>Simple Authentication and Security Layer (SASL) >> >>Editor: >>A. Melnikov >> >>Filename: draft-ietf-sasl-rfc2222bis-08.txt >> > >Your timing is convenient. I have recently come to realize that neither >rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of >security layers. Perhaps I'm missing something. > >It's also pretty clear to me that SASL mechanisms cannot re-key security >layers without application involvement (at least if using any SASL APIs >that require that the application use per-message/buffer security layer >calls). > As a developer, I am not sure I agree. At least I can imagine how this can be done automatically. >Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely >address this by mentioning multiple authentications and replacing old >security layers with new ones, which is, almost, exactly how I would >expect SASL apps to re-key (see below). > No, reauthentication is not the same as re-keying. The client may choose to reauthenticate as a different user, for example if the client is some kind of a proxy. >I propose the following changes to rfc2222bis: > > - Explicitly state that there is no security layer re-keying facility. > Yes. But I would like to add instead that "there is no generic security layer re-keying facility", as each SASL mechanism that support a security layer is free to implement own re-keying. > (Alternatively design such a facility and add it to rfc2222bis; I > don't like this alternative myself, mostly because it would require > updating all the SASL mechanisms to specify re-keying and because > either way the application must be involved in the re-keying process, > so this alternative buys us nothing.) > I don't like this either, for the same reasons. > > If re-keying be done by re-authenticating and negotiating new > security layers (as in section 6.3 of rfc2222bis) then presumably the > authenticated identities should remain the same(!). > > - Add security considerations text about security layer expiration due > to passage of time, use of cryptographic material, administrative > policies (e.g., credentials expiration). > > Consider the text of draft-ietf-secsh-newmodes, for example; the > details of layer expiration typically will vary by SASL mechanism, > but the underlying rationales (e.g., defense against cryptanalysis) > should hold across the board. > I would appreciate if you can send some text to me. > > - Add a requirement that SASL mechanisms provide indications of > security layer expiration to applications. > We can't make this a requirement, as support for a security layer is an optional feature of SASL framework. But we can make this as a recommendation. >Security layer expiration > should probably have advisory and mandatory modes (advisory primarily > for applications that lack support for re-negotiating security > layers). > > - Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, > LDAP) specify how to replace old SASL security layers with new ones. > This wouldn't be possible, as not all protocols support reauthentication. > - If section 6.3 was meant for any purpose other than re-keying then > please clarify it. For example, if an application authenticates as > one identity, then switches to another and re-authenticates, > Yes. > presumably it should not act (or be allowed to, by its peer) on > behalf of the first identity while using the second security layer, > at least for some mechanisms. > > Can you suggest some text? >Additionally, where IETF documents specify application protocol use of >SASL it would be nice to have clarifications/extensions for >re-negotiation of SASL security layers -- that is, re-keying. > >Cheers, > >Nico > > From owner-ietf-sasl Tue Jul 27 08:31:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFVXGK061138; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RFVXlX061137; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) 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 i6RFVXmp061126 for ; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) (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 i6RFVSJ6017706 for ; Tue, 27 Jul 2004 08:31:28 -0700 (PDT) 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 i6RFVS4F017836 for ; Tue, 27 Jul 2004 09:31:28 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RFT26U025319; Tue, 27 Jul 2004 10:29:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RFT1RL025318; Tue, 27 Jul 2004 10:29:01 -0500 (CDT) Date: Tue, 27 Jul 2004 10:29:01 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040727152901.GQ815@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> <41066B90.9030203@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41066B90.9030203@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 03:49:52PM +0100, Alexey Melnikov wrote: > Nicolas Williams wrote: > > >On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > > > > > >>This message initiates a SASL Working Group Last Call on the > >>document: > >> > >>Title: > >>Simple Authentication and Security Layer (SASL) > >> > >>Editor: > >>A. Melnikov > >> > >>Filename: draft-ietf-sasl-rfc2222bis-08.txt > >> > > > >Your timing is convenient. I have recently come to realize that neither > >rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of > >security layers. Perhaps I'm missing something. > > > >It's also pretty clear to me that SASL mechanisms cannot re-key security > >layers without application involvement (at least if using any SASL APIs > >that require that the application use per-message/buffer security layer > >calls). > > > As a developer, I am not sure I agree. At least I can imagine how this > can be done automatically. What do you not agree with? The case described in the parenthetical expression above cannot have automatic re-keying without changing the existing APIs. We've been over this, with respect to the GSS-API, at either the old CAT WG list or at the KRB WG list a year or two ago. > >Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely > >address this by mentioning multiple authentications and replacing old > >security layers with new ones, which is, almost, exactly how I would > >expect SASL apps to re-key (see below). > > > No, reauthentication is not the same as re-keying. The client may choose > to reauthenticate as a different user, for example if the client is some > kind of a proxy. RFC2222 and rfc222bis are mighty clear that re-authentication that negotiates new security layers leads to replacement of the old layers with the new ones. Re-authenticate the same identities while negotiating new layers and you've got re-keying. IPsec w/ IKEv1 handles re-keying by establishing brand new SAs (for the same IDs). ONC RPC w/ RPCSEC_GSS (and, therefore, NFS) handles re-keying the same way, namely, by establishing new GSS-API security contexts (for the same names). (This is actually very implicit, rather than explicit, in the RPCSEC_GSS spec; what happens is that a GSS sec. context is needed only for the life of an actual RPC, but RPC apps, like NFS, typically make many RPCs and authorize peers on each call by inspecting the peer's GSS name. Today I would want the spec to be explicit about re-keying. This is, in fact, my attitude to SASL and re-keying.) IPsec w/ IKEv2 can re-key IKE_SAs during their lifetime, but if those expire it reverts to IPsec w/ IKEv1 re-keying behaviour. SSHv2 supports true re-keying, rather than re-keying by re-authentication. But if you use the GSS-API-protected SSHv2 key exchange to re-key SSHv2 connections then you also re-authenticate. I think there's a well established tradition of re-keying by re-authenticating the same identities where possible. > >I propose the following changes to rfc2222bis: > > > >- Explicitly state that there is no security layer re-keying facility. > > > Yes. But I would like to add instead that "there is no generic security > layer re-keying facility", as each SASL mechanism that support a > security layer is free to implement own re-keying. See my note above; some SASL APIs will require changes to support re-keying with such mechanisms. I'm pretty sure that the Cyrus SASL API would, for example. And existing SASL mechanisms do not support re-keying, leaving us with re-keying-by-re-authenticating as the only simple alternative, an alternative for which there is a fine tradition. > >- Add security considerations text about security layer expiration due > > to passage of time, use of cryptographic material, administrative > > policies (e.g., credentials expiration). > > > > Consider the text of draft-ietf-secsh-newmodes, for example; the > > details of layer expiration typically will vary by SASL mechanism, > > but the underlying rationales (e.g., defense against cryptanalysis) > > should hold across the board. > > > I would appreciate if you can send some text to me. Generic text for rfc2222bis? I can do that. > > > >- Add a requirement that SASL mechanisms provide indications of > > security layer expiration to applications. > > > We can't make this a requirement, as support for a security layer is an > optional feature of SASL framework. > But we can make this as a recommendation. Nonsense. You can make this mandatory, for new and revised mechanisms, where security layer support is available. The SASL GSS mechanisms can provide this today, since the GSS-API provides for context expiration. And note that infinite and, possibly, unspecified security layer lifetimes should be legitimate values for security layer expiration. > >Security layer expiration > > should probably have advisory and mandatory modes (advisory primarily > > for applications that lack support for re-negotiating security > > layers). > > > >- Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, > > LDAP) specify how to replace old SASL security layers with new ones. > > > This wouldn't be possible, as not all protocols support reauthentication. But new ones could. It's not at all clear to me that SMTP/SUBMIT don't support re-authentication, for example. I'm not sure whether this WG can clarify that, but it can clarify that _new_ application protocols that use SASL must support re-authentication, and thus re-keying. We can go back and update the application protocol specs where lack of re-authentication/re-keying hurts -- later. First we need rfc2222bis to say something about the matter. > >- If section 6.3 was meant for any purpose other than re-keying then > > please clarify it. For example, if an application authenticates as > > one identity, then switches to another and re-authenticates, > > > Yes. > > > presumably it should not act (or be allowed to, by its peer) on > > behalf of the first identity while using the second security layer, > > at least for some mechanisms. > > > > > Can you suggest some text? No, I cannot. This WG should discuss and come up with this clarification. I can send you text on re-keying, but perhaps we should see where the WG looks to be heading on that matter. Cheers, Nico -- From owner-ietf-sasl Tue Jul 27 08:51:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFpIGJ065417; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RFpI1d065415; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFpI7G065394 for ; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) (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 i6RFpG0R014432 for ; Tue, 27 Jul 2004 08:51:16 -0700 (PDT) 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 i6RFpC4F009355 for ; Tue, 27 Jul 2004 09:51:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RFmlTM025329; Tue, 27 Jul 2004 10:48:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RFmkRW025328; Tue, 27 Jul 2004 10:48:46 -0500 (CDT) Date: Tue, 27 Jul 2004 10:48:46 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040727154846.GM826@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> <41066B90.9030203@isode.com> <20040727152901.GQ815@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040727152901.GQ815@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 10:29:01AM -0500, Nicolas Williams wrote: > But new ones could. It's not at all clear to me that SMTP/SUBMIT don't > support re-authentication, for example. I'm not sure whether this WG > can clarify that, but it can clarify that _new_ application protocols > that use SASL must support re-authentication, and thus re-keying. Actually, rfc2554 is quite clear that it is not possible to re-authenticate in the SMTP/SUBMIT protocols. This is unfortunate. Nico -- From owner-ietf-sasl Tue Jul 27 11:22:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIMfdS099614; Tue, 27 Jul 2004 11:22:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RIMfJJ099613; Tue, 27 Jul 2004 11:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIMdc9099554 for ; Tue, 27 Jul 2004 11:22:40 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i6RIMNs9003667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jul 2004 14:22:26 -0400 (EDT) Message-ID: <41069D5E.9010403@columbia.edu> Date: Tue, 27 Jul 2004 14:22:22 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: Kerberos WG , SASL WG , security-wg@ggf.org, nfsv4@ietf.org, saag@mit.edu Subject: Kitten (Common Authentication Technologies - Next Generation) at IETF 60 X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Common Authentication Technologies Next Generation (Kitten) BOF will be meeting at IETF 60: 1530-1730 Afternoon Sessions II Grande B SEC kitten Kitten (Daughter of CAT) BOF The agenda of the meeting is as follows: _ Kitten BOF Agenda for IETF 60_ * Introduction and Welcome [5 minutes] - Jeffrey Altman * Discussion of the Global Grid Forum GSS requirements [15 minutes] - Doug Engert * Discussion of channel bindings portability issues (C struct et all) [10 minutes] - Sam Hartman * Discussion of GSSAPI naming [15 minutes] - Sam Hartman * Discussion of need for cryptographic channel bindings and CCM [10 minutes] - Nicolas Williams * Discussion of Stackable Psuedo Mechanisms [10 minutes] - Nicolas Williams * Discussion of the SPNEGO issues [10 minutes] - Wyllys Ingersol * Discussion of the C# Bindings for GSSAPI [10 minutes] - Microsoft * Charter discussion [15 minutes] - Jeffrey Altman An introduction to the purpose of the Kitten Working Group and a proposed charter may be found at: http://www.ietf.org/ietf/04aug/kitten.txt We encourage anyone interested in the future of GSSAPI (applications which use GSSAPI or mechanisms implementing GSSAPI); those concerned with authenticated name portability; and those participating in the Cryptographic Channel Bindings work to attend this BOF and participate in the discussions. For the most part the Kitten participants have identified problem areas; have presented some potential incomplete solutions; and there is much work to be done. I hope to see you there. Jeffrey Altman From owner-ietf-sasl Tue Jul 27 11:54:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIsDWT007299; Tue, 27 Jul 2004 11:54:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RIsDAo007298; Tue, 27 Jul 2004 11:54:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIs594007257 for ; Tue, 27 Jul 2004 11:54:10 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BpX5Q-0004Am-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: GSS-API channel bindings Date: Tue, 27 Jul 2004 20:54:01 +0200 Lines: 42 Message-ID: References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:8lfckb0bwOCEgjYbavs0poCWWNE= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: ... > As you can see, there's a lot of activity around this topic. Thanks for this useful overview of activities. >> I understand that the simplest "solution", from the SASL mechanism >> point of view, might simply be to consider GSS-API mechanisms, that >> doesn't link gss_wrap/gss_get_mic tokens with one specific >> authentication, as broken. However, channel bindings are provided by >> GSS-API to enable applications to close this hole, hence these GSS-API >> mechanisms can probably not be viewed as broken in general. So it is >> unfortunate that the SASL wrapping of GSS-API forbid channel bindings. >> I'd say this warrant a paragraph in the security section, unless the >> text about channel bindings is loosened up. > > The SASL handling of GSS-API mechanisms does need some tweaking, both, > in light of the above and to provide for re-keying (GSS-API contexts can > expire, after all) by reestablishing GSS security contexts for the > principals involved. Do you have any thoughts on how to modify the SASL GSSAPI mechanism so it is possible for it to use non-NULL channel bindings automatically? The most simplistic solution is to permit non-NULL channel bindings in the specification, and leave everything up to application protocols. However, that approach require application protocol implementations to tell the SASL library what GSSAPI channel bindings it wants. While this is feasible, perhaps it can be made even better. What I'm trying to understand, is whether the SASL GSSAPI mechanism, by itself, could construct the actual channel binding, and use it at both ends. (Some application might want to provide the channel binding data themselves, so the above should only be a possible default behaviour, in order to bind SASL GSSAPI authentication to a specific channel.) Regards, Simon From owner-ietf-sasl Tue Jul 27 13:23:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RKN0YI028938; Tue, 27 Jul 2004 13:23:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RKN0kB028937; Tue, 27 Jul 2004 13:23:00 -0700 (PDT) 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 i6RKMvnU028909 for ; Tue, 27 Jul 2004 13:22:57 -0700 (PDT) (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 i6RKMuJ6025774 for ; Tue, 27 Jul 2004 13:22:56 -0700 (PDT) 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 i6RKMt4H002427 for ; Tue, 27 Jul 2004 14:22:56 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RKKTSW025770; Tue, 27 Jul 2004 15:20:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RKKSIY025769; Tue, 27 Jul 2004 15:20:28 -0500 (CDT) Date: Tue, 27 Jul 2004 15:20:28 -0500 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040727202028.GW815@binky.central.sun.com> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 08:54:01PM +0200, Simon Josefsson wrote: > > Nicolas Williams writes: > > ... > > As you can see, there's a lot of activity around this topic. > > Thanks for this useful overview of activities. NP. [...] > > The SASL handling of GSS-API mechanisms does need some tweaking, both, > > in light of the above and to provide for re-keying (GSS-API contexts can > > expire, after all) by reestablishing GSS security contexts for the > > principals involved. > > Do you have any thoughts on how to modify the SASL GSSAPI mechanism so > it is possible for it to use non-NULL channel bindings automatically? See the CCM I-D in the NFSv4 WG and my personal I-D on stackable GSS pseudo-mechanisms, which is due to be a WG I-D for KITTEN, if the KITTEN BoF (which will meet this Monday) succeeds. The short answer is that by negotiating the use of CCM-BIND apps also negotiate the use of channel bindings. CCM-BIND is a stackable pseudo-mechanism which is primarily intended for these two purposes: - properly implement channel bindings the (the krb5 and spkm mechs don't) - indicate, in mechanism negotiations, the willingness to use channe bindings Applications shouldn't offer or accept CCM mechanisms in their negotiations if they have no useful channel to bind to. The flip side is that apps SHOULD offer and/or accept CCM mechanisms in their negotiations if they do have such channels and bindings and want to use channel bindings. > The most simplistic solution is to permit non-NULL channel bindings in > the specification, and leave everything up to application protocols. See above. This could work, but, the incomplete channel bindings support in the Kerberos V and SPKM GSS mechanisms, and the additional complexity for application protocols argues for the approach I offer instead, namely to leverage existing mechanism negotiations in application protocols to negotiate the use of channel bindings by using mechanism OIDs which indicate the desire to do so. > However, that approach require application protocol implementations to > tell the SASL library what GSSAPI channel bindings it wants. While > this is feasible, perhaps it can be made even better. And requires changes to the application protocol to properly negotiate the use of channel bindings. The approach I offer does not. > What I'm trying to understand, is whether the SASL GSSAPI mechanism, > by itself, could construct the actual channel binding, and use it at > both ends. No, it cannot, but I have an I-D, which did not make the cutoff for new I-Ds which specifies channel bindings constructor interfaces that make this task easy for application developers. > (Some application might want to provide the channel binding data > themselves, so the above should only be a possible default behaviour, > in order to bind SASL GSSAPI authentication to a specific channel.) Of course. Nico -- From owner-ietf-sasl Thu Jul 29 12:21:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJLBvX090828; Thu, 29 Jul 2004 12:21:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJLBwa090827; Thu, 29 Jul 2004 12:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJL7NE090803 for ; Thu, 29 Jul 2004 12:21:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 29 Jul 2004 20:24:41 +0100 Message-ID: <41094E1C.2050404@isode.com> Date: Thu, 29 Jul 2004 20:21:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: >Do you have any thoughts on how to modify the SASL GSSAPI mechanism so >it is possible for it to use non-NULL channel bindings automatically? > >The most simplistic solution is to permit non-NULL channel bindings in >the specification, and leave everything up to application protocols. > >However, that approach require application protocol implementations to >tell the SASL library what GSSAPI channel bindings it wants. While >this is feasible, perhaps it can be made even better. > >What I'm trying to understand, is whether the SASL GSSAPI mechanism, >by itself, could construct the actual channel binding, and use it at >both ends. > CMU SASL API allows applications to pass IP/port number of the both endpoints to the SASL library. It seems that this is sufficient to construct proper channel binding information? (Just thinking aloud). Also, if either the client or the server end uses non null channel binding and the other end doesn't, will they be able to authenticate? >(Some application might want to provide the channel binding data >themselves, so the above should only be a possible default behaviour, >in order to bind SASL GSSAPI authentication to a specific channel.) > > > > From owner-ietf-sasl Thu Jul 29 12:59:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJx2Ws097435; Thu, 29 Jul 2004 12:59:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJx2Jb097434; Thu, 29 Jul 2004 12:59:02 -0700 (PDT) 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 i6TJx19A097400 for ; Thu, 29 Jul 2004 12:59:01 -0700 (PDT) (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 i6TJx0J6011506 for ; Thu, 29 Jul 2004 12:59:00 -0700 (PDT) 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 i6TJwx4H008836 for ; Thu, 29 Jul 2004 13:59:00 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6TJuWFF003373; Thu, 29 Jul 2004 14:56:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6TJuWQ7003372; Thu, 29 Jul 2004 14:56:32 -0500 (CDT) Date: Thu, 29 Jul 2004 14:56:32 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040729195632.GB896@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> <41094E1C.2050404@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41094E1C.2050404@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jul 29, 2004 at 08:21:00PM +0100, Alexey Melnikov wrote: > > Simon Josefsson wrote: > > >Do you have any thoughts on how to modify the SASL GSSAPI mechanism so > >it is possible for it to use non-NULL channel bindings automatically? > > > >The most simplistic solution is to permit non-NULL channel bindings in > >the specification, and leave everything up to application protocols. > > > >However, that approach require application protocol implementations to > >tell the SASL library what GSSAPI channel bindings it wants. While > >this is feasible, perhaps it can be made even better. > > > >What I'm trying to understand, is whether the SASL GSSAPI mechanism, > >by itself, could construct the actual channel binding, and use it at > >both ends. > > > CMU SASL API allows applications to pass IP/port number of the both > endpoints to the SASL library. It seems that this is sufficient to > construct proper channel binding information? (Just thinking aloud). No, it's not enough because there's no cryptographic binding there, direct or indirect. Throw in authenticated and "latched" IPsec IDs and you've got strong bindings. Or, if you're running over a TLS channel, throw in the TLS finished messages. Or, if you're running over an SSHv2 channel, throw in the SSHv2 session ID. > Also, if either the client or the server end uses non null channel > binding and the other end doesn't, will they be able to authenticate? With the GSS-API? Technically they shouldn't, though the krb5 mech has some warts in this area (I won't describe them here). The point is: GSS-API channel bindings are not negotiated by the GSS mechanisms, so both peers must know a priori that both have or don't have channel bindings. Thus my comments earlier about CCM-BIND and negotiation of the use of GSS mechanisms specifically designed to signal and implement the use of channel bindings. Please see draft-ietf-nfsv4-channel-bindings-02.txt. 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 i6TJx2Ws097435; Thu, 29 Jul 2004 12:59:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJx2Jb097434; Thu, 29 Jul 2004 12:59:02 -0700 (PDT) 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 i6TJx19A097400 for ; Thu, 29 Jul 2004 12:59:01 -0700 (PDT) (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 i6TJx0J6011506 for ; Thu, 29 Jul 2004 12:59:00 -0700 (PDT) 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 i6TJwx4H008836 for ; Thu, 29 Jul 2004 13:59:00 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6TJuWFF003373; Thu, 29 Jul 2004 14:56:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6TJuWQ7003372; Thu, 29 Jul 2004 14:56:32 -0500 (CDT) Date: Thu, 29 Jul 2004 14:56:32 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040729195632.GB896@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> <41094E1C.2050404@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41094E1C.2050404@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jul 29, 2004 at 08:21:00PM +0100, Alexey Melnikov wrote: > > Simon Josefsson wrote: > > >Do you have any thoughts on how to modify the SASL GSSAPI mechanism so > >it is possible for it to use non-NULL channel bindings automatically? > > > >The most simplistic solution is to permit non-NULL channel bindings in > >the specification, and leave everything up to application protocols. > > > >However, that approach require application protocol implementations to > >tell the SASL library what GSSAPI channel bindings it wants. While > >this is feasible, perhaps it can be made even better. > > > >What I'm trying to understand, is whether the SASL GSSAPI mechanism, > >by itself, could construct the actual channel binding, and use it at > >both ends. > > > CMU SASL API allows applications to pass IP/port number of the both > endpoints to the SASL library. It seems that this is sufficient to > construct proper channel binding information? (Just thinking aloud). No, it's not enough because there's no cryptographic binding there, direct or indirect. Throw in authenticated and "latched" IPsec IDs and you've got strong bindings. Or, if you're running over a TLS channel, throw in the TLS finished messages. Or, if you're running over an SSHv2 channel, throw in the SSHv2 session ID. > Also, if either the client or the server end uses non null channel > binding and the other end doesn't, will they be able to authenticate? With the GSS-API? Technically they shouldn't, though the krb5 mech has some warts in this area (I won't describe them here). The point is: GSS-API channel bindings are not negotiated by the GSS mechanisms, so both peers must know a priori that both have or don't have channel bindings. Thus my comments earlier about CCM-BIND and negotiation of the use of GSS mechanisms specifically designed to signal and implement the use of channel bindings. Please see draft-ietf-nfsv4-channel-bindings-02.txt. 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 i6TJLBvX090828; Thu, 29 Jul 2004 12:21:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJLBwa090827; Thu, 29 Jul 2004 12:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJL7NE090803 for ; Thu, 29 Jul 2004 12:21:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 29 Jul 2004 20:24:41 +0100 Message-ID: <41094E1C.2050404@isode.com> Date: Thu, 29 Jul 2004 20:21:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: >Do you have any thoughts on how to modify the SASL GSSAPI mechanism so >it is possible for it to use non-NULL channel bindings automatically? > >The most simplistic solution is to permit non-NULL channel bindings in >the specification, and leave everything up to application protocols. > >However, that approach require application protocol implementations to >tell the SASL library what GSSAPI channel bindings it wants. While >this is feasible, perhaps it can be made even better. > >What I'm trying to understand, is whether the SASL GSSAPI mechanism, >by itself, could construct the actual channel binding, and use it at >both ends. > CMU SASL API allows applications to pass IP/port number of the both endpoints to the SASL library. It seems that this is sufficient to construct proper channel binding information? (Just thinking aloud). Also, if either the client or the server end uses non null channel binding and the other end doesn't, will they be able to authenticate? >(Some application might want to provide the channel binding data >themselves, so the above should only be a possible default behaviour, >in order to bind SASL GSSAPI authentication to a specific channel.) > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RKN0YI028938; Tue, 27 Jul 2004 13:23:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RKN0kB028937; Tue, 27 Jul 2004 13:23:00 -0700 (PDT) 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 i6RKMvnU028909 for ; Tue, 27 Jul 2004 13:22:57 -0700 (PDT) (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 i6RKMuJ6025774 for ; Tue, 27 Jul 2004 13:22:56 -0700 (PDT) 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 i6RKMt4H002427 for ; Tue, 27 Jul 2004 14:22:56 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RKKTSW025770; Tue, 27 Jul 2004 15:20:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RKKSIY025769; Tue, 27 Jul 2004 15:20:28 -0500 (CDT) Date: Tue, 27 Jul 2004 15:20:28 -0500 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040727202028.GW815@binky.central.sun.com> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 08:54:01PM +0200, Simon Josefsson wrote: > > Nicolas Williams writes: > > ... > > As you can see, there's a lot of activity around this topic. > > Thanks for this useful overview of activities. NP. [...] > > The SASL handling of GSS-API mechanisms does need some tweaking, both, > > in light of the above and to provide for re-keying (GSS-API contexts can > > expire, after all) by reestablishing GSS security contexts for the > > principals involved. > > Do you have any thoughts on how to modify the SASL GSSAPI mechanism so > it is possible for it to use non-NULL channel bindings automatically? See the CCM I-D in the NFSv4 WG and my personal I-D on stackable GSS pseudo-mechanisms, which is due to be a WG I-D for KITTEN, if the KITTEN BoF (which will meet this Monday) succeeds. The short answer is that by negotiating the use of CCM-BIND apps also negotiate the use of channel bindings. CCM-BIND is a stackable pseudo-mechanism which is primarily intended for these two purposes: - properly implement channel bindings the (the krb5 and spkm mechs don't) - indicate, in mechanism negotiations, the willingness to use channe bindings Applications shouldn't offer or accept CCM mechanisms in their negotiations if they have no useful channel to bind to. The flip side is that apps SHOULD offer and/or accept CCM mechanisms in their negotiations if they do have such channels and bindings and want to use channel bindings. > The most simplistic solution is to permit non-NULL channel bindings in > the specification, and leave everything up to application protocols. See above. This could work, but, the incomplete channel bindings support in the Kerberos V and SPKM GSS mechanisms, and the additional complexity for application protocols argues for the approach I offer instead, namely to leverage existing mechanism negotiations in application protocols to negotiate the use of channel bindings by using mechanism OIDs which indicate the desire to do so. > However, that approach require application protocol implementations to > tell the SASL library what GSSAPI channel bindings it wants. While > this is feasible, perhaps it can be made even better. And requires changes to the application protocol to properly negotiate the use of channel bindings. The approach I offer does not. > What I'm trying to understand, is whether the SASL GSSAPI mechanism, > by itself, could construct the actual channel binding, and use it at > both ends. No, it cannot, but I have an I-D, which did not make the cutoff for new I-Ds which specifies channel bindings constructor interfaces that make this task easy for application developers. > (Some application might want to provide the channel binding data > themselves, so the above should only be a possible default behaviour, > in order to bind SASL GSSAPI authentication to a specific channel.) Of course. 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 i6RIsDWT007299; Tue, 27 Jul 2004 11:54:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RIsDAo007298; Tue, 27 Jul 2004 11:54:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIs594007257 for ; Tue, 27 Jul 2004 11:54:10 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BpX5Q-0004Am-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Jul 2004 20:54:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: GSS-API channel bindings Date: Tue, 27 Jul 2004 20:54:01 +0200 Lines: 42 Message-ID: References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> <20040715182807.GZ632478@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:8lfckb0bwOCEgjYbavs0poCWWNE= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams writes: ... > As you can see, there's a lot of activity around this topic. Thanks for this useful overview of activities. >> I understand that the simplest "solution", from the SASL mechanism >> point of view, might simply be to consider GSS-API mechanisms, that >> doesn't link gss_wrap/gss_get_mic tokens with one specific >> authentication, as broken. However, channel bindings are provided by >> GSS-API to enable applications to close this hole, hence these GSS-API >> mechanisms can probably not be viewed as broken in general. So it is >> unfortunate that the SASL wrapping of GSS-API forbid channel bindings. >> I'd say this warrant a paragraph in the security section, unless the >> text about channel bindings is loosened up. > > The SASL handling of GSS-API mechanisms does need some tweaking, both, > in light of the above and to provide for re-keying (GSS-API contexts can > expire, after all) by reestablishing GSS security contexts for the > principals involved. Do you have any thoughts on how to modify the SASL GSSAPI mechanism so it is possible for it to use non-NULL channel bindings automatically? The most simplistic solution is to permit non-NULL channel bindings in the specification, and leave everything up to application protocols. However, that approach require application protocol implementations to tell the SASL library what GSSAPI channel bindings it wants. While this is feasible, perhaps it can be made even better. What I'm trying to understand, is whether the SASL GSSAPI mechanism, by itself, could construct the actual channel binding, and use it at both ends. (Some application might want to provide the channel binding data themselves, so the above should only be a possible default behaviour, in order to bind SASL GSSAPI authentication to a specific channel.) 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 i6RIMfdS099614; Tue, 27 Jul 2004 11:22:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RIMfJJ099613; Tue, 27 Jul 2004 11:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RIMdc9099554 for ; Tue, 27 Jul 2004 11:22:40 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i6RIMNs9003667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jul 2004 14:22:26 -0400 (EDT) Message-ID: <41069D5E.9010403@columbia.edu> Date: Tue, 27 Jul 2004 14:22:22 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: Kerberos WG , SASL WG , security-wg@ggf.org, nfsv4@ietf.org, saag@mit.edu Subject: Kitten (Common Authentication Technologies - Next Generation) at IETF 60 X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Common Authentication Technologies Next Generation (Kitten) BOF will be meeting at IETF 60: 1530-1730 Afternoon Sessions II Grande B SEC kitten Kitten (Daughter of CAT) BOF The agenda of the meeting is as follows: _ Kitten BOF Agenda for IETF 60_ * Introduction and Welcome [5 minutes] - Jeffrey Altman * Discussion of the Global Grid Forum GSS requirements [15 minutes] - Doug Engert * Discussion of channel bindings portability issues (C struct et all) [10 minutes] - Sam Hartman * Discussion of GSSAPI naming [15 minutes] - Sam Hartman * Discussion of need for cryptographic channel bindings and CCM [10 minutes] - Nicolas Williams * Discussion of Stackable Psuedo Mechanisms [10 minutes] - Nicolas Williams * Discussion of the SPNEGO issues [10 minutes] - Wyllys Ingersol * Discussion of the C# Bindings for GSSAPI [10 minutes] - Microsoft * Charter discussion [15 minutes] - Jeffrey Altman An introduction to the purpose of the Kitten Working Group and a proposed charter may be found at: http://www.ietf.org/ietf/04aug/kitten.txt We encourage anyone interested in the future of GSSAPI (applications which use GSSAPI or mechanisms implementing GSSAPI); those concerned with authenticated name portability; and those participating in the Cryptographic Channel Bindings work to attend this BOF and participate in the discussions. For the most part the Kitten participants have identified problem areas; have presented some potential incomplete solutions; and there is much work to be done. I hope to see you there. Jeffrey Altman Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFpIGJ065417; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RFpI1d065415; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFpI7G065394 for ; Tue, 27 Jul 2004 08:51:18 -0700 (PDT) (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 i6RFpG0R014432 for ; Tue, 27 Jul 2004 08:51:16 -0700 (PDT) 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 i6RFpC4F009355 for ; Tue, 27 Jul 2004 09:51:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RFmlTM025329; Tue, 27 Jul 2004 10:48:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RFmkRW025328; Tue, 27 Jul 2004 10:48:46 -0500 (CDT) Date: Tue, 27 Jul 2004 10:48:46 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040727154846.GM826@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> <41066B90.9030203@isode.com> <20040727152901.GQ815@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040727152901.GQ815@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 10:29:01AM -0500, Nicolas Williams wrote: > But new ones could. It's not at all clear to me that SMTP/SUBMIT don't > support re-authentication, for example. I'm not sure whether this WG > can clarify that, but it can clarify that _new_ application protocols > that use SASL must support re-authentication, and thus re-keying. Actually, rfc2554 is quite clear that it is not possible to re-authenticate in the SMTP/SUBMIT protocols. This is unfortunate. 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 i6RFVXGK061138; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RFVXlX061137; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) 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 i6RFVXmp061126 for ; Tue, 27 Jul 2004 08:31:33 -0700 (PDT) (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 i6RFVSJ6017706 for ; Tue, 27 Jul 2004 08:31:28 -0700 (PDT) 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 i6RFVS4F017836 for ; Tue, 27 Jul 2004 09:31:28 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6RFT26U025319; Tue, 27 Jul 2004 10:29:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6RFT1RL025318; Tue, 27 Jul 2004 10:29:01 -0500 (CDT) Date: Tue, 27 Jul 2004 10:29:01 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040727152901.GQ815@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> <41066B90.9030203@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41066B90.9030203@isode.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jul 27, 2004 at 03:49:52PM +0100, Alexey Melnikov wrote: > Nicolas Williams wrote: > > >On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > > > > > >>This message initiates a SASL Working Group Last Call on the > >>document: > >> > >>Title: > >>Simple Authentication and Security Layer (SASL) > >> > >>Editor: > >>A. Melnikov > >> > >>Filename: draft-ietf-sasl-rfc2222bis-08.txt > >> > > > >Your timing is convenient. I have recently come to realize that neither > >rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of > >security layers. Perhaps I'm missing something. > > > >It's also pretty clear to me that SASL mechanisms cannot re-key security > >layers without application involvement (at least if using any SASL APIs > >that require that the application use per-message/buffer security layer > >calls). > > > As a developer, I am not sure I agree. At least I can imagine how this > can be done automatically. What do you not agree with? The case described in the parenthetical expression above cannot have automatic re-keying without changing the existing APIs. We've been over this, with respect to the GSS-API, at either the old CAT WG list or at the KRB WG list a year or two ago. > >Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely > >address this by mentioning multiple authentications and replacing old > >security layers with new ones, which is, almost, exactly how I would > >expect SASL apps to re-key (see below). > > > No, reauthentication is not the same as re-keying. The client may choose > to reauthenticate as a different user, for example if the client is some > kind of a proxy. RFC2222 and rfc222bis are mighty clear that re-authentication that negotiates new security layers leads to replacement of the old layers with the new ones. Re-authenticate the same identities while negotiating new layers and you've got re-keying. IPsec w/ IKEv1 handles re-keying by establishing brand new SAs (for the same IDs). ONC RPC w/ RPCSEC_GSS (and, therefore, NFS) handles re-keying the same way, namely, by establishing new GSS-API security contexts (for the same names). (This is actually very implicit, rather than explicit, in the RPCSEC_GSS spec; what happens is that a GSS sec. context is needed only for the life of an actual RPC, but RPC apps, like NFS, typically make many RPCs and authorize peers on each call by inspecting the peer's GSS name. Today I would want the spec to be explicit about re-keying. This is, in fact, my attitude to SASL and re-keying.) IPsec w/ IKEv2 can re-key IKE_SAs during their lifetime, but if those expire it reverts to IPsec w/ IKEv1 re-keying behaviour. SSHv2 supports true re-keying, rather than re-keying by re-authentication. But if you use the GSS-API-protected SSHv2 key exchange to re-key SSHv2 connections then you also re-authenticate. I think there's a well established tradition of re-keying by re-authenticating the same identities where possible. > >I propose the following changes to rfc2222bis: > > > >- Explicitly state that there is no security layer re-keying facility. > > > Yes. But I would like to add instead that "there is no generic security > layer re-keying facility", as each SASL mechanism that support a > security layer is free to implement own re-keying. See my note above; some SASL APIs will require changes to support re-keying with such mechanisms. I'm pretty sure that the Cyrus SASL API would, for example. And existing SASL mechanisms do not support re-keying, leaving us with re-keying-by-re-authenticating as the only simple alternative, an alternative for which there is a fine tradition. > >- Add security considerations text about security layer expiration due > > to passage of time, use of cryptographic material, administrative > > policies (e.g., credentials expiration). > > > > Consider the text of draft-ietf-secsh-newmodes, for example; the > > details of layer expiration typically will vary by SASL mechanism, > > but the underlying rationales (e.g., defense against cryptanalysis) > > should hold across the board. > > > I would appreciate if you can send some text to me. Generic text for rfc2222bis? I can do that. > > > >- Add a requirement that SASL mechanisms provide indications of > > security layer expiration to applications. > > > We can't make this a requirement, as support for a security layer is an > optional feature of SASL framework. > But we can make this as a recommendation. Nonsense. You can make this mandatory, for new and revised mechanisms, where security layer support is available. The SASL GSS mechanisms can provide this today, since the GSS-API provides for context expiration. And note that infinite and, possibly, unspecified security layer lifetimes should be legitimate values for security layer expiration. > >Security layer expiration > > should probably have advisory and mandatory modes (advisory primarily > > for applications that lack support for re-negotiating security > > layers). > > > >- Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, > > LDAP) specify how to replace old SASL security layers with new ones. > > > This wouldn't be possible, as not all protocols support reauthentication. But new ones could. It's not at all clear to me that SMTP/SUBMIT don't support re-authentication, for example. I'm not sure whether this WG can clarify that, but it can clarify that _new_ application protocols that use SASL must support re-authentication, and thus re-keying. We can go back and update the application protocol specs where lack of re-authentication/re-keying hurts -- later. First we need rfc2222bis to say something about the matter. > >- If section 6.3 was meant for any purpose other than re-keying then > > please clarify it. For example, if an application authenticates as > > one identity, then switches to another and re-authenticates, > > > Yes. > > > presumably it should not act (or be allowed to, by its peer) on > > behalf of the first identity while using the second security layer, > > at least for some mechanisms. > > > > > Can you suggest some text? No, I cannot. This WG should discuss and come up with this clarification. I can send you text on re-keying, but perhaps we should see where the WG looks to be heading on that matter. 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 i6REnsVl051395; Tue, 27 Jul 2004 07:49:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6REns94051394; Tue, 27 Jul 2004 07:49:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REnrVb051387 for ; Tue, 27 Jul 2004 07:49:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 27 Jul 2004 15:53:20 +0100 Message-ID: <41066B90.9030203@isode.com> Date: Tue, 27 Jul 2004 15:49:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> In-Reply-To: <20040721214621.GX815@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams wrote: >On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > > >>This message initiates a SASL Working Group Last Call on the >>document: >> >>Title: >>Simple Authentication and Security Layer (SASL) >> >>Editor: >>A. Melnikov >> >>Filename: draft-ietf-sasl-rfc2222bis-08.txt >> > >Your timing is convenient. I have recently come to realize that neither >rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of >security layers. Perhaps I'm missing something. > >It's also pretty clear to me that SASL mechanisms cannot re-key security >layers without application involvement (at least if using any SASL APIs >that require that the application use per-message/buffer security layer >calls). > As a developer, I am not sure I agree. At least I can imagine how this can be done automatically. >Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely >address this by mentioning multiple authentications and replacing old >security layers with new ones, which is, almost, exactly how I would >expect SASL apps to re-key (see below). > No, reauthentication is not the same as re-keying. The client may choose to reauthenticate as a different user, for example if the client is some kind of a proxy. >I propose the following changes to rfc2222bis: > > - Explicitly state that there is no security layer re-keying facility. > Yes. But I would like to add instead that "there is no generic security layer re-keying facility", as each SASL mechanism that support a security layer is free to implement own re-keying. > (Alternatively design such a facility and add it to rfc2222bis; I > don't like this alternative myself, mostly because it would require > updating all the SASL mechanisms to specify re-keying and because > either way the application must be involved in the re-keying process, > so this alternative buys us nothing.) > I don't like this either, for the same reasons. > > If re-keying be done by re-authenticating and negotiating new > security layers (as in section 6.3 of rfc2222bis) then presumably the > authenticated identities should remain the same(!). > > - Add security considerations text about security layer expiration due > to passage of time, use of cryptographic material, administrative > policies (e.g., credentials expiration). > > Consider the text of draft-ietf-secsh-newmodes, for example; the > details of layer expiration typically will vary by SASL mechanism, > but the underlying rationales (e.g., defense against cryptanalysis) > should hold across the board. > I would appreciate if you can send some text to me. > > - Add a requirement that SASL mechanisms provide indications of > security layer expiration to applications. > We can't make this a requirement, as support for a security layer is an optional feature of SASL framework. But we can make this as a recommendation. >Security layer expiration > should probably have advisory and mandatory modes (advisory primarily > for applications that lack support for re-negotiating security > layers). > > - Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, > LDAP) specify how to replace old SASL security layers with new ones. > This wouldn't be possible, as not all protocols support reauthentication. > - If section 6.3 was meant for any purpose other than re-keying then > please clarify it. For example, if an application authenticates as > one identity, then switches to another and re-authenticates, > Yes. > presumably it should not act (or be allowed to, by its peer) on > behalf of the first identity while using the second security layer, > at least for some mechanisms. > > Can you suggest some text? >Additionally, where IETF documents specify application protocol use of >SASL it would be nice to have clarifications/extensions for >re-negotiation of SASL security layers -- that is, re-keying. > >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 i6REgf3C049825; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6REgfEA049824; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6REgfq1049818 for ; Tue, 27 Jul 2004 07:42:41 -0700 (PDT) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i6REgfCB018968 for ; Tue, 27 Jul 2004 07:42:41 -0700 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i6REged28712 for ; Tue, 27 Jul 2004 07:42:40 -0700 (PDT) Message-Id: <200407271442.i6REged28712@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Liberty SASL-based Authn over SOAP To: ietf-sasl@imc.org From: Jeff.Hodges@KingsMountain.com Reply-to: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jul 2004 07:42:40 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Of possible interest... Liberty ID-WSF Authentication Service Specification http://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.0.pdf Abstract: This specification defines an ID-WSF Authentication Protocol based on a profile of the Simple Authentication and Security Layer (SASL) framework mapped onto ID-* SOAP-bound messages. Next, it defines an ID-WSF Authentication Service Identity Providers may offer, which is based on the authentication protocol. This authentication service enables Web Services Consumers and/or Liberty-enabled User Agents or Devices to authenticate with Identity Providers using various authentication mechanisms and obtain ID-WSF security tokens. Finally, it defines an ID-WSF Single Sign-On Service. This service provides authentication assertions to Web Service Consumers via a profile of the ID-FF Single Sign-On Protocol, enabling Web Service Consumers to interact with ID-FF-based Service Providers. [ID-WSF = "Identity Web Services Framework" ID-FF = "Identity Federation Framework"] Likely helpful... Liberty Glossary, Version 1.3 http://www.projectliberty.org/specs/liberty-glossary-v1.3.pdf Thanks to Alexey for his review in the process of writing this spec. Other specs that the ID-WSF Authn Svc spec depends upon, or is related to (e.g. ID-FF specs) are available at [1]. If folks have any questions about these specs, or Liberty, feel free to drop me a line. thanks, JeffH [1] Liberty Alliance Project - Spec repository http://www.projectliberty.org/specs/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q8OPPh072340; Mon, 26 Jul 2004 01:24:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q8OPF2072339; Mon, 26 Jul 2004 01:24:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (illegal-drugs.naming-schemes.org [67.65.18.113]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q8OOnk072328 for ; Mon, 26 Jul 2004 01:24:24 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 2FD7DE004C; Mon, 26 Jul 2004 04:24:28 -0400 (EDT) To: ietf-sasl@imc.org Subject: [Sam Hartman] Agenda for SASL at IETF 60 From: Sam Hartman Date: Mon, 26 Jul 2004 04:24:28 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-=-= I'm sorry this hasn't been reviewed here. Kurt, Alexey and I were discussing a proposed agenda and I realized that later today is the deadline for submitting the agenda. Naturally if the consensus of the working group is that we need to discuss something else, we will do so. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 26 Jul 2004 04:22:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by suchdamage.org (Postfix) with ESMTP id 25C0313230 for ; Mon, 26 Jul 2004 04:22:42 -0400 (EDT) Received: from cz.mit.edu (illegal-drugs.naming-schemes.org [67.65.18.113]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i6Q8MagH014036 for ; Mon, 26 Jul 2004 04:22:37 -0400 (EDT) Received: by cz.mit.edu (Postfix, from userid 8042) id 054BFE004C; Mon, 26 Jul 2004 04:22:40 -0400 (EDT) To: kurt@openldap.org, hartmans@mit.edu, agenda@ietf.org Subject: Agenda for SASL at IETF 60 Message-Id: <20040726082240.054BFE004C@cz.mit.edu> Date: Mon, 26 Jul 2004 04:22:40 -0400 (EDT) From: hartmans@MIT.EDU (Sam Hartman) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: MIME-Version: 1.0 Simple AUthentication and Security Layer (SASL) Tuesday, AUgust 3, 2004 1300-1400 =============================================== Agenda: Introductions and Agenda Bashing - chairs (5 minutes) Review of SASL Base last call - Chairs/Alexey (10 minutes) Digest md5 (draft--ietf-sasl-rfc2831bis) - Alexey (15 minutes) GSSAPI (draft-ietf-sasl-gssapi) - Alexey (15 minutes) Cram-md5 (draft-ietf-sasl-crammd5) - (15 minutes) Open mic - (remaining time) --=-=-=-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PMbOap066831; Sun, 25 Jul 2004 15:37:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PMbOmD066830; Sun, 25 Jul 2004 15:37:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PMbM9l066823 for ; Sun, 25 Jul 2004 15:37:23 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust157.tnt103.lnd4.gbr.da.uu.net [213.116.54.157]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 25 Jul 2004 23:38:11 +0100 Message-ID: <4104263B.2000707@isode.com> Date: Sun, 25 Jul 2004 22:29:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: GSSAPI direction References: <20040721163835.96C90E0052@cz.mit.edu> In-Reply-To: <20040721163835.96C90E0052@cz.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: >[This message and for the most part any of my participation in GSSAPI >discussions are in the role of a participant not as a WG chair.] > >I'd like to start a discussion about what direction we want to take >with the GSSAPI work. Our charter requires that the work needs to be >based on the existing draft. We probably need to at least document >the behavior of the GSSAPI (kerberos 5) sasl mechanism. > > I agree. >However the current GSSAPI protocol seems to be fairly inefficient. >It requires an extra round trip to negotiate the security layers; it >does not piggyback this negotiation on the last token. The mechanism >will not take advantage of the prot_ready flag to remove a half round >trip. > >I think the GSSAPI sasl mechanism need to be as efficient as we can >make them. There are two primary motivations for this. First, I'd >like to see GSSAPI HTTP be reasonably fast. Second, I'd like to >remove any excuses we can for designing SASL mechanisms instead of >GSSAPI mechanisms. Redundancy in security protocols is undesirable. > >Note that if we do change the gssapi draft in an incompatible manner, > > I don't mind the changes you are proposing (at least I agree with their motivation), however this suggestion is a bit late and I would like to point out that there several independent implementations of GSSAPI (Kerberos) mechanism that interoperate well (at least better than DIGEST-MD5). I am afraid that it is not possible to reduce existing 2 round trips in a backward compatible manner. I would be glad if you can prove me wrong. So, if the WG wants to tackle the issue that you've described above, I would suggest that the WG publishes the existing GSSAPI draft as GSSAPI Kerberos-only and designs a new GSSAPIv2 (which works for all GSSAPI mechanisms) in a separate draft. >we would need to change the prefix of the sasl mechanism names. Note >also that changing the gssapi mechanism is more reasonable than the >other mechanisms; so far the gssapi mechanism is only an internet >draft. There is a description of GSSAPI in RFC 2222 but we're already >going to end up being incompatible with that description for >everything besides Kerberos. > Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJoFXm047456; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MJoF1d047455; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJoEP4047447 for ; Thu, 22 Jul 2004 12:50:15 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21425; Thu, 22 Jul 2004 15:50:17 -0400 (EDT) Message-Id: <200407221950.PAA21425@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-10.txt Date: Thu, 22 Jul 2004 15:50:16 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-10.txt Pages : 7 Date : 2004-7-22 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-10.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-saslprep-10.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-saslprep-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145714.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFihdF027356; Thu, 22 Jul 2004 08:44:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MFihXU027355; Thu, 22 Jul 2004 08:44:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-EIGHTY-TWO.MIT.EDU [18.187.6.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFig6M027349 for ; Thu, 22 Jul 2004 08:44:42 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id CBEA6E0052; Thu, 22 Jul 2004 11:44:58 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> <20040721214621.GX815@binky.central.sun.com> From: Sam Hartman Date: Thu, 22 Jul 2004 11:44:58 -0400 In-Reply-To: <20040721214621.GX815@binky.central.sun.com> (Nicolas Williams's message of "Wed, 21 Jul 2004 16:46:21 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> - Add security considerations text about security layer Nicolas> expiration due to passage of time, use of cryptographic Nicolas> material, administrative policies (e.g., credentials Nicolas> expiration). Nicolas> Consider the text of draft-ietf-secsh-newmodes, for Nicolas> example; the details of layer expiration typically will Nicolas> vary by SASL mechanism, but the underlying rationales Nicolas> (e.g., defense against cryptanalysis) should hold across Nicolas> the board. Nico has a point. The security ADs seem to care a fair bit about key reuse. Given that the issue has been brought up, I'd expect a discuss if we don't at least address it in security considerations. At a minimum we need to discuss the fact that security layers can exceed their key lifetimes and give guidance to application designers. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LLmbGJ033471; Wed, 21 Jul 2004 14:48:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LLmbva033470; Wed, 21 Jul 2004 14:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LLmafn033464 for ; Wed, 21 Jul 2004 14:48:36 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6LLkS53000577 for ; Wed, 21 Jul 2004 15:46:28 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i6LLme8X018683 for ; Wed, 21 Jul 2004 15:48:40 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i6LLkLRj005246; Wed, 21 Jul 2004 16:46:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i6LLkLPc005245; Wed, 21 Jul 2004 16:46:21 -0500 (CDT) Date: Wed, 21 Jul 2004 16:46:21 -0500 From: Nicolas Williams To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] Message-ID: <20040721214621.GX815@binky.central.sun.com> Mail-Followup-To: "Kurt D. Zeilenga" , ietf-sasl@imc.org References: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote: > This message initiates a SASL Working Group Last Call on the > document: > > Title: > Simple Authentication and Security Layer (SASL) > > Editor: > A. Melnikov > > Filename: draft-ietf-sasl-rfc2222bis-08.txt Your timing is convenient. I have recently come to realize that neither rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of security layers. Perhaps I'm missing something. It's also pretty clear to me that SASL mechanisms cannot re-key security layers without application involvement (at least if using any SASL APIs that require that the application use per-message/buffer security layer calls). Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely address this by mentioning multiple authentications and replacing old security layers with new ones, which is, almost, exactly how I would expect SASL apps to re-key (see below). I propose the following changes to rfc2222bis: - Explicitly state that there is no security layer re-keying facility. (Alternatively design such a facility and add it to rfc2222bis; I don't like this alternative myself, mostly because it would require updating all the SASL mechanisms to specify re-keying and because either way the application must be involved in the re-keying process, so this alternative buys us nothing.) If re-keying be done by re-authenticating and negotiating new security layers (as in section 6.3 of rfc2222bis) then presumably the authenticated identities should remain the same(!). - Add security considerations text about security layer expiration due to passage of time, use of cryptographic material, administrative policies (e.g., credentials expiration). Consider the text of draft-ietf-secsh-newmodes, for example; the details of layer expiration typically will vary by SASL mechanism, but the underlying rationales (e.g., defense against cryptanalysis) should hold across the board. - Add a requirement that SASL mechanisms provide indications of security layer expiration to applications. Security layer expiration should probably have advisory and mandatory modes (advisory primarily for applications that lack support for re-negotiating security layers). - Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT, LDAP) specify how to replace old SASL security layers with new ones. - If section 6.3 was meant for any purpose other than re-keying then please clarify it. For example, if an application authenticates as one identity, then switches to another and re-authenticates, presumably it should not act (or be allowed to, by its peer) on behalf of the first identity while using the second security layer, at least for some mechanisms. Additionally, where IETF documents specify application protocol use of SASL it would be nice to have clarifications/extensions for re-negotiation of SASL security layers -- that is, re-keying. 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 i6LKA6e1022647; Wed, 21 Jul 2004 13:10:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LKA63s022646; Wed, 21 Jul 2004 13:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LKA5bO022640 for ; Wed, 21 Jul 2004 13:10:05 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i6LKAAv4010593 for ; Wed, 21 Jul 2004 20:10:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040721130918.04ea1370@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 21 Jul 2004 13:10:30 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected] 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: [with correct Last Call close date --Kdz] This message initiates a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. If after completing your review you find no issues, please indicate so to the chairs. The Last Call period will close on Friday, 13 August 2004. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! Kurt Zeilenga, SASL WG co-chair Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LK8KFV022485; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LK8KSS022484; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LK8KvT022473 for ; Wed, 21 Jul 2004 13:08:20 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i6LK8Lv4010578 for ; Wed, 21 Jul 2004 20:08:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040721130411.04e7dbb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 21 Jul 2004 13:08:42 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt 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: This message initiates a SASL Working Group Last Call on the document: Title: Simple Authentication and Security Layer (SASL) Editor: A. Melnikov Filename: draft-ietf-sasl-rfc2222bis-08.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. If after completing your review you find no issues, please indicate so to the chairs. The Last Call period will close on Friday, 13 September 2003. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! Kurt Zeilenga, SASL WG co-chair Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGcJmN002832; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LGcJPM002831; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-TWO-EIGHTY-TWO.MIT.EDU [18.187.6.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGcIm5002825 for ; Wed, 21 Jul 2004 09:38:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 96C90E0052; Wed, 21 Jul 2004 12:38:35 -0400 (EDT) To: ietf-sasl@imc.org Subject: GSSAPI direction Message-Id: <20040721163835.96C90E0052@cz.mit.edu> Date: Wed, 21 Jul 2004 12:38:35 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [This message and for the most part any of my participation in GSSAPI discussions are in the role of a participant not as a WG chair.] I'd like to start a discussion about what direction we want to take with the GSSAPI work. Our charter requires that the work needs to be based on the existing draft. We probably need to at least document the behavior of the GSSAPI (kerberos 5) sasl mechanism. However the current GSSAPI protocol seems to be fairly inefficient. It requires an extra round trip to negotiate the security layers; it does not piggyback this negotiation on the last token. The mechanism will not take advantage of the prot_ready flag to remove a half round trip. I think the GSSAPI sasl mechanism need to be as efficient as we can make them. There are two primary motivations for this. First, I'd like to see GSSAPI HTTP be reasonably fast. Second, I'd like to remove any excuses we can for designing SASL mechanisms instead of GSSAPI mechanisms. Redundancy in security protocols is undesirable. Note that if we do change the gssapi draft in an incompatible manner, we would need to change the prefix of the sasl mechanism names. Note also that changing the gssapi mechanism is more reasonable than the other mechanisms; so far the gssapi mechanism is only an internet draft. There is a description of GSSAPI in RFC 2222 but we're already going to end up being incompatible with that description for everything besides Kerberos. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LCh28V078250; Wed, 21 Jul 2004 05:43:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LCh2NO078249; Wed, 21 Jul 2004 05:43:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from komp67.org (yn250.internetdsl.tpnet.pl [80.55.247.250]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6LCh0BR078234 for ; Wed, 21 Jul 2004 05:43:01 -0700 (PDT) (envelope-from jgmyers@netscape.com) Date: Wed, 21 Jul 2004 14:43:00 +0100 To: "Ietf-sasl" From: "Jgmyers" Subject: Protected message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ouyenmooiqtdcfbsrzwy" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------ouyenmooiqtdcfbsrzwy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached file tells everything.


----------ouyenmooiqtdcfbsrzwy Content-Type: application/octet-stream; name="text_document.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="text_document.scr" ----------ouyenmooiqtdcfbsrzwy-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L01rNW005358; Tue, 20 Jul 2004 17:01:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L01rt8005357; Tue, 20 Jul 2004 17:01:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from PC_hipolito.com (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L01pt2005351 for ; Tue, 20 Jul 2004 17:01:52 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Tue, 20 Jul 2004 19:02:03 -0500 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------majkqzkcezrdrjmmzrse" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------majkqzkcezrdrjmmzrse Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Lovely animals


----------majkqzkcezrdrjmmzrse Content-Type: application/octet-stream; name="Dog.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Dog.scr" ----------majkqzkcezrdrjmmzrse-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDgd5g067734; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GDgdrd067733; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDgcFw067726 for ; Fri, 16 Jul 2004 06:42:39 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 16 Jul 2004 14:44:48 +0100 Message-ID: <40F7DB35.4000502@isode.com> Date: Fri, 16 Jul 2004 14:42:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Lyndon Nerenberg CC: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: in CRAM-MD5 References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> In-Reply-To: <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote: > --On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" > wrote: > >>> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" >>> ; a bracketed string of printing characters, not >>> ; containing embedded "<" or ">" >>> >>> and modify the text to emphasize the importance of generating unique >>> challenges, making reference to the historical behaviour. >> >> Seems reasonable to me. > I am glad about this change, I've been advocating something similar before. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FIVYFN089623; Thu, 15 Jul 2004 11:31:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FIVYRr089622; Thu, 15 Jul 2004 11:31:34 -0700 (PDT) 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 i6FIVVfF089598 for ; Thu, 15 Jul 2004 11:31:31 -0700 (PDT) (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 i6FIVHJ6002650; Thu, 15 Jul 2004 11:31:17 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i6FIV18X024824; Thu, 15 Jul 2004 12:31:01 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i6FIS7ZJ646312; Thu, 15 Jul 2004 13:28:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i6FIS7qs646311; Thu, 15 Jul 2004 13:28:07 -0500 (CDT) Date: Thu, 15 Jul 2004 13:28:07 -0500 From: Nicolas Williams To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: GSS-API channel bindings Message-ID: <20040715182807.GZ632478@binky.central.sun.com> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jul 05, 2004 at 09:51:09AM +0200, Simon Josefsson wrote: > > There is a requirement that the GSS-API channel bindings are NULL. > I'd feel more comfortable if there was a way to somehow make use of > channel bindings, to link the authentication to the specific channel. > Does anyone have ideas on whether to add this, and if the answer is > positive, how it might be done? 1. Existing GSS-API mechanisms fail to correctly deal with channel bindings. E.g., SPKM is way underspaecified in general, and here specifically; also, the Kerberos V mechanism does not have a way for the acceptor to prove to the initiator that it too has the same channel bindings as the initiator. 2. We're trying to address this through a stackable pseudo-mechanism (CCM-BIND) one of whose purposes is to address this problem. See: draft-ietf-nfsv4-ccm-03.txt 3. The whole subject of channel bindings needs further specification. I'm about to submit a new version of draft-ietf-nfsv4-channel-bindings (-01.txt) that does this and which describes what goes into the channel bindings for SSHv2, TLS and IPsec channels, and then I'll submit draft-williams-gssapi-channel-bindings-00.txt for the KITTEN BoF (and, hopefully, WG), which fills in the details of how to use channel bindings to SSHv2, TLS and IPsec channels with the GSS-API. The deadline for filing new I-Ds has passed though, so this won't get posted to the I-D repository until after this meeting. 4. Given CCM-BIND and the two other drafts it should be possible to use SASL with GSS-API channel bindings; SASL APIs will have to be modified so the application can provide the necessary channel information. 5. I have proposed a set of interfaces for determining the features of GSS mechs, as part of a framework for stackable pseudo-mechanisms, which should help GSS apps avoid having to hardcode mechanism OIDs and information about them (e.g., "channel bindings work well with this mechanism, but not with that one"). See: draft-williams-gssapi-stackable-pseudo-mechs-00.txt As you can see, there's a lot of activity around this topic. > I understand that the simplest "solution", from the SASL mechanism > point of view, might simply be to consider GSS-API mechanisms, that > doesn't link gss_wrap/gss_get_mic tokens with one specific > authentication, as broken. However, channel bindings are provided by > GSS-API to enable applications to close this hole, hence these GSS-API > mechanisms can probably not be viewed as broken in general. So it is > unfortunate that the SASL wrapping of GSS-API forbid channel bindings. > I'd say this warrant a paragraph in the security section, unless the > text about channel bindings is loosened up. The SASL handling of GSS-API mechanisms does need some tweaking, both, in light of the above and to provide for re-keying (GSS-API contexts can expire, after all) by reestablishing GSS security contexts for the principals involved. 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 i6FHMKi2077364; Thu, 15 Jul 2004 10:22:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FHMKph077363; Thu, 15 Jul 2004 10:22:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHMIQh077356 for ; Thu, 15 Jul 2004 10:22:19 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 15 Jul 2004 18:24:44 +0100 Message-ID: <40F6BD45.302@isode.com> Date: Thu, 15 Jul 2004 18:22:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nkb CC: ietf-sasl@imc.org Subject: Re: Beginner question: can we use SASL over HTTP? References: <40F668B2.6080801@pacific.net.sg> In-Reply-To: <40F668B2.6080801@pacific.net.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: nkb wrote: > Hi. > I'm new to this list. Pardon me if this question is ignorant. > > I would like to access webpages (e.g. myhome.aspx) that require some > form of authentication, s.a. the windows' NTLM authentication. I've > written most of the application codes. I'm stuck at not being able to > access pages that require authentication, specifically windows NTLM > authentication. Before I spend too much time reading into SASL, I was > wondering if this is the library that I could use to help me take care > of this NTLM authentication to access webpages? Thank you for any > pointers. The short answer is "no". A longer answer is: there is a draft that describes how to use SASL over HTTP, however it is not implemented by any known browser. If you have more questions on this, send me reply off the mailing list. Regards, Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FBLOrN016817; Thu, 15 Jul 2004 04:21:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FBLOiL016816; Thu, 15 Jul 2004 04:21:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.gold.ocn.ne.jp (gold.ocn.ne.jp [222.146.40.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FBLM1b016810 for ; Thu, 15 Jul 2004 04:21:23 -0700 (PDT) (envelope-from nkb@pacific.net.sg) Received: from [10.1.5.20] (pat.polyphony.co.jp [210.254.79.2]) by smtp.gold.ocn.ne.jp (Postfix) with ESMTP id 0A6952AB for ; Thu, 15 Jul 2004 20:21:23 +0900 (JST) Message-ID: <40F668B2.6080801@pacific.net.sg> Date: Thu, 15 Jul 2004 20:21:22 +0900 From: nkb User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Beginner question: can we use SASL over HTTP? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. I'm new to this list. Pardon me if this question is ignorant. I would like to access webpages (e.g. myhome.aspx) that require some form of authentication, s.a. the windows' NTLM authentication. I've written most of the application codes. I'm stuck at not being able to access pages that require authentication, specifically windows NTLM authentication. Before I spend too much time reading into SASL, I was wondering if this is the library that I could use to help me take care of this NTLM authentication to access webpages? Thank you for any pointers. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CJc7MW058213; Mon, 12 Jul 2004 12:38:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CJc7x8058212; Mon, 12 Jul 2004 12:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CJc55C058198 for ; Mon, 12 Jul 2004 12:38:06 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05044; Mon, 12 Jul 2004 15:38:07 -0400 (EDT) Message-Id: <200407121938.PAA05044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-03.txt Date: Mon, 12 Jul 2004 15:38:07 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-03.txt Pages : 9 Date : 2004-7-12 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-12143512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-12143512.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LDF3F008303; Fri, 9 Jul 2004 14:13:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69LDFw7008302; Fri, 9 Jul 2004 14:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LD5JF008290 for ; Fri, 9 Jul 2004 14:13:14 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i69LD59O034589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2004 15:13:07 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 09 Jul 2004 14:13:00 -0700 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: Re: in CRAM-MD5 Message-ID: <2147483647.1089382380@d154-5-18-205.bchsia.telus.net> In-Reply-To: <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" wrote: >> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" >> ; a bracketed string of printing characters, not >> ; containing embedded "<" or ">" >> >> and modify the text to emphasize the importance of generating unique >> challenges, making reference to the historical behaviour. > > Seems reasonable to me. Excellent. I've sent version -03 of the draft off for publication. The major changes from -02 are: - reformatted and edited to put it into the style the RFC Editor prefers; - mods as described (explanitory text still to come); - new and updated examples from Simon. It would be useful if someone could contribute an ACAP example (or some other non-IMAP example, and which doesn't base64 encode parts of the exchange); - addressed *most* of Kurt's review comments from his March 10 message to the list. Still to be done: - Changes from RFC2195; - the Abstract and Introduction still need work; - text rational for : uniqueness property and historical behaviour (and probably a short paragraph under Security Considerations). --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JOtZ4099646; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69JOt26099645; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JOt4n099635 for ; Fri, 9 Jul 2004 12:24:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i69JOvv4016853; Fri, 9 Jul 2004 19:24:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040709122444.04ac1778@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Jul 2004 12:25:04 -0700 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: in CRAM-MD5 Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:40 PM 7/8/2004, Lyndon Nerenberg wrote: >--On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" wrote: > >>Why isn't RFC-822 msg-id production here as was done in RFC 2195? >>The production below is quite different than a msg-id (in some >>ways more restrictive and in other ways less restrictive). >> >>For compatibility with existing RFC 2195, I think this specification >>should simple incorporate (directly or by reference) the msg-id >>production previously used. > >There is a problem here. RFC2822 states: > > msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] > >If we reference 822 for , people are going to assume the 2822 definition replaces it. Suddenly we have these [CFWS] tokens muddying things up. > >The format for the challenge reflects directly on CRAM's birth in an email environment. Since email software already had to deal with generating unique message ids, re-using that code as a source for unique strings made sense at the time. But the important property of the challenge is that it be unique, not that it syntactically resemble a element. So relaxing the formatting requirement to simplify the grammar should be fine, provided the new production does not syntactically invalidate existing implementations. Therefore, I'm proposing that we change the syntax of the challenge to: > > challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" > ; a bracketed string of printing characters, not > ; containing embedded "<" or ">" > >and modify the text to emphasize the importance of generating unique challenges, making reference to the historical behaviour. Seems reasonable to me. 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 i691eg2X004846; Thu, 8 Jul 2004 18:40:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i691egn5004845; Thu, 8 Jul 2004 18:40:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691ef2g004838 for ; Thu, 8 Jul 2004 18:40:41 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i691ed9O029629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2004 19:40:42 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 08 Jul 2004 18:40:33 -0700 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" cc: ietf-sasl@imc.org Subject: in CRAM-MD5 Message-ID: <2147483647.1089312033@d154-5-18-205.bchsia.telus.net> In-Reply-To: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> References: <6.0.1.1.0.20040310231958.02c45708@127.0.0.1> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" wrote: > Why isn't RFC-822 msg-id production here as was done in RFC 2195? > The production below is quite different than a msg-id (in some > ways more restrictive and in other ways less restrictive). > > For compatibility with existing RFC 2195, I think this specification > should simple incorporate (directly or by reference) the msg-id > production previously used. There is a problem here. RFC2822 states: msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] If we reference 822 for , people are going to assume the 2822 definition replaces it. Suddenly we have these [CFWS] tokens muddying things up. The format for the challenge reflects directly on CRAM's birth in an email environment. Since email software already had to deal with generating unique message ids, re-using that code as a source for unique strings made sense at the time. But the important property of the challenge is that it be unique, not that it syntactically resemble a element. So relaxing the formatting requirement to simplify the grammar should be fine, provided the new production does not syntactically invalidate existing implementations. Therefore, I'm proposing that we change the syntax of the challenge to: challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">" ; a bracketed string of printing characters, not ; containing embedded "<" or ">" and modify the text to emphasize the importance of generating unique challenges, making reference to the historical behaviour. --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LTc9K061819; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67LTcOh061818; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LTbqF061812 for ; Wed, 7 Jul 2004 14:29:38 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 269B5E0051; Wed, 7 Jul 2004 17:29:40 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG Subject: Re: Final changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <40D7666B.7070001@isode.com> From: Sam Hartman Date: Wed, 07 Jul 2004 17:29:40 -0400 In-Reply-To: <40D7666B.7070001@isode.com> (Alexey Melnikov's message of "Mon, 21 Jun 2004 23:51:23 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Rob Siemborski wrote: >> On Fri, 21 May 2004, Sam Hartman wrote: >>> >> It seems we can handle this cleanly enough if we treat it >>> just >> like the initial response. >>> >>> But is it worth the complexity? IT seems that if we can avoid >>> the introduction of distinguishing the two cases we should do >>> so. >>> >>> >> If it is not worth the complexity (and, really, I can't think >> of any situation where an empty server success data would be >> *useful*-- it just seems that we'd be giving up some level of >> flexibility), then we should just forbid empty success data -- >> this would lead to the less confusion than attributing two >> potential meanings to "no success data". >> >> Alexey> Should I treat "forbid empty success data" as the WG Alexey> consensus on empty versa no data on success? I think so. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i657pPp3060777; Mon, 5 Jul 2004 00:51:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i657pP1W060776; Mon, 5 Jul 2004 00:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i657pKhs060747 for ; Mon, 5 Jul 2004 00:51:21 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BhOFt-0006W7-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2004 09:51:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: GSS-API channel bindings Date: Mon, 05 Jul 2004 09:51:09 +0200 Lines: 18 Message-ID: References: <40DC9563.4070006@isode.com> <40E1381F.4020409@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:K389zgfsMv5NEvcQ6x6g6U/wlfk= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is a requirement that the GSS-API channel bindings are NULL. I'd feel more comfortable if there was a way to somehow make use of channel bindings, to link the authentication to the specific channel. Does anyone have ideas on whether to add this, and if the answer is positive, how it might be done? I understand that the simplest "solution", from the SASL mechanism point of view, might simply be to consider GSS-API mechanisms, that doesn't link gss_wrap/gss_get_mic tokens with one specific authentication, as broken. However, channel bindings are provided by GSS-API to enable applications to close this hole, hence these GSS-API mechanisms can probably not be viewed as broken in general. So it is unfortunate that the SASL wrapping of GSS-API forbid channel bindings. I'd say this warrant a paragraph in the security section, unless the text about channel bindings is loosened up. Thanks, Simon