From kitten-bounces@lists.ietf.org Thu Apr 05 17:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZt2-0002f2-IV; Thu, 05 Apr 2007 17:52:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZt0-0002V9-Nl for kitten@lists.ietf.org; Thu, 05 Apr 2007 17:52:54 -0400 Received: from citi.umich.edu ([141.211.133.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZZsz-0004qJ-Cz for kitten@lists.ietf.org; Thu, 05 Apr 2007 17:52:54 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id DACAD392A1; Thu, 5 Apr 2007 17:52:52 -0400 (EDT) Message-ID: <46156FB4.4070007@citi.umich.edu> Date: Thu, 05 Apr 2007 17:52:52 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: kitten@lists.ietf.org, spkm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Is PKU2U meant to be a GSS API mechanism or a stand alone security protocol? The abstract seems to imply that pku2u could be a stand alone protocol. However, the 1st sentence of the Section 5 says that pku2u "can only be used in conjunction with GSS-API". In Section 5, The syntax of the initial context establishment token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. PKU2U is identified by the Objection Identifier (OID) id-kerberos- pku2u. id-kerberos-pku2u ::= { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) pku2u(7) } Subsequent context establishment tokens MUST NOT be encapsulated in this GSS-API generic token framing. First, I hope that the 1st sentence refers to "tokens" not just the 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed but the AS_REP token is not which doesn't make sense. Second, what does the "subsequent context establishment tokens" refer to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. I propose to remove this sentence from the draft. What would be left is the description how to frame context establishment tokens (AS_REQ/AS_REP) and then the rest are treated as per-message token according to rfc4121. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 05 19:08:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZb49-0001Fp-0R; Thu, 05 Apr 2007 19:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZb47-0001Cp-BX for kitten@lists.ietf.org; Thu, 05 Apr 2007 19:08:28 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZb44-0002Vc-7y for kitten@lists.ietf.org; Thu, 05 Apr 2007 19:08:27 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l35N8NKI028944 for ; Thu, 5 Apr 2007 23:08:23 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l35N8M7M021836 for ; Thu, 5 Apr 2007 17:08:23 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l35N7VR0005662; Thu, 5 Apr 2007 18:07:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l35N7Upr005661; Thu, 5 Apr 2007 18:07:30 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Apr 2007 18:07:30 -0500 From: Nicolas Williams To: Olga Kornievskaia Message-ID: <20070405230730.GB28748@Sun.COM> Mail-Followup-To: Olga Kornievskaia , kitten@lists.ietf.org, spkm@ietf.org References: <46156FB4.4070007@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46156FB4.4070007@citi.umich.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: kitten@lists.ietf.org, spkm@ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 05, 2007 at 05:52:52PM -0400, Olga Kornievskaia wrote: > Is PKU2U meant to be a GSS API mechanism or a stand alone security > protocol? The abstract seems to imply that pku2u could be a stand alone > protocol. However, the 1st sentence of the Section 5 says that pku2u > "can only be used in conjunction with GSS-API". GSS mechanisms can be stand-alone too, I suppose. PKU2U has got to be intended to be a standards-track GSS-API mechanism, else why are we here? > In Section 5, > > The syntax of the initial context establishment token follows the > initialContextToken syntax defined in Section 3.1 of [RFC2743]. > PKU2U is identified by the Objection Identifier (OID) id-kerberos- > pku2u. > > id-kerberos-pku2u ::= > { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) > pku2u(7) } > > Subsequent context establishment tokens MUST NOT be encapsulated in > this GSS-API generic token framing. > > > First, I hope that the 1st sentence refers to "tokens" not just the 1st > (AS_REQ) token. As its written, it says that AS_REQ token is framed but > the AS_REP token is not which doesn't make sense. No, it *does* make sense. RFC2743 only requires the pseudo-ASN.1 DER header on the initial context token. It does not require it on any other tokens at all. RFC1964 went beyond this and required the use of that header on all of the Kerberos V GSS mechanism's context and per-message tokens. We all recognize that there was little or no point to this, so when we were working on RFC4121 we wanted to dispense with that header on all but the initial context token (that one being required by RFC2743) and settled for not having that header on per-message tokens but keeping it on all context tokens (primarily because of packet inspection tools that are used to them having that header, as I recall). > Second, what does the "subsequent context establishment tokens" refer > to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? PKU2U's context token exchanges look like this: I: AS-REQ A: AS-REP I: AP-REQ A: AP-REP Here the first one is the "initial context establishment token" and the subsequent three tokens are ""subsequent context establishment tokens." > Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. This is incorrect. > I propose to remove this sentence from the draft. What would be left is > the description how to frame context establishment tokens > (AS_REQ/AS_REP) and then the rest are treated as per-message token > according to rfc4121. You might argue that if you'd like to build PKU2U as a stackable mechanism that stacks on top of RFC4121 *then* having the RFC2743 header on the AP-REQ/AP-REP tokens in the PKU2U spec would help keep your implementation simple. As a proponent of stackable mechanisms I tend to agree, but because this stackable mechanism in particular would be stackable only on top of RFC1964/RFC4121 it would be OK for the implementation to know to remove the header on output/insert the header on input. [Note to skeptics: yes, such a stackable mechanism would need a special interface by which it could turn acquire a CREDENTIAL HANDLE for the Kerberos V mechanism using a Ticket, ticket session key and ancilliary data. In Solaris we have gss_acquire_cred_with_password(); we could easily add gss_acquire_cred_with_ticket()...] I feel loath to perpetuate the mistake made in RFC1964 of adding that header that had been intended only for the initial context token to all tokens. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 06 03:29:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZisO-0007YV-Pb; Fri, 06 Apr 2007 03:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZisM-0007YG-MP for kitten@lists.ietf.org; Fri, 06 Apr 2007 03:28:50 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZisJ-0001v0-80 for kitten@lists.ietf.org; Fri, 06 Apr 2007 03:28:50 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 6 Apr 2007 00:28:46 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Fri, 6 Apr 2007 00:28:46 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Apr 2007 00:28:46 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2007 00:28:27 -0700 Message-ID: In-Reply-To: <46156FB4.4070007@citi.umich.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt thread-index: Acd4BGUsFkcuKA6FRNmwF8cjiYBM3AAGKRiw References: <46156FB4.4070007@citi.umich.edu> From: "Liqiang(Larry) Zhu" To: Olga Kornievskaia , , X-OriginalArrivalTime: 06 Apr 2007 07:28:46.0262 (UTC) FILETIME=[363BC560:01C7781D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Subject: RE: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Olga Kornievskaia wrote: > Is PKU2U meant to be a GSS API mechanism or a standalone security=20 > protocol? The abstract seems to imply that pku2u could be a stand=20 > alone protocol. However, the 1st sentence of the Section 5 says that=20 > pku2u "can only be used in conjunction with GSS-API". PKU2U as defined here requires the use of GSS-API. I do not know if you have objections to this requirement. > First, I hope that the 1st sentence refers to "tokens" not just the=20 > 1st > (AS_REQ) token. As its written, it says that AS_REQ token is framed=20 > but the AS_REP token is not which doesn't make sense. Your understanding is correct. Only the first message has the framing. This is consistent with RFC4121 and RFC4178. > Second, what does the "subsequent context establishment tokens" refer=20 > to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? > Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. Only the first message has the token framing. This is how all other GSS-API mechanisms work today. --larry -----Original Message----- From: Olga Kornievskaia [mailto:aglo@citi.umich.edu]=20 Sent: Thursday, April 05, 2007 2:53 PM To: kitten@lists.ietf.org; spkm@ietf.org Subject: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Is PKU2U meant to be a GSS API mechanism or a stand alone security=20 protocol? The abstract seems to imply that pku2u could be a stand alone=20 protocol. However, the 1st sentence of the Section 5 says that pku2u=20 "can only be used in conjunction with GSS-API". In Section 5, The syntax of the initial context establishment token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. PKU2U is identified by the Objection Identifier (OID) id-kerberos- pku2u. id-kerberos-pku2u ::=3D { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) pku2u(7) } Subsequent context establishment tokens MUST NOT be encapsulated in this GSS-API generic token framing. First, I hope that the 1st sentence refers to "tokens" not just the 1st=20 (AS_REQ) token. As its written, it says that AS_REQ token is framed but=20 the AS_REP token is not which doesn't make sense. Second, what does the "subsequent context establishment tokens" refer=20 to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)?=20 Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. I propose to remove this sentence from the draft. What would be left is=20 the description how to frame context establishment tokens=20 (AS_REQ/AS_REP) and then the rest are treated as per-message token=20 according to rfc4121. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 12 10:12:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc02M-0005Gw-SI; Thu, 12 Apr 2007 10:12:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc02L-0005Gr-JM for kitten@ietf.org; Thu, 12 Apr 2007 10:12:33 -0400 Received: from irvbhxw02.quest.com ([12.106.87.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc02K-00075n-Au for kitten@ietf.org; Thu, 12 Apr 2007 10:12:33 -0400 Thread-Index: Acd9DJsExkgCzrUoQEudf9NiFvv+6w== Received: from melmbxw01.prod.quest.corp ([10.20.4.118]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 07:12:29 -0700 Received: from [10.100.0.16] ([10.20.36.132]) by melmbxw01.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 00:12:26 +1000 Message-ID: <461E3E36.3020601@quest.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message Date: Fri, 13 Apr 2007 00:12:06 +1000 Importance: normal Priority: normal From: "David Leonard" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 14:12:26.0762 (UTC) FILETIME=[994146A0:01C77D0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Hello, Kitten group. I'd like to let you know about an experimental project we have, PGSSAPI, which is a dispatching library (a lot like mechglue) but operates primarily on shared libraries that expose a GSSAPI (really an ABI). The problem this tries to solve is when you have applications pre-linked with existing GSS libraries and you want to make use of other security libraries that aren't mechglue compatible. It's intended for use either by operating system vendors who want their userland tools to be able to be reconfigured with different gss providers, and/or for application writers who want to configure the gss provider through their application's native config. Some of the design goals were to support legacy use of the GSSAPI v1, map between v1 callers and v2 implementations, transparent memory management and spnego. I also added a ioctl-like call intended to be used for developing and experimenting with extensions to the GSSAPI. Some of the problems I envisage are how to handle the bypassing of gss (especially as there is no krb5 C api standard), display_status state between threads. This is a project in early stages, and I would be interested in comments on the idea. More information is at http://rc.vintela.com/topics/pgssapi/ David Leonard _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 12 13:29:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc37A-0006yO-IP; Thu, 12 Apr 2007 13:29:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc379-0006yI-RL for kitten@ietf.org; Thu, 12 Apr 2007 13:29:43 -0400 Received: from www.ioplex.com ([66.220.1.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hc377-0003mA-Ed for kitten@ietf.org; Thu, 12 Apr 2007 13:29:43 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id CDD7E42B64; Thu, 12 Apr 2007 13:29:30 -0400 (EDT) Date: Thu, 12 Apr 2007 13:29:27 -0400 From: Michael B Allen To: "David Leonard" Message-Id: <20070412132927.7fe8a260.mba2000@ioplex.com> In-Reply-To: <461E3E36.3020601@quest.com> References: <461E3E36.3020601@quest.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, 13 Apr 2007 00:12:06 +1000 "David Leonard" wrote: > Hello, Kitten group. > > I'd like to let you know about an experimental project we have, PGSSAPI, > which is a dispatching library (a lot like mechglue) but operates > primarily on shared libraries that expose a GSSAPI (really an ABI). > > The problem this tries to solve is when you have applications pre-linked > with existing GSS libraries and you want to make use of other security > libraries that aren't mechglue compatible. It's intended for use either > by operating system vendors who want their userland tools to be able to > be reconfigured with different gss providers, and/or for application > writers who want to configure the gss provider through their > application's native config. > > Some of the design goals were to support legacy use of the GSSAPI v1, > map between v1 callers and v2 implementations, transparent memory > management and spnego. I also added a ioctl-like call intended to be > used for developing and experimenting with extensions to the GSSAPI. > > Some of the problems I envisage are how to handle the bypassing of gss > (especially as there is no krb5 C api standard), display_status state > between threads. > > This is a project in early stages, and I would be interested in comments > on the idea. More information is at http://rc.vintela.com/topics/pgssapi/ Hi David, Do you have any documentation that describes the technical aspects of your approach (e.g. how symbols are loaded, specific linking requirements, etc). From browsing the code and looking at the page you provided I could not find anything technical. The design.xml file looks interesting but apparently I do not have xml2html. Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 12 14:25:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3zD-0002p4-7P; Thu, 12 Apr 2007 14:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3zC-0002nC-Dk for kitten@ietf.org; Thu, 12 Apr 2007 14:25:34 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc3z9-0001iN-VV for kitten@ietf.org; Thu, 12 Apr 2007 14:25:34 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3CIPTi2013400 for ; Thu, 12 Apr 2007 18:25:29 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3CIPSNa023889 for ; Thu, 12 Apr 2007 12:25:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3CIOYsb004328; Thu, 12 Apr 2007 13:24:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3CIOX94004327; Thu, 12 Apr 2007 13:24:33 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Apr 2007 13:24:33 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20070412182432.GG28748@Sun.COM> Mail-Followup-To: Michael B Allen , David Leonard , kitten@ietf.org References: <461E3E36.3020601@quest.com> <20070412132927.7fe8a260.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412132927.7fe8a260.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: kitten@ietf.org, David Leonard Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 12, 2007 at 01:29:27PM -0400, Michael B Allen wrote: > Do you have any documentation that describes the technical aspects of > your approach (e.g. how symbols are loaded, specific linking requirements, > etc). From browsing the code and looking at the page you provided I could > not find anything technical. The design.xml file looks interesting but > apparently I do not have xml2html. Maybe it's in the xml2rfc DTD? http://xml.resource.org/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 12 18:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7Yc-0007Rr-TG; Thu, 12 Apr 2007 18:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7Yb-0007Rm-PU for kitten@ietf.org; Thu, 12 Apr 2007 18:14:21 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7Ya-0008O2-Bk for kitten@ietf.org; Thu, 12 Apr 2007 18:14:21 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CMEJFA022326 for ; Thu, 12 Apr 2007 22:14:19 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3CMEJ3M010621 for ; Thu, 12 Apr 2007 16:14:19 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3CMDOvq004615; Thu, 12 Apr 2007 17:13:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3CMDNGa004614; Thu, 12 Apr 2007 17:13:23 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Apr 2007 17:13:23 -0500 From: Nicolas Williams To: David Leonard Message-ID: <20070412221322.GG4375@Sun.COM> Mail-Followup-To: David Leonard , kitten@ietf.org References: <461E3E36.3020601@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461E3E36.3020601@quest.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org I recall someone from vintela wishing that the GSS functions took an additional argument corresponding to, effectively, what krb5_context is in the MIT and Heimdal krb5 APIs: an object representing application- specific settings that don't relate directly to other GSS objects. And we've all lamented C bindings issues like gss_buffer_desc (which, by having its layout and size being part of the API, and thus the ABI, makes it hard to track what allocator allocated what buffers). Is that what PGSSAPI is about? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 12 21:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcAi3-0003rZ-Si; Thu, 12 Apr 2007 21:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcAi2-0003rS-DY for kitten@ietf.org; Thu, 12 Apr 2007 21:36:18 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcAi1-0001PT-0o for kitten@ietf.org; Thu, 12 Apr 2007 21:36:18 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 99E2442B8B; Thu, 12 Apr 2007 21:35:59 -0400 (EDT) Date: Thu, 12 Apr 2007 21:35:54 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20070412213554.5b3c6a26.mba2000@ioplex.com> In-Reply-To: <20070412221322.GG4375@Sun.COM> References: <461E3E36.3020601@quest.com> <20070412221322.GG4375@Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org, David.Leonard@quest.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, 12 Apr 2007 17:13:23 -0500 Nicolas Williams wrote: > I recall someone from vintela wishing that the GSS functions took an > additional argument corresponding to, effectively, what krb5_context is > in the MIT and Heimdal krb5 APIs: an object representing application- > specific settings that don't relate directly to other GSS objects. > > And we've all lamented C bindings issues like gss_buffer_desc (which, by > having its layout and size being part of the API, and thus the ABI, > makes it hard to track what allocator allocated what buffers). An application context (as opposed to the existing authentication context) would help in a number of ways. Making an implementation thread safe would be more elegant because the lock could be associated with the application context instead of being a global. Higher level code could be more efficient because the application context could be embedded in the higher level code's context. As you mention, allocation could be abstracted. My personal belief is that every major inteface should have an application context. Think about the possibilites for a stdlib malloc interface that accepted an application context. The fact that it doesn't have one is a design flaw IMO. Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 13 13:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPdX-0004Tb-A0; Fri, 13 Apr 2007 13:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPdW-0004RQ-BP for kitten@ietf.org; Fri, 13 Apr 2007 13:32:38 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPdU-0006wk-Su for kitten@ietf.org; Fri, 13 Apr 2007 13:32:38 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3DHWa64001284 for ; Fri, 13 Apr 2007 17:32:36 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3DHWZWK002983 for ; Fri, 13 Apr 2007 11:32:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3DHVe1g005384; Fri, 13 Apr 2007 12:31:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3DHVdfP005383; Fri, 13 Apr 2007 12:31:39 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 13 Apr 2007 12:31:39 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20070413173139.GB4375@Sun.COM> Mail-Followup-To: Michael B Allen , David.Leonard@quest.com, kitten@ietf.org References: <461E3E36.3020601@quest.com> <20070412221322.GG4375@Sun.COM> <20070412213554.5b3c6a26.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412213554.5b3c6a26.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org, David.Leonard@quest.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 12, 2007 at 09:35:54PM -0400, Michael B Allen wrote: > On Thu, 12 Apr 2007 17:13:23 -0500 > Nicolas Williams wrote: > > > I recall someone from vintela wishing that the GSS functions took an > > additional argument corresponding to, effectively, what krb5_context is > > in the MIT and Heimdal krb5 APIs: an object representing application- > > specific settings that don't relate directly to other GSS objects. > > > > And we've all lamented C bindings issues like gss_buffer_desc (which, by > > having its layout and size being part of the API, and thus the ABI, > > makes it hard to track what allocator allocated what buffers). > > An application context (as opposed to the existing authentication context) > would help in a number of ways. Making an implementation thread safe > would be more elegant because the lock could be associated with the > application context instead of being a global. Higher level code could > be more efficient because the application context could be embedded > in the higher level code's context. As you mention, allocation could > be abstracted. I'm not sure that an app context here is needed to simplify thread safety because in general the GSS-API already has the right kind of objects for fine-grained locking (i.e., you can associate locks with NAME, CREDENTIAL HANDLE and SECURITY CONTEXT objects). Never mind the global locking that you see in our mech_krb5 implementation -- that's not a result of the GSS-API's design. > My personal belief is that every major inteface should have an application > context. Think about the possibilites for a stdlib malloc interface that > accepted an application context. The fact that it doesn't have one is > a design flaw IMO. I agree that complex interfaces should have app contexts. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 13 13:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPhR-0000Eg-6X; Fri, 13 Apr 2007 13:36:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPhP-0000A7-EL for kitten@ietf.org; Fri, 13 Apr 2007 13:36:39 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPhO-0001OM-4o for kitten@ietf.org; Fri, 13 Apr 2007 13:36:39 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3DHabNO002785 for ; Fri, 13 Apr 2007 17:36:37 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3DHabnb004700 for ; Fri, 13 Apr 2007 11:36:37 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3DHZgDd005391; Fri, 13 Apr 2007 12:35:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3DHZglQ005390; Fri, 13 Apr 2007 12:35:42 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 13 Apr 2007 12:35:42 -0500 From: Nicolas Williams To: David Leonard Message-ID: <20070413173541.GC4375@Sun.COM> Mail-Followup-To: David Leonard , kitten@ietf.org References: <461E3E36.3020601@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461E3E36.3020601@quest.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org OK, so I looked at the design.xml document. I see that you have an ioctl-like interface for specifying certain application preferences (like which provider to use for a given mechanism, where there are multiple options). This is good, but I'm afraid that it's not good enough. Consider a situation where an application uses the GSS-API and some library in the same application independently uses the GSS-API. Without an "application context"-like object as an argument to the GSS functions the only way to resolve conflicts between these two consumers is to walk the call stack to find out which consumer is making the calls. This gets worse if the application and the library might share some GSS objects. IMO your approach is fine for many situations, but not general enough. I wonder if for the GSS-APIv3 we should not just bite the bullet and add arguments to existing GSSv2 functions, and rename them to gss3_*. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 13 14:50:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQqK-0001yL-Tg; Fri, 13 Apr 2007 14:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQqJ-0001yD-G5 for kitten@ietf.org; Fri, 13 Apr 2007 14:49:55 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQqH-0007Sh-Nw for kitten@ietf.org; Fri, 13 Apr 2007 14:49:55 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 8DA1F42B90; Fri, 13 Apr 2007 14:49:39 -0400 (EDT) Date: Fri, 13 Apr 2007 14:49:33 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20070413144933.2b2dd6ad.mba2000@ioplex.com> In-Reply-To: <20070413173139.GB4375@Sun.COM> References: <461E3E36.3020601@quest.com> <20070412221322.GG4375@Sun.COM> <20070412213554.5b3c6a26.mba2000@ioplex.com> <20070413173139.GB4375@Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: kitten@ietf.org, David.Leonard@quest.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, 13 Apr 2007 12:31:39 -0500 Nicolas Williams wrote: > On Thu, Apr 12, 2007 at 09:35:54PM -0400, Michael B Allen wrote: > > On Thu, 12 Apr 2007 17:13:23 -0500 > > Nicolas Williams wrote: > > > > > I recall someone from vintela wishing that the GSS functions took an > > > additional argument corresponding to, effectively, what krb5_context is > > > in the MIT and Heimdal krb5 APIs: an object representing application- > > > specific settings that don't relate directly to other GSS objects. > > > > > > And we've all lamented C bindings issues like gss_buffer_desc (which, by > > > having its layout and size being part of the API, and thus the ABI, > > > makes it hard to track what allocator allocated what buffers). > > > > An application context (as opposed to the existing authentication context) > > would help in a number of ways. Making an implementation thread safe > > would be more elegant because the lock could be associated with the > > application context instead of being a global. Higher level code could > > be more efficient because the application context could be embedded > > in the higher level code's context. As you mention, allocation could > > be abstracted. > > I'm not sure that an app context here is needed to simplify thread > safety because in general the GSS-API already has the right kind of > objects for fine-grained locking (i.e., you can associate locks with > NAME, CREDENTIAL HANDLE and SECURITY CONTEXT objects). Never mind the > global locking that you see in our mech_krb5 implementation -- that's > not a result of the GSS-API's design. I'd be willing to wager that having one lock on the app context for protecting everything would not only be simpler but more efficient because there are fewer locks and fewer locking calls which improves cache locality and reduces syscalls. Of course you must make sure that you unlock while blocking (e.g. to perform I/O with the filesystem or network) [1]. Also, I think the global locking in mech_krb5 *is* the result of GSS-API's design because mechglue's API is directly derived from GSS-API's. If GSS-API had an app context, mechglue would have one and the lock would not need to be global. Or did I not understand what you mean? Mike [1] I am not certain that this technique is more efficient on systems with many CPUs and high numbers of GSS-API calls. -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 13 15:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcR7Y-00061B-D6; Fri, 13 Apr 2007 15:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcR7X-000615-4y for kitten@ietf.org; Fri, 13 Apr 2007 15:07:43 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcR7V-0004IB-MF for kitten@ietf.org; Fri, 13 Apr 2007 15:07:43 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3DJ7f6V002446 for ; Fri, 13 Apr 2007 19:07:41 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3DJ7eER018803 for ; Fri, 13 Apr 2007 13:07:41 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3DJ6kQV005418; Fri, 13 Apr 2007 14:06:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3DJ6kXV005417; Fri, 13 Apr 2007 14:06:46 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 13 Apr 2007 14:06:45 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20070413190645.GD4375@Sun.COM> Mail-Followup-To: Michael B Allen , David.Leonard@quest.com, kitten@ietf.org References: <461E3E36.3020601@quest.com> <20070412221322.GG4375@Sun.COM> <20070412213554.5b3c6a26.mba2000@ioplex.com> <20070413173139.GB4375@Sun.COM> <20070413144933.2b2dd6ad.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070413144933.2b2dd6ad.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: kitten@ietf.org, David.Leonard@quest.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Apr 13, 2007 at 02:49:33PM -0400, Michael B Allen wrote: > I'd be willing to wager that having one lock on the app context for > protecting everything would not only be simpler but more efficient > because there are fewer locks and fewer locking calls which improves > cache locality and reduces syscalls. Of course you must make sure that you > unlock while blocking (e.g. to perform I/O with the filesystem or network) > [1]. It's a trade-off in granularity. A big lock per-app context pushes responsibility for synchronization to the application (this is the model in the MIT krb5 API since thread-safety was added). A per-object lock pushes responsibility for synchronization into the framework and the providers, which makes it easier for the application developer. Finer grained locking gives the developer more freedom. This has real world impact in protocols like NFSv4. A busy multi- threaded client that does not support fine-grained locking will either serialize GSS per-message function calls and leave performance on the table, or it will setup multiple GSS-API security contexts, one per- thread, consuming more memory and reducing performance on the server (by cooling L2 caches). > Also, I think the global locking in mech_krb5 *is* the result of GSS-API's > design because mechglue's API is directly derived from GSS-API's. If > GSS-API had an app context, mechglue would have one and the lock would > not need to be global. Or did I not understand what you mean? Absolutely not. The global locking in mech_krb5 is the result of something else entirely: the MIT source from which it was derived was not thread-safe at the time (late 90s), so the simplest way to make it thread-safe (but not thread-hot) was to throw in a big lock. > [1] I am not certain that this technique is more efficient on systems > with many CPUs and high numbers of GSS-API calls. It really depends on the protocol. In the case of NFSv4 what you propose is less than optimal. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 13 16:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcS2C-0000PX-Mi; Fri, 13 Apr 2007 16:06:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcS2C-0000PL-Ae for kitten@ietf.org; Fri, 13 Apr 2007 16:06:16 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcS29-00032v-B5 for kitten@ietf.org; Fri, 13 Apr 2007 16:06:15 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 29D0342B71; Fri, 13 Apr 2007 16:06:08 -0400 (EDT) Date: Fri, 13 Apr 2007 16:06:05 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20070413160605.1c4ad4ff.mba2000@ioplex.com> In-Reply-To: <20070413190645.GD4375@Sun.COM> References: <461E3E36.3020601@quest.com> <20070412221322.GG4375@Sun.COM> <20070412213554.5b3c6a26.mba2000@ioplex.com> <20070413173139.GB4375@Sun.COM> <20070413144933.2b2dd6ad.mba2000@ioplex.com> <20070413190645.GD4375@Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@ietf.org, David.Leonard@quest.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, 13 Apr 2007 14:06:45 -0500 Nicolas Williams wrote: > On Fri, Apr 13, 2007 at 02:49:33PM -0400, Michael B Allen wrote: > > I'd be willing to wager that having one lock on the app context for > > protecting everything would not only be simpler but more efficient > > because there are fewer locks and fewer locking calls which improves > > cache locality and reduces syscalls. Of course you must make sure that you > > unlock while blocking (e.g. to perform I/O with the filesystem or network) > > [1]. > > It's a trade-off in granularity. A big lock per-app context pushes > responsibility for synchronization to the application (this is the model > in the MIT krb5 API since thread-safety was added). A per-object lock > pushes responsibility for synchronization into the framework and the > providers, which makes it easier for the application developer. Finer > grained locking gives the developer more freedom. > > This has real world impact in protocols like NFSv4. A busy multi- > threaded client that does not support fine-grained locking will either > serialize GSS per-message function calls and leave performance on the > table, or it will setup multiple GSS-API security contexts, one per- > thread, consuming more memory and reducing performance on the server (by > cooling L2 caches). You don't have to serialize GSS calls. Just unlock "The Big Lock" while you call anything that can block (e.g. krb5_cc_* functions). I don't see why you can't reach full CPU utilization if you never hold the lock while blocking. But I think we're probably OT now so I'll give it a rest. > > Also, I think the global locking in mech_krb5 *is* the result of GSS-API's > > design because mechglue's API is directly derived from GSS-API's. If > > GSS-API had an app context, mechglue would have one and the lock would > > not need to be global. Or did I not understand what you mean? > > Absolutely not. > > The global locking in mech_krb5 is the result of something else > entirely: the MIT source from which it was derived was not thread-safe > at the time (late 90s), so the simplest way to make it thread-safe (but > not thread-hot) was to throw in a big lock. Ok. Well I'm not terribly familiar with the MIT implementation. We use Heimdal and it (at least 0.7) uses a number of globals for GSS-API objects (although I guess I can't say the Heimdal authors wouldn't continue to use globals if there were an app context). Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 13 16:11:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcS70-0001mr-7P; Fri, 13 Apr 2007 16:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcS6y-0001lj-OR for kitten@ietf.org; Fri, 13 Apr 2007 16:11:12 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcS6t-00069J-8J for kitten@ietf.org; Fri, 13 Apr 2007 16:11:12 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3DKB6LC008543 for ; Fri, 13 Apr 2007 20:11:06 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3DKB6Jc015454 for ; Fri, 13 Apr 2007 14:11:06 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3DKA9qX005452; Fri, 13 Apr 2007 15:10:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3DKA9Oq005451; Fri, 13 Apr 2007 15:10:09 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 13 Apr 2007 15:10:09 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20070413201008.GE4375@Sun.COM> Mail-Followup-To: Michael B Allen , David.Leonard@quest.com, kitten@ietf.org References: <461E3E36.3020601@quest.com> <20070412221322.GG4375@Sun.COM> <20070412213554.5b3c6a26.mba2000@ioplex.com> <20070413173139.GB4375@Sun.COM> <20070413144933.2b2dd6ad.mba2000@ioplex.com> <20070413190645.GD4375@Sun.COM> <20070413160605.1c4ad4ff.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070413160605.1c4ad4ff.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: kitten@ietf.org, David.Leonard@quest.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Apr 13, 2007 at 04:06:05PM -0400, Michael B Allen wrote: > > This has real world impact in protocols like NFSv4. A busy multi- > > threaded client that does not support fine-grained locking will either > > serialize GSS per-message function calls and leave performance on the > > table, or it will setup multiple GSS-API security contexts, one per- > > thread, consuming more memory and reducing performance on the server (by > > cooling L2 caches). > > You don't have to serialize GSS calls. Just unlock "The Big Lock" while > you call anything that can block (e.g. krb5_cc_* functions). I don't > see why you can't reach full CPU utilization if you never hold the lock > while blocking. Big lock -> serialize. That's why we want to avoid big locks in general. > But I think we're probably OT now so I'll give it a rest. Yes, we are way OT. > > > Also, I think the global locking in mech_krb5 *is* the result of GSS-API's > > > design because mechglue's API is directly derived from GSS-API's. If > > > GSS-API had an app context, mechglue would have one and the lock would > > > not need to be global. Or did I not understand what you mean? > > > > Absolutely not. > > > > The global locking in mech_krb5 is the result of something else > > entirely: the MIT source from which it was derived was not thread-safe > > at the time (late 90s), so the simplest way to make it thread-safe (but > > not thread-hot) was to throw in a big lock. > > Ok. Well I'm not terribly familiar with the MIT implementation. We use > Heimdal and it (at least 0.7) uses a number of globals for GSS-API objects > (although I guess I can't say the Heimdal authors wouldn't continue to > use globals if there were an app context). No, you can, but there is a good point here: thread-safety for the GSS-APIv2uX couldn't rely on an app context, so implementors would either have to use big locks or per-object locks. But if we were to pursue a GSS-APIv3 which has room for an app context argument then we'd have to pick a model for thread-safety. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 16 22:26:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HddOg-0003vY-2a; Mon, 16 Apr 2007 22:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvNL-0003rt-BQ for kitten@lists.ietf.org; Thu, 29 Mar 2007 10:13:15 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvNH-0002fF-V4 for kitten@lists.ietf.org; Thu, 29 Mar 2007 10:13:15 -0400 Received: from [192.168.1.103] ((unknown) [24.176.246.106]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 29 Mar 2007 15:13:10 +0100 X-SMTP-Protocol-Errors: NORDNS In-Reply-To: <87tzw4p5g1.fsf@mocca.josefsson.org> References: <87tzw4p5g1.fsf@mocca.josefsson.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1CB4ECB2-D903-4D75-97B1-B7ED11999691@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Thu, 29 Mar 2007 07:13:03 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 16 Apr 2007 22:26:20 -0400 Cc: password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mar 29, 2007, at 6:03 AM, Simon Josefsson wrote: > I'm cc:ing this to the password-auth mailing list that I created for > discussion of the document. Some discussions of the document may be > off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to > see it discussed elsewhere (let me know!), so consider dropping the > IETF lists when starting such a thread. Given the SASL charter allows for the WG to review, as time permits, independently developed SASL mechanism specifications, and the SASL WG is currently discussing revision of our charter to include additional work item(s) in this area, I would prefer discussions related to password-based SASL mechanisms stay on the SASL WG list (at least for now). -- Kurt, SASL WG co-chair _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 16 22:26:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HddOg-0003vd-5V; Mon, 16 Apr 2007 22:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HddIZ-0007lE-0B for kitten@ietf.org; Mon, 16 Apr 2007 22:20:03 -0400 Received: from [69.25.196.182] (helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HddIW-0007aK-P7 for kitten@ietf.org; Mon, 16 Apr 2007 22:20:02 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 205C5499D; Mon, 16 Apr 2007 22:20:00 -0400 (EDT) To: kitten@ietf.org From: Sam Hartman Message-Id: <20070417022000.205C5499D@carter-zimmerman.suchdamage.org> Date: Mon, 16 Apr 2007 22:20:00 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Mon, 16 Apr 2007 22:26:20 -0400 Cc: Subject: Seeking kitten chairs--reply by April 30 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Hi. It is with great sadness that I announce that Jeff Altman has stepped down as kitten chair to pursue his business and because he is no longer attending IETF. While Jeff does not expect to travel to future meetings he does expect to continue to be involved in this working group. I know that I look forward to his future contributions from Jeff. Also I'd like to thank Jeff for doing such a great job of getting us this far. Kitten started with a very aggressive charter. We've not done such a great job of tackling the charter items in the order we expected, but we have done a good job of turning out a steady stream of high-quality documents. I do have a couple of folks who have volunteered to be chairs. One is relatively new, one is relatively experienced but is unavailable until the end of June. So, I would appreciate interest from anyone who would be interested in chairing (or co-chairing) the working group or who would be interested in mentoring a new chair until the end of June. Thanks, --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Apr 17 01:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdgfA-0006E2-4D; Tue, 17 Apr 2007 01:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdgf9-0006Dx-0S for kitten@ietf.org; Tue, 17 Apr 2007 01:55:35 -0400 Received: from irvbhxw02.quest.com ([12.106.87.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdgf7-00027u-JJ for kitten@ietf.org; Tue, 17 Apr 2007 01:55:34 -0400 thread-index: AceAtQLVbhXJlcm/S7eUpIWTPelzJg== Received: from melmbxw01.prod.quest.corp ([10.20.4.118]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 22:55:32 -0700 Received: from [10.20.36.144] ([10.20.36.144]) by melmbxw01.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 15:55:30 +1000 Message-ID: <46246182.9040307@quest.com> Date: Tue, 17 Apr 2007 15:56:18 +1000 From: "David Leonard" User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Class: urn:content-classes:message Importance: normal To: Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 References: <461E3E36.3020601@quest.com> In-Reply-To: <461E3E36.3020601@quest.com> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 17 Apr 2007 05:55:30.0204 (UTC) FILETIME=[014455C0:01C780B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Sorry for the delay. I'll reply to a couple of question below: Michael B Allen wrote: >Do you have any documentation that describes the technical aspects of >your approach (e.g. how symbols are loaded, specific linking = requirements, >etc). From browsing the code and looking at the page you provided I = could >not find anything technical. The design.xml file looks interesting but >apparently I do not have xml2html. I have put up a text version of design.xml at=20 http://rc.vintela.com/pub/rc/pgssapi/ The specific symbols loaded are not documented (but see pgss-dlprov.c=20 for the current list). The intent is to match what standard C=20 development tools would do on each platform assuming a direct=20 implementation of the GSSAPI and shared libraries. So far, dlsym() or an = equivalent finds function pointers in shared libraries or equivalent,=20 and PGSS casts them into function pointer types derived from the RFC(s). = If the library relies on the caller using a special header file, then it = probably won't work; so PGSS may have to be taught how to handle some = cases. Nicolas Williams wrote: >I recall someone from vintela wishing that the GSS functions took an >additional argument corresponding to, effectively, what krb5_context is >in the MIT and Heimdal krb5 APIs: an object representing application- >specific settings that don't relate directly to other GSS objects. > =20 Yes, he also started this PGSSAPI project :) >And we've all lamented C bindings issues like gss_buffer_desc (which, = by >having its layout and size being part of the API, and thus the ABI, >makes it hard to track what allocator allocated what buffers). > =20 Just as painful is the hidden last-error context maintained for=20 gss_display_status(). >Is that what PGSSAPI is about? No.. PGSSAPI is mostly about allowing you to decouple your apps from=20 particular GSS implementation libraries. It has a secondary goal of multiplexing those security libraries, and it = is there that an application context would make this a lot easier to = manage. >OK, so I looked at the design.xml document. I see that you have an >ioctl-like interface for specifying certain application preferences >(like which provider to use for a given mechanism, where there are >multiple options). > >This is good, but I'm afraid that it's not good enough. > >Consider a situation where an application uses the GSS-API and some >library in the same application independently uses the GSS-API. = Without >an "application context"-like object as an argument to the GSS = functions >the only way to resolve conflicts between these two consumers is to = walk >the call stack to find out which consumer is making the calls. > >This gets worse if the application and the library might share some GSS >objects. > >IMO your approach is fine for many situations, but not general enough. > =20 You're absolutely right: like the rest of the GSSAPI, a single=20 application is assumed. This matches the goal of this library is to fit=20 existing GSS applications. Even if it was changed to provide an application context, it couldn't be = passed to nor made use of by gss_accept_sec_context(), for example. pgss_ctl() talks to mechanisms, and mechanisms are currently ignorant of = app contexts. Aside from that, this kind of trapdoor for talking to mechanism=20 implementation is missing from the GSSAPI. Instead what happens now is=20 we use functions like gss_krb5_get_ccache(). If we're talking about=20 future GSSv3 design, then I'd like to see this idea some way of sending=20 messages from the application to the mechanism while not exceeding the=20 API would be useful. It doesn't have to be ioctl-like. >I wonder if for the GSS-APIv3 we should not just bite the bullet and = add >arguments to existing GSSv2 functions, and rename them to gss3_*. I'd like to see a more object-oriented approach applied to any gssapiv3. = By this, I mean ensure every function is thought of in terms of an=20 operation on a context. Not only would this lead to consistency between the OO language mappings = (eg java, python) but then w wouldn't have the GSS_display_status()=20 madness. Maybe security contexts could be created in an initial invalid=20 state, rather than having invalidity managed as both null pointers and=20 half-formed contexts. And throw out minor_status while you're there :) Figuring out the mapping between a gssapiv3 application and a gssapiv2=20 implementation (and vice versa) will be interesting, and could be part=20 of pgss. --=20 David Leonard Resource Central software engineer Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Apr 17 10:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdouh-0004y5-Qw; Tue, 17 Apr 2007 10:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdoug-0004xB-Af for kitten@ietf.org; Tue, 17 Apr 2007 10:44:10 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdotT-0001J1-L9 for kitten@ietf.org; Tue, 17 Apr 2007 10:42:58 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3HEgqvi009463 for ; Tue, 17 Apr 2007 14:42:53 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3HEgqbS024220 for ; Tue, 17 Apr 2007 08:42:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3HEftXP008743; Tue, 17 Apr 2007 09:41:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3HEft3w008742; Tue, 17 Apr 2007 09:41:55 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 17 Apr 2007 09:41:55 -0500 From: Nicolas Williams To: David Leonard Message-ID: <20070417144154.GQ4375@Sun.COM> Mail-Followup-To: David Leonard , kitten@ietf.org References: <461E3E36.3020601@quest.com> <46246182.9040307@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46246182.9040307@quest.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Apr 17, 2007 at 03:56:18PM +1000, David Leonard wrote: > >I wonder if for the GSS-APIv3 we should not just bite the bullet and add > >arguments to existing GSSv2 functions, and rename them to gss3_*. > I'd like to see a more object-oriented approach applied to any gssapiv3. > By this, I mean ensure every function is thought of in terms of an > operation on a context. Actually, the abstract GSS-API is object-oriented enough as it is -- see the Java bindings. Adding an application context is not OO. > Not only would this lead to consistency between the OO language mappings > (eg java, python) but then w wouldn't have the GSS_display_status() The GSS_Display_status() problem is not about application contexts, though those would solv eit. The problem with GSS_Display_status() is that minor_status in all the function calls is a small integer output parameter (OM_uint32 * in the C bindings) whereas it should instead be an opaque object output parameter. > madness. Maybe security contexts could be created in an initial invalid > state, rather than having invalidity managed as both null pointers and > half-formed contexts. And throw out minor_status while you're there :) That's been one thought (and it would allow for setting flags on the acceptor side while still re-using GSS_Accept_sec_context() as it is). But it's not comprehensive. > Figuring out the mapping between a gssapiv3 application and a gssapiv2 > implementation (and vice versa) will be interesting, and could be part > of pgss. I think such a mapping should be quite feasible -- that is, a GSSv3 mechglue should be able to use mechanisms implemented with a GSSv2 interface without much trouble. Is this worth doing? Or is it better to patch up the GSSv2 APIs and muddle throguh? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 18 16:46:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH3E-0004ta-1M; Wed, 18 Apr 2007 16:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH3C-0004t3-2l; Wed, 18 Apr 2007 16:46:50 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeH3B-0003nK-M6; Wed, 18 Apr 2007 16:46:50 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA28427; Wed, 18 Apr 2007 22:46:40 +0200 (MESZ) From: Martin Rex Message-Id: <200704182046.l3IKkfsK024424@fs4113.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Wed, 18 Apr 2007 22:46:41 +0200 (MEST) In-Reply-To: from "Liqiang" at Apr 6, 7 00:28:27 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: spkm@ietf.org, kitten@lists.ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Liqiang wrote: > > Olga Kornievskaia wrote: > > First, I hope that the 1st sentence refers to "tokens" not just the > > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed > > but the AS_REP token is not which doesn't make sense. > > Your understanding is correct. Only the first message has the framing. > This is consistent with RFC4121 and RFC4178. NOPE, it is significantly different from rfc1964 and rfc4121. rfc4121 only dropped the framing on the per-message tokens, it still uses the same=full framing as rfc1964 for all of the context level tokens: quoting rfc4121: [RFC1964] describes the GSS-API mechanism for Kerberos Version 5. It defines the format of context establishment, per-message and context deletion tokens, and uses algorithm identifiers for each cryptosystem in per-message and context deletion tokens. The approach taken in this document obviates the need for algorithm identifiers. This is accomplished by using the same encryption algorithm, specified by the crypto profile [RFC3961] for the session key or subkey that is created during context negotiation, and its * required checksum algorithm. Message layouts of the per-message * tokens are therefore revised to remove algorithm indicators and to add extra information to support the generic crypto framework [RFC3961]. I don't like the idea of dropping the generic framing on any of the context level tokens. > > > Second, what does the "subsequent context establishment tokens" refer > > to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? > > Furthermore, there shouldn't be any unframed tokens in GSS-API > > mechanism. > > Only the first message has the token framing. This is how all other > GSS-API mechanisms work today. The GSS-API spec only requires the generic token framing on the initial context token. There is no requirement for any other (context level and message protection tokens). rfc4121 is actually the only mechanism that I know which does not use the token, and it only does so for the message protection tokens. rfc-1964 (Kerberos 5 gssapi mechanism) has been using the generic framing on all tokens, as well as rfc-2025 (Simple Public Key GSS-API mechanisms). Quoting rfc-2025 (SPKM): The above GSS-API framing shall be applied to all tokens emitted by the SPKM GSS-API mechanism, including SPKM-REP-TI (the response from the Target to the Initiator), SPKM-REP-IT (the response from the Initiator to the Target), SPKM-ERROR, context-deletion, and per- message tokens, not just to the initial token in a context establishment exchange. While not required by RFC-1508, this enables implementations to perform enhanced error-checking. and using this framing throughout is an extremely reasonable approach (you may remember that I opposed that change in rfc4121... :) section 6.1 of rfc2025: 6.1. SPKM_Parse_token call [...] If all tokens are framed as suggested in RFC-1508, Appendix B (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this document), then any mechanism implementation should be able to return at least the mech_type parameter (the other parameters being NULL) for any uncorrupted input token. If the mechanism implementation whose SPKM_Parse_token() function is being called does recognize the token, it can return token_type so that the application can subsequently call the correct GSS function. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 18 16:55:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHB5-0007jd-QF; Wed, 18 Apr 2007 16:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHB4-0007j0-TC for kitten@lists.ietf.org; Wed, 18 Apr 2007 16:54:58 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHB3-0006IR-Bp for kitten@lists.ietf.org; Wed, 18 Apr 2007 16:54:58 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3IKsuv5001558 for ; Wed, 18 Apr 2007 20:54:56 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3IKsuCL013616 for ; Wed, 18 Apr 2007 14:54:56 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3IKrvU6010459; Wed, 18 Apr 2007 15:53:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3IKrtsI010458; Wed, 18 Apr 2007 15:53:55 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 18 Apr 2007 15:53:55 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070418205355.GS4375@Sun.COM> Mail-Followup-To: Martin Rex , Liqiang , aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org References: <200704182046.l3IKkfsK024424@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704182046.l3IKkfsK024424@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Liqiang , spkm@ietf.org, kitten@lists.ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 18, 2007 at 10:46:41PM +0200, Martin Rex wrote: > Liqiang wrote: > > > > Olga Kornievskaia wrote: > > > First, I hope that the 1st sentence refers to "tokens" not just the > > > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed > > > but the AS_REP token is not which doesn't make sense. > > > > Your understanding is correct. Only the first message has the framing. > > This is consistent with RFC4121 and RFC4178. > > NOPE, it is significantly different from rfc1964 and rfc4121. Regardless, RFC2743 only requires it on the initial context token. We should probably consider whether we want to RECOMMEND, or even REQUIRE that that header be added to all security context establishment tokens, not just the initial one. But until somebody tables that matter we should not consider RFC1964/4121 as imposing such a requirement on other mechanism that use different mechanism OIDs. That said, there's this interesting question: PKU2U re-uses RFC4121 for everything following PKU2U's first two security context tokens (which are KDC messages between the initiator and the acceptor acting as a pseudo-KDC), so, should those context tokens lifted from RFC4121 bear this header? I could go either way. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 18 17:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHK2-0005BD-Vp; Wed, 18 Apr 2007 17:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHK2-0005Ah-Km; Wed, 18 Apr 2007 17:04:14 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHJx-0001ir-5V; Wed, 18 Apr 2007 17:04:14 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA19449; Wed, 18 Apr 2007 23:03:56 +0200 (MESZ) From: Martin Rex Message-Id: <200704182103.l3IL3tQb025387@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 18 Apr 2007 23:03:55 +0200 (MEST) In-Reply-To: <20070418205355.GS4375@Sun.COM> from "Nicolas Williams" at Apr 18, 7 03:53:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: kitten@lists.ietf.org, lzhu@windows.microsoft.com, Martin.Rex@sap.com, spkm@ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Wed, Apr 18, 2007 at 10:46:41PM +0200, Martin Rex wrote: > > Liqiang wrote: > > > > > > Olga Kornievskaia wrote: > > > > First, I hope that the 1st sentence refers to "tokens" not just the > > > > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed > > > > but the AS_REP token is not which doesn't make sense. > > > > > > Your understanding is correct. Only the first message has the framing. > > > This is consistent with RFC4121 and RFC4178. > > > > NOPE, it is significantly different from rfc1964 and rfc4121. > > Regardless, RFC2743 only requires it on the initial context token. I know. I did confirm this a few lines later. > > We should probably consider whether we want to RECOMMEND, or even > REQUIRE that that header be added to all security context establishment > tokens, not just the initial one. > > But until somebody tables that matter we should not consider > RFC1964/4121 as imposing such a requirement on other mechanism that use > different mechanism OIDs. Require, because it will amount to less code, less complexity and less confusion. The overhead is negligable. I don't expect any implementation of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite the seperate mechanism OID. > > That said, there's this interesting question: PKU2U re-uses RFC4121 for > everything following PKU2U's first two security context tokens (which > are KDC messages between the initiator and the acceptor acting as a > pseudo-KDC), so, should those context tokens lifted from RFC4121 bear > this header? I really want to see the generic framing on all context level tokens (which is what you meant by header, I assume). Could it be that you actually didn't want to ask about the framing, but about the mechanism OID within the header (if it is present)? I'd like to see the generic framing, and I'd like to see it with the same mechanism OID as in the initial context token (which is different from rfc1964/rfc2141). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 18 17:11:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHQw-0003wV-Qb; Wed, 18 Apr 2007 17:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHQv-0003wH-VF for kitten@lists.ietf.org; Wed, 18 Apr 2007 17:11:22 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHQo-0004Od-Mg for kitten@lists.ietf.org; Wed, 18 Apr 2007 17:11:21 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3ILBEaT000270 for ; Wed, 18 Apr 2007 21:11:14 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3ILBDUn011336 for ; Wed, 18 Apr 2007 15:11:13 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3ILAEPn010539; Wed, 18 Apr 2007 16:10:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3ILAEdM010538; Wed, 18 Apr 2007 16:10:14 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 18 Apr 2007 16:10:14 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070418211013.GT4375@Sun.COM> Mail-Followup-To: Martin Rex , lzhu@windows.microsoft.com, aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org References: <20070418205355.GS4375@Sun.COM> <200704182103.l3IL3tQb025387@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704182103.l3IL3tQb025387@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: lzhu@windows.microsoft.com, spkm@ietf.org, kitten@lists.ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 18, 2007 at 11:03:55PM +0200, Martin Rex wrote: > > We should probably consider whether we want to RECOMMEND, or even > > REQUIRE that that header be added to all security context establishment > > tokens, not just the initial one. > > > > But until somebody tables that matter we should not consider > > RFC1964/4121 as imposing such a requirement on other mechanism that use > > different mechanism OIDs. > > Require, because it will amount to less code, less complexity and less > confusion. The overhead is negligable. I don't expect any implementation > of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite > the seperate mechanism OID. I can't tell if RFC2478/4178 require that header on non-initial SPNEGO context tokens, but our implementation does NOT put it on any SPNEGO context token other than the initial one. Did we miss this? This requirement, if we wanted to make it, would have to apply only to future Standards-Track mechs. > > That said, there's this interesting question: PKU2U re-uses RFC4121 for > > everything following PKU2U's first two security context tokens (which > > are KDC messages between the initiator and the acceptor acting as a > > pseudo-KDC), so, should those context tokens lifted from RFC4121 bear > > this header? > > I really want to see the generic framing on all context level tokens > (which is what you meant by header, I assume). Yes, that's what I meant by 'header'. > Could it be that you actually didn't want to ask about the framing, > but about the mechanism OID within the header (if it is present)? No. > I'd like to see the generic framing, and I'd like to see it with > the same mechanism OID as in the initial context token (which is > different from rfc1964/rfc2141). Yes, if the generic header is on all context tokens then the same OID has to be used for all those context tokens for any given security context. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 19 10:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXR9-0003CA-7D; Thu, 19 Apr 2007 10:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXR7-0003Bu-Vo; Thu, 19 Apr 2007 10:16:37 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXR7-0007xQ-Hy; Thu, 19 Apr 2007 10:16:37 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id QAA11705; Thu, 19 Apr 2007 16:16:21 +0200 (MESZ) From: Martin Rex Message-Id: <200704191416.l3JEGHn3002032@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Apr 2007 16:16:16 +0200 (MEST) In-Reply-To: <20070418211013.GT4375@Sun.COM> from "Nicolas Williams" at Apr 18, 7 04:10:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: kitten@lists.ietf.org, lzhu@windows.microsoft.com, Martin.Rex@sap.com, spkm@ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Wed, Apr 18, 2007 at 11:03:55PM +0200, Martin Rex wrote: > > > We should probably consider whether we want to RECOMMEND, or even > > > REQUIRE that that header be added to all security context establishment > > > tokens, not just the initial one. > > > > > > But until somebody tables that matter we should not consider > > > RFC1964/4121 as imposing such a requirement on other mechanism that use > > > different mechanism OIDs. > > > > Require, because it will amount to less code, less complexity and less > > confusion. The overhead is negligable. I don't expect any implementation > > of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite > > the seperate mechanism OID. > > I can't tell if RFC2478/4178 require that header on non-initial SPNEGO > context tokens, but our implementation does NOT put it on any SPNEGO > context token other than the initial one. Did we miss this? > > This requirement, if we wanted to make it, would have to apply only to > future Standards-Track mechs. That requirement *DID* exist in rfc-2478. So there seems to be a completely backwards incompatible change in rfc-4178. At least rfc-4178 is very explicit what it wants in 4.2. Rfc2478 was always meant to use the generic framing on all context tokens (they're called "negotiation tokens"). It's true that this is not explicitly spelled out, but at the time when rfc-2478 was produced, both of the gss-api mechanism in the IETF/CAT discussion (rfc-1964 Kerberos 5, rfc-2025 SPKM) was using the generic framing on all of the tokens (context level AND per-message tokens), and the little words about the issue in rfc-2478: 3.2.1. Syntax This section specifies the syntax of the corresponding "innerContextToken" field for the first token and subsequent negotiation tokens. During the mechanism negociation, the "innerContextToken" field contains the ASN.1 structure "NegociationToken" given below, encoded using the DER encoding conventions. talks about "innerContextToken" for the first **AND** subsequent negotiation tokens, which implies that all negotiation (=context level) tokens are built in the same fashion an all carry the generic framing. I thought there was an interop of SPNEGO-implementations a while ago-- I would have expected this issue to become apparent if it was ambiguous, provided that there are truely independent implementations of _the_spec_. In TLS it regularly happens that there is an early adopter of a new feature and all others follow the lead instead of the spec, and as a result breaking the spec in various subtle ways (i.e. I just noticed that SSLv3 and TLS v1.0 prohibit the use of an empty CAlist in the CertificatRequest message from the server, TLS v1.1 secretly changes this in a backwards incompatible fashion without the slightest warning and OpenSSL seems to have violated the SSLv3 and TLSv1 specs from the beginning). > > > > That said, there's this interesting question: PKU2U re-uses RFC4121 for > > > everything following PKU2U's first two security context tokens (which > > > are KDC messages between the initiator and the acceptor acting as a > > > pseudo-KDC), so, should those context tokens lifted from RFC4121 bear > > > this header? > > > > I really want to see the generic framing on all context level tokens > > (which is what you meant by header, I assume). > > Yes, that's what I meant by 'header'. > > > Could it be that you actually didn't want to ask about the framing, > > but about the mechanism OID within the header (if it is present)? > > No. > > > I'd like to see the generic framing, and I'd like to see it with > > the same mechanism OID as in the initial context token (which is > > different from rfc1964/rfc2141). > > Yes, if the generic header is on all context tokens then the same OID > has to be used for all those context tokens for any given security > context. > > Nico > -- > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 19 10:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY4U-0004EK-VM; Thu, 19 Apr 2007 10:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY4T-0004E6-KZ for kitten@lists.ietf.org; Thu, 19 Apr 2007 10:57:17 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeY4T-0000HQ-13 for kitten@lists.ietf.org; Thu, 19 Apr 2007 10:57:17 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JEvGwd008241 for ; Thu, 19 Apr 2007 14:57:16 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3JEvFfQ029130 for ; Thu, 19 Apr 2007 08:57:16 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3JEuGea011318; Thu, 19 Apr 2007 09:56:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3JEuFMV011317; Thu, 19 Apr 2007 09:56:15 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Apr 2007 09:56:15 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070419145614.GJ4375@Sun.COM> Mail-Followup-To: Martin Rex , lzhu@windows.microsoft.com, aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org References: <20070418211013.GT4375@Sun.COM> <200704191416.l3JEGHn3002032@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704191416.l3JEGHn3002032@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lzhu@windows.microsoft.com, spkm@ietf.org, kitten@lists.ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 19, 2007 at 04:16:16PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > I can't tell if RFC2478/4178 require that header on non-initial SPNEGO > > context tokens, but our implementation does NOT put it on any SPNEGO > > context token other than the initial one. Did we miss this? > > > > > This requirement, if we wanted to make it, would have to apply only to > > future Standards-Track mechs. > > That requirement *DID* exist in rfc-2478. So there seems to be > a completely backwards incompatible change in rfc-4178. > At least rfc-4178 is very explicit what it wants in 4.2. > > Rfc2478 was always meant to use the generic framing on all context > tokens (they're called "negotiation tokens"). It's true that this > is not explicitly spelled out, but at the time when rfc-2478 was > produced, both of the gss-api mechanism in the IETF/CAT discussion > (rfc-1964 Kerberos 5, rfc-2025 SPKM) was using the generic framing > on all of the tokens (context level AND per-message tokens), and > the little words about the issue in rfc-2478: > > 3.2.1. Syntax > > This section specifies the syntax of the corresponding > "innerContextToken" field for the first token and subsequent > negotiation tokens. During the mechanism negociation, the > "innerContextToken" field contains the ASN.1 structure > "NegociationToken" given below, encoded using the DER encoding > conventions. > > talks about "innerContextToken" for the first **AND** subsequent > negotiation tokens, which implies that all negotiation (=context level) > tokens are built in the same fashion an all carry the generic framing. I don't agree with that reading of the text. Regardless, if there are posts on the old CAT list about this saying that the generic framing is expected on non-initial context tokens then I agree that RFC4178 made a change. But we can't all be reading mailing lists from years ago -- RFCs shouldn't miss such things, and RFC2478 was missing a lot of details (e.g., what ASN.1 encoding to use). > I thought there was an interop of SPNEGO-implementations a while ago-- > I would have expected this issue to become apparent if it was ambiguous, > provided that there are truely independent implementations of _the_spec_. There truly independent implementations of _RFC4178_ were tested. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 19 11:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYxr-0004ak-F9; Thu, 19 Apr 2007 11:54:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYxp-0004aZ-HO; Thu, 19 Apr 2007 11:54:29 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYxm-00080j-3O; Thu, 19 Apr 2007 11:54:29 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA00774; Thu, 19 Apr 2007 17:54:16 +0200 (MESZ) From: Martin Rex Message-Id: <200704191552.l3JFqNWE008872@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Apr 2007 17:52:23 +0200 (MEST) In-Reply-To: <20070419145614.GJ4375@Sun.COM> from "Nicolas Williams" at Apr 19, 7 09:56:15 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: kitten@lists.ietf.org, spkm@ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Thu, Apr 19, 2007 at 04:16:16PM +0200, Martin Rex wrote: > > Nicolas Williams wrote: > > > I can't tell if RFC2478/4178 require that header on non-initial SPNEGO > > > context tokens, but our implementation does NOT put it on any SPNEGO > > > context token other than the initial one. Did we miss this? > > > > > > > > This requirement, if we wanted to make it, would have to apply only to > > > future Standards-Track mechs. > > > > That requirement *DID* exist in rfc-2478. So there seems to be > > a completely backwards incompatible change in rfc-4178. > > At least rfc-4178 is very explicit what it wants in 4.2. > > [...] > > I thought there was an interop of SPNEGO-implementations a while ago-- > > I would have expected this issue to become apparent if it was ambiguous, > > provided that there are truely independent implementations of _the_spec_. > > There truly independent implementations of _RFC4178_ were tested. As I said, rfc-4178 is very explicit what it wants in section 4.2. and this fact is highly appreciated. I would have expected this backwards incompatible change to become apparent when interop-testing backwards compatibility with exiting (i.e. legacy) implementations of SPNEGO. SPNEGO started out as SNEGO (without the handshake protection and without the optimistic token), and IIRC there (once) was a sample implementation of SNEGO by Bull announced by Denis Pinkas: From: pinkas@emsc.frcl.bull.fr (Denis Pinkas) Message-Id: <9602271637.AA23945@emsc.frcl.bull.fr> Subject: Simple GSS-API negotiation available To: cat-ietf@mit.edu (IETF CAT WG) Date: Tue, 27 Feb 1996 17:37:43 +0100 (NFT) An implementation of the Simple GSS-API negotiation mechanism (Internet-Draft draft-ietf-cat-snego-01.txt, 19 February 1996) is now available at the following URL : ftp://ftp.enst-bretagne.fr/pub/security/gssneg.tar.gz It uses SNACC 1.1 libraries for encoding and decoding of PDUs described in ASN.1. The SNACC compiler can be found at: Unfortunately, that "reference" implementation appears to be no longer available anywhere. Anyway -- there seemed to be very few independent implementations of rfc-2478 and only one implementation with a significant installed base. Personally, I never liked SPNEGO, and the claimed abiguities in rfc-2748 seemed to cause a certain amount of interoperability problems anyway, so I think it is OK if rfc-4178 prefers interoperability with a significant installed base to interoperability with rfc-2478. When a feature of a revised spec is significantly clarified over the previous version of the spec, a backwards interoperability warning should be added. This is missing in rfc-4178 4.2. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 19 12:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZC0-0004PV-Ky; Thu, 19 Apr 2007 12:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZBz-0004PQ-MV for kitten@lists.ietf.org; Thu, 19 Apr 2007 12:09:07 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZBy-0003Or-AU for kitten@lists.ietf.org; Thu, 19 Apr 2007 12:09:07 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JG95xK003179 for ; Thu, 19 Apr 2007 16:09:05 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3JG95aK012922 for ; Thu, 19 Apr 2007 10:09:05 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3JG86nn011408; Thu, 19 Apr 2007 11:08:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3JG86YF011407; Thu, 19 Apr 2007 11:08:06 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Apr 2007 11:08:05 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070419160805.GO4375@Sun.COM> Mail-Followup-To: Martin Rex , spkm@ietf.org, kitten@lists.ietf.org References: <20070419145614.GJ4375@Sun.COM> <200704191552.l3JFqNWE008872@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704191552.l3JFqNWE008872@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@lists.ietf.org, spkm@ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 19, 2007 at 05:52:23PM +0200, Martin Rex wrote: > When a feature of a revised spec is significantly clarified over the > previous version of the spec, a backwards interoperability warning > should be added. This is missing in rfc-4178 4.2. It is certainly not missing from where it belongs -- see RFC 4178, Appendix C: ... The working group was not aware of any RFC 2478 implementations deployed on the Internet. Even if there are such implementations, it is unlikely that they will inter-operate because of a critical flaw in the description of the encoding of the mechanism list in RFC 2478. With the approach taken in this specification, security is ensured between new implementations all the time while maintaining interoperability with the implementations deployed within the IETF community. The working group believes that this justifies breaking compatibility with a correct implementation of RFC 2478. ... Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 19 13:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaGm-00034s-UU; Thu, 19 Apr 2007 13:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaGl-00033k-19; Thu, 19 Apr 2007 13:18:07 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeaGj-0000ko-K5; Thu, 19 Apr 2007 13:18:07 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id TAA25445; Thu, 19 Apr 2007 19:18:01 +0200 (MESZ) From: Martin Rex Message-Id: <200704191718.l3JHI22h015497@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Apr 2007 19:18:02 +0200 (MEST) In-Reply-To: <20070419160805.GO4375@Sun.COM> from "Nicolas Williams" at Apr 19, 7 11:08:05 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Martin.Rex@sap.com, spkm@ietf.org, kitten@lists.ietf.org Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Thu, Apr 19, 2007 at 05:52:23PM +0200, Martin Rex wrote: > > When a feature of a revised spec is significantly clarified over the > > previous version of the spec, a backwards interoperability warning > > should be added. This is missing in rfc-4178 4.2. > > It is certainly not missing from where it belongs -- see RFC 4178, > Appendix C: > > ... > The working group was not aware of any RFC 2478 implementations > deployed on the Internet. Even if there are such implementations, it > is unlikely that they will inter-operate because of a critical flaw > in the description of the encoding of the mechanism list in RFC 2478. > > With the approach taken in this specification, security is ensured > between new implementations all the time while maintaining > interoperability with the implementations deployed within the IETF > community. The working group believes that this justifies breaking > compatibility with a correct implementation of RFC 2478. > ... I disagree. As I said, I want to see a "change warning" _exactly_ where a feature or detail is (incompatibly) changed, i.e. section 4.2. not in an Appendix. The particular change is not even mentioned in the text you quoted, probably because it wasn't realized as a change by the authors and by reviewers. If a change/clarification is locally highlighted as such, it will much more likely result in adequate thought and review about the change/clarification. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 01:03:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiO38-00018Z-68; Mon, 30 Apr 2007 01:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiO36-00018M-S6 for kitten@ietf.org; Mon, 30 Apr 2007 01:03:44 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiO35-0007GV-Dh for kitten@ietf.org; Mon, 30 Apr 2007 01:03:44 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3U53chw026209 for ; Mon, 30 Apr 2007 05:03:42 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3U53cvG004354 for ; Sun, 29 Apr 2007 23:03:38 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3U52X1C029173; Mon, 30 Apr 2007 00:02:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3U52WwH029172; Mon, 30 Apr 2007 00:02:32 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 00:02:32 -0500 From: Nicolas Williams To: David Leonard Message-ID: <20070430050231.GX21027@Sun.COM> Mail-Followup-To: David Leonard , kitten@ietf.org References: <461E3E36.3020601@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461E3E36.3020601@quest.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Hmmm, it strikes me that we already have a pointer argument in every GSS call in the C bindings. It's the OM_uint32 *minor_status argument. Suppose that we added functions for associating/dissassociating application contexts with/from minor_status pointer values? Compatibility would be preserved: minor_status would remain a pointer to OM_uint32 that can be safely dereferenced only to access an OM_uint32 value. And we'd no longer ened to entertain adding new versions of all the GSSv2 C bindings functions just to add an application context parameter -- we already have one we can use. Also, this would solve the composite minor_status code problem for pseudo-mechanisms like SPNEGO: if there's an app context associated with the minor_status pointer parameter to a routine with comlex minor status codes, then save the complex error information in the app context and then retrieve it again in gss_display_status(). Something like: OM_uint32 gss_make_app_context(OM_uint32 *minor_status); OM_uint32 gss_release_app_context(OM_uint32 *minor_status); OM_unit32 gss_set_app_context_attribute(OM_uint32 *minor_status, const char *attr, const gss_buffer_t value); OM_unit32 gss_get_app_context_attribute(OM_uint32 *minor_status, const char *attr, gss_buffer_t value); Comments? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 11:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXe2-0007Ar-RI; Mon, 30 Apr 2007 11:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXe1-0007Am-Vm for kitten@ietf.org; Mon, 30 Apr 2007 11:18:29 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXe0-0007rI-LX for kitten@ietf.org; Mon, 30 Apr 2007 11:18:29 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 6537842B99; Mon, 30 Apr 2007 11:18:24 -0400 (EDT) Date: Mon, 30 Apr 2007 11:18:22 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20070430111822.dd0e0aa7.mba2000@ioplex.com> In-Reply-To: <20070430050231.GX21027@Sun.COM> References: <461E3E36.3020601@quest.com> <20070430050231.GX21027@Sun.COM> Organization: IOPLEX Software X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, 30 Apr 2007 00:02:32 -0500 Nicolas Williams wrote: > Hmmm, it strikes me that we already have a pointer argument in every GSS > call in the C bindings. It's the OM_uint32 *minor_status argument. > > Suppose that we added functions for associating/dissassociating > application contexts with/from minor_status pointer values? Actually the more I think about this (you're going to hate this) I think everything should be pushed into one context. Merge what is now the authentication context and the new concept of an app context into one context that is initialized up-front with a call to "gss3_context_init". Then it can be used to set "params" before calling the usual gss functions. For example, a gss3_accept_sec_context call might look like the following: ret = gss3_context_init(&gssctx); if (ret == GSS3_S_COMPLETE) { ret = gss3_set_param(gssctx, GSS3_C_ACCEPTOR_CRED, verifier_cred_handle); if (ret) { ret = gss3_get_param(gssctx, GSS3_C_MINOR_STATUS, &minor); } else { do { read_token(input, input_token); ret = gss3_accept_sec_context(gssctx, input_token, output_token); write_token(output, output_token); } while (ret == GSS3_S_CONTINUE_NEEDED); if (ret == GSS3_S_COMPLETE) { ret = gss3_get_param(gssctx, GSS3_C_DELEGATED_CRED, &deleg); ... Now the accept_sec_context has been reduced to only accepting and producing buffers. User's only need to set or get the parameters that they are concerned with. This is much cleaner and simpler IMO. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 12:28:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYjR-0005Qs-Ue; Mon, 30 Apr 2007 12:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYjR-0005Qj-2G for kitten@ietf.org; Mon, 30 Apr 2007 12:28:09 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYjP-0000jQ-GV for kitten@ietf.org; Mon, 30 Apr 2007 12:28:09 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3UGS6MY024420 for ; Mon, 30 Apr 2007 16:28:06 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UGS604024505 for ; Mon, 30 Apr 2007 10:28:06 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3UGQxmQ029627; Mon, 30 Apr 2007 11:26:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3UGQxTY029626; Mon, 30 Apr 2007 11:26:59 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 11:26:59 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20070430162659.GO21027@Sun.COM> Mail-Followup-To: Michael B Allen , kitten@ietf.org References: <461E3E36.3020601@quest.com> <20070430050231.GX21027@Sun.COM> <20070430111822.dd0e0aa7.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070430111822.dd0e0aa7.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 11:18:22AM -0400, Michael B Allen wrote: > On Mon, 30 Apr 2007 00:02:32 -0500 > Nicolas Williams wrote: > > > Hmmm, it strikes me that we already have a pointer argument in every GSS > > call in the C bindings. It's the OM_uint32 *minor_status argument. > > > > Suppose that we added functions for associating/dissassociating > > application contexts with/from minor_status pointer values? > > Actually the more I think about this (you're going to hate this) > I think everything should be pushed into one context. Merge what > is now the authentication context and the new concept of an app > context into one context that is initialized up-front with a call to > "gss3_context_init". Then it can be used to set "params" before calling > the usual gss functions. > > For example, a gss3_accept_sec_context call might look like the following: > > ret = gss3_context_init(&gssctx); > if (ret == GSS3_S_COMPLETE) { > ret = gss3_set_param(gssctx, GSS3_C_ACCEPTOR_CRED, verifier_cred_handle); > if (ret) { > ret = gss3_get_param(gssctx, GSS3_C_MINOR_STATUS, &minor); > } else { > do { > read_token(input, input_token); > ret = gss3_accept_sec_context(gssctx, input_token, output_token); > write_token(output, output_token); > } while (ret == GSS3_S_CONTINUE_NEEDED); > > if (ret == GSS3_S_COMPLETE) { > ret = gss3_get_param(gssctx, GSS3_C_DELEGATED_CRED, &deleg); > ... > > Now the accept_sec_context has been reduced to only accepting and > producing buffers. User's only need to set or get the parameters that > they are concerned with. This is much cleaner and simpler IMO. But here's the thing: by stealing the OM_uint32 *minor_context parameter we get what you want, what David wants and a fixed gss_display_status(), ALL without changing function signatures and without having to change any application code that doesn't need these features. Yes, it's a bit of a hack to associate some contextual object with a OM_uint32 * value, but it's not terrible, and the price (backwards compat) is right: I'd rather avoid redoing the whole API if we can. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 14:00:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaAm-0007CS-8d; Mon, 30 Apr 2007 14:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hia9t-0006hW-EP for kitten@ietf.org; Mon, 30 Apr 2007 13:59:33 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hia7U-0008A5-K1 for kitten@ietf.org; Mon, 30 Apr 2007 13:57:05 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 8F50C42B91; Mon, 30 Apr 2007 13:57:00 -0400 (EDT) Date: Mon, 30 Apr 2007 13:56:58 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20070430135658.1aceaae4.mba2000@ioplex.com> In-Reply-To: <20070430162659.GO21027@Sun.COM> References: <461E3E36.3020601@quest.com> <20070430050231.GX21027@Sun.COM> <20070430111822.dd0e0aa7.mba2000@ioplex.com> <20070430162659.GO21027@Sun.COM> Organization: IOPLEX Software X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, 30 Apr 2007 11:26:59 -0500 Nicolas Williams wrote: > On Mon, Apr 30, 2007 at 11:18:22AM -0400, Michael B Allen wrote: > > ret = gss3_context_init(&gssctx); > > if (ret == GSS3_S_COMPLETE) { > > ret = gss3_set_param(gssctx, GSS3_C_ACCEPTOR_CRED, verifier_cred_handle); > > if (ret) { > > ret = gss3_get_param(gssctx, GSS3_C_MINOR_STATUS, &minor); > > } else { > > do { > > read_token(input, input_token); > > ret = gss3_accept_sec_context(gssctx, input_token, output_token); > > write_token(output, output_token); > > } while (ret == GSS3_S_CONTINUE_NEEDED); > > > > if (ret == GSS3_S_COMPLETE) { > > ret = gss3_get_param(gssctx, GSS3_C_DELEGATED_CRED, &deleg); > > ... > > > > Now the accept_sec_context has been reduced to only accepting and > > producing buffers. User's only need to set or get the parameters that > > they are concerned with. This is much cleaner and simpler IMO. > > But here's the thing: by stealing the OM_uint32 *minor_context parameter > we get what you want, what David wants and a fixed gss_display_status(), > ALL without changing function signatures and without having to change > any application code that doesn't need these features. > > Yes, it's a bit of a hack to associate some contextual object with a > OM_uint32 * value, but it's not terrible, and the price (backwards > compat) is right: I'd rather avoid redoing the whole API if we can. Nico, The API illustrated in the concept code above is clearly a "redo". I told you you would hate it :-> Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 14:38:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HialA-0005Ni-Uf; Mon, 30 Apr 2007 14:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HialA-0005Na-B4 for kitten@ietf.org; Mon, 30 Apr 2007 14:38:04 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hial9-0006v9-3s for kitten@ietf.org; Mon, 30 Apr 2007 14:38:04 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3UIbx1P021255; Mon, 30 Apr 2007 14:37:59 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3UIbwI4019294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Apr 2007 14:37:59 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id l3UIbwhq011217; Mon, 30 Apr 2007 14:37:58 -0400 (EDT) To: Michael B Allen References: <461E3E36.3020601@quest.com> <20070430050231.GX21027@Sun.COM> <20070430111822.dd0e0aa7.mba2000@ioplex.com> <20070430162659.GO21027@Sun.COM> From: Tom Yu Date: Mon, 30 Apr 2007 14:37:58 -0400 In-Reply-To: <20070430162659.GO21027@Sun.COM> (Nicolas Williams's message of "Mon, 30 Apr 2007 11:26:59 -0500") Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Nico" == Nicolas Williams writes: Nico> But here's the thing: by stealing the OM_uint32 *minor_context parameter Nico> we get what you want, what David wants and a fixed gss_display_status(), Nico> ALL without changing function signatures and without having to change Nico> any application code that doesn't need these features. I'm not sure you can guarantee that a caller will always pass the same pointer in as a minor_context parameter, nor that the caller will never alter the value pointed to. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 14:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hib5p-0000Od-6A; Mon, 30 Apr 2007 14:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hib5o-0000OX-1e for kitten@ietf.org; Mon, 30 Apr 2007 14:59:24 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hib5m-0002fV-Bt for kitten@ietf.org; Mon, 30 Apr 2007 14:59:24 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3UIxL5b011147 for ; Mon, 30 Apr 2007 18:59:21 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UIxLNp010634 for ; Mon, 30 Apr 2007 12:59:21 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3UIwGJY000137; Mon, 30 Apr 2007 13:58:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3UIwBpZ000136; Mon, 30 Apr 2007 13:58:11 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 13:58:11 -0500 From: Nicolas Williams To: Tom Yu Message-ID: <20070430185811.GT21027@Sun.COM> Mail-Followup-To: Tom Yu , Michael B Allen , kitten@ietf.org References: <461E3E36.3020601@quest.com> <20070430050231.GX21027@Sun.COM> <20070430111822.dd0e0aa7.mba2000@ioplex.com> <20070430162659.GO21027@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 02:37:58PM -0400, Tom Yu wrote: > >>>>> "Nico" == Nicolas Williams writes: > > Nico> But here's the thing: by stealing the OM_uint32 *minor_context parameter > Nico> we get what you want, what David wants and a fixed gss_display_status(), > Nico> ALL without changing function signatures and without having to change > Nico> any application code that doesn't need these features. > > I'm not sure you can guarantee that a caller will always pass the same > pointer in as a minor_context parameter, nor that the caller will > never alter the value pointed to. No, you can't -- but you can guarantee that the caller who would associate an app context with minor_status values would. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 16:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HicEi-0008Js-F3; Mon, 30 Apr 2007 16:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HicEg-0008Jm-Dc for kitten@ietf.org; Mon, 30 Apr 2007 16:12:38 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HicEg-00010W-0m for kitten@ietf.org; Mon, 30 Apr 2007 16:12:38 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA24255; Mon, 30 Apr 2007 22:12:32 +0200 (MESZ) From: Martin Rex Message-Id: <200704302012.l3UKCXGp021085@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 30 Apr 2007 22:12:32 +0200 (MEST) In-Reply-To: <20070430162659.GO21027@Sun.COM> from "Nicolas Williams" at Apr 30, 7 11:26:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org YUCK, and I believe it will not work. minor_status in the C-Bindings has always been a OM_uint32. Since in C a function can only have a single return value and that is used for the OM_uint32 major_status, therefore it is necessary to use a function argument to supply the (OM_uint32) buffer for returning the value. > > But here's the thing: by stealing the OM_uint32 *minor_context parameter > we get what you want, what David wants and a fixed gss_display_status(), > ALL without changing function signatures and without having to change > any application code that doesn't need these features. That is obviously wrong. the minor_status value that should be translated into text in an input parameter to gss_display_status, namely "status_value", and therefore it is passed as an OM_uint32 by value, and *NOT* by reference. The minor_status that is passed by reference into gss_display_status is function return parameter of gss_display_status to report translation errors from within gss_display_status, *NOT* the value that is to be translated into text! On Mon, Apr 30, 2007 at 11:18:22AM -0400, Michael B Allen wrote: = > = > Suppose that we added functions for associating/dissassociating = > application contexts with/from minor_status pointer values? = = Actually the more I think about this (you're going to hate this) = I think everything should be pushed into one context. Merge what = is now the authentication context and the new concept of an app = context into one context that is initialized up-front with a call to = "gss3_context_init". Then it can be used to set "params" before calling = the usual gss functions. = = For example, a gss3_accept_sec_context call might look like the following: = = ret = gss3_context_init(&gssctx); = if (ret == GSS3_S_COMPLETE) { = ret = gss3_set_param(gssctx, GSS3_C_ACCEPTOR_CRED, verifier_cred_handle); = if (ret) { = ret = gss3_get_param(gssctx, GSS3_C_MINOR_STATUS, &minor); = } else { = do { = read_token(input, input_token); = ret = gss3_accept_sec_context(gssctx, input_token, output_token); = write_token(output, output_token); = } while (ret == GSS3_S_CONTINUE_NEEDED); = = if (ret == GSS3_S_COMPLETE) { = ret = gss3_get_param(gssctx, GSS3_C_DELEGATED_CRED, &deleg); = ... = = Now the accept_sec_context has been reduced to only accepting and = producing buffers. User's only need to set or get the parameters that = they are concerned with. This is much cleaner and simpler IMO. You're forgetting the context attributes retured from accept_sec_context plus the name of the authenticated peer/initiator, and also the input context attributes that are missing in GSS-API v2 and have been asked for. To me your approach looks like it suffers an "object orientation challenge", results in more and less readable code and is usually the preferred approach of those that don't want to spent time on thinking ahead. I don't know what the real pupose of the gss_ctx here is. It is certainly overkill like this if the only purpose is to deal with minor_status values from different mechanisms. What about gss_acquire_cred, gss_import_name, gss_export_name, gss_canonicalize_name, gss_compare_name and the others, do they also need a gss_ctx in your model? Can credentials or names created with gss_ctx a be used with gss_ctx b? What about full duplex operation for message protection on a security context? -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 16:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HicFU-0008Sf-2G; Mon, 30 Apr 2007 16:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HicFS-0008Sa-Sm for kitten@ietf.org; Mon, 30 Apr 2007 16:13:26 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HicFN-00012a-Bx for kitten@ietf.org; Mon, 30 Apr 2007 16:13:26 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3UKDKFL005782 for ; Mon, 30 Apr 2007 20:13:20 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UKDKN1021095 for ; Mon, 30 Apr 2007 14:13:20 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3UKCFFZ000416; Mon, 30 Apr 2007 15:12:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3UKCFmY000415; Mon, 30 Apr 2007 15:12:15 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 15:12:15 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070430201214.GV21027@Sun.COM> Mail-Followup-To: Martin Rex , mba2000@ioplex.com, kitten@ietf.org References: <20070430162659.GO21027@Sun.COM> <200704302012.l3UKCXGp021085@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704302012.l3UKCXGp021085@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 10:12:32PM +0200, Martin Rex wrote: > YUCK, and I believe it will not work. > > minor_status in the C-Bindings has always been a OM_uint32. I did not propose changing it! _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 16:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HicJS-0000db-Rc; Mon, 30 Apr 2007 16:17:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HicJR-0000dW-Vz for kitten@ietf.org; Mon, 30 Apr 2007 16:17:33 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HicJQ-0002c6-K3 for kitten@ietf.org; Mon, 30 Apr 2007 16:17:33 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3UKHWUg018596 for ; Mon, 30 Apr 2007 20:17:32 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UKHWBa023195 for ; Mon, 30 Apr 2007 14:17:32 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3UKGRUV000423; Mon, 30 Apr 2007 15:16:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3UKGR8R000422; Mon, 30 Apr 2007 15:16:27 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 15:16:27 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070430201626.GW21027@Sun.COM> Mail-Followup-To: Martin Rex , mba2000@ioplex.com, kitten@ietf.org References: <20070430162659.GO21027@Sun.COM> <200704302012.l3UKCXGp021085@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704302012.l3UKCXGp021085@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 10:12:32PM +0200, Martin Rex wrote: > > But here's the thing: by stealing the OM_uint32 *minor_context parameter > > we get what you want, what David wants and a fixed gss_display_status(), > > ALL without changing function signatures and without having to change > > any application code that doesn't need these features. > > That is obviously wrong. the minor_status value that should be > translated into text in an input parameter to gss_display_status, > namely "status_value", and therefore it is passed as an OM_uint32 by value, > and *NOT* by reference. It's not obviously wrong. Mechanisms like SPNEGO have error display strings, and therefore minor status codes, that depend on other mechanisms, and so these are dynamic -- SPNEGO implementations have to allocate their minor_status values at runtime or lose information. Once you start going down that route what I propose becomes obvious. Note, once more, that I don't propose changing the type of minor_status, or that GSS functions not put actual minor status codes in there, nor that it be possible to case minor_status OM_uint32 * values to any other type. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 16:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hicdi-00081s-QW; Mon, 30 Apr 2007 16:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hicdh-00081n-Cy for kitten@ietf.org; Mon, 30 Apr 2007 16:38:29 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hicdf-00068K-Vs for kitten@ietf.org; Mon, 30 Apr 2007 16:38:29 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA02537; Mon, 30 Apr 2007 22:38:07 +0200 (MESZ) From: Martin Rex Message-Id: <200704302038.l3UKc74l022583@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 30 Apr 2007 22:38:07 +0200 (MEST) In-Reply-To: <20070430201626.GW21027@Sun.COM> from "Nicolas Williams" at Apr 30, 7 03:16:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: kitten@ietf.org, Martin.Rex@sap.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Mon, Apr 30, 2007 at 10:12:32PM +0200, Martin Rex wrote: > > > But here's the thing: by stealing the OM_uint32 *minor_context parameter > > > we get what you want, what David wants and a fixed gss_display_status(), > > > ALL without changing function signatures and without having to change > > > any application code that doesn't need these features. > > > > That is obviously wrong. the minor_status value that should be > > translated into text in an input parameter to gss_display_status, > > namely "status_value", and therefore it is passed as an OM_uint32 by value, > > and *NOT* by reference. > > It's not obviously wrong. Mechanisms like SPNEGO have error display > strings, and therefore minor status codes, that depend on other > mechanisms, and so these are dynamic -- SPNEGO implementations have to > allocate their minor_status values at runtime or lose information. > > Once you start going down that route what I propose becomes obvious. > > Note, once more, that I don't propose changing the type of minor_status, > or that GSS functions not put actual minor status codes in there, nor > that it be possible to case minor_status OM_uint32 * values to any other > type. Personally, I conider SPNEGO to be of _EXTREMELY_ limited use, and sometimes just as a useless overhead (WWW-Autheticate: Negotiate). A much more significant problem than the limited minor_status numberspace is the namespace problem, because it directly and significantly affects the entire security. The error code numberspace issue is fairly common and can usually be dealt with. Microsoft Windows comes with a huge number of independent APIs, but still Microsoft managed to fit most of them into a single DWORD GetLastError() number space. In my gsskrb5 wrapper for Microsoft's Kerberos SSP I have a number of different sources from which I combine/fold error numbers into a single OM_uint32. Errors local to my code (e.g. parsing tokens or object handle consistency), errors from ANSI-C functions, error from "regular" Win32-API functions (e.g. LoadLibrary), errors from WinSock functions (e.g. gethostbyname), errors from SSPI functions. The reason why SPNEGO does not break horribly in the Microsoft environment in spite of the distinct name spaces between NTLM and Kerberos SSPs is because with NTLM the target name is completely ignored anyway and on the acceptor side Microsoft doesn't use the name-based authentication provided by the SSP, rather it uses the impersonation and delegation through SSPI functions. I it will much harder for Unix-based SPNEGO approaches to solve the namespace issue than to find a workable approach to the error number space problem (unless they also dump the entire target-authentication and switch from name-based authentication for the acceptor to something opaque as well). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 17:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hicym-0003rt-9s; Mon, 30 Apr 2007 17:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hicyl-0003ro-OZ for kitten@ietf.org; Mon, 30 Apr 2007 17:00:15 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hicyk-0001Mm-5t for kitten@ietf.org; Mon, 30 Apr 2007 17:00:15 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3UL0DQF003429 for ; Mon, 30 Apr 2007 21:00:13 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UL0Ds6014012 for ; Mon, 30 Apr 2007 15:00:13 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3UKx66D000462; Mon, 30 Apr 2007 15:59:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3UKx6jF000461; Mon, 30 Apr 2007 15:59:06 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 15:59:06 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070430205906.GY21027@Sun.COM> Mail-Followup-To: Martin Rex , mba2000@ioplex.com, kitten@ietf.org References: <20070430201626.GW21027@Sun.COM> <200704302038.l3UKc74l022583@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704302038.l3UKc74l022583@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 10:38:07PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > Note, once more, that I don't propose changing the type of minor_status, > > or that GSS functions not put actual minor status codes in there, nor > > that it be possible to case minor_status OM_uint32 * values to any other > > type. > > [...] But you didn't answer the [unstated, granted] question: is there a fundamental problem with this approach? I think the answer is obviously "no." It doesn't break compatibility at the binary nor source levels, but it does solve David's problem more comprehensively than the previous proposal. - Backwards compatible with existing binaries? Check. - Backwards compatible at the source level? Check. - Does it allow for the things that David Leonard and Vintella want? Check (David agrees in private e-mail). - Does it solve the pseudo-mechanism composite/dynamic minor_status code issue? Check. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 17:51:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hidmh-0004z3-4g; Mon, 30 Apr 2007 17:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hidmg-0004yy-Cn for kitten@ietf.org; Mon, 30 Apr 2007 17:51:50 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hidmf-0000U2-0k for kitten@ietf.org; Mon, 30 Apr 2007 17:51:50 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA10522; Mon, 30 Apr 2007 23:51:42 +0200 (MESZ) From: Martin Rex Message-Id: <200704302151.l3ULpfSg027927@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 30 Apr 2007 23:51:41 +0200 (MEST) In-Reply-To: <20070430205906.GY21027@Sun.COM> from "Nicolas Williams" at Apr 30, 7 03:59:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org, Martin.Rex@sap.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Mon, Apr 30, 2007 at 10:38:07PM +0200, Martin Rex wrote: > > Nicolas Williams wrote: > > > Note, once more, that I don't propose changing the type of minor_status, > > > or that GSS functions not put actual minor status codes in there, nor > > > that it be possible to case minor_status OM_uint32 * values to any other > > > type. > > > > [...] > > But you didn't answer the [unstated, granted] question: is there a > fundamental problem with this approach? > > I think the answer is obviously "no." It doesn't break compatibility at > the binary nor source levels, but it does solve David's problem more > comprehensively than the previous proposal. > > - Backwards compatible with existing binaries? Check. > - Backwards compatible at the source level? Check. > - Does it allow for the things that David Leonard and Vintella want? > Check (David agrees in private e-mail). > - Does it solve the pseudo-mechanism composite/dynamic minor_status > code issue? Check. Huh? We are still talking about the minor_status, aren't we? The OM_uint32 * minor_status values are pointers created and supplied by the application caller, and they're likely to be local and distinct for each call to gssapi. Some application callers will visualize the numeric value directly, so there is no point in the mechanism associating any information with particular pointer values. The rest will pass the minor_status to gss_display_status() by value, so that the gssapi mechanism has no benefit whatsoever from memorizing any previous random and unrelated pointer values when trying to translate the OM_uint32 integer passed into gss_display_status(). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 18:11:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hie5Q-0002L5-OG; Mon, 30 Apr 2007 18:11:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hie5Q-0002Ko-03 for kitten@ietf.org; Mon, 30 Apr 2007 18:11:12 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hie5P-000379-KS for kitten@ietf.org; Mon, 30 Apr 2007 18:11:11 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 8F2CC42B61; Mon, 30 Apr 2007 18:11:07 -0400 (EDT) Date: Mon, 30 Apr 2007 18:11:05 -0400 From: Michael B Allen To: martin.rex@sap.com Message-Id: <20070430181105.442ce11c.mba2000@ioplex.com> In-Reply-To: <200704302012.l3UKCXGp021085@fs4113.wdf.sap.corp> References: <20070430162659.GO21027@Sun.COM> <200704302012.l3UKCXGp021085@fs4113.wdf.sap.corp> Organization: IOPLEX Software X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@ietf.org, Martin Rex , Nicolas Williams Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, 30 Apr 2007 22:12:32 +0200 (MEST) Martin Rex wrote: > = For example, a gss3_accept_sec_context call might look like the following: > = > = ret = gss3_context_init(&gssctx); > = if (ret == GSS3_S_COMPLETE) { > = ret = gss3_set_param(gssctx, GSS3_C_ACCEPTOR_CRED, verifier_cred_handle); > = if (ret) { > = ret = gss3_get_param(gssctx, GSS3_C_MINOR_STATUS, &minor); > = } else { > = do { > = read_token(input, input_token); > = ret = gss3_accept_sec_context(gssctx, input_token, output_token); > = write_token(output, output_token); > = } while (ret == GSS3_S_CONTINUE_NEEDED); > = > = if (ret == GSS3_S_COMPLETE) { > = ret = gss3_get_param(gssctx, GSS3_C_DELEGATED_CRED, &deleg); > = ... > = > = Now the accept_sec_context has been reduced to only accepting and > = producing buffers. User's only need to set or get the parameters that > = they are concerned with. This is much cleaner and simpler IMO. > > You're forgetting the context attributes retured from accept_sec_context > plus the name of the authenticated peer/initiator, and also the > input context attributes that are missing in GSS-API v2 and have been > asked for. All of that would be handled through gss3_{set,get}_param. The api would be like how the ldap_* api sets and gets options. > What about gss_acquire_cred, gss_import_name, gss_export_name, > gss_canonicalize_name, gss_compare_name and the others, do they also > need a gss_ctx in your model? Yes. As a general rule everything but the most trivial functions should have a context (e.g. like the krb5_* api). > Can credentials or names created with gss_ctx a be used with gss_ctx b? I can't think of a reason why not but the object would need to be freed with the context from which it was allocated. Again krb5_* and ldap_* apis illustrate that. > What about full duplex operation for message protection on a security > context? Never heard of that but I'm not suggested that the procedures or semantics of any functions or parameters be changed. I'm only suggesting that there be a single context in place of the current authentication context and proposed application context and that the API I propose take advantage of that context by simplifying some parameter management. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 18:29:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HieNN-0005ac-W8; Mon, 30 Apr 2007 18:29:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HieNN-0005aX-41 for kitten@ietf.org; Mon, 30 Apr 2007 18:29:45 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HieNL-0006wV-NH for kitten@ietf.org; Mon, 30 Apr 2007 18:29:45 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3UMThuL019940 for ; Mon, 30 Apr 2007 22:29:43 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UMTgGP019703 for ; Mon, 30 Apr 2007 16:29:42 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3UMSbtj000624; Mon, 30 Apr 2007 17:28:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3UMSa1n000623; Mon, 30 Apr 2007 17:28:36 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 17:28:36 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070430222835.GA21027@Sun.COM> Mail-Followup-To: Martin Rex , mba2000@ioplex.com, kitten@ietf.org References: <20070430205906.GY21027@Sun.COM> <200704302151.l3ULpfSg027927@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704302151.l3ULpfSg027927@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 11:51:41PM +0200, Martin Rex wrote: > Huh? > > We are still talking about the minor_status, aren't we? Yes, and evidently you did not read what I wrote closely enough :) > The OM_uint32 * minor_status values are pointers created and > supplied by the application caller, and they're likely to be > local and distinct for each call to gssapi. Indeed. In the new model an app that wants this new feature (but not other apps) must have OM_uint32 * minor_status values that are malloc()ed, ... ...or, if the app wants to use a pointer to a OM_uint32 variable (which would not be recommended) then it would have to remain in scope across all uses of that variable with all GSS functions for whatever the app is doing. > Some application callers will visualize the numeric value directly, > so there is no point in the mechanism associating any information > with particular pointer values. Minor status codes are NOT defined! Applications cannot interpret them deirectly -- they MUST call gss_display_status() in order to interpret them. But it wouldn't matter if they were defined. Apps that want this new feature would not interpret OM_uint32 minor_status values directly. > The rest will pass the minor_status to gss_display_status() > by value, so that the gssapi mechanism has no benefit whatsoever > from memorizing any previous random and unrelated pointer values > when trying to translate the OM_uint32 integer passed into > gss_display_status(). Oh, but it does. It can provide more context than simple integers can, and when the app context object is destroyed the mechanism can also release such additional context (whereas pseudo-mechs today cannot because their minor status codes may be dynamically established and the mechs have no idea when they will no longer be referenced). And then there are David's uses for this scheme (see the post that started this thread). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 19:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HifiN-0005VC-SF; Mon, 30 Apr 2007 19:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HifiN-0005V7-5A for kitten@ietf.org; Mon, 30 Apr 2007 19:55:31 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HifiL-00069j-U6 for kitten@ietf.org; Mon, 30 Apr 2007 19:55:31 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3UNtS1d012465; Mon, 30 Apr 2007 19:55:28 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3UNtRv1015146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Apr 2007 19:55:28 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id l3UNtRBm013831; Mon, 30 Apr 2007 19:55:27 -0400 (EDT) To: Martin Rex References: <20070430205906.GY21027@Sun.COM> <200704302151.l3ULpfSg027927@fs4113.wdf.sap.corp> <20070430222835.GA21027@Sun.COM> From: Tom Yu Date: Mon, 30 Apr 2007 19:55:27 -0400 In-Reply-To: <20070430222835.GA21027@Sun.COM> (Nicolas Williams's message of "Mon, 30 Apr 2007 17:28:36 -0500") Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Nico" == Nicolas Williams writes: Nico> Oh, but it does. It can provide more context than simple integers can, Nico> and when the app context object is destroyed the mechanism can also Nico> release such additional context (whereas pseudo-mechs today cannot Nico> because their minor status codes may be dynamically established and the Nico> mechs have no idea when they will no longer be referenced). That reminds me of a potentially very important question: Do the GSS-API C Bindings require that a minor_status value be valid for multiple invocation cycles of gss_display_status()? "Invocation cycle" means looping through gss_display_status() until the value pointed to by message_context reaches zero. The answer to this question determines whether a mechanism has a good way to decide when to garbage-collect dynamic state associated with a minor_status value. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 20:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HigIM-0003ns-41; Mon, 30 Apr 2007 20:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HigIL-0003nn-Jx for kitten@ietf.org; Mon, 30 Apr 2007 20:32:41 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HigIL-0003Fh-7O for kitten@ietf.org; Mon, 30 Apr 2007 20:32:41 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id CAA23071; Tue, 1 May 2007 02:32:36 +0200 (MESZ) From: Martin Rex Message-Id: <200705010032.l410WZqI009012@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 1 May 2007 02:32:35 +0200 (MEST) In-Reply-To: <20070430222835.GA21027@Sun.COM> from "Nicolas Williams" at Apr 30, 7 05:28:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: kitten@ietf.org, Martin.Rex@sap.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > Minor status codes are NOT defined! Applications cannot interpret them > deirectly -- they MUST call gss_display_status() in order to interpret > them. > > But it wouldn't matter if they were defined. Apps that want this new > feature would not interpret OM_uint32 minor_status values directly. Applications hardly interpret them. Portable apps certainly will never try. The will only visualize to a user. Most apps will special case very few of the major_status values, simply because there will not be programmatic recovery available anyway--instead user intervention or even admin intervention required. > > > The rest will pass the minor_status to gss_display_status() > > by value, so that the gssapi mechanism has no benefit whatsoever > > from memorizing any previous random and unrelated pointer values > > when trying to translate the OM_uint32 integer passed into > > gss_display_status(). > > Oh, but it does. It can provide more context than simple integers can, > and when the app context object is destroyed the mechanism can also > release such additional context (whereas pseudo-mechs today cannot > because their minor status codes may be dynamically established and the > mechs have no idea when they will no longer be referenced). I'm sorry, but I completely fail to understand what you are referring to. If this is about GSS-API v3 with a backwards-incompatible change to the function signature of gss_display_status, then we should probably redesign it anyway. If this is about a GSS-API v2 backwards compatible change, then this possibility simply doesn't exist. The input parameter to gss_display_status is a 32-bit integer scalar type, there simply is no pointer value. The mechanism has no means to recognize relation to previous failed GSS-API calls other than by the numeric value of that 32-bit integer--you simply cannot improve it beyond what is there today. I have seen gssapi mechanism that keep additional state around for failed gssapi calls in a pretty useful and fairly robust fashion. They keep a small ring buffer of dynamically allocated failure messages for failed gssapi calls and they related by minor_status code only. If one cares for thread-safety, using a small ring buffer per-thread might do for that. Cleaning up dynamic thread local storage can be difficult at times. With Microsoft's broken approach it is impossible for statically linked libraries, and difficult for DLLs that might get loaded&unloaded several times during process lifetime and unsynchronized with thread creation/deletion. With POSIX threads it works fine if you can use free() as the destructor function (otherwise you get problems if a shared library get dlclose()d before the thread terminates). But compared to the authentication problem from incompatible namespaces of arbitrary gssapi mechanism I consider the minor_status issue almost a trivial issue. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 20:54:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Higdt-0000c3-8b; Mon, 30 Apr 2007 20:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Higds-0000bt-IW for kitten@ietf.org; Mon, 30 Apr 2007 20:54:56 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Higdr-0006cU-5X for kitten@ietf.org; Mon, 30 Apr 2007 20:54:56 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id CAA14305; Tue, 1 May 2007 02:54:53 +0200 (MESZ) From: Martin Rex Message-Id: <200705010054.l410sqSY010384@fs4113.wdf.sap.corp> To: tlyu@MIT.EDU (Tom Yu) Date: Tue, 1 May 2007 02:54:52 +0200 (MEST) In-Reply-To: from "Tom Yu" at Apr 30, 7 07:55:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: kitten@ietf.org, Martin.Rex@sap.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Tom Yu wrote: > > >>>>> "Nico" == Nicolas Williams writes: > > Nico> Oh, but it does. It can provide more context than simple integers can, > Nico> and when the app context object is destroyed the mechanism can also > Nico> release such additional context (whereas pseudo-mechs today cannot > Nico> because their minor status codes may be dynamically established and the > Nico> mechs have no idea when they will no longer be referenced). > > That reminds me of a potentially very important question: > > Do the GSS-API C Bindings require that a minor_status value be valid > for multiple invocation cycles of gss_display_status()? "Invocation > cycle" means looping through gss_display_status() until the value > pointed to by message_context reaches zero. A very similar question was asked about all the various input parameters to gss_accept_sec_context() and gss_init_sec_context() which are iteration calls in *ALL* language bindings, and the answer was: - all input parameters MUST be the same for all iteration calls, - all modify parameters MUST ONLY be modified by the gssapi mechanism on iteration calls - all opaque and static output parameters MUST be the same for all iteration calls, (i.e. mech_oid, deleg_cred and src_name) - no restriction for the token paramters, they're specific to each individual call > > The answer to this question determines whether a mechanism has a good > way to decide when to garbage-collect dynamic state associated with a > minor_status value. While a minor_status text containing dynamic situation-specific information might be helpful in a small number of situations, it is quite possible for gssapi mechanisms to get along just fine with a 32-bit flat integer and no dynamic resources whatsoever. With GSS-API v2 I see no other possibility than to use a (ring) buffer for a small number of past errors, potentially thread-local if that is an issue. I've seen implementations doing this and it worked well. If the only thing that's being done is to echo back the entire offending input parameter, then I don't really see the need. An application does now which input parameters it supplied to a gssapi call, and which of these input parametes can be configured/changed by a user and how. Dynamically generated error messages should primarily be used to convey information that is local to the GSS-API mechanism. i.e. GSS_S_FAILURE + minor_status = "File not found" is pretty dumb for a mechanism since none of input parameters of any of the gss_api v2 calls conveys a file name -- so the mechanism should at least provide sufficient information on what kind of file it is acutally looking for. And when it is a configuration file, then the name will often be static (i.e. can be recomputed with ease). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 21:24:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hih6P-0007tI-9n; Mon, 30 Apr 2007 21:24:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hih6O-0007tD-RL for kitten@ietf.org; Mon, 30 Apr 2007 21:24:24 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hih6O-000163-F3 for kitten@ietf.org; Mon, 30 Apr 2007 21:24:24 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id DAA20408; Tue, 1 May 2007 03:24:20 +0200 (MESZ) From: Martin Rex Message-Id: <200705010124.l411OJrU012456@fs4113.wdf.sap.corp> To: mba2000@ioplex.com (Michael B Allen) Date: Tue, 1 May 2007 03:24:19 +0200 (MEST) In-Reply-To: <20070430181105.442ce11c.mba2000@ioplex.com> from "Michael B Allen" at Apr 30, 7 06:11:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Michael B Allen wrote: > > > > You're forgetting the context attributes retured from accept_sec_context > > plus the name of the authenticated peer/initiator, and also the > > input context attributes that are missing in GSS-API v2 and have been > > asked for. > > All of that would be handled through gss3_{set,get}_param. The api would > be like how the ldap_* api sets and gets options. That is the awful response I expected. As I said, this approach is extremely OO-impaired, i.e. broken. GSS-API is an interface standard, more than it is an on-the-wire standard. An OO-approach for an API quickly results in myriads of incompatible proprietary variants (of set/get params), while the beauty of GSS-API (at least at the C-level) is that you can easily get a large number of fully interoperable implementations over many years. We've been doing binary plug'n'play with ~15 third-party gssapi mechanism for the last 9 years. In contrast to that, try to compile the most recent version of a GNOME-based app on a original 4-year old Linux distro and you hit a brick wall -- you will usually not be able to get it compile without updating a large number of other apps and libraries as well-- which shows how broken the approach is. At times of Motif and X11R4/R5 the backwards compatibility of X11-apps used to be MUCH MUCH MUCH better. > > I can't think of a reason why not but the object would need to be freed > with the context from which it was allocated. Again krb5_* and ldap_* > apis illustrate that. Luckily I never had to deal with either one, krb5_* and ldap_*. I've been using GSS-API, SSPI and OpenSSL-like APIs to TLS and neither of them uses it. > > > What about full duplex operation for message protection on a security > > context? > > Never heard of that but I'm not suggested that the procedures or semantics > of any functions or parameters be changed. I'm only suggesting that there > be a single context in place of the current authentication context and > proposed application context and that the API I propose take advantage > of that context by simplifying some parameter management. When communicating there are usually two independent streams on the same connection, one from initiator to acceptor and one in the opposite direction. If you can communicate in both direction simultaneously and indepently, it is called full-duplex, i.e. you might be using two independent threads for reading and writing on a network socket. For GSS-API, the question would be whether parallel calls (in seperate threads) to message protection (=write) and message unprotection (=read) on the same gssapi security context handle should be supported. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 21:55:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hihai-00028O-Gn; Mon, 30 Apr 2007 21:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hihag-00020L-Tf for kitten@ietf.org; Mon, 30 Apr 2007 21:55:42 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hihaf-0004pX-LL for kitten@ietf.org; Mon, 30 Apr 2007 21:55:42 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id AC07242B61; Mon, 30 Apr 2007 21:55:37 -0400 (EDT) Date: Mon, 30 Apr 2007 21:55:36 -0400 From: Michael B Allen To: martin.rex@sap.com Message-Id: <20070430215536.347a545f.mba2000@ioplex.com> In-Reply-To: <200705010124.l411OJrU012456@fs4113.wdf.sap.corp> References: <20070430181105.442ce11c.mba2000@ioplex.com> <200705010124.l411OJrU012456@fs4113.wdf.sap.corp> Organization: IOPLEX Software X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Tue, 1 May 2007 03:24:19 +0200 (MEST) Martin Rex wrote: > Michael B Allen wrote: > > > > > > You're forgetting the context attributes retured from accept_sec_context > > > plus the name of the authenticated peer/initiator, and also the > > > input context attributes that are missing in GSS-API v2 and have been > > > asked for. > > > > All of that would be handled through gss3_{set,get}_param. The api would > > be like how the ldap_* api sets and gets options. > > That is the awful response I expected. > As I said, this approach is extremely OO-impaired, i.e. broken. I have no idea what you're talking about. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 22:59:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiiaP-0001C8-Fb; Mon, 30 Apr 2007 22:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiiaP-0001C3-6i for kitten@ietf.org; Mon, 30 Apr 2007 22:59:29 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiiaN-0004SJ-Ti for kitten@ietf.org; Mon, 30 Apr 2007 22:59:29 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l412xRe9019188 for ; Tue, 1 May 2007 02:59:27 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l412xRTm013868 for ; Mon, 30 Apr 2007 20:59:27 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l412wKbs000861; Mon, 30 Apr 2007 21:58:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l412wJHw000860; Mon, 30 Apr 2007 21:58:19 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 21:58:19 -0500 From: Nicolas Williams To: Tom Yu Message-ID: <20070501025818.GE21027@Sun.COM> Mail-Followup-To: Tom Yu , Martin Rex , kitten@ietf.org References: <20070430205906.GY21027@Sun.COM> <200704302151.l3ULpfSg027927@fs4113.wdf.sap.corp> <20070430222835.GA21027@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, Martin Rex Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 30, 2007 at 07:55:27PM -0400, Tom Yu wrote: > That reminds me of a potentially very important question: > > Do the GSS-API C Bindings require that a minor_status value be valid > for multiple invocation cycles of gss_display_status()? "Invocation > cycle" means looping through gss_display_status() until the value > pointed to by message_context reaches zero. > > The answer to this question determines whether a mechanism has a good > way to decide when to garbage-collect dynamic state associated with a > minor_status value. Unsure. I think I'd want mechanisms to be conservative about this. Of course, with an additional function to "register" and "unregister" minor status pointers (which is another way to describe my proposal) the issue goes away where apps use this extension. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 23:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiiiL-0005hE-T9; Mon, 30 Apr 2007 23:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiiiK-0005h9-Ob for kitten@ietf.org; Mon, 30 Apr 2007 23:07:40 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiiiK-0005lf-CJ for kitten@ietf.org; Mon, 30 Apr 2007 23:07:40 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l4137ZgR029254 for ; Tue, 1 May 2007 03:07:39 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l4137ZOB016492 for ; Mon, 30 Apr 2007 21:07:35 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4136SrG000868; Mon, 30 Apr 2007 22:06:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4136Sou000867; Mon, 30 Apr 2007 22:06:28 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 22:06:28 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070501030627.GF21027@Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20070430222835.GA21027@Sun.COM> <200705010032.l410WZqI009012@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705010032.l410WZqI009012@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Tue, May 01, 2007 at 02:32:35AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > Minor status codes are NOT defined! Applications cannot interpret them > > deirectly -- they MUST call gss_display_status() in order to interpret > > them. > > > > But it wouldn't matter if they were defined. Apps that want this new > > feature would not interpret OM_uint32 minor_status values directly. > > Applications hardly interpret them. Portable apps certainly > will never try. The will only visualize to a user. No, users certainly don't ever look at minor status code values! They look at output from gss_display_status(). > Most apps will special case very few of the major_status values, > simply because there will not be programmatic recovery available > anyway--instead user intervention or even admin intervention required. Major status codes are defined, so apps can refer to them symbolically (via C preprocessor defines in the C bindings). > > Oh, but it does. It can provide more context than simple integers can, > > and when the app context object is destroyed the mechanism can also > > release such additional context (whereas pseudo-mechs today cannot > > because their minor status codes may be dynamically established and the > > mechs have no idea when they will no longer be referenced). > > I'm sorry, but I completely fail to understand what you are > referring to. > > If this is about GSS-API v3 with a backwards-incompatible change > to the function signature of gss_display_status, then we should > probably redesign it anyway. I'd rather not. I think you're too quick to say no. I asked you what's wrong with the proposal but you won't say other than asserting this: > If this is about a GSS-API v2 backwards compatible change, then > this possibility simply doesn't exist. The input parameter > to gss_display_status is a 32-bit integer scalar type, there > simply is no pointer value. The mechanism has no means to > recognize relation to previous failed GSS-API calls other > than by the numeric value of that 32-bit integer--you simply > cannot improve it beyond what is there today. In the C bindings the minor_status parameter is always a OM_uint32 *, it is always a pointer. And my proposal doesn't change the type, it's backwards compatible, both for binaries and source. > I have seen gssapi mechanism that keep additional state around > for failed gssapi calls in a pretty useful and fairly robust > fashion. Only by making assumptions about the app's thread model. Oh, I forget, as far as you're concerned the GSS-API and multi-threading don't mix. But to Sun, and, I believe, to MIT, thread-safe GSS matters. > They keep a small ring buffer of dynamically allocated failure messages > for failed gssapi calls and they related by minor_status code only. > If one cares for thread-safety, using a small ring buffer per-thread > might do for that. Cleaning up dynamic thread local storage That won't suffice: it assumes threads don't do GSS work for multiple different peers. In today's world lots of multi-threaded apps don't dedicate a thread to each peer, instead they are async apps that use threads for concurrency. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 30 23:21:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiivW-00040A-TM; Mon, 30 Apr 2007 23:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiivV-0003y2-EE for kitten@ietf.org; Mon, 30 Apr 2007 23:21:17 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiivT-00079U-VR for kitten@ietf.org; Mon, 30 Apr 2007 23:21:17 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l413LFvI006287 for ; Tue, 1 May 2007 03:21:15 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l413LFHv016339 for ; Mon, 30 Apr 2007 21:21:15 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l413K8lp000913; Mon, 30 Apr 2007 22:20:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l413K808000912; Mon, 30 Apr 2007 22:20:08 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Apr 2007 22:20:07 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070501032007.GI21027@Sun.COM> Mail-Followup-To: Martin Rex , Michael B Allen , kitten@ietf.org References: <20070430181105.442ce11c.mba2000@ioplex.com> <200705010124.l411OJrU012456@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705010124.l411OJrU012456@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: kitten@ietf.org Subject: Re: Pluggable GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Tue, May 01, 2007 at 03:24:19AM +0200, Martin Rex wrote: > Michael B Allen wrote: > > All of that would be handled through gss3_{set,get}_param. The api would > > be like how the ldap_* api sets and gets options. > > That is the awful response I expected. > As I said, this approach is extremely OO-impaired, i.e. broken. > > GSS-API is an interface standard, more than it is an on-the-wire > standard. An OO-approach for an API quickly results in myriads > of incompatible proprietary variants (of set/get params), > while the beauty of GSS-API (at least at the C-level) is that > you can easily get a large number of fully interoperable > implementations over many years. We've been doing > binary plug'n'play with ~15 third-party gssapi mechanism > for the last 9 years. You are reaching. The standard is extensible, the protocol aspects of it not nearly as complex as the API itself, and as for the bits on the wire, the API itself defines very little. Also, there is no ABI for the C bindings, and that truly sucks. > > Never heard of that but I'm not suggested that the procedures or semantics > > of any functions or parameters be changed. I'm only suggesting that there > > be a single context in place of the current authentication context and > > proposed application context and that the API I propose take advantage > > of that context by simplifying some parameter management. > > When communicating there are usually two independent streams on > the same connection, one from initiator to acceptor and one in the > opposite direction. If you can communicate in both direction > simultaneously and indepently, it is called full-duplex, > i.e. you might be using two independent threads for reading > and writing on a network socket. > > For GSS-API, the question would be whether parallel calls > (in seperate threads) to message protection (=write) and > message unprotection (=read) on the same gssapi security context handle > should be supported. RPCSEC_GSS depends on it! Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten