From wwwrun@core3.amsl.com Mon Jun 8 09:33:05 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 1F8A53A6DB9; Mon, 8 Jun 2009 09:33:04 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'GSS-API Extension for Storing Delegated Credentials' to Proposed Standard Message-Id: <20090608163305.1F8A53A6DB9@core3.amsl.com> Date: Mon, 8 Jun 2009 09:33:05 -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, 08 Jun 2009 16:33:05 -0000 The IESG has approved the following document: - 'GSS-API Extension for Storing Delegated Credentials ' 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-store-cred-04.txt Technical Summary This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. Working Group Summary This docment is a product of the kitten working group. The working group process was uneventful. Document Quality There is at least 1 existing implementation of the feature and other implementors are interested. Personnel Alexey Melnikov is the document shepherd for this document. Tim Polk is the responsible AD. RFC Editor Note Please make the following changes: (1) In Section 3: OLD: o default_cred BOOLEAN -- if TRUE make the stored credential available as the default credential (for acquisition with GSS_C_NO_NAME as the desired name or for use as GSS_C_NO_CREDENTIAL) NEW: o default_cred BOOLEAN -- advisory input; if TRUE make the stored credential available as the default credential (for acquisition with GSS_C_NO_NAME as the desired name or for use as GSS_C_NO_CREDENTIAL) (2) In Section 3: OLD: Finally, if the current credential store has no default credential (that is, no credential that could be acquired for GSS_C_NO_NAME) or if the default_cred input argument is TRUE, and the input credential can be successfully stored, then the input credential will be available for acquisition with GSS_C_NO_NAME as the desired name input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(), GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and GSS_Accept_sec_context(). NEW: In the GSS-API the default credential can be used by using GSS_C_NO_CREDENTIAL or a CREDENTIAL handle acquired by calling GSS_Acquire_cred() or GSS_Add_cred() with the desired_name input set to GSS_C_NO_NAME. If the default_cred input argument is TRUE, and the input credential can be successfully stored, then the input credential SHOULD be stored as the default credential (see above). If the current credential store has no default credential (see above) then the implementation MAY make the stored credentials available as the default credential regardless of the value of the default_cred input argument. From wwwrun@core3.amsl.com Mon Jun 8 09:37:56 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 EA3C83A6D02; Mon, 8 Jun 2009 09:37:56 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Extended Generic Security Service Mechanism Inquiry APIs' to Proposed Standard Message-Id: <20090608163756.EA3C83A6D02@core3.amsl.com> Date: Mon, 8 Jun 2009 09:37:56 -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, 08 Jun 2009 16:37:57 -0000 The IESG has approved the following document: - 'Extended Generic Security Service Mechanism Inquiry APIs ' 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-extended-mech-inquiry-06.txt Technical Summary This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. This document provides new functionality to obtain specific GSS-API mechanism attributes. It defines new GSS-API functions that allow retrieval and display of said attributes. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications. Working Group Summary The WG process was not controversial. Document Quality There are no implementors of these interfaces that we know of. However, there should be significant demand once these interfaces become standard, as a number of applications have hard-coded around limitations of the current GSS-API. Enabling better programming practices is desired. Personnel Shawn M. Emery is the document shepherd for this document. Tim Polk is the responsible AD. RFC Editor Note Please make the following six changes: (1) Section 3.4.2, title: s/3.4.2. GSS_Indicate_mechs_by_attr()/3.4.2. GSS_Indicate_mechs_by_attrs()/ (2) Section 3.4.3, last sentence: s/GSS_Inquire_mech_attrs_for_mech()/GSS_Inquire_attrs_for_mech() (3) Section 3.4.6, third sentence: s/typdefs/typedefs/ (4) Section 3.4.6, Figure 2 OLD: OM_uint32 gss_inquire_mechs_for_attrs( OM_uint32 *minor_status, gss_const_OID_set desired_mech_attrs, gss_const_OID_set except_mech_attrs, gss_const_OID_set critical_mech_attrs, gss_OID_set *mechs); NEW: OM_uint32 gss_indicate_mechs_by_attrs( OM_uint32 *minor_status, gss_const_OID_set desired_mech_attrs, gss_const_OID_set except_mech_attrs, gss_const_OID_set critical_mech_attrs, gss_OID_set *mechs); (5) Section 5, first sentence: s/namsepace/namespace/ (6) Section 5, first sentence: s/IESG Protocol Action/IETF Consensus/ From wwwrun@core3.amsl.com Mon Jun 15 08:07:51 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 404D03A68F3; Mon, 15 Jun 2009 08:07:50 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Generic Security Service API Version 2 : Java Bindings Update' to Proposed Standard Message-Id: <20090615150751.404D03A68F3@core3.amsl.com> Date: Mon, 15 Jun 2009 08:07:51 -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, 15 Jun 2009 15:07:51 -0000 The IESG has approved the following document: - 'Generic Security Service API Version 2 : Java Bindings Update ' 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-rfc2853bis-05.txt Technical Summary This document clarifies and updates the Java bindings specification for the Generic Security Services Application Programming Interface (GSS-API) version 2. Working Group Summary This document is a product of the kitten working group. The working group process was unremarkable. Document Quality There are at three vendors that have implemented the GSS-API Java bindings; this ID is an update to synchronize with the known implementations. Personnel Shawn M. Emery is the document shepherd for this document. Tim Polk is the responsible AD. RFC Editor Note Please insert the following into the header: Obsoletes: 2853 (if approved) License Note: This document is being forwarded for publication assuming that the proposed update to the TLP will be completed by the IETF Trust prior to completion of the RFC publication process. If that process does not terminate successfully, please perform the following two modifications to section 1 as follows: (1) Change the section title to "Conventions and Licenses" (2) Insert a new second paragraph, replacing XXXX with the RFC number assigned to this specification: The following license applies to all code segments included in this specification. If code is extracted from this specification, please include the following text in the code: /* -- Copyright (c) 2009 IETF Trust and the persons identified as -- authors of the code. All rights reserved. -- -- Redistribution and use in source and binary forms, with or without -- modification, are permitted provided that the following conditions -- are met: -- -- - Redistributions of source code must retain the above copyright -- notice, this list of conditions and the following disclaimer. -- -- - Redistributions in binary form must reproduce the above copyright -- notice, this list of conditions and the following disclaimer in -- the documentation and/or other materials provided with the -- distribution. -- -- - Neither the name of Internet Society, IETF or IETF Trust, nor the -- names of specific contributors, may be used to endorse or promote -- products derived from this software without specific prior -- written permission. -- -- -- -- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -- 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -- LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -- A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -- OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -- LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -- DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -- THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -- OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- -- This code is part of RFC XXXX; see the RFC itself for full legal notices. -- -- */ From simon@josefsson.org Thu Jun 25 08:09:28 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 B8C3028C13A for ; Thu, 25 Jun 2009 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 c-W91c0WVml9 for ; Thu, 25 Jun 2009 08:09:28 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 7B7FD3A685D for ; Thu, 25 Jun 2009 08:09:25 -0700 (PDT) Received: from mocca.josefsson.org (m90-137-90-225.cust.tele2.se [90.137.90.225]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5PEseCg019767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2009 16:54:45 +0200 X-Hashcash: 1:22:090625:kitten@ietf.org::ztiXHqT/2ni6xkTX:5buw X-Hashcash: 1:22:090625:sasl@ietf.org::UfOcsTtOlXOtKJVU:3z2o From: Simon Josefsson To: kitten@ietf.org, sasl@ietf.org Subject: channel bindings and address types OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Thu, 25 Jun 2009 16:54:40 +0200 Message-ID: <873a9oicsv.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, 25 Jun 2009 15:09:28 -0000 I'm working on GS2 and thinking about how the GSS-CHANNEL-BINDING structure should be used. In particular, I'm thinking of how to set the address type fields in an implementation, quoting RFC 5554: GSS-CHANNEL-BINDINGS ::= SEQUENCE { initiator-address-type INTEGER, -- See RFC2744 initiator-address OCTET STRING, -- See RFC2744 acceptor-address-type INTEGER, -- See RFC2744 acceptor-address OCTET STRING, -- See RFC2744 application-data OCTET STRING -- See RFC5056 } The values for the initiator-address-type and acceptor-address-type fields are specified Appendix A of RFC 2744. However, that is C specific. I can't find anything in RFC 2743 about the address types. As far as I can tell, RFC 5554 does not improve this situation? The conclusion appears to be that there are no implementation-agnostic definition of the address type values? I suggest we update RFC 2743/5554 and define symbols for GSS_C_AF_INET etc in a implementation independent way. Further, there are no address type value allocated for IPv6 address as far as I can see? I think SCRAM/GS2 needs to be able to support IPv6 end points. /Simon From Nicolas.Williams@sun.com Thu Jun 25 08:26:38 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 D78123A6AA4 for ; Thu, 25 Jun 2009 08:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.330, 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 FcJbxRJTdh3Z for ; Thu, 25 Jun 2009 08:26:37 -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 889B63A689E for ; Thu, 25 Jun 2009 08:26:37 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5PFPmnW001881; Thu, 25 Jun 2009 15:25:48 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 n5PFPlpe006583; Thu, 25 Jun 2009 09:25:47 -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 n5PFFgNu010684; Thu, 25 Jun 2009 10:15:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5PFFgvH010683; Thu, 25 Jun 2009 10:15:42 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 25 Jun 2009 10:15:42 -0500 From: Nicolas Williams To: Simon Josefsson Subject: Re: channel bindings and address types Message-ID: <20090625151542.GH3425@Sun.COM> References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625151313.GE1308@Sun.COM> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, sasl@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, 25 Jun 2009 15:26:39 -0000 On Thu, Jun 25, 2009 at 10:13:13AM -0500, Nicolas Williams wrote: > On Thu, Jun 25, 2009 at 04:54:40PM +0200, Simon Josefsson wrote: > > I'm working on GS2 and thinking about how the GSS-CHANNEL-BINDING > > structure should be used. In particular, I'm thinking of how to set the > > address type fields in an implementation, quoting RFC 5554: > > > > GSS-CHANNEL-BINDINGS ::= SEQUENCE { > > initiator-address-type INTEGER, -- See RFC2744 > > initiator-address OCTET STRING, -- See RFC2744 > > acceptor-address-type INTEGER, -- See RFC2744 > > acceptor-address OCTET STRING, -- See RFC2744 > > application-data OCTET STRING -- See RFC5056 > > } > > These are OPTIONAL, or should have been marked as such. See RFC2744. To be more specific, they are NOT OPTIONAL in the ASN.1 sense -- they must be present -- but they can be GSS_C_AF_UNSPEC and the empty octet strings. GS2, specifically, MUST set the *-address-type fields to GSS_C_AF_UNSPEC and the *-address fields to the empty octet string. From simon@josefsson.org Thu Jun 25 08:54:13 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 1548E3A6A27 for ; Thu, 25 Jun 2009 08:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Z6509Eo7eAEX for ; Thu, 25 Jun 2009 08:54:12 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id A7B3E3A6DDC for ; Thu, 25 Jun 2009 08:54:08 -0700 (PDT) Received: from mocca.josefsson.org (m90-137-82-10.cust.tele2.se [90.137.82.10]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5PFpsor021414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2009 17:51:59 +0200 From: Simon Josefsson To: Nicolas Williams Subject: Re: channel bindings and address types References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> <20090625151542.GH3425@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090625:sasl@ietf.org::kaBrDICHGuF6X+J2:4xSE X-Hashcash: 1:22:090625:kitten@ietf.org::OeRLimC2zxf5Cbrt:HTAx X-Hashcash: 1:22:090625:nicolas.williams@sun.com::33oBGY1V2KHF0H42:JeHm Date: Thu, 25 Jun 2009 17:51:53 +0200 In-Reply-To: <20090625151542.GH3425@Sun.COM> (Nicolas Williams's message of "Thu, 25 Jun 2009 10:15:42 -0500") Message-ID: <871vp8gvl2.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, 25 Jun 2009 15:54:13 -0000 Nicolas Williams writes: > GS2, specifically, MUST set the *-address-type fields to GSS_C_AF_UNSPEC > and the *-address fields to the empty octet string. I agree and this approach avoids the entire problem, and the potential NAT problem as well. Case closed, and sorry about the noise. It still seems useful to update GSS-API to support IPv6 address types, though. /Simon From Nicolas.Williams@Sun.COM Thu Jun 25 08:56:26 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 0A2953A6C3A for ; Thu, 25 Jun 2009 08:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.324, 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 vt1+jAt6pQUr for ; Thu, 25 Jun 2009 08:56:25 -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 4CB6D3A6A2E for ; Thu, 25 Jun 2009 08:56:25 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5PFNPff013447; Thu, 25 Jun 2009 15:23:25 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 n5PFNOZ6004928; Thu, 25 Jun 2009 09:23:25 -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 n5PFDHNE010677; Thu, 25 Jun 2009 10:13:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5PFDDFD010676; Thu, 25 Jun 2009 10:13:13 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 25 Jun 2009 10:13:13 -0500 From: Nicolas Williams To: Simon Josefsson Subject: Re: channel bindings and address types Message-ID: <20090625151313.GE1308@Sun.COM> References: <873a9oicsv.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873a9oicsv.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, sasl@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, 25 Jun 2009 15:56:26 -0000 On Thu, Jun 25, 2009 at 04:54:40PM +0200, Simon Josefsson wrote: > I'm working on GS2 and thinking about how the GSS-CHANNEL-BINDING > structure should be used. In particular, I'm thinking of how to set the > address type fields in an implementation, quoting RFC 5554: > > GSS-CHANNEL-BINDINGS ::= SEQUENCE { > initiator-address-type INTEGER, -- See RFC2744 > initiator-address OCTET STRING, -- See RFC2744 > acceptor-address-type INTEGER, -- See RFC2744 > acceptor-address OCTET STRING, -- See RFC2744 > application-data OCTET STRING -- See RFC5056 > } These are OPTIONAL, or should have been marked as such. See RFC2744. From Nicolas.Williams@sun.com Thu Jun 25 09:07:44 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 80AB93A69CF for ; Thu, 25 Jun 2009 09:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.318, 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 9gxtpLaO3e4z for ; Thu, 25 Jun 2009 09:07:43 -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 AFB793A6945 for ; Thu, 25 Jun 2009 09:07:43 -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 n5PG6eRu016474 for ; Thu, 25 Jun 2009 16:06:40 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 n5PG6eer038587 for ; Thu, 25 Jun 2009 10:06:40 -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 n5PFuZsi010705; Thu, 25 Jun 2009 10:56:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5PFuZMf010704; Thu, 25 Jun 2009 10:56:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 25 Jun 2009 10:56:35 -0500 From: Nicolas Williams To: Simon Josefsson Subject: Re: channel bindings and address types Message-ID: <20090625155635.GG1308@Sun.COM> References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> <20090625151542.GH3425@Sun.COM> <871vp8gvl2.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871vp8gvl2.fsf@mocca.josefsson.org> 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, 25 Jun 2009 16:07:44 -0000 On Thu, Jun 25, 2009 at 05:51:53PM +0200, Simon Josefsson wrote: > Nicolas Williams writes: > > > GS2, specifically, MUST set the *-address-type fields to GSS_C_AF_UNSPEC > > and the *-address fields to the empty octet string. > > I agree and this approach avoids the entire problem, and the potential > NAT problem as well. Case closed, and sorry about the noise. > > It still seems useful to update GSS-API to support IPv6 address types, > though. Complete? yes, useful? no. As you surmised, NAT and the *address* fields in there don't mix. Even without NAT (and no, IPv6 does not mean no NAT, sadly) binding in the network addresses provides no additional security unless IPsec is in use and provides a tight IP address <-> peer ID binding. To really add security you should do channel binding to IPsec channels, and that looks much the same as channel binding to TLS. (For more about IPsec channels see the BTNS WG.) So, in the end binding to addresses is just not very useful. Nico -- From raeburn@MIT.EDU Thu Jun 25 09:15:10 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 CDCA13A6F26 for ; Thu, 25 Jun 2009 09:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Vk8EdpjkBVOW for ; Thu, 25 Jun 2009 09:15:09 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 3E0173A6F39 for ; Thu, 25 Jun 2009 09:15:09 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n5PGB4On006100; Thu, 25 Jun 2009 12:11:04 -0400 (EDT) Received: from [10.0.0.172] (c-76-119-232-32.hsd1.ma.comcast.net [76.119.232.32]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n5PGB3GQ024863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2009 12:11:04 -0400 (EDT) From: Ken Raeburn To: Simon Josefsson In-Reply-To: <873a9oicsv.fsf@mocca.josefsson.org> Subject: Re: channel bindings and address types References: <873a9oicsv.fsf@mocca.josefsson.org> Message-Id: <756AA2C9-4BD5-4413-B780-47476D10C490@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 12:11:03 -0400 X-Mailer: Apple Mail (2.935.3) X-Scanned-By: MIMEDefang 2.42 Cc: kitten@ietf.org, sasl@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, 25 Jun 2009 16:15:10 -0000 On Jun 25, 2009, at 10:54, Simon Josefsson wrote: > The values for the initiator-address-type and acceptor-address-type > fields are specified Appendix A of RFC 2744. However, that is C > specific. I can't find anything in RFC 2743 about the address types. > As far as I can tell, RFC 5554 does not improve this situation? > > The conclusion appears to be that there are no implementation-agnostic > definition of the address type values? I think it's pretty obvious that all implementations need to use the same values regardless of implementation language or operating systems. It's a little messy that they're specified in C rather than abstractly, but they are specified. RFC 5554 does make it explicit that the C bindings specify how the content is defined, and explicitly says so for the address fields; I don't think it needs to explicitly restate it for address type fields. > I suggest we update RFC 2743/5554 and define symbols for GSS_C_AF_INET > etc in a implementation independent way. I'm not sure it's needed, but it wouldn't hurt anything, either. > Further, there are no address type value allocated for IPv6 address as > far as I can see? Not officially. MIT doesn't implement it, but Heimdal appears to use 24 for GSS_C_AF_INET6. -- Ken Raeburn / raeburn@mit.edu / no longer at MIT Kerberos Consortium From lha@kth.se Thu Jun 25 09:40:35 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 860213A6B26 for ; Thu, 25 Jun 2009 09:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 qoGuKx8wIZcJ for ; Thu, 25 Jun 2009 09:40:34 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id DC7753A68AE for ; Thu, 25 Jun 2009 09:40:34 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 49A966708978 for ; Thu, 25 Jun 2009 09:28:07 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Brightmail Gateway) with ESMTP id 300BF28089 for ; Thu, 25 Jun 2009 09:28:07 -0700 (PDT) X-AuditID: 11807134-a6c80bb0000021f3-f5-4a43a5978bab Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with ESMTP id 108A428041 for ; Thu, 25 Jun 2009 09:28:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KLS001AJZ2UXU50@elliott.apple.com> for kitten@ietf.org; Thu, 25 Jun 2009 09:28:07 -0700 (PDT) Subject: Re: channel bindings and address types From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <871vp8gvl2.fsf@mocca.josefsson.org> Date: Thu, 25 Jun 2009 09:28:06 -0700 Message-id: References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> <20090625151542.GH3425@Sun.COM> <871vp8gvl2.fsf@mocca.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1068) X-Brightmail-Tracker: AAAAAA== Cc: "kitten@ietf.org" , Nicolas Williams 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, 25 Jun 2009 16:40:35 -0000 25 jun 2009 kl. 08:51 skrev Simon Josefsson: > Nicolas Williams writes: > >> GS2, specifically, MUST set the *-address-type fields to >> GSS_C_AF_UNSPEC >> and the *-address fields to the empty octet string. > > I agree and this approach avoids the entire problem, and the potential > NAT problem as well. Case closed, and sorry about the noise. > > It still seems useful to update GSS-API to support IPv6 address types, > though. Heimdal uses #define GSS_C_AF_INET6 24 and store in the same way as v4 keys are stored. Love From jhutz@cmu.edu Thu Jun 25 12:03:33 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 242DA3A6B51 for ; Thu, 25 Jun 2009 12:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=-0.912, 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 Fbu+4botAbNI for ; Thu, 25 Jun 2009 12:03:32 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id DC2DD3A67E2 for ; Thu, 25 Jun 2009 12:03:31 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n5PHhbTw017507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 13:43:37 -0400 (EDT) Date: Thu, 25 Jun 2009 13:43:37 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Simon Josefsson Subject: Re: channel bindings and address types Message-ID: <768D48FC14DD016BC6D36066@MINBAR.FAC.CS.CMU.EDU> In-Reply-To: <7124_1245946084_n5PG83h2032176_20090625155635.GG1308@Sun.COM> References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> <20090625151542.GH3425@Sun.COM> <871vp8gvl2.fsf@mocca.josefsson.org> <7124_1245946084_n5PG83h2032176_20090625155635.GG1308@Sun.COM> 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.217.196 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, 25 Jun 2009 19:03:33 -0000 --On Thursday, June 25, 2009 10:56:35 AM -0500 Nicolas Williams wrote: > On Thu, Jun 25, 2009 at 05:51:53PM +0200, Simon Josefsson wrote: >> Nicolas Williams writes: >> >> > GS2, specifically, MUST set the *-address-type fields to >> > GSS_C_AF_UNSPEC and the *-address fields to the empty octet string. >> >> I agree and this approach avoids the entire problem, and the potential >> NAT problem as well. Case closed, and sorry about the noise. >> >> It still seems useful to update GSS-API to support IPv6 address types, >> though. > > Complete? yes, useful? no. > > As you surmised, NAT and the *address* fields in there don't mix. Even > without NAT (and no, IPv6 does not mean no NAT, sadly) binding in the > network addresses provides no additional security unless IPsec is in use > and provides a tight IP address <-> peer ID binding. To really add > security you should do channel binding to IPsec channels, and that looks > much the same as channel binding to TLS. (For more about IPsec channels > see the BTNS WG.) So, in the end binding to addresses is just not very > useful. Personally, I believe that for some time it has been the consensus of the GSS-API community that binding to addresses is not useful and should be avoided and treated as a deprecated feature. Note, however, that I am not chair of the KITTEN working group. -- Jeff From jhutz@cmu.edu Thu Jun 25 12:04:34 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 D80863A6838 for ; Thu, 25 Jun 2009 12:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 pLXVq4LKAKsQ for ; Thu, 25 Jun 2009 12:04:34 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 8E4203A6F2B for ; Thu, 25 Jun 2009 12:03:45 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n5PFXRqa008300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 11:33:27 -0400 (EDT) Date: Thu, 25 Jun 2009 11:33:27 -0400 From: Jeffrey Hutzelman To: Simon Josefsson , kitten@ietf.org, sasl@ietf.org Subject: Re: channel bindings and address types Message-ID: <53AF0FE207A61D1183B855E3@MINBAR.FAC.CS.CMU.EDU> In-Reply-To: <12360_1245942589_n5PF9lsw019426_873a9oicsv.fsf@mocca.josefsson.org> References: <12360_1245942589_n5PF9lsw019426_873a9oicsv.fsf@mocca.josefsson.org> 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.217.196 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: Thu, 25 Jun 2009 19:04:34 -0000 --On Thursday, June 25, 2009 04:54:40 PM +0200 Simon Josefsson wrote: > I'm working on GS2 and thinking about how the GSS-CHANNEL-BINDING > structure should be used. In particular, I'm thinking of how to set the > address type fields in an implementation, quoting RFC 5554: > > GSS-CHANNEL-BINDINGS ::= SEQUENCE { > initiator-address-type INTEGER, -- See RFC2744 > initiator-address OCTET STRING, -- See RFC2744 > acceptor-address-type INTEGER, -- See RFC2744 > acceptor-address OCTET STRING, -- See RFC2744 > application-data OCTET STRING -- See RFC5056 > } > > The values for the initiator-address-type and acceptor-address-type > fields are specified Appendix A of RFC 2744. However, that is C > specific. I can't find anything in RFC 2743 about the address types. > As far as I can tell, RFC 5554 does not improve this situation? It does, if you read enough of it. Basically, it points out that even though some of the API bits are in 2744, they're actually not C-specific, and it also points out that the encoding of channel bindings on the wire is specific to the mechanism; RFC4121 defines an encoding for Kerberos but not for other mechanisms. It also refers specifically to RFC2744 for the values of the address-type fields. Furthermore, one of the bullet points in section 5.1, starting at the bottom of page 13 in scram-01, makes it clear that we hash only the external channel type and binding data; that is, SCRAM ignores the address fields in the RFC2743/2744/5554 channel binding structure. This is reasonable -- binding to IP addresses not only provides little security benefit but is actively harmful. GS2 should simply set the address types to 0 and the strings empty, using only the application-data field as described in RFC5554. -- Jeff > I suggest we update RFC 2743/5554 and define symbols for GSS_C_AF_INET > etc in a implementation independent way. No. > Further, there are no address type value allocated for IPv6 address as > far as I can see? > > I think SCRAM/GS2 needs to be able to support IPv6 end points. It needs to not try to represent addresses in channel bindings. -- Jeff From Shawn.Emery@Sun.COM Fri Jun 26 00:50:42 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 408453A6A9B for ; Fri, 26 Jun 2009 00:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=0.150, 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 KkKJgi5D+IgN for ; Fri, 26 Jun 2009 00:50:41 -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 DAC943A69BA for ; Fri, 26 Jun 2009 00:50:40 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5Q7Tb9T000172 for ; Fri, 26 Jun 2009 07:29:37 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLU00E004Q90100@mail-amer.sun.com> for kitten@ietf.org; Fri, 26 Jun 2009 01:29:37 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLU0053W4TCL040@mail-amer.sun.com>; Fri, 26 Jun 2009 01:29:36 -0600 (MDT) Date: Fri, 26 Jun 2009 01:29:25 -0600 From: Shawn M Emery Subject: Re: channel bindings and address types In-reply-to: <768D48FC14DD016BC6D36066@MINBAR.FAC.CS.CMU.EDU> Sender: Shawn.Emery@Sun.COM To: Jeffrey Hutzelman Message-id: <4A4478D5.30307@sun.com> References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> <20090625151542.GH3425@Sun.COM> <871vp8gvl2.fsf@mocca.josefsson.org> <7124_1245946084_n5PG83h2032176_20090625155635.GG1308@Sun.COM> <768D48FC14DD016BC6D36066@MINBAR.FAC.CS.CMU.EDU> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Cc: kitten@ietf.org, Simon Josefsson , Nicolas Williams 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: Fri, 26 Jun 2009 07:50:42 -0000 Jeffrey Hutzelman wrote: > --On Thursday, June 25, 2009 10:56:35 AM -0500 Nicolas Williams > wrote: > >> On Thu, Jun 25, 2009 at 05:51:53PM +0200, Simon Josefsson wrote: >>> Nicolas Williams writes: >>> >>> > GS2, specifically, MUST set the *-address-type fields to >>> > GSS_C_AF_UNSPEC and the *-address fields to the empty octet string. >>> >>> I agree and this approach avoids the entire problem, and the potential >>> NAT problem as well. Case closed, and sorry about the noise. >>> >>> It still seems useful to update GSS-API to support IPv6 address types, >>> though. >> >> Complete? yes, useful? no. >> >> As you surmised, NAT and the *address* fields in there don't mix. Even >> without NAT (and no, IPv6 does not mean no NAT, sadly) binding in the >> network addresses provides no additional security unless IPsec is in use >> and provides a tight IP address <-> peer ID binding. To really add >> security you should do channel binding to IPsec channels, and that looks >> much the same as channel binding to TLS. (For more about IPsec channels >> see the BTNS WG.) So, in the end binding to addresses is just not very >> useful. > > Personally, I believe that for some time it has been the consensus of > the GSS-API community that binding to addresses is not useful and > should be avoided and treated as a deprecated feature. > > Note, however, that I am not chair of the KITTEN working group. RFC 5554 states that network address as channel bindings is not very secure, which the chair would imply as not being very useful. Shawn. -- From simon@josefsson.org Sat Jun 27 09:39: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 B1FD93A6B83 for ; Sat, 27 Jun 2009 09:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 JzxzExkHEhpt for ; Sat, 27 Jun 2009 09:39:10 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 7488628C210 for ; Sat, 27 Jun 2009 09:39:07 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-27-182.bredband.comhem.se [80.216.27.182]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5RGdLv5022250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 27 Jun 2009 18:39:23 +0200 From: Simon Josefsson To: Shawn M Emery Subject: Re: channel bindings and address types References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> <20090625151542.GH3425@Sun.COM> <871vp8gvl2.fsf@mocca.josefsson.org> <7124_1245946084_n5PG83h2032176_20090625155635.GG1308@Sun.COM> <768D48FC14DD016BC6D36066@MINBAR.FAC.CS.CMU.EDU> <4A4478D5.30307@sun.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090627:nicolas.williams@sun.com::mAUcciqc78E4fUfO:Nj1 X-Hashcash: 1:22:090627:shawn.emery@sun.com::LGZDyWg5IR5FV/nm:2Up0 X-Hashcash: 1:22:090627:jhutz@cmu.edu::mAHLe2ahs7zOk9+D:4BxP X-Hashcash: 1:22:090627:kitten@ietf.org::84bM30RNHVroD47L:5qS4 Date: Sat, 27 Jun 2009 18:39:21 +0200 In-Reply-To: <4A4478D5.30307@sun.com> (Shawn M. Emery's message of "Fri, 26 Jun 2009 01:29:25 -0600") Message-ID: <87ws6xk4w6.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Sat, 27 Jun 2009 16:39:11 -0000 Shawn M Emery writes: > RFC 5554 states that network address as channel bindings is not very > secure, which the chair would imply as not being very useful. Where does it say that? This part Language bindings that use OCTET STRING (or equivalent) for channel bindings will not support the use of network addresses as channel bindings. This should not cause any security problems, as the use of network addresses as channel bindings is not generally secure. appears to me imply that network address alone is not secure as a channel binding, but that isn't the same. If there is something inherent insecure about using network addresses in channel bindings, I'd like to understand more. As far as I can tell, there is no security problem in using network addresses in channel bindings. There is the obvious and major deployment problem wrt NAT-like situations though. /Simon From Nicolas.Williams@sun.com Sat Jun 27 22:17:42 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 EC1C83A6864 for ; Sat, 27 Jun 2009 22:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.733 X-Spam-Level: X-Spam-Status: No, score=-5.733 tagged_above=-999 required=5 tests=[AWL=0.313, 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 yK2MWzi37oK7 for ; Sat, 27 Jun 2009 22:17:41 -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 BCE9B3A6B1C for ; Sat, 27 Jun 2009 22:17:40 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5S5HxW1027662 for ; Sun, 28 Jun 2009 05:17:59 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 n5S5HxHu032678 for ; Sat, 27 Jun 2009 23:17:59 -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 n5S57lKX012925; Sun, 28 Jun 2009 00:07:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5S57dUH012924; Sun, 28 Jun 2009 00:07:39 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 28 Jun 2009 00:07:39 -0500 From: Nicolas Williams To: Simon Josefsson Subject: Re: channel bindings and address types Message-ID: <20090628050739.GY1308@Sun.COM> References: <873a9oicsv.fsf@mocca.josefsson.org> <20090625151313.GE1308@Sun.COM> <20090625151542.GH3425@Sun.COM> <871vp8gvl2.fsf@mocca.josefsson.org> <7124_1245946084_n5PG83h2032176_20090625155635.GG1308@Sun.COM> <768D48FC14DD016BC6D36066@MINBAR.FAC.CS.CMU.EDU> <4A4478D5.30307@sun.com> <87ws6xk4w6.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ws6xk4w6.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Shawn M Emery 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: Sun, 28 Jun 2009 05:17:43 -0000 On Sat, Jun 27, 2009 at 06:39:21PM +0200, Simon Josefsson wrote: > Shawn M Emery writes: > > > RFC 5554 states that network address as channel bindings is not very > > secure, which the chair would imply as not being very useful. > > Where does it say that? This part > > Language bindings that use OCTET STRING (or equivalent) for channel > bindings will not support the use of network addresses as channel > bindings. This should not cause any security problems, as the use of > network addresses as channel bindings is not generally secure. > > appears to me imply that network address alone is not secure as a > channel binding, but that isn't the same. How is the quote ("...not generally secure") not in agreement with what Shawn said ("not very secure")? > If there is something inherent insecure about using network addresses in > channel bindings, I'd like to understand more. > > As far as I can tell, there is no security problem in using network > addresses in channel bindings. There is the obvious and major > deployment problem wrt NAT-like situations though. Indeed, no security _harm_ results from using channel binding to network addresses. However, channel binding to network addresses adds little or no security. It can only add security when the network is physically secure or IPsec (or equivalent, for non-IP networks) is in use, and then only if a) IPsec protection is end-to-end, b) the IPsec policy ties peers and IP addresses together tightly, and c) the IPsec policy does not change adversely during the life of the connection. Channel binding to network addresses could be seen as a proxy for channel binding to IPsec, but only in very specific circumstances, circumstances that applications cannot check for without having IPsec APIs, and if they do then they might as well have access to IPsec channel APIs that export channel bindings. There are no APIs for determining that the network path between two hosts is physically secure either. Given that channel binding to network addresses adds little or no security, may lead to a sense of false security, is difficult to use in any way that does add security, and will cause problems when NAT is in the picture, channel binding to network addresses is best discouraged. Nico --