From Shawn.Emery@Sun.COM Sun Nov 8 19:06:02 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F8E3A68DB for ; Sun, 8 Nov 2009 19:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.046 X-Spam-Level: X-Spam-Status: No, score=-8.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT0nbV3kJwrJ for ; Sun, 8 Nov 2009 19:06:01 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id BC4C73A689A for ; Sun, 8 Nov 2009 19:06:01 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA936Rhe017872 for ; Mon, 9 Nov 2009 03:06:27 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KST00G00N71OG00@mail-amer.sun.com> for kitten@ietf.org; Sun, 08 Nov 2009 20:06:27 -0700 (MST) Received: from host-19-253.meeting.ietf.org ([unknown] [133.93.19.253]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KST005YONAQ4H40@mail-amer.sun.com> for kitten@ietf.org; Sun, 08 Nov 2009 20:06:27 -0700 (MST) Date: Sun, 08 Nov 2009 20:06:23 -0700 From: "Shawn M. Emery" Subject: [Fwd: WebEx Meeting Invitation: kitten] Sender: Shawn.Emery@Sun.COM To: kitten@ietf.org Message-id: <4AF7872F.8080206@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:06:03 -0000 -------- Original Message -------- Subject: WebEx Meeting Invitation: kitten Date: Sat, 07 Nov 2009 21:24:44 -0800 From: Alexa Morris To: Shawn.Emery@Sun.COM, tlyu@mit.edu CC: Tim Polk , Pasi.Eronen@nokia.com References: <245677589.1257654097214.JavaMail.nobody@jsj2wl001.webex.com> **** You can forward this email invitation to attendees **** Hello , IETF Secretariat invites you to attend this online meeting. Topic: kitten at IETF 76 Date: Wednesday, November 11, 2009 Time: 8:45 am, Japan Time (Tokyo, GMT+09:00) Meeting Number: 960 014 980 Meeting Password: kitten ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=130168692&UID=0&PW=NZjgxODNkZTcy&RT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: kitten 4. Click "Join Now". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=130168692&UID=0&PW=NZjgxODNkZTcy&ORT=MiM0OQ%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:960 014 980 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=130168692&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=ld4h06Gca17cNbbCLy3zVksmQRCc9nOYZn3eH7y19dw=&RT=MiM0OQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From Nicolas.Williams@sun.com Wed Nov 11 10:22:51 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADDE3A6AE0 for ; Wed, 11 Nov 2009 10:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpmtex4VebY8 for ; Wed, 11 Nov 2009 10:22:50 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 08A373A687D for ; Wed, 11 Nov 2009 10:22:50 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABINFE4022964 for ; Wed, 11 Nov 2009 18:23:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABINF84063017 for ; Wed, 11 Nov 2009 11:23:15 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABIBf9n013775 for ; Wed, 11 Nov 2009 12:11:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABIBeZP013774 for kitten@ietf.org; Wed, 11 Nov 2009 12:11:40 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 12:11:40 -0600 From: Nicolas Williams To: kitten@ietf.org Subject: GSS-APIv3 sketch Message-ID: <20091111181140.GC10501@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 18:22:51 -0000 As I mentioned yesterday, I started with a goal of writing a new, model mechglue based on GSS-APIv2u1, with some extensions, and with the "PGSSAPI" idea fully incorporated. For those who don't remember, the PGSSAPI proposal was to add a [non-security] context handle to all GSS functions, and which I'd refined to "turn the minor_context argument into that context handle" proposal. Well, I realized at one point that there were a number of other problems with the GSS-APIv2u1 that I wanted to solve, and that my solutions were less than ideal. For example: memory management, which involved lots of interning of things in my scheme. That led me to consider a close-to- wipe-the-slate approach -- the slate can't be wiped entirely clean, both because the effort to update existing applications of the GSS-API to the new-thing must be minimal, and because protocol aspects of the GSS-API cannot change. Here, then, is my proposal for a GSS-APIv3 (from memory, and not necessarily complete -- it's still a work in progress). My approach to implementation is described below. - Problems to be solved: - memory management - extensibility - credentials limitations - application/instance-specific configuration - error reporting - QoP issues - C-Bindings ABI issues (primarily: remove ABI non-determinism caused by certain aspects of the v2u1 API that are left open to implementors) - At the abstract level the API changes very little: - minor_status indeed becomes a "call context handle" - functions are added to deal with that (more on this below) - this provides for better error reporting - this provides for application-specific mechglue configuration - for portability: a function to get from a call context handle what used to be a discrete minor status number (providers need not support this) - must distinguish between input and output buffers (more on this below) - sundry extensions - including a credential store handle and related functions (more on this below), mechglue/provider configuration control, some amount of reflection, ... - see below - optional output arguments, of functions where an output is not essential and can be obtained via inquiry functions, are eliminated (e.g., context expiration time is no longer output by init/accept_sec_context functions) - extensibility: new flags can be added that are critical or non-critical (see below) - credentials are more set-like objects - add_cred() function is revamped, simplified - it only adds elements to an existing credential - the requirement that desired_name be the same for add_cred() calls that add elements to existing creds is gone - allows for better control over what creds are used for accept_sec_context() - default initiator principal for a credential set can be inquired/set (but this is cred handle-specific -- a credential store's default initiator principal notion is distinct) - see below about credential stores - All existing extensions will be included - C-Bindings: - new symbol/macro prefix name, either gss3_ or gs3_ (capitalized, for macros) - requires C99 - requires uint64_t - all uses of OM_uint32 become uses of uint64_t - for flags arguments, half the word contains critical and legacy flags, while the other half contains non-critical flags - requires that all opaque types be declared as pointers to incomplete structures, and that the opaque types all be distinct (for static type safety) - memory management: - option for simple, single-threaded apps: sec context and per-msg output tokens automatically release when either the next token is output or the sec context is deleted - buffer types: - struct gss3_in_buffer_desc - gss3_in_buffer_t - gss3_out_buffer_t The gss3_out_buffer_t type is opaque, but accessor macros are provided (these may expand to function calls or to casts and derefences; accessor functions provided so one can take their addresses and pass them around, if desired). gss3_release_buffer() releases only output buffers. No more accidentally calling it to release application buffers! (Static type safety ensures this.) (Internally the gss3_out_buffer_t need only track length, value, and provider release function pointer.) - a function to allocate provider-specific input buffers for optimizing context/per-msg input token processing (returned as both, an output buffer, for releasing, and an input buffer, for the app to place tokens into) - think of crypto HW where using a buffer allocated for the purpose can be used to reduce overhead in using the crypto HW (the newest UltraSPARC crypto units support this, for example) - OID, OID set, and output buffer set types - no input buffer set type yet - OID type is opaque - all set types are opaque, manipulated only via functions and accessed only via accessor getter macros/functions - str_to_oid() and oid_to_str() revived - OID description functions are provided, outputting symbol name, the type of thing the OID refers to, stringified OID (with and without arcs resolved to names), description - release_oid() revived (Internally these types need only track count/length, value/elements and provider ops vectors.) - all opaque _objects_ (creds, cred stores, contexts, names, call contexts), but not buffers, OIDs, OID sets, can be duplicated and refcounted. There's a function per-object type to duplicate, and a function per-object type to get an additional reference to an object. The traditional release functions decrement reference counts, destroying the object when the last reference is gone. - minor_status indeed becomes a call context handle (gss3_call_ctx_id_t) - there's a default handle, GSS3_C_DEFAULT_CALL_CONTEXT, that can be duplicated to get a call context handle that refers to the default mechglue/provider configuration - new call contexts can be allocated, with a given configuration file, or with manual mechglue configuration (add provider, add provider, ...) - and these can be duplicated, of course - memory management functions can be specified, if desired - configuration is frozen when one call indicate_mechs() or one of the extended mech inquiry functions - display_status() clearly has more information now - internally the mechglue maintains a cache of provider-specific call contexts in each mechglue call context; this allows providers to track more error/status information in a context-specific manner - on next call to anything other than display_status() or release_call_context() the previous error information is cleared - mechglue vs. provider errors better delineated (there's a mechanism OID for the mechglue itself) - thread safety - v3 API is thread-safe provided that: only one thread is accessing any given object at any given time - for buffers and sets, what matters is destructive calls - security contexts can allow concurrent per-msg token functions if the app requests this (rationale: the mechanism may be able to produce better concurrency than the application could by locking around these functions) - well-defined SPI - the API is the SPI, _mostly_, but there's a function that each provider must provide by which a mechglue above it can configure the provider - among other things, the mechglue passes a dlsym()-like function and handle to providers that providers can use to re-enter the mechglue (for pseudo-mechanisms, such as SPNEGO and stackable mechanisms); re-entrance must be done this way - mechglues can be stacked; this is only interesting for testing purposes, and for accessing providers with a v2u1 interface only (see below) - I've several approaches for the delegated credential issue - credential stores - opaque object - anonymous credential stores (think MEMORY ccache type) can be created at any time - notion of "current credential store" associated with call contexts - a credential store has a notion of "default initiator principal" - external credential stores supported for: process, session, user - a reference to such a cred store can be obtained if it exists - credential stores can be set for a process, session, user, but creation of those things is not provided for (i.e., the API is agnostic as to how processes, sessions, or users are created; a login program still has to create such items in an OS-specific manner) - when the input cred store is anonymous it becomes non-anonymous (think taking a MEMORY ccache and copying it to a FILE ccache) - note: no per-thread stores -- not needed because there's always a call context and call contexts have a "current credential store" notion - optional cred store argument for credential acquisition and credential listing functions (not really needed, but makes API easier to use, I think) - _of course_, there's a store_cred() function - QoP issues fixed - QoP integer argument for per-msg token functions replaced with optional policy names - able to inquire what QoP _policies_ a credential supports - able to set what QoP _policies_ a credential can/must not use - able to inquire what QoP _policies_ a sec context supports - able to set what QoP _policies_ a sec context can/must not use, and what QoP policy is the default for per-msg token functions - policies are named with well-known names with well-known semantics or locally-controllable semantics - Fixed semantics - FIPS-140-2 (fixed semantics) - NIST something or other (fixed semantics) - Fixed relative semantics, but with locally-definable exact semantics - strong (strong algs only) - fast (fast algs only; may or may not be strong) - interop (required-to-implement algs included) - weak (weak algs included) - notweak (same as interop but with weak algs excluded; may not be as strong as 'strong' policy) I.e., sysadmin can say "'strong' means AES enctypes for krb5 mech, ...". - locally-definable policy names (and semantics)? locally- definable policy names complicate the API... - Sundry extensions - I don't remember them all, but... - a per-msg token normalized-to-zero-start sequence number, for mechanisms/sec contexts that can support it (the rationale: apps like RPCSEC_GSS have had to build their own -- what a waste!) Implementation approach: - There's a file format for describing GSS-API functions: - function name, acronym (for internal purposes) - function attributes - versions of the API where the function is present - mechglue core (code can't be generated) or not core (code can be generated) - stackable mech core or not core - whether it deals with call context allocation/release - whether providers include this function (whether to generate function pointer typedef) - function arguments and per-argument attributes - type - input/output (optional, as often this can be inferred) - whether present in v2u1 and/or v3 APIs - ... - function description - header comments - A compiler reads the above and generates: - header file contents: - C function prototypes - file C function pointer typedefs (named _fct) - code: - mechglue core function stubs - mechglue non-core functions, including code - there are several patterns, inferred from function name/attrs and argument list - stackable mechanism core function stubs - "null" stackable mechanism non-core functions, including code - to be used as basis for constructing a variety of stackable mechanisms - there are several patterns, inferred from function name/attrs and argument list - ssh-agent-like shell interface to GSS-API (to make it possible to write most tests as shell scripts!) - compatibility shim code: - v2u1->v3 provider shim (so you can use existing v2u1 mechglues and providers as providers for a v3 mechglue) - v3->v2u1 shim (so you can use a v3 mechglue implementation in v2u1 applications) - this uses interning to solve memory management issues (i.e., output buffers are interned) - documentation: - xml2rfc stubs (including generic abstract and C-bindings argument descriptions + function description supplied in input file); these can be accessed from a larger xml2rfc document as XML entities - POD (or whatever) manpage stubs (including generic abstract and C-bindings argument descriptions + function description supplied in input file, SEE ALSOs, ...) Currently my compiler is written as a ksh script. Ideally the input file should be XML and the compiler would be mostly a collection of XSLT transformations of the input, but I've no clue as to how to write XSLT transforms, so for me ksh it is for now. Also, since I switched to a v3 design mid-stream, my compiler is not entirely updated, and the mechglue core is incomplete and busted. For me this is a weekends-only project, which means it's progressing _slowly_. I intend to ask our legal department for permission to open source this with a permissive license, as I want to have a reference implementation to speed standardization and adoption, but I make no guarantees. There's no IPR here that I know of (I've not applied for any patents covering any aspect of the above; I have described this project to others before; I believe most of this obvious enough). Note too that the above approach can easily be re-purposed to generate a SASL API. I've considered having a SASL-as-GSS API, but there are too many minor impedance mismatches for me to be comfortable with that approach. (The same problem applies to TLS, IMO, though a reasonable subset of TLS/DTLS can be made available as a "non-standard" GSS mechanism, in the GGF way.) Nico -- From Nicolas.Williams@sun.com Wed Nov 11 11:01:21 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1F63A69C0 for ; Wed, 11 Nov 2009 11:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFLpAmvknnkt for ; Wed, 11 Nov 2009 11:01:20 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id BB23F3A6957 for ; Wed, 11 Nov 2009 11:01:20 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABJ1nlA027057 for ; Wed, 11 Nov 2009 19:01:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABJ1mFe024546 for ; Wed, 11 Nov 2009 12:01:48 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABIgjIP013807; Wed, 11 Nov 2009 12:42:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABIgiOq013806; Wed, 11 Nov 2009 12:42:44 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 12:42:44 -0600 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: GSS-APIv3 sketch Message-ID: <20091111184244.GN1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:01:21 -0000 On Wed, Nov 11, 2009 at 10:40:50AM -0800, Love Hörnquist Åstrand wrote: > > I have so many comments that I don't know where to start. > > First out: any work that doesn't include async is dead in the water. Oh, I forgot to mention that. It does include async. > Its not mentioned how this is gss3 objects relates to gss2 object. They are distinct. The compat shims take care of that. > Well-defined SPI will force everything to reimplemnent GSS-API > semantics in all layer, this sucks and duplicates code. No, see the compat shims. From Nicolas.Williams@sun.com Wed Nov 11 11:06:03 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8E63A69E1 for ; Wed, 11 Nov 2009 11:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBcKQnD+IOVh for ; Wed, 11 Nov 2009 11:06:02 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id A488F3A6830 for ; Wed, 11 Nov 2009 11:06:02 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABJ6V5c003437 for ; Wed, 11 Nov 2009 19:06:31 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABJ6UJd028026 for ; Wed, 11 Nov 2009 12:06:30 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABIlRAX013815; Wed, 11 Nov 2009 12:47:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABIlRVw013814; Wed, 11 Nov 2009 12:47:27 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 12:47:27 -0600 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: GSS-APIv3 sketch Message-ID: <20091111184726.GD10501@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20091111184244.GN1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:06:03 -0000 On Wed, Nov 11, 2009 at 12:42:44PM -0600, Nicolas Williams wrote: > On Wed, Nov 11, 2009 at 10:40:50AM -0800, Love Hörnquist Åstrand wrote: > > > > I have so many comments that I don't know where to start. > > > > First out: any work that doesn't include async is dead in the water. > > Oh, I forgot to mention that. It does include async. I should describe it: - The simplest way to do async is: - add a new return code, S_ASYNC_CONTINUE_NEEDED - add a callback, to be set on a call context handle, that will be called (on a different thread) when the suspended function is ready to make progress This requires threads. I don't mind that at all. Any alternative based on poll(2)/select(2)/libevent/kevent/event ports/whatever is going to either be OS-specific or will require a third party event library (e.g., libevent), neither of which seems more appropriate than just requiring threads (note: not POSIX threads, specifically, nor any other specific thread implementation). The same approach of associating callbacks with the call context works for prompter callbacks for dealing with initial credential acquisition. From Nicolas.Williams@sun.com Wed Nov 11 11:14:06 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6593A6825 for ; Wed, 11 Nov 2009 11:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM5df4omuM0j for ; Wed, 11 Nov 2009 11:14:05 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id C75D43A6814 for ; Wed, 11 Nov 2009 11:14:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABJEXQH010545 for ; Wed, 11 Nov 2009 19:14:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABJEXNQ033547 for ; Wed, 11 Nov 2009 12:14:33 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABItTWV013821; Wed, 11 Nov 2009 12:55:29 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABItT18013820; Wed, 11 Nov 2009 12:55:29 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 12:55:29 -0600 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: GSS-APIv3 sketch Message-ID: <20091111185529.GO1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <68453834-10E4-48A2-8147-D26969FF37C9@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68453834-10E4-48A2-8147-D26969FF37C9@apple.com> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:14:06 -0000 On Wed, Nov 11, 2009 at 10:57:30AM -0800, Love Hörnquist Åstrand wrote: > > 11 nov 2009 kl. 10:42 skrev Nicolas Williams: > > > On Wed, Nov 11, 2009 at 10:40:50AM -0800, Love Hörnquist Åstrand wrote: > >> > >> I have so many comments that I don't know where to start. > >> > >> First out: any work that doesn't include async is dead in the water. > > > > Oh, I forgot to mention that. It does include async. > > If the api requires calling sane function serveral times with the same arguments, the API is broken. > > >> Its not mentioned how this is gss3 objects relates to gss2 object. > > > > They are distinct. The compat shims take care of that. > > > >> Well-defined SPI will force everything to reimplemnent GSS-API > >> semantics in all layer, this sucks and duplicates code. > > > > No, see the compat shims. > > That doesn't answer my question, making the SPI look like the API is the problem. Actually, I have options to set the SPI symbol prefix to anything you like, so as long as you don't have additional SPI arguments (as we do in OpenSolaris) you're OK. But ALSO, I did answer your question: providers that don't support he new SPI can be accessed via v2u1 mechglues used through the v3 mechglue (that's what the note about shims was about). From lha@apple.com Wed Nov 11 10:40:15 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30573A69A6 for ; Wed, 11 Nov 2009 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeKFV8s584u1 for ; Wed, 11 Nov 2009 10:40:14 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 0DCEC3A68AD for ; Wed, 11 Nov 2009 10:40:14 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id A3574793E961 for ; Wed, 11 Nov 2009 10:40:42 -0800 (PST) X-AuditID: 11807130-b7b0aae00000102c-61-4afb052a8aa9 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id A1.B6.04140.A250BFA4; Wed, 11 Nov 2009 10:40:42 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from xn--i-a--a-euaf1n.apple.com (xn--i-a--a-euaf1n.apple.com [17.201.27.32]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KSY00E0HJVU6480@et.apple.com> for kitten@ietf.org; Wed, 11 Nov 2009 10:40:42 -0800 (PST) Subject: Re: GSS-APIv3 sketch From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <20091111181140.GC10501@Sun.COM> Date: Wed, 11 Nov 2009 10:40:50 -0800 Message-id: References: <20091111181140.GC10501@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1126) X-Brightmail-Tracker: AAAAAQAAAZE= X-Mailman-Approved-At: Wed, 11 Nov 2009 11:24:47 -0800 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 18:40:15 -0000 I have so many comments that I don't know where to start. First out: any work that doesn't include async is dead in the water. Its not mentioned how this is gss3 objects relates to gss2 object. Well-defined SPI will force everything to reimplemnent GSS-API semantics in all layer, this sucks and duplicates code. Love 11 nov 2009 kl. 10:11 skrev Nicolas Williams: > As I mentioned yesterday, I started with a goal of writing a new, model > mechglue based on GSS-APIv2u1, with some extensions, and with the > "PGSSAPI" idea fully incorporated. For those who don't remember, the > PGSSAPI proposal was to add a [non-security] context handle to all GSS > functions, and which I'd refined to "turn the minor_context argument > into that context handle" proposal. > > Well, I realized at one point that there were a number of other problems > with the GSS-APIv2u1 that I wanted to solve, and that my solutions were > less than ideal. For example: memory management, which involved lots of > interning of things in my scheme. That led me to consider a close-to- > wipe-the-slate approach -- the slate can't be wiped entirely clean, both > because the effort to update existing applications of the GSS-API to the > new-thing must be minimal, and because protocol aspects of the GSS-API > cannot change. > > Here, then, is my proposal for a GSS-APIv3 (from memory, and not > necessarily complete -- it's still a work in progress). My approach to > implementation is described below. > > - Problems to be solved: > > - memory management > - extensibility > - credentials limitations > - application/instance-specific configuration > - error reporting > - QoP issues > - C-Bindings ABI issues (primarily: remove ABI non-determinism > caused by certain aspects of the v2u1 API that are left open to > implementors) > > - At the abstract level the API changes very little: > > - minor_status indeed becomes a "call context handle" > > - functions are added to deal with that (more on this below) > - this provides for better error reporting > - this provides for application-specific mechglue configuration > - for portability: a function to get from a call context handle > what used to be a discrete minor status number (providers need > not support this) > > - must distinguish between input and output buffers (more on this > below) > > - sundry extensions > > - including a credential store handle and related functions (more > on this below), mechglue/provider configuration control, some > amount of reflection, ... > > - see below > > - optional output arguments, of functions where an output is not > essential and can be obtained via inquiry functions, are > eliminated (e.g., context expiration time is no longer output by > init/accept_sec_context functions) > > - extensibility: new flags can be added that are critical or > non-critical (see below) > > - credentials are more set-like objects > - add_cred() function is revamped, simplified > - it only adds elements to an existing credential > - the requirement that desired_name be the same for add_cred() > calls that add elements to existing creds is gone > - allows for better control over what creds are used for > accept_sec_context() > - default initiator principal for a credential set can be > inquired/set (but this is cred handle-specific -- a credential > store's default initiator principal notion is distinct) > - see below about credential stores > > - All existing extensions will be included > > - C-Bindings: > > - new symbol/macro prefix name, either gss3_ or gs3_ (capitalized, > for macros) > > - requires C99 > > - requires uint64_t > > - all uses of OM_uint32 become uses of uint64_t > > - for flags arguments, half the word contains critical and legacy > flags, while the other half contains non-critical flags > > - requires that all opaque types be declared as pointers to > incomplete structures, and that the opaque types all be distinct > (for static type safety) > > - memory management: > > - option for simple, single-threaded apps: sec context and > per-msg output tokens automatically release when either the > next token is output or the sec context is deleted > > - buffer types: > > - struct gss3_in_buffer_desc > - gss3_in_buffer_t > - gss3_out_buffer_t > > The gss3_out_buffer_t type is opaque, but accessor macros are > provided (these may expand to function calls or to casts and > derefences; accessor functions provided so one can take their > addresses and pass them around, if desired). > > gss3_release_buffer() releases only output buffers. No more > accidentally calling it to release application buffers! > (Static type safety ensures this.) > > (Internally the gss3_out_buffer_t need only track length, > value, and provider release function pointer.) > > - a function to allocate provider-specific input buffers for > optimizing context/per-msg input token processing (returned > as both, an output buffer, for releasing, and an input > buffer, for the app to place tokens into) > > - think of crypto HW where using a buffer allocated for the > purpose can be used to reduce overhead in using the > crypto HW (the newest UltraSPARC crypto units support > this, for example) > > - OID, OID set, and output buffer set types > > - no input buffer set type yet > - OID type is opaque > - all set types are opaque, manipulated only via functions and > accessed only via accessor getter macros/functions > > - str_to_oid() and oid_to_str() revived > > - OID description functions are provided, outputting symbol > name, the type of thing the OID refers to, stringified > OID (with and without arcs resolved to names), > description > > - release_oid() revived > > (Internally these types need only track count/length, > value/elements and provider ops vectors.) > > - all opaque _objects_ (creds, cred stores, contexts, names, call > contexts), but not buffers, OIDs, OID sets, can be duplicated and > refcounted. > > There's a function per-object type to duplicate, and a function > per-object type to get an additional reference to an object. The > traditional release functions decrement reference counts, > destroying the object when the last reference is gone. > > - minor_status indeed becomes a call context handle > (gss3_call_ctx_id_t) > > - there's a default handle, GSS3_C_DEFAULT_CALL_CONTEXT, that can > be duplicated to get a call context handle that refers to the > default mechglue/provider configuration > > - new call contexts can be allocated, with a given configuration > file, or with manual mechglue configuration (add provider, add > provider, ...) > > - and these can be duplicated, of course > > - memory management functions can be specified, if desired > > - configuration is frozen when one call indicate_mechs() or one > of the extended mech inquiry functions > > - display_status() clearly has more information now > - internally the mechglue maintains a cache of > provider-specific call contexts in each mechglue call > context; this allows providers to track more error/status > information in a context-specific manner > - on next call to anything other than display_status() or > release_call_context() the previous error information is > cleared > - mechglue vs. provider errors better delineated (there's a > mechanism OID for the mechglue itself) > > - thread safety > > - v3 API is thread-safe provided that: only one thread is > accessing any given object at any given time > > - for buffers and sets, what matters is destructive calls > > - security contexts can allow concurrent per-msg token > functions if the app requests this (rationale: the mechanism > may be able to produce better concurrency than the > application could by locking around these functions) > > - well-defined SPI > > - the API is the SPI, _mostly_, but there's a function that each > provider must provide by which a mechglue above it can > configure the provider > > - among other things, the mechglue passes a dlsym()-like > function and handle to providers that providers can use to > re-enter the mechglue (for pseudo-mechanisms, such as SPNEGO > and stackable mechanisms); re-entrance must be done this way > > - mechglues can be stacked; this is only interesting for testing > purposes, and for accessing providers with a v2u1 interface > only (see below) > > - I've several approaches for the delegated credential issue > > - credential stores > > - opaque object > - anonymous credential stores (think MEMORY ccache type) can be > created at any time > - notion of "current credential store" associated with call > contexts > - a credential store has a notion of "default initiator > principal" > - external credential stores supported for: process, session, > user > - a reference to such a cred store can be obtained if it > exists > - credential stores can be set for a process, session, user, > but creation of those things is not provided for (i.e., the > API is agnostic as to how processes, sessions, or users are > created; a login program still has to create such items in > an OS-specific manner) > - when the input cred store is anonymous it becomes > non-anonymous (think taking a MEMORY ccache and copying > it to a FILE ccache) > - note: no per-thread stores -- not needed because there's > always a call context and call contexts have a "current > credential store" notion > - optional cred store argument for credential acquisition and > credential listing functions (not really needed, but makes API > easier to use, I think) > - _of course_, there's a store_cred() function > > - QoP issues fixed > > - QoP integer argument for per-msg token functions replaced with > optional policy names > - able to inquire what QoP _policies_ a credential supports > - able to set what QoP _policies_ a credential can/must not use > - able to inquire what QoP _policies_ a sec context supports > - able to set what QoP _policies_ a sec context can/must not use, > and what QoP policy is the default for per-msg token functions > - policies are named with well-known names with well-known > semantics or locally-controllable semantics > - Fixed semantics > - FIPS-140-2 (fixed semantics) > - NIST something or other (fixed semantics) > - Fixed relative semantics, but with locally-definable exact > semantics > - strong (strong algs only) > - fast (fast algs only; may or may not be strong) > - interop (required-to-implement algs included) > - weak (weak algs included) > - notweak (same as interop but with weak algs excluded; > may not be as strong as 'strong' policy) > > I.e., sysadmin can say "'strong' means AES enctypes for krb5 > mech, ...". > > - locally-definable policy names (and semantics)? locally- > definable policy names complicate the API... > > - Sundry extensions > - I don't remember them all, but... > - a per-msg token normalized-to-zero-start sequence number, for > mechanisms/sec contexts that can support it (the rationale: > apps like RPCSEC_GSS have had to build their own -- what a > waste!) > > Implementation approach: > > - There's a file format for describing GSS-API functions: > > - function name, acronym (for internal purposes) > - function attributes > - versions of the API where the function is present > - mechglue core (code can't be generated) or not core (code can > be generated) > - stackable mech core or not core > - whether it deals with call context allocation/release > - whether providers include this function (whether to generate > function pointer typedef) > - function arguments and per-argument attributes > - type > - input/output (optional, as often this can be inferred) > - whether present in v2u1 and/or v3 APIs > - ... > - function description > - header comments > > - A compiler reads the above and generates: > > - header file contents: > - C function prototypes > - file C function pointer typedefs (named _fct) > > - code: > - mechglue core function stubs > - mechglue non-core functions, including code > - there are several patterns, inferred from function > name/attrs and argument list > - stackable mechanism core function stubs > - "null" stackable mechanism non-core functions, including code > - to be used as basis for constructing a variety of stackable > mechanisms > - there are several patterns, inferred from function > name/attrs and argument list > - ssh-agent-like shell interface to GSS-API (to make it possible > to write most tests as shell scripts!) > > - compatibility shim code: > - v2u1->v3 provider shim (so you can use existing v2u1 mechglues > and providers as providers for a v3 mechglue) > - v3->v2u1 shim (so you can use a v3 mechglue implementation in > v2u1 applications) > - this uses interning to solve memory management issues (i.e., > output buffers are interned) > > - documentation: > - xml2rfc stubs (including generic abstract and C-bindings > argument descriptions + function description supplied in input > file); these can be accessed from a larger xml2rfc document as > XML entities > - POD (or whatever) manpage stubs (including generic abstract and > C-bindings argument descriptions + function description > supplied in input file, SEE ALSOs, ...) > > Currently my compiler is written as a ksh script. Ideally the input > file should be XML and the compiler would be mostly a collection of XSLT > transformations of the input, but I've no clue as to how to write XSLT > transforms, so for me ksh it is for now. > > Also, since I switched to a v3 design mid-stream, my compiler is not > entirely updated, and the mechglue core is incomplete and busted. > > For me this is a weekends-only project, which means it's progressing > _slowly_. I intend to ask our legal department for permission to open > source this with a permissive license, as I want to have a reference > implementation to speed standardization and adoption, but I make no > guarantees. There's no IPR here that I know of (I've not applied for > any patents covering any aspect of the above; I have described this > project to others before; I believe most of this obvious enough). > > Note too that the above approach can easily be re-purposed to generate a > SASL API. I've considered having a SASL-as-GSS API, but there are too > many minor impedance mismatches for me to be comfortable with that > approach. (The same problem applies to TLS, IMO, though a reasonable > subset of TLS/DTLS can be made available as a "non-standard" GSS > mechanism, in the GGF way.) > > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From lha@apple.com Wed Nov 11 10:56:54 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136543A6863 for ; Wed, 11 Nov 2009 10:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68QEWfppum2O for ; Wed, 11 Nov 2009 10:56:53 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 6B13B3A6AF4 for ; Wed, 11 Nov 2009 10:56:53 -0800 (PST) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 05051793EFE7 for ; Wed, 11 Nov 2009 10:57:22 -0800 (PST) X-AuditID: 11807137-b7bd4ae000000f0d-a9-4afb0911e54f Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id 60.EE.03853.1190BFA4; Wed, 11 Nov 2009 10:57:21 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from xn--i-a--a-euaf1n.apple.com (xn--i-a--a-euaf1n.apple.com [17.201.27.32]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KSY002B0KNLR010@elliott.apple.com> for kitten@ietf.org; Wed, 11 Nov 2009 10:57:21 -0800 (PST) Subject: Re: GSS-APIv3 sketch From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <20091111184244.GN1105@Sun.COM> Date: Wed, 11 Nov 2009 10:57:30 -0800 Content-transfer-encoding: quoted-printable Message-id: <68453834-10E4-48A2-8147-D26969FF37C9@apple.com> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1126) X-Brightmail-Tracker: AAAAAQAAAZE= X-Mailman-Approved-At: Wed, 11 Nov 2009 11:24:47 -0800 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 18:56:54 -0000 11 nov 2009 kl. 10:42 skrev Nicolas Williams: > On Wed, Nov 11, 2009 at 10:40:50AM -0800, Love H=F6rnquist =C5strand = wrote: >>=20 >> I have so many comments that I don't know where to start. >>=20 >> First out: any work that doesn't include async is dead in the water. >=20 > Oh, I forgot to mention that. It does include async. If the api requires calling sane function serveral times with the same = arguments, the API is broken. >> Its not mentioned how this is gss3 objects relates to gss2 object. >=20 > They are distinct. The compat shims take care of that. >=20 >> Well-defined SPI will force everything to reimplemnent GSS-API >> semantics in all layer, this sucks and duplicates code. >=20 > No, see the compat shims. That doesn't answer my question, making the SPI look like the API is the = problem. Love From Nicolas.Williams@sun.com Wed Nov 11 11:25:07 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4773A6781 for ; Wed, 11 Nov 2009 11:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLNt6YhEwkTd for ; Wed, 11 Nov 2009 11:25:06 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id D657A3A66B4 for ; Wed, 11 Nov 2009 11:25:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABJPYY1015082 for ; Wed, 11 Nov 2009 19:25:34 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABJPXix041442 for ; Wed, 11 Nov 2009 12:25:34 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABJ6UT5013830; Wed, 11 Nov 2009 13:06:30 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABJ6UgC013829; Wed, 11 Nov 2009 13:06:30 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 13:06:30 -0600 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: GSS-APIv3 sketch Message-ID: <20091111190629.GE10501@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <68453834-10E4-48A2-8147-D26969FF37C9@apple.com> <20091111185529.GO1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20091111185529.GO1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:25:07 -0000 On Wed, Nov 11, 2009 at 12:55:29PM -0600, Nicolas Williams wrote: > On Wed, Nov 11, 2009 at 10:57:30AM -0800, Love Hörnquist Åstrand wrote: > > That doesn't answer my question, making the SPI look like the API is the problem. > > Actually, I have options to set the SPI symbol prefix to anything you > like, so as long as you don't have additional SPI arguments (as we do in > OpenSolaris) you're OK. But ALSO, I did answer your question: providers > that don't support he new SPI can be accessed via v2u1 mechglues used > through the v3 mechglue (that's what the note about shims was about). I should add too that this is how I plan to test the mechglue, since I don't intend to port any existing providers to this SPI: - configure a v3 call context to use a v2u1 mechglue as a provider - add stackable mechanism providers (to excercise the v3 SPI) - test Also, my plan is to mix OpenSolaris and MIT mechglues to access different mechanism providers indirectly: - configure a v3 call context to use the OpenSolaris v2u1 mechglue as a provide mech_dh - add the MIT v2u1 mechglue (compiled to have the same ABI as the OpenSolaris one) as a provider to provide mech_krb5 - add stackable mechanism providers (to excercise the v3 SPI) - test Nico -- From jhutz@cmu.edu Wed Nov 11 11:41:05 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5013A681A for ; Wed, 11 Nov 2009 11:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cuvl1QeW3buA for ; Wed, 11 Nov 2009 11:41:04 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 700EB3A67C0 for ; Wed, 11 Nov 2009 11:41:04 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nABJfSWq022518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Nov 2009 14:41:28 -0500 (EST) Date: Wed, 11 Nov 2009 14:41:27 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , =?UTF-8?Q?Love_H=C3=B6rnquist_=C3=85strand?= Subject: Re: GSS-APIv3 sketch Message-ID: <68143B6DDFEB5DEDE9738772@minbar.fac.cs.cmu.edu> In-Reply-To: <23095_1257966878_nABJEb0J026813_20091111185529.GO1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <68453834-10E4-48A2-8147-D26969FF37C9@apple.com> <23095_1257966878_nABJEb0J026813_20091111185529.GO1105@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:41:05 -0000 --On Wednesday, November 11, 2009 12:55:29 PM -0600 Nicolas Williams wrote: >> >> Well-defined SPI will force everything to reimplemnent GSS-API >> >> semantics in all layer, this sucks and duplicates code. >> > >> > No, see the compat shims. >> >> That doesn't answer my question, making the SPI look like the API is the >> problem. > > Actually, I have options to set the SPI symbol prefix to anything you > like, so as long as you don't have additional SPI arguments (as we do in > OpenSolaris) you're OK. But ALSO, I did answer your question: providers > that don't support he new SPI can be accessed via v2u1 mechglues used > through the v3 mechglue (that's what the note about shims was about). I think you're missing Love's point. Regardless of what the symbol names are, if the API and SPI are the same, then both the mechglue and each mechanism have to implement all of the semantics of that interface. That was sort of necessary with GSSAPIv2, because the mechglue concept was introduced after the original API design, which envisioned selecting a mechanism at link time. Now that we understand how silly that is, there's no reason to presume that anyone will link to a GSSAPIv3 mechanism provider directly, and so the API and SPI need not be the same. From Nicolas.Williams@sun.com Wed Nov 11 12:40:24 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7781E3A6879 for ; Wed, 11 Nov 2009 12:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFgQrf3sTCJ7 for ; Wed, 11 Nov 2009 12:40:23 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 776223A684A for ; Wed, 11 Nov 2009 12:40:23 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABKeZ2R027094 for ; Wed, 11 Nov 2009 20:40:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABKeZ9F026526 for ; Wed, 11 Nov 2009 13:40:35 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABKE1p5013858; Wed, 11 Nov 2009 14:14:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABKE1qc013857; Wed, 11 Nov 2009 14:14:01 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 14:14:01 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: GSS-APIv3 sketch Message-ID: <20091111201400.GP1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <68453834-10E4-48A2-8147-D26969FF37C9@apple.com> <23095_1257966878_nABJEb0J026813_20091111185529.GO1105@Sun.COM> <68143B6DDFEB5DEDE9738772@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68143B6DDFEB5DEDE9738772@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:40:24 -0000 On Wed, Nov 11, 2009 at 02:41:27PM -0500, Jeffrey Hutzelman wrote: > --On Wednesday, November 11, 2009 12:55:29 PM -0600 Nicolas Williams > wrote: > > >>>> Well-defined SPI will force everything to reimplemnent GSS-API > >>>> semantics in all layer, this sucks and duplicates code. > >>> > >>> No, see the compat shims. > >> > >>That doesn't answer my question, making the SPI look like the API is the > >>problem. > > > >Actually, I have options to set the SPI symbol prefix to anything you > >like, so as long as you don't have additional SPI arguments (as we do in > >OpenSolaris) you're OK. But ALSO, I did answer your question: providers > >that don't support he new SPI can be accessed via v2u1 mechglues used > >through the v3 mechglue (that's what the note about shims was about). > > I think you're missing Love's point. Regardless of what the symbol names > are, if the API and SPI are the same, then both the mechglue and each > mechanism have to implement all of the semantics of that interface. That > was sort of necessary with GSSAPIv2, because the mechglue concept was > introduced after the original API design, which envisioned selecting a > mechanism at link time. Now that we understand how silly that is, there's > no reason to presume that anyone will link to a GSSAPIv3 mechanism provider > directly, and so the API and SPI need not be the same. I didn't say the SPI is exactly the same as the API. I said "mostly". The reason for the two to be mostly the same is simple: I can't think of why I'd want the SPI to be radically different than the API, that is, I haven't found an implementation reason for wanting the SPI to be radically different than the API. In fact, having them be at least very similar helps make the code generation approach possible. For example, suppose I created a single SPI function interface to all per-message token functions -- I sure could, but then the code generator would have to learn all the specific details of how to map per-msg token API functions onto that one SPI function, thus negating the whole point of a code generator approach. Let's look at possible SPI departures from the API: - symbol prefixes -- easy to handle - extra arguments, as in the OpenSolaris SPI (which is not open) - I don't see a need for such extra arguments, but as long as the pattern is regular, it can be easily handled - instead of using dlopen()/dlsym() you call a function that returns a struct full of function pointers -- easy to handle - I also forgot to mention that the mechglue configuration interface allows you do implement statically-linked providers if you want - radical departures from the API, such as merging API functions at the SPI layer -- NOT easy to handle - gratuitous departures, such as different argument ordering -- why bother?? - other departures?? Nico -- From Nicolas.Williams@sun.com Wed Nov 11 12:45:34 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC693A68EE for ; Wed, 11 Nov 2009 12:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oozhTxBwjxwt for ; Wed, 11 Nov 2009 12:45:33 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id AC5833A684A for ; Wed, 11 Nov 2009 12:45:33 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABKk2uV012717 for ; Wed, 11 Nov 2009 20:46:02 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABKk10Z029901 for ; Wed, 11 Nov 2009 13:46:01 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABKYSUs013868 for ; Wed, 11 Nov 2009 14:34:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABKYS3o013867 for kitten@ietf.org; Wed, 11 Nov 2009 14:34:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 14:34:28 -0600 From: Nicolas Williams To: kitten@ietf.org Subject: Re: GSS-APIv3 sketch Message-ID: <20091111203428.GF10501@Sun.COM> References: <20091111181140.GC10501@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091111181140.GC10501@Sun.COM> User-Agent: Mutt/1.5.7i X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:45:34 -0000 On Wed, Nov 11, 2009 at 12:11:40PM -0600, Nicolas Williams wrote: > - the API is the SPI, _mostly_, but there's a function that each > provider must provide by which a mechglue above it can > configure the provider > > - among other things, [...] To be clear, the SPI is not exactly the API, and my description of the differences between the two was not intended to be complete ("among other things, ..."). Besides the differences I pointed out in the original and follow-ups, it's reasonable to have some slight semantic differences, such as: a provider not providing async support, with the mechglue invoking the provider on a helper thread so as to layer async support above it (Jeff's suggestion), or a provider not providing per-msg token concurrency but the mechglue providing it on the provider's behalf. There may be other differences, but the point stands: the SPI will be _mostly_ the same as the API. The rationale is as given in one of those follow-ups: the more similar the two, the easier it is to generate mechglue code, plus, there's no obvious reason to want the two interfaces to diverge in more than minor ways. But if someone has any reasons to want the two interfaces to diverge radically, I'd love to hear them. Nico -- From Nicolas.Williams@sun.com Wed Nov 11 13:57:18 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFCC3A6864 for ; Wed, 11 Nov 2009 13:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL4eHC7NPNVP for ; Wed, 11 Nov 2009 13:57:17 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id AC79C3A6856 for ; Wed, 11 Nov 2009 13:57:17 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABLvRZl028744 for ; Wed, 11 Nov 2009 21:57:39 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABLvRH6011539 for ; Wed, 11 Nov 2009 14:57:27 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABLjspw013996 for ; Wed, 11 Nov 2009 15:45:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABLjsgU013995 for kitten@ietf.org; Wed, 11 Nov 2009 15:45:54 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 15:45:54 -0600 From: Nicolas Williams To: kitten@ietf.org Subject: Re: GSS-APIv3 sketch Message-ID: <20091111214553.GG10501@Sun.COM> References: <20091111181140.GC10501@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091111181140.GC10501@Sun.COM> User-Agent: Mutt/1.5.7i X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 21:57:18 -0000 I did forget to mention a variety of other things, one of them is: - The code generator will also generate marshall/unmarshall code for encoding function calls and results for proxying over sockets/doors/... This is necessary for the agent-like shell interface to the GSS-API. It's also useful for things like kgssapi/gssd interfaces. It's also useful for doing some privilege separation kinds of things. In particular it's useful for a stackable mechanism I've in mind that authenticates _two_ initiator principals to a single target acceptor principal. It's also useful for GSS-API credentials forwarding ala ssh-agent forwarding. Yes, I should look at my notes and produce the full list of things I've already got code or comments for. I left them at home :( Nico -- From abartlet@samba.org Wed Nov 11 14:59:04 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672AD3A6890 for ; Wed, 11 Nov 2009 14:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Fd9c6RP4Al for ; Wed, 11 Nov 2009 14:59:03 -0800 (PST) Received: from lists.samba.org (fn.samba.org [216.83.154.106]) by core3.amsl.com (Postfix) with ESMTP id 23B8B3A6B62 for ; Wed, 11 Nov 2009 14:59:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id A385AAD21A; Wed, 11 Nov 2009 15:57:13 -0700 (MST) Subject: Re: GSS-APIv3 sketch From: Andrew Bartlett To: Nicolas Williams In-Reply-To: <20091111184726.GD10501@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d8uYpG+vdxVUYuOH/tzb" Date: Thu, 12 Nov 2009 09:59:26 +1100 Message-Id: <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Cc: "kitten@ietf.org" , vl , Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 22:59:04 -0000 --=-d8uYpG+vdxVUYuOH/tzb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2009-11-11 at 12:47 -0600, Nicolas Williams wrote: > On Wed, Nov 11, 2009 at 12:42:44PM -0600, Nicolas Williams wrote: > > On Wed, Nov 11, 2009 at 10:40:50AM -0800, Love H=C3=B6rnquist =C3=85str= and wrote: > > >=20 > > > I have so many comments that I don't know where to start. > > >=20 > > > First out: any work that doesn't include async is dead in the water. > >=20 > > Oh, I forgot to mention that. It does include async. >=20 > I should describe it: >=20 > - The simplest way to do async is: >=20 > - add a new return code, S_ASYNC_CONTINUE_NEEDED > - add a callback, to be set on a call context handle, that will be > called (on a different thread) when the suspended function is > ready to make progress >=20 > This requires threads. I don't mind that at all. Any alternative > based on poll(2)/select(2)/libevent/kevent/event ports/whatever is > going to either be OS-specific or will require a third party event > library (e.g., libevent), neither of which seems more appropriate > than just requiring threads (note: not POSIX threads, specifically, > nor any other specific thread implementation). >=20 > The same approach of associating callbacks with the call context works > for prompter callbacks for dealing with initial credential acquisition. I'm hoping that Volker or Metze (CC'ed async experts on the Samba Team) can fill out some more detail, but I'll start by nothing that anything that requires threads, or causes the library to start threads is a non-starter for Samba. =20 Creating threads behind the applications' back is a really bad idea.=20 We really need a proper state machine, with integration available into our event library (or any other the event library the caller provides). =20 As to portability, if no event lib is provided by the caller, then just block like GSSAPI does at the moment. =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-d8uYpG+vdxVUYuOH/tzb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBK+0HOz4A8Wyi0NrsRAmXYAJ45G7y3we9VrQDV32xM6renNHPuuQCeLfn8 aWXXah16DGnecrtr7n/9rSg= =Acvv -----END PGP SIGNATURE----- --=-d8uYpG+vdxVUYuOH/tzb-- From Volker.Lendecke@SerNet.DE Wed Nov 11 15:06:40 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F933A6929 for ; Wed, 11 Nov 2009 15:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkqagPONgydo for ; Wed, 11 Nov 2009 15:06:38 -0800 (PST) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id E7A5F3A68FC for ; Wed, 11 Nov 2009 15:06:37 -0800 (PST) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8MHG-0003bQ-5S; Thu, 12 Nov 2009 00:07:02 +0100 Received: by intern.SerNet.DE id 1N8MHF-004jYm-T7; Thu, 12 Nov 2009 00:07:02 +0100 Received: by intern.SerNet.DE id 1N8MHF-004jYU-K6; Thu, 12 Nov 2009 00:07:01 +0100 Date: Thu, 12 Nov 2009 00:08:50 +0100 From: Volker Lendecke To: Andrew Bartlett Subject: Re: GSS-APIv3 sketch References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> User-Agent: Mutt/1.5.18 (2008-05-17) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "kitten@ietf.org" , vl , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:06:40 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2009 at 09:59:26AM +1100, Andrew Bartlett wrote: > > The same approach of associating callbacks with the call context works > > for prompter callbacks for dealing with initial credential acquisition. >=20 > I'm hoping that Volker or Metze (CC'ed async experts on the Samba Team) > can fill out some more detail, but I'll start by nothing that anything > that requires threads, or causes the library to start threads is a > non-starter for Samba. =20 >=20 > Creating threads behind the applications' back is a really bad idea.=20 >=20 > We really need a proper state machine, with integration available into > our event library (or any other the event library the caller > provides). =20 >=20 > As to portability, if no event lib is provided by the caller, then just > block like GSSAPI does at the moment. =20 Just to confirm: Samba and probably other applications really need an async gensec without threads. I've very recently seen a talk by a SUN engineer talking about doing threads behind an app's back. This really, really nasty stuff. For a possible model how to do the async API, I would suggest looking at the avahi libraries: http://avahi.org/download/doxygen/struct_avahi_poll.html Writing an async state machine is definitely a non-trivial task, but it is possible given the right infrastructure. In Samba, it has taken us several iterations to come up with something that makes state machines relatively easy to do. Unfortunately it heavily depends on our hierarchical memory allocator called talloc. Without such a thing, memory management can very quickly become a real nightmare. Volker --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkr7RAAACgkQbZMKAi3WUknLYQCgkVcDAyNjfAav7fU2nZoGPmrH LlIAn2a8QkT2Vi5jivbJT8z5q1AAFI5Q =3y36 -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From Nicolas.Williams@sun.com Wed Nov 11 15:19:23 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C247C3A696C for ; Wed, 11 Nov 2009 15:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9R8Qi+9nDTb for ; Wed, 11 Nov 2009 15:19:23 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 098403A67F1 for ; Wed, 11 Nov 2009 15:19:23 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABNJnIM018385 for ; Wed, 11 Nov 2009 23:19:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABNJnWk064801 for ; Wed, 11 Nov 2009 16:19:49 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABN0kWM014516; Wed, 11 Nov 2009 17:00:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABN0jR7014515; Wed, 11 Nov 2009 17:00:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 17:00:45 -0600 From: Nicolas Williams To: Andrew Bartlett Subject: Re: GSS-APIv3 sketch Message-ID: <20091111230044.GW1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , vl , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:19:23 -0000 On Thu, Nov 12, 2009 at 09:59:26AM +1100, Andrew Bartlett wrote: > I'm hoping that Volker or Metze (CC'ed async experts on the Samba Team) > can fill out some more detail, but I'll start by nothing that anything > that requires threads, or causes the library to start threads is a > non-starter for Samba. > > Creating threads behind the applications' back is a really bad idea. In the Solaris unified process model this can just happen. That is, libraries are free to create worker threads. > We really need a proper state machine, with integration available into > our event library (or any other the event library the caller > provides). That's much more work, and much less portable, and much more OS-/event- API-specific. I'm speaking here from a standardization point of view. (In fact, using libevent would result in reasonably portable interfaces, certainly across all Unix, Linux, and BSD type operating systems. But that's beside the point that I'm making.) I think implementations could certainly have such interfaces, but I think we'd not standardize them here. Nico -- From Nicolas.Williams@sun.com Wed Nov 11 15:23:21 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BD03A6890 for ; Wed, 11 Nov 2009 15:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWiDcQO2rUPW for ; Wed, 11 Nov 2009 15:23:20 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 6ACFE3A67F1 for ; Wed, 11 Nov 2009 15:23:20 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABNNkpx006929 for ; Wed, 11 Nov 2009 23:23:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABNNkUN001550 for ; Wed, 11 Nov 2009 16:23:46 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABN4hqo014536; Wed, 11 Nov 2009 17:04:43 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABN4gwf014535; Wed, 11 Nov 2009 17:04:42 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 17:04:42 -0600 From: Nicolas Williams To: Volker Lendecke Subject: Re: GSS-APIv3 sketch Message-ID: <20091111230442.GY1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , vl , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:23:21 -0000 On Thu, Nov 12, 2009 at 12:08:50AM +0100, Volker Lendecke wrote: > > I'm hoping that Volker or Metze (CC'ed async experts on the Samba Team) > > can fill out some more detail, but I'll start by nothing that anything > > that requires threads, or causes the library to start threads is a > > non-starter for Samba. > > > > Creating threads behind the applications' back is a really bad idea. > > > > We really need a proper state machine, with integration available into > > our event library (or any other the event library the caller > > provides). > > > > As to portability, if no event lib is provided by the caller, then just > > block like GSSAPI does at the moment. > > Just to confirm: Samba and probably other applications > really need an async gensec without threads. I've very > recently seen a talk by a SUN engineer talking about doing > threads behind an app's back. This really, really nasty > stuff. I'd like to hear more about this. Can you please describe the problem with libraries creating worker threads? You can use private e-mail if you wish. References to bug reports would be great. Nico -- From Nicolas.Williams@sun.com Wed Nov 11 15:38:42 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2473A6B68 for ; Wed, 11 Nov 2009 15:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7pdQPBP30ys for ; Wed, 11 Nov 2009 15:38:41 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id B89963A68FC for ; Wed, 11 Nov 2009 15:38:41 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABNdAFo026797 for ; Wed, 11 Nov 2009 23:39:10 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABNdAnh027658 for ; Wed, 11 Nov 2009 16:39:10 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABNK7jJ014587; Wed, 11 Nov 2009 17:20:07 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABNK72Z014586; Wed, 11 Nov 2009 17:20:07 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Nov 2009 17:20:07 -0600 From: Nicolas Williams To: Andrew Bartlett Subject: Re: GSS-APIv3 sketch Message-ID: <20091111232007.GI10501@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230044.GW1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091111230044.GW1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , vl , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:38:42 -0000 On Wed, Nov 11, 2009 at 05:00:45PM -0600, Nicolas Williams wrote: > I think implementations could certainly have such interfaces, but I > think we'd not standardize them here. On second thought, I think we could do non-threaded async APIs as separate RFCs, one for each event interface. We might end up with only one: libevent. One sketch: - app calls set_async_XYZ() on a call context handle to register XYZ-specific event loops - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED - app calls init/accept_sec_context() again when a related event is posted Another: - app calls set_async_XYZ() on a call context handle to indicate the desire to do XYZ-specific async calls - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED - app calls get_async_XYZ() on the call context handle to get XYZ-specific event descriptions that the app then handles in an XYZ-specific way - app calls init/accept_sec_context() again when a related event is posted Nico -- From Volker.Lendecke@SerNet.DE Wed Nov 11 23:17:57 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2273A69B3 for ; Wed, 11 Nov 2009 23:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkpgyRZKV33t for ; Wed, 11 Nov 2009 23:17:56 -0800 (PST) Received: from mail.SerNet.de (mail.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 4AEB23A6853 for ; Wed, 11 Nov 2009 23:17:55 -0800 (PST) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8Twi-0003HU-Un; Thu, 12 Nov 2009 08:18:20 +0100 Received: by intern.SerNet.DE id 1N8Twh-0057MW-SY; Thu, 12 Nov 2009 08:18:20 +0100 Received: by intern.SerNet.DE id 1N8Twh-0057MC-5g; Thu, 12 Nov 2009 08:18:19 +0100 Date: Thu, 12 Nov 2009 08:20:18 +0100 From: Volker Lendecke To: Nicolas Williams Subject: Re: GSS-APIv3 sketch References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <20091111230442.GY1105@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 07:17:57 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 11, 2009 at 05:04:42PM -0600, Nicolas Williams wrote: > I'd like to hear more about this. Can you please describe the problem > with libraries creating worker threads? You can use private e-mail if > you wish. References to bug reports would be great. The most nasty implications come from initialization and =66rom fork. If you have several libraries doing threads, it is easy for unsuspecting applications creating races. The worst one is fork: You have to shut down all threads before the fork and potentially re-start them after it, because you need to drop all locks/mutexes/etc during the fork. If needed, I can try to contact the author and get his slides Volker --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkr7tzEACgkQbZMKAi3WUknHzACfemQsdX7Q7uvwQBuo6JfZdcBO XIwAn06/6bhPi8furdO/GQEZYSxeUN/v =6ZCO -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From metze@samba.org Thu Nov 12 04:03:38 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666343A681D for ; Thu, 12 Nov 2009 04:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkdI49wrp83f for ; Thu, 12 Nov 2009 04:03:37 -0800 (PST) Received: from mail.mx-netz.de (ip-217-172-181-76.mx-netz.de [217.172.181.76]) by core3.amsl.com (Postfix) with ESMTP id 6133E3A6818 for ; Thu, 12 Nov 2009 04:03:36 -0800 (PST) Received: from [172.30.76.9] (unknown [172.30.76.9]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (SASL METHOD:[PLAIN] USERNAME:[metze]) by mail.mx-netz.de (SMTP-MAIL-SERVER) with ESMTP id 1C9B720C554; Thu, 12 Nov 2009 13:04:01 +0100 (CET) Message-ID: <4AFBF9A5.7040209@samba.org> Date: Thu, 12 Nov 2009 13:03:49 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: GSS-APIv3 sketch References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230044.GW1105@Sun.COM> <20091111232007.GI10501@Sun.COM> In-Reply-To: <20091111232007.GI10501@Sun.COM> X-Enigmail-Version: 0.95.7 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA682073F2BB7555BEF76C324" Cc: "kitten@ietf.org" , vl , =?ISO-8859-1?Q?Love_H=F6rnqui?= =?ISO-8859-1?Q?st_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 12:03:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA682073F2BB7555BEF76C324 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Nicolas Williams schrieb: > On Wed, Nov 11, 2009 at 05:00:45PM -0600, Nicolas Williams wrote: >> I think implementations could certainly have such interfaces, but I >> think we'd not standardize them here. >=20 > On second thought, I think we could do non-threaded async APIs as > separate RFCs, one for each event interface. We might end up with only= > one: libevent. >=20 > One sketch: >=20 > - app calls set_async_XYZ() on a call context handle to register > XYZ-specific event loops > - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED > - app calls init/accept_sec_context() again when a related event is > posted >=20 > Another: >=20 > - app calls set_async_XYZ() on a call context handle to indicate the > desire to do XYZ-specific async calls > - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED > - app calls get_async_XYZ() on the call context handle to get > XYZ-specific event descriptions that the app then handles in an > XYZ-specific way > - app calls init/accept_sec_context() again when a related event is > posted I think such models could nicely work from the callers view. But init/accept_sec_context() should only return A_ASYNC_CONTINUE_NEEDED once! And the caller gets only notified when the function has completed, so that the caller can get the result. The main remaining problem has to do with the mech implementations, they need an api to register different types of events. Think about this: A system has a libgssv3.so with mechglue code and a few mech implementations by different vendors. Then some application wants to use libevent with the libgssv3.so. On the same box samba wants to use it's tevent library with libgssv3.so. And a third application wants to use the glib event code with libgssv3.so. The mech implementations should work in all 3 cases without knowledge about the specific event system. metze --------------enigA682073F2BB7555BEF76C324 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr7+a0ACgkQm70gjA5TCD97YgCfc3pcr1gQsb6CoJrH9pOzyFLU AuUAoLtNht7MoRgQ9YBZNAUcfBPaLlNF =iaCs -----END PGP SIGNATURE----- --------------enigA682073F2BB7555BEF76C324-- From Nicolas.Williams@sun.com Thu Nov 12 09:22:44 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DB83A6BB4 for ; Thu, 12 Nov 2009 09:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWt2FqtJMzWK for ; Thu, 12 Nov 2009 09:22:43 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 414903A6AF2 for ; Thu, 12 Nov 2009 09:22:43 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nACHNB8m027622 for ; Thu, 12 Nov 2009 17:23:11 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nACHNAfj015765 for ; Thu, 12 Nov 2009 10:23:10 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACH44u4015015; Thu, 12 Nov 2009 11:04:04 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACH43Bl015014; Thu, 12 Nov 2009 11:04:03 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 11:04:03 -0600 From: Nicolas Williams To: Volker Lendecke Subject: Re: GSS-APIv3 sketch Message-ID: <20091112170403.GB1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@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 Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 17:22:44 -0000 On Thu, Nov 12, 2009 at 08:20:18AM +0100, Volker Lendecke wrote: > On Wed, Nov 11, 2009 at 05:04:42PM -0600, Nicolas Williams wrote: > > I'd like to hear more about this. Can you please describe the problem > > with libraries creating worker threads? You can use private e-mail if > > you wish. References to bug reports would be great. > > The most nasty implications come from initialization and > from fork. If you have several libraries doing threads, it > is easy for unsuspecting applications creating races. The > worst one is fork: You have to shut down all threads before > the fork and potentially re-start them after it, because you > need to drop all locks/mutexes/etc during the fork. If > needed, I can try to contact the author and get his slides I'd love to see that, please :) OpenSolaris' fork() == fork1(), and it has forkx(2) for libraries. forkx(2) allows library-forked child procs to not interfere with the application running in the parent, e.g., by not triggering SIGCHLD and not showing up in plain wait(3C) calls. And libraries in OpenSolaris that create worker threads take care to use pthread_atfork() and atexit() handlers to do fork/exit cleanup. Of course, pthread_atfork() and atexit() are standard functions... Libraries on Linux should use them too. If there are issues in OpenSolaris (apologies to the list) about this, I really want to hear about them, because we need to make sure they are addressed if it's at all possible. I also care to hear about issues on Linux and *BSD though (I do some development on Linux, but mostly I want to be informed). Nico -- From lha@apple.com Thu Nov 12 10:51:30 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDB83A6AB9 for ; Thu, 12 Nov 2009 10:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.067 X-Spam-Level: X-Spam-Status: No, score=-103.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ+qCJzzLt83 for ; Thu, 12 Nov 2009 10:51:29 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B498F3A6A14 for ; Thu, 12 Nov 2009 10:51:29 -0800 (PST) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 750F07F1E68B for ; Thu, 12 Nov 2009 10:51:58 -0800 (PST) X-AuditID: 11807137-b7bd4ae000000f0d-5b-4afc594e8c8f Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id CC.9D.03853.E495CFA4; Thu, 12 Nov 2009 10:51:58 -0800 (PST) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_mjJoBOjBw0YAAlI77VxBJQ)" Received: from [10.0.1.8] (99-52-202-108.lightspeed.snjsca.sbcglobal.net [99.52.202.108]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KT000G27F2LDJ50@elliott.apple.com> for kitten@ietf.org; Thu, 12 Nov 2009 10:51:58 -0800 (PST) Subject: Re: GSS-APIv3 sketch From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <20091112170403.GB1105@Sun.COM> Date: Thu, 12 Nov 2009 10:52:03 -0800 Message-id: References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1126) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" , Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:51:30 -0000 --Boundary_(ID_mjJoBOjBw0YAAlI77VxBJQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 12 nov 2009 kl. 09:04 skrev Nicolas Williams: > I'd love to see that, please :) http://www.opengroup.org/onlinepubs/009695399/functions/fork.html "A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. [THR] --Boundary_(ID_mjJoBOjBw0YAAlI77VxBJQ) Content-type: image/gif; name=opt-start.gif Content-transfer-encoding: base64 Content-disposition: inline; filename=opt-start.gif R0lGODlhDwALAIAAAAAAAPj8+CH5BAEAAAEALAAAAAAPAAsAQAIcjI8ZoMcOH1zNSGrxrA34DyaP RG4awowbCbZIAQA7 --Boundary_(ID_mjJoBOjBw0YAAlI77VxBJQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Fork handlers may be established by means of the pthread_atfork()function in order to maintain application invariants across fork() calls." Does libc regiester all mutexes it uses with pthread_atfork() so malloc will continue to work ? As long as all libraries doesn't you pthread_atfork() you are dead. Fork-and-not-do-exec is dead concept in multi threaded apps. Love --Boundary_(ID_mjJoBOjBw0YAAlI77VxBJQ)-- From Volker.Lendecke@SerNet.DE Thu Nov 12 10:54:31 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE2F3A6B17 for ; Thu, 12 Nov 2009 10:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsLVKqo2CSge for ; Thu, 12 Nov 2009 10:54:30 -0800 (PST) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 2D3563A683A for ; Thu, 12 Nov 2009 10:54:30 -0800 (PST) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8eoq-0007pG-TN; Thu, 12 Nov 2009 19:54:56 +0100 Received: by intern.SerNet.DE id 1N8eoq-006pRQ-LY; Thu, 12 Nov 2009 19:54:56 +0100 Received: by intern.SerNet.DE id 1N8eoq-006pR9-HF; Thu, 12 Nov 2009 19:54:56 +0100 Date: Thu, 12 Nov 2009 19:54:56 +0100 From: Volker Lendecke To: Nicolas Williams Subject: Re: GSS-APIv3 sketch References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <20091112170403.GB1105@Sun.COM> User-Agent: Mutt/1.5.9i Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:54:31 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2009 at 11:04:03AM -0600, Nicolas Williams wrote: > I'd love to see that, please :) It was a talk at the OpenSolaris developer conference in Dresden a couple of weeks ago: http://www.osdevcon.org/2009/program_detail.html#zdenek > OpenSolaris' fork() =3D=3D fork1(), and it has forkx(2) for libraries. > forkx(2) allows library-forked child procs to not interfere with the > application running in the parent, e.g., by not triggering SIGCHLD and > not showing up in plain wait(3C) calls. And libraries in OpenSolaris > that create worker threads take care to use pthread_atfork() and > atexit() handlers to do fork/exit cleanup. >=20 > Of course, pthread_atfork() and atexit() are standard functions... > Libraries on Linux should use them too. Yes, sure. It is all possible and doable. But I am just scared by its complexity. Race conditions and deadlocks can stay undetected for very long and if they happen they can turn out to be very hard to reproduce and fix. But that might be just me. I know event-based programming has its own quirks and complexities, but at least you can the programs under a debugger. > If there are issues in OpenSolaris (apologies to the list) about this, I > really want to hear about them, because we need to make sure they are > addressed if it's at all possible. I also care to hear about issues on > Linux and *BSD though (I do some development on Linux, but mostly I want > to be informed). There were no special Solaris issues mentioned. All standard pthreads stuff. The author (interestingly a SUN employee) talked about Solaris crypto libraries having issues, but he mostly used them as examples from his own experience fixing threaded libs. The problems he mentioned however were pretty generic. Let me point out another thing: By using threads and a purely blocking API, you force everyone into threads. If you do it async, it is very easy to create blocking wrappers around the async calls which then can be used in threaded programs. The other way round is a lot harder. Volker --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFK/Fn/bZMKAi3WUkkRAovaAJ9lUbdlpwLuDeES6JjplWzOtWfuZQCeMgSV Ro85V1n0J+RQB13+ugDOgG4= =wXGJ -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From Nicolas.Williams@sun.com Thu Nov 12 12:00:21 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDCF3A6B28 for ; Thu, 12 Nov 2009 12:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.972 X-Spam-Level: X-Spam-Status: No, score=-4.972 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsIfpPo6cykc for ; Thu, 12 Nov 2009 12:00:19 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id C87BE28C1D0 for ; Thu, 12 Nov 2009 12:00:13 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nACK0c3s028334 for ; Thu, 12 Nov 2009 20:00:38 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nACK0bx7058615 for ; Thu, 12 Nov 2009 13:00:37 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACJfYQb018447; Thu, 12 Nov 2009 13:41:34 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACJfXBi018446; Thu, 12 Nov 2009 13:41:33 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 13:41:33 -0600 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: GSS-APIv3 sketch Message-ID: <20091112194133.GF1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:00:21 -0000 On Thu, Nov 12, 2009 at 10:52:03AM -0800, Love Hörnquist Åstrand wrote: > 12 nov 2009 kl. 09:04 skrev Nicolas Williams: > > I'd love to see that, please :) > > http://www.opengroup.org/onlinepubs/009695399/functions/fork.html > > "A process shall be created with a single thread. If a multi-threaded > process calls fork(), the new process shall contain a replica of the > calling thread and its entire address space, possibly including the > states of mutexes and other resources. Consequently, to avoid errors, > the child process may only execute async-signal-safe operations until > such time as one of the exec functions is called. [THR] > Fork handlers may be established by means of the > pthread_atfork()function in order to maintain application invariants > across fork() calls." > > Does libc regiester all mutexes it uses with pthread_atfork() so > malloc will continue to work ? As long as all libraries doesn't you > pthread_atfork() you are dead. If there are libraries in OpenSolaris that use threads but don't clean up their synchronization state in fork() children via pthread_atfork(), then that's _BUG_. I'll grant that some such libraries may not be part of core Solaris, that they may be FOSS with upstreams that don't care about such bugs. But here we're talking about libraries (GSS-API mechglue and providers) that are part of core Solaris. > Fork-and-not-do-exec is dead concept in multi threaded apps. Fork-and-not-exec is a suspect idea no matter what, and if you'll fork-and-exec then you should use posix_spawn(3C). But why is any of this a concern here? Does Samba fork-and-not-exec? Are you afraid that there are libraries that would? Nico -- From Nicolas.Williams@sun.com Thu Nov 12 12:01:37 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797493A6801 for ; Thu, 12 Nov 2009 12:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO2gE71zQGI7 for ; Thu, 12 Nov 2009 12:01:36 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id D5C373A67B3 for ; Thu, 12 Nov 2009 12:01:24 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nACK1sxq028669 for ; Thu, 12 Nov 2009 20:01:54 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nACK1rAQ059637 for ; Thu, 12 Nov 2009 13:01:53 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACJgpdE018464; Thu, 12 Nov 2009 13:42:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACJgpLr018463; Thu, 12 Nov 2009 13:42:51 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 13:42:51 -0600 From: Nicolas Williams To: Volker Lendecke Subject: Re: GSS-APIv3 sketch Message-ID: <20091112194250.GG1105@Sun.COM> References: <20091111181140.GC10501@Sun.COM> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@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 Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:01:37 -0000 On Thu, Nov 12, 2009 at 07:54:56PM +0100, Volker Lendecke wrote: > Let me point out another thing: By using threads and a > purely blocking API, you force everyone into threads. If you > do it async, it is very easy to create blocking wrappers > around the async calls which then can be used in threaded > programs. The other way round is a lot harder. That ship has sailed: Solaris 10 and up has a unified process model, and it's a threaded process model. Nico -- From Volker.Lendecke@SerNet.DE Thu Nov 12 12:05:11 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBDC3A6778 for ; Thu, 12 Nov 2009 12:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqi1muK3ZahO for ; Thu, 12 Nov 2009 12:05:10 -0800 (PST) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 3D21C3A659C for ; Thu, 12 Nov 2009 12:05:10 -0800 (PST) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8fvF-0008Ir-NE; Thu, 12 Nov 2009 21:05:37 +0100 Received: by intern.SerNet.DE id 1N8fvF-006so2-EU; Thu, 12 Nov 2009 21:05:37 +0100 Received: by intern.SerNet.DE id 1N8fvF-006snl-9x; Thu, 12 Nov 2009 21:05:37 +0100 Date: Thu, 12 Nov 2009 21:05:37 +0100 From: Volker Lendecke To: Nicolas Williams Subject: Re: GSS-APIv3 sketch References: <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> <20091112194133.GF1105@Sun.COM> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <20091112194133.GF1105@Sun.COM> User-Agent: Mutt/1.5.9i Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:05:11 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 12, 2009 at 01:41:33PM -0600, Nicolas Williams wrote: > But why is any of this a concern here? Does Samba fork-and-not-exec? Yes. Volker --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFK/GqQbZMKAi3WUkkRAlNAAJ9mNHd4DuobF4pwqG1uGkSBrX5tAwCeM1UI huGSaBIEUe8CFZXFFGiyY7E= =kHkF -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From Volker.Lendecke@SerNet.DE Thu Nov 12 12:05:35 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6293A68D4 for ; Thu, 12 Nov 2009 12:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aouu32hzbTh5 for ; Thu, 12 Nov 2009 12:05:34 -0800 (PST) Received: from mail.SerNet.de (mail.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 62E723A659C for ; Thu, 12 Nov 2009 12:05:34 -0800 (PST) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8fve-0008Mm-CY; Thu, 12 Nov 2009 21:06:02 +0100 Received: by intern.SerNet.DE id 1N8fve-006sp9-4C; Thu, 12 Nov 2009 21:06:02 +0100 Received: by intern.SerNet.DE id 1N8fvd-006sou-Vh; Thu, 12 Nov 2009 21:06:02 +0100 Date: Thu, 12 Nov 2009 21:06:01 +0100 From: Volker Lendecke To: Nicolas Williams Subject: Re: GSS-APIv3 sketch References: <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> <20091112194250.GG1105@Sun.COM> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <20091112194250.GG1105@Sun.COM> User-Agent: Mutt/1.5.9i Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:05:35 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2009 at 01:42:51PM -0600, Nicolas Williams wrote: > On Thu, Nov 12, 2009 at 07:54:56PM +0100, Volker Lendecke wrote: > > Let me point out another thing: By using threads and a > > purely blocking API, you force everyone into threads. If you > > do it async, it is very easy to create blocking wrappers > > around the async calls which then can be used in threaded > > programs. The other way round is a lot harder. >=20 > That ship has sailed: Solaris 10 and up has a unified process model, and > it's a threaded process model. So GSSAPI is a Solaris only thing? Volker --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFK/GqpbZMKAi3WUkkRAjeiAJ9eWEexyLjOInlrCXKav1S5c7kyUwCfZy6v h6jPI9Q+vjvIFzKlDGzK6/0= =x90C -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From Nicolas.Williams@sun.com Thu Nov 12 12:24:51 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122343A6825 for ; Thu, 12 Nov 2009 12:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGG7Uue1wtks for ; Thu, 12 Nov 2009 12:24:50 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id D0B673A67D8 for ; Thu, 12 Nov 2009 12:24:49 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nACKPIff021516 for ; Thu, 12 Nov 2009 20:25:18 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nACKPIO7025818 for ; Thu, 12 Nov 2009 13:25:18 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACK6Dod018519; Thu, 12 Nov 2009 14:06:13 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACK6CJF018518; Thu, 12 Nov 2009 14:06:12 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 14:06:12 -0600 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: GSS-APIv3 sketch Message-ID: <20091112200612.GH1105@Sun.COM> References: <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> <20091112194133.GF1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091112194133.GF1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:24:51 -0000 On Thu, Nov 12, 2009 at 01:41:33PM -0600, Nicolas Williams wrote: > If there are libraries in OpenSolaris that use threads but don't clean > up their synchronization state in fork() children via pthread_atfork(), > then that's _BUG_. I'll grant that some such libraries may not be part Also, to be fair, I'd consider such behavior to be a BUG in Linux, *BSD, ... pthread_atfork() and atexit() are standard interfaces, and they exist to avoid the problems that you fear will crop up. If those interfaces are not used properly, or not used at all, where they should be, then that has to be considered a bug. For a _standard_ GSS-API async extension I'd like the REQUIRED to implement to be one that encodes the least OS-specific detail. The callback API is that extension (it can be implemented on any OS that provides for either threads or a global event loop -- that's Windows, Linux, Solaris, *BSD, and probably a great many others). I don't mind, and will help design, specify and implement alternatives that are RECOMMENDED or OPTIONAL to implement; such alternatives will be less portable than the callback design since details of async I/O event systems vary greatly (though with libevent we can get most Unix/Unix-like OSes as well as Windows). Do you agree? Nico -- From Nicolas.Williams@sun.com Thu Nov 12 12:28:53 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA453A67DD for ; Thu, 12 Nov 2009 12:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJIVPWRO35Ux for ; Thu, 12 Nov 2009 12:28:52 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id D1A0C3A6359 for ; Thu, 12 Nov 2009 12:28:52 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nACKTLre006676 for ; Thu, 12 Nov 2009 20:29:22 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nACKTLGB028150 for ; Thu, 12 Nov 2009 13:29:21 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACKAGEQ018530; Thu, 12 Nov 2009 14:10:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACKAFM7018529; Thu, 12 Nov 2009 14:10:15 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 14:10:15 -0600 From: Nicolas Williams To: Volker Lendecke Subject: Re: GSS-APIv3 sketch Message-ID: <20091112201015.GI1105@Sun.COM> References: <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> <20091112194250.GG1105@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 Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:28:53 -0000 On Thu, Nov 12, 2009 at 09:06:01PM +0100, Volker Lendecke wrote: > On Thu, Nov 12, 2009 at 01:42:51PM -0600, Nicolas Williams wrote: > > On Thu, Nov 12, 2009 at 07:54:56PM +0100, Volker Lendecke wrote: > > > Let me point out another thing: By using threads and a > > > purely blocking API, you force everyone into threads. If you > > > do it async, it is very easy to create blocking wrappers > > > around the async calls which then can be used in threaded > > > programs. The other way round is a lot harder. > > > > That ship has sailed: Solaris 10 and up has a unified process model, and > > it's a threaded process model. > > So GSSAPI is a Solaris only thing? How does that follow? I'm advising you that on Solaris you can expect core libraries to launch threads, and you can expect them to use pthread_atfork() and atexit() propoerly. Note that I'm NOT saying "you can't have a libevent-/whatever-based GSS async extension". I'm not being hostile to what you propose nor to you. I'm saying that I think we must have a callback-based GSS async extension as _one_ choice, and probably the required-to-implement choice because that one makes the fewest assumptions about operating systems. Nico -- From Volker.Lendecke@SerNet.DE Thu Nov 12 12:31:38 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AF73A6832 for ; Thu, 12 Nov 2009 12:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIRjcOw+yBpi for ; Thu, 12 Nov 2009 12:31:38 -0800 (PST) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 0F47B3A6359 for ; Thu, 12 Nov 2009 12:31:37 -0800 (PST) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8gKq-0003kV-SL; Thu, 12 Nov 2009 21:32:04 +0100 Received: by intern.SerNet.DE id 1N8gKq-006uCl-Jg; Thu, 12 Nov 2009 21:32:04 +0100 Received: by intern.SerNet.DE id 1N8gKq-006uCU-8g; Thu, 12 Nov 2009 21:32:04 +0100 Date: Thu, 12 Nov 2009 21:34:03 +0100 From: Volker Lendecke To: Nicolas Williams Subject: Re: GSS-APIv3 sketch References: <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> <20091112194250.GG1105@Sun.COM> <20091112201015.GI1105@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20091112201015.GI1105@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:31:39 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2009 at 02:10:15PM -0600, Nicolas Williams wrote: > On Thu, Nov 12, 2009 at 09:06:01PM +0100, Volker Lendecke wrote: > > On Thu, Nov 12, 2009 at 01:42:51PM -0600, Nicolas Williams wrote: > > > On Thu, Nov 12, 2009 at 07:54:56PM +0100, Volker Lendecke wrote: > > > > Let me point out another thing: By using threads and a > > > > purely blocking API, you force everyone into threads. If you > > > > do it async, it is very easy to create blocking wrappers > > > > around the async calls which then can be used in threaded > > > > programs. The other way round is a lot harder. > > >=20 > > > That ship has sailed: Solaris 10 and up has a unified process model, = and > > > it's a threaded process model. > >=20 > > So GSSAPI is a Solaris only thing? >=20 > How does that follow? I'm advising you that on Solaris you can expect > core libraries to launch threads, and you can expect them to use > pthread_atfork() and atexit() propoerly. >=20 > Note that I'm NOT saying "you can't have a libevent-/whatever-based GSS > async extension". I'm not being hostile to what you propose nor to you. >=20 > I'm saying that I think we must have a callback-based GSS async > extension as _one_ choice, and probably the required-to-implement choice > because that one makes the fewest assumptions about operating systems. That sounds good! I had understood that you only want the blocking API, depending on threads. Thanks :-) Volker --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkr8cToACgkQbZMKAi3WUklIdACeLpSLV9b+oXC9IizY+tWGV40/ cGEAn22ML6O+aBJ1rElgtMlPU6FKW0v1 =W7BS -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From Nicolas.Williams@sun.com Thu Nov 12 12:52:20 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9F33A693F for ; Thu, 12 Nov 2009 12:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3Rsbw52rOnU for ; Thu, 12 Nov 2009 12:52:19 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 1D5863A68B7 for ; Thu, 12 Nov 2009 12:52:19 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nACKqlSC003697 for ; Thu, 12 Nov 2009 20:52:47 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nACKql2p042595 for ; Thu, 12 Nov 2009 13:52:47 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACKXhgD018607; Thu, 12 Nov 2009 14:33:43 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACKXhJY018606; Thu, 12 Nov 2009 14:33:43 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 14:33:43 -0600 From: Nicolas Williams To: Volker Lendecke Subject: Re: GSS-APIv3 sketch Message-ID: <20091112203343.GK1105@Sun.COM> References: <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net> <20091111230442.GY1105@Sun.COM> <20091112170403.GB1105@Sun.COM> <20091112194250.GG1105@Sun.COM> <20091112201015.GI1105@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 Cc: "kitten@ietf.org" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:52:20 -0000 On Thu, Nov 12, 2009 at 09:34:03PM +0100, Volker Lendecke wrote: > That sounds good! I had understood that you only want the > blocking API, depending on threads. I thought so :) > Thanks :-) NP. Thanks for the info. From tlyu@MIT.EDU Mon Nov 16 18:04:47 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289313A69A7 for ; Mon, 16 Nov 2009 18:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OROxZ83DD0SH for ; Mon, 16 Nov 2009 18:04:46 -0800 (PST) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 6EF333A68E7 for ; Mon, 16 Nov 2009 18:04:46 -0800 (PST) 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 nAH24MX8024915; Mon, 16 Nov 2009 21:04:22 -0500 (EST) 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 nAH24kUR025401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 21:04:46 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id nAH24Zkn023313; Mon, 16 Nov 2009 21:04:35 -0500 (EST) To: Nicolas Williams Subject: Re: GSS-APIv3 sketch References: <20091111181140.GC10501@Sun.COM> From: Tom Yu Date: Mon, 16 Nov 2009 21:04:35 -0500 In-Reply-To: <20091111181140.GC10501@Sun.COM> (Nicolas Williams's message of "Wed, 11 Nov 2009 13:11:40 -0500") Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 02:04:47 -0000 Nicolas Williams writes: > > - struct gss3_in_buffer_desc > - gss3_in_buffer_t > - gss3_out_buffer_t Should we be more conforming about namespaces and avoid the POSIX-reserved "_t" suffix? (as long as we are trying to atone for our past sins...) From leifj@mnt.se Tue Nov 17 06:19:36 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA2A28C152 for ; Tue, 17 Nov 2009 06:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwa60Qdjp8pb for ; Tue, 17 Nov 2009 06:19:35 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by core3.amsl.com (Postfix) with ESMTP id 8C02E3A6AB2 for ; Tue, 17 Nov 2009 06:19:35 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id nAHEJTKQ018766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 15:19:32 +0100 (CET) Message-ID: <4B02B0F2.7070005@mnt.se> Date: Tue, 17 Nov 2009 15:19:30 +0100 From: Leif Johansson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: leifj@mnt.se Subject: Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt References: <200909141004.39686.leifj@mnt.se> In-Reply-To: <200909141004.39686.leifj@mnt.se> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, =?ISO-8859-1?Q?Love_H=F6?=, Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 14:19:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > gss_buffer_set_t it is then unless people scream bloody murder at it > fairly soon So Luke pointed out that we need to pull in gss_buffer_set_t from somewhere and the only reference he could think of was the GSI draft which isn't a standards-track RFC. Of course I can copy the gss-buffer stuff but maybe it should be a separate document... possibly for inclusion into v3 later on? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksCsPIACgkQ8Jx8FtbMZnfMGQCgmMEEAjcuf9LTeLQyXA99j3xF hYEAn3rJ6vh+VsHz0oh35pKDd629KW6k =dFEL -----END PGP SIGNATURE----- From leifj@mnt.se Tue Nov 17 06:21:44 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26E828C0F2 for ; Tue, 17 Nov 2009 06:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FISGkTGOYmLt for ; Tue, 17 Nov 2009 06:21:44 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by core3.amsl.com (Postfix) with ESMTP id E7C833A6AA5 for ; Tue, 17 Nov 2009 06:21:43 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id nAHELdOG018507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 15:21:41 +0100 (CET) Message-ID: <4B02B173.5070003@mnt.se> Date: Tue, 17 Nov 2009 15:21:39 +0100 From: Leif Johansson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: leifj@mnt.se Subject: dropping gss_name_to_any ? References: <200909141004.39686.leifj@mnt.se> In-Reply-To: <200909141004.39686.leifj@mnt.se> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, =?ISO-8859-1?Q?Love_H=F6?=, Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 14:21:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I've never been comfortable with this API - it feels difficult to specify > property. I'd be in favor of dropping it. I'd like to confirm that we have consensus on dropping gss_name_to_any (or consensus that I misunderstood that thread) Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksCsXMACgkQ8Jx8FtbMZndm3wCgvl81EpmJZag8dKh4XT/3YdMt H4gAoKiNLWnBoyaBU6tosqiemtGXKxZ2 =8cy5 -----END PGP SIGNATURE----- From lukeh@padl.com Tue Nov 17 07:47:39 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A333A6968 for ; Tue, 17 Nov 2009 07:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7kwBMlqN1ra for ; Tue, 17 Nov 2009 07:47:39 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id CE6403A6857 for ; Tue, 17 Nov 2009 07:47:38 -0800 (PST) Received: by us.padl.com with ESMTP id nAHFlA5n003484; Tue, 17 Nov 2009 10:47:14 -0500 Subject: Re: dropping gss_name_to_any ? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Luke Howard In-Reply-To: <4B02B173.5070003@mnt.se> Date: Tue, 17 Nov 2009 16:47:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1076) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: kitten@ietf.org, Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:47:39 -0000 On 17/11/2009, at 3:21 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> I've never been comfortable with this API - it feels difficult to >> specify >> property. I'd be in favor of dropping it. > > I'd like to confirm that we have consensus on dropping gss_name_to_any > (or consensus that I misunderstood that thread) I don't mind, however we did implement it. -- Luke From Nicolas.Williams@sun.com Tue Nov 17 09:05:47 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0523A687F for ; Tue, 17 Nov 2009 09:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.21 X-Spam-Level: X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d22AxDUempqC for ; Tue, 17 Nov 2009 09:05:46 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 90BD53A6876 for ; Tue, 17 Nov 2009 09:05:45 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAHH5hxo008674 for ; Tue, 17 Nov 2009 17:05:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nAHH5hFQ043600 for ; Tue, 17 Nov 2009 10:05:43 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAHGkXfc001519; Tue, 17 Nov 2009 10:46:33 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAHGkWEn001518; Tue, 17 Nov 2009 10:46:32 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 17 Nov 2009 10:46:32 -0600 From: Nicolas Williams To: Leif Johansson Subject: Re: dropping gss_name_to_any ? Message-ID: <20091117164631.GM773@Sun.COM> References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B02B173.5070003@mnt.se> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, =?ISO-8859-1?Q?Love_H=F6?=@core3.amsl.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:05:47 -0000 On Tue, Nov 17, 2009 at 03:21:39PM +0100, Leif Johansson wrote: > > I've never been comfortable with this API - it feels difficult to specify > > property. I'd be in favor of dropping it. > > I'd like to confirm that we have consensus on dropping gss_name_to_any > (or consensus that I misunderstood that thread) I'm for dropping it, but Luke seems to think it's useful, and he did implement it, including a plug-in interface. Luke? Nico -- From lukeh@padl.com Tue Nov 17 09:17:32 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5783A69A8 for ; Tue, 17 Nov 2009 09:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM4JLBuqij5P for ; Tue, 17 Nov 2009 09:17:31 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 72CF83A6962 for ; Tue, 17 Nov 2009 09:17:31 -0800 (PST) Received: by us.padl.com with ESMTP id nAHHHBt3005368; Tue, 17 Nov 2009 12:17:19 -0500 Subject: Re: dropping gss_name_to_any ? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Luke Howard In-Reply-To: <20091117164631.GM773@Sun.COM> Date: Tue, 17 Nov 2009 18:17:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> <20091117164631.GM773@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1076) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:17:32 -0000 On 17/11/2009, at 5:46 PM, Nicolas Williams wrote: > On Tue, Nov 17, 2009 at 03:21:39PM +0100, Leif Johansson wrote: >>> I've never been comfortable with this API - it feels difficult to >>> specify >>> property. I'd be in favor of dropping it. >> >> I'd like to confirm that we have consensus on dropping >> gss_name_to_any >> (or consensus that I misunderstood that thread) > > I'm for dropping it, but Luke seems to think it's useful, and he did > implement it, including a plug-in interface. Luke? I only really implemented it because it's in the spec. But there are cases where it may be useful -- but those all defeat the purpose of a general-purpose, mechanism-agnostic API. For example, the SAML provider surfaces the assertion object via this interface, but then it requires the caller be using the same SAML implementation. -- Luke From lha@kth.se Tue Nov 17 14:04:07 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485E13A68D8 for ; Tue, 17 Nov 2009 14:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smSB-H3sR5+L for ; Tue, 17 Nov 2009 14:04:06 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 746363A6824 for ; Tue, 17 Nov 2009 14:04:06 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 27C5679EB6CC for ; Tue, 17 Nov 2009 14:04:05 -0800 (PST) X-AuditID: 11807136-b7bafae000000e8d-0a-4b031dd5e64e Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id DB.00.03725.5DD130B4; Tue, 17 Nov 2009 14:04:05 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from xn--i-a--a-euaf1n.apple.com (xn--i-a--a-euaf1n.apple.com [17.201.27.32]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KT9009BSXASLVA0@gertie.apple.com> for kitten@ietf.org; Tue, 17 Nov 2009 14:04:05 -0800 (PST) Subject: Re: dropping gss_name_to_any ? From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: Date: Tue, 17 Nov 2009 14:04:04 -0800 Message-id: References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> <20091117164631.GM773@Sun.COM> To: Luke Howard X-Mailer: Apple Mail (2.1127) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:04:07 -0000 17 nov 2009 kl. 09:17 skrev Luke Howard: > > On 17/11/2009, at 5:46 PM, Nicolas Williams wrote: > >> On Tue, Nov 17, 2009 at 03:21:39PM +0100, Leif Johansson wrote: >>>> I've never been comfortable with this API - it feels difficult to >>>> specify >>>> property. I'd be in favor of dropping it. >>> >>> I'd like to confirm that we have consensus on dropping >>> gss_name_to_any >>> (or consensus that I misunderstood that thread) >> >> I'm for dropping it, but Luke seems to think it's useful, and he did >> implement it, including a plug-in interface. Luke? > > > I only really implemented it because it's in the spec. But there are > cases where it may be useful -- but those all defeat the purpose of a > general-purpose, mechanism-agnostic API. For example, the SAML > provider surfaces the assertion object via this interface, but then it > requires the caller be using the same SAML implementation. I think that when we get a real use for it we can add it all back. Pushing out random objects is sane. Love From lukeh@padl.com Tue Nov 17 15:52:47 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4D53A67B3 for ; Tue, 17 Nov 2009 15:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV5L-o6QW4dC for ; Tue, 17 Nov 2009 15:52:47 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 392FB3A67B0 for ; Tue, 17 Nov 2009 15:52:46 -0800 (PST) Received: by us.padl.com with ESMTP id nAHNqNsK015520; Tue, 17 Nov 2009 18:52:27 -0500 Subject: Re: dropping gss_name_to_any ? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed From: Luke Howard In-Reply-To: Date: Wed, 18 Nov 2009 00:52:22 +0100 Content-Transfer-Encoding: 7bit Message-Id: <74E9274D-D2E5-4C5D-98DB-6D6F4AB9279D@padl.com> References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> <20091117164631.GM773@Sun.COM> To: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= X-Mailer: Apple Mail (2.1076) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:52:48 -0000 > Pushing out random objects is sane. Or insane? :-) -- Luke From lha@kth.se Tue Nov 17 15:58:47 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109783A694E for ; Tue, 17 Nov 2009 15:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM3ZknvGZ+zp for ; Tue, 17 Nov 2009 15:58:46 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 5B78C3A6AF2 for ; Tue, 17 Nov 2009 15:58:46 -0800 (PST) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id E0D0779F2887 for ; Tue, 17 Nov 2009 15:58:44 -0800 (PST) X-AuditID: 11807137-b7bd4ae000000f0d-4c-4b0338b4c09e Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id 08.39.03853.4B8330B4; Tue, 17 Nov 2009 15:58:44 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from xn--i-a--a-euaf1n.apple.com (xn--i-a--a-euaf1n.apple.com [17.201.27.32]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KTA0081O2LW9O00@elliott.apple.com> for kitten@ietf.org; Tue, 17 Nov 2009 15:58:44 -0800 (PST) Subject: Re: dropping gss_name_to_any ? From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <74E9274D-D2E5-4C5D-98DB-6D6F4AB9279D@padl.com> Date: Tue, 17 Nov 2009 15:58:44 -0800 Message-id: <52B31A6F-A19D-4B39-875B-16CD76F82BC3@kth.se> References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> <20091117164631.GM773@Sun.COM> <74E9274D-D2E5-4C5D-98DB-6D6F4AB9279D@padl.com> To: Luke Howard X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:58:47 -0000 17 nov 2009 kl. 15:52 skrev Luke Howard: >> Pushing out random objects is sane. > > Or insane? :-) yes sorry. Love From Nicolas.Williams@sun.com Tue Nov 17 16:09:10 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1A73A6B2B for ; Tue, 17 Nov 2009 16:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.269 X-Spam-Level: X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l5R2aU6V+p8 for ; Tue, 17 Nov 2009 16:09:09 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 07E1B3A6879 for ; Tue, 17 Nov 2009 16:09:08 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAI093vf001373 for ; Wed, 18 Nov 2009 00:09:03 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nAI092HG035619 for ; Tue, 17 Nov 2009 17:09:02 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAHNvQYb001761; Tue, 17 Nov 2009 17:57:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAHNvP56001760; Tue, 17 Nov 2009 17:57:25 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 17 Nov 2009 17:57:25 -0600 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: dropping gss_name_to_any ? Message-ID: <20091117235725.GW773@Sun.COM> References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> <20091117164631.GM773@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:09:10 -0000 On Tue, Nov 17, 2009 at 02:04:04PM -0800, Love Hörnquist Åstrand wrote: > I think that when we get a real use for it we can add it all back. > > Pushing out random objects is sane. Insane, yes. My original use had been for an OS-specific view of things like the PAC. But as long as there's few consumers or the parsing code can live in a library, then there's no need for this. I.e., there's no need for this -- it was a mistake on my part to include it in the first place. From leifj@mnt.se Wed Nov 18 04:45:41 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8E83A691D for ; Wed, 18 Nov 2009 04:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V97714dcPjtE for ; Wed, 18 Nov 2009 04:45:40 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by core3.amsl.com (Postfix) with ESMTP id 1A4763A689F for ; Wed, 18 Nov 2009 04:45:39 -0800 (PST) Received: from [192.36.125.216] (dhcp-216.pilsnet.sunet.se [192.36.125.216] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id nAICjYK9027695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 13:45:36 +0100 (CET) Message-ID: <4B03EC70.3040602@mnt.se> Date: Wed, 18 Nov 2009 13:45:36 +0100 From: Leif Johansson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: dropping gss_name_to_any ? References: <200909141004.39686.leifj@mnt.se> <4B02B173.5070003@mnt.se> <20091117164631.GM773@Sun.COM> <20091117235725.GW773@Sun.COM> In-Reply-To: <20091117235725.GW773@Sun.COM> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:45:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Tue, Nov 17, 2009 at 02:04:04PM -0800, Love Hörnquist Åstrand wrote: >> I think that when we get a real use for it we can add it all back. >> >> Pushing out random objects is sane. > > Insane, yes. My original use had been for an OS-specific view of things > like the PAC. But as long as there's few consumers or the parsing code > can live in a library, then there's no need for this. I.e., there's no > need for this -- it was a mistake on my part to include it in the first > place. OK I'll venture to declare consensus on that point then. That just leaves one item for me before I can get out 06: where to define gss_buffer_set_t and related functions: separate document or inline? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksD7HAACgkQ8Jx8FtbMZncNpACgtFt3R3TLZQKPZQ/eHK9IVh53 CAIAoLwP+B4JlHMfiKZ4nAH/LWcz0r5p =Y1Qe -----END PGP SIGNATURE-----