From alexey.melnikov@isode.com Tue Aug 11 05:16: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 B7E4F3A7095 for ; Tue, 11 Aug 2009 05:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=-0.716, 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 RoMJMfFJH+3I for ; Tue, 11 Aug 2009 05:16:30 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A5CEA3A6D9A for ; Tue, 11 Aug 2009 05:16:29 -0700 (PDT) Received: from [172.16.2.149] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 11 Aug 2009 13:11:07 +0100 Message-ID: <4A815FC7.8000400@isode.com> Date: Tue, 11 Aug 2009 13:10:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: kitten@ietf.org Subject: Determining strength of encryption provided by a GSS-API mechanism MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; 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: Tue, 11 Aug 2009 12:16:30 -0000 In continuation of the discussion in Stockholm about what can be done in the WG that is of interest to implementors, I have one minor request. I am working on a Cyrus SASL plugin that either uses GSS-API or SSPI. SASL uses a thing called Strength Security Factor (SSF) to determine if a particular authentication mechanism is allowed by client or server security policy. SSF roughly correspond to the key size for symmetric ciphers, with SSF==0 being no privacy and no integrity, and SSF==1 being integrity only. (I am not going to defend the concept of SSF, but I think it is relatively easy to understand by sysadmins and it seems to work.) Each Cyrus SASL plugin needs to advertise its minimal and maximal supported SSF, so the maximal SSF is going to be the strength of the strongest supported symmetric cipher. What I am missing is some API for retrieving SSF provided by a GSS-API mechanism's gss_wrap() with privacy, as well as for retrieving the best SSF that can be provided by the mechanism. Is such API already available, and if the answer is no, are people interested in working on defining it? Thanks, Alexey From lha@kth.se Tue Aug 11 15:09: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 5A79C3A69EE for ; Tue, 11 Aug 2009 15:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 rpA8T1udW03C for ; Tue, 11 Aug 2009 15:09:53 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 1D15A3A6FB6 for ; Tue, 11 Aug 2009 15:09:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 6FC01155B81; Tue, 11 Aug 2009 23:42:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UQfcQgl0MkeJ; Tue, 11 Aug 2009 23:42:52 +0200 (CEST) Received: from [10.0.1.6] (c80-216-69-25.bredband.comhem.se [80.216.69.25]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 7DE9E155910; Tue, 11 Aug 2009 23:42:52 +0200 (CEST) Subject: Re: Determining strength of encryption provided by a GSS-API mechanism Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <4A815FC7.8000400@isode.com> Date: Tue, 11 Aug 2009 23:42:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4A815FC7.8000400@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1075.2) 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: Tue, 11 Aug 2009 22:09:54 -0000 11 aug 2009 kl. 14:10 skrev Alexey Melnikov: > Is such API already available no > and if the answer is no, are people interested in working on > defining it? sure, I think the definition of SSF is broken, and its not simple to understand, racing to yet another higher number seems bad. Love From rfc-editor@rfc-editor.org Tue Aug 11 16:39: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 9A02B3A6AA7; Tue, 11 Aug 2009 16:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.614 X-Spam-Level: X-Spam-Status: No, score=-16.614 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 BQDcJKc05dyt; Tue, 11 Aug 2009 16:39:32 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id A74713A6AD5; Tue, 11 Aug 2009 16:39:32 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id EF2AD303F2A; Tue, 11 Aug 2009 16:15:46 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5653 on Generic Security Service API Version 2: Java Bindings Update From: rfc-editor@rfc-editor.org Message-Id: <20090811231546.EF2AD303F2A@bosco.isi.edu> Date: Tue, 11 Aug 2009 16:15:46 -0700 (PDT) Cc: kitten@ietf.org, rfc-editor@rfc-editor.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: Tue, 11 Aug 2009 23:39:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5653 Title: Generic Security Service API Version 2: Java Bindings Update Author: M. Upadhyay, S. Malkani Status: Standards Track Date: August 2009 Mailbox: m.d.upadhyay+ietf@gmail.com, Seema.Malkani@gmail.com Pages: 99 Characters: 209903 Obsoletes: RFC2853 I-D Tag: draft-ietf-kitten-rfc2853bis-05.txt URL: http://www.rfc-editor.org/rfc/rfc5653.txt The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings" (RFC 2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). [STANDARDS TRACK] This document is a product of the Kitten (GSS-API Next Generation) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From Nicolas.Williams@sun.com Wed Aug 12 11:45:16 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 C1AA43A6994 for ; Wed, 12 Aug 2009 11:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 GwuXQV3T1sZx for ; Wed, 12 Aug 2009 11:45:16 -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 3ED3A3A6943 for ; Wed, 12 Aug 2009 11:45:15 -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 n7CIRHkG028991 for ; Wed, 12 Aug 2009 18:27:17 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 n7CIRCwo003254 for ; Wed, 12 Aug 2009 12:27:12 -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 n7CIGYct013100; Wed, 12 Aug 2009 13:16:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CIGXIm013099; Wed, 12 Aug 2009 13:16:33 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 12 Aug 2009 13:16:33 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: Determining strength of encryption provided by a GSS-API mechanism Message-ID: <20090812181633.GG10982@Sun.COM> References: <4A815FC7.8000400@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Wed, 12 Aug 2009 18:45:16 -0000 On Tue, Aug 11, 2009 at 11:42:53PM +0200, Love Hörnquist Åstrand wrote: > > 11 aug 2009 kl. 14:10 skrev Alexey Melnikov: > > > Is such API already available > > no Though we've discussed designs for APIs that allow applications to request / determine which strength profiles to use / are in use. > >and if the answer is no, are people interested in working on > >defining it? > > sure, I think the definition of SSF is broken, and its not simple to > understand, racing to yet another higher number seems bad. Indeed. SSF is bad, bad, bad. It's not possible to permanently assign a "strength" number to a mechanism or "enctype". Strength is in the eye of the beholder and may vary with time. And users shouldn't, and likely don't, care about numeric strength representations -- they should, and probably do, care about strength representations in their language, such as "strong", names of standards (e.g., "fips140-1"), and so on. IMO only relative strength should matter, and rather than use numbers we should use names of policies, policies that can be created and maintained locally or, in the case of policies that correspond to standards, delivered by vendors and updated as those standards are updated. No, that's not helpful to you: even if we had such GSS APIs you'd still have to introduce equivalent SASL APIs and you'd still have to do something about SSF for backwards compatibility. Nico -- From alexey.melnikov@isode.com Wed Aug 12 13:14:31 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 B00683A6978 for ; Wed, 12 Aug 2009 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 xDCe4WOlxF10 for ; Wed, 12 Aug 2009 13:14:30 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8419C3A6A93 for ; Wed, 12 Aug 2009 13:13:56 -0700 (PDT) Received: from [92.40.60.62] (92.40.60.62.sub.mbb.three.co.uk [92.40.60.62]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Aug 2009 21:09:06 +0100 Message-ID: <4A832155.10801@isode.com> Date: Wed, 12 Aug 2009 21:08:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Nicolas Williams Subject: Re: Determining strength of encryption provided by a GSS-API mechanism References: <4A815FC7.8000400@isode.com> <20090812181633.GG10982@Sun.COM> In-Reply-To: <20090812181633.GG10982@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable 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, 12 Aug 2009 20:14:31 -0000 Nicolas Williams wrote: >On Tue, Aug 11, 2009 at 11:42:53PM +0200, Love H=F6rnquist =C5strand wrote: > =20 > >>11 aug 2009 kl. 14:10 skrev Alexey Melnikov: >> >> =20 >> >>>Is such API already available >>> =20 >>> >>no >> =20 >> >Though we've discussed designs for APIs that allow applications to >request / determine which strength profiles to use / are in use. > =20 > Can you provide a pointer? >>>and if the answer is no, are people interested in working on =20 >>>defining it? >>> =20 >>> >>sure, I think the definition of SSF is broken, and its not simple to =20 >>understand, racing to yet another higher number seems bad. >> =20 >> >Indeed. SSF is bad, bad, bad. > >It's not possible to permanently assign a "strength" number to a >mechanism or "enctype". Strength is in the eye of the beholder and may >vary with time. And users shouldn't, and likely don't, care about >numeric strength representations -- they should, and probably do, care >about strength representations in their language, such as "strong", >names of standards (e.g., "fips140-1"), and so on. > >IMO only relative strength should matter, > This is how SSF is used, for the most part. But you are right, there is=20 no way to reclassify a cipher as weak using SSF. >and rather than use numbers we >should use names of policies, policies that can be created and >maintained locally or, in the case of policies that correspond to >standards, delivered by vendors and updated as those standards are >updated. > =20 > Well, if the WG can provide a way to control and determine which ciphers=20 are supported, this would be great. >No, that's not helpful to you: even if we had such GSS APIs you'd still >have to introduce equivalent SASL APIs and you'd still have to do >something about SSF for backwards compatibility. > =20 > From Nicolas.Williams@sun.com Wed Aug 12 14:36:16 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 CB37428C172 for ; Wed, 12 Aug 2009 14:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.224, 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 G0AbE7lNvtrG for ; Wed, 12 Aug 2009 14:36:16 -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 7A6D03A6838 for ; Wed, 12 Aug 2009 14:36:15 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7CLZlqe012583 for ; Wed, 12 Aug 2009 21:35:47 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 n7CLZjRU019818 for ; Wed, 12 Aug 2009 15:35:45 -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 n7CLP35X013177; Wed, 12 Aug 2009 16:25:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CLP2ei013176; Wed, 12 Aug 2009 16:25:02 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 12 Aug 2009 16:25:02 -0500 From: Nicolas Williams To: Alexey Melnikov Subject: Re: Determining strength of encryption provided by a GSS-API mechanism Message-ID: <20090812212501.GK10982@Sun.COM> References: <4A815FC7.8000400@isode.com> <20090812181633.GG10982@Sun.COM> <4A832155.10801@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A832155.10801@isode.com> 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: Wed, 12 Aug 2009 21:36:16 -0000 On Wed, Aug 12, 2009 at 09:08:53PM +0100, Alexey Melnikov wrote: > >Though we've discussed designs for APIs that allow applications to > >request / determine which strength profiles to use / are in use. > > Can you provide a pointer? Searching my sent box for mails with "qop" in the subject I see this: Date: Fri, 22 Sep 2006 10:33:34 -0500 From: Nicolas Williams To: Alexey Melnikov Cc: Hai Zaar , kitten@ietf.org Subject: GSS-API QoPs and SASL SSF (Re: SASL always returns ssf=56 for GSSAPI) > >IMO only relative strength should matter, > > > This is how SSF is used, for the most part. But you are right, there is > no way to reclassify a cipher as weak using SSF. Apps hardcode SSF values at build time, as do mechanisms. That means they can't be changed without rebuilding and redeploying code. That's bad. There's other things that are bad: - numbers for this just suck; policy names are much better - strength may be context-specific, as in the case of the Kerberos V GSS-API mechanism (where the enctype used is completely independent of the SASL mechanism name / GSS mech OID) > Well, if the WG can provide a way to control and determine which ciphers > are supported, this would be great. One could do this with an extension for credentials acquisition, another for security context inquiry, and a way to do policy<->QoP mapping (though one would never need it -- just for completeness). Something like: /* * Set the policy that may be used to establish security contexts, and * the policy that will be used as the default QoP (GSS_C_QOP_DEFAULT) * for per-message token functions (gss_wrap() and friends). * * (We could also just add a variant of gss_add/acquire_cred() instead * of modifying an existing cred handle.) */ OM_uint32 gss_set_cred_policy( OM_uint32 *minor_status, gss_cred_id_t input_cred, gss_OID mech, gss_cred_id_t *output_cred, gss_buffer_t context_establishement_policy, gss_buffer_t per_msg_token_policy ); OM_uint32 gss_add_cred_policy( /* same args as gss_add_cred() */ ... /* plus: */ gss_buffer_t context_establishement_policy, gss_buffer_t per_msg_token_policy ); ... /* * Find out the name of a policy that was used to establish a security * context, and the name of the policy that set the default QoP for that * security context. */ OM_uint32 gss_inquire_sec_context_policy( OM_uint32 *minor_status, gss_ctx_id_t ctx, gss_buffer_t context_establishement_policy, gss_buffer_t per_msg_token_policy ); OM_uint32 gss_qop_to_policy( OM_uint32 *minor_status, gss_buffer_t per_msg_token_policy, gss_qop_t *qop ); OM_uint32 gss_policy_to_qop( OM_uint32 *minor_status, gss_qop_t qop, gss_buffer_t per_msg_token_policy ); Nico -- From Nicolas.Williams@sun.com Wed Aug 12 15:07:01 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 BFFC53A6FA1 for ; Wed, 12 Aug 2009 15:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=0.208, 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 1DlS6imVB-GF for ; Wed, 12 Aug 2009 15:07:01 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id E23B03A6EEF for ; Wed, 12 Aug 2009 15:07:00 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7CM5fFa023213 for ; Wed, 12 Aug 2009 22:05:41 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 n7CM5fmY038983 for ; Wed, 12 Aug 2009 16:05:41 -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 n7CLt4Cj013207; Wed, 12 Aug 2009 16:55:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CLt4Sh013206; Wed, 12 Aug 2009 16:55:04 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 12 Aug 2009 16:55:04 -0500 From: Nicolas Williams To: Alexey Melnikov Subject: Re: Determining strength of encryption provided by a GSS-API mechanism Message-ID: <20090812215504.GN10982@Sun.COM> References: <4A815FC7.8000400@isode.com> <20090812181633.GG10982@Sun.COM> <4A832155.10801@isode.com> <20090812212501.GK10982@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090812212501.GK10982@Sun.COM> 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: Wed, 12 Aug 2009 22:07:01 -0000 > gss_buffer_t context_establishement_policy, > gss_buffer_t per_msg_token_policy These buffers would have policy names, in the caller's locale's codeset, or maybe just all US-ASCII. We'd also need a function to get localized policy names (and descriptions). And we'd need a namespace for standards-based policy names vs. local policy names. Plus a policy comparison function. OM_uint32 gss_display_policy( OM_uint32 *minor_status, gss_buffer_t policy, gss_buffer_t localized_name, gss_buffer_t localized_desc, int *is_context_establishement_policy, int *is_per_msg_token_policy ); A function for listing known policies would also be nice. The contents of policies would be purely local; no interchange format is needed. /* * 'result' is set to 1 if policy1 is a superset of policy2, 0 if the * two policies are equivalent, and -1 if they are disjoint or if * policy2 is a superset of policy1. * * If mech is GSS_NO_OID then the comparison is across all available * mechanisms. (Internally the framework would call the * compare_policies method for each available mechanism, and set result * to 1 or 0 only if all the comparisons output the same non-negative * value, else -1.) */ OM_uint32 gss_compare_policies( OM_uint32 *minor_status, gss_OID mech, /* may be GSS_NO_OID */ gss_buffer_t policy1, gss_buffer_t policy2, int *result ); From alexey.melnikov@isode.com Wed Aug 12 15:32:58 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 640863A6B73 for ; Wed, 12 Aug 2009 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 VEqaYaUkp0Cg for ; Wed, 12 Aug 2009 15:32:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4420E3A6A9B for ; Wed, 12 Aug 2009 15:32:57 -0700 (PDT) Received: from [92.40.60.62] (92.40.60.62.sub.mbb.three.co.uk [92.40.60.62]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Aug 2009 23:26:55 +0100 Message-ID: <4A834194.6030508@isode.com> Date: Wed, 12 Aug 2009 23:26:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Nicolas Williams Subject: Re: Determining strength of encryption provided by a GSS-API mechanism References: <4A815FC7.8000400@isode.com> <20090812181633.GG10982@Sun.COM> <4A832155.10801@isode.com> <20090812212501.GK10982@Sun.COM> In-Reply-To: <20090812212501.GK10982@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 12 Aug 2009 22:32:58 -0000 Nicolas Williams wrote: >On Wed, Aug 12, 2009 at 09:08:53PM +0100, Alexey Melnikov wrote: > > >>>Though we've discussed designs for APIs that allow applications to >>>request / determine which strength profiles to use / are in use. >>> >>> >>Can you provide a pointer? >> >> >Searching my sent box for mails with "qop" in the subject I see this: > > Date: Fri, 22 Sep 2006 10:33:34 -0500 > From: Nicolas Williams > To: Alexey Melnikov > Cc: Hai Zaar , kitten@ietf.org > Subject: GSS-API QoPs and SASL SSF (Re: SASL always returns ssf=56 for GSSAPI) > > :-). >>>IMO only relative strength should matter, >>> >>> >>This is how SSF is used, for the most part. But you are right, there is >>no way to reclassify a cipher as weak using SSF. >> >> >Apps hardcode SSF values at build time, > Actually apps don't. My server certainly doesn't. It has 2 file configuration options: min_ssf and max_ssf for controlling use of security layers. >as do mechanisms. > Mechanisms do, because they have no way of learning from GSS-API. So either mechanisms have to hardcode the highest known value, or they need to lie that they support certain SSF. >That means >they can't be changed without rebuilding and redeploying code. That's >bad. > >There's other things that are bad: > > - numbers for this just suck; policy names are much better > > Well, it means you need to have entirely different API and, more importantly, UI for managing such policies. Good UIs like this are difficult. > - strength may be context-specific, as in the case of the Kerberos V > GSS-API mechanism (where the enctype used is completely independent > of the SASL mechanism name / GSS mech OID) > > From Nicolas.Williams@sun.com Wed Aug 12 15:53:51 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 803BE3A6C37 for ; Wed, 12 Aug 2009 15:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=0.201, 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 1wGpeRyF421e for ; Wed, 12 Aug 2009 15:53:50 -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 43CBB3A69DA for ; Wed, 12 Aug 2009 15:53:50 -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 n7CMqwuW018091 for ; Wed, 12 Aug 2009 22:52:58 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 n7CMqtg4000326 for ; Wed, 12 Aug 2009 16:52:55 -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 n7CMgHQF013246; Wed, 12 Aug 2009 17:42:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CMgH30013245; Wed, 12 Aug 2009 17:42:17 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 12 Aug 2009 17:42:17 -0500 From: Nicolas Williams To: Alexey Melnikov Subject: Re: Determining strength of encryption provided by a GSS-API mechanism Message-ID: <20090812224217.GQ10982@Sun.COM> References: <4A815FC7.8000400@isode.com> <20090812181633.GG10982@Sun.COM> <4A832155.10801@isode.com> <20090812212501.GK10982@Sun.COM> <4A834194.6030508@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A834194.6030508@isode.com> 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: Wed, 12 Aug 2009 22:53:51 -0000 On Wed, Aug 12, 2009 at 11:26:28PM +0100, Alexey Melnikov wrote: > Nicolas Williams wrote: > >Searching my sent box for mails with "qop" in the subject I see this: > > :-). :) > >Apps hardcode SSF values at build time, > > > Actually apps don't. My server certainly doesn't. It has 2 file > configuration options: min_ssf and max_ssf for controlling use of > security layers. Ah, I stand corrected. > >as do mechanisms. > > > Mechanisms do, because they have no way of learning from GSS-API. So > either mechanisms have to hardcode the highest known value, or they need > to lie that they support certain SSF. Right. > >There's other things that are bad: > > > >- numbers for this just suck; policy names are much better > > > > > Well, it means you need to have entirely different API and, more > importantly, UI for managing such policies. Good UIs like this are > difficult. I have given the subject much thought, though intermittently, over the past few years. I believe the API that I've sketched for you is a very good start, and that it makes it possible to have very simple UIs for users and server configuration. The hard part is about how to express policies. E.g., a simple "must use AES" is not enough, and policies are almost unavoidably going to have mechanism-specific contents. But fortunately, because policy contents is a local problem, policy expression is not our problem here :) (Policy interchange formats are not really a problem that we need to solve either. Standard policies could be expressed in English, with the task of expressing them in machine-readable form being left to implementors.) Nico -- From Shawn.Emery@Sun.COM Sat Aug 15 23:27: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 1D6603A694F for ; Sat, 15 Aug 2009 23:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 1qxpPpf0dLgP for ; Sat, 15 Aug 2009 23:27:09 -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 5AD313A6911 for ; Sat, 15 Aug 2009 23:27:09 -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 n7G6RBRu011896 for ; Sun, 16 Aug 2009 06:27:12 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 <0KOG00C00HTUQ700@mail-amer.sun.com> for kitten@ietf.org; Sun, 16 Aug 2009 00:27:11 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [174.51.183.68]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOG002ZDHXBAG50@mail-amer.sun.com> for kitten@ietf.org; Sun, 16 Aug 2009 00:27:11 -0600 (MDT) Date: Sun, 16 Aug 2009 00:26:34 -0600 From: Shawn M Emery Subject: KITTEN: IETF 75 - 76 Sender: Shawn.Emery@Sun.COM To: kitten@ietf.org Message-id: <4A87A69A.3050408@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) 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, 16 Aug 2009 06:27:10 -0000 Folks, As our AD (Tim) had mentioned at the last session, we should gage interest in the working group going forward by polling the members to see what items they would be willing to work on between now and IETF 76 (starting November 8). Tim would like one or two new drafts to be created as an indicator. Love had given a set of new work items that would be of interest, as follows: 1. initialization/new credentials 2. listing/iterating credentials 3. exporting/importing credentials 4. error message reporting 5. asynchronous calls ...along with Alexey's recent request for policy/encryption strength. We are looking for authors and editors for any of these new items or something else that you would like to see developed within KITTEN. -- Shawn. From alexey.melnikov@isode.com Sun Aug 16 03:32:23 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 CEB743A6CD9 for ; Sun, 16 Aug 2009 03:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 sLfJKkn1qBDx for ; Sun, 16 Aug 2009 03:32:23 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D67493A6B64 for ; Sun, 16 Aug 2009 03:32:22 -0700 (PDT) Received: from [92.40.68.31] (92.40.68.31.sub.mbb.three.co.uk [92.40.68.31]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 16 Aug 2009 11:32:26 +0100 Message-ID: <4A87E02D.7030503@isode.com> Date: Sun, 16 Aug 2009 11:32:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Shawn M Emery Subject: Re: KITTEN: IETF 75 - 76 References: <4A87A69A.3050408@sun.com> In-Reply-To: <4A87A69A.3050408@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sun, 16 Aug 2009 10:32:23 -0000 Shawn M Emery wrote: > Folks, Hi Shawn, > As our AD (Tim) had mentioned at the last session, we should gage > interest in the working group going forward by polling the members to > see what items they would be willing to work on between now and IETF > 76 (starting November 8). Tim would like one or two new drafts to be > created as an indicator. > > Love had given a set of new work items that would be of interest, as > follows: > > 1. initialization/new credentials I agree this is an issue, current APIs are awkward/insufficient in this area. > 2. listing/iterating credentials > 3. exporting/importing credentials I think Leif has expressed interest in (3) before. > 4. error message reporting > 5. asynchronous calls The last 2 are generally required for use by modern applications. > ...along with Alexey's recent request for policy/encryption strength. > > We are looking for authors and editors for any of these new items or > something else that you would like to see developed within KITTEN. I can't volunteer to edit anything at the moment, but I will review and comment. From Nicolas.Williams@sun.com Sun Aug 16 17:02:00 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 088513A6842 for ; Sun, 16 Aug 2009 17:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.158, 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 7zpOcQzoFFT4 for ; Sun, 16 Aug 2009 17:01:59 -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 40CE13A6851 for ; Sun, 16 Aug 2009 17:01:59 -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 n7H023e4017389 for ; Mon, 17 Aug 2009 00:02:03 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 n7H023KJ009208 for ; Sun, 16 Aug 2009 18:02:03 -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 n7GNpM4S002664; Sun, 16 Aug 2009 18:51:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7GNpMqF002663; Sun, 16 Aug 2009 18:51:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 16 Aug 2009 18:51:22 -0500 From: Nicolas Williams To: Shawn M Emery Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090816235122.GP1043@Sun.COM> References: <4A87A69A.3050408@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A87A69A.3050408@sun.com> 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: Mon, 17 Aug 2009 00:02:00 -0000 On Sun, Aug 16, 2009 at 12:26:34AM -0600, Shawn M Emery wrote: > Love had given a set of new work items that would be of interest, as > follows: > > 1. initialization/new credentials > 2. listing/iterating credentials > 3. exporting/importing credentials (1) is a complex matter as it requires interaction with users and needs to cover such things as principal name, password, new password, PIN, PIN change and other prompts. A design is certainly possible. (2) is really listing of principal names for which the caller has credentials (we can already list mechanisms for which the caller has credentials). This is likely a difficult thing to design since we will want to be able to control what principals GSS_Accept_sec_context() can accept sec contexts for, and that means a significant revamp of the semantics of CREDENTIAL HANDLEs _or_ a replacement for GSS_Accept_sec_context(). > 4. error message reporting Yes. (I still believe in the "PGSSAPI" idea where, in the C bindings, we change the semantics and type of the minor_status argument, though in a binary backwards compatible way. I can expand if desired.) > 5. asynchronous calls Developers can use threads to work around the lack of these, so it seems to me that these should be a lower priority. > ...along with Alexey's recent request for policy/encryption strength. Yes. This should be, IMO, a high priority. > We are looking for authors and editors for any of these new items or > something else that you would like to see developed within KITTEN. I'll edit, but I need co-authors who'll contribute text, API designs, and energy to the list. Nico -- From lha@kth.se Mon Aug 17 09:50:20 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 7D83428C277 for ; Mon, 17 Aug 2009 09:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 gzLmBmdyCbGE for ; Mon, 17 Aug 2009 09:50:18 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 5274428C288 for ; Mon, 17 Aug 2009 09:50:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 77AC9155B56; Mon, 17 Aug 2009 18:49:50 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9AhRaeE40+5l; Mon, 17 Aug 2009 18:49:48 +0200 (CEST) Received: from [10.0.1.6] (c80-216-69-25.bredband.comhem.se [80.216.69.25]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 436D615590F; Mon, 17 Aug 2009 18:49:39 +0200 (CEST) Subject: Re: KITTEN: IETF 75 - 76 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/alternative; boundary=Apple-Mail-183--509845363 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090816235122.GP1043@Sun.COM> Date: Mon, 17 Aug 2009 18:49:37 +0200 Message-Id: <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) 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: Mon, 17 Aug 2009 16:50:20 -0000 --Apple-Mail-183--509845363 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes 17 aug 2009 kl. 01:51 skrev Nicolas Williams: > On Sun, Aug 16, 2009 at 12:26:34AM -0600, Shawn M Emery wrote: >> Love had given a set of new work items that would be of interest, as >> follows: >> >> 1. initialization/new credentials >> 2. listing/iterating credentials >> 3. exporting/importing credentials > > (1) is a complex matter as it requires interaction with users and > needs > to cover such things as principal name, password, new password, PIN, > PIN > change and other prompts. A design is certainly possible. > > (2) is really listing of principal names for which the caller has > credentials (we can already list mechanisms for which the caller has > credentials). This is likely a difficult thing to design since we > will > want to be able to control what principals GSS_Accept_sec_context() > can > accept sec contexts for, and that means a significant revamp of the > semantics of CREDENTIAL HANDLEs _or_ a replacement for > GSS_Accept_sec_context(). accept sec context is not really intresting since it doesn't make thinks not work. init sec context however it mostly useless since the consumers don't know about what credentials they have. have a list of mechs there is credentials for is also mostly useless, i have lha@SU.SE (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos) E.KTH.SE (sasl-digest-md5), lha@LKDC.SHA1:EA35DAB08BD8EC833C160FAFCDF03E4B13F72D6B (Kerberos) any many other, knowing that I have some Kerberos credentals is mostly useless. Its not even possible to build ui to do specific selection, or selection other then providing a text field that you can do gss_import_name(GSS_C_NT_USER) on and hope that it work. >> 4. error message reporting > > Yes. (I still believe in the "PGSSAPI" idea where, in the C bindings, > we change the semantics and type of the minor_status argument, > though in > a binary backwards compatible way. I can expand if desired.) Lets redo the api, ISC is broken as it since there is no way to add new tokens. >> 5. asynchronous calls > > Developers can use threads to work around the lack of these, so it > seems > to me that these should be a lower priority. I disagree, threads consume lots of resources that and are very complicated to use. >> ...along with Alexey's recent request for policy/encryption strength. > > Yes. This should be, IMO, a high priority. And not over engineered. Let's solve the SASL problem and nothing more. >> We are looking for authors and editors for any of these new items or >> something else that you would like to see developed within KITTEN. > > I'll edit, but I need co-authors who'll contribute text, API designs, > and energy to the list. Love --Apple-Mail-183--509845363 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Sun, Aug 16, 2009 at 12:26:34AM -0600, Shawn M Emery = wrote:
Love had given a set of new work = items that would be of interest, as
follows:

  1. = initialization/new credentials
=   2. listing/iterating credentials
  3. exporting/importing = credentials

(1) is a complex matter as it requires = interaction with users and needs
to cover such things as principal = name, password, new password, PIN, PIN
change and other prompts. =  A design is certainly possible.

(2) is really listing of = principal names for which the caller has
credentials (we can already = list mechanisms for which the caller has
credentials).  This is = likely a difficult thing to design since we will
want to be able to = control what principals GSS_Accept_sec_context() can
accept sec = contexts for, and that means a significant revamp of the
semantics of = CREDENTIAL HANDLEs _or_ a replacement = for
GSS_Accept_sec_context().

accept sec context is not really intresting since it doesn't make = thinks not work. init sec context however it mostly useless since the = consumers don't know about what credentials they = have.

have a list of mechs there is credentials = for is also mostly useless, i have lha@SU.SE (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos) E.KTH.SE (sasl-digest-md5), = lha@LKDC.SHA1:EA35DAB08BD8EC833C160FAFCDF03E4B13F72D6B (Kerberos) any = many other, knowing that I have some Kerberos credentals is mostly = useless.

Its not even possible to build ui to = do specific selection, or selection other then providing a text field = that you can do gss_import_name(GSS_C_NT_USER) on and hope that it = work.

  4. error message = reporting

Yes.  (I still believe in the = "PGSSAPI" idea where, in the C bindings,
we change the semantics and = type of the minor_status argument, though in
a binary backwards = compatible way.  I can expand if = desired.)

Lets redo the api, = ISC is broken as it since there is no way to add new = tokens.

  5. asynchronous = calls

Developers can use threads to work around the = lack of these, so it seems
to me that these should be a lower = priority.

I disagree, threads = consume lots of resources that and are very complicated to = use.

...along with Alexey's recent request for = policy/encryption strength.

Yes.  This should = be, IMO, a high priority.

And = not over engineered. Let's solve the SASL problem and nothing = more.

We= are looking for authors and editors for any of these new items or =
something else that you would = like to see developed within KITTEN.

I'll edit, but = I need co-authors who'll contribute text, API designs,
and energy to = the list.

Love=


= --Apple-Mail-183--509845363-- From Nicolas.Williams@sun.com Mon Aug 17 10:37:17 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 5B43828C100 for ; Mon, 17 Aug 2009 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 vhcnRRS4KkkD for ; Mon, 17 Aug 2009 10:37:16 -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 9AFDC3A6C67 for ; Mon, 17 Aug 2009 10:37:15 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7HHbK0x007180 for ; Mon, 17 Aug 2009 17:37:20 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 n7HHbGlW022502 for ; Mon, 17 Aug 2009 11:37:16 -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 n7HHQXFH002948; Mon, 17 Aug 2009 12:26:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7HHQWZ6002947; Mon, 17 Aug 2009 12:26:32 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 17 Aug 2009 12:26:32 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090817172632.GT1043@Sun.COM> References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> 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: Mon, 17 Aug 2009 17:37:17 -0000 On Mon, Aug 17, 2009 at 06:49:37PM +0200, Love Hörnquist Åstrand wrote: > 17 aug 2009 kl. 01:51 skrev Nicolas Williams: > >(2) is really listing of principal names for which the caller has > >credentials (we can already list mechanisms for which the caller has > >credentials). This is likely a difficult thing to design since we > >will want to be able to control what principals > >GSS_Accept_sec_context() can accept sec contexts for, and that means > >a significant revamp of the semantics of CREDENTIAL HANDLEs _or_ a > >replacement for GSS_Accept_sec_context(). > > accept sec context is not really intresting since it doesn't make > thinks not work. init sec context however it mostly useless since the > consumers don't know about what credentials they have. Acceptors with creds for multiple principals have little choice but to use GSS_C_NO_CREDENTIAL and check the resulting security context to see if the acceptor principal (and mech, and, if we ever add it, QoP policy) is acceptable to the app. That's lame. I'd rather be able to acquire a CREDENTIAL HANDLE for all the principals I'm willing to accept sec contexts for and then use that. The GSS-API concept of CREDENTIAL HANDLEs is a set of credentials for the same principal, but different mechanisms. Changing this to allow it to be a set of credentials for any {mechanism, principal} seems... difficult, but perhaps fun anyways. > have a list of mechs there is credentials for is also mostly useless, > i have lha@SU.SE (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos) > E.KTH.SE (sasl-digest-md5), > lha@LKDC.SHA1:EA35DAB08BD8EC833C160FAFCDF03E4B13F72D6B (Kerberos) any > many other, knowing that I have some Kerberos credentals is mostly > useless. Yes, this problem affects initiators too. If you want to solve the Identity Selection problem _above_ the GSS-API (and I agree that the solutions do belong outside the GSS-API), then you need to solve the CREDENTIAL HANDLE issue first. [For the benefit of lurkers: in practice though you always have a "default" principal, and you have to be able to choose a principal to use in any given context. The Identity Selection problem is not as easy to solve as simply letting CREDENTIAL HANDLEs be sets of creds for any {mech, princ}, but that is a very helpful first step.] > >> 4. error message reporting > > > >Yes. (I still believe in the "PGSSAPI" idea where, in the C bindings, > >we change the semantics and type of the minor_status argument, > >though in > >a binary backwards compatible way. I can expand if desired.) > > Lets redo the api, ISC is broken as it since there is no way to add > new tokens. ISC? I don't want to re-design the API from scratch if we can avoid it. Moreover, all of the enhancements we're discussing are incremental, _except_ for this one and the multi-princ credentials one; this one fits right in as proposed above, and we can solve the multi-princ credentials problem incrementally too. If we had more problems to fix that are not incremental then I'd agree on a whole re-design. Also, I don't agree that there's no way to add new token types, if that's what you meant. You could add support for new tokens (e.g., re-key tokens, default QoP cipher change, ...) as follows: a) provide a way to indicate that the app supports the new thing (this could be a credential handle property, but it could also be done using the PGSSAPI proposal); b) provide new functions to output the new token types; c) provide new major status codes (for existing per-msg token generating functions) indicating that the caller must first engage in some other type of token exchange (e.g., re-key); d) provide new major status codes (for existing per-msg token consuming functions) indicating that an input token is of the wrong type (so the caller may then call the correct function with it). (a) and (b) are the bare minimum that must be done, but you need (c) if you want async re-keys (i.e., if you want the mech to decide when a re-key is needed). (d) is not strictly needed: app protocols have to be revised anyways to use new token types, so we can expect apps to identify token types. > >> 5. asynchronous calls > > > >Developers can use threads to work around the lack of these, so it > >seems > >to me that these should be a lower priority. > > I disagree, threads consume lots of resources that and are very > complicated to use. I agree that async versions are desirable. I believe the other items on Shawn's list are more important though, that's all. > >>...along with Alexey's recent request for policy/encryption strength. > > > >Yes. This should be, IMO, a high priority. > > And not over engineered. Let's solve the SASL problem and nothing more. I agree. I want nothing to do with, for example, a language for expressing cryptographic quality of protection policies. I want only a way to obtain non-hard-coded, context-specific policies. The key is context-specific (because the Kerberos mech can use any enctype in a context-specific way -- you can't tell which it is just from the mech's OID, unlike SCRAM). (A context-specific SSF number is acceptable to me as a way to support SASL.) Nico -- From leifj@mnt.se Mon Aug 17 15:13: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 537E83A6D9F for ; Mon, 17 Aug 2009 15:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 CpRwsd-Z4-oG for ; Mon, 17 Aug 2009 15:13:32 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 455CE3A6B42 for ; Mon, 17 Aug 2009 15:13:31 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so743175eye.31 for ; Mon, 17 Aug 2009 15:13:32 -0700 (PDT) Received: by 10.210.113.16 with SMTP id l16mr3879155ebc.56.1250547212878; Mon, 17 Aug 2009 15:13:32 -0700 (PDT) Received: from klapautius.localnet (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) by mx.google.com with ESMTPS id 5sm294514eyf.18.2009.08.17.15.13.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Aug 2009 15:13:32 -0700 (PDT) From: Leif Johansson Organization: mnt.se To: kitten@ietf.org Subject: Re: KITTEN: IETF 75 - 76 Date: Tue, 18 Aug 2009 00:13:28 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-14-generic; KDE/4.2.2; i686; ; ) References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> In-Reply-To: <4A87E02D.7030503@isode.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908180013.29152.leifj@mnt.se> Cc: Shawn M Emery X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 22:13:33 -0000 On Sunday 16 August 2009 12.32.13 Alexey Melnikov wrote: > Shawn M Emery wrote: > > Folks, > > Hi Shawn, > > > As our AD (Tim) had mentioned at the last session, we should gage > > interest in the working group going forward by polling the members to > > see what items they would be willing to work on between now and IETF > > 76 (starting November 8). Tim would like one or two new drafts to be > > created as an indicator. > > > > Love had given a set of new work items that would be of interest, as > > follows: > > > > 1. initialization/new credentials > > I agree this is an issue, current APIs are awkward/insufficient in this > area. > > > 2. listing/iterating credentials > > 3. exporting/importing credentials > > I think Leif has expressed interest in (3) before. That was exporting unfinished contexts actually - slightly different. > > > 4. error message reporting > > 5. asynchronous calls > > The last 2 are generally required for use by modern applications. hmm, is asynchronous calls related to exportable contexts perhaps...? Cheers Leif From Nicolas.Williams@sun.com Mon Aug 17 15:35: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 3E0AF3A6CDE for ; Mon, 17 Aug 2009 15:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=0.151, 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 eih7MJhtq-Vo for ; Mon, 17 Aug 2009 15:35:49 -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 83B273A6ACE for ; Mon, 17 Aug 2009 15:35:49 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7HMZm2K003188 for ; Mon, 17 Aug 2009 22:35:49 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 n7HMZmFv024415 for ; Mon, 17 Aug 2009 16:35:48 -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 n7HMP4LN003234; Mon, 17 Aug 2009 17:25:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7HMP1QM003233; Mon, 17 Aug 2009 17:25:01 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 17 Aug 2009 17:25:01 -0500 From: Nicolas Williams To: Leif Johansson Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090817222500.GC1043@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908180013.29152.leifj@mnt.se> 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: Mon, 17 Aug 2009 22:35:50 -0000 On Tue, Aug 18, 2009 at 12:13:28AM +0200, Leif Johansson wrote: > > I think Leif has expressed interest in (3) before. > > That was exporting unfinished contexts actually - slightly different. Oh yes, that too (that's trivial, of course, though exporting non-fully established contexts has to be allowed to fail). > > > 4. error message reporting > > > 5. asynchronous calls > > > > The last 2 are generally required for use by modern applications. > > hmm, is asynchronous calls related to exportable contexts perhaps...? No. Think of how gss_init_sec_context() and gss_accept_sec_context() can go off and do things like: DNS lookups, TGS exchanges, certificate validation (including OSCP and/or CRL checking), ... All those tasks must complete before those functions can return, but each of those tasks can take a long time to complete or fail to complete. I.e., we want versions of gss_init/accept_sec_context() that will do as much work as they can, then return without necessarily completing their work, instead returning some completion event object so the application can wait for completion in its event loop. The basic problem here are is that async APIs tend to be very OS-specific. But I think we can still have an OS-agnostic design IF we can rely on background threads (i.e., on a multi-threaded process model). Relying on bg-threads might not be feasible on systems where a multi-threaded process model can't be relied upon (well, on such systems the async functions can just always operate synchronously when called in a single-threaded process). Nico -- From Martin.Rex@sap.com Mon Aug 17 16:02: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 570683A6F4A for ; Mon, 17 Aug 2009 16:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 TPHQTtEHtDLe for ; Mon, 17 Aug 2009 16:02:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 5C1E528C2A4 for ; Mon, 17 Aug 2009 16:02:05 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n7HN28fV004368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 01:02:08 +0200 (MEST) From: Martin Rex Message-Id: <200908172302.n7HN27Nx008325@fs4113.wdf.sap.corp> Subject: Re: KITTEN: IETF 75 - 76 To: leifj@mnt.se Date: Tue, 18 Aug 2009 01:02:07 +0200 (MEST) In-Reply-To: <200908180013.29152.leifj@mnt.se> from "Leif Johansson" at Aug 18, 9 00:13:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 23:02:06 -0000 Leif Johansson wrote: > > That was exporting unfinished contexts actually - slightly different. exporting&importing unfinished security contexts will usually break the gssapi architecture. The context establishement calls take a number of arguments that must be the same for the initial and all iteration calls, and it is an implementation issue at which point which of these parameters is accessed. Fully established security contexts do not normally need access to credentials (the gss_cred_id_t that was provided to gss_init_sec_context or gss_accept_sec_context can be released when the security context establishment has completed or failed). During security context establishment, access to credentials might be necessary at various stages, and the caller would have to make sure the parameters during each iteration call are the same as during the first call. Credentials that are stored on a hardware token are often not transferable, and also may require a serialization of the access. > > > > > > 4. error message reporting > > > 5. asynchronous calls > > > > The last 2 are generally required for use by modern applications. > > hmm, is asynchronous calls related to exportable contexts perhaps...? What exactly do you mean by asynchronous calls?? GSS-API does not include message transport, so all calls are by definition asynchronous. Or were you thinking about the Kerberos 5 gssapi mechanisms communication with the KDC during gss_init_sec_context() (and possibly during gss_acquire_cred for some newer implementations)? -Martin From Martin.Rex@sap.com Mon Aug 17 16:10: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 023A63A6CB7 for ; Mon, 17 Aug 2009 16:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 nmSE35B0MA8m for ; Mon, 17 Aug 2009 16:10:17 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2A0AD3A6A0E for ; Mon, 17 Aug 2009 16:10:17 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n7HNA9Yo011934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 01:10:09 +0200 (MEST) From: Martin Rex Message-Id: <200908172310.n7HNA875008595@fs4113.wdf.sap.corp> Subject: Re: KITTEN: IETF 75 - 76 To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 18 Aug 2009 01:10:08 +0200 (MEST) In-Reply-To: <20090817222500.GC1043@Sun.COM> from "Nicolas Williams" at Aug 17, 9 05:25:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@sun.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 23:10:19 -0000 Nicolas Williams wrote: > > > > > hmm, is asynchronous calls related to exportable contexts perhaps...? > > No. Think of how gss_init_sec_context() and gss_accept_sec_context() > can go off and do things like: DNS lookups, TGS exchanges, certificate > validation (including OSCP and/or CRL checking), ... All those tasks > must complete before those functions can return, but each of those tasks > can take a long time to complete or fail to complete. > > I.e., we want versions of gss_init/accept_sec_context() that will do as > much work as they can, then return without necessarily completing their > work, instead returning some completion event object so the application > can wait for completion in its event loop. > > The basic problem here are is that async APIs tend to be very > OS-specific. But I think we can still have an OS-agnostic design IF we > can rely on background threads (i.e., on a multi-threaded process > model). Relying on bg-threads might not be feasible on systems where a > multi-threaded process model can't be relied upon (well, on such systems > the async functions can just always operate synchronously when called in > a single-threaded process). To me that sounds like barking up the wrong tree. If an application does not want to get blocked, it should use seperate threads for the UI and other events that it does want to do in parallel. The application should take care about and have control over each an every thread in a process. Having service APIs create additional threads invisible to the application will open a huge can of worms. Maybe you want an API to specify timeouts after which a gssapi call should give up and return an error? Ideally, that should already be configurable in an implementation specific fashion (but often is not). -Martin From Nicolas.Williams@sun.com Mon Aug 17 16:25:09 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 ABAB23A6A7C for ; Mon, 17 Aug 2009 16:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.147, 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 Qg19IsRU9OmT for ; Mon, 17 Aug 2009 16:25:08 -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 AB4C13A67F2 for ; Mon, 17 Aug 2009 16:25:07 -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 n7HNPCUd001197 for ; Mon, 17 Aug 2009 23:25:12 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 n7HNPCJx047661 for ; Mon, 17 Aug 2009 17:25:12 -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 n7HNEUd2003267; Mon, 17 Aug 2009 18:14:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7HNEUT6003266; Mon, 17 Aug 2009 18:14:30 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 17 Aug 2009 18:14:30 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090817231429.GG1043@Sun.COM> References: <200908180013.29152.leifj@mnt.se> <200908172302.n7HN27Nx008325@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908172302.n7HN27Nx008325@fs4113.wdf.sap.corp> 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: Mon, 17 Aug 2009 23:25:09 -0000 On Tue, Aug 18, 2009 at 01:02:07AM +0200, Martin Rex wrote: > Leif Johansson wrote: > > > > That was exporting unfinished contexts actually - slightly different. > > exporting&importing unfinished security contexts will usually > break the gssapi architecture. We've had this argument. > The context establishement calls take a number of arguments > that must be the same for the initial and all iteration calls, > and it is an implementation issue at which point which of these > parameters is accessed. I don't see how this is an issue. The implementation can make sure that the exported partially established sec context encodes these arguments so they can be checked later after importing. > During security context establishment, access to credentials might > be necessary at various stages, and the caller would have to > make sure the parameters during each iteration call are the same > as during the first call. > > Credentials that are stored on a hardware token are often not > transferable, and also may require a serialization of the access. None of that means that we can't have a partially established security context export/import facility that is allowed to fail when non-extractable keys in tokens are involved. (Alternatively, export might succeed and the exported sec context token might just have enough information to either re-establish logged-in access to the token, or call back into a service in the process that "exported" the sec context; import could still fail, obviously.) We can agree that GSS_Export_sec_context() either MUST NOT succeed for partially established security contexts, or that it is OPTIONAL for it to succeed in the case of partially established security contexts. In the former case we can then introduce a new function that does support this feature, with all the above caveats. We should stop having this argument now. > > hmm, is asynchronous calls related to exportable contexts perhaps...? > > What exactly do you mean by asynchronous calls?? > > GSS-API does not include message transport, so all calls are > by definition asynchronous. > > Or were you thinking about the Kerberos 5 gssapi mechanisms communication > with the KDC during gss_init_sec_context() (and possibly during > gss_acquire_cred for some newer implementations)? The latter. And no, gss_acquire_cred() cannot do this (because what matters, in the krb5 case, is the target name passed to gss_init_sec_context()). And it's not just about Kerberos. PKIX-based mechanisms, such as PKU2U (or SPKM-*) may need to talk to third-parties in either the initiator, acceptor, or both cases (e.g., to validate certificates). In both cases (Kerberos and PKIX) we have not only message exchanges with KDCs, OCSP Responders, and/or CRL servers, but also potentially DNS lookups (of KDC/OCSP/CRL server names). All of these are potentially very slow, particularly in failure cases (network partitions, ...). Single-threaded, async I/O style programs that would normally remain responsive have to block in these functions, or else they must create background threads in which to do the gss_init/accept_sec_context() calls (in which case they'd be... creating async versions of gss_init/accept_sec_context(), which proves the point that they are doable). Nico -- From Nicolas.Williams@sun.com Mon Aug 17 16:31:46 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 CE71E3A6D90 for ; Mon, 17 Aug 2009 16:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.144, 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 fasXg-GLoG3n for ; Mon, 17 Aug 2009 16:31:46 -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 F3CF53A682F for ; Mon, 17 Aug 2009 16:31:45 -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 n7HNVpfa002906 for ; Mon, 17 Aug 2009 23:31:51 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 n7HNVmKN051039 for ; Mon, 17 Aug 2009 17:31:48 -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 n7HNL6N2003273; Mon, 17 Aug 2009 18:21:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7HNL6RM003272; Mon, 17 Aug 2009 18:21:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 17 Aug 2009 18:21:06 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090817232106.GH1043@Sun.COM> References: <20090817222500.GC1043@Sun.COM> <200908172310.n7HNA875008595@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908172310.n7HNA875008595@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Shawn.Emery@sun.com 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, 17 Aug 2009 23:31:46 -0000 On Tue, Aug 18, 2009 at 01:10:08AM +0200, Martin Rex wrote: > > > hmm, is asynchronous calls related to exportable contexts perhaps...? > > To me that sounds like barking up the wrong tree. > > If an application does not want to get blocked, it should use > seperate threads for the UI and other events that it does want > to do in parallel. The application should take care about > and have control over each an every thread in a process. > Having service APIs create additional threads invisible to > the application will open a huge can of worms. Of course that can be done, and that was my first response to Love. However, implementors can well do better, in terms of efficiency, if there are actual standard async variants of these. To see why consider this: default stack sizes for threads can be quite sizeable (e.g., 1MB in Solaris 32-bit, or 2MB in 64-bit). An application might have no idea how much stack space gss_init/accept_sec_context() might need. To be fair, a mechglue implementor who does the background thread thing wouldn't necessarily know either, but chances are they will (one way or another). A mechglue and mechanism implementation where both support the async functions might not even need anything more than a thread to run a small I/O event loop, with tiny stack needs since all it'd do is wait for I/O and call the application callback (which should probably post an event to the application I/O loop). > Maybe you want an API to specify timeouts after which a > gssapi call should give up and return an error? Ideally, > that should already be configurable in an implementation specific > fashion (but often is not). That's not enough. Nor is it necessary in the case where mechglue and mechanisms support thread cancellation. Of course, that's a very OS-specific feature that the C bindings don't remotely address. So yes, a timeout parameter would be nice, but it's still not enough. From lha@kth.se Tue Aug 18 21:01:36 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 AB3713A682E for ; Tue, 18 Aug 2009 21:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_SE=0.35, 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 WWoLPM5J92Vd for ; Tue, 18 Aug 2009 21:01:36 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id CD97C3A6859 for ; Tue, 18 Aug 2009 21:01:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 130EE14C135; Wed, 19 Aug 2009 06:01:10 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xgst0aqHY9kq; Wed, 19 Aug 2009 06:01:09 +0200 (CEST) Received: from [10.0.1.3] (99-52-202-108.lightspeed.snjsca.sbcglobal.net [99.52.202.108]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 2233F14EAD8; Wed, 19 Aug 2009 06:01:07 +0200 (CEST) Subject: Re: KITTEN: IETF 75 - 76 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090817172632.GT1043@Sun.COM> Date: Tue, 18 Aug 2009 10:59:59 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9CC1B781-EA9D-4FAB-8675-5BB47F6BE094@kth.se> References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> <20090817172632.GT1043@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) 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: Wed, 19 Aug 2009 04:01:36 -0000 > Yes, this problem affects initiators too. If you want to solve the > Identity Selection problem _above_ the GSS-API (and I agree that the > solutions do belong outside the GSS-API), then you need to solve the > CREDENTIAL HANDLE issue first. The credential handle problem is already solved for init sec context, if you just can get hold of them. GSS-API is part of the identity selection problem since its the holder of credentials. The application/framework will need to drive authentication and select/ try credentials as it seems approproate and remember what of them was useful. This would work today, if it was possible to get initial credentials and list existing/configured credentials Love From lha@kth.se Tue Aug 18 21:01:40 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 EC0313A6A4E for ; Tue, 18 Aug 2009 21:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_SE=0.35, 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 dajbTBbTeGRJ for ; Tue, 18 Aug 2009 21:01:40 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 17F923A6874 for ; Tue, 18 Aug 2009 21:01:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 0793214EE72; Wed, 19 Aug 2009 06:01:15 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BrObSOnxn0Jt; Wed, 19 Aug 2009 06:01:13 +0200 (CEST) Received: from [10.0.1.3] (99-52-202-108.lightspeed.snjsca.sbcglobal.net [99.52.202.108]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 7DA9A14EAD8; Wed, 19 Aug 2009 06:01:12 +0200 (CEST) Subject: Re: KITTEN: IETF 75 - 76 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090817172632.GT1043@Sun.COM> Date: Tue, 18 Aug 2009 11:05:03 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2E7A7B76-CF8C-4213-8300-3325E414204F@kth.se> References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> <20090817172632.GT1043@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) 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: Wed, 19 Aug 2009 04:01:41 -0000 17 aug 2009 kl. 10:26 skrev Nicolas Williams: > ISC? init sec context. > I don't want to re-design the API from scratch if we can avoid it. if we are doing an async api, its redoing the api. > Moreover, all of the enhancements we're discussing are incremental, > _except_ for this one and the multi-princ credentials one; this one > fits > right in as proposed above, and we can solve the multi-princ > credentials > problem incrementally too. If we had more problems to fix that are > not > incremental then I'd agree on a whole re-design. I find PGSSAPI very distasteful. > Also, I don't agree that there's no way to add new token types, if > that's what you meant. You could add support for new tokens (e.g., > re-key tokens, default QoP cipher change, ...) as follows: There is no way to add more input variables to ISC. ISC have been extended to day, for example for NFS. you have to acquire a special NFS credentials, modify the credential to select what enctypes the kernel supports, and then call ISC. This doesn't work for credential when you talk to different servers that have diffrent properties, like TLS channel bindings. I'm not worried about rekeying, if you want to tackle that we are redoing the whole gss-api model. Love From lha@kth.se Tue Aug 18 21:01:49 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 8BC5E3A6874 for ; Tue, 18 Aug 2009 21:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_SE=0.35, 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 JyPNRrnhdlv4 for ; Tue, 18 Aug 2009 21:01:48 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id C72CC3A682E for ; Tue, 18 Aug 2009 21:01:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id B949A14EAD8; Wed, 19 Aug 2009 06:01:23 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hgtA1uGHSnIM; Wed, 19 Aug 2009 06:01:22 +0200 (CEST) Received: from [10.0.1.3] (99-52-202-108.lightspeed.snjsca.sbcglobal.net [99.52.202.108]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 20B8F14ED4B; Wed, 19 Aug 2009 06:01:16 +0200 (CEST) Subject: Re: KITTEN: IETF 75 - 76 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090817172632.GT1043@Sun.COM> Date: Tue, 18 Aug 2009 11:06:41 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> <20090817172632.GT1043@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) Cc: kitten@ietf.org, Shawn 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: Wed, 19 Aug 2009 04:01:49 -0000 17 aug 2009 kl. 10:26 skrev Nicolas Williams: >>>> ...along with Alexey's recent request for policy/encryption >>>> strength. >>> >>> Yes. This should be, IMO, a high priority. >> >> And not over engineered. Let's solve the SASL problem and nothing >> more. > > I agree. I want nothing to do with, for example, a language for > expressing cryptographic quality of protection policies. I want > only a > way to obtain non-hard-coded, context-specific policies. The key is > context-specific (because the Kerberos mech can use any enctype in a > context-specific way -- you can't tell which it is just from the > mech's > OID, unlike SCRAM). (A context-specific SSF number is acceptable to > me as a way to support SASL.) OM_uint32 gss_context_sasl_ssf(OM_uint32 *minor, gss_ctx_id_t ctx, OM_uint32 *ssf); Love From lha@kth.se Tue Aug 18 21:01:53 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 00F2D3A6A50 for ; Tue, 18 Aug 2009 21:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_SE=0.35, 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 GbV0ZhXMRR20 for ; Tue, 18 Aug 2009 21:01:52 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 24F993A6A24 for ; Tue, 18 Aug 2009 21:01:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 13E7C14ED4B; Wed, 19 Aug 2009 06:01:27 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Hf0IZOkF6jDe; Wed, 19 Aug 2009 06:01:26 +0200 (CEST) Received: from [10.0.1.3] (99-52-202-108.lightspeed.snjsca.sbcglobal.net [99.52.202.108]) by smtp-2.sys.kth.se (Postfix) with ESMTP id F33DF14ED3A; Wed, 19 Aug 2009 06:01:24 +0200 (CEST) Subject: Re: KITTEN: IETF 75 - 76 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090817172632.GT1043@Sun.COM> Date: Tue, 18 Aug 2009 11:09:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <23BA3749-5F9A-46AC-B4BB-BB7188F9261A@kth.se> References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> <20090817172632.GT1043@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) 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: Wed, 19 Aug 2009 04:01:53 -0000 17 aug 2009 kl. 10:26 skrev Nicolas Williams: > Acceptors with creds for multiple principals have little choice but to > use GSS_C_NO_CREDENTIAL and check the resulting security context to > see > if the acceptor principal (and mech, and, if we ever add it, QoP > policy) > is acceptable to the app. That's lame. I'd rather be able to > acquire a > CREDENTIAL HANDLE for all the principals I'm willing to accept sec > contexts for and then use that. > > The GSS-API concept of CREDENTIAL HANDLEs is a set of credentials for > the same principal, but different mechanisms. Changing this to > allow it > to be a set of credentials for any {mechanism, principal} seems... > difficult, but perhaps fun anyways. I don't care about this now, its not a problem I ever run in to. In fact, I mostly run into the problem that app developer specify a credential handle, and for that reason the application doesn't work with aliases and other mechs that the app author though about. Love From Nicolas.Williams@sun.com Wed Aug 19 09:42:59 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 74CC53A69FB for ; Wed, 19 Aug 2009 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 DMAekLPeht0w for ; Wed, 19 Aug 2009 09:42:58 -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 884D53A68A6 for ; Wed, 19 Aug 2009 09:42:57 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JGh0kw022002 for ; Wed, 19 Aug 2009 16:43:00 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 n7JGgw1K048877 for ; Wed, 19 Aug 2009 10:42:58 -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 n7JGWGrk004034; Wed, 19 Aug 2009 11:32:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JGWFeJ004033; Wed, 19 Aug 2009 11:32:15 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 19 Aug 2009 11:32:15 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090819163215.GD1043@Sun.COM> References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> <20090817172632.GT1043@Sun.COM> <9CC1B781-EA9D-4FAB-8675-5BB47F6BE094@kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9CC1B781-EA9D-4FAB-8675-5BB47F6BE094@kth.se> 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: Wed, 19 Aug 2009 16:42:59 -0000 On Tue, Aug 18, 2009 at 10:59:59AM -0700, Love Hörnquist Åstrand wrote: > >Yes, this problem affects initiators too. If you want to solve the > >Identity Selection problem _above_ the GSS-API (and I agree that the > >solutions do belong outside the GSS-API), then you need to solve the > >CREDENTIAL HANDLE issue first. > > The credential handle problem is already solved for init sec context, > if you just can get hold of them. True. > GSS-API is part of the identity selection problem since its the holder > of credentials. > > The application/framework will need to drive authentication and select/ > try credentials as it seems approproate and remember what of them was > useful. > > This would work today, if it was possible to get initial credentials > and list existing/configured credentials Sure. An iterator following the same design principles as gss_display_status() would look like: OM_unit32 gss_list_default_cred_names( OM_uint32 *minor_status, gss_name_t *name, int *more ); From Nicolas.Williams@sun.com Wed Aug 19 09:50: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 24F8A3A6889 for ; Wed, 19 Aug 2009 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 M+uBIWIcsvWB for ; Wed, 19 Aug 2009 09:50:49 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id E67473A69E7 for ; Wed, 19 Aug 2009 09:50:48 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JGorwI026863 for ; Wed, 19 Aug 2009 16:50:53 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 n7JGoraQ054475 for ; Wed, 19 Aug 2009 10:50:53 -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 n7JGeBQk004040; Wed, 19 Aug 2009 11:40:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JGeBBH004039; Wed, 19 Aug 2009 11:40:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 19 Aug 2009 11:40:11 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090819164010.GE1043@Sun.COM> References: <4A87A69A.3050408@sun.com> <20090816235122.GP1043@Sun.COM> <77312362-85D0-4BDC-AD16-28450B38C5CB@kth.se> <20090817172632.GT1043@Sun.COM> <2E7A7B76-CF8C-4213-8300-3325E414204F@kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2E7A7B76-CF8C-4213-8300-3325E414204F@kth.se> 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: Wed, 19 Aug 2009 16:50:50 -0000 On Tue, Aug 18, 2009 at 11:05:03AM -0700, Love Hörnquist Åstrand wrote: > I find PGSSAPI very distasteful. If we could go back in time and make that first argument to all GSS functions be an opaque pointer, a handle to an abstract app/lib context, that'd be OK, yes? I'm proposing that we do just that, only without the time travel part, and with just a bit of backwards compatibility in the mechglue to detect old apps / old mechs that expect that argument to be a OM_uint32 *. That bit of backwards compatibility would be quite isolated, and it'd be very similar to existing code in MIT krb5 to intern handles (in order to distinguish between old apps and new ones, properly obtained handles would have to be interned). > >Also, I don't agree that there's no way to add new token types, if > >that's what you meant. You could add support for new tokens (e.g., > >re-key tokens, default QoP cipher change, ...) as follows: > > There is no way to add more input variables to ISC. Indeed. > ISC have been extended to day, for example for NFS. you have to > acquire a special NFS credentials, modify the credential to select > what enctypes the kernel supports, and then call ISC. This doesn't > work for credential when you talk to different servers that have > diffrent properties, like TLS channel bindings. Yes. > I'm not worried about rekeying, if you want to tackle that we are > redoing the whole gss-api model. Not really. The SSPI does it, and the SSPI is very similar to the GSS-API. Re-keying would be an incremental change, not a fundamental one (but it would require updates to app protocols in order for them to be able to use it). For SASL re-keying would be much more intrusive . No, I don't care about re-keying. From Martin.Rex@sap.com Wed Aug 19 12:24:29 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 34BF728C0EC for ; Wed, 19 Aug 2009 12:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 6WJGHM9JwLqg for ; Wed, 19 Aug 2009 12:24:28 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 58D5F3A6EB8 for ; Wed, 19 Aug 2009 12:23:55 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n7JJNxJA016742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 21:23:59 +0200 (MEST) From: Martin Rex Message-Id: <200908191923.n7JJNwWq027044@fs4113.wdf.sap.corp> Subject: Re: KITTEN: IETF 75 - 76 To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 19 Aug 2009 21:23:58 +0200 (MEST) In-Reply-To: <20090819163215.GD1043@Sun.COM> from "Nicolas Williams" at Aug 19, 9 11:32:15 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@sun.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:24:29 -0000 Nicolas Williams wrote: > > > GSS-API is part of the identity selection problem since its the holder > > of credentials. > > > > The application/framework will need to drive authentication and select/ > > try credentials as it seems approproate and remember what of them was > > useful. > > > > This would work today, if it was possible to get initial credentials > > and list existing/configured credentials > > Sure. An iterator following the same design principles as > gss_display_status() would look like: > > OM_unit32 gss_list_default_cred_names( > OM_uint32 *minor_status, > gss_name_t *name, > int *more > ); That call looks somewhat restricted to me. How about something like this: OM_uint32 gss_list_default_cred_names( OM_uint32 * minor_status, gss_name_t * name, gss_OID_set * mech_oids, int * is_default, OM_uint32 * cred_context ); That would also match what you have to feed into an explicit call to gss_acquire_cred() in order to reliably get a credentials handle for exactly and each one listed. -Martin From Martin.Rex@sap.com Wed Aug 19 12:59:32 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 C63DC3A6F53 for ; Wed, 19 Aug 2009 12:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 UC2tQHRNDqMj for ; Wed, 19 Aug 2009 12:59:32 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 891DF3A6E57 for ; Wed, 19 Aug 2009 12:58:56 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n7JJwxNC005036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 21:58:59 +0200 (MEST) From: Martin Rex Message-Id: <200908191958.n7JJwwn0029779@fs4113.wdf.sap.corp> Subject: Re: KITTEN: IETF 75 - 76 To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 19 Aug 2009 21:58:58 +0200 (MEST) In-Reply-To: <20090819164010.GE1043@Sun.COM> from "Nicolas Williams" at Aug 19, 9 11:40:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@sun.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:59:32 -0000 Nicolas Williams wrote: > > > I'm not worried about rekeying, if you want to tackle that we are > > redoing the whole gss-api model. > > Not really. The SSPI does it, and the SSPI is very similar to the > GSS-API. Re-keying would be an incremental change, not a fundamental > one (but it would require updates to app protocols in order for them to > be able to use it). For SASL re-keying would be much more intrusive . > No, I don't care about re-keying. Re-keying will require re-design of the API. I'm not aware about rekeying being available in SSPI. It must be availabe in some way for schannel, because IIS is able to perform renegotiation in order to request a client cert after having looked at the URL -- but I do not think it exists for NTLM or Kerberos 5 SSPs. If I'm wrong, do you have an URL to the Microsoft documentation describing how it works? In traditional GSS-API it is not possible to modify a security context once it has been established. And a communication might go entirely unidirectional after security context establishment for the rest of its lifetime (e.g. the data channel of an FTP with GSS-API extensions). -Martin From Nicolas.Williams@sun.com Wed Aug 19 13:39:55 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 DFEA428C10F for ; Wed, 19 Aug 2009 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=0.121, 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 9MxeVHgKmz76 for ; Wed, 19 Aug 2009 13:39:55 -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 179393A6D27 for ; Wed, 19 Aug 2009 13:39:55 -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 n7JKe0iZ018074 for ; Wed, 19 Aug 2009 20:40:00 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 n7JKe0h6011374 for ; Wed, 19 Aug 2009 14:40: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 n7JKTHlo004423; Wed, 19 Aug 2009 15:29:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JKTEQw004422; Wed, 19 Aug 2009 15:29:14 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 19 Aug 2009 15:29:14 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090819202914.GI1043@Sun.COM> References: <20090819163215.GD1043@Sun.COM> <200908191923.n7JJNwWq027044@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908191923.n7JJNwWq027044@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Shawn.Emery@sun.com 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, 19 Aug 2009 20:39:56 -0000 On Wed, Aug 19, 2009 at 09:23:58PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > > GSS-API is part of the identity selection problem since its the holder > > > of credentials. > > > > > > The application/framework will need to drive authentication and select/ > > > try credentials as it seems approproate and remember what of them was > > > useful. > > > > > > This would work today, if it was possible to get initial credentials > > > and list existing/configured credentials > > > > Sure. An iterator following the same design principles as > > gss_display_status() would look like: > > > > OM_unit32 gss_list_default_cred_names( > > OM_uint32 *minor_status, > > gss_name_t *name, > > int *more > > ); > > That call looks somewhat restricted to me. It is. It should be sufficient however. (Here name would be an MN.) If you care about specific mechs you could then call gss_add_cred() with each name output by gss_list_default_cred_names() and inquire the result. > How about something like this: > > OM_uint32 gss_list_default_cred_names( > OM_uint32 * minor_status, > gss_name_t * name, > gss_OID_set * mech_oids, > int * is_default, > OM_uint32 * cred_context > ); What's "cred_context"? Would that correspond to the 'more' argument in my variant? But yes, it'd be quite useful (though not strictly necessary) to output a mech OID set and is_default. As long as only mech OIDs that are all in the same family (and therefore have the same MN/exported name token forms) are allowed to appear in mech_oids. Nico -- From Nicolas.Williams@sun.com Wed Aug 19 13:41: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 2410A3A6D49 for ; Wed, 19 Aug 2009 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=0.119, 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 3OBM2iDH1FGx for ; Wed, 19 Aug 2009 13:41:41 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id C676628C2DC for ; Wed, 19 Aug 2009 13:41:38 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JKfiYF010480 for ; Wed, 19 Aug 2009 20:41:44 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 n7JKfhKR012560 for ; Wed, 19 Aug 2009 14:41:43 -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 n7JKUwRH004429; Wed, 19 Aug 2009 15:30:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JKUuQL004428; Wed, 19 Aug 2009 15:30:56 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 19 Aug 2009 15:30:56 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090819203055.GJ1043@Sun.COM> References: <20090819164010.GE1043@Sun.COM> <200908191958.n7JJwwn0029779@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908191958.n7JJwwn0029779@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Shawn.Emery@sun.com 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, 19 Aug 2009 20:41:42 -0000 On Wed, Aug 19, 2009 at 09:58:58PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > > I'm not worried about rekeying, if you want to tackle that we are > > > redoing the whole gss-api model. > > > > Not really. The SSPI does it, and the SSPI is very similar to the > > GSS-API. Re-keying would be an incremental change, not a fundamental > > one (but it would require updates to app protocols in order for them to > > be able to use it). For SASL re-keying would be much more intrusive . > > No, I don't care about re-keying. > > Re-keying will require re-design of the API. I don't agree. It should be an incremental change to the API, though requiring changes to app protocols. > I'm not aware about rekeying being available in SSPI. It is, when used for TLS. > In traditional GSS-API it is not possible to modify a security > context once it has been established. And a communication might That's not a problem. > go entirely unidirectional after security context establishment > for the rest of its lifetime (e.g. the data channel of an FTP > with GSS-API extensions). That's an app protocol problem (see previous caveats that re-keying _obviously_ would require app protocol changes). From Martin.Rex@sap.com Wed Aug 19 15:11:05 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 25DC23A6D48 for ; Wed, 19 Aug 2009 15:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.781 X-Spam-Level: X-Spam-Status: No, score=-5.781 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 xLqJZL08+Hh8 for ; Wed, 19 Aug 2009 15:11:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 275573A6810 for ; Wed, 19 Aug 2009 15:11:02 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n7JMB6sC010688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 00:11:07 +0200 (MEST) From: Martin Rex Message-Id: <200908192211.n7JMB5d3007759@fs4113.wdf.sap.corp> Subject: Re: KITTEN: IETF 75 - 76 To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 20 Aug 2009 00:11:05 +0200 (MEST) In-Reply-To: <20090819203055.GJ1043@Sun.COM> from "Nicolas Williams" at Aug 19, 9 03:30:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@sun.com, Martin.Rex@sap.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 22:11:05 -0000 Nicolas Williams wrote: > > > And a communication might > > go entirely unidirectional after security context establishment > > for the rest of its lifetime (e.g. the data channel of an FTP > > with GSS-API extensions). > > That's an app protocol problem (see previous caveats that re-keying > _obviously_ would require app protocol changes). When I built our application framing protocol for exchanging GSS-API protected data in 1996, I added a capability for security context refresh into that framing protocol in order to support security context refresh for the Kerberos 5 gssapi mechanism, because rfc1964 compliant Kerberos 5 mechanisms expire their security contexts. (Microsoft tried it during W2K beta3 to enforce security context expiration in their Kerberos 5 SSP, but it created operational problems which none of their apps was able to cope with, that they reverted that change in W2K rc1). When the security context lifetime drops below a certain threshold, my app will poll the validity of the credentials to check whether they are valid longer than the remaining security context lifetime, it will then periodically attempt to refresh the security context prior to sending protected messages on a security context that is close to expiration. When the establishment of a new security context succeeds (same target and src_name), then the old security context is deleted and the new one is used for the protection of future messages. Technically, this has always been possible with all existing gssapi mechanisms at the application level. Just that hardly anyone seems to be doing it. The issues one has to deal with are: Unavailability of credentials, credentials expiration, failure to establish a new security context (the previous one is still around), not getting into a deadly embrace when the server wants the client to do a refresh, but the client is unable (or unwilling) to comply. Stuffing parts of that below gssapi will significantly increase the complexity of a gssapi mechanis, the gss-api semantics, need additional API-calls -- while still requiring significant changes/support from the application side. IMHO -- if the functionality is needed, it can be, and should be built at the application level entirely -- and it will work just fine with all existing gssapi mechanisms. -Martin From Nicolas.Williams@sun.com Wed Aug 19 15:25:32 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 28D3B3A69DE for ; Wed, 19 Aug 2009 15:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.903 X-Spam-Level: X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.143, 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 vKIWgt6ntdk9 for ; Wed, 19 Aug 2009 15:25:31 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id E85E03A6C93 for ; Wed, 19 Aug 2009 15:25:24 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JMPSbB001821 for ; Wed, 19 Aug 2009 22:25:28 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 n7JMPRDL054744 for ; Wed, 19 Aug 2009 16:25:27 -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 n7JMEjZS004568; Wed, 19 Aug 2009 17:14:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JMEf5j004567; Wed, 19 Aug 2009 17:14:41 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 19 Aug 2009 17:14:41 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090819221441.GR1043@Sun.COM> References: <20090819203055.GJ1043@Sun.COM> <200908192211.n7JMB5d3007759@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908192211.n7JMB5d3007759@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Shawn.Emery@sun.com 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, 19 Aug 2009 22:25:32 -0000 On Thu, Aug 20, 2009 at 12:11:05AM +0200, Martin Rex wrote: > IMHO -- if the functionality is needed, it can be, and should be > built at the application level entirely -- and it will work > just fine with all existing gssapi mechanisms. I agree. No one is actually proposing to add re-keying to the GSS-API, so let's not bother. One might argue that with sundry extensions the GSS-API would be a useful API for using TLS, much as with the SSPI, therefore we should add support for re-keying and other TLS-isms. No one is proposing that either, but if some one did propose it and intended to implement, then I'd probably support such a proposal. From Martin.Rex@sap.com Thu Aug 20 08:10:01 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 0E8BF3A6CD6 for ; Thu, 20 Aug 2009 08:10:01 -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.432, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 5PignUjBLsLn for ; Thu, 20 Aug 2009 08:10:00 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id EA71C3A6BD5 for ; Thu, 20 Aug 2009 08:09:59 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n7KF9M1o018298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 17:09:22 +0200 (MEST) From: Martin Rex Message-Id: <200908201509.n7KF9JVH010226@fs4113.wdf.sap.corp> Subject: Re: KITTEN: IETF 75 - 76 To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 20 Aug 2009 17:09:19 +0200 (MEST) In-Reply-To: <20090819202914.GI1043@Sun.COM> from "Nicolas Williams" at Aug 19, 9 03:29:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@sun.com, Martin.Rex@sap.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 15:10:01 -0000 Nicolas Williams wrote: > > > > > > Sure. An iterator following the same design principles as > > > gss_display_status() would look like: > > > > > > OM_unit32 gss_list_default_cred_names( > > > OM_uint32 *minor_status, > > > gss_name_t *name, > > > int *more > > > ); > > > > That call looks somewhat restricted to me. > > It is. It should be sufficient however. (Here name would be an MN.) An MN means that it refers to a singular identity/name in one particular namespace, it does _not_ imply a single mechanism (oid) only. A Kerberos principal is going to be an MN for the rfc1964/rfc4121 mech OID, for the pre-rfc1964 mechoid and for the IAKERB mechoid. But I would NOT want to require the name to be an MN here! > > If you care about specific mechs you could then call gss_add_cred() with > each name output by gss_list_default_cred_names() and inquire the > result. gss_add_cred() is completely broken by design (unfortunately it was too late in the process when I complained about this brokenness). gss_add_cred() can only add components, and it begins either with a default credential (one that gss_acquire_cred() would create when given a GSS_C_NO_OID_SET list of mechanism OIDs), or with an explicitly supplied credential. So if you want to create a credential with a single mech_oid, you can NOT use gss_add_cred() for that purpose, you MUST use gss_acquire_cred() with a gss_OID_set containing that one mech_oid instead. > > > How about something like this: > > > > OM_uint32 gss_list_default_cred_names( > > OM_uint32 * minor_status, > > gss_name_t * name, > > gss_OID_set * mech_oids, > > int * is_default, > > OM_uint32 * cred_context > > ); > > What's "cred_context"? Would that correspond to the 'more' argument in > my variant? Yup. similar to rfc-2744 definition of gss_display_status, where there is a "OM_uint32 * message context" parameter. > > But yes, it'd be quite useful (though not strictly necessary) to output > a mech OID set and is_default. As long as only mech OIDs that are all > in the same family (and therefore have the same MN/exported name token > forms) are allowed to appear in mech_oids. I do not want to require that the returned name is an MN (because this would take away the possibility for the gssapi mechanism to select/negotiate the best common mechanism and _require_ the user to perform an a-priori conscious selection. Thinking about it, I would actually want to add two more function parameters: OM_uint32 * lifetime, gss_bufFer_t descriptive_message, to allow application writer to show additional information in selection UIs that they show to users. :) -Martin From Nicolas.Williams@sun.com Thu Aug 20 08:47:18 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 A1EC628C190 for ; Thu, 20 Aug 2009 08:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.132, 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 6msh6hPDB3mr for ; Thu, 20 Aug 2009 08:47:17 -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 C4AA328C115 for ; Thu, 20 Aug 2009 08:47:17 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7KFlN3q020630 for ; Thu, 20 Aug 2009 15:47:23 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 n7KFlNRx051411 for ; Thu, 20 Aug 2009 09:47:23 -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 n7KFadl2005015; Thu, 20 Aug 2009 10:36:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7KFac7S005014; Thu, 20 Aug 2009 10:36:38 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 20 Aug 2009 10:36:38 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090820153638.GW1043@Sun.COM> References: <20090819202914.GI1043@Sun.COM> <200908201509.n7KF9JVH010226@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908201509.n7KF9JVH010226@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Shawn.Emery@sun.com 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, 20 Aug 2009 15:47:18 -0000 On Thu, Aug 20, 2009 at 05:09:19PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > It is. It should be sufficient however. (Here name would be an MN.) > > An MN means that it refers to a singular identity/name in one > particular namespace, it does _not_ imply a single mechanism (oid) only. I made that clear further down where I referred to mech families. > A Kerberos principal is going to be an MN for the rfc1964/rfc4121 mech OID, > for the pre-rfc1964 mechoid and for the IAKERB mechoid. > > But I would NOT want to require the name to be an MN here! How could it be anything but? Oh sure, for a family of mechanisms the name could be one that's imported with GSS_Import_name() and a mech-specific name type OID, or GSS_C_NULL_OID, and not canonicalized. But such a name would likely not be useful for credential acquisition for other mechanisms outside that family. > I do not want to require that the returned name is an MN (because this > would take away the possibility for the gssapi mechanism to > select/negotiate the best common mechanism and _require_ the user to > perform an a-priori conscious selection. I don't follow this. > Thinking about it, I would actually want to add two more function > parameters: > OM_uint32 * lifetime, > gss_bufFer_t descriptive_message, > > to allow application writer to show additional information in > selection UIs that they show to users. :) What would descriptive_message have? A description of the mechanism/mechanism family? What about lifetime? Why is that necessary? Sure, we could put all outputs of GSS_Inquire_cred*() here. Heck, cred_usage seems a lot more useful that lifetime in this context. From Martin.Rex@sap.com Thu Aug 20 11:00: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 E95F43A6EDB for ; Thu, 20 Aug 2009 11:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tkUfG4GHzdfb for ; Thu, 20 Aug 2009 11:00:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9DC553A6B87 for ; Thu, 20 Aug 2009 11:00:27 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n7KI0VJO002183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 20:00:31 +0200 (MEST) From: Martin Rex Message-Id: <200908201800.n7KI0Uqp020684@fs4113.wdf.sap.corp> Subject: Re: KITTEN: IETF 75 - 76 To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 20 Aug 2009 20:00:30 +0200 (MEST) In-Reply-To: <20090820153638.GW1043@Sun.COM> from "Nicolas Williams" at Aug 20, 9 10:36:38 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@sun.com, Martin.Rex@sap.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:00:29 -0000 Nicolas Williams wrote: > > On Thu, Aug 20, 2009 at 05:09:19PM +0200, Martin Rex wrote: > > > > Thinking about it, I would actually want to add two more function > > parameters: > > OM_uint32 * lifetime, > > gss_bufFer_t descriptive_message, > > > > to allow application writer to show additional information in > > selection UIs that they show to users. :) > > What would descriptive_message have? A description of the > mechanism/mechanism family? An implementation specific text provided to (human) end users that will help them to recognize/distinguish the nature or purpose of the particular credential. > > What about lifetime? Why is that necessary? In order to distinguish valid from expired credentials right away. The creation (or refresh) of credentials is still a local matter, and the information that credentials are available in theory, but unusable because they're expired is quite helpful. > > Sure, we could put all outputs of GSS_Inquire_cred*() here. I see a difference here. GSS_Inquire_cred() is about _real_ credential handles. The new API call is about _conceivable_ credentials which the mechanism does not actually need to create. If you look at the spec, gss_acquire_cred() and gss_inquire_cred() can fail with GSS_S_CREDENTIALS_EXPIRED, and when they do, the caller does not get any information about the credentials at all. With the new API call, expired credentials still don't have to be created -- the returned information is about "conceivable" credentials only, not real ones. > > Heck, cred_usage seems a lot more useful that lifetime in this context. Now that you mention it -- I would like a cred_usage INPUT parameter here! > > > A Kerberos principal is going to be an MN for the rfc1964/rfc4121 mech OID, > > for the pre-rfc1964 mechoid and for the IAKERB mechoid. > > > > But I would NOT want to require the name to be an MN here! > > How could it be anything but? Oh sure, for a family of mechanisms the > name could be one that's imported with GSS_Import_name() and a > mech-specific name type OID, or GSS_C_NULL_OID, and not canonicalized. > But such a name would likely not be useful for credential acquisition > for other mechanisms outside that family. > > > I do not want to require that the returned name is an MN (because this > > would take away the possibility for the gssapi mechanism to > > select/negotiate the best common mechanism and _require_ the user to > > perform an a-priori conscious selection. On a Windows platform, there might be a multi-mechanism offering ntlm _and_ Kerberos 5. In theory these use distinct namespaces, in practice, a mapping is possible if they both refer to an account in a W2K+ Active Directory. Do we want an API call that can only enumerate credentials for individual mechanisms, or more appropriately, an API call that can enumerate aggregate credentials with names from distinct namespaces. Possible namespaces for the above could be NameUserPrincipal, NameSamCompatible, and even an enterprise name (which is, AFAIK not an MN), without precluding an aggregate credential that still allows negotiation of the actual mechanism to be used. -Martin From Nicolas.Williams@sun.com Thu Aug 20 11:51: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 91DA03A6A95 for ; Thu, 20 Aug 2009 11:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.146, 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 zzZq0PR9IkGt for ; Thu, 20 Aug 2009 11:51:37 -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 AEAFB3A691D for ; Thu, 20 Aug 2009 11:51:37 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7KIc5jm022635 for ; Thu, 20 Aug 2009 18:38:05 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 n7KIc42r052624 for ; Thu, 20 Aug 2009 12:38:05 -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 n7KIRLOM005277; Thu, 20 Aug 2009 13:27:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7KIRLKM005276; Thu, 20 Aug 2009 13:27:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 20 Aug 2009 13:27:21 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090820182721.GB1043@Sun.COM> References: <20090820153638.GW1043@Sun.COM> <200908201800.n7KI0Uqp020684@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908201800.n7KI0Uqp020684@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Shawn.Emery@sun.com 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, 20 Aug 2009 18:51:38 -0000 On Thu, Aug 20, 2009 at 08:00:30PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > What about lifetime? Why is that necessary? > > In order to distinguish valid from expired credentials right away. That only requires a boolean :) > > Sure, we could put all outputs of GSS_Inquire_cred*() here. > > I see a difference here. GSS_Inquire_cred() is about _real_ credential > handles. The new API call is about _conceivable_ credentials which > the mechanism does not actually need to create. Do you mean that, for example, if you have expired Kerberos creds then this function could still return the principal name associated with them, even though the creds are expired? Or that if you have no creds, not even expired ones, but the mechanisms could derive a principal name(s) from your local user ID, then this function could return that? > > Heck, cred_usage seems a lot more useful that lifetime in this context. > > Now that you mention it -- I would like a cred_usage INPUT parameter here! I thought so :) > > > But I would NOT want to require the name to be an MN here! > > [...] > On a Windows platform, there might be a multi-mechanism offering > ntlm _and_ Kerberos 5. In theory these use distinct namespaces, > in practice, a mapping is possible if they both refer to an > account in a W2K+ Active Directory. That's not true in all configurations, but OK. I'd be OK with that provided that there was some name mapping function that, given an MN, returns a generic NAME object that the MN can be "canonicalized" to. > Do we want an API call that can only enumerate credentials for > individual mechanisms, or more appropriately, an API call that can > enumerate aggregate credentials with names from distinct namespaces. I want an API that is mechanism/mechanism-family specific, at least as an option. Nico --