From canetti@post.tau.ac.il Wed Apr 1 02:19:11 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D972128C151 for ; Wed, 1 Apr 2009 02:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl4wf9pztFFw for ; Wed, 1 Apr 2009 02:19:11 -0700 (PDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id F245028C10A for ; Wed, 1 Apr 2009 02:19:10 -0700 (PDT) Received: from [132.67.110.213] (lap-canetti1.cs.tau.ac.il [132.67.110.213]) by doar.tau.ac.il (Postfix) with ESMTP id F09BCBEFB; Wed, 1 Apr 2009 12:20:08 +0300 (IDT) Message-ID: <49D331C6.7000407@post.tau.ac.il> Date: Wed, 01 Apr 2009 12:20:06 +0300 From: canetti User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: secdir@mit.edu, kitten@ietf.org, Ran Canetti Subject: Security review of draft-ietf-kitten-gssapi-channel-bindings-06 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 09:19:11 -0000 *I have reviewed this document as part of the security directorate's *ongoing effort to review all IETF documents being processed by the *IESG. These comments were written primarily for the benefit of the *security area directors. Document editors and WG chairs should treat *these comments just like any other last call comments. This is a very short document. It describes a more generic way of formatting the API for channel bindings. The move to a more generic format is welcome. One potential objection here, however, is to the requirement that compliant implementations MUST interpret the API as having the new format. This may have backwards compatibility issues, and for no apparent good reason. It might be better to specify the format so that an implementation will be able to take also older API formats. (Since this is not an interoperability or security-sensitive issue, there seems to be no reason for the IETF to MANDATE one way over another.) Best, Ran From jhutz@cmu.edu Wed Apr 1 07:14:21 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA9F3A6D5A for ; Wed, 1 Apr 2009 07:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQIqC3pJ517q for ; Wed, 1 Apr 2009 07:14:20 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 00B6C3A67E1 for ; Wed, 1 Apr 2009 07:14:19 -0700 (PDT) Received: from [192.168.1.108] (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n31EF75J015692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 10:15:08 -0400 (EDT) Date: Wed, 01 Apr 2009 10:15:08 -0400 From: Jeffrey Hutzelman To: canetti , secdir@mit.edu, kitten@ietf.org, Ran Canetti Subject: Re: [secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06 Message-ID: In-Reply-To: <200904010920.n319KOb5006961@mx03.srv.cs.cmu.edu> References: <200904010920.n319KOb5006961@mx03.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:14:21 -0000 --On Wednesday, April 01, 2009 12:20:06 PM +0300 canetti wrote: > > > > *I have reviewed this document as part of the security directorate's > *ongoing effort to review all IETF documents being processed by the > *IESG. These comments were written primarily for the benefit of the > *security area directors. Document editors and WG chairs should treat > *these comments just like any other last call comments. > > > This is a very short document. It describes a more generic way of > formatting the API for channel bindings. The move to a more generic > format is welcome. One potential objection here, however, is to the > requirement that compliant implementations MUST interpret the API as > having the new format. This may have backwards compatibility issues, and > for no apparent good reason. It might be better to specify the format so > that an implementation will be able to take also older API formats. > (Since this is not an interoperability or security-sensitive issue, there > seems to be no reason for the IETF to MANDATE one way over another.) Since it's the only one that applies to implementatios, I assume you're referring to the requirement that, when bindings of the GSS-API to a particular programming language model channel bindings as octet strings, the input be treated as corresponding only to the application-data portion of the channel bindings structure rather than some (unspecified) encoding of the channel bindings structure. This requirement is needed for interoperability. GSS-API mechanisms supporting channel bindings are responsible for checking that the channel bindings claimed by the initiator and acceptor are the same, and failing the authentication process otherwise. This is typically done by transferring an integrity-protected copy of the channel bindings data or a hash thereof. Naturally, for this to work it is important that when the channel bindings are actually the same, so are the data strings used by the mechanism implementations at both ends. More generally, it is important that for any given set of channel binding data, the data string used to represent that data by any given mechanism always be the same. This is accomplished at three layers... - By defining abstract interfaces between GSS-API applications and the GSS-API framework or mechanism, including what information about channel bindings must be passed down. This is done in RFC2743, updated and clarified by the present document. - By defining concrete bindings to the abstract interfaces in various specific programming languages. This is done in RFC2744 for C, and by RFC2853 (to be updated by a current KITTEN document) for Java. - By defining, for each mechanism, the procedure for transforming the abstract channel binding information into a particular octet string used to verify channel bindings on the wire. What the present requirement is about is insuring that, when the concrete bindings for a particular language provide only for a single octet string rather than for all of the elements in the GSS-CHANNEL-BINDINGS structure, the interpretation of that octet string is consistent from one implementation to the next. Note that this is not a change to the API; it is a clarification which improves interoperability by requiring all implementations of an ambiguous API to resolve the ambiguity in the same way. -- Jeff From Nicolas.Williams@sun.com Wed Apr 1 14:51:30 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431E728C1DE for ; Wed, 1 Apr 2009 14:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.752 X-Spam-Level: X-Spam-Status: No, score=-5.752 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgTmfrclu6Ht for ; Wed, 1 Apr 2009 14:51:29 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id D92E028C1D8 for ; Wed, 1 Apr 2009 14:51:28 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31LqTHf017730 for ; Wed, 1 Apr 2009 21:52:29 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n31LqSkS028425 for ; Wed, 1 Apr 2009 15:52:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31LZfdX015565; Wed, 1 Apr 2009 16:35:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31LZaVl015564; Wed, 1 Apr 2009 16:35:36 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 16:35:36 -0500 From: Nicolas Williams To: canetti Subject: Re: Security review of draft-ietf-kitten-gssapi-channel-bindings-06 Message-ID: <20090401213536.GT9992@Sun.COM> References: <49D331C6.7000407@post.tau.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D331C6.7000407@post.tau.ac.il> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, secdir@mit.edu, Ran Canetti X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:51:30 -0000 On Wed, Apr 01, 2009 at 12:20:06PM +0300, canetti wrote: > *I have reviewed this document as part of the security directorate's > *ongoing effort to review all IETF documents being processed by the > *IESG. These comments were written primarily for the benefit of the > *security area directors. Document editors and WG chairs should treat > *these comments just like any other last call comments. Thanks! I know that Jeff has already answered this... > This is a very short document. It describes a more generic way of > formatting the API for channel bindings. The move to a more generic > format is welcome. One potential objection here, however, is to the > requirement that compliant implementations MUST interpret the API as > having the new format. This may have backwards compatibility issues, > and for no apparent good reason. It might be better to specify the > format so that an implementation will be able to take also older API > formats. (Since this is not an interoperability or security-sensitive > issue, there seems to be no reason for the IETF to MANDATE one way > over another.) Let's pick a programming language, say, Python, and suppose that the Python bindings of the GSS-API followed RFC2743 with regards to channel binding. An implementation of those bindings AND of the Kerberos V GSS-API mechanism (RFCs 1964 and 4121) would have to decide how to map the RFC2743 "OCTET STRING" channel binding input to the mechanism's channel binding (which is defined in terms of RFC2744's gss_channel_bindings_struct C struct rather than "OCTET STRING"). Two implementations of such bindings would fail to interop when using channel bindings if the implementors decided this matter differently. Worse, suppose that you had a Python bindings implementation that mapped the RFC2743 OCTET STRING channel binding input to then initiator_address field of the RFC2744 gss_channel_bindings_struct C struct. Then you could not interop with C implementations of the same application protocol when using channel binding[*]. IMO the only reasonable decision for the implementors would be to map the RFC2743 OCTET STRING channel binding input to the RFC2744 application_data field of gss_channel_bindings_struct. And indeed, this may require changing some of the putative implementations of the putative Python bindings of the GSS-API. I don't see any alternatives. [*] Only RFC2744 application_data makes sense for channel binding nowadays. Use of network addresses for channel binding was long ago abandoned -- think of NATs :( -- and anyways, channel binding to cryptographically secure channels makes much sense, while channel binding to network addresses does not make much sense at all. Nico -- From root@core3.amsl.com Wed Apr 1 15:30:01 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E60F13A6831; Wed, 1 Apr 2009 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-extensions-iana-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090401223001.E60F13A6831@core3.amsl.com> Date: Wed, 1 Apr 2009 15:30:01 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 22:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Namespace Considerations and Registries for GSS-API Extensions Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-extensions-iana-06.txt Pages : 10 Date : 2009-04-01 This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-extensions-iana-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-kitten-gssapi-extensions-iana-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-01152455.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Apr 1 15:30:01 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E9E0F3A68C3; Wed, 1 Apr 2009 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-extended-mech-inquiry-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090401223001.E9E0F3A68C3@core3.amsl.com> Date: Wed, 1 Apr 2009 15:30:01 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 22:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Extended Generic Security Service Mechanism Inquiry APIs Author(s) : N. Williams Filename : draft-ietf-kitten-extended-mech-inquiry-06.txt Pages : 13 Date : 2009-04-01 This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications. These interfaces include: mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that posses given attributes, and a function for displaying mechanism attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-extended-mech-inquiry-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-kitten-extended-mech-inquiry-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-01152607.I-D@ietf.org> --NextPart-- From canetti@post.tau.ac.il Sat Apr 4 07:36:19 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583AA3A69B1 for ; Sat, 4 Apr 2009 07:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwu2EptXz0lF for ; Sat, 4 Apr 2009 07:36:18 -0700 (PDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id 189AE3A6860 for ; Sat, 4 Apr 2009 07:36:17 -0700 (PDT) Received: from [192.168.0.101] (c-98-224-221-50.hsd1.mi.comcast.net [98.224.221.50]) by doar.tau.ac.il (Postfix) with ESMTP id 9A753BEFA; Sat, 4 Apr 2009 17:37:17 +0300 (IDT) Message-ID: <49D70E1A.7050306@post.tau.ac.il> Date: Sat, 04 Apr 2009 10:36:58 +0300 From: canetti User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: Security review of draft-ietf-kitten-gssapi-channel-bindings-06 References: <49D331C6.7000407@post.tau.ac.il> <20090401213536.GT9992@Sun.COM> In-Reply-To: <20090401213536.GT9992@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, secdir@mit.edu, Ran Canetti X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 14:36:19 -0000 Thanks Jeff and Nico for the tutorial. The current specification does seem very reasonable. Best, Ran Nicolas Williams wrote: > On Wed, Apr 01, 2009 at 12:20:06PM +0300, canetti wrote: >> *I have reviewed this document as part of the security directorate's >> *ongoing effort to review all IETF documents being processed by the >> *IESG. These comments were written primarily for the benefit of the >> *security area directors. Document editors and WG chairs should treat >> *these comments just like any other last call comments. > > Thanks! > > I know that Jeff has already answered this... > >> This is a very short document. It describes a more generic way of >> formatting the API for channel bindings. The move to a more generic >> format is welcome. One potential objection here, however, is to the >> requirement that compliant implementations MUST interpret the API as >> having the new format. This may have backwards compatibility issues, >> and for no apparent good reason. It might be better to specify the >> format so that an implementation will be able to take also older API >> formats. (Since this is not an interoperability or security-sensitive >> issue, there seems to be no reason for the IETF to MANDATE one way >> over another.) > > Let's pick a programming language, say, Python, and suppose that the > Python bindings of the GSS-API followed RFC2743 with regards to channel > binding. > > An implementation of those bindings AND of the Kerberos V > GSS-API mechanism (RFCs 1964 and 4121) would have to decide how to map > the RFC2743 "OCTET STRING" channel binding input to the mechanism's > channel binding (which is defined in terms of RFC2744's > gss_channel_bindings_struct C struct rather than "OCTET STRING"). Two > implementations of such bindings would fail to interop when using > channel bindings if the implementors decided this matter differently. > > Worse, suppose that you had a Python bindings implementation that mapped > the RFC2743 OCTET STRING channel binding input to then initiator_address > field of the RFC2744 gss_channel_bindings_struct C struct. Then you > could not interop with C implementations of the same application > protocol when using channel binding[*]. > > IMO the only reasonable decision for the implementors would be to map > the RFC2743 OCTET STRING channel binding input to the RFC2744 > application_data field of gss_channel_bindings_struct. And indeed, this > may require changing some of the putative implementations of the > putative Python bindings of the GSS-API. I don't see any alternatives. > > [*] Only RFC2744 application_data makes sense for channel binding > nowadays. Use of network addresses for channel binding was long ago > abandoned -- think of NATs :( -- and anyways, channel binding > to cryptographically secure channels makes much sense, while channel > binding to network addresses does not make much sense at all. > > Nico From root@core3.amsl.com Mon Apr 6 13:00:02 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0FB8528C231; Mon, 6 Apr 2009 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-channel-bindings-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090406200002.0FB8528C231@core3.amsl.com> Date: Mon, 6 Apr 2009 13:00:02 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 20:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Clarifications and Extensions to the GSS-API for the Use of Channel Bindings Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-channel-bindings-07.txt Pages : 11 Date : 2009-04-06 This document clarifies and generalizes the Generic Security Services Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-kitten-gssapi-channel-bindings-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-06125338.I-D@ietf.org> --NextPart-- From Josh.Howlett@ja.net Thu Apr 9 01:28:50 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56143A67DB for ; Thu, 9 Apr 2009 01:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMEEOC2+qm6n for ; Thu, 9 Apr 2009 01:28:50 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 033993A6B6C for ; Thu, 9 Apr 2009 01:28:50 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1Lrpdt-0000U5-Ne for kitten@ietf.org; Thu, 09 Apr 2009 09:29:49 +0100 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D0A004A6B8E_9DDB1CDB for ; Thu, 9 Apr 2009 08:29:01 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id C48604A6B86_9DDB1CDF for ; Thu, 9 Apr 2009 08:29:01 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Key usage values Date: Thu, 9 Apr 2009 09:29:47 +0100 Message-ID: <6ED388AA006C454BA35B0098396B9BFB0513CA8A@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key usage values Thread-Index: Acm47VeaITq7UF6kQxSAX7Z4uxcNPw== From: "Josh Howlett" To: Cc: Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 08:28:50 -0000 Section 2 of RFC 4121 defines four key usage values for naming specific keys for signing and sealing. Section 2 of RFC 3961 states that '[n]ew protocols defined in terms of the Kerberos encryption and checksum types should use their own key usage values.' I infer from this that the key usage values defined in RFC 4121 can only be used with that mechanism, and that newly defined mechanisms that also use the Kerberos encryption and checksum crypto should define new usage values. Is that the correct interpretation? If so, could someone kindly explain why this is necessary, and why it isn't permitted to simply re-use the values defined for the K5 mechanism if a new mechanism is re-using RFC3961 crypto? Many thanks, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Nicolas.Williams@sun.com Thu Apr 9 09:22:54 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4C43A6CA7 for ; Thu, 9 Apr 2009 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mFhcNOBXJ7p for ; Thu, 9 Apr 2009 09:22:53 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id EA19B3A6B64 for ; Thu, 9 Apr 2009 09:22:52 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n39GO1M3016701 for ; Thu, 9 Apr 2009 16:24:01 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n39GO0Fx042417 for ; Thu, 9 Apr 2009 10:24:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n39GEcGG007354; Thu, 9 Apr 2009 11:14:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n39GEZGu007353; Thu, 9 Apr 2009 11:14:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 9 Apr 2009 11:14:35 -0500 From: Nicolas Williams To: Josh Howlett Subject: Re: Key usage values Message-ID: <20090409161435.GB1500@Sun.COM> References: <6ED388AA006C454BA35B0098396B9BFB0513CA8A@uxsrvr20.atlas.ukerna.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB0513CA8A@uxsrvr20.atlas.ukerna.ac.uk> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:22:54 -0000 On Thu, Apr 09, 2009 at 09:29:47AM +0100, Josh Howlett wrote: > Section 2 of RFC 4121 defines four key usage values for naming specific > keys for signing and sealing. > > Section 2 of RFC 3961 states that '[n]ew protocols defined in terms of > the Kerberos encryption and checksum types should use their own key > usage values.' > > I infer from this that the key usage values defined in RFC 4121 can only > be used with that mechanism, and that newly defined mechanisms that also > use the Kerberos encryption and checksum crypto should define new usage > values. > > Is that the correct interpretation? RFC4121 is a new protocol relative to RFC3961, but new GSS-API mechanisms that re-use parts of RFC4121 wouldn't necessarily be new protocols relative to RFC3961. Also, that "should" is lower-cased, and even if it were up-cased it would still only be a SHOULD. Provided that you make sure that cut-n- paste attacks aren't possible, then I think it would be reasonable to say that it's so much easier to promote re-use of parts of RFC4121 if no new key usages are required that protocols based on RFC4121 shouldn't have to use different key usages. Suppose you create a new GSS-API mechanism based on RFC4121, so much so that if an attacker were to change the mechanism OID in the RFC2743 header the result could be accepted anyways, but with a loss of security because the difference in security semantics somehow resides in the OID of the mechanism used. Then you have a problem. Nico -- From jhutz@cmu.edu Thu Apr 9 09:35:30 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9DC3A68D5 for ; Thu, 9 Apr 2009 09:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[AWL=-1.448, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4pJFqJU3dvv for ; Thu, 9 Apr 2009 09:35:29 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by core3.amsl.com (Postfix) with ESMTP id C3E4E3A67EB for ; Thu, 9 Apr 2009 09:35:29 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n39GaX2N021324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 12:36:35 -0400 (EDT) Date: Thu, 09 Apr 2009 12:36:34 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Josh Howlett Subject: Re: Key usage values Message-ID: <73A08334A5D68755A531C746@atlantis.pc.cs.cmu.edu> In-Reply-To: <200904091624.n39GO6Ej022069@mx02.srv.cs.cmu.edu> References: <6ED388AA006C454BA35B0098396B9BFB0513CA8A@uxsrvr20.atlas.ukerna.ac.uk> <200904091624.n39GO6Ej022069@mx02.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.117 Cc: kitten@ietf.org, jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:35:30 -0000 --On Thursday, April 09, 2009 11:14:35 AM -0500 Nicolas Williams wrote: > On Thu, Apr 09, 2009 at 09:29:47AM +0100, Josh Howlett wrote: >> Section 2 of RFC 4121 defines four key usage values for naming specific >> keys for signing and sealing. >> >> Section 2 of RFC 3961 states that '[n]ew protocols defined in terms of >> the Kerberos encryption and checksum types should use their own key >> usage values.' >> >> I infer from this that the key usage values defined in RFC 4121 can only >> be used with that mechanism, and that newly defined mechanisms that also >> use the Kerberos encryption and checksum crypto should define new usage >> values. >> >> Is that the correct interpretation? > > RFC4121 is a new protocol relative to RFC3961, but new GSS-API > mechanisms that re-use parts of RFC4121 wouldn't necessarily be new > protocols relative to RFC3961. > > Also, that "should" is lower-cased, and even if it were up-cased it > would still only be a SHOULD. Provided that you make sure that cut-n- > paste attacks aren't possible, then I think it would be reasonable to > say that it's so much easier to promote re-use of parts of RFC4121 if no > new key usages are required that protocols based on RFC4121 shouldn't > have to use different key usages. What's important is that the same key doesn't get reused with the same key usage for different things, in such a way that data encrypted in one place could usefully be copied and pasted to another. A new GSS-API mechanism which reuses the per-message tokens from RFC4121 but uses a key other than a Kerberos ticket session key should not have a problem. In fact, IMHO such a mechanism _should_ use the same key usage values, rather than creating confusion by reusing the RFC4121 messages with minor differences. -- Jeff From Josh.Howlett@ja.net Thu Apr 9 09:36:19 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E9A3A68D5 for ; Thu, 9 Apr 2009 09:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4x053Zjx3Yn for ; Thu, 9 Apr 2009 09:36:18 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 648773A6846 for ; Thu, 9 Apr 2009 09:36:18 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LrxFl-0001HZ-Cn; Thu, 09 Apr 2009 17:37:25 +0100 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CE64B4A6B4F_9DE2414B; Thu, 9 Apr 2009 16:36:36 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id B60624A6B4E_9DE2412F; Thu, 9 Apr 2009 16:36:34 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Key usage values Date: Thu, 9 Apr 2009 17:37:24 +0100 Message-ID: <6ED388AA006C454BA35B0098396B9BFB0513CC10@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <20090409161435.GB1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key usage values Thread-Index: Acm5L58rZd5MFubWSaWSZwhonrW4ZgAAaDuw References: <6ED388AA006C454BA35B0098396B9BFB0513CA8A@uxsrvr20.atlas.ukerna.ac.uk> <20090409161435.GB1500@Sun.COM> From: "Josh Howlett" To: "Nicolas Williams" Cc: kitten@ietf.org, Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:36:19 -0000 > Suppose you create a new GSS-API mechanism based on RFC4121,=20 > so much so that if an attacker were to change the mechanism=20 > OID in the RFC2743 header the result could be accepted=20 > anyways, but with a loss of security because the difference=20 > in security semantics somehow resides in the OID of the=20 > mechanism used. Then you have a problem. Interesting; I'll be mindful of that - thank you. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Thu Apr 9 09:47:06 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A0B3A6902 for ; Thu, 9 Apr 2009 09:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axFO9unYjU5o for ; Thu, 9 Apr 2009 09:47:05 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 026293A6B0E for ; Thu, 9 Apr 2009 09:45:50 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LrxOz-0001I3-8H; Thu, 09 Apr 2009 17:46:57 +0100 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A95C24A6B4F_9DE2650B; Thu, 9 Apr 2009 16:46:08 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 9ACCB4A6B2C_9DE264EF; Thu, 9 Apr 2009 16:46:06 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Key usage values Date: Thu, 9 Apr 2009 17:47:09 +0100 Message-ID: <6ED388AA006C454BA35B0098396B9BFB0513CC13@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <73A08334A5D68755A531C746@atlantis.pc.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key usage values Thread-Index: Acm5MWDVEGfRadePRyuyJMUcHmS7AAAAD9CA References: <6ED388AA006C454BA35B0098396B9BFB0513CA8A@uxsrvr20.atlas.ukerna.ac.uk> <200904091624.n39GO6Ej022069@mx02.srv.cs.cmu.edu> <73A08334A5D68755A531C746@atlantis.pc.cs.cmu.edu> From: "Josh Howlett" To: "Jeffrey Hutzelman" Cc: kitten@ietf.org, Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:47:06 -0000 > What's important is that the same key doesn't get reused with=20 > the same key usage for different things, in such a way that=20 > data encrypted in one place could usefully be copied and=20 > pasted to another. A new GSS-API mechanism which reuses the=20 > per-message tokens from RFC4121 but uses a key other than a=20 > Kerberos ticket session key should not have a problem. In=20 > fact, IMHO such a mechanism _should_ use the same key usage=20 > values, rather than creating confusion by reusing the RFC4121=20 > messages with minor differences. That's what I intuited initially, but the text in RFC 3961 ('[n]ew protocols defined in terms of the Kerberos encryption and checksum types should use their own key usage values.') gave me cause for doubt. I'll proceed as you suggest. Many thanks, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Nicolas.Williams@sun.com Fri Apr 10 15:14:54 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5DD3A6981; Fri, 10 Apr 2009 15:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHYYcqncW-I1; Fri, 10 Apr 2009 15:14:53 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id A45713A68AE; Fri, 10 Apr 2009 15:14:53 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3AMG27t010368; Fri, 10 Apr 2009 22:16:02 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3AMG1AH012594; Fri, 10 Apr 2009 16:16:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3AM6d2q008558; Fri, 10 Apr 2009 17:06:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3AM6dcM008557; Fri, 10 Apr 2009 17:06:39 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 10 Apr 2009 17:06:39 -0500 From: Nicolas Williams To: tls@ietf.org Subject: Optimizing use of SASL/GS2 over TLS Message-ID: <20090410220638.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Mailman-Approved-At: Fri, 10 Apr 2009 15:22:35 -0700 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tls@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 22:14:54 -0000 [Note: SASL and KITTEN WGs are Bcc'ed.] I've submitted an I-D describing how to reduce the number of round trips needed for SASL/GS2 mechanism negotiation and authentication when running over TLS: draft-williams-tls-app-sasl-opt-01.txt This can be seen as a variant of the TLS/GSS proposal from a while back as it achieves the same result: you can use the GSS-API for authentication _and_ TLS for session protection without having to pay a round trip penalty. But it does it in a slightly different and simpler way. I'm hoping this proposal will be less controversial than the TLS/GSS proposal. Comments? Nico -- From wwwrun@core3.amsl.com Mon Apr 13 10:47:19 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 34A953A69E1; Mon, 13 Apr 2009 10:47:18 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Clarifications and Extensions to the GSS-API for the Use of Channel Bindings' to Proposed Standard Message-Id: <20090413174719.34A953A69E1@core3.amsl.com> Date: Mon, 13 Apr 2009 10:47:19 -0700 (PDT) Cc: kitten mailing list , kitten chair , Internet Architecture Board , RFC Editor X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:47:19 -0000 The IESG has approved the following document: - 'Clarifications and Extensions to the GSS-API for the Use of Channel Bindings ' as a Proposed Standard This document is the product of the Kitten (GSS-API Next Generation) Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-07.txt Technical Summary This document clarifies and generalizes the Generic Security Services Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. Working Group Summary This document is a product of the kitten working group. The working group discussions were uneventful. Document Quality There are no current implementations that we are aware of. However, with the recent publication on channel binding usage, RFC5056, it is expected that this guidance will help foster such interest with vendors. Personnel Shawn M. Emery is the document shepherd for this document. Tim Polk has reviewed this document for the IESG. From Shawn.Emery@Sun.COM Mon Apr 20 23:29:27 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B263A6910 for ; Mon, 20 Apr 2009 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2Xrocau9RpF for ; Mon, 20 Apr 2009 23:29:26 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 7D3193A6D1F for ; Mon, 20 Apr 2009 23:29:26 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3L6UgRE006898 for ; Tue, 21 Apr 2009 06:30:42 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIF00C00TXOQ500@mail-amer.sun.com> for kitten@ietf.org; Tue, 21 Apr 2009 00:30:42 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIF0090YU36Y0D0@mail-amer.sun.com> for kitten@ietf.org; Tue, 21 Apr 2009 00:30:42 -0600 (MDT) Date: Tue, 21 Apr 2009 00:29:40 -0600 From: Shawn M Emery Subject: IETF 74: Kitten WG Minutes Sender: Shawn.Emery@Sun.COM To: kitten@ietf.org Message-id: <49ED67D4.5080309@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 06:29:27 -0000 We've uploaded the Kitten WG minutes from the session at the 74th IETF: http://www.ietf.org/proceedings/09mar/minutes/kitten.txt Please provide any comments/questions by this Friday (4/24). Alexey & Shawn, Co-chairs --