From iesg-secretary@ietf.org Mon May 2 10:31:05 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BF7E0790; Mon, 2 May 2011 10:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbp3plqdIICt; Mon, 2 May 2011 10:31:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F38E079B; Mon, 2 May 2011 10:31:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502173103.28559.76887.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 10:31:03 -0700 Cc: kitten mailing list , kitten chair , RFC Editor Subject: [kitten] Document Action: 'Moving DIGEST-MD5 to Historic' to Informational RFC (draft-ietf-kitten-digest-to-historic-04.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 17:31:05 -0000 The IESG has approved the following document: - 'Moving DIGEST-MD5 to Historic' (draft-ietf-kitten-digest-to-historic-04.txt) as an Informational RFC This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-kitten-digest-to-historic/ Technical Summary The DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism has known security and interoperability problems. This memo recommends that RFC 2831 be moved to Historic status, and that the DIGEST-MD5 mechanism be marked as OBSOLETE in the IANA Registry. Working Group Summary This document is a product of the SASL and KITTEN Working Groups (which merged during the lifetime of the document). Document Quality This document passed a Working Group Last Call in the SASL and KITTEN Working Groups with no major concerns. Personnel Tom Yu (tlyu@mit.edu) is the document shepherd Stephen Farrell (stephen.farrell@cs.tcd.ie) is the responsible AD. From Internet-Drafts@ietf.org Fri May 6 11:30:34 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CF9E07C3; Fri, 6 May 2011 11:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQFVCI60EadY; Fri, 6 May 2011 11:30:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88018E07C8; Fri, 6 May 2011 11:30:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506183005.26272.40606.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 11:30:05 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D ACTION:draft-ietf-kitten-sasl-openid-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 18:30:34 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A SASL & GSS-API Mechanism for OpenID Author(s) : E. Lear, et al Filename : draft-ietf-kitten-sasl-openid-02.txt Pages : 24 Date : 2011-04-27 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-sasl-openid-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06112129.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon May 9 09:30:03 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC96E086A; Mon, 9 May 2011 09:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYxxgbS1wY1k; Mon, 9 May 2011 09:30:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208D4E0845; Mon, 9 May 2011 09:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509163003.30973.30734.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:30:03 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D ACTION:draft-ietf-kitten-digest-to-historic-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:30:03 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Moving DIGEST-MD5 to Historic Author(s) : A. Melnikov Filename : draft-ietf-kitten-digest-to-historic-04.txt Pages : 7 Date : 2011-04-22 This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms, and moves RFC 2831 to Historic. status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-digest-to-historic-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-digest-to-historic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09091708.I-D@ietf.org> --NextPart-- From shawn.emery@oracle.com Sun May 15 21:42:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79EE071D for ; Sun, 15 May 2011 21:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swLsBRGOH92d for ; Sun, 15 May 2011 21:42:29 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA39E0679 for ; Sun, 15 May 2011 21:42:29 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4G4gOdl026165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 May 2011 04:42:27 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4G4gNSb016784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 May 2011 04:42:23 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4G4gHq5022552 for ; Sun, 15 May 2011 23:42:17 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 May 2011 21:42:17 -0700 Message-ID: <4DD0AB28.6000406@oracle.com> Date: Sun, 15 May 2011 22:42:16 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110412 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/mixed; boundary="------------080609020303040205060309" X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4DD0AB34.0077:SCFSTAT5015188,ss=1,fgs=0 Subject: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 04:42:32 -0000 This is a multi-part message in MIME format. --------------080609020303040205060309 Content-Type: multipart/alternative; boundary="------------090309020304070004020600" --------------090309020304070004020600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Per kitten WG session discussions in Prague, this starts a consensus call for the recharter of the kitten WG. The call expires in two weeks, 5/29/11. Please provide feed-back of the proposed changes, see attached. Members that find the changes adequate then please respond as well. Please give feed-back directly to the list. Alexey, Shawn, & Tom. -- kitten co-chairs --------------090309020304070004020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Per kitten WG session discussions in Prague, this starts a consensus call for the recharter of the kitten WG.  The call expires in two weeks, 5/29/11.  Please provide feed-back of the proposed changes, see attached.  Members that find the changes adequate then please respond as well.  Please give feed-back directly to the list.

Alexey,
Shawn, &
Tom.
--
kitten co-chairs
--------------090309020304070004020600-- --------------080609020303040205060309 Content-Type: text/plain; name="kitten-charter-diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kitten-charter-diff.txt" kitten-charter: @@ -48,30 +48,27 @@ * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, for example, by eliminating parameters which are commonly used with the default values. - This WG is also chartered to transition proposed SASL mechanisms as - GSS-API mechanisms: + This WG is also chartered to finalize proposed SASL mechanisms as + GSS-API mechanisms (based on RFC 5801): * A SASL Mechanism for OpenID - draft-lear-ietf-sasl-openid-00 - * A SASL Mechanism for SAML - draft-wierenga-ietf-sasl-saml-00 + * One of more SASL Mechanism(s) for SAML + * A SASL Mechanism for OAuth The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations - that support the use of GSS-API mechanisms in SASL (draft-ietf-sasl- - gs2). + that support the use of GSS-API mechanisms in SASL (RFC 5801). - * Shepherd draft-ietf-sasl-digest-to-historic to publication. - This WG should review proposals for new SASL and GSS-API mechanisms, but may take on work on such mechanisms only through a revision of this charter. The WG should also review non-mechanism proposals related to SASL and the GSS-API. However, work that adds SASL or GSS-API support in - application protocols should be handled by the application's WG. + application protocols is out of scope and should be handled by the + corresponding application's WG. Deliverables: * GSS-API: initializing credentials @@ -83,20 +80,24 @@ * GSS-API: interfaces/improvements for better error message reporting * GSS-API: programmer friendly interfaces - * GSS-API: transition SASL mechanism for OpenID + * SASL: SASL mechanism for OpenID - * GSS-API: transition SASL mechanism for SAML + * SASL: SASL mechanism(s) for SAML + * SASL: SASL mechanism for OAuth + * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana * GSS-API: publish draft-ietf-kitten-gssapi-naming-exts * SASL: publish draft-melnikov-digest-to-historic - Goals and Milestones: - Done - Submit naming-exts to the IESG as Proposed Standard - Aug 2010 - WGLC on gssapi-extensions-iana - Aug 2010 - Submit gssapi-extensions-iana to the IESG as Proposed Standard + May 2011 Submit SASL OpenID mechanism to the IESG as Proposed Standard + Jun 2011 Submit naming-exts to the IESG as Proposed Standard + Jul 2011 WGLC on gssapi-extensions-iana + Aug 2011 Submit SASL SAML mechanism(s) to the IESG as Proposed Standard + Sep 2011 Submit gssapi-extensions-iana to the IESG as Proposed Standard + Oct 2011 Submit SASL OAuth mechanism to the IESG as Proposed Standard --------------080609020303040205060309-- From nico@cryptonector.com Sun May 15 21:58:38 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D987E0671 for ; Sun, 15 May 2011 21:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCPR2CCHDsSv for ; Sun, 15 May 2011 21:58:38 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1E167E062B for ; Sun, 15 May 2011 21:58:38 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 9254235005B for ; Sun, 15 May 2011 21:58:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Kx/kj14zy8Dr/b1rt2mNi Rrvct3mfSdo/QIY5XaxJxuXrX+SZdiL9yyXepivaUGpj9Blu162DZKfzAtYbYeK+ 5WHyAlF3AriOOJChEBUA2yQpwSR/Fh+fbH/fGZ4/jynQXbAP9yvD/Vb5ysfq8zpi /gAvpMaRgiRF1zFStlh6lA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Sni5r8NOIUJbomaJBo7C NyjFKiE=; b=Uox5/w0oRF7LLwgesystFDYz84kT1ccLIpwrO7l+WVTQt4MBT33T xvLVja9mdm7Xa5W5uLxcg6oFy7u+EJ/BllCxldJgeArZywqruOTovqJIPkEkloF3 98yp4AUpiLNDnUmNAGCwBs1T5YQy+i3ui/eBqdz1vVjyEVw/p8BC0lU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 6FE6A350058 for ; Sun, 15 May 2011 21:58:37 -0700 (PDT) Received: by vws12 with SMTP id 12so3455120vws.31 for ; Sun, 15 May 2011 21:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.93.72 with SMTP id cs8mr5488294vdb.116.1305521916846; Sun, 15 May 2011 21:58:36 -0700 (PDT) Received: by 10.52.184.3 with HTTP; Sun, 15 May 2011 21:58:36 -0700 (PDT) In-Reply-To: <4DD0AB28.6000406@oracle.com> References: <4DD0AB28.6000406@oracle.com> Date: Sun, 15 May 2011 23:58:36 -0500 Message-ID: From: Nico Williams To: Shawn Emery Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 04:58:38 -0000 I'm quite interested in two specific extensions: a) Standardizing the DCE styole option and adding an option for DCE style negotiation for replay cache avoidance. Replay cache avoidance has been adopted in KRB-WG, but the GSS aspects may need to be reviewed here, or they might even have to be KITTEN work items. b) A utility function for obtaining an encrypted, exported, partially-establised security context token, and corresponding utility function to decrypt and import such a token. (Cue Martin's objections.) Nico -- From mrex@sap.com Mon May 16 07:16:33 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD1CE06AD for ; Mon, 16 May 2011 07:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.207 X-Spam-Level: X-Spam-Status: No, score=-9.207 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9FUPuytdnhI for ; Mon, 16 May 2011 07:16:33 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF2E0699 for ; Mon, 16 May 2011 07:16:32 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p4GEGUTw015356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 May 2011 16:16:30 +0200 (MEST) From: Martin Rex Message-Id: <201105161416.p4GEGUng024779@fs4113.wdf.sap.corp> To: shawn.emery@oracle.com (Shawn Emery) Date: Mon, 16 May 2011 16:16:30 +0200 (MEST) In-Reply-To: <4DD0AB28.6000406@oracle.com> from "Shawn Emery" at May 15, 11 10:42:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 14:16:34 -0000 Shawn Emery wrote: > > kitten-charter: > @@ -48,30 +48,27 @@ > * Provide a more programmer friendly GSS-API for application developers. > This could include reducing the number of interface parameters, for > example, by eliminating parameters which are commonly used with the > default values. I'm slighty confused by this charter item and what it is supposed to mean. GSS-APIv2 has been out there as Proposed Standard for 11 years (actually used for 15 years, and considering that it is fully backwards compatible on API calls to GSS-APIv1, its 18 years). You really don't want to change any of the _existing_ functions and their parameters at this point, because it would inevitably be backwards incompatible with _all_ of the installed base. You could come up with new functions with less parameters that are easier to use, avoiding any confusion with what is already there. But actually, the existing GSS-API v2 standard does not require mechanisms to offer all options that are defined at the API level, but instead offer only a limited subset, and provides some guidance to "portable application callers" what subset of features they may expect to be available from all mechanism, and what may be available only from a few specific mechanisms. The only guidance that is really lacking is the guidance about the absence of the hostbased service name for naming servers. -Martin From shawn.emery@oracle.com Wed May 18 23:26:14 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2ABE0754 for ; Wed, 18 May 2011 23:26:14 -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.930, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK+qv4iEDQb3 for ; Wed, 18 May 2011 23:26:14 -0700 (PDT) Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) by ietfa.amsl.com (Postfix) with ESMTP id 36344E0741 for ; Wed, 18 May 2011 23:26:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by rcsinet14.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p4J6QDMW029665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 May 2011 06:26:13 GMT Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4J6QA7k001647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 May 2011 06:26:12 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4J6QAGw025710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 May 2011 06:26:10 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4J6Q5oK028967 for ; Thu, 19 May 2011 01:26:05 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 May 2011 23:26:04 -0700 Message-ID: <4DD4B7FB.9030402@oracle.com> Date: Thu, 19 May 2011 00:26:03 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110412 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: kitten@ietf.org References: <201105161416.p4GEGUng024779@fs4113.wdf.sap.corp> In-Reply-To: <201105161416.p4GEGUng024779@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4DD4B804.00E4:SCFMA922111,ss=1,fgs=0 Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 06:26:15 -0000 On 05/16/11 08:16 AM, Martin Rex wrote: > Shawn Emery wrote: >> kitten-charter: >> @@ -48,30 +48,27 @@ >> * Provide a more programmer friendly GSS-API for application developers. >> This could include reducing the number of interface parameters, for >> example, by eliminating parameters which are commonly used with the >> default values. > I'm slighty confused by this charter item and what it is supposed to mean. > GSS-APIv2 has been out there as Proposed Standard for 11 years > (actually used for 15 years, and considering that it is fully backwards > compatible on API calls to GSS-APIv1, its 18 years). > > You really don't want to change any of the _existing_ functions and > their parameters at this point, because it would inevitably be backwards > incompatible with _all_ of the installed base. This work is item is not about changing existing interfaces, but adding additional interfaces that are simplified. > You could come up with new functions with less parameters that are > easier to use, avoiding any confusion with what is already there. > But actually, the existing GSS-API v2 standard does not require > mechanisms to offer all options that are defined at the API level, > but instead offer only a limited subset, and provides some guidance > to "portable application callers" what subset of features they may > expect to be available from all mechanism, and what may be available > only from a few specific mechanisms. My experience is that application developers get this wrong quite often resulting in unexpected behavior, memory management issues, etc. Most of these problems could have been avoided by using the correct default value or by not having to specify almost half of the arguments to begin with. > The only guidance that is really lacking is the guidance about > the absence of the hostbased service name for naming servers. I disagree about this being the only issue. Shawn. -- From shawn.emery@oracle.com Thu May 19 00:33:04 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB46E0785 for ; Thu, 19 May 2011 00:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB5S-qObverJ for ; Thu, 19 May 2011 00:33:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 10726E077B for ; Thu, 19 May 2011 00:33:04 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4J7X1UA003721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 May 2011 07:33:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4J7X06Z027482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 May 2011 07:33:01 GMT Received: from abhmt013.oracle.com (abhmt013.oracle.com [141.146.116.22]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4J7WtGS016880 for ; Thu, 19 May 2011 02:32:55 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 May 2011 00:32:54 -0700 Message-ID: <4DD4C7A5.5000403@oracle.com> Date: Thu, 19 May 2011 01:32:53 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110412 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" References: <4DD0AB28.6000406@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090202.4DD4C7AF.00BF:SCFSTAT5015188,ss=1,fgs=0 Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 07:33:04 -0000 On 05/15/11 10:58 PM, Nico Williams wrote: > I'm quite interested in two specific extensions: > > a) Standardizing the DCE styole option and adding an option for DCE > style negotiation for replay cache avoidance. Replay cache avoidance > has been adopted in KRB-WG, but the GSS aspects may need to be > reviewed here, or they might even have to be KITTEN work items. > > b) A utility function for obtaining an encrypted, exported, > partially-establised security context token, and corresponding utility > function to decrypt and import such a token. (Cue Martin's > objections.) Are there any volunteers to be authors or contribute to the design of said work? Shawn. -- From hartmans@mit.edu Thu May 19 03:04:08 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C92E0795 for ; Thu, 19 May 2011 03:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgt3duTQHxwe for ; Thu, 19 May 2011 03:04:07 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE7FE0727 for ; Thu, 19 May 2011 03:04:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (wifi-tnc2011-470.tnc2011.org [78.128.233.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C83A920463; Thu, 19 May 2011 06:00:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9B9D84125; Thu, 19 May 2011 06:04:03 -0400 (EDT) From: Sam Hartman To: mrex@sap.com References: <201105161416.p4GEGUng024779@fs4113.wdf.sap.corp> Date: Thu, 19 May 2011 06:04:03 -0400 In-Reply-To: <201105161416.p4GEGUng024779@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 16 May 2011 16:16:30 +0200 (MEST)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 10:04:08 -0000 >>>>> "Martin" == Martin Rex writes: Martin> GSS-APIv2 has been out there as Proposed Standard for 11 Martin> years (actually used for 15 years, and considering that it Martin> is fully backwards compatible on API calls to GSS-APIv1, its Martin> 18 years). Martin> You really don't want to change any of the _existing_ Martin> functions and their parameters at this point, because it Martin> would inevitably be backwards incompatible with _all_ of the Martin> installed base. I agree that we do not want to change the set of parameters that existing functions take. Other changes--for example changing semantics, adding new possibilities of defaults--do not inherently break the entire installed base. We would have to carefully consider the impact of any such change before making it. From hartmans@mit.edu Thu May 19 03:05:53 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4348CE07AA for ; Thu, 19 May 2011 03:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8uSNoDcFGdx for ; Thu, 19 May 2011 03:05:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DC1CDE0727 for ; Thu, 19 May 2011 03:05:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (wifi-tnc2011-470.tnc2011.org [78.128.233.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9DFCE20463; Thu, 19 May 2011 06:01:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EDF274125; Thu, 19 May 2011 06:05:49 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4DD0AB28.6000406@oracle.com> Date: Thu, 19 May 2011 06:05:49 -0400 In-Reply-To: (Nico Williams's message of "Sun, 15 May 2011 23:58:36 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 10:05:53 -0000 >>>>> "Nico" == Nico Williams writes: Nico> b) A utility function for obtaining an encrypted, exported, Nico> partially-establised security context token, and corresponding Nico> utility function to decrypt and import such a token. (Cue Nico> Martin's objections.) I definitely strongly support standardization work regarding partial context export. I'm not sure the encryption should happen in GSS-API although I'll agree it is likely that is the correct place for it. From lukeh@padl.com Thu May 19 05:35:50 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE585E075B for ; Thu, 19 May 2011 05:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGsQWwxk6zDr for ; Thu, 19 May 2011 05:35:50 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 093BFE069A for ; Thu, 19 May 2011 05:35:49 -0700 (PDT) Received: by us.padl.com with ESMTP id p4JCZgft005400; Thu, 19 May 2011 08:35:46 -0400 From: Luke Howard Content-Type: multipart/alternative; boundary=Apple-Mail-359--1063656134 Date: Thu, 19 May 2011 14:35:41 +0200 Message-Id: <4809991C-E6EE-4819-89EB-6D692D5F80F0@padl.com> To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_50,HTML_MESSAGE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.0 Cc: Jeffrey Altman Subject: [kitten] gss_acquire_cred_ext() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 12:35:50 -0000 --Apple-Mail-359--1063656134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, We have an application requirement for an extended variant of = gss_acquire_cred() that takes a set of attributes. Those attributes may = indicate things as: * a user's password * a user's private key * the service name * behaviour, such as whether we prompt for credentials if required, = callbacks, etc. There are a few ways to skin this cat API-wise. Here's something to get = the discussion started, suggested by Sam. For now I'm interested in = coming up with an API that can let us deprecate = gss_acquire_cred_with_password() (from Solaris). Additional attributes = and their format we can discuss in a separate thread. gss_const_OID GSS_CA_PASSWORD; typedef struct gss_password_cred_attr_desc { gss_const_OID attribute; /* GSS_CA_PASSWORD */ gss_buffer_desc password; } gss_password_cred_attr_t; typedef struct gss_cred_attr_desc { gss_const_OID attribute; /* OM_uint32 flags or int mandatory; ? */ /* ... */ } gss_cred_attr_t; OM_uint32 gss_acquire_cred_ext( OM_uint32 *minor_status, const gss_name_t desired_name, const gss_const_cred_attr_t *credential_attrs, int credential_attr_count, OM_uint32 time_req, gss_const_OID desired_mech, gss_cred_usage_t cred_usage, gss_cred_id_t *output_cred_handle ); (Note other out parameters have been removed for simplicity. You can use = gss_inquire_cred() to get them.) So you might use it like this: acquire_cred_with_password() { gss_password_cred_attr_t password =3D { GSS_CA_PASSWORD, { 4, "asdf" } }; gss_cred_attr_t attrs[] =3D { (gss_cred_attr_t)&password }; ... major =3D gss_acquire_cred_ext( &minor, name, attrs, sizeof(attrs) / sizeof(attrs[0]), time_req, mech, GSS_C_INITIATE, &cred); } If you finding the casting objectionable, then we could do something = like: typedef struct gss_cred_attr_desc { gss_const_OID attribute; const void *value; } gss_cred_attr_t; And finally, if you don't like the gss_wrap_iov() pattern of passing the = count as a function parameter, we could define a gss_cred_attr_set_t. = That would be more consistent with the rest of the GSS-API but maybe = marginally more work for application developers. Let the flaming begin! -- Luke= --Apple-Mail-359--1063656134 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii gss_const_OID = GSS_CA_PASSWORD;

typedef struct = gss_password_cred_attr_desc {
= gss_const_OID attribute; /* GSS_CA_PASSWORD = */
gss_buffer_desc = password;
} = gss_password_cred_attr_t;
typedef struct gss_cred_attr_desc = {
= gss_const_OID = attribute;
/* = OM_uint32 flags or int mandatory; ? */
/* ... = */
} = gss_cred_attr_t;

gss_acquire_cred_ext(
OM_uint32 = *minor_status,
const gss_name_t = desired_name,
const gss_const_cred_attr_t = *credential_attrs,
int = credential_attr_count,
OM_uint32 = time_req,
gss_const_OID = desired_mech,
gss_cred_usage_t = cred_usage,
gss_cred_id_t = *output_cred_handle
= );

(Note other out = parameters have been removed for simplicity. You can use = gss_inquire_cred() to get them.)

So you might = use it like this:

acquire_cred_with_password()
{
gss_password_cred_attr_t password = =3D {
= GSS_CA_PASSWORD,
{ = 4, "asdf" } };
gss_cred_attr_t attrs[] =3D { = (gss_cred_attr_t)&password };


= major =3D = gss_acquire_cred_ext(
= &minor,
= name,
= attrs,
sizeof(attrs) / = sizeof(attrs[0]),
= time_req,
= mech,
= GSS_C_INITIATE,
= &cred);
}

If you finding the = casting objectionable, then we could do something = like:

typedef struct gss_cred_attr_desc = {
= gss_const_OID = attribute;
const void = *value;
} = gss_cred_attr_t;

And finally, if you don't like = the gss_wrap_iov() pattern of passing the count as a function parameter, = we could define a gss_cred_attr_set_t. That would be more consistent = with the rest of the GSS-API but maybe marginally more work for = application developers.

Let the flaming = begin!

-- Luke
= --Apple-Mail-359--1063656134-- From nico@cryptonector.com Thu May 19 08:33:52 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BC8E07F7 for ; Thu, 19 May 2011 08:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ588AP-xVTr for ; Thu, 19 May 2011 08:33:52 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 36ABDE0751 for ; Thu, 19 May 2011 08:33:52 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by hapkido.dreamhost.com (Postfix) with ESMTP id E25AB179EBD for ; Thu, 19 May 2011 08:33:51 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id F14B2674070 for ; Thu, 19 May 2011 08:33:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=TlCHOex1BiygSxBvXxmVw TAb469xFZsV2NK1mFkQ9SLy2zHLJj0wHstA285Z3yFlXi2RQZzlreA9AsgNVnIEJ 6WTjFCoPRt7tXYp1Hac5IGlL7vYXDnhHS/bCHVu/FDzC1/LXoAkfqpQoB+W3I/Vf 0UKpSwJpNZWDNRnuUYed9c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JEf8/ZZ069FAJLZ3RI9/ zUWCTR0=; b=wWuc1bl06dk3pinxtBISjCndUzvoxbCbU7U6A37/qMGSKLVboR11 mPSZr0OHoQqM0jURLlyiu62LfB84FG47bhTsueutJX6XkQmZWydOaS11GELcDTiV rLvLvZpAY5NITEXvYtODsvBhKq2xMHh3KPZwRBtJKlvKYM07iqwMvKU= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id CDF4267406A for ; Thu, 19 May 2011 08:33:50 -0700 (PDT) Received: by vxg33 with SMTP id 33so2390453vxg.31 for ; Thu, 19 May 2011 08:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.202 with SMTP id w10mr1211274vdv.79.1305819230192; Thu, 19 May 2011 08:33:50 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Thu, 19 May 2011 08:33:50 -0700 (PDT) In-Reply-To: <4809991C-E6EE-4819-89EB-6D692D5F80F0@padl.com> References: <4809991C-E6EE-4819-89EB-6D692D5F80F0@padl.com> Date: Thu, 19 May 2011 10:33:50 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Altman Subject: Re: [kitten] gss_acquire_cred_ext() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 15:33:52 -0000 I'll think about this today and get back to you. My preferred API design for this sort of thing would be to have a function to acquire an "empty" handle, and one to add a single attribute -- because we're likely to do that for sec contexts, I'd like a consistent approach for credentials. The nice thing about this approach is that you can always add new functions to set new attributes with data types that are different from the ones you have in mind today. Nico -- From mrex@sap.com Thu May 19 09:16:25 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15007E0802 for ; Thu, 19 May 2011 09:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.468 X-Spam-Level: X-Spam-Status: No, score=-9.468 tagged_above=-999 required=5 tests=[AWL=0.781, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxDEXrv45Mzb for ; Thu, 19 May 2011 09:16:24 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D656FE06D5 for ; Thu, 19 May 2011 09:16:22 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p4JGGFaJ028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2011 18:16:15 +0200 (MEST) From: Martin Rex Message-Id: <201105191616.p4JGGFBQ012250@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Thu, 19 May 2011 18:16:14 +0200 (MEST) In-Reply-To: from "Nico Williams" at May 19, 11 10:33:50 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, jaltman@secure-endpoints.com Subject: Re: [kitten] gss_acquire_cred_ext() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 16:16:25 -0000 Nico Williams wrote: > > I'll think about this today and get back to you. > > My preferred API design for this sort of thing would be to have a > function to acquire an "empty" handle, and one to add a single > attribute -- because we're likely to do that for sec contexts, I'd > like a consistent approach for credentials. The nice thing about this > approach is that you can always add new functions to set new > attributes with data types that are different from the ones you have > in mind today. I think I'm currently leaning towards the approach depicted by Nico. The primary question is about making things easy for the caller, especially dealing with older implementations in a simple backwards compatible fashion. The abstract underlying problem is that an application may be used with gss-api mechanism implementations with differing features/characteristics, and you probably do not want to require completely seperate code paths for the application for each different incarnation of a gssapi mechanism implementation. The two possible approaches are: (a) like existing context attributes: one call that takes a huge list of features of input attributes and returns a list of output features that were recognized/granted. It's up to the application caller to check whether the resulting list of attributes/characteristics fits the callers requirements, the gssapi mechanism is supposed to return a valid credentials if at all possible, even when none of the requested attributes is recognized or supported/available. dealing with conflicting attributes might become somewhere between difficult to non-predictable, like indicating which attributes are more important for the caller than others. (b) the application itself iterates over the attributes that it likes for a credential handle and requests each attribute/characteristic seperately. A failure leaves the credential handle as-is, and the error is specific to the requested attribute. The application caller is automatically fully aware about which attributes are available and which aren't. An inquiry function is probably necessary to determine all attributes later on, or for delegated credentials handles. -Martin From nico@cryptonector.com Thu May 19 09:52:14 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BEFE073D for ; Thu, 19 May 2011 09:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dp++Cc2GTny for ; Thu, 19 May 2011 09:52:13 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id D80BDE073B for ; Thu, 19 May 2011 09:52:13 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 7152B1006E for ; Thu, 19 May 2011 09:52:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=SIsIH9Z7ByVdY8GEDnixc CcsqNSwDFshVQFflhN+mJZPblUgQK2R2vgtxbQu3BtERZpD+f9pbxGTtD1tANGOk A7aE0kBm+h6XOU6sd/zjOdSU40mXN8g8pB2G7Pear0T2110ITHNx8MBitLv5h6Mk Fp70mBV9BvwtC1HnYp1adQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=IguSdX2DcPyR/J27xfKx Re8RMFA=; b=w5NmM5VtGm+TaMxIwTHPyYHBCjwjO/RCA5i0X4KGQH5DitOND+5I /Pcqnsjy3O7MLAlZFjbAWOV0NoQClOPQer1gPuK57iq91rAAmBQkEfEqmKZ8Wbsq kgzejweeYb0yTjL3PEdnngLgsGlTPEf21uez3wYNGTiyUlqrJax5X+0= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 4403810059 for ; Thu, 19 May 2011 09:52:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so2462018vxg.31 for ; Thu, 19 May 2011 09:52:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.106 with SMTP id cp10mr1080623vdc.199.1305823932647; Thu, 19 May 2011 09:52:12 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Thu, 19 May 2011 09:52:12 -0700 (PDT) In-Reply-To: <201105191616.p4JGGFBQ012250@fs4113.wdf.sap.corp> References: <201105191616.p4JGGFBQ012250@fs4113.wdf.sap.corp> Date: Thu, 19 May 2011 11:52:12 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, jaltman@secure-endpoints.com Subject: Re: [kitten] gss_acquire_cred_ext() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 16:52:14 -0000 On Thu, May 19, 2011 at 11:16 AM, Martin Rex wrote: > The primary question is about making things easy for the caller, > especially dealing with older implementations in a simple backwards > compatible fashion. I agree. I think multiple function calls is probably less ugly than an array of attributes, plus, if there's unsupported attributes, then what? A call per-attribute will make it possible to determine that some attrs are not supported. > The abstract underlying problem is that an application may be > used with gss-api mechanism implementations with differing > features/characteristics, and you probably do not want to require > completely seperate code paths for the application for each > different incarnation of a gssapi mechanism implementation. Exactly. Also, if you pass a credential to a library (think of something like RPCSEC_GSS), then you probably want a way to set attributes more than once. In terms of lines of caller code, my approach is probably a bit lengthier, but I find multiple function calls more readable than a single call with a large array as an input. Nico -- From nico@cryptonector.com Thu May 19 10:32:54 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0E9E0665 for ; Thu, 19 May 2011 10:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fURYeZim+V4A for ; Thu, 19 May 2011 10:32:54 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECE8E0658 for ; Thu, 19 May 2011 10:32:54 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by hapkido.dreamhost.com (Postfix) with ESMTP id E7ACA1797DD for ; Thu, 19 May 2011 10:32:53 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 91D4C54077 for ; Thu, 19 May 2011 10:32:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=FpM1E7ozbkGRYBX8x+SLc7caUW6YZJRUgBOIMvjw6o1O huRvmYuowRTEcwvRxGoP2DnrtbFjSWadEAtR4foOE2oDdlnYi3KYGssdeLwm+Xr4 0tqZm3STmIZN1u5GIivKhstoBCSJui4U8u31OdP8m5By/bThnS/vryI7nGmvi6Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=XNAGljo1kZTtgrTWVLTVP6FB6uo=; b=SUwM0gd3qiM xJgJqQqaZjZJM+PVwDDqH9enzba/ZhqlD+DgFzmV/xlRLlwawXAZbbTlE6yVucEv uSRE9DBucLm2I0+JnQRxZxJ84dY+FiTNWQqt8fG8ZQZ9Q2Lf1w+gHTwb2D23tdHN C7XP8xrqdJlMTWyadplmn6omYh0kcQ+w= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 63F1F5406F for ; Thu, 19 May 2011 10:32:53 -0700 (PDT) Received: by vws12 with SMTP id 12so2512112vws.31 for ; Thu, 19 May 2011 10:32:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.76.106 with SMTP id j10mr5121732vdw.39.1305826372820; Thu, 19 May 2011 10:32:52 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Thu, 19 May 2011 10:32:52 -0700 (PDT) In-Reply-To: <201105161416.p4GEGUng024779@fs4113.wdf.sap.corp> References: <4DD0AB28.6000406@oracle.com> <201105161416.p4GEGUng024779@fs4113.wdf.sap.corp> Date: Thu, 19 May 2011 12:32:52 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 17:32:55 -0000 On Mon, May 16, 2011 at 9:16 AM, Martin Rex wrote: > Shawn Emery wrote: >> kitten-charter: >> @@ -48,30 +48,27 @@ >> =C2=A0 =C2=A0* Provide a more programmer friendly GSS-API for applicatio= n developers. >> =C2=A0 =C2=A0This could include reducing the number of interface paramet= ers, for >> =C2=A0 =C2=A0example, by eliminating parameters which are commonly used = with the >> =C2=A0 =C2=A0default values. > > I'm slighty confused by this charter item and what it is supposed to mean= . We've discussed adding _new_ versions of certain functions with fewer arguments, for example. No one, to my knowledge, has yet proposed making backwards-incompatible changes to the API. Certainly no one has proposed changing the C prototypes of GSS-API C bindings, nor the various types (e.g., gss_buffer_desc), nor any changes to existing Java bindings methods. I suppose we might change the abstract API in such ways, but no one has proposed that either (and I doubt anyone intends to; certainly I do not). Nico -- From lukeh@padl.com Thu May 19 12:19:30 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC1FE06AD for ; Thu, 19 May 2011 12:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=-2.031, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcYjbP5ESlcj for ; Thu, 19 May 2011 12:19:30 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id C1924E06B3 for ; Thu, 19 May 2011 12:19:29 -0700 (PDT) Received: by us.padl.com with ESMTP id p4JHa3hJ013841; Thu, 19 May 2011 13:36:09 -0400 References: <4809991C-E6EE-4819-89EB-6D692D5F80F0@padl.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <10A151DE-5E72-4A1C-8F99-B4BC45D00CC4@padl.com> X-Mailer: iPhone Mail (8J2) From: Luke Howard Date: Thu, 19 May 2011 19:33:10 +0200 To: Nico Williams X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_50,MIME_QP_LONG_LINE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.2 Cc: "kitten@ietf.org" , Jeffrey Altman Subject: Re: [kitten] gss_acquire_cred_ext() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 19:19:30 -0000 Oh, like the gss_set_cred_option we have today? Maybe that's not such a bad i= dea... Sent from my iPhone On 19/05/2011, at 17:33, Nico Williams wrote: > I'll think about this today and get back to you. >=20 > My preferred API design for this sort of thing would be to have a > function to acquire an "empty" handle, and one to add a single > attribute -- because we're likely to do that for sec contexts, I'd > like a consistent approach for credentials. The nice thing about this > approach is that you can always add new functions to set new > attributes with data types that are different from the ones you have > in mind today. >=20 > Nico > -- From simon@josefsson.org Fri May 20 02:09:12 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2171E06F2 for ; Fri, 20 May 2011 02:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy-GFAyjq2cO for ; Fri, 20 May 2011 02:09:12 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id C5AF3E06BA for ; Fri, 20 May 2011 02:09:11 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4K98aGM011919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 May 2011 11:08:39 +0200 From: Simon Josefsson To: Nico Williams References: <201105191616.p4JGGFBQ012250@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110520:kitten@ietf.org::gr3fkcWmYelFmS0h:C+1U X-Hashcash: 1:22:110520:mrex@sap.com::OV7odZ+R80k1ZYon:OZF8 X-Hashcash: 1:22:110520:jaltman@secure-endpoints.com::X6SIoL+uQ7NXYEfF:KJac X-Hashcash: 1:22:110520:nico@cryptonector.com::nhKL9OXFYkdllBdk:T9AX Date: Fri, 20 May 2011 11:08:37 +0200 In-Reply-To: (Nico Williams's message of "Thu, 19 May 2011 11:52:12 -0500") Message-ID: <87hb8poi22.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, jaltman@secure-endpoints.com Subject: Re: [kitten] gss_acquire_cred_ext() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 09:09:12 -0000 Nico Williams writes: > In terms of lines of caller code, my approach is probably a bit > lengthier, but I find multiple function calls more readable than a > single call with a large array as an input. +1 I think this approach is easier to implement in a callback environment as well: the callback would then add the new property (e.g., password) to the context, rather than having to add the property to an internal list, and schedule some code to add all properties to the context once the callback loop is over. /Simon From alexey.melnikov@isode.com Sat May 21 05:55:17 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF1E06B4 for ; Sat, 21 May 2011 05:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1xdOH80K9B0 for ; Sat, 21 May 2011 05:55:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 09774E06AB for ; Sat, 21 May 2011 05:55:16 -0700 (PDT) Received: from [192.168.100.60] (95-177-109-161.chess.managedbroadband.co.uk [95.177.109.161]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 21 May 2011 13:55:14 +0100 Message-ID: <4DD7B627.40004@isode.com> Date: Sat, 21 May 2011 13:55:03 +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 Emery References: <4DD0AB28.6000406@oracle.com> <4DD4C7A5.5000403@oracle.com> In-Reply-To: <4DD4C7A5.5000403@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 12:55:17 -0000 Shawn Emery wrote: > On 05/15/11 10:58 PM, Nico Williams wrote: > >> I'm quite interested in two specific extensions: >> >> a) Standardizing the DCE styole option and adding an option for DCE >> style negotiation for replay cache avoidance. Replay cache avoidance >> has been adopted in KRB-WG, but the GSS aspects may need to be >> reviewed here, or they might even have to be KITTEN work items. > I would review this, but not being familiar with details of this I would like to get some extra information from Nico about the need for this. >> b) A utility function for obtaining an encrypted, exported, >> partially-establised security context token, and corresponding utility >> function to decrypt and import such a token. (Cue Martin's >> objections.) > I am happy to work on this one. > Are there any volunteers to be authors or contribute to the design of > said work? From internet-drafts@ietf.org Sun May 22 07:08:28 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA123E069E; Sun, 22 May 2011 07:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJFlQbVumyZK; Sun, 22 May 2011 07:08:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77713E065D; Sun, 22 May 2011 07:08:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110522140828.15443.50247.idtracker@ietfa.amsl.com> Date: Sun, 22 May 2011 07:08:28 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 14:08:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : Sun Microsystems Leif Johansson Sam Hartman Filename : draft-ietf-kitten-gssapi-naming-exts-10.txt Pages : 16 Date : 2011-05-22 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-10= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-10.= txt From leifj@mnt.se Sun May 22 16:30:21 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC26E06DB for ; Sun, 22 May 2011 16:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqV9nsc+d02e for ; Sun, 22 May 2011 16:30:20 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 38B13E06AA for ; Sun, 22 May 2011 16:30:19 -0700 (PDT) Received: from [10.33.1.63] ([212.247.15.226]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p4MEncgY028787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 May 2011 16:49:40 +0200 (CEST) Message-ID: <4DD92282.6040400@mnt.se> Date: Sun, 22 May 2011 16:49:38 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: kitten@ietf.org References: <4D6DFA7C.1080401__858.060739892785$1299053205$gmane$org@oracle.com> <87wrkhbybl.fsf@latte.josefsson.org> <87fwr3kkq0.fsf__30668.2908013046$1299249964$gmane$org@latte.josefsson.org> <87wriw7rlj.fsf_-_@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] GFD.24 and draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 23:30:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/22/2011 01:52 PM, Sam Hartman wrote: > I strongly support the adoption of Simon's text or similar text in > naming extensions. I may not have been clear enough in -10 for Sam and Simon to be happy but I expect that we'll have to do -11 at the next WGLC at which time I'll include Simon's proposed text if this is still deemed appropriate. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ZIoEACgkQ8Jx8FtbMZneERgCdGRPyW05YofmH38kTJ+ZA3Dkp YDEAnj9r8KmAu1WhkSM4uC7Oc38yDaEs =L68n -----END PGP SIGNATURE----- From leifj@mnt.se Sun May 22 16:30:22 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D60EE06AA for ; Sun, 22 May 2011 16:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVlxnW9Ctuqo for ; Sun, 22 May 2011 16:30:21 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E2E06D9 for ; Sun, 22 May 2011 16:30:20 -0700 (PDT) Received: from [10.33.1.63] ([212.247.15.226]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p4MEAcPC014507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 May 2011 16:10:41 +0200 (CEST) Message-ID: <4DD9195E.5020007@mnt.se> Date: Sun, 22 May 2011 16:10:38 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "kitten@ietf.org" , Simon Josefsson X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: New Version Notification - draft-ietf-kitten-gssapi-naming-exts-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 23:30:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In his WGLC review of the naming extensions draft Simon found a few issues. I've tried to address them in -10 but *please* review this version so I caught them all. Cheers Leif - -------- Original Message -------- Subject: New Version Notification - draft-ietf-kitten-gssapi-naming-exts-10.txt Date: Sun, 22 May 2011 07:08:28 -0700 From: internet-drafts@ietf.org To: kitten-chairs@tools.ietf.org, draft-ietf-kitten-gssapi-naming-exts@tools.ietf.org, stephen.farrell@cs.tcd.ie New version (-10) has been submitted for draft-ietf-kitten-gssapi-naming-exts-10.txt. http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-10.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-gssapi-naming-exts-10 IETF Secretariat. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ZGV4ACgkQ8Jx8FtbMZncfHwCglvlcQT7MYRF4Jb4BAlrUaxy5 y/IAn17lqza3WKseLRwrGX0esuxmuH29 =bHL/ -----END PGP SIGNATURE----- From internet-drafts@ietf.org Tue May 24 13:16:26 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36FE07FA; Tue, 24 May 2011 13:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqcW8z-aL4lb; Tue, 24 May 2011 13:16:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D907DE06AE; Tue, 24 May 2011 13:16:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110524201625.6926.92760.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2011 13:16:25 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:16:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : Nicolas Williams Leif Johansson Sam Hartman Simon Josefsson Filename : draft-ietf-kitten-gssapi-naming-exts-11.txt Pages : 18 Date : 2011-05-24 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-11= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-11.= txt From leifj@mnt.se Tue May 24 13:21:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BDEE07D3 for ; Tue, 24 May 2011 13:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIHUjM-nIdNn for ; Tue, 24 May 2011 13:21:45 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8FDE06AE for ; Tue, 24 May 2011 13:21:45 -0700 (PDT) Received: from [78.64.183.133] (host-78-64-183-133.homerun.telia.com [78.64.183.133]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p4OKLaLH004507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 May 2011 22:21:43 +0200 (CEST) Message-ID: <4DDC134D.5020406@mnt.se> Date: Tue, 24 May 2011 22:21:33 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20110524201625.6926.92760.idtracker@ietfa.amsl.com> In-Reply-To: <20110524201625.6926.92760.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:21:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/24/2011 10:16 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : GSS-API Naming Extensions > Author(s) : Nicolas Williams > Leif Johansson > Sam Hartman > Simon Josefsson > Filename : draft-ietf-kitten-gssapi-naming-exts-11.txt > Pages : 18 > Date : 2011-05-24 > > The Generic Security Services API (GSS-API) provides a simple naming > architecture that supports name-based authorization. This document > introduces new APIs that extend the GSS-API naming model to support > name attribute transfer between GSS-API peers. > This version is the result of intense discussions between Nico, me, Sam and Simon in order to resolve the WGLC comments by Simon. We propose a second WGLC on -11 asap. Cheers Leif > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-11.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3cE00ACgkQ8Jx8FtbMZncgyACgpgUmwLYY8eytGTxb+v0D3xRr GX4An2JxluTHSo+wbMaon3azZTBCVYGC =PfCe -----END PGP SIGNATURE----- From shawn.emery@oracle.com Wed May 25 23:39:27 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EE3E071A for ; Wed, 25 May 2011 23:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09ltDIoQ2YZ1 for ; Wed, 25 May 2011 23:39:26 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 94064E0715 for ; Wed, 25 May 2011 23:39:26 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4Q6dNvT006882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 26 May 2011 06:39:25 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4Q6dMoQ003117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 May 2011 06:39:23 GMT Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4Q6dHJT001549 for ; Thu, 26 May 2011 01:39:17 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 May 2011 23:39:17 -0700 Message-ID: <4DDDF593.5080100@oracle.com> Date: Thu, 26 May 2011 00:39:15 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110412 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4DDDF59E.0032:SCFSTAT5015188,ss=1,fgs=0 Subject: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 06:39:27 -0000 This message officially starts the 3rd kitten Working Group Last Call for the following document: GSS-API Naming Extensions http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-11 The Working Group Last Call for this document starts today on Thursday, May 26th and will end on Thursday, June 9th. Please send any comments to the kitten mailing list or directly to the chairs. Feed-back from reviews that found no issues are also welcome. Thank you, Shawn Emery, kitten WG co-chair -- From lear@cisco.com Thu May 26 13:49:19 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F074E078D for ; Thu, 26 May 2011 13:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.565 X-Spam-Level: X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOcNDHp+B4y6 for ; Thu, 26 May 2011 13:49:18 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 37A79E0714 for ; Thu, 26 May 2011 13:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=3399; q=dns/txt; s=iport; t=1306442958; x=1307652558; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=HRrX+pfHcOzaXsKJiUrPBKC175EgDDeza0f9ud6Sq1E=; b=aZgqEaWZ8Da835EHxfP+cD/1v3k9KoUSqpPndMIzQLLP9OrNMJ49hbUY PIlYSvyvZ1jqbe7H4nYcZP7ASqI/T6RpYyFsw4zXj6OOmFculnPJ/mzq/ AMl4EQi8bpw8PBOSdBDVT1xPN5Ob1g2jRWCSj/bGMHR7uhEOE7D/YkBjl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKa73k2Q/khR/2dsb2JhbABVhEmhbHinco0GkFmFFYEHBJA5jxI X-IronPort-AV: E=Sophos;i="4.65,276,1304294400"; d="scan'208,217";a="32489644" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 26 May 2011 20:49:17 +0000 Received: from dhcp-10-55-88-68.cisco.com (dhcp-10-55-88-68.cisco.com [10.55.88.68]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4QKnHtV027598; Thu, 26 May 2011 20:49:17 GMT Message-ID: <4DDEBCCC.8050804@cisco.com> Date: Thu, 26 May 2011 22:49:16 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Shawn Emery References: <4DD0AB28.6000406@oracle.com> In-Reply-To: <4DD0AB28.6000406@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------030105080202030206030607" Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 20:49:19 -0000 This is a multi-part message in MIME format. --------------030105080202030206030607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Shawn, Just so that this is on the record, I would request a change to the proposed charter, such that the existing draft-ietf-kitten-saml work is progressed. The document has completed working group last call with nary a comment. We've invested substantial time and effort, and for many reasons I believe it to be the correct approach. As I have said previously, I have no objection to SAML-EC also moving forward, so long as it doesn't slow the other work. Eliot On 5/16/11 6:42 AM, Shawn Emery wrote: > > Per kitten WG session discussions in Prague, this starts a consensus > call for the recharter of the kitten WG. The call expires in two > weeks, 5/29/11. Please provide feed-back of the proposed changes, see > attached. Members that find the changes adequate then please respond > as well. Please give feed-back directly to the list. > > Alexey, > Shawn, & > Tom. > -- > kitten co-chairs > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------030105080202030206030607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Shawn,

Just so that this is on the record, I would request a change to the proposed charter, such that the existing draft-ietf-kitten-saml work is progressed.  The document has completed working group last call with nary a comment.  We've invested substantial time and effort, and for many reasons I believe it to be the correct approach.  As I have said previously, I have no objection to SAML-EC also moving forward, so long as it doesn't slow the other work.

Eliot

On 5/16/11 6:42 AM, Shawn Emery wrote:

Per kitten WG session discussions in Prague, this starts a consensus call for the recharter of the kitten WG.  The call expires in two weeks, 5/29/11.  Please provide feed-back of the proposed changes, see attached.  Members that find the changes adequate then please respond as well.  Please give feed-back directly to the list.

Alexey,
Shawn, &
Tom.
--
kitten co-chairs

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
--------------030105080202030206030607-- From hartmans@mit.edu Fri May 27 10:09:40 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F297CE082E for ; Fri, 27 May 2011 10:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.235 X-Spam-Level: X-Spam-Status: No, score=-104.235 tagged_above=-999 required=5 tests=[AWL=-1.970, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGmvd-ZrqeCy for ; Fri, 27 May 2011 10:09:39 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD2E082D for ; Fri, 27 May 2011 10:09:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0F87720265; Fri, 27 May 2011 13:05:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2C3B44125; Fri, 27 May 2011 13:09:36 -0400 (EDT) From: Sam Hartman To: Shawn Emery References: <4DDDF593.5080100@oracle.com> Date: Fri, 27 May 2011 13:09:36 -0400 In-Reply-To: <4DDDF593.5080100@oracle.com> (Shawn Emery's message of "Thu, 26 May 2011 00:39:15 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:09:40 -0000 During the discussions that we held, the authors discovered an issue that we had not previously discussed. One possible resolution is to do nothing. It's possible that you could set an attribute on a name used to acquire credentials or on an attribute used as target name in gss_init_sec_context. It's possible that such an attribute could have semantics that were intended to change the behavior of acquire_cred or init_sec_context. We have no such attributes specified and at least currently I'm not aware of plans to specify such attributes although I've at least had thought experiments where doing something like this might have been the right approach. This draft is silent on what happens if such an attribute is set and for whatever reason the effect of that attribute cannot be carried out. The typical GSS-API philosophy is that applications need to check to see if optional services are provided, so this may be the right approach. I said I'd write up this situation and discuss whether we want to have some text about this issue. I think all the authors would be happy to wait until someone actually proposes such an attribute before deciding to do something about this. I suspect some people (Martin) may even argue that no such attributes should exist. --Sam From lukeh@padl.com Fri May 27 10:12:58 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00353E082E for ; Fri, 27 May 2011 10:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtv9HiIbmvAB for ; Fri, 27 May 2011 10:12:57 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3F345E06EE for ; Fri, 27 May 2011 10:12:57 -0700 (PDT) Received: by us.padl.com with ESMTP id p4RHCqgH007578; Fri, 27 May 2011 13:12:55 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 27 May 2011 13:12:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4DDDF593.5080100@oracle.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_40, FH_HELO_EQ_D_D_D_D, HELO_DYNAMIC_IPADDR2, TVD_RCVD_IP X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 1.2 Cc: "kitten@ietf.org" Subject: [kitten] [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:12:58 -0000 > It's possible that you could set an attribute on a name used to acquire > credentials or on an attribute used as target name in > gss_init_sec_context. > > It's possible that such an attribute could have semantics that were > intended to change the behavior of acquire_cred or init_sec_context. We > have no such attributes specified and at least currently I'm not aware > of plans to specify such attributes although I've at least had thought > experiments where doing something like this might have been the right > approach. Right, I certainly implemented something like this for MIT. -- Luke From hartmans@mit.edu Fri May 27 10:14:48 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82991E06F4 for ; Fri, 27 May 2011 10:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.071 X-Spam-Level: X-Spam-Status: No, score=-104.071 tagged_above=-999 required=5 tests=[AWL=-1.806, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STdhBNcjr6Kp for ; Fri, 27 May 2011 10:14:48 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 083B8E068D for ; Fri, 27 May 2011 10:14:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 662C620265; Fri, 27 May 2011 13:10:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9248D4125; Fri, 27 May 2011 13:14:45 -0400 (EDT) From: Sam Hartman To: Alexey Melnikov References: <4DD0AB28.6000406@oracle.com> <4DD4C7A5.5000403@oracle.com> <4DD7B627.40004@isode.com> Date: Fri, 27 May 2011 13:14:45 -0400 In-Reply-To: <4DD7B627.40004@isode.com> (Alexey Melnikov's message of "Sat, 21 May 2011 13:55:03 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:14:48 -0000 I'm happy to contribute to the design of the gss partial context stuff. From hartmans@mit.edu Fri May 27 10:22:07 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFA2E0835 for ; Fri, 27 May 2011 10:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wQVsERtdU1K for ; Fri, 27 May 2011 10:22:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE3E0675 for ; Fri, 27 May 2011 10:22:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DEF1420265; Fri, 27 May 2011 13:17:52 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 11D3C4125; Fri, 27 May 2011 13:22:04 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4809991C-E6EE-4819-89EB-6D692D5F80F0@padl.com> Date: Fri, 27 May 2011 13:22:04 -0400 In-Reply-To: (Nico Williams's message of "Thu, 19 May 2011 10:33:50 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] gss_acquire_cred_ext() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:22:07 -0000 >>>>> "Nico" == Nico Williams writes: Nico> I'll think about this today and get back to you. My preferred Nico> API design for this sort of thing would be to have a function Nico> to acquire an "empty" handle, and one to add a single Nico> attribute -- because we're likely to do that for sec contexts, Nico> I'd like a consistent approach for credentials. The nice Nico> thing about this approach is that you can always add new Nico> functions to set new attributes with data types that are Nico> different from the ones you have in mind today. I'm happy with this sort of approach if we can provide a way that the mechglue need not implement all these functions. I agree with your general design though. I was planning on providing a liberally licensed c++ header with an object for constructing the array in Luke's proposal. I'm happy pushing more of that into the IETF provided we do so in a manner that does not involve the mechglue needing to know about all the attributes. From nico@cryptonector.com Fri May 27 11:58:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD61BE06C7 for ; Fri, 27 May 2011 11:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPBeOcJThQ5o for ; Fri, 27 May 2011 11:58:56 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 49EBEE0671 for ; Fri, 27 May 2011 11:58:56 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id EB36E508078 for ; Fri, 27 May 2011 11:58:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=kfL3vGsU4Bl1zQhSFf/fC q4vaF7NZXqv3z3Mb+4SrDuktUkzvxjXolgELu9U7YI8Ay0X59XPEousM1FYR4814 SGW1ORtdP8qmbt4+RVIfVdjWeC9KHJFqCR/8vXKmK2+M597wg4Rt923uiV2UDKn+ jVgsT8+nUldsVPeo/o2+UU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=wxDA2bg+86ooC6mrlACP OxbnJlg=; b=ojuIMYkipFz9c64YiZcV74Mv+SbWNtugg1VgaQ24t7HNpT8eNv+3 1dAxr0qXcRjGxSLFHXbLLY6GnucBhYVYAWlhj1Gl4p+SULtMJTy6D40PrFyM+W0L AImmNsHKVhOtWxCC5m575yqGAbTfHzgrDeFaBQo9kfJL2mX5UDeRNFs= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id C871B508029 for ; Fri, 27 May 2011 11:58:55 -0700 (PDT) Received: by vws12 with SMTP id 12so1948876vws.31 for ; Fri, 27 May 2011 11:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.106 with SMTP id cp10mr3347512vdc.199.1306522735220; Fri, 27 May 2011 11:58:55 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 11:58:55 -0700 (PDT) In-Reply-To: References: <4DD0AB28.6000406@oracle.com> <4DD4C7A5.5000403@oracle.com> <4DD7B627.40004@isode.com> Date: Fri, 27 May 2011 13:58:55 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 18:58:56 -0000 On Fri, May 27, 2011 at 12:14 PM, Sam Hartman wrote: > I'm happy to contribute to the design of the gss partial context stuff. Me too. From nico@cryptonector.com Fri May 27 12:04:26 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521F8E06A7 for ; Fri, 27 May 2011 12:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVLBVC3J3i-z for ; Fri, 27 May 2011 12:04:25 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id A8728E06A2 for ; Fri, 27 May 2011 12:04:25 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 2013F428083 for ; Fri, 27 May 2011 12:04:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=g7awNI7dL/i/GGAkx40dsCcdMfxdjdjGHIdjTzEw0jjS 1Wjy/+jdg9rmxEonM4UL7zkLghjpaGjyKV99f+s4rR18TycLyESxvKUXFXgonL97 ccuLjHNMJ6L8t/ViCng/6v8yAe3BUv7JLlJ8eFPM6jrZ1aMCtpf184Dq7bLh+s8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=haB/LBPoCSZQdAMcCyWrqklEwek=; b=QYfNZqSNk6K fE9i443IPve61coNTBekKX6hxAfqsJs+WqZyeb0qbfqUjj9ot7vBvchHznjrLgP8 jUusp7tVnppld6YboccgsoH6w1SxyqPHrkXvZTDl1OJ2HEnG3soNSOAFzutde5cm W/Ze85vrUI925YoDR1qkadjIJPGiOxso= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 1463642808D for ; Fri, 27 May 2011 12:03:16 -0700 (PDT) Received: by vws12 with SMTP id 12so1951786vws.31 for ; Fri, 27 May 2011 12:03:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.196 with SMTP id n4mr3711495vdv.39.1306522995115; Fri, 27 May 2011 12:03:15 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 12:03:15 -0700 (PDT) In-Reply-To: References: <4DDDF593.5080100@oracle.com> Date: Fri, 27 May 2011 14:03:15 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:04:26 -0000 On Fri, May 27, 2011 at 12:09 PM, Sam Hartman wrote= : > During the discussions that we held, the authors discovered an issue > that we had not previously discussed. I believe we did discuss it, years ago, when this work was first proposed. > One possible resolution is to do nothing. > > It's possible that you could set an attribute =C2=A0on a name used to acq= uire > credentials or on an attribute used as target name in > gss_init_sec_context. > > It's possible that such an attribute could have semantics that were > intended to change the behavior of acquire_cred or init_sec_context. =C2= =A0We > have no such attributes specified and at least currently I'm not aware > of plans to specify such attributes although I've at least had thought > experiments where doing something like this might have been the right > approach. > > This draft is silent on what happens if such an attribute is set and for > whatever reason the effect of that attribute cannot be carried out. > The typical GSS-API philosophy is that applications need to check to see > if optional services are provided, so this may be the right approach. > > I said I'd write up this situation and discuss whether we want to have > some text about this issue. > > I think all the authors would be happy to wait until someone actually > proposes such an attribute before deciding to do something about this. > I suspect some people (Martin) may even argue that no such attributes > should exist. I would prefer that we cover this now. Here's my proposal: add an 'int critical' argument to GSS_Set_name_attribute() to indicate whether it is critical that the mechanism understand the given attribute wherever the name is used as an input, and allow the mechanism to ignore non-critical attributes that it doesn't understand. Nico -- From lukeh@padl.com Fri May 27 12:07:28 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D61E07D5 for ; Fri, 27 May 2011 12:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1ZTi15xmsh9 for ; Fri, 27 May 2011 12:07:28 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 092ADE0701 for ; Fri, 27 May 2011 12:07:27 -0700 (PDT) Received: by us.padl.com with ESMTP id p4RJ7IQG020138; Fri, 27 May 2011 15:07:22 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 27 May 2011 15:07:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> References: <4DDDF593.5080100@oracle.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_20, FH_HELO_EQ_D_D_D_D, HELO_DYNAMIC_IPADDR2, TVD_RCVD_IP X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 1.2 Cc: "kitten@ietf.org" , Sam Hartman Subject: [kitten] [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:07:28 -0000 > Here's my proposal: add an 'int critical' argument to > GSS_Set_name_attribute() to indicate whether it is critical that the > mechanism understand the given attribute wherever the name is used as > an input, and allow the mechanism to ignore non-critical attributes > that it doesn't understand. Don't forget we (Heimdal and MIT) are shipping since some time now, not = changing the ABI would be nice. -- Luke= From nico@cryptonector.com Fri May 27 12:11:04 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653F9E06B5 for ; Fri, 27 May 2011 12:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFOIwtCboLrK for ; Fri, 27 May 2011 12:11:03 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id ECB92E082D for ; Fri, 27 May 2011 12:11:03 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id C23556B007F for ; Fri, 27 May 2011 12:11:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=SnZfMCukXKy+iBvrApPaX +Yp1cPF3pV9+kBupVz/Olf+CevboLX54YlV9Ek3Mo+vEZBxmkR+J1whzYw3QxLKf vU+jrF+H3NK+fHq1z178EL4faI6LzD0OQF3mq+51gOaw2wdnBL5fCdf2k3VrtC84 98iwT8+Fn9JSqPEkzIRSWc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=zIfa95xCuzf6JTtJdO8U Lu3y6mc=; b=y//iGX6I8OxnQgXoKo4myAEC3zPqSb8AB4IgNpJZ6yc8hXSe7KYf yifYZb6+1ya2xeL6iha0DxpBV/FjzEtzd/8ZXJGjD9kFnL9MZ1IvtjEizH4jFBfA blYQkePknLYFIdxsBUz4K8PMctszJCLwXpdKJzbO55v2HvDz1GzgY5Q= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 949EA6B007E for ; Fri, 27 May 2011 12:11:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so1962041vxg.31 for ; Fri, 27 May 2011 12:11:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.196 with SMTP id n4mr3722697vdv.39.1306523462982; Fri, 27 May 2011 12:11:02 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 12:11:02 -0700 (PDT) In-Reply-To: <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> Date: Fri, 27 May 2011 14:11:02 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:11:04 -0000 On Fri, May 27, 2011 at 2:07 PM, Luke Howard wrote: >> Here's my proposal: add an 'int critical' argument to >> GSS_Set_name_attribute() to indicate whether it is critical that the >> mechanism understand the given attribute wherever the name is used as >> an input, and allow the mechanism to ignore non-critical attributes >> that it doesn't understand. > > Don't forget we (Heimdal and MIT) are shipping since some time now, not changing the ABI would be nice. Ah, I had forgotten, yes. What are the current semantics of these implementations w.r.t. name attributes set via this function? Is this in use at all? Would it be safe to say that these attributes are always critical then? That would be the best solution... Nico -- From lukeh@padl.com Fri May 27 12:16:16 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCEEE07CE for ; Fri, 27 May 2011 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6JYCm1jIDhD for ; Fri, 27 May 2011 12:16:15 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1EE06D1 for ; Fri, 27 May 2011 12:16:15 -0700 (PDT) Received: by us.padl.com with ESMTP id p4RJGA4O027998; Fri, 27 May 2011 15:16:13 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 27 May 2011 15:16:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_40, FH_HELO_EQ_D_D_D_D, HELO_DYNAMIC_IPADDR2, TVD_RCVD_IP X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 1.2 Cc: "kitten@ietf.org" , Sam Hartman Subject: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:16:16 -0000 On 27/05/2011, at 3:11 PM, Nico Williams wrote: > On Fri, May 27, 2011 at 2:07 PM, Luke Howard wrote: >>> Here's my proposal: add an 'int critical' argument to >>> GSS_Set_name_attribute() to indicate whether it is critical that the >>> mechanism understand the given attribute wherever the name is used = as >>> an input, and allow the mechanism to ignore non-critical attributes >>> that it doesn't understand. >>=20 >> Don't forget we (Heimdal and MIT) are shipping since some time now, = not changing the ABI would be nice. >=20 > Ah, I had forgotten, yes. What are the current semantics of these > implementations w.r.t. name attributes set via this function? Is this > in use at all? Would it be safe to say that these attributes are > always critical then? That would be the best solution... Well, we return GSS_S_UNAVAILABLE if the attribute is not recognised. I = don't think there are any shipping plugins that define the semantics of = particular attributes. In the Kerberos case, it's up to the plugin = whether to make the attribute AD-If-Relevant, if that's what you meant = by criticality. -- Luke= From nico@cryptonector.com Fri May 27 12:24:05 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36167E07D5 for ; Fri, 27 May 2011 12:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPy+maZkO1AB for ; Fri, 27 May 2011 12:24:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id B7E93E06FD for ; Fri, 27 May 2011 12:24:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 953C56B007B for ; Fri, 27 May 2011 12:24:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=r/NDm8M1akAKCb9YyKjFLI2t5qACEknKQfHhPmHHYRAT ND0VhUGkuqkIiyJvgIyFQOev32ZePIZ7kUV/FkuPi5ve7tMXpWJyhk101s19QDab 9Kh55hzzgLHdgjf8t+l+rx5i+4us04BtF7TSs8k5vDR/i8whZaWrs9I/GQJmwtE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=vJ4vAHQwHGVqOUNTwu44kbGOWQA=; b=BCZqgWWwBjZ wh7GzZyOteHisZ8RoPkINbTX1NiPHK3REK7Dm0wDcHpfok3riIewI3mSszS9YsBJ RNw/zn8rkobbQFtUYMm5Vg0brtMVEbdJ5H5w3+/bGfGTtTmqA8fTwatsx80aUvIB v/fDUTHr0lJu+vmnX7MpNREi33d89uOs= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 6827B6B0079 for ; Fri, 27 May 2011 12:24:04 -0700 (PDT) Received: by vxg33 with SMTP id 33so1970499vxg.31 for ; Fri, 27 May 2011 12:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.106 with SMTP id cp10mr3381351vdc.199.1306524243812; Fri, 27 May 2011 12:24:03 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 12:24:03 -0700 (PDT) In-Reply-To: <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> Date: Fri, 27 May 2011 14:24:03 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:24:05 -0000 On Fri, May 27, 2011 at 2:16 PM, Luke Howard wrote: >> Ah, I had forgotten, yes. =C2=A0What are the current semantics of these >> implementations w.r.t. name attributes set via this function? =C2=A0Is t= his >> in use at all? =C2=A0Would it be safe to say that these attributes are >> always critical then? =C2=A0That would be the best solution... > > Well, we return GSS_S_UNAVAILABLE if the attribute is not recognised. I d= on't think there are any shipping plugins that define the semantics of part= icular attributes. In the Kerberos case, it's up to the plugin whether to m= ake the attribute AD-If-Relevant, if that's what you meant by criticality. That's not the only thing I meant by criticality. Imagine an attribute that corresponds to Kerberos realm, or, perhaps, transit path: in this case criticality would refer to the mechanism ensuring that the target is in the given realm or across the given transit path. Ah... I think it'd be quite fine if we said that these attributes are non-critical, and that the caller has to inquire any resulting credentials' or security contexts' target names to see what resulted. Nico -- From hartmans@mit.edu Fri May 27 12:34:33 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A5EE0700 for ; Fri, 27 May 2011 12:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.813 X-Spam-Level: X-Spam-Status: No, score=-103.813 tagged_above=-999 required=5 tests=[AWL=-1.548, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeQrOr2NSWew for ; Fri, 27 May 2011 12:34:32 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B7117E06A2 for ; Fri, 27 May 2011 12:34:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6DC8120265; Fri, 27 May 2011 15:30:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 606834125; Fri, 27 May 2011 15:34:29 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4DDDF593.5080100@oracle.com> Date: Fri, 27 May 2011 15:34:29 -0400 In-Reply-To: (Nico Williams's message of "Fri, 27 May 2011 14:03:15 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:34:33 -0000 >>>>> "Nico" == Nico Williams writes: Nico> I would prefer that we cover this now. Nico> Here's my proposal: add an 'int critical' argument to Nico> GSS_Set_name_attribute() to indicate whether it is critical Nico> that the mechanism understand the given attribute wherever the Nico> name is used as an input, and allow the mechanism to ignore Nico> non-critical attributes that it doesn't understand. I'm against changing the function signature of anything specified by C bindings in this document. I'd support adding a new API in a future document (set_critical_attribute) if we need it. From hartmans@mit.edu Fri May 27 12:39:44 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596C2E0718 for ; Fri, 27 May 2011 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vo+MMpGroYR for ; Fri, 27 May 2011 12:39:43 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C81E9E0700 for ; Fri, 27 May 2011 12:39:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F29252009E; Fri, 27 May 2011 15:35:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 17EB64125; Fri, 27 May 2011 15:39:41 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> Date: Fri, 27 May 2011 15:39:41 -0400 In-Reply-To: (Nico Williams's message of "Fri, 27 May 2011 14:24:03 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:39:44 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Ah... I think it'd be quite fine if we said that these Nico> attributes are non-critical, and that the caller has to Nico> inquire any resulting credentials' or security contexts' Nico> target names to see what resulted. I'm also against this proposal because it is impractical. In particular, in a mechanism like iakerb, when do you actually find out if the attribute is being respected? What about a mechanism like Moonshot's implementation of gss-eap that sometimes goes through Kerberos but sometimes does not? I think I'm with Simon and we should not go into this now. In particular, I think it's unreasonable to ask the application to check after every call to init_sec_context. Even if you buy it's reasonable to ask the application to check the resulting context, which I am dubious about, it's not clear whether asking the application to check after the first call is good enough and asking the application to check at the end can be highly problematic. Solutions I can live with in the future: * gss_set_critical_name_attribute or whatever * A mechanism attribute indicating a mechanism understands some well-defined set of attributes. From lukeh@padl.com Fri May 27 12:41:16 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2ABE0718 for ; Fri, 27 May 2011 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PdKURVw4T4W for ; Fri, 27 May 2011 12:41:15 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9040FE0700 for ; Fri, 27 May 2011 12:41:15 -0700 (PDT) Received: by us.padl.com with ESMTP id p4RJfAjL001716; Fri, 27 May 2011 15:41:13 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 27 May 2011 15:41:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <03DC139B-B691-4E6D-91DB-35E3F1B65487@padl.com> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_05, FH_HELO_EQ_D_D_D_D, HELO_DYNAMIC_IPADDR2, TVD_RCVD_IP X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 1.1 Cc: "kitten@ietf.org" Subject: [kitten] [SPAM] Re: [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:41:16 -0000 If you really want to add a flag and keep the ABI, we could make the = complete argument a bit mask in the API bindings, but it's kind of ugly = as we'd normally use OM_uint32 for that. -- Luke= From nico@cryptonector.com Fri May 27 12:49:16 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62BFE07EE for ; Fri, 27 May 2011 12:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiVwKfpebGb2 for ; Fri, 27 May 2011 12:49:16 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 61EE3E07D5 for ; Fri, 27 May 2011 12:49:16 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 17905B8072 for ; Fri, 27 May 2011 12:49:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=A3N1p+UAU5nI6S7utP6Xt s8ELl8s9Y9tOY5ziAbLyfSYcloLlYmxEYIoet7bSTSPpI2dUdDYVI2c2c7rrYItc sqxp6Y+DcfUZjpxXcm41/7YS4duXOisGZcZhhxZfyaVg+sB5UXAypdHAVSxfoOJ5 qpvY0fA7jUtUn+mjlisJxo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=RzlkQC4wdGiEfGF3G2E6 Mb+e5jo=; b=Yqy7y53g9WfW+esHgdQwWSXofreEgBAw8Z2JG4RsV9EQjac6QTXW chMkPwGJUzpNGSJQ1H76M9fP6Fo57vXtRCFD1mGCGt/1L8bLlhaMQyuMZNOhsTCV zPxMH2hTaHHIDEO4kcpXsZaWE9tCPzyP4dez1ZLgw8JHUXj+x/tzdpE= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id E5874B8074 for ; Fri, 27 May 2011 12:49:15 -0700 (PDT) Received: by vxg33 with SMTP id 33so1986950vxg.31 for ; Fri, 27 May 2011 12:49:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.170 with SMTP id dd10mr3536089vdb.159.1306525755355; Fri, 27 May 2011 12:49:15 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 12:49:15 -0700 (PDT) In-Reply-To: References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> Date: Fri, 27 May 2011 14:49:15 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:49:17 -0000 Going by what you say, Sam, I have the impression that nothing's really using this function yet, so then why don't we say that all attributes set with it are critical in that the mechanism must understand them? From nico@cryptonector.com Fri May 27 12:50:08 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F456E0802 for ; Fri, 27 May 2011 12:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY5DSi1nmykL for ; Fri, 27 May 2011 12:50:07 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 647FFE07D5 for ; Fri, 27 May 2011 12:50:07 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 2A27C1B406F for ; Fri, 27 May 2011 12:50:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=tjs8CegFFOrhW/JO3Ajx2 alZ4GdfPKzBruFChzjbyMCwYOxc1eZnCB7dG6Q2uIq8nE9iCONhkHwEwPUCPQwTm e+lpoivhuKtCL2VqvXEF33M86kW/egoPwqCm2dOTDiN6rK34YRLqjWP6eDGHeIxA ujzbgKBO9GeXDlOpBHvC2E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Mr5WpMQbDBPW4l4cJQXR 1TByqwA=; b=gbt6IZMwZiPOQo6gohGw4Xpx0hfNbla14rYMutj+dfGHWm/rmvMP TbjpwZF9dqwVMcGWM03IfnVgyELgvZHJ7EY63YwnY30HgCpo4f7DbiByY3AtCHeO 9N6Hpj9dwTLl5/Ei97VynCz9wtQ3GaCJVIID6yisEl1UG5/heSjP2Uw= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E51061B406B for ; Fri, 27 May 2011 12:50:06 -0700 (PDT) Received: by vxg33 with SMTP id 33so1987494vxg.31 for ; Fri, 27 May 2011 12:50:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.196 with SMTP id n4mr3776652vdv.39.1306525806224; Fri, 27 May 2011 12:50:06 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 12:50:06 -0700 (PDT) In-Reply-To: <03DC139B-B691-4E6D-91DB-35E3F1B65487@padl.com> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <03DC139B-B691-4E6D-91DB-35E3F1B65487@padl.com> Date: Fri, 27 May 2011 14:50:06 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:50:08 -0000 On Fri, May 27, 2011 at 2:41 PM, Luke Howard wrote: > If you really want to add a flag and keep the ABI, we could make the complete argument a bit mask in the API bindings, but it's kind of ugly as we'd normally use OM_uint32 for that. Actually, that's not a bad idea. I kinda like it. From simon@josefsson.org Fri May 27 13:13:08 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD60CE06C4 for ; Fri, 27 May 2011 13:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhrNn2YHVrBA for ; Fri, 27 May 2011 13:13:08 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id D174BE072C for ; Fri, 27 May 2011 13:13:07 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4RKCl1f029436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 May 2011 22:12:49 +0200 From: Simon Josefsson To: Sam Hartman References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110527:kitten@ietf.org::9rvL8600zgZqIwd1:3v4N X-Hashcash: 1:22:110527:nico@cryptonector.com::iPIUPAQd/J+KZd2i:Z4Z9 X-Hashcash: 1:22:110527:hartmans-ietf@mit.edu::XnUaJtRQZdt4ZumK:YM0D Date: Fri, 27 May 2011 22:12:47 +0200 In-Reply-To: (Sam Hartman's message of "Fri, 27 May 2011 15:39:41 -0400") Message-ID: <87pqn3aon4.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 20:13:08 -0000 My preference is to defer any additions, unless we identify some reason why it cannot be done later and that it has to be done in this document. I'm not convinced it is sufficient to have a boolean critical flag. For example, it may be that the local mechaninism understands an attribute, and attempts to enforce it, but was not able to (due to the server or something else). The security context establishment could fail in this case. It may better to proceed and to let the application query the security context for what happened. Thus, I propose applications invoke GSS_Inquire_context to get "targ_name" once the context is established (or even before it) and use GSS_Get_name_attribute to extract some attributes, and that these attributes and their value is what the application looks at. It is just a matter of defining some attributes that means whatever we want them to mean, including "that other attribute was honored during this context establishment". If the application asserted one attribute, that attribute could specify two other attributes that is returned after the context is established, one would be present if the mechanism supported the attribute, and another could be present if the mechanism supported the attribute and it did something useful. Would this work? /Simon From lukeh@padl.com Fri May 27 13:19:13 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64C9E0807 for ; Fri, 27 May 2011 13:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDSsZeTjxwtS for ; Fri, 27 May 2011 13:19:13 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61BE072F for ; Fri, 27 May 2011 13:19:12 -0700 (PDT) Received: by us.padl.com with ESMTP id p4RKJ6jZ001864; Fri, 27 May 2011 16:19:10 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 27 May 2011 16:19:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <540C1EDD-DC96-4DDD-853E-ABB72FE627AE@padl.com> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <03DC139B-B691-4E6D-91DB-35E3F1B65487@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_05, FH_HELO_EQ_D_D_D_D, HELO_DYNAMIC_IPADDR2, TVD_RCVD_IP X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 1.1 Cc: "kitten@ietf.org" , Sam Hartman Subject: [kitten] [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 20:19:13 -0000 On 27/05/2011, at 3:50 PM, Nico Williams wrote: > On Fri, May 27, 2011 at 2:41 PM, Luke Howard wrote: >> If you really want to add a flag and keep the ABI, we could make the = complete argument a bit mask in the API bindings, but it's kind of ugly = as we'd normally use OM_uint32 for that. >=20 > Actually, that's not a bad idea. I kinda like it. Hmm. Aesthetically, not so nice. -- Luke= From nico@cryptonector.com Fri May 27 13:28:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CC5E06A8 for ; Fri, 27 May 2011 13:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGshrZKnPTh1 for ; Fri, 27 May 2011 13:28:45 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3153AE0678 for ; Fri, 27 May 2011 13:28:45 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id DF4646B0079 for ; Fri, 27 May 2011 13:28:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=eFj+clXcCU1Mv6l1l/EZdcStF3F3QN7rAK/qqeVuo0Qg Obp6WtDkgNEttDuhMJozo3zg2XwyvHZwXAHih62P8qy34FA3jql+/TOblWDWhmak kPHjcHYtSdkFXTjkTANx0nYWetlUCJOSiqYkOA0Bg9rx/kywQMh1S2JoVh+iFTM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Ffe7noQWCLaE8XswmaPa5nJSV08=; b=JM4aSEfsOVN aK0nkUvQkbs+dP+uk1HLKQmYK6uxdkV+gVLJAjdUxVuBJ8VXIAsvrGlqhKHqnKSq JdMsWD3YhG0zU8C3aOb+P4MvSYe5xPwPB41+UKAx1Xk9OLaLy83rgpiv+ClzmWYL Dwq9AWsIo++aPNsevS769PIJyRkCt64Q= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id B41BD6B0070 for ; Fri, 27 May 2011 13:28:44 -0700 (PDT) Received: by vxg33 with SMTP id 33so2012250vxg.31 for ; Fri, 27 May 2011 13:28:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.196 with SMTP id n4mr3826466vdv.39.1306528124073; Fri, 27 May 2011 13:28:44 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 13:28:44 -0700 (PDT) In-Reply-To: <87pqn3aon4.fsf@latte.josefsson.org> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <87pqn3aon4.fsf@latte.josefsson.org> Date: Fri, 27 May 2011 15:28:44 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 20:28:46 -0000 On Fri, May 27, 2011 at 3:12 PM, Simon Josefsson wrot= e: > My preference is to defer any additions, unless we identify some reason > why it cannot be done later and that it has to be done in this document. I'd rather first see if we can resolve this now. We have until WGLC ends to do before we decide to punt. > I'm not convinced it is sufficient to have a boolean critical flag. > > For example, it may be that the local mechaninism understands an > attribute, and attempts to enforce it, but was not able to (due to the > server or something else). =C2=A0The security context establishment could > fail in this case. =C2=A0It may better to proceed and to let the applicat= ion > query the security context for what happened. > > Thus, I propose applications invoke GSS_Inquire_context to get > "targ_name" once the context is established (or even before it) and use > GSS_Get_name_attribute to extract some attributes, and that these > attributes and their value is what the application looks at. =C2=A0It is = just > a matter of defining some attributes that means whatever we want them to > mean, including "that other attribute was honored during this context > establishment". =C2=A0If the application asserted one attribute, that > attribute could specify two other attributes that is returned after the > context is established, one would be present if the mechanism supported > the attribute, and another could be present if the mechanism supported > the attribute and it did something useful. > > Would this work? I proposed using inquiry functions to find out what happens because there's precedent for it in the GSS-API (think of non-MN targ_name values passed to GSS_Init_sec_context()). Sam didn't like that approach, but I don't see what else we could do regarding security context establishment. For some mechanisms there may not be any way to determine support for a given target name attribute until the target thinks the context is fully established. We could make name attributes critical relative to credential acquisition. It'd be odd, but OK with me, to make name attributes critical only for credential acquisition but not security context target. Nico -- From hartmans@mit.edu Sat May 28 08:06:37 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABECE0704 for ; Sat, 28 May 2011 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.619 X-Spam-Level: X-Spam-Status: No, score=-103.619 tagged_above=-999 required=5 tests=[AWL=-1.354, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFY14BLqnJXp for ; Sat, 28 May 2011 08:06:37 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E1402E06EC for ; Sat, 28 May 2011 08:06:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 53AC7201C9; Sat, 28 May 2011 11:02:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 99FA94125; Sat, 28 May 2011 11:06:30 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <87pqn3aon4.fsf@latte.josefsson.org> Date: Sat, 28 May 2011 11:06:30 -0400 In-Reply-To: (Nico Williams's message of "Fri, 27 May 2011 15:28:44 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 15:06:37 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Fri, May 27, 2011 at 3:12 PM, Simon Josefsson wrote: >> My preference is to defer any additions, unless we identify some >> reason why it cannot be done later and that it has to be done in >> this document. Nico> I'd rather first see if we can resolve this now. We have Nico> until WGLC ends to do before we decide to punt. There's no way I'll be happy with a solution now. I've convinced myself the problem is a bit tricky. I've convinced myself that: * A critical flag is difficult to specify and may be insufficient. I can think of multiple things it could mean * Ignoring the issue and having the initiator look at the resulting context is undesirable and for things like restrictions on a ticket possibly actively harmful * I can't see any reason to decide this now. I also don't have a lot of time to think about this. So, I have a strong preference for doing nothing unless it can be shown that doing nothing is harmful. From nico@cryptonector.com Sat May 28 08:49:19 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD81E06DA for ; Sat, 28 May 2011 08:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifZDOuHJSOWg for ; Sat, 28 May 2011 08:49:18 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6671CE0664 for ; Sat, 28 May 2011 08:49:18 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 1127C1B4059 for ; Sat, 28 May 2011 08:49:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=GYxE9Su/6jkYPlrYsT8+2qs806O/fU0HaV4s+BbDflS4 BQ665206x6lujbcjRQLRBPcPRYiv/BPQOR+uQLpSCNoiWTSHM1O5DddmPmCcIsAE YSxSVQl4ETLiNFiBarhL2DqCQd76PrZ0cM3RxjMNqyawPxabLCA6T9X1Kf2vW1Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=1OwRYhncFD/USsLKZgPzxKHmIKE=; b=MB1SkfzhFNb jRdjE0jbESUNxjSip5ew6pOG3IJv56jQDd5sPrlevL3VrSQTUqve9UynCP1rBNVJ FSWZ/k12TT0cbubSblCGGQ68EydcgwqdNv+a5af/5IlFVr3XCQKGKXyiAHVPuyZx XKYJmmPXykjYQqg9otEr3XVKTimidMNg= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E270B1B4058 for ; Sat, 28 May 2011 08:49:17 -0700 (PDT) Received: by vws12 with SMTP id 12so2472726vws.31 for ; Sat, 28 May 2011 08:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.133 with SMTP id ia5mr4526351vdb.239.1306597757122; Sat, 28 May 2011 08:49:17 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Sat, 28 May 2011 08:49:17 -0700 (PDT) In-Reply-To: References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <87pqn3aon4.fsf@latte.josefsson.org> Date: Sat, 28 May 2011 10:49:17 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 15:49:19 -0000 On Sat, May 28, 2011 at 10:06 AM, Sam Hartman wrote= : > There's no way I'll be happy with a solution now. =C2=A0I've convinced my= self > the problem is a bit tricky. I've convinced myself that: > > * A critical flag is difficult to specify and may be insufficient. I can > =C2=A0think of multiple things it could mean > > * Ignoring the issue and having the initiator look at the resulting > =C2=A0context is undesirable and for things like restrictions on a ticket > =C2=A0possibly actively harmful All the more reason to get criticality right right now. Or at least know that we're not painting ourselves into any corners. For example, I think we should remove the set-attribute function if we choose to not resolve its semantics now, as implementors will be forced to pick some semantics for it, which will then cause us trouble down the line. Worse, since implementors already ship that and will want to continue doing so, we kinda need to clarify its semantics now. > * I can't see any reason to decide this now. See above > I also don't have a lot of time to think about this. There's no need to hurry though, is there? If we're not readyto pass WGLC, we can wait until a more opportune time. > So, I have a strong preference for doing nothing unless it can be shown > that doing nothing is harmful. Well, if different implementors implement different semantics for this function, that will cause some harm -- not a lot, perhaps not enough for us to bother nailing this down, but I think we should try. Nico -- From simon@josefsson.org Sun May 29 00:06:31 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE24E0686 for ; Sun, 29 May 2011 00:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UD6nvtCv5k9 for ; Sun, 29 May 2011 00:06:30 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id CE3A5E069E for ; Sun, 29 May 2011 00:06:28 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4T768cJ027760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 29 May 2011 09:06:10 +0200 From: Simon Josefsson To: Nico Williams References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <87pqn3aon4.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110529:kitten@ietf.org::LsMhqqTbs+U9hLWe:0zmL X-Hashcash: 1:22:110529:nico@cryptonector.com::mTFGAVNStgWWbFp5:63Ho X-Hashcash: 1:22:110529:hartmans-ietf@mit.edu::90GWTNA/fWAIyaom:890n Date: Sun, 29 May 2011 09:06:08 +0200 In-Reply-To: (Nico Williams's message of "Sat, 28 May 2011 10:49:17 -0500") Message-ID: <87aae67zq7.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 07:06:31 -0000 Nico Williams writes: > On Sat, May 28, 2011 at 10:06 AM, Sam Hartman wrote: >> There's no way I'll be happy with a solution now.  I've convinced myself >> the problem is a bit tricky. I've convinced myself that: >> >> * A critical flag is difficult to specify and may be insufficient. I can >>  think of multiple things it could mean >> >> * Ignoring the issue and having the initiator look at the resulting >>  context is undesirable and for things like restrictions on a ticket >>  possibly actively harmful > > All the more reason to get criticality right right now. Or at least > know that we're not painting ourselves into any corners. > > For example, I think we should remove the set-attribute function if we > choose to not resolve its semantics now, as implementors will be > forced to pick some semantics for it, which will then cause us trouble > down the line. Worse, since implementors already ship that and will > want to continue doing so, we kinda need to clarify its semantics now. I'm not following this -- why are implementations forced to resolve this semantics now? Why can't the semantics wrt credential acquisition be attribute specific? /Simon From nico@cryptonector.com Sun May 29 00:19:45 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A676E069E for ; Sun, 29 May 2011 00:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grMoXyoojk3d for ; Sun, 29 May 2011 00:19:44 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id DFFB1E0686 for ; Sun, 29 May 2011 00:19:44 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id A8A39508063 for ; Sun, 29 May 2011 00:19:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=f24vMfsbAtHQWq6aiP07lSFefg822fX/0zgfmGxitB2A Bsu/n6tudiExBmYLVMNoABeMOtrG9WlZMQYe9b5Rr+OCmx1Nln9mlfAove2DGo9y l1QqR9NDHIJa5Q3t9WYjgCBdMmJIrbu3iVkxY2JjPcmlWY0hoHXsTZujnScK5ek= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=KLbQ7ueDSSgTOvRjyiAlo5EMSU4=; b=ogwbrr737sQ Hu5+m2cH5kfEsDBWJCmrv/7TtsY/iaLmvFciLI74HdiWUcdYrhwnDHf5EJR7rcxE Q7DjtpDr4Of8WenyhECwm5WWtfpHgUOEieGoY387Dpi4ArBvZF3iXKsdi8kYXaJf jLPL3+LHJfzZ5Y+SgRtVMtbc9Z3D4HOU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 828C8508029 for ; Sun, 29 May 2011 00:19:44 -0700 (PDT) Received: by vws12 with SMTP id 12so2798343vws.31 for ; Sun, 29 May 2011 00:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.170 with SMTP id dd10mr5208404vdb.159.1306653583734; Sun, 29 May 2011 00:19:43 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Sun, 29 May 2011 00:19:43 -0700 (PDT) In-Reply-To: <87aae67zq7.fsf@latte.josefsson.org> References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <87pqn3aon4.fsf@latte.josefsson.org> <87aae67zq7.fsf@latte.josefsson.org> Date: Sun, 29 May 2011 02:19:43 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 07:19:45 -0000 On Sun, May 29, 2011 at 2:06 AM, Simon Josefsson wrot= e: > Nico Williams writes: > >> On Sat, May 28, 2011 at 10:06 AM, Sam Hartman wr= ote: >>> There's no way I'll be happy with a solution now. =C2=A0I've convinced = myself >>> the problem is a bit tricky. I've convinced myself that: >>> >> All the more reason to get criticality right right now. =C2=A0Or at leas= t >> know that we're not painting ourselves into any corners. >> >> For example, I think we should remove the set-attribute function if we >> choose to not resolve its semantics now, as implementors will be >> forced to pick some semantics for it, which will then cause us trouble >> down the line. =C2=A0Worse, since implementors already ship that and wil= l >> want to continue doing so, we kinda need to clarify its semantics now. > > I'm not following this -- why are implementations forced to resolve this > semantics now? [...] This is our chance to make sure that different implementations don't provide different, incompatible semantics. I happen to think that that's important. > [...] Why can't the semantics wrt credential acquisition be > attribute specific? The issue is that the set-attribute function's semantics need to be clear. As for whether the semantics should be attribute-specific, well, if there's any way in which an attribute's being set on a name prior to credential acquisition or prior to using the name as a target name, could be meaningful... What else could that meaning be if not that the resulting authenticated principal's name will bear that attribute? Consider an attribute for naming a trust path (think of a Kerberos transited path, or a PKI certificate validation path): surely we'll want a name attribute to indicate trust path, and surely setting the trust path attribute on a name should actually result in that trust path being required. Maybe it's because it's late, but I can't think of any attributes that one wouldn't want to work this way. So we only have to decide criticality. Sam makes a very good case for criticality being the default. Privately Sam asked if it'd make a difference if an attribute was set on an MN versus a non-MN -- I think that would be an interesting way to distinguish between critical and non-critical. Nico -- From simon@josefsson.org Sun May 29 11:47:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C63E0759 for ; Sun, 29 May 2011 11:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wcz56Wp-d7gE for ; Sun, 29 May 2011 11:47:55 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id C3C4FE0756 for ; Sun, 29 May 2011 11:47:42 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4TIlRP4026156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 29 May 2011 20:47:30 +0200 From: Simon Josefsson To: Nico Williams References: <4DDDF593.5080100@oracle.com> <5543C0A1-EDF8-4573-B1D5-7E46EFEC3A67@padl.com> <2A490007-53BC-492A-A7AD-AC6FBE01BC6E@padl.com> <87pqn3aon4.fsf@latte.josefsson.org> <87aae67zq7.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110529:hartmans-ietf@mit.edu::S+W4LCiU1mBUxwhH:RYA X-Hashcash: 1:22:110529:nico@cryptonector.com::s4lnTk14xgm4fo5S:4mOz X-Hashcash: 1:22:110529:kitten@ietf.org::NZg4bk+/dAVx1GJS:JmMG Date: Sun, 29 May 2011 20:47:26 +0200 In-Reply-To: (Nico Williams's message of "Sun, 29 May 2011 02:19:43 -0500") Message-ID: <87boyljqdd.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] [SPAM] Re: [SPAM] Re: WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 18:47:56 -0000 Nico Williams writes: > On Sun, May 29, 2011 at 2:06 AM, Simon Josefsson wrote: >> Nico Williams writes: >> >>> On Sat, May 28, 2011 at 10:06 AM, Sam Hartman wrote: >>>> There's no way I'll be happy with a solution now.  I've convinced myself >>>> the problem is a bit tricky. I've convinced myself that: >>>> >>> All the more reason to get criticality right right now.  Or at least >>> know that we're not painting ourselves into any corners. >>> >>> For example, I think we should remove the set-attribute function if we >>> choose to not resolve its semantics now, as implementors will be >>> forced to pick some semantics for it, which will then cause us trouble >>> down the line.  Worse, since implementors already ship that and will >>> want to continue doing so, we kinda need to clarify its semantics now. >> >> I'm not following this -- why are implementations forced to resolve this >> semantics now? [...] > > This is our chance to make sure that different implementations don't > provide different, incompatible semantics. I happen to think that > that's important. I agree -- but if each attribute provides guidance, surely implementers of those attributes will behave the same? Is your worry that we don't provide enough guidance to people specifying attributes? >> [...] Why can't the semantics wrt credential acquisition be >> attribute specific? > > The issue is that the set-attribute function's semantics need to be clear. > > As for whether the semantics should be attribute-specific, well, if > there's any way in which an attribute's being set on a name prior to > credential acquisition or prior to using the name as a target name, > could be meaningful... What else could that meaning be if not that > the resulting authenticated principal's name will bear that attribute? > Consider an attribute for naming a trust path (think of a Kerberos > transited path, or a PKI certificate validation path): surely we'll > want a name attribute to indicate trust path, and surely setting the > trust path attribute on a name should actually result in that trust > path being required. Maybe it's because it's late, but I can't think > of any attributes that one wouldn't want to work this way. I can think of plenty of attributes that would not demand that the target name has the same attribute. For example, the attribute named "http://josefsson.org/ foobar" that I define now to mean absolutely nothing. If an application set that attribute on a name, and establish a security context to that target name, the target name would not necessarily have that attribute asserted. /Simon