From leifj@it.su.se Sun Mar 8 09:31: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 8E65A28C19E for ; Sun, 8 Mar 2009 09:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, HELO_EQ_SE=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 eRnTB5Su3VgZ for ; Sun, 8 Mar 2009 09:31:53 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 85F0B28C212 for ; Sun, 8 Mar 2009 09:31:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id E81D83C500 for ; Sun, 8 Mar 2009 17:32:23 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00802-01-3 for ; Sun, 8 Mar 2009 17:32:23 +0100 (CET) Received: from k2.mnt.se (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 8909D3C4B8 for ; Sun, 8 Mar 2009 17:32:23 +0100 (CET) From: Leif Johansson To: kitten@ietf.org Subject: naming extensions issues Date: Sun, 8 Mar 2009 17:32:17 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart17930497.hkdDiyxtji"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903081732.22196.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 16:31:54 -0000 --nextPart17930497.hkdDiyxtji Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, Jumping right in as if everybody remembers exactly where we are with=20 the naming extensions draft: I'll update the current version of the draft with new boilerplate in a few= =20 minutes. The 4 major issues I have with the current model are: * The critical flag * The mapped flag I don't see the usefulness of this flag. The model I'd like to work from is= =20 one where the authorization decisions are always pushed up the stack=20 to the application - i.e the security context is established regardless of weather attributes are understood or even available. It is then up to the application to figure out if the context carries enough extra information=20 to be useful. In this model the application will understand the semantics of each=20 attribute including the fact that it is derived (in other words the mapped flag is a property of the attribute schema - not the context) from other attributes or it won't care! * The negative flag Negative assertions are dangerous (I claim with my poker face on) If=20 there isn't a use-case for them I think they should be removed on general=20 principle. At least there should be a single example of a "native" claims- based identity technology we would like to map to GSS-API naming=20 extensions where negative assertions are used :) * The use of OIDs Clearly OIDs are nice and a well established part of GSS-API. However in many of the cases where attributes will arise naturally the "native" naming is based on UR*'s. Requiring OIDs implies the creation of an IANA registry for the mapping! The alternative is to pass names using=20 gss_buffer_t (i.e octet strings). Cheers Leif --nextPart17930497.hkdDiyxtji 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) iEYEABECAAYFAkmz8xIACgkQ8Jx8FtbMZneVPwCgvFPSXVC/07PU5OUQmbY+JruC tT8AnRbbhvS4ogsHhZFqYiVSKB1AcBQj =PjTw -----END PGP SIGNATURE----- --nextPart17930497.hkdDiyxtji-- From root@core3.amsl.com Sun Mar 8 09:45:01 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C957D3A6A4B; Sun, 8 Mar 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-naming-exts-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090308164501.C957D3A6A4B@core3.amsl.com> Date: Sun, 8 Mar 2009 09:45:01 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : N. Williams, L. Johansson Filename : draft-ietf-kitten-gssapi-naming-exts-04.txt Pages : 18 Date : 2009-03-08 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-naming-exts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-08093456.I-D@ietf.org> --NextPart-- From Nicolas.Williams@sun.com Sun Mar 8 22:41:16 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7F83A6403 for ; Sun, 8 Mar 2009 22:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.712 X-Spam-Level: X-Spam-Status: No, score=-5.712 tagged_above=-999 required=5 tests=[AWL=0.334, 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 anU05TEsgTHG for ; Sun, 8 Mar 2009 22:41:15 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 0B5EA3A68CD for ; Sun, 8 Mar 2009 22:41:15 -0700 (PDT) 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 n295fmr5015914 for ; Mon, 9 Mar 2009 05:41:48 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n295fmls033503 for ; Sun, 8 Mar 2009 23:41:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n295WgAB018758; Mon, 9 Mar 2009 00:32:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n295WWdY018757; Mon, 9 Mar 2009 00:32:32 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Mar 2009 00:32:32 -0500 From: Nicolas Williams To: Leif Johansson Subject: Re: naming extensions issues Message-ID: <20090309053232.GG9992@Sun.COM> References: <200903081732.22196.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903081732.22196.leifj@it.su.se> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 05:41:16 -0000 On Sun, Mar 08, 2009 at 05:32:17PM +0100, Leif Johansson wrote: > I'll update the current version of the draft with new boilerplate in a few > minutes. The 4 major issues I have with the current model are: > > * The critical flag > * The mapped flag > > I don't see the usefulness of this flag. The model I'd like to work from is > one where the authorization decisions are always pushed up the stack > to the application - i.e the security context is established regardless of > weather attributes are understood or even available. It is then up to the > application to figure out if the context carries enough extra information > to be useful. I agree. I had hoped that the system could do common mapping operations, and indeed, it can, but those need to be initiated by the application, not the mechglue. > * The negative flag > > Negative assertions are dangerous (I claim with my poker face on) If > there isn't a use-case for them I think they should be removed on general > principle. At least there should be a single example of a "native" claims- > based identity technology we would like to map to GSS-API naming > extensions where negative assertions are used :) We don't need a "negative" flag, but we do need a "complete" flag so that an application can evaluate negative ACL entries, particularly ones where the subject of the ACE is a group. I believe negative ACL entries with group subjects are dangerous precisely because it's difficult to ensure that full group membership context is always available, but because such ACEs are used we do need a way to convey whether a name's attributes are complete. > * The use of OIDs > > Clearly OIDs are nice and a well established part of GSS-API. However > in many of the cases where attributes will arise naturally the "native" > naming is based on UR*'s. Requiring OIDs implies the creation of an > IANA registry for the mapping! The alternative is to pass names using > gss_buffer_t (i.e octet strings). Applications should use symbols to refer to these things. Whether those symbols resolve internally to OIDs or strings I don't really care. If they be strings then don't bother with gss_buffer_t since we're talking about attribute names, which can be C strings in the C API (const char *). I'm not sure that an IANA registry can be avoided though. Can you expand on that? Nico -- From root@core3.amsl.com Mon Mar 9 00:00:01 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D0E473A68BB; Mon, 9 Mar 2009 00:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-store-cred-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309070001.D0E473A68BB@core3.amsl.com> Date: Mon, 9 Mar 2009 00:00:01 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 07:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : GSS-API Extension for Storing Delegated Credentials Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-store-cred-04.txt Pages : 12 Date : 2009-03-08 This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-store-cred-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-store-cred-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-08235707.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 01:30:01 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 36ACD3A68DF; Mon, 9 Mar 2009 01:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-channel-bindings-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309083001.36ACD3A68DF@core3.amsl.com> Date: Mon, 9 Mar 2009 01:30:01 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 08:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Clarifications and Extensions to the GSS-API for the Use of Channel Bindings Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-channel-bindings-06.txt Pages : 11 Date : 2009-03-09 This document clarifies and generalizes the Generic Security Services Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-channel-bindings-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09011553.I-D@ietf.org> --NextPart-- From alexey.melnikov@isode.com Mon Mar 9 02:44: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 89E383A69E5 for ; Mon, 9 Mar 2009 02:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.083, 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 gExhcJki1aFa for ; Mon, 9 Mar 2009 02:44:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D675E3A69A6 for ; Mon, 9 Mar 2009 02:44:36 -0700 (PDT) Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Mar 2009 09:45:08 +0000 Message-ID: <49B4E510.9060500@isode.com> Date: Mon, 09 Mar 2009 09:44:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Leif Johansson Subject: Re: naming extensions issues References: <200903081732.22196.leifj@it.su.se> In-Reply-To: <200903081732.22196.leifj@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 09:44:39 -0000 Leif Johansson wrote: >Hello all, > >Jumping right in as if everybody remembers exactly where we are with >the naming extensions draft: > >I'll update the current version of the draft with new boilerplate in a few >minutes. The 4 major issues I have with the current model are: > >* The critical flag >* The mapped flag > >I don't see the usefulness of this flag. The model I'd like to work from is >one where the authorization decisions are always pushed up the stack >to the application - i.e the security context is established regardless of >weather attributes are understood or even available. It is then up to the >application to figure out if the context carries enough extra information >to be useful. > I agree with you on this. So the critical flag can definitely go. >In this model the application will understand the semantics of each >attribute including the fact that it is derived (in other words the mapped >flag is a property of the attribute schema - not the context) > I am not sure about the mapped flag yet. Do you have information to support the last claim? > from other >attributes or it won't care! > >* The negative flag > >Negative assertions are dangerous (I claim with my poker face on) If >there isn't a use-case for them I think they should be removed on general >principle. At least there should be a single example of a "native" claims- >based identity technology we would like to map to GSS-API naming >extensions where negative assertions are used :) > > Removing this looks fine to me. >* The use of OIDs > >Clearly OIDs are nice and a well established part of GSS-API. However >in many of the cases where attributes will arise naturally the "native" >naming is based on UR*'s. Requiring OIDs implies the creation of an >IANA registry for the mapping! The alternative is to pass names using >gss_buffer_t (i.e octet strings). > > Can we use one of Nico's tricks to encode any string as an OID under a registered prefix ;-)? A new registry would be fine with me, if people would bother registrering stuff in it. From Josh.Howlett@ja.net Mon Mar 9 13:26:22 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 C54D53A6BFC for ; Mon, 9 Mar 2009 13:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 M4pfiN79h2Td for ; Mon, 9 Mar 2009 13:26:22 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 064823A69A8 for ; Mon, 9 Mar 2009 13:26:21 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1Lgm3r-0005Qe-81 for kitten@ietf.org; Mon, 09 Mar 2009 20:26:55 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C05D14A6B3A_9B57B71B for ; Mon, 9 Mar 2009 20:26:25 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id AE4DE4A6B38_9B57B71F for ; Mon, 9 Mar 2009 20:26:25 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Guidelines for GSS-API mechanism designers Date: Mon, 9 Mar 2009 20:27:05 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04E711A9@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Guidelines for GSS-API mechanism designers Thread-Index: Acmg9WlRPrhi8XE2RA6WxmpvrIuicA== From: "Josh Howlett" To: Cc: Josh Howlett 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 Mar 2009 20:26:22 -0000 The KITTEN WG charter states: This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity: ... o Guidelines for GSS-API mechanism designers Has any material for this item been produced yet? Any pointers to general reference documentation on GSS-API would be welcome also. TIA, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Shawn.Emery@Sun.COM Wed Mar 11 00:28:14 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 DA24C3A69E9 for ; Wed, 11 Mar 2009 00:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 cICQjNQMtSHD for ; Wed, 11 Mar 2009 00:28:14 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 892593A691E for ; Wed, 11 Mar 2009 00:28:13 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2B7SlSG000219 for ; Wed, 11 Mar 2009 07:28:47 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KGB00600ZAWTH00@mail-amer.sun.com> for kitten@ietf.org; Wed, 11 Mar 2009 01:28:47 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KGB00J6JZFZ2H50@mail-amer.sun.com>; Wed, 11 Mar 2009 01:28:47 -0600 (MDT) Date: Wed, 11 Mar 2009 01:27:27 -0600 From: Shawn M Emery Subject: Re: Guidelines for GSS-API mechanism designers In-reply-to: <6ED388AA006C454BA35B0098396B9BFB04E711A9@uxsrvr20.atlas.ukerna.ac.uk> Sender: Shawn.Emery@Sun.COM To: Josh Howlett Message-id: <49B767DF.5080305@sun.com> References: <6ED388AA006C454BA35B0098396B9BFB04E711A9@uxsrvr20.atlas.ukerna.ac.uk> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) 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 Mar 2009 07:28:14 -0000 Josh Howlett wrote: > The KITTEN WG charter states: > > This working group is chartered to revise the GSSAPI v2 RFCs for the > purpose of clarifying areas of ambiguity: > ... > o Guidelines for GSS-API mechanism designers > > Has any material for this item been produced yet? > No there hasn't. But there are a number of new mechanisms that are being proposed (PKU2U, LIPKEY, etc.), that this should probably warrant another look into this area. What mechanism are you proposing, perhaps we could answer specific questions you may have? > Any pointers to general reference documentation on GSS-API would be > welcome also. > For a general reference from a application developer point of view you can start here: http://docs.sun.com/app/docs/doc/816-1331 Shawn. -- From leifj@it.su.se Wed Mar 11 01:48: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 D7FFD3A692C for ; Wed, 11 Mar 2009 01:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, 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 V6xfMmhzJhkR for ; Wed, 11 Mar 2009 01:48:40 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id A45B13A68D1 for ; Wed, 11 Mar 2009 01:48:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 277DC3C932; Wed, 11 Mar 2009 09:49:14 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14933-01-16; Wed, 11 Mar 2009 09:49:13 +0100 (CET) Received: from k2.mnt.se (wavelan-97.vlan-102.publik.su.se [77.238.33.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 397CB3CE60; Wed, 11 Mar 2009 09:49:13 +0100 (CET) From: Leif Johansson To: Nicolas Williams Subject: Re: naming extensions issues Date: Wed, 11 Mar 2009 09:49:12 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903081732.22196.leifj@it.su.se> <20090309053232.GG9992@Sun.COM> In-Reply-To: <20090309053232.GG9992@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2318895.Z8LzCdeGaP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903110949.12547.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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 Mar 2009 08:48:40 -0000 --nextPart2318895.Z8LzCdeGaP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 09 March 2009 06:32:32 Nicolas Williams wrote: > On Sun, Mar 08, 2009 at 05:32:17PM +0100, Leif Johansson wrote: > > I'll update the current version of the draft with new boilerplate in a > > few minutes. The 4 major issues I have with the current model are: > > > > * The critical flag > > * The mapped flag > > > > I don't see the usefulness of this flag. The model I'd like to work from > > is one where the authorization decisions are always pushed up the stack > > to the application - i.e the security context is established regardless > > of weather attributes are understood or even available. It is then up to > > the application to figure out if the context carries enough extra > > information to be useful. > > I agree. I had hoped that the system could do common mapping > operations, and indeed, it can, but those need to be initiated by the > application, not the mechglue. > > > * The negative flag > > > > Negative assertions are dangerous (I claim with my poker face on) If > > there isn't a use-case for them I think they should be removed on gener= al > > principle. At least there should be a single example of a "native" > > claims- based identity technology we would like to map to GSS-API naming > > extensions where negative assertions are used :) > > We don't need a "negative" flag, but we do need a "complete" flag so > that an application can evaluate negative ACL entries, particularly ones > where the subject of the ACE is a group. I believe negative ACL entries > with group subjects are dangerous precisely because it's difficult to > ensure that full group membership context is always available, but > because such ACEs are used we do need a way to convey whether a name's > attributes are complete. > I'm not sure I understand this. Are you saying there are negative ACLs in the wild that naming extensions need to support? Could you expand on the semantics of the complete flag? > > * The use of OIDs > > > > Clearly OIDs are nice and a well established part of GSS-API. However > > in many of the cases where attributes will arise naturally the "native" > > naming is based on UR*'s. Requiring OIDs implies the creation of an > > IANA registry for the mapping! The alternative is to pass names using > > gss_buffer_t (i.e octet strings). > > Applications should use symbols to refer to these things. Whether those > symbols resolve internally to OIDs or strings I don't really care. If > they be strings then don't bother with gss_buffer_t since we're talking > about attribute names, which can be C strings in the C API (const char *). > > I'm not sure that an IANA registry can be avoided though. Can you > expand on that? Because we can refer to existing registries - possibly this is an IANA=20 registry registries but in any case it will be a smaller management load than a full table of all urn:s people use in SAML (say) mapped to OIDs which will be but a small part of the registry if we use OIDs. Cheers Leif --nextPart2318895.Z8LzCdeGaP 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) iEYEABECAAYFAkm3ewgACgkQ8Jx8FtbMZnfB7QCeIWloLiohvHsTGYE5ICVbIHpV VNMAmwU44QlrgsiseAi3zZhA1KjebqVw =sTRj -----END PGP SIGNATURE----- --nextPart2318895.Z8LzCdeGaP-- From leifj@it.su.se Wed Mar 11 01:55:22 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 2E3973A6AE7 for ; Wed, 11 Mar 2009 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6, 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 r7eOhVohHp1H for ; Wed, 11 Mar 2009 01:55:21 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 218CF3A67A1 for ; Wed, 11 Mar 2009 01:55:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id AFBE53CF01; Wed, 11 Mar 2009 09:55:56 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15176-01-70; Wed, 11 Mar 2009 09:55:56 +0100 (CET) Received: from k2.mnt.se (wavelan-97.vlan-102.publik.su.se [77.238.33.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 165CE3CF13; Wed, 11 Mar 2009 09:55:55 +0100 (CET) From: Leif Johansson To: Alexey Melnikov Subject: Re: naming extensions issues Date: Wed, 11 Mar 2009 09:55:55 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903081732.22196.leifj@it.su.se> <49B4E510.9060500@isode.com> In-Reply-To: <49B4E510.9060500@isode.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3377115.eoRkYljHAt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903110955.55560.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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 Mar 2009 08:55:22 -0000 --nextPart3377115.eoRkYljHAt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > I am not sure about the mapped flag yet. Do you have information to > support the last claim? Have you ever seen a single example where it was un-awkward to consume authorization below the application - eg in the TLS or TCP layer of the sta= ck? Even consuming authz in the webserver is often un-intuitive for most web- apps even if that often leads to nicer separation of concerns. Imagine tell= ing a webapp developer that authz is now pushed further down the stack :-) > > > from other > >attributes or it won't care! > > > >* The negative flag > > > >Negative assertions are dangerous (I claim with my poker face on) If > >there isn't a use-case for them I think they should be removed on general > >principle. At least there should be a single example of a "native" claim= s- > >based identity technology we would like to map to GSS-API naming > >extensions where negative assertions are used :) > > Removing this looks fine to me. > > >* The use of OIDs > > > >Clearly OIDs are nice and a well established part of GSS-API. However > >in many of the cases where attributes will arise naturally the "native" > >naming is based on UR*'s. Requiring OIDs implies the creation of an > >IANA registry for the mapping! The alternative is to pass names using > >gss_buffer_t (i.e octet strings). > > Can we use one of Nico's tricks to encode any string as an OID under a > registered prefix ;-)? That still requires a registry :-) On the other hand all OIDs are UR*s > > A new registry would be fine with me, if people would bother > registrering stuff in it. Another problem is that most GSS implementations define OIDs at compile- time (correct me If I'm wrong please!) so if you need to add an attribute t= hen=20 you need to redeploy your app which is a definite non-starter. Attributes= =20 need to be able to change at configure-time for apps. Cheers Leif --nextPart3377115.eoRkYljHAt 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) iEYEABECAAYFAkm3fJsACgkQ8Jx8FtbMZndw4QCeOaxxmCFzK4YvuR80CLHvl0w5 dYwAoJNAomHxjy8sHcrYvMXm+RKNLvp+ =Hk3a -----END PGP SIGNATURE----- --nextPart3377115.eoRkYljHAt-- From Josh.Howlett@ja.net Wed Mar 11 02:53: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 1C8AD3A67FF for ; Wed, 11 Mar 2009 02:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 iAJRKD67gqSD for ; Wed, 11 Mar 2009 02:53:29 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 32A0B28C1D5 for ; Wed, 11 Mar 2009 02:53:29 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LhL8W-00076f-2h; Wed, 11 Mar 2009 09:54:04 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9DF7A4A6B5C_9B78A1BB; Wed, 11 Mar 2009 09:53:31 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 8A75E4A6B2E_9B78A19F; Wed, 11 Mar 2009 09:53:29 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines for GSS-API mechanism designers Date: Wed, 11 Mar 2009 09:54:08 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04E71418@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <49B767DF.5080305@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Guidelines for GSS-API mechanism designers Thread-Index: AcmiGwuDCQ99FANbSDuOvwVlUOj2AAAELAEg References: <6ED388AA006C454BA35B0098396B9BFB04E711A9@uxsrvr20.atlas.ukerna.ac.uk> <49B767DF.5080305@sun.com> From: "Josh Howlett" To: Cc: kitten@ietf.org, Josh Howlett 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 Mar 2009 09:53:30 -0000 Shawn wrote: > Josh Howlett wrote: > > The KITTEN WG charter states: > > > > This working group is chartered to revise the GSSAPI v2=20 > RFCs for the > > purpose of clarifying areas of ambiguity: > > ... > > o Guidelines for GSS-API mechanism designers > > > > Has any material for this item been produced yet? > >=20=20=20 >=20 > No there hasn't. But there are a number of new mechanisms=20 > that are being proposed (PKU2U, LIPKEY, etc.), that this=20 > should probably warrant another look into this area. What=20 > mechanism are you proposing An EAP GSS mechanism (for the avoidance of doubt, not a GSS EAP method - I'm aware the previous work on this). > perhaps we could answer specific=20 > questions you may have? That would be greatly appreciated. I have questions, but I wasn't sure if this was the appropriate forum for GSS newbies like myself to pose them. best regards, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From alexey.melnikov@isode.com Wed Mar 11 04:09:25 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 ABD873A68A4 for ; Wed, 11 Mar 2009 04:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 v4OSFXY5UvAF for ; Wed, 11 Mar 2009 04:09:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 89CEC3A67DF for ; Wed, 11 Mar 2009 04:09:24 -0700 (PDT) Received: from [172.16.2.107] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 11 Mar 2009 11:09:58 +0000 Message-ID: <49B79BF6.6070306@isode.com> Date: Wed, 11 Mar 2009 11:09:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Leif Johansson Subject: Re: naming extensions issues References: <200903081732.22196.leifj@it.su.se> <49B4E510.9060500@isode.com> <200903110955.55560.leifj@it.su.se> In-Reply-To: <200903110955.55560.leifj@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 11:09:25 -0000 Leif Johansson wrote: >>I am not sure about the mapped flag yet. Do you have information to >>support the last claim? >> >Have you ever seen a single example where it was un-awkward to consume >authorization below the application - eg in the TLS or TCP layer of the stack? >Even consuming authz in the webserver is often un-intuitive for most web- >apps even if that often leads to nicer separation of concerns. Imagine telling >a webapp developer that authz is now pushed further down the stack :-) > > I am not sure I understand this comment in relationship to my earlier comment. All I was thinking is that if an attribute is constructed based on the value of 2 or more other attributes, the caller might want to know whether that was the case, or if the attribute was included with data itself. But I might be forgetting what "mapped" means. From leifj@it.su.se Wed Mar 11 13:21: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 E767028C1C7 for ; Wed, 11 Mar 2009 13:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.154 X-Spam-Level: X-Spam-Status: No, score=-5.154 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, HELO_EQ_SE=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 t4IkQI76J+9g for ; Wed, 11 Mar 2009 13:21:40 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id B790E28C1C6 for ; Wed, 11 Mar 2009 13:21:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id E272A3E3C7; Wed, 11 Mar 2009 21:22:14 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26572-01-83; Wed, 11 Mar 2009 21:22:14 +0100 (CET) Received: from k2.mnt.se (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 4FFBC3E28C; Wed, 11 Mar 2009 21:22:14 +0100 (CET) From: Leif Johansson To: Alexey Melnikov Subject: Re: naming extensions issues Date: Wed, 11 Mar 2009 21:22:12 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903081732.22196.leifj@it.su.se> <200903110955.55560.leifj@it.su.se> <49B79BF6.6070306@isode.com> In-Reply-To: <49B79BF6.6070306@isode.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1397781.dQyoYMnPJM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903112122.13204.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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 Mar 2009 20:21:41 -0000 --nextPart1397781.dQyoYMnPJM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 March 2009 12:09:42 Alexey Melnikov wrote: > Leif Johansson wrote: > >>I am not sure about the mapped flag yet. Do you have information to > >>support the last claim? > > > >Have you ever seen a single example where it was un-awkward to consume > >authorization below the application - eg in the TLS or TCP layer of the > > stack? Even consuming authz in the webserver is often un-intuitive for > > most web- apps even if that often leads to nicer separation of concerns. > > Imagine telling a webapp developer that authz is now pushed further down > > the stack :-) > > I am not sure I understand this comment in relationship to my earlier > comment. All I was thinking is that if an attribute is constructed based = on > the value of 2 or more other attributes, the caller might want to know > whether that was the case, or if the attribute was included with data > itself. > > But I might be forgetting what "mapped" means. No you're right that is what mapped means. I misread your comment! My response to _:this_ comment is that the attribute consumer (the=20 application) already must know the semantics of the attributes it needs to= =20 consume.=20 This knowledge involves much more than knowing if an attribute was derived= =20 or not and I'm not sure it can be encoded in a protocol. Put another way:=20 mapped doesn't do enough to convey semantics of attributes. Cheers Leif --nextPart1397781.dQyoYMnPJM 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) iEYEABECAAYFAkm4HXUACgkQ8Jx8FtbMZndLOACglhf+IeX6afqUnIJtkPbmGEn9 ihwAn1FBqawiojtXxdbjQFj0Ffjf7o9d =3JzL -----END PGP SIGNATURE----- --nextPart1397781.dQyoYMnPJM-- From Nicolas.Williams@sun.com Wed Mar 11 13:45: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 41CE328C1FC for ; Wed, 11 Mar 2009 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, 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 d3vkaXVOh7I7 for ; Wed, 11 Mar 2009 13:45:24 -0700 (PDT) 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 4C26728C1D6 for ; Wed, 11 Mar 2009 13:45:24 -0700 (PDT) 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 n2BKjgcT006324 for ; Wed, 11 Mar 2009 20:45: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 n2BKjgEv006793 for ; Wed, 11 Mar 2009 14:45:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2BKaZlK021639; Wed, 11 Mar 2009 15:36:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2BKaYRf021638; Wed, 11 Mar 2009 15:36:34 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Mar 2009 15:36:34 -0500 From: Nicolas Williams To: Leif Johansson Subject: Re: naming extensions issues Message-ID: <20090311203633.GM9992@Sun.COM> References: <200903081732.22196.leifj@it.su.se> <20090309053232.GG9992@Sun.COM> <200903110949.12547.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903110949.12547.leifj@it.su.se> 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 Mar 2009 20:45:30 -0000 On Wed, Mar 11, 2009 at 09:49:12AM +0100, Leif Johansson wrote: > > > Negative assertions are dangerous (I claim with my poker face on) If > > > there isn't a use-case for them I think they should be removed on general > > > principle. At least there should be a single example of a "native" > > > claims- based identity technology we would like to map to GSS-API naming > > > extensions where negative assertions are used :) > > > > We don't need a "negative" flag, but we do need a "complete" flag so > > that an application can evaluate negative ACL entries, particularly ones > > where the subject of the ACE is a group. I believe negative ACL entries > > with group subjects are dangerous precisely because it's difficult to > > ensure that full group membership context is always available, but > > because such ACEs are used we do need a way to convey whether a name's > > attributes are complete. > > I'm not sure I understand this. Are you saying there are negative ACLs > in the wild that naming extensions need to support? Could you expand on > the semantics of the complete flag? NT/NFSv4/ZFS-style ACLs allow you to have entries that DENY access to the ACL entry (ACE) subject. If the subject of a DENY ACE is a user then that's easy to check for when doing file access authorization -- you always know the user ID of the client. If the subject of a DENY ACE is a group then you need to know with certainty whether the client user is a member of that group. If krb5 ticket authorization-data includes group membership data for the client principal then it's crucial to know whether that group membership list is complete. If it is not complete then the server may want to deny access to files when evaluating DENY ACEs with groups as subjects. The Windows "PAC" contains a user's group memberships. It is also complete within the user's forest (and, IIRC, groups cannot have members from other forests). > > Applications should use symbols to refer to these things. Whether those > > symbols resolve internally to OIDs or strings I don't really care. If > > they be strings then don't bother with gss_buffer_t since we're talking > > about attribute names, which can be C strings in the C API (const char *). > > > > I'm not sure that an IANA registry can be avoided though. Can you > > expand on that? > > Because we can refer to existing registries - possibly this is an IANA > registry registries but in any case it will be a smaller management load > than a full table of all urn:s people use in SAML (say) mapped to OIDs > which will be but a small part of the registry if we use OIDs. Well, maybe, but I'd like to see concrete examples. Not every use of naming extensions will be for SAML things... From Nicolas.Williams@sun.com Wed Mar 11 13:47: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 EDF973A6836 for ; Wed, 11 Mar 2009 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, 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 FYgKh8EhJZMT for ; Wed, 11 Mar 2009 13:47:53 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id D5D6628C1E1 for ; Wed, 11 Mar 2009 13:47:47 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2BKmOZn015468 for ; Wed, 11 Mar 2009 20:48:24 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 n2BKmOif009868 for ; Wed, 11 Mar 2009 14:48:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2BKdJo6021646; Wed, 11 Mar 2009 15:39:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2BKdIYs021645; Wed, 11 Mar 2009 15:39:18 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Mar 2009 15:39:18 -0500 From: Nicolas Williams To: Leif Johansson Subject: Re: naming extensions issues Message-ID: <20090311203918.GN9992@Sun.COM> References: <200903081732.22196.leifj@it.su.se> <49B4E510.9060500@isode.com> <200903110955.55560.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903110955.55560.leifj@it.su.se> 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 Mar 2009 20:47:54 -0000 On Wed, Mar 11, 2009 at 09:55:55AM +0100, Leif Johansson wrote: > > I am not sure about the mapped flag yet. Do you have information to > > support the last claim? > > Have you ever seen a single example where it was un-awkward to consume > authorization below the application - eg in the TLS or TCP layer of the stack? > Even consuming authz in the webserver is often un-intuitive for most web- > apps even if that often leads to nicer separation of concerns. Imagine telling > a webapp developer that authz is now pushed further down the stack :-) Agreed. > > >Clearly OIDs are nice and a well established part of GSS-API. However > > >in many of the cases where attributes will arise naturally the "native" > > >naming is based on UR*'s. Requiring OIDs implies the creation of an > > >IANA registry for the mapping! The alternative is to pass names using > > >gss_buffer_t (i.e octet strings). > > > > Can we use one of Nico's tricks to encode any string as an OID under a > > registered prefix ;-)? > > That still requires a registry :-) On the other hand all OIDs are UR*s Does it? Why? > > A new registry would be fine with me, if people would bother > > registrering stuff in it. > > Another problem is that most GSS implementations define OIDs at compile- > time (correct me If I'm wrong please!) so if you need to add an attribute then > you need to redeploy your app which is a definite non-starter. Attributes > need to be able to change at configure-time for apps. Hmmm, no, you can add OIDs at run-time. There's a pair of deprecated functions, gss_oid_to_str() and gss_str_to_oid(), that help with this, but I don't see why they should have been deprecated (basically, it made it possible to implement gss_release_oid() as a no-op, but the memory mgmt can be dealt with anyways, so we can always undeprecate these). Nico -- From Nicolas.Williams@sun.com Wed Mar 11 13:49: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 981F53A6836 for ; Wed, 11 Mar 2009 13:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.715 X-Spam-Level: X-Spam-Status: No, score=-5.715 tagged_above=-999 required=5 tests=[AWL=0.331, 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 S4NkjbZUzHI9 for ; Wed, 11 Mar 2009 13:49:37 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id CF5BF3A6A74 for ; Wed, 11 Mar 2009 13:49:37 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2BKoCA5014774 for ; Wed, 11 Mar 2009 20:50:12 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 n2BKoCC4011524 for ; Wed, 11 Mar 2009 14:50:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2BKf6cY021654; Wed, 11 Mar 2009 15:41:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2BKf6RS021653; Wed, 11 Mar 2009 15:41:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Mar 2009 15:41:06 -0500 From: Nicolas Williams To: Alexey Melnikov Subject: Re: naming extensions issues Message-ID: <20090311204106.GO9992@Sun.COM> References: <200903081732.22196.leifj@it.su.se> <49B4E510.9060500@isode.com> <200903110955.55560.leifj@it.su.se> <49B79BF6.6070306@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B79BF6.6070306@isode.com> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 20:49:38 -0000 On Wed, Mar 11, 2009 at 11:09:42AM +0000, Alexey Melnikov wrote: > But I might be forgetting what "mapped" means. Originally "mapped" was for things like the Windows PAC being used on a Unix system: you might want to extract the individual items from the PAC (user SID, group SIDs, home directory UNC, ...) and then have them mapped to local equivalents (UID, GIDs, /net/...). I think that was too ambitious. From Shawn.Emery@Sun.COM Wed Mar 11 22:46: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 25AAF3A67A3 for ; Wed, 11 Mar 2009 22:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 jordRGRe+12d for ; Wed, 11 Mar 2009 22:46:52 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 5F7EF3A63D3 for ; Wed, 11 Mar 2009 22:46:51 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2C5lRbl023009 for ; Thu, 12 Mar 2009 05:47:27 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_eyy4kG8h5sVmQd926nZIhw)" Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KGD00C00PD1FA00@mail-amer.sun.com> for kitten@ietf.org; Wed, 11 Mar 2009 23:47:27 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KGD004VCPEY0930@mail-amer.sun.com>; Wed, 11 Mar 2009 23:47:23 -0600 (MDT) Date: Wed, 11 Mar 2009 23:46:04 -0600 From: Shawn M Emery Subject: Re: Guidelines for GSS-API mechanism designers In-reply-to: <6ED388AA006C454BA35B0098396B9BFB04E71418@uxsrvr20.atlas.ukerna.ac.uk> Sender: Shawn.Emery@Sun.COM To: Josh Howlett Message-id: <49B8A19C.8060904@sun.com> References: <6ED388AA006C454BA35B0098396B9BFB04E711A9@uxsrvr20.atlas.ukerna.ac.uk> <49B767DF.5080305@sun.com> <6ED388AA006C454BA35B0098396B9BFB04E71418@uxsrvr20.atlas.ukerna.ac.uk> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 05:46:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_eyy4kG8h5sVmQd926nZIhw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Josh Howlett wrote: > Shawn wrote: > >> Josh Howlett wrote: >> >>> The KITTEN WG charter states: >>> >>> This working group is chartered to revise the GSSAPI v2 >>> >> RFCs for the >> >>> purpose of clarifying areas of ambiguity: >>> ... >>> o Guidelines for GSS-API mechanism designers >>> >>> Has any material for this item been produced yet? >>> >>> >> No there hasn't. But there are a number of new mechanisms >> that are being proposed (PKU2U, LIPKEY, etc.), that this >> should probably warrant another look into this area. What >> mechanism are you proposing >> > > An EAP GSS mechanism (for the avoidance of doubt, not a GSS EAP method - > I'm aware the previous work on this). > Ah, right WG then. >> perhaps we could answer specific >> questions you may have? >> > > That would be greatly appreciated. I have questions, but I wasn't sure > if this was the appropriate forum for GSS newbies like myself to pose > them. > Please post your questions to the list. I'm sure other people here will be interested in the topic. Shawn. -- --Boundary_(ID_eyy4kG8h5sVmQd926nZIhw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Josh Howlett wrote: 
Shawn wrote:
  
Josh Howlett wrote:
    
The KITTEN WG charter states:

  This working group is chartered to revise the GSSAPI v2 
      
RFCs for the
    
  purpose of clarifying areas of ambiguity:
  ...
  o Guidelines for GSS-API mechanism designers

Has any material for this item been produced yet?
  
      
No there hasn't.  But there are a number of new mechanisms 
that are being proposed (PKU2U, LIPKEY, etc.), that this 
should probably warrant another look into this area.  What 
mechanism are you proposing
    

An EAP GSS mechanism (for the avoidance of doubt, not a GSS EAP method -
I'm aware the previous work on this).

Ah, right WG then.

perhaps we could answer specific 
questions you may have?
    

That would be greatly appreciated. I have questions, but I wasn't sure
if this was the appropriate forum for GSS newbies like myself to pose
them.

Please post your questions to the list.  I'm sure other people here will be interested in the topic.

Shawn.
--
--Boundary_(ID_eyy4kG8h5sVmQd926nZIhw)-- From leifj@it.su.se Thu Mar 12 01:13: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 661AD3A69F6 for ; Thu, 12 Mar 2009 01:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6, 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 AYY8lPdSQdFk for ; Thu, 12 Mar 2009 01:13:38 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 5547F3A6819 for ; Thu, 12 Mar 2009 01:13:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 668D03D766; Thu, 12 Mar 2009 09:14:13 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24321-01-49; Thu, 12 Mar 2009 09:14:13 +0100 (CET) Received: from k2.mnt.se (wavelan-97.vlan-102.publik.su.se [77.238.33.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 96F793D7A6; Thu, 12 Mar 2009 09:14:12 +0100 (CET) From: Leif Johansson To: Nicolas Williams Subject: Re: naming extensions issues Date: Thu, 12 Mar 2009 09:14:11 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903081732.22196.leifj@it.su.se> <200903110955.55560.leifj@it.su.se> <20090311203918.GN9992@Sun.COM> In-Reply-To: <20090311203918.GN9992@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2586657.8X430JLprF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903120914.12171.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 08:13:39 -0000 --nextPart2586657.8X430JLprF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > That still requires a registry :-) On the other hand all OIDs are UR*s > > Does it? Why? Do you have an algorithm for mapping urns to oids? If you don't there will be a table lookup somewhere... Or am I missing something? > > > > A new registry would be fine with me, if people would bother > > > registrering stuff in it. > > > > Another problem is that most GSS implementations define OIDs at compile- > > time (correct me If I'm wrong please!) so if you need to add an attribu= te > > then you need to redeploy your app which is a definite non-starter. > > Attributes need to be able to change at configure-time for apps. > > Hmmm, no, you can add OIDs at run-time. There's a pair of deprecated > functions, gss_oid_to_str() and gss_str_to_oid(), that help with this, > but I don't see why they should have been deprecated (basically, it made > it possible to implement gss_release_oid() as a no-op, but the memory > mgmt can be dealt with anyways, so we can always undeprecate these). > > Nico So there is a way to keep oids in play. I guess we need other opinions on un-deprecating those...=20 Cheers Leif --nextPart2586657.8X430JLprF 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) iEYEABECAAYFAkm4xFQACgkQ8Jx8FtbMZneKVACbBtpaWNt8W0p7euL8xXzfE6CG apIAoI8eK6Hp+1Lh0zSauBWhaUzW0bCi =Auz2 -----END PGP SIGNATURE----- --nextPart2586657.8X430JLprF-- From leifj@it.su.se Thu Mar 12 01:26: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 048233A68F7 for ; Thu, 12 Mar 2009 01:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, 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 qtHtvo6lt1cp for ; Thu, 12 Mar 2009 01:26:08 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 9AE833A681F for ; Thu, 12 Mar 2009 01:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 269123D673; Thu, 12 Mar 2009 09:26:45 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25845-01-67; Thu, 12 Mar 2009 09:26:44 +0100 (CET) Received: from k2.mnt.se (wavelan-97.vlan-102.publik.su.se [77.238.33.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 0A83A3D5DA; Thu, 12 Mar 2009 09:26:44 +0100 (CET) From: Leif Johansson To: Nicolas Williams Subject: Re: naming extensions issues Date: Thu, 12 Mar 2009 09:26:39 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903081732.22196.leifj@it.su.se> <200903110949.12547.leifj@it.su.se> <20090311203633.GM9992@Sun.COM> In-Reply-To: <20090311203633.GM9992@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10966131.OURuQZqxRe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903120926.43518.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 08:26:10 -0000 --nextPart10966131.OURuQZqxRe Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 March 2009 21:36:34 Nicolas Williams wrote: > On Wed, Mar 11, 2009 at 09:49:12AM +0100, Leif Johansson wrote: > > > > Negative assertions are dangerous (I claim with my poker face on) If > > > > there isn't a use-case for them I think they should be removed on > > > > general principle. At least there should be a single example of a > > > > "native" claims- based identity technology we would like to map to > > > > GSS-API naming extensions where negative assertions are used :) > > > > > > We don't need a "negative" flag, but we do need a "complete" flag so > > > that an application can evaluate negative ACL entries, particularly > > > ones where the subject of the ACE is a group. I believe negative ACL > > > entries with group subjects are dangerous precisely because it's > > > difficult to ensure that full group membership context is always > > > available, but because such ACEs are used we do need a way to convey > > > whether a name's attributes are complete. > > > > I'm not sure I understand this. Are you saying there are negative ACLs > > in the wild that naming extensions need to support? Could you expand on > > the semantics of the complete flag? > > NT/NFSv4/ZFS-style ACLs allow you to have entries that DENY access to > the ACL entry (ACE) subject. > > If the subject of a DENY ACE is a user then that's easy to check for > when doing file access authorization -- you always know the user ID of > the client. > > If the subject of a DENY ACE is a group then you need to know with > certainty whether the client user is a member of that group. > > If krb5 ticket authorization-data includes group membership data for the > client principal then it's crucial to know whether that group membership > list is complete. If it is not complete then the server may want to > deny access to files when evaluating DENY ACEs with groups as subjects. > > The Windows "PAC" contains a user's group memberships. It is also > complete within the user's forest (and, IIRC, groups cannot have members > from other forests). OK I see. The problem is that in many cases it will be impossible to know if the attribute set (eg group membership) represents a complete view of the user. In general the users identity (as represented by the attributes carried by the user) may be spread out over several "attribute providers". The complete flag as I understand it assumes that the attribute provider (eg idp) knows it is authoritative for a user. That may be true in certain situations but in most cases it will not. Of course that doesn't mean the flag is useless :) In non-federated deployments it will still work. I pity the fool (TM) who tries to deploy=20 negative ACLs in a federated setting though :-) > > > > Applications should use symbols to refer to these things. Whether > > > those symbols resolve internally to OIDs or strings I don't really > > > care. If they be strings then don't bother with gss_buffer_t since > > > we're talking about attribute names, which can be C strings in the C > > > API (const char *). > > > > > > I'm not sure that an IANA registry can be avoided though. Can you > > > expand on that? > > > > Because we can refer to existing registries - possibly this is an IANA > > registry registries but in any case it will be a smaller management load > > than a full table of all urn:s people use in SAML (say) mapped to OIDs > > which will be but a small part of the registry if we use OIDs. > > Well, maybe, but I'd like to see concrete examples. Not every use of > naming extensions will be for SAML things... Correct. However OIDs are mappable to strings (eg as URNs) wo=20 requiring the use of tables but the reverse isn't true. Cheers Leif --nextPart10966131.OURuQZqxRe 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) iEYEABECAAYFAkm4xz8ACgkQ8Jx8FtbMZneY2gCfReqhAlu8Ppi0oVIFJraqXvqb OegAmwbLyg/8sW3+VEZLRd7MhroJTwra =DICE -----END PGP SIGNATURE----- --nextPart10966131.OURuQZqxRe-- From Nicolas.Williams@sun.com Thu Mar 12 06:40: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 E91773A68FD for ; Thu, 12 Mar 2009 06:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.406 X-Spam-Level: X-Spam-Status: No, score=-5.406 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, 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 Oc8omIF4Qe39 for ; Thu, 12 Mar 2009 06:40:08 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 150803A6868 for ; Thu, 12 Mar 2009 06:39:59 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2CDeZVF015070 for ; Thu, 12 Mar 2009 13:40:35 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 n2CDeZt3000105 for ; Thu, 12 Mar 2009 07:40:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2CDVRZv022085; Thu, 12 Mar 2009 08:31:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2CDVMCj022084; Thu, 12 Mar 2009 08:31:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Mar 2009 08:31:22 -0500 From: Nicolas Williams To: Leif Johansson Subject: Re: naming extensions issues Message-ID: <20090312133122.GW9992@Sun.COM> References: <200903081732.22196.leifj@it.su.se> <200903110949.12547.leifj@it.su.se> <20090311203633.GM9992@Sun.COM> <200903120926.43518.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903120926.43518.leifj@it.su.se> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:40:12 -0000 On Thu, Mar 12, 2009 at 09:26:39AM +0100, Leif Johansson wrote: > OK I see. The problem is that in many cases it will be impossible to know > if the attribute set (eg group membership) represents a complete view of > the user. In general the users identity (as represented by the attributes > carried by the user) may be spread out over several "attribute providers". I'm perfectly happy if the complete flag is never set in practice (though the PAC is a complete flag, in effect, so if the implementation treats the contents of the PAC as indicidual attributes then the complete flag must be set). > The complete flag as I understand it assumes that the attribute provider > (eg idp) knows it is authoritative for a user. That may be true in certain > situations but in most cases it will not. That's fine. > Of course that doesn't mean the flag is useless :) In non-federated > deployments it will still work. I pity the fool (TM) who tries to deploy > negative ACLs in a federated setting though :-) Negative ACEs with groups as subject are bad. > > > > I'm not sure that an IANA registry can be avoided though. Can you > > > > expand on that? > > > > > > Because we can refer to existing registries - possibly this is an IANA > > > registry registries but in any case it will be a smaller management load > > > than a full table of all urn:s people use in SAML (say) mapped to OIDs > > > which will be but a small part of the registry if we use OIDs. > > > > Well, maybe, but I'd like to see concrete examples. Not every use of > > naming extensions will be for SAML things... > > Correct. However OIDs are mappable to strings (eg as URNs) wo > requiring the use of tables but the reverse isn't true. Yes it is true: you can encode strings of characters as OID arcs (I posted on the SASL WG about this). Nico -- From jhutz@cmu.edu Fri Mar 13 12:41:01 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83323A6987 for ; Fri, 13 Mar 2009 12:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=1.067, 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 kCJyWMoX4U-g for ; Fri, 13 Mar 2009 12:41:01 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 737A13A697D for ; Fri, 13 Mar 2009 12:41:00 -0700 (PDT) Received: from 173-115-106-206.pools.spcsdns.net (173-115-106-206.pools.spcsdns.net [173.115.106.206]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n2DJfY7O027137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 15:41:36 -0400 (EDT) Date: Fri, 13 Mar 2009 15:41:33 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Leif Johansson Subject: Re: naming extensions issues Message-ID: <3B0A0620E5DA11BD8A7B0D58@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903121341.n2CDfFqA017727@raisinbran.srv.cs.cmu.edu> References: <200903081732.22196.leifj@it.su.se> <200903110949.12547.leifj@it.su.se> <20090311203633.GM9992@Sun.COM> <200903120926.43518.leifj@it.su.se> <200903121341.n2CDfFqA017727@raisinbran.srv.cs.cmu.edu> 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.185.41 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: Fri, 13 Mar 2009 19:41:01 -0000 --On Thursday, March 12, 2009 08:31:22 AM -0500 Nicolas Williams wrote: >> Correct. However OIDs are mappable to strings (eg as URNs) wo >> requiring the use of tables but the reverse isn't true. > > Yes it is true: you can encode strings of characters as OID arcs (I > posted on the SASL WG about this). Yes, there is a way to represent any OID as a URN (and thus as a string), and a way to represent any string (incluing a URN) as an OID. However, the mappings in question are not inverses of each other. From leifj@it.su.se Mon Mar 16 14:55: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 AD77B3A6902 for ; Mon, 16 Mar 2009 14:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_SE=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 SePLdCI4pjSS for ; Mon, 16 Mar 2009 14:55:35 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id E83DC3A680A for ; Mon, 16 Mar 2009 14:55:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id F41283C136; Mon, 16 Mar 2009 22:56:14 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15805-01-35; Mon, 16 Mar 2009 22:56:14 +0100 (CET) Received: from k2.mnt.se (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 5993F3C14E; Mon, 16 Mar 2009 22:56:14 +0100 (CET) From: Leif Johansson To: Jeffrey Hutzelman Subject: Re: naming extensions issues Date: Mon, 16 Mar 2009 22:56:12 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903081732.22196.leifj@it.su.se> <200903121341.n2CDfFqA017727@raisinbran.srv.cs.cmu.edu> <3B0A0620E5DA11BD8A7B0D58@atlantis.pc.cs.cmu.edu> In-Reply-To: <3B0A0620E5DA11BD8A7B0D58@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9997669.6jtmt67U8h"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903162256.12896.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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: Mon, 16 Mar 2009 21:55:35 -0000 --nextPart9997669.6jtmt67U8h Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline > Yes, there is a way to represent any OID as a URN (and thus as a string), > and a way to represent any string (incluing a URN) as an OID. However, the > mappings in question are not inverses of each other. The sheer geeky-ness of the thing boggles the mind :-) and yet we are not any closer to consensus. Cheers Leif --nextPart9997669.6jtmt67U8h 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) iEYEABECAAYFAkm+yvwACgkQ8Jx8FtbMZndmcwCcD9o+1fBhwlTpso5xlHFG7s3a Lv4AoMCWmd5YXT54RblOGPyTIC13poUO =B8uZ -----END PGP SIGNATURE----- --nextPart9997669.6jtmt67U8h-- From Nicolas.Williams@sun.com Mon Mar 16 15:17: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 4B9FA3A68ED for ; Mon, 16 Mar 2009 15:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.352, 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 HApy-SIycvmQ for ; Mon, 16 Mar 2009 15:17:23 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 7ABFF3A691A for ; Mon, 16 Mar 2009 15:17:23 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2GMI5Lv026792 for ; Mon, 16 Mar 2009 22:18:05 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n2GMI4Wi032043 for ; Mon, 16 Mar 2009 16:18:04 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2GM1NtW026498; Mon, 16 Mar 2009 17:01:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2GM1KEn026497; Mon, 16 Mar 2009 17:01:20 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 16 Mar 2009 17:01:20 -0500 From: Nicolas Williams To: Leif Johansson Subject: Re: naming extensions issues Message-ID: <20090316220120.GO9992@Sun.COM> References: <200903081732.22196.leifj@it.su.se> <200903121341.n2CDfFqA017727@raisinbran.srv.cs.cmu.edu> <3B0A0620E5DA11BD8A7B0D58@atlantis.pc.cs.cmu.edu> <200903162256.12896.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903162256.12896.leifj@it.su.se> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Jeffrey Hutzelman 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, 16 Mar 2009 22:17:24 -0000 On Mon, Mar 16, 2009 at 10:56:12PM +0100, Leif Johansson wrote: > > > Yes, there is a way to represent any OID as a URN (and thus as a string), > > and a way to represent any string (incluing a URN) as an OID. However, the > > mappings in question are not inverses of each other. > > The sheer geeky-ness of the thing boggles the mind :-) and yet we are not > any closer to consensus. Make a proposal. Include a C bindings snippet. From Josh.Howlett@ja.net Wed Mar 18 10:11: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 2E6CF28C1C0 for ; Wed, 18 Mar 2009 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 OZbZdUyhTStz for ; Wed, 18 Mar 2009 10:11:31 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 457FE28C1B7 for ; Wed, 18 Mar 2009 10:11:31 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LjzJO-00066r-Lc for kitten@ietf.org; Wed, 18 Mar 2009 17:12:14 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2C12D4A6B60_9C12B40B for ; Wed, 18 Mar 2009 17:11:28 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 20AD34A6B2E_9C12B40F for ; Wed, 18 Mar 2009 17:11:28 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines for GSS-API mechanism designers Date: Wed, 18 Mar 2009 17:12:12 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43A1F@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <49B8A19C.8060904@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Guidelines for GSS-API mechanism designers Thread-Index: Acmi1i1odR1x/fnYSEGTVWwyoU5hbQFD/kdA References: <6ED388AA006C454BA35B0098396B9BFB04E711A9@uxsrvr20.atlas.ukerna.ac.uk> <49B767DF.5080305@sun.com> <6ED388AA006C454BA35B0098396B9BFB04E71418@uxsrvr20.atlas.ukerna.ac.uk> <49B8A19C.8060904@sun.com> From: "Josh Howlett" To: Cc: Josh Howlett 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 Mar 2009 17:11:32 -0000 > Please post your questions to the list. I'm sure other=20 > people here will be interested in the topic. Ok, here's my first three questions. First, I'm puzzled about the relationship between TLS and GSS-API with respect to their confidentiality and integrity services. I observe that, in the wild, most application that use GSS-API tend to do so only for entity authentication during context establishment, and use TLS for confidentiality and integrity (and sometimes also authentication of the acceptor). For example, Negotiate over HTTPS with an X.509 cipher-suite and authentication of the server certificate is a common configuration. Now, RFC2743 section 1.2.2 does not mandate support for per-message security services. Given this is optional, and no-one seems to use per-message security anyway, what is the motivation for a GSS mechanism designer to address that? I am aware that using GSS-API + TLS in the manner described above can lead to channel binding problems. Are there any other reasons? Secondly, my feeble-minded interpretation of section 4.2 of RFC 4121 is that the design of these per-message tokens (unlike the context-establishment tokens) are independent of Kerberos; and so the same scheme could be used for any mechanism. This interpretation appears to be supported by section 7 of RFC3961 'Use of Kerberos Encryption Outside This Specification'. Is this interpretation correct? Consequently, can a GSS mechanism designer simply point to section 4.2 of RFC 4121 for definitions of per-message security services? Thirdly, if this is the case then I assume that there must be some definition of what constitutes an acceptable base key. I had a look in RFC 3961, but I can't find it. I have concluded that I'm either looking in the wrong place, grossly confused, both of these, or worse. Some clarification on this matter would be greatly appreciated.=20 Many thanks, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Martin.Rex@sap.com Wed Mar 18 17:17: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 C21C228C1F1 for ; Wed, 18 Mar 2009 17:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.341 X-Spam-Level: X-Spam-Status: No, score=-5.341 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_39=0.6, 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 odBEjfYAbAz9 for ; Wed, 18 Mar 2009 17:17:03 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C81FE3A6B3E for ; Wed, 18 Mar 2009 17:17:02 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n2J0HimW024613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 01:17:44 +0100 (MET) From: Martin Rex Message-Id: <200903190017.n2J0Hcfx002911@fs4113.wdf.sap.corp> Subject: Re: Guidelines for GSS-API mechanism designers To: Josh.Howlett@ja.net (Josh Howlett) Date: Thu, 19 Mar 2009 01:17:38 +0100 (MET) In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04F43A1F@uxsrvr20.atlas.ukerna.ac.uk> from "Josh Howlett" at Mar 18, 9 05:12:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: kitten@ietf.org, Josh.Howlett@ja.net X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:17:04 -0000 Hi Josh, Anything answers I can think of are neither simple nor short... (you probably expected that...) Josh Howlett wrote: > > First, I'm puzzled about the relationship between TLS and GSS-API with > respect to their confidentiality and integrity services. There actually is NO real relationship between TLS and GSS-API. The two were designed as entirely independent solutions to substantially different problem spaces. The reason why they may look similar is that they both apply to "online" communication between two communication peers. Another similiarity (at least during the childhood of GSS-API) was the use of cryptographic algorithms for - verification of a cryptograhpic proof for an asserted identity - message protection (integrity and confidentiality) Bottom line, that's all they have in common. In most other areas, TLS and GSS-API have historically had a very different focus and different areas where they excel in, which is why there are more and more environments that ask for the best features of both approaches and come up with combinations of both like the one you found. SSL/TLS: focus on many many unrelated end entities focus on internet (open untrusted networks), focus on encrypted communication channel secure client authentication (by TLS) rarely used => in general no client TLS credential available in many environments server is only identified, not authenticated - server TLS credential only used for secure key-exchange of SSL handshake. focus on wire-format focus on interoperability between packaged apps of independent vendors SSL/TLS encompasses/wraps then entire communication, ususally it is another ISO layer 4 protocol above TCP strong ties to the underlying transport GSS-API: focus on homogeneous, centrally administrated users (or realms thereof) focus on secure authentication of the client => GSS-API client credential required in many environments server is only identified, not authenticated => (real) GSS-API server credential might be optional focus on Application programming Interface the absolute minimum of wire-format (the generic framing of the initial context-level token). focus on single-source applications for use in a distributed environment focus on the possibility to add GSS-API tokens in a transparent and backwards compatibile fashion at arbitrary protocol layers to existing apps. GSS-API is only half-a-layer in the OSI model, it must be combined with some kind of application specific transport protocol semantics (usually PDU+semantics, but at the minimum semantics). focus on adding secure authentication and secure communication capabilities into applications with the possibility to re-use an already existing authentication infrastructure TLS was originally born under the name SSL in the home of Netscape, with the purpose of providing an encrypted communication channel between a web browser and a web server (both available as products from Netscape back then) for use in the internet between independent end entities. In order to meet crypto export regulations, SSL was only neutered down to 40-bit RC4, 512-bit RSA EXPORTable ciphersuites. GSS-API was originally born in a combined effort of several Unix vendors http://en.wikipedia.org/wiki/Distributed_Computing_Environment DCE itself is an extension of the Kerberos 5 protocol. In the original GSS-API (v1) design a GSS-API mechanism was assumed to provide at minimum a secure non-disclosing authentication of the client to the server plus message integrity protection facilities. In order to meet crypto export regulations, GSS-API was neutered from the requirement to provide message confidentiality protection for application data (aka encryption). The idea to allow GSS-API mechanism without message integrity protection materialized much later (during GSS-API v2 discussion), in a kind of surprise during an IETF meeting when a mechanism without that functionality was presented. :) The reason why the designers of GSS-API (v1) never thought about GSS-API mechanisms without at least message integrity protection is that these are real security problems by itself when communicating over a communication channel that is not tamper-proof. Technically, one can build a GSS-API on top of a disclosing authentication scheme -- in which case the absence of message protection facilities should not come as a surprise... The reason why GSS-API was adopted in some of the areas was not in order to immediately solve open security problems, but instead to first move to a common API and obtain the option to replace an existing insecure authentication scheme with a secure one without further app modifications in the future. However, if no message protection (which is cryptographically bound to the the authentication process) is applied to the application data following the authentication, then an attacker might modify that application data in transit while it traverses insecure communication channels and neither of the communication peers will be able to detect such modification prior to processing the data/messages. > > I observe that, in the wild, most application that use GSS-API tend to > do so only for entity authentication during context establishment, and > use TLS for confidentiality and integrity (and sometimes also > authentication of the acceptor). For example, Negotiate over HTTPS with > an X.509 cipher-suite and authentication of the server certificate is a > common configuration. That is probably what it looks like to you. Historically, the application started with an application-level and application-specific authentication (e.g. HTTP basic, HTTP digest or form based authentication). Then the possibility to use TLS was added to the application or application-hosting Web-Server. In order to take the burden of "creation/assignment, distribution and verification" of client authentication off the shoulders of the application and to replace it with secure authentication there were two possible approaches: either start using TLS with client credentials (X.509 certs) -- or try to leverage the use of an existing authentication infrastructure -- which today comes often with GSS-API as one of its interfaces. If your clients are members of a centrally adminstrated authentication infrastructure already (and in particular, if that authentication infrastructure does not use X.509 certs for authentication), then the TLS client cert approach is probably not what you are looking for. If one is already using a GSS-API based authentication infrastructure that is based on X.509 certs, then the solution is usually to make those credentials accessible to the SSL/TLS protocol stacks of the client software (e.g. Web Browsers) of your users. That's what we did 9 years ago. > > Now, RFC2743 section 1.2.2 does not mandate support for per-message > security services. Given this is optional, and no-one seems to use > per-message security anyway, what is the motivation for a GSS mechanism > designer to address that? > > I am aware that using GSS-API + TLS in the manner described above can > lead to channel binding problems. Are there any other reasons? Well, there are actually a number of subtle ramifications (read: security vulnerabilities and potential security vulnerabilities) if there is no cryptographic binding between the message integrity check on the application data and the authentication procedure. > > Secondly, my feeble-minded interpretation of section 4.2 of RFC 4121 is > that the design of these per-message tokens (unlike the > context-establishment tokens) are independent of Kerberos; and so the > same scheme could be used for any mechanism. In theory, yes, one can do that (reuse per-message PDUs of an existing gssapi mechanism for a new gssapi mechanism). Most of the time when a "new" gssapi mechanism is designed, it is actually the wrapping of an existing authentication system or existing authentication technology and comes with PDUs for integrity and confidentiality protection of application data. So the only thing that the "new gssapi mechanism" adds to the picture is the wrapping/unwrapping from native tokens into GSS-API context-level and per-message tokens. It is usually a good idea to reuse existing and proven cryptographic protocols and protocol PDUs rather then to invent them from scratch (and fail). However, arbitrarily mixing and matching PDUs from different existing cryptographic protocols might sometimes get you into trouble. > > This interpretation appears > to be supported by section 7 of RFC3961 'Use of Kerberos Encryption > Outside This Specification'. Is this interpretation correct? > Consequently, can a GSS mechanism designer simply point to section 4.2 > of RFC 4121 for definitions of per-message security services? > > Thirdly, if this is the case then I assume that there must be some > definition of what constitutes an acceptable base key. I had a look in > RFC 3961, but I can't find it. I have concluded that I'm either looking > in the wrong place, grossly confused, both of these, or worse. Some > clarification on this matter would be greatly appreciated. I'm not a Kerberos protocol wrangler, so I'm having difficulties commenting on this. RFC-4121 section 4.2 does not seem to define per-message security services. I'm more familiar with the predecessor of rfc-4121: rfc-1964 and that did not (newly) define per-message security services, but instead, it defined how to map/convert exising Kerberos PDUs to and from GSS-API context-level and per-message tokens. -Martin From Josh.Howlett@ja.net Thu Mar 19 04:31: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 6FC843A69AB for ; Thu, 19 Mar 2009 04:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 UykYUdGkXSip for ; Thu, 19 Mar 2009 04:31:52 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 79C3A3A6873 for ; Thu, 19 Mar 2009 04:31:52 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LkGUG-0006d5-Po for kitten@ietf.org; Thu, 19 Mar 2009 11:32:36 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CA71D4A6B66_9C22D24B for ; Thu, 19 Mar 2009 11:31:48 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id A66C14A6B62_9C22D24F for ; Thu, 19 Mar 2009 11:31:48 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines for GSS-API mechanism designers Date: Thu, 19 Mar 2009 11:32:34 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43AF0@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <200903190017.n2J0Hcfx002911@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Guidelines for GSS-API mechanism designers Thread-Index: AcmoKCfkhFMDmgonSPyU9uiwCg05uQAVHLcw References: <6ED388AA006C454BA35B0098396B9BFB04F43A1F@uxsrvr20.atlas.ukerna.ac.uk>from "Josh Howlett" at Mar 18, 9 05:12:12 pm <200903190017.n2J0Hcfx002911@fs4113.wdf.sap.corp> From: "Josh Howlett" To: Cc: Josh Howlett 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, 19 Mar 2009 11:31:53 -0000 Hi Martin, > Anything answers I can think of are neither simple nor short... > (you probably expected that...) Indeed, and I am grateful for your detailed response. > > Secondly, my feeble-minded interpretation of section 4.2 of=20 > RFC 4121=20 > > is that the design of these per-message tokens (unlike the=20 > > context-establishment tokens) are independent of Kerberos;=20 > and so the=20 > > same scheme could be used for any mechanism. > > .............. > > It is usually a good idea to reuse existing and proven cryptographic > protocols and protocol PDUs rather then to invent them from scratch > (and fail). However, arbitrarily mixing and matching PDUs from > different existing cryptographic protocols might sometimes get > you into trouble. I infer from this that, in general, the GSS community would in principle support re-use of RFC4121 per-message PDUs for another mechanism, where it makes sense. Is that a reasonable summary? > > This interpretation appears > > to be supported by section 7 of RFC3961 'Use of Kerberos Encryption > > Outside This Specification'. Is this interpretation correct? > > Consequently, can a GSS mechanism designer simply point to=20 > section 4.2 > > of RFC 4121 for definitions of per-message security services? > >=20 > > Thirdly, if this is the case then I assume that there must be some > > definition of what constitutes an acceptable base key. I=20 > had a look in > > RFC 3961, but I can't find it. I have concluded that I'm=20 > either looking > > in the wrong place, grossly confused, both of these, or worse. Some > > clarification on this matter would be greatly appreciated.=20 >=20 > I'm not a Kerberos protocol wrangler, so I'm having difficulties > commenting on this. >=20 > RFC-4121 section 4.2 does not seem to define per-message=20 > security services. You're right, the question that I asked didn't make sense (I think I mixed up the definition of a PDU (section 4.2 of RFC4121) with the algorithms that protect the data within those PDUs (RFC3961)). Let me try again; hopefully this makes more sense. Assuming that the inference that I stated above is correct (the general desirability of re-using per-message PDUs), I presume that this can also be extended to the re-use of the algorithms defined in RFC3961. This is certainly implied by section 7 of that document ('Use of Kerberos Encryption Outside This Specification'). However, to use RFC3961 security services in other contexts seems (to me) to require that there is some definition of what constitutes an appropriate base-key. RFC3961 does not appear to explicitly define the properties of an appropriate base key. I assume that it is the sub-session key (or a derivation thereof), but I can't find this explicitly called out. In any case, it would be useful to know what, if any, expectations of this key exist. The reason I ask is that, for an EAP mechanism, the GSS peers will both be wielding an EAP MSK at the conclusion of context establishment and I need to understand how that is best exposed to RFC3961-like security services. best regards, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From leifj@it.su.se Thu Mar 19 05:08:08 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 B17BE3A6814 for ; Thu, 19 Mar 2009 05:08:08 -0700 (PDT) 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_SE=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 uQ7Xw2otyUEo for ; Thu, 19 Mar 2009 05:08:08 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id E552A3A6800 for ; Thu, 19 Mar 2009 05:08:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 6C4BD3C09A; Thu, 19 Mar 2009 13:08:51 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11461-01-66; Thu, 19 Mar 2009 13:08:51 +0100 (CET) Received: from k2.mnt.se (dhcp246.it.su.se [130.237.95.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 7E67C3BE9B; Thu, 19 Mar 2009 13:08:50 +0100 (CET) From: Leif Johansson To: Nicolas Williams Subject: Re: naming extensions issues Date: Thu, 19 Mar 2009 13:08:44 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903081732.22196.leifj@it.su.se> <200903162256.12896.leifj@it.su.se> <20090316220120.GO9992@Sun.COM> In-Reply-To: <20090316220120.GO9992@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1401616.DVy9ep89Xb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903191308.48215.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: kitten@ietf.org, Jeffrey Hutzelman 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, 19 Mar 2009 12:08:08 -0000 --nextPart1401616.DVy9ep89Xb Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 16 March 2009 23:01:20 Nicolas Williams wrote: > On Mon, Mar 16, 2009 at 10:56:12PM +0100, Leif Johansson wrote: > > > Yes, there is a way to represent any OID as a URN (and thus as a > > > string), and a way to represent any string (incluing a URN) as an OID= =2E=20 > > > However, the mappings in question are not inverses of each other. > > > > The sheer geeky-ness of the thing boggles the mind :-) and yet we are n= ot > > any closer to consensus. > > Make a proposal. Include a C bindings snippet. My proposal is that we use const char * and leave it up to the implementati= on to decide how to interpret the attribute but that it SHOULD be either a str= ing=20 representation of an OID, a URN or a URI (those can easily be distinguished from each other). Cheers Leif --nextPart1401616.DVy9ep89Xb 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) iEYEABECAAYFAknCNcwACgkQ8Jx8FtbMZndacwCfS8bccTsLVbMEKfwXiNOH1Pwb 8AQAn1aIi1vbMu/+BUQeKOhTOtA80WQX =YO1n -----END PGP SIGNATURE----- --nextPart1401616.DVy9ep89Xb-- From Josh.Howlett@ja.net Thu Mar 19 15:28:25 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 344DF3A6991 for ; Thu, 19 Mar 2009 15:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 W0pdWsbfheKQ for ; Thu, 19 Mar 2009 15:28:24 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 5C03E3A659B for ; Thu, 19 Mar 2009 15:28:24 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LkQjd-0007DL-6Y for kitten@ietf.org; Thu, 19 Mar 2009 22:29:09 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5148B4A6B29_9C2C704B for ; Thu, 19 Mar 2009 22:28:20 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 3FBC04A6A7D_9C2C704F for ; Thu, 19 Mar 2009 22:28:20 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: TOK_ID in the K5 mechanism? Date: Thu, 19 Mar 2009 22:29:07 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43C04@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TOK_ID in the K5 mechanism? Thread-Index: Acmo4h3wFB0red4DQ3y8fh8pkjhERQ== From: "Josh Howlett" To: Cc: Josh Howlett 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, 19 Mar 2009 22:28:25 -0000 Could someone kindly explain the purpose of the TOK_ID required by the K5 m= echanism (RFC4121)? To the na=EFve reader, it seems that innerField is self= -describing, in that it contains an unambigous Kerberos message. I found a reference to this in the Acknowledgments section; unfortunately, = the meaning of the accompanying explanation eludes me (I don't understand h= ow the pseudo ASN.1 header would get encoded in a PDU, given that section 3= .1 of RFC2743 explicitly states that it is descriptive only). Many thanks, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Nicolas.Williams@sun.com Thu Mar 19 15:45:49 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E33B3A6AAF for ; Thu, 19 Mar 2009 15:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.675 X-Spam-Level: X-Spam-Status: No, score=-5.675 tagged_above=-999 required=5 tests=[AWL=0.371, 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 wY4c8xAUjr68 for ; Thu, 19 Mar 2009 15:45:48 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 5974E3A6902 for ; Thu, 19 Mar 2009 15:45:48 -0700 (PDT) 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 n2JMkYmU001643 for ; Thu, 19 Mar 2009 22:46: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 n2JMkX8D051532 for ; Thu, 19 Mar 2009 16:46:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2JMbOE6029624; Thu, 19 Mar 2009 17:37:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2JMbIPn029623; Thu, 19 Mar 2009 17:37:18 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Mar 2009 17:37:18 -0500 From: Nicolas Williams To: Josh Howlett Subject: Re: TOK_ID in the K5 mechanism? Message-ID: <20090319223717.GB9992@Sun.COM> References: <6ED388AA006C454BA35B0098396B9BFB04F43C04@uxsrvr20.atlas.ukerna.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04F43C04@uxsrvr20.atlas.ukerna.ac.uk> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 22:45:49 -0000 On Thu, Mar 19, 2009 at 10:29:07PM +0000, Josh Howlett wrote: > Could someone kindly explain the purpose of the TOK_ID required by the > K5 mechanism (RFC4121)? To the naïve reader, it seems that innerField > is self-describing, in that it contains an unambigous Kerberos > message. It's there because it was there in RFC1964. It's there in RFC1964 because... well, I don't know (and I had nothing to do with that :) RFC1964 went way overboard with token headers. It required the RFC2743 section 3.1 initial context token header on every token, not just the initial one, and it added a TOK_ID to all the security context tokens. None of that was needed -- it is and would have been sufficient to use the RFC2743 section 3.1 initial context token header only on the initial context token and TOK_IDs only on the per-message (and context deletion) tokens. RFC4121 removed the need for the RFC2743 section 3.1 initial context token header on the per-message tokens, but kept it for the non-initial context tokens, and it kept the TOK_ID for all context tokens. This change was done for two reasons: a) to reduce the size of per-message tokens and alleviate alignment issues, b) to minimize the amount of change and special-casing that existing implementors of RFC1964 would have to do in order to implement RFC4121. > I found a reference to this in the Acknowledgments section; > unfortunately, the meaning of the accompanying explanation eludes me > (I don't understand how the pseudo ASN.1 header would get encoded in a > PDU, given that section 3.1 of RFC2743 explicitly states that it is > descriptive only). Can you quote the specific text? Nico -- From Josh.Howlett@ja.net Fri Mar 20 04:23:45 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 23D4D3A69BB for ; Fri, 20 Mar 2009 04:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 mB9tJ2FmBx+U for ; Fri, 20 Mar 2009 04:23:44 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 4C9683A67DA for ; Fri, 20 Mar 2009 04:23:44 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1Lkcpq-0007du-DE; Fri, 20 Mar 2009 11:24:22 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7C9984A6B63_9C37CB4B; Fri, 20 Mar 2009 11:23:32 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 6476B4A6B3C_9C37CB2F; Fri, 20 Mar 2009 11:23:30 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TOK_ID in the K5 mechanism? Date: Fri, 20 Mar 2009 11:24:19 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43CB4@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <20090319223717.GB9992@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TOK_ID in the K5 mechanism? Thread-Index: Acmo5Jb3Bbo2xOQdSfCiS7/YOypjtwAZ32sQ References: <6ED388AA006C454BA35B0098396B9BFB04F43C04@uxsrvr20.atlas.ukerna.ac.uk> <20090319223717.GB9992@Sun.COM> From: "Josh Howlett" To: "Nicolas Williams" Cc: kitten@ietf.org, Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 11:23:45 -0000 > RFC4121 removed the need for the RFC2743 section 3.1 initial=20 > context token header on the per-message tokens, but kept it=20 > for the non-initial context tokens, and it kept the TOK_ID=20 > for all context tokens. This change was done for two=20 > reasons: a) to reduce the size of per-message tokens and=20 > alleviate alignment issues Ok. So for a new mechanism this type of tagging should, in general, be unnecessary? Or, more generally, the GSS acceptor doesn't care about the contents of innerField; it just passes it off to the appropriate mechanism on the basis of the value of MechType given in the InitialContextToken? > > I found a reference to this in the Acknowledgments section;=20 > > unfortunately, the meaning of the accompanying explanation=20 > eludes me=20 > > (I don't understand how the pseudo ASN.1 header would get=20 > encoded in a=20 > > PDU, given that section 3.1 of RFC2743 explicitly states that it is=20 > > descriptive only). >=20 > Can you quote the specific text? Never mind, I was getting confused again :-| Many thanks, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Fri Mar 20 04:30:14 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 1F4B33A6B0C for ; Fri, 20 Mar 2009 04:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 S1WbzSElC7GZ for ; Fri, 20 Mar 2009 04:30:13 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 580CA3A6A6D for ; Fri, 20 Mar 2009 04:30:13 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LkcwF-0007eo-Gk for kitten@ietf.org; Fri, 20 Mar 2009 11:30:59 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 953484A6B38_9C37E41B for ; Fri, 20 Mar 2009 11:30:09 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 838924A6B2E_9C37E41F for ; Fri, 20 Mar 2009 11:30:09 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Initiator/acceptor client/server distinction Date: Fri, 20 Mar 2009 11:30:58 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43CBD@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initiator/acceptor client/server distinction Thread-Index: AcmpT1beaqf5gc2bQim0EC0OXwIW4A== From: "Josh Howlett" To: Cc: Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 11:30:14 -0000 Does the GSS initiator/acceptor relationship have a 1:1 mapping to the conventional client/server model, or can a client/server adopt either role? I can't find these terms defined in RFC2743, hence my confusion. TIA, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Fri Mar 20 04:48: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 CE40A3A6B14 for ; Fri, 20 Mar 2009 04:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 0RGJRIl5kkAK for ; Fri, 20 Mar 2009 04:48:32 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 027D13A68BF for ; Fri, 20 Mar 2009 04:48:32 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LkdDy-0007gk-6B for kitten@ietf.org; Fri, 20 Mar 2009 11:49:18 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3EBF54A6B64_9C3828CB for ; Fri, 20 Mar 2009 11:48:28 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 2746E4A6B62_9C3828CF for ; Fri, 20 Mar 2009 11:48:28 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Impact of a new GSS mech on applications Date: Fri, 20 Mar 2009 11:49:17 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43CCF@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Impact of a new GSS mech on applications Thread-Index: AcmpUeXMlL+9eDMHSsa2fLaZsYm9zw== From: "Josh Howlett" To: Cc: Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 11:48:32 -0000 I understand that a GSS caller can either use a default mechanism, or stipulate that a particular mechanism is used. >From an application's PoV, what are the implications if a new mechanism appears on the system? For example, it seems to me (speaking from a positive of significant ignorance about GSS) that an application might want impose a common policy on certain features of GSS-API (anonymity, delegation) across all mechanisms. However, it also seems that some mechanism-specific policy might be needed (which mechanisms are permitted, quality of protection, security services). I am curious how contemporary applications deal with this. TIA, josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Fri Mar 20 08:34:56 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 C1D2828C1D1 for ; Fri, 20 Mar 2009 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Ul-odru6ZNdG for ; Fri, 20 Mar 2009 08:34:56 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id DDEB528C143 for ; Fri, 20 Mar 2009 08:34:55 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1Lkgku-0000Cb-EF for kitten@ietf.org; Fri, 20 Mar 2009 15:35:32 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 30F034A6B5E_9C3B792B for ; Fri, 20 Mar 2009 15:34:42 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 22AFD4A6B3A_9C3B792F for ; Fri, 20 Mar 2009 15:34:40 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Initiator/acceptor client/server distinction Date: Fri, 20 Mar 2009 15:34:25 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43D84@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04F43CBD@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initiator/acceptor client/server distinction Thread-Index: AcmpT1beaqf5gc2bQim0EC0OXwIW4AAITsmg References: <6ED388AA006C454BA35B0098396B9BFB04F43CBD@uxsrvr20.atlas.ukerna.ac.uk> From: "Josh Howlett" To: "Josh Howlett" , Cc: Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 15:34:56 -0000 > Does the GSS initiator/acceptor relationship have a 1:1=20 > mapping to the conventional client/server model, or can a=20 > client/server adopt either role? >=20 > I can't find these terms defined in RFC2743, hence my confusion. For the benefit of the archives, I found an answer to this in Wikipedia (so it must be true): http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Progr am_Interface Initiator/acceptor=20 The peer that sends the first token is the initiator; the other the acceptor. Generally, the client program is the initiator while the server is the acceptor. I humbly suggest that the next revision of GSS-API provides a reference model that explains these types of distinctions. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Martin.Rex@sap.com Fri Mar 20 08:36:33 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EBF13A69A2 for ; Fri, 20 Mar 2009 08:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.664 X-Spam-Level: X-Spam-Status: No, score=-5.664 tagged_above=-999 required=5 tests=[AWL=0.585, 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 Hidj784an2yW for ; Fri, 20 Mar 2009 08:36:32 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 662BF3A67F5 for ; Fri, 20 Mar 2009 08:36:32 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n2KFbHFb004951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2009 16:37:17 +0100 (MET) From: Martin Rex Message-Id: <200903201537.n2KFbGsE015063@fs4113.wdf.sap.corp> Subject: Re: Initiator/acceptor client/server distinction To: Josh.Howlett@ja.net (Josh Howlett) Date: Fri, 20 Mar 2009 16:37:16 +0100 (MET) In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04F43CBD@uxsrvr20.atlas.ukerna.ac.uk> from "Josh Howlett" at Mar 20, 9 11:30:58 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: kitten@ietf.org, Josh.Howlett@ja.net X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 15:36:33 -0000 Josh Howlett wrote: > > Does the GSS initiator/acceptor relationship have a 1:1 mapping to the > conventional client/server model, or can a client/server adopt either > role? Much more often no than yes -- I can think of the following problems: - when the authentication of a gssapi mechanism is only uni-directional, i.e. initiator->acceptor, you may not be able to reverse roles - when the credentials of the gssapi mechanism are direction-specific, like with traditional Kerberos 5, where an initiating credential is usually represented by a TGT in a ticket cache and an accepting credential is usually represented by a secret key in a keytab. - when the server doesn't know in advance which client it is talking to, because the initiator has to pass the acceptors name into gss_init_sec_context(), while the acceptor receives the initiators name as output from gss_accept_sec_context() after a successful security handshake. In general, servers don't know in advance who is trying to talk to them and want look up authenticated clients in ACLs after the authentication. Therefore the mapping is usually client = initiator and server = acceptor. It is much easier to exchange the roles of connection initiator and connection acceptor between client and server than it is to reverse the roles of "secure authentication initiator" and "secure authentication acceptor" between client and server. -Martin From Nicolas.Williams@sun.com Fri Mar 20 08:55: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 5915228C223 for ; Fri, 20 Mar 2009 08:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.678 X-Spam-Level: X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.368, 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 fARPxTueHj-0 for ; Fri, 20 Mar 2009 08:55:02 -0700 (PDT) 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 885F328C1EE for ; Fri, 20 Mar 2009 08:55:02 -0700 (PDT) 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 n2KFtYYZ017582 for ; Fri, 20 Mar 2009 15:55: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 n2KFtYk2034786 for ; Fri, 20 Mar 2009 09:55:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2KFkNQG000055; Fri, 20 Mar 2009 10:46:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2KFkGgF000054; Fri, 20 Mar 2009 10:46:16 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 20 Mar 2009 10:46:16 -0500 From: Nicolas Williams To: Josh Howlett Subject: Re: TOK_ID in the K5 mechanism? Message-ID: <20090320154616.GF9992@Sun.COM> References: <6ED388AA006C454BA35B0098396B9BFB04F43C04@uxsrvr20.atlas.ukerna.ac.uk> <20090319223717.GB9992@Sun.COM> <6ED388AA006C454BA35B0098396B9BFB04F43CB4@uxsrvr20.atlas.ukerna.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04F43CB4@uxsrvr20.atlas.ukerna.ac.uk> 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: Fri, 20 Mar 2009 15:55:03 -0000 On Fri, Mar 20, 2009 at 11:24:19AM +0000, Josh Howlett wrote: > > RFC4121 removed the need for the RFC2743 section 3.1 initial > > context token header on the per-message tokens, but kept it > > for the non-initial context tokens, and it kept the TOK_ID > > for all context tokens. This change was done for two > > reasons: a) to reduce the size of per-message tokens and > > alleviate alignment issues > > Ok. So for a new mechanism this type of tagging should, in general, be > unnecessary? Correct. The only token headers defined by the GSS-API are: 1) The RFC2743 section 3.1 initial context token header. This is needed so that a multi-mechanism acceptor can figure out which mechanism should consume this token. Once an initial security context token is successfully consumed the acceptor has state in the form of a partially established security context token (or fully established, in the case of a half round-trip exchange) that it can use to figure out how to consume the next context token from the initiator. 2) The RFC2743 section 3.2 exported name token. It is the application's job to properly frame per-message tokens so that the peer can know: a) how long a token is (and where, on the wire), b) what kind of token it is (MIC or wrap, or not-a-gss-token). (b) is usually implied, and (a) is usually an explicit length field on the wire. > Or, more generally, the GSS acceptor doesn't care about the contents of > innerField; it just passes it off to the appropriate mechanism on the > basis of the value of MechType given in the InitialContextToken? That's exactly right for a GSS-API _library_ (or what we call a "mechglue"). The mechanism itself, of course, does care. [The reason I draw a distinction between mechglue and mechanism here is that if you have a mechglue implementation where the plug-in interface is the GSS-API itself, then your application could link directly with the mechanism, in which case what you called the "GSS acceptor" most definitely does care about the innerToken contents :) -- a subtle distinction, I know.] Nico -- From Josh.Howlett@ja.net Fri Mar 20 09: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 250ED3A6991 for ; Fri, 20 Mar 2009 09:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 a57oq65hMTjL for ; Fri, 20 Mar 2009 09:03:37 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 655D03A6831 for ; Fri, 20 Mar 2009 09:03:37 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LkhCp-0000GS-PG; Fri, 20 Mar 2009 16:04:23 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 795034A6B5D_9C3BE55B; Fri, 20 Mar 2009 16:03:33 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 5AC744A6B3C_9C3BE53F; Fri, 20 Mar 2009 16:03:31 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TOK_ID in the K5 mechanism? Date: Fri, 20 Mar 2009 16:04:19 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43DA8@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <20090320154616.GF9992@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TOK_ID in the K5 mechanism? Thread-Index: AcmpdF2f0icxMa2hQ5mY6hs8YwKUbQAAJLkQ References: <6ED388AA006C454BA35B0098396B9BFB04F43C04@uxsrvr20.atlas.ukerna.ac.uk><20090319223717.GB9992@Sun.COM><6ED388AA006C454BA35B0098396B9BFB04F43CB4@uxsrvr20.atlas.ukerna.ac.uk> <20090320154616.GF9992@Sun.COM> From: "Josh Howlett" To: "Nicolas Williams" Cc: kitten@ietf.org, Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:03:38 -0000 > [The reason I draw a distinction between mechglue and=20 > mechanism here is that if you have a mechglue implementation=20 > where the plug-in interface is the GSS-API itself, then your=20 > application could link directly with the mechanism, in which=20 > case what you called the "GSS acceptor" most definitely does=20 > care about the innerToken contents :) -- a subtle=20 > distinction, I know.] Almost too subtle for a Friday afternoon, but I have managed to grok it :) Many thanks, josh.=20 JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Nicolas.Williams@sun.com Fri Mar 20 09:19: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 059563A6969 for ; Fri, 20 Mar 2009 09:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.681 X-Spam-Level: X-Spam-Status: No, score=-5.681 tagged_above=-999 required=5 tests=[AWL=0.365, 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 VfrBS2oP0BnG for ; Fri, 20 Mar 2009 09:19:14 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id BDBFE3A6BB7 for ; Fri, 20 Mar 2009 09:19:13 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2KGJxE2000175 for ; Fri, 20 Mar 2009 16:19:59 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n2KGJxWt055705 for ; Fri, 20 Mar 2009 10:19:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2KGAm7i000090; Fri, 20 Mar 2009 11:10:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2KGAmjG000089; Fri, 20 Mar 2009 11:10:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 20 Mar 2009 11:10:48 -0500 From: Nicolas Williams To: Josh Howlett Subject: Re: Impact of a new GSS mech on applications Message-ID: <20090320161048.GJ9992@Sun.COM> References: <6ED388AA006C454BA35B0098396B9BFB04F43CCF@uxsrvr20.atlas.ukerna.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04F43CCF@uxsrvr20.atlas.ukerna.ac.uk> 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: Fri, 20 Mar 2009 16:19:15 -0000 On Fri, Mar 20, 2009 at 11:49:17AM +0000, Josh Howlett wrote: > I understand that a GSS caller can either use a default mechanism, or > stipulate that a particular mechanism is used. > > From an application's PoV, what are the implications if a new mechanism > appears on the system? Acceptor applications are not affected. For initiator applications: - If the application uses a specific mechanism: no impact. - If the application negotiates mechanisms: it depends. If the new mechanism is anything like SPNEGO, then it's important that the application not negotiate it. If the new mechanism does not provide per-message tokens but the application expects whatever mechanism it negotiates to provide per-message tokens then it's important that the application not negotiate it. Here it'd be useful to have APIs by which to find out about mechanism attributes like "is a mechanism-negotiation mechanism like SPNEGO," and "supports wrap tokens" and so on. In fact, there's an I-D for this: draft-ietf-kitten-extended-mech-inquiry-04.txt. - If the application uses the default mechanism: it depends on how the mechglue selects the default mechanism. For example, the Solaris libgss is very dumb about this: it uses the first mechanism listed in /etc/gss/mech. A better default mechanism selection would be: the first mechanism listed in /etc/gss/mech.mechanism listed in /etc/gss/mech for which there are initiator credentials. > For example, it seems to me (speaking from a positive of significant > ignorance about GSS) that an application might want impose a common > policy on certain features of GSS-API (anonymity, delegation) across all > mechanisms. However, it also seems that some mechanism-specific policy > might be needed (which mechanisms are permitted, quality of protection, > security services). Yes. > I am curious how contemporary applications deal with this. If they have such needs then they either fail if they negotiate a new mechanism that does not meet those needs, or they must be updated to blacklist such new mechanisms. Thus draft-ietf-kitten-extended-mech-inquiry-04.txt. Nico -- From Josh.Howlett@ja.net Fri Mar 20 09:42: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 CFC953A6A35 for ; Fri, 20 Mar 2009 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 CPArqjNKyiho for ; Fri, 20 Mar 2009 09:42:40 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id D898A3A6903 for ; Fri, 20 Mar 2009 09:42:38 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1Lkhoa-0000Ig-LE; Fri, 20 Mar 2009 16:43:24 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4EA144A6B2E_9C3C77AB; Fri, 20 Mar 2009 16:42:34 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 391784A6A7D_9C3C778F; Fri, 20 Mar 2009 16:42:32 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Impact of a new GSS mech on applications Date: Fri, 20 Mar 2009 16:43:20 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43DCE@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <20090320161048.GJ9992@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Impact of a new GSS mech on applications Thread-Index: Acmpd72CYXaJL0r0RE+PUukyEjMiqwAAXdlw References: <6ED388AA006C454BA35B0098396B9BFB04F43CCF@uxsrvr20.atlas.ukerna.ac.uk> <20090320161048.GJ9992@Sun.COM> From: "Josh Howlett" To: "Nicolas Williams" Cc: kitten@ietf.org, Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:42:40 -0000 > > From an application's PoV, what are the implications if a new=20 > > mechanism appears on the system? >=20 > Acceptor applications are not affected. Doh, of course. > > For example, it seems to me (speaking from a positive of=20 > significant=20 > > ignorance about GSS) that an application might want impose a common=20 > > policy on certain features of GSS-API (anonymity,=20 > delegation) across=20 > > all mechanisms. However, it also seems that some mechanism-specific=20 > > policy might be needed (which mechanisms are permitted, quality of=20 > > protection, security services). >=20 > Yes. > ... > Thus draft-ietf-kitten-extended-mech-inquiry-04.txt. That seems like a good idea to me, given the issues that you enumerated. Thanks again for the great information. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Martin.Rex@sap.com Fri Mar 20 13:33: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 CA71C3A687D for ; Fri, 20 Mar 2009 13:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.706 X-Spam-Level: X-Spam-Status: No, score=-5.706 tagged_above=-999 required=5 tests=[AWL=0.543, 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 GYHBHayJF5nH for ; Fri, 20 Mar 2009 13:33:19 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 757093A6947 for ; Fri, 20 Mar 2009 13:33:18 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n2KKY3dO028160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2009 21:34:03 +0100 (MET) From: Martin Rex Message-Id: <200903202034.n2KKY3Kd006110@fs4113.wdf.sap.corp> Subject: Re: Initiator/acceptor client/server distinction To: Josh.Howlett@ja.net (Josh Howlett) Date: Fri, 20 Mar 2009 21:34:03 +0100 (MET) In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04F43D84@uxsrvr20.atlas.ukerna.ac.uk> from "Josh Howlett" at Mar 20, 9 03:34:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: Josh.Howlett@ja.net, kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 20:33:20 -0000 Josh Howlett wrote: > > > Does the GSS initiator/acceptor relationship have a 1:1 > > mapping to the conventional client/server model, or can a > > client/server adopt either role? > > > > I can't find these terms defined in RFC2743, hence my confusion. > > For the benefit of the archives, I found an answer to this in Wikipedia > (so it must be true): > > http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Progr > am_Interface > > Initiator/acceptor > > The peer that sends the first token is the initiator; the other the > acceptor. This statement is IMHO implied by the terms "initiator" and "acceptor". > > Generally, the client program is the initiator while the server is > the acceptor. I would describe it rather differently: If the two communication peers are of type "client" and "server", then the client will usually assume the role of the initiator and have to assert the servers identity upfront to gss_init_sec_contest, while the server assumes the role of the acceptor and learns the clients authenticated identity as a result of a successful security context establishment. Some people infer that the peer that calls the network connect() is the "client" and the one that calls the network accept() is the server, but that is NOT universally true (we ship some components that do it the other way round). I personally think the use of the terms "client" and "server" would be inappropriate to describe what GSS-API is doing. -Martin From Josh.Howlett@ja.net Sat Mar 21 09:17:52 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 AD9A73A68A6 for ; Sat, 21 Mar 2009 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 5MOY+Dr-U-1E for ; Sat, 21 Mar 2009 09:17:52 -0700 (PDT) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id D6E703A67B6 for ; Sat, 21 Mar 2009 09:17:51 -0700 (PDT) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1Ll3u0-0000dT-KP; Sat, 21 Mar 2009 16:18:28 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5FD1E4A6B31_9C51320B; Sat, 21 Mar 2009 16:17:36 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 41E844A6A7D_9C5131EF; Sat, 21 Mar 2009 16:17:34 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Initiator/acceptor client/server distinction Date: Sat, 21 Mar 2009 16:18:23 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04F43DFF@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <200903202034.n2KKY3Kd006110@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initiator/acceptor client/server distinction Thread-Index: Acmpmzs33dI9BKokQZ6Ocdyi+/YPEgAoCyUw References: <6ED388AA006C454BA35B0098396B9BFB04F43D84@uxsrvr20.atlas.ukerna.ac.uk> from "Josh Howlett" at Mar 20, 9 03:34:25 pm <200903202034.n2KKY3Kd006110@fs4113.wdf.sap.corp> From: "Josh Howlett" To: Cc: kitten@ietf.org, Josh Howlett X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 16:17:52 -0000 > If the two communication peers are of type "client" and=20 > "server", then the client will usually assume the role of the=20 > initiator ... > I personally think the use of the terms "client" and "server" > would be inappropriate to describe what GSS-API is doing. It is this /apparent/ ambiguity that I initially found confusing. As you imply, the terms "client" and "server" probably aren't helpful when trying to understand GSS-API and possibly misleading. Thank you for helping to clarify this for me. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From wleggette@cleversafe.com Sat Mar 21 13:07: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 542443A6AD2 for ; Sat, 21 Mar 2009 13:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 u7CIyuBunh-7 for ; Sat, 21 Mar 2009 13:07:36 -0700 (PDT) Received: from out003.atlarge.net (out004.atlarge.net [129.41.63.10]) by core3.amsl.com (Postfix) with ESMTP id 956053A6960 for ; Sat, 21 Mar 2009 13:07:35 -0700 (PDT) Received: from csi-01-ex.atlarge.net ([10.100.50.47]) by out003.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 15:03:19 -0500 Received: from 10.100.70.6 ([10.100.70.6]) by csi-01-ex.atlarge.net ([10.100.50.47]) via Exchange Front-End Server owa.atlarge.net ([10.100.50.120]) with Microsoft Exchange Server HTTP-DAV ; Sat, 21 Mar 2009 20:03:18 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Sat, 21 Mar 2009 15:08:22 -0500 Subject: GSS-API mechanism review From: Wesley Leggette To: Message-ID: Thread-Topic: GSS-API mechanism review Thread-Index: AcmqYMjY7fFDyvdg/ki+ILyy4v6RVg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Mar 2009 20:03:19.0314 (UTC) FILETIME=[146E8720:01C9AA60] X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 20:07:37 -0000 We are using GSS-API for authentication on a distributed storage system. In order to support basic password authentication using a backing LDAP infrastructure we designed a disclosing password mechanism that supports delegation. The authentication protocol is heavily based on the SSH authentication protocols. 1. Were we duplicating work? Is there an existing password-based GSS-API mechanism? 2. We would like to document and present this protocol and mechanism for review. Is this the correct body to present this information to? Thanks, Wesley Leggette Senior Software Developer Cleversafe, Inc. From Nicolas.Williams@sun.com Sat Mar 21 20:32:45 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 BCCE73A6ABC for ; Sat, 21 Mar 2009 20:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.373, 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 7rqPsfVMmBzT for ; Sat, 21 Mar 2009 20:32:44 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 341E53A6AB8 for ; Sat, 21 Mar 2009 20:32:43 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2M3XUJC009819 for ; Sun, 22 Mar 2009 03:33: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 n2M3XTm1036858 for ; Sat, 21 Mar 2009 21:33:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2M3Gffe001783; Sat, 21 Mar 2009 22:16:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2M3Gdvo001782; Sat, 21 Mar 2009 22:16:39 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 21 Mar 2009 22:16:39 -0500 From: Nicolas Williams To: Wesley Leggette Subject: Re: GSS-API mechanism review Message-ID: <20090322031639.GO9992@Sun.COM> References: 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 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:32:45 -0000 On Sat, Mar 21, 2009 at 03:08:22PM -0500, Wesley Leggette wrote: > We are using GSS-API for authentication on a distributed storage system. In > order to support basic password authentication using a backing LDAP > infrastructure we designed a disclosing password mechanism that supports > delegation. The authentication protocol is heavily based on the SSH > authentication protocols. So, this mechanism does a Diffie-Hellman key exchange with the server authenticated by an RSA/DSA public key signature, and then a password is sent encrypted with a session key derived from the DH exchange? > 1. Were we duplicating work? Is there an existing password-based GSS-API > mechanism? Maybe. There's SCRAM, which we're likely to get consensus on this week. If we do then we'll have a password-based GSS-API mechanism. SCRAM is like DIGEST-MD5, and does not authenticate the server first. SCRAM as proposed also does not support delegation, but it could probably be extended to do so. SCRAM has fairly different properties from what I *think* you're proposing, so, I don't think you're duplicating work. > 2. We would like to document and present this protocol and mechanism for > review. Is this the correct body to present this information to? The KITTEN WG does not do work on mechanisms, but it's as a good forum to start seeking review. Nico -- From wleggette@cleversafe.com Sat Mar 21 21:02:12 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 3579028C1BC for ; Sat, 21 Mar 2009 21:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 GZJ2QAUDD1NE for ; Sat, 21 Mar 2009 21:02:11 -0700 (PDT) Received: from out003.atlarge.net (out004.atlarge.net [129.41.63.10]) by core3.amsl.com (Postfix) with ESMTP id 584FD28C1F1 for ; Sat, 21 Mar 2009 21:02:11 -0700 (PDT) Received: from csi-01-ex.atlarge.net ([10.100.50.47]) by out003.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 22:57:54 -0500 Received: from 10.100.70.6 ([10.100.70.6]) by csi-01-ex.atlarge.net ([10.100.50.47]) via Exchange Front-End Server owa.atlarge.net ([10.100.50.137]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Mar 2009 03:57:54 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Sat, 21 Mar 2009 23:02:57 -0500 Subject: Re: GSS-API mechanism review From: Wesley Leggette To: Nicolas Williams Message-ID: Thread-Topic: GSS-API mechanism review Thread-Index: AcmqoxVE8gKMEc6h10GnJ5g0vD/XXw== In-Reply-To: <20090322031639.GO9992@Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2009 03:57:54.0654 (UTC) FILETIME=[610E97E0:01C9AAA2] Cc: kitten@ietf.org, Jason Resch X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 04:02:12 -0000 On 3/21/09 22:16, "Nicolas Williams" wrote: > On Sat, Mar 21, 2009 at 03:08:22PM -0500, Wesley Leggette wrote: >> We are using GSS-API for authentication on a distributed storage system. In >> order to support basic password authentication using a backing LDAP >> infrastructure we designed a disclosing password mechanism that supports >> delegation. The authentication protocol is heavily based on the SSH >> authentication protocols. > > So, this mechanism does a Diffie-Hellman key exchange with the server > authenticated by an RSA/DSA public key signature, and then a password > is sent encrypted with a session key derived from the DH exchange? > Precisely. >> 1. Were we duplicating work? Is there an existing password-based GSS-API >> mechanism? > > Maybe. There's SCRAM, which we're likely to get consensus on this week. > If we do then we'll have a password-based GSS-API mechanism. SCRAM is > like DIGEST-MD5, and does not authenticate the server first. SCRAM as > proposed also does not support delegation, but it could probably be > extended to do so. > > SCRAM has fairly different properties from what I *think* you're > proposing, so, I don't think you're duplicating work. > Thanks for the reference. I will investigate this. >> 2. We would like to document and present this protocol and mechanism for >> review. Is this the correct body to present this information to? > > The KITTEN WG does not do work on mechanisms, but it's as a good forum > to start seeking review. Thanks. Can you offer any advice on how I should proceed from here? Wesley Leggette From Nicolas.Williams@sun.com Sat Mar 21 21:30:33 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348D03A69F4 for ; Sat, 21 Mar 2009 21:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.370, 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 rMmD-FABpUf0 for ; Sat, 21 Mar 2009 21:30:32 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id AF9853A6839 for ; Sat, 21 Mar 2009 21:30:31 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2M4VJ4E020508 for ; Sun, 22 Mar 2009 04:31:19 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 n2M4VJI4002108 for ; Sat, 21 Mar 2009 22:31:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2M4Ebmc001814; Sat, 21 Mar 2009 23:14:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2M4EX0u001813; Sat, 21 Mar 2009 23:14:33 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 21 Mar 2009 23:14:33 -0500 From: Nicolas Williams To: Wesley Leggette Subject: Re: GSS-API mechanism review Message-ID: <20090322041432.GP9992@Sun.COM> References: <20090322031639.GO9992@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, Jason Resch X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 04:30:33 -0000 On Sat, Mar 21, 2009 at 11:02:57PM -0500, Wesley Leggette wrote: > On 3/21/09 22:16, "Nicolas Williams" wrote: > > So, this mechanism does a Diffie-Hellman key exchange with the server > > authenticated by an RSA/DSA public key signature, and then a password > > is sent encrypted with a session key derived from the DH exchange? > > Precisely. I imagine that delegation is a simple matter of sending the password as is? > > SCRAM has fairly different properties from what I *think* you're > > proposing, so, I don't think you're duplicating work. > > Thanks for the reference. I will investigate this. Actually, I didn't give you a reference, but that's partly because only recently have we begun to reach consensus on how to make SCRAM both, a SASL mechanism and a GSS-API mechanism. I'll submit an I-D that covers that tomorrow, in the mean time you should look at: draft-newman-auth-scram-10.txt > Thanks. Can you offer any advice on how I should proceed from here? Submit an individual Internet-Draft, ask for review on several mailing lists, such as the old SECSH WG mailing list and this one (but set Reply-To so we don't need to keep cross-posting), and follow the individual I-D process. Nico -- From wleggette@cleversafe.com Sun Mar 22 10:57: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 0BA343A689D for ; Sun, 22 Mar 2009 10:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 yGr2OIDB-xuo for ; Sun, 22 Mar 2009 10:57:31 -0700 (PDT) Received: from out003.atlarge.net (out004.atlarge.net [129.41.63.10]) by core3.amsl.com (Postfix) with ESMTP id 41F583A67F6 for ; Sun, 22 Mar 2009 10:57:31 -0700 (PDT) Received: from csi-01-ex.atlarge.net ([10.100.50.47]) by out003.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 12:53:14 -0500 Received: from 10.100.70.6 ([10.100.70.6]) by csi-01-ex.atlarge.net ([10.100.50.47]) via Exchange Front-End Server owa.atlarge.net ([10.100.50.139]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Mar 2009 17:53:13 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Sun, 22 Mar 2009 12:58:18 -0500 Subject: Re: GSS-API mechanism review From: Wesley Leggette To: Nicolas Williams Message-ID: Thread-Topic: GSS-API mechanism review Thread-Index: AcmrF8e2klbhcy7VPEeFFGXJn/ypMA== In-Reply-To: <20090322174143.GQ9992@Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2009 17:53:14.0500 (UTC) FILETIME=[12D02C40:01C9AB17] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.6.1016-16524.004 X-TM-AS-Result: No--7.566800-8.000000-31 Cc: kitten@ietf.org, Jason Resch X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:57:32 -0000 Speaking of SPKM, we were thinking of implementing it, but could not find any reference implementations to ensure compatibility. In any case, because we require delegation, we're thinking of implementing a mechanism that uses RFC 3820 proxy certificates. Does PKU2U provide this? Wesley Leggette On 3/22/09 12:41, "Nicolas Williams" wrote: > Actually, there is some duplication. > > Originally we had SPKM and LIPKEY, where the latter was a simple > username & password sent protected by the former, and the former is a > PKI-based mechanism. > > SPKM was never widely implemented and deployed. There is a replacement > for SPKM coming called PKU2U, which is also a PKI-based mechanism, but > using Kebreros V and PKINIT messages as building blocks. > > So once we get PKU2U it will be possible to define a successor to LIPKEY > but in terms of PKU2U. > > That does not mean that you should not proceed with your mechanism > though. From Nicolas.Williams@sun.com Sun Mar 22 10:57: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 5DEC33A6B54 for ; Sun, 22 Mar 2009 10:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.679 X-Spam-Level: X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=0.367, 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 YbO2XNZn8RIq for ; Sun, 22 Mar 2009 10:57:40 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 67D293A69D4 for ; Sun, 22 Mar 2009 10:57:40 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2MHwSXx021359 for ; Sun, 22 Mar 2009 17:58:28 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n2MHwSMZ055328 for ; Sun, 22 Mar 2009 11:58:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2MHfjq4002074; Sun, 22 Mar 2009 12:41:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2MHfhFj002073; Sun, 22 Mar 2009 12:41:43 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 22 Mar 2009 12:41:43 -0500 From: Nicolas Williams To: Wesley Leggette Subject: Re: GSS-API mechanism review Message-ID: <20090322174143.GQ9992@Sun.COM> References: <20090322031639.GO9992@Sun.COM> <20090322041432.GP9992@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090322041432.GP9992@Sun.COM> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Jason Resch X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:57:41 -0000 Actually, there is some duplication. Originally we had SPKM and LIPKEY, where the latter was a simple username & password sent protected by the former, and the former is a PKI-based mechanism. SPKM was never widely implemented and deployed. There is a replacement for SPKM coming called PKU2U, which is also a PKI-based mechanism, but using Kebreros V and PKINIT messages as building blocks. So once we get PKU2U it will be possible to define a successor to LIPKEY but in terms of PKU2U. That does not mean that you should not proceed with your mechanism though. From lha@kth.se Sun Mar 22 11:09:09 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804393A689D for ; Sun, 22 Mar 2009 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFb-BbEPCo0s for ; Sun, 22 Mar 2009 11:09:08 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 9C94D3A6856 for ; Sun, 22 Mar 2009 11:09:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 5CC8C14C146; Sun, 22 Mar 2009 19:09:26 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FBUh-EmCLjcA; Sun, 22 Mar 2009 19:09:18 +0100 (CET) Received: from [10.0.1.2] (99-52-202-108.lightspeed.snjsca.sbcglobal.net [99.52.202.108]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 0BCB114C133; Sun, 22 Mar 2009 19:09:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1051) Subject: Re: GSS-API mechanism review From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Sun, 22 Mar 2009 11:09:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Wesley Leggette X-Mailer: Apple Mail (2.1051) Cc: "kitten@ietf.org" , Jason Resch , 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: Sun, 22 Mar 2009 18:09:09 -0000 SPKM is based on crypto from 1980/1990 and very under specified. I didn't even bother implementing one since it was so weird and detached from reality. Love 22 mar 2009 kl. 10:58 skrev Wesley Leggette: > > Speaking of SPKM, we were thinking of implementing it, but could not > find > any reference implementations to ensure compatibility. In any case, > because > we require delegation, we're thinking of implementing a mechanism > that uses > RFC 3820 proxy certificates. Does PKU2U provide this? > > > Wesley Leggette > > > > On 3/22/09 12:41, "Nicolas Williams" wrote: > >> Actually, there is some duplication. >> >> Originally we had SPKM and LIPKEY, where the latter was a simple >> username & password sent protected by the former, and the former is a >> PKI-based mechanism. >> >> SPKM was never widely implemented and deployed. There is a >> replacement >> for SPKM coming called PKU2U, which is also a PKI-based mechanism, >> but >> using Kebreros V and PKINIT messages as building blocks. >> >> So once we get PKU2U it will be possible to define a successor to >> LIPKEY >> but in terms of PKU2U. >> >> That does not mean that you should not proceed with your mechanism >> though. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From Nicolas.Williams@sun.com Sun Mar 22 11:55: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 287B53A689E for ; Sun, 22 Mar 2009 11:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.682 X-Spam-Level: X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=0.364, 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 vGmwzSIMSCLl for ; Sun, 22 Mar 2009 11:55:02 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3FC933A67FD for ; Sun, 22 Mar 2009 11:55:02 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2MItpOd014355 for ; Sun, 22 Mar 2009 18:55:51 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 n2MItohF012308 for ; Sun, 22 Mar 2009 12:55:51 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2MIdAmD002087; Sun, 22 Mar 2009 13:39:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2MIdAts002086; Sun, 22 Mar 2009 13:39:10 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 22 Mar 2009 13:39:10 -0500 From: Nicolas Williams To: Wesley Leggette Subject: Re: GSS-API mechanism review Message-ID: <20090322183909.GR9992@Sun.COM> References: <20090322174143.GQ9992@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, Jason Resch X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 18:55:03 -0000 On Sun, Mar 22, 2009 at 12:58:18PM -0500, Wesley Leggette wrote: > Speaking of SPKM, we were thinking of implementing it, but could not find > any reference implementations to ensure compatibility. In any case, because > we require delegation, we're thinking of implementing a mechanism that uses > RFC 3820 proxy certificates. Does PKU2U provide this? No, PKU2U is just PKI based, but LIPKEY does indirectly imply delegation since LIPKEY sends the username and password as is -- protected, yes, but the acceptor gets the cleartext, so there's your delegation :) PKU2U will allow: - anonymous DH - DH + acceptor authentication using certs - DH + initiator and acceptor authentication using certs Nico -- From leifj@it.su.se Wed Mar 25 11:27:22 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 5C7FD3A67DF for ; Wed, 25 Mar 2009 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_SE=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 ajDLuhf6ohgH for ; Wed, 25 Mar 2009 11:27:21 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 470AB3A6D7F for ; Wed, 25 Mar 2009 11:27:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 812073C1B0 for ; Wed, 25 Mar 2009 19:28:12 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30601-01-42 for ; Wed, 25 Mar 2009 19:28:12 +0100 (CET) Received: from k2.mnt.se (dhcp-17de.meeting.ietf.org [130.129.23.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id E946B3BF67 for ; Wed, 25 Mar 2009 19:28:11 +0100 (CET) From: Leif Johansson To: kitten@ietf.org Subject: naming extensions outstanding issues take 2 Date: Wed, 25 Mar 2009 19:28:03 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1285355.udliAL0b3m"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903251928.07425.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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, 25 Mar 2009 18:27:22 -0000 --nextPart1285355.udliAL0b3m Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline So pending confirmation on the list for mapped and negative/complete the=20 remaining issue seems to be what to do about OID/string. I believe it is reasonable to break this issue down in several smaller ones. 1. Is a change warranted at all? 2. If we want "strings", how should they be represented, gss_buffer_t * or= =20 const char * ? I've hear arguments for both - Love I think said he preferred buffers over const char* and Nico may have stated his preference for=20 the latter. 3. if we want "strings", what constraints do we want to place on those=20 strings: any null terminated string or a specific syntax? My suggestion=20 is that we say the string SHOULD contain a URI but MAY contain any string and add a note on how to achieve maximum interoperability. We may want to add a list of mandatory-to-implement attributes associated with each underlying technology. My reason for URIs is that=20 each OID is a URN (urn:oid:...) is a URI so by referencing URIs we=20 will be covering (imo) all the significant use-cases. 4. Do we need a registry? That will depend on the outcome of 3. Cheers Leif=20 --nextPart1285355.udliAL0b3m 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) iEYEABECAAYFAknKd7MACgkQ8Jx8FtbMZncXzwCgumohZAzbtCkzbOF7OPeacUVc 8VIAoMHj29ldTyHIs8++JVAcytQeGhZN =62EJ -----END PGP SIGNATURE----- --nextPart1285355.udliAL0b3m-- From Nicolas.Williams@sun.com Wed Mar 25 12:07: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 486343A6D8F for ; Wed, 25 Mar 2009 12:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.349, 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 sb2hLYGl744w for ; Wed, 25 Mar 2009 12:07:09 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 7410E3A6B80 for ; Wed, 25 Mar 2009 12:07:08 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2PJ80Du006179 for ; Wed, 25 Mar 2009 19:08:00 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 n2PJ80BJ022828 for ; Wed, 25 Mar 2009 13:08:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2PIwlra011517; Wed, 25 Mar 2009 13:58:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2PIwiPo011516; Wed, 25 Mar 2009 13:58:44 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 25 Mar 2009 13:58:44 -0500 From: Nicolas Williams To: Leif Johansson Subject: Re: naming extensions outstanding issues take 2 Message-ID: <20090325185843.GY9992@Sun.COM> References: <200903251928.07425.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903251928.07425.leifj@it.su.se> 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, 25 Mar 2009 19:07:10 -0000 On Wed, Mar 25, 2009 at 07:28:03PM +0100, Leif Johansson wrote: > So pending confirmation on the list for mapped and negative/complete the > remaining issue seems to be what to do about OID/string. I believe it is > reasonable to break this issue down in several smaller ones. > > 1. Is a change warranted at all? > > 2. If we want "strings", how should they be represented, gss_buffer_t * or > const char * ? I've hear arguments for both - Love I think said he preferred > buffers over const char* and Nico may have stated his preference for > the latter. I prefer buffers too because these will be returned by the mechanism and may not be constants: the name may not be known to the mechanism, but derived from a typed-hole in the mechanism's PDUs, like krb5 authz-data. But the buffer contents should be strings -- US-ASCII or UTF-8 strings to be specific. > 3. if we want "strings", what constraints do we want to place on those > strings: any null terminated string or a specific syntax? My suggestion > is that we say the string SHOULD contain a URI but MAY contain any > string and add a note on how to achieve maximum interoperability. We > may want to add a list of mandatory-to-implement attributes associated > with each underlying technology. My reason for URIs is that > each OID is a URN (urn:oid:...) is a URI so by referencing URIs we > will be covering (imo) all the significant use-cases. I'm fine with URIs. > 4. Do we need a registry? That will depend on the outcome of 3. Probably not, or, at least it should not be a requirement that any naming extensions used through this API be registered. From leifj@it.su.se Wed Mar 25 16:18: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 E0B3128C17C for ; Wed, 25 Mar 2009 16:18:34 -0700 (PDT) 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.372, BAYES_00=-2.599, HELO_EQ_SE=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 P5pxRnfnxpyR for ; Wed, 25 Mar 2009 16:18:34 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id C3F1F3A6DB1 for ; Wed, 25 Mar 2009 16:18:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 65B7E3BF29; Thu, 26 Mar 2009 00:19:25 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20852-01-47; Thu, 26 Mar 2009 00:19:25 +0100 (CET) Received: from k2.mnt.se (dhcp-17de.meeting.ietf.org [130.129.23.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id CF9DC3BE6F; Thu, 26 Mar 2009 00:19:24 +0100 (CET) From: Leif Johansson To: Nicolas Williams Subject: Re: naming extensions outstanding issues take 2 Date: Thu, 26 Mar 2009 00:19:15 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903251928.07425.leifj@it.su.se> <20090325185843.GY9992@Sun.COM> In-Reply-To: <20090325185843.GY9992@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2116182.gz3jlCqyNO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903260019.19931.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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, 25 Mar 2009 23:18:35 -0000 --nextPart2116182.gz3jlCqyNO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 25 March 2009 19:58:44 Nicolas Williams wrote: > On Wed, Mar 25, 2009 at 07:28:03PM +0100, Leif Johansson wrote: > > So pending confirmation on the list for mapped and negative/complete the > > remaining issue seems to be what to do about OID/string. I believe it is > > reasonable to break this issue down in several smaller ones. > > > > 1. Is a change warranted at all? > > > > 2. If we want "strings", how should they be represented, gss_buffer_t * > > or const char * ? I've hear arguments for both - Love I think said he > > preferred buffers over const char* and Nico may have stated his > > preference for the latter. > > I prefer buffers too because these will be returned by the mechanism and > may not be constants: the name may not be known to the mechanism, but > derived from a typed-hole in the mechanism's PDUs, like krb5 authz-data. > But the buffer contents should be strings -- US-ASCII or UTF-8 strings > to be specific. > I agree! > > 3. if we want "strings", what constraints do we want to place on those > > strings: any null terminated string or a specific syntax? My suggestion > > is that we say the string SHOULD contain a URI but MAY contain any > > string and add a note on how to achieve maximum interoperability. We > > may want to add a list of mandatory-to-implement attributes associated > > with each underlying technology. My reason for URIs is that > > each OID is a URN (urn:oid:...) is a URI so by referencing URIs we > > will be covering (imo) all the significant use-cases. > > I'm fine with URIs. Good. > > > 4. Do we need a registry? That will depend on the outcome of 3. > > Probably not, or, at least it should not be a requirement that any > naming extensions used through this API be registered. I agree.=20 Dang :-) Cheers Leif --nextPart2116182.gz3jlCqyNO 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) iEYEABECAAYFAknKu/MACgkQ8Jx8FtbMZnf+dwCfW/L4T2kk6W27n6ZoFDiw5hIg LKQAoMlnm86oqCqnknW/9gMSoQYkZbdK =vrVB -----END PGP SIGNATURE----- --nextPart2116182.gz3jlCqyNO-- From root@core3.amsl.com Wed Mar 25 16:45:02 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 16CEC28C26B; Wed, 25 Mar 2009 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-extensions-iana-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090325234502.16CEC28C26B@core3.amsl.com> Date: Wed, 25 Mar 2009 16:45:02 -0700 (PDT) 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, 25 Mar 2009 23:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Namespace Considerations and Registries for GSS-API Extensions Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-extensions-iana-05.txt Pages : 10 Date : 2009-03-25 This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-extensions-iana-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-extensions-iana-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-25164036.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Mar 25 17:00:04 2009 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E4F313A6DBC; Wed, 25 Mar 2009 17:00:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-extended-mech-inquiry-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090326000004.E4F313A6DBC@core3.amsl.com> Date: Wed, 25 Mar 2009 17:00:04 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Extended Generic Security Service Mechanism Inquiry APIs Author(s) : N. Williams Filename : draft-ietf-kitten-extended-mech-inquiry-05.txt Pages : 13 Date : 2009-03-25 This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications. These interfaces include: mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that posses given attributes, and a function for displaying mechanism attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-extended-mech-inquiry-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-extended-mech-inquiry-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-25164527.I-D@ietf.org> --NextPart-- From wleggette@cleversafe.com Wed Mar 25 19:03: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 D80803A6D8A for ; Wed, 25 Mar 2009 19:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 V+p8cv5vcSKn for ; Wed, 25 Mar 2009 19:03:34 -0700 (PDT) Received: from out001.atlarge.net (out001.atlarge.net [129.41.63.69]) by core3.amsl.com (Postfix) with ESMTP id EA65E3A6D66 for ; Wed, 25 Mar 2009 19:03:31 -0700 (PDT) Received: from csi-01-ex.atlarge.net ([10.100.50.47]) by out001.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 20:59:23 -0500 Received: from 10.100.70.6 ([10.100.70.6]) by csi-01-ex.atlarge.net ([10.100.50.47]) via Exchange Front-End Server owa.atlarge.net ([10.100.50.82]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Mar 2009 01:59:08 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Wed, 25 Mar 2009 21:04:16 -0500 Subject: Name type for new mechanism From: Wesley Leggette To: "kitten@ietf.org" Message-ID: Thread-Topic: Name type for new mechanism Thread-Index: Acmttyp55YAi5wgpQ0+9FL54duzcyw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Mar 2009 01:59:23.0171 (UTC) FILETIME=[7BEF6730:01C9ADB6] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.6.1016-16540.004 X-TM-AS-Result: No--1.976200-8.000000-31 Cc: Jason Resch 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, 26 Mar 2009 02:03:34 -0000 I am current writing an I-D for our password mechanism, which we are calling "Basic Password Authentication Mechanism". Our mech requires three name forms: user name, host-based service, and account identifier. My questions: 1. We take "account identifier" to be an account UUID/GUID because we make use of this form in our application. Is it reasonable to require this in a mechanism in general, or is this more a SHOULD sort of thing? 2. We support federated systems and as such allow a "realm" to be indicated. However, our current implementation interprets a user name or service-based host similiarly to Kerberos but uses the OIDs for mechanism-independent name forms. Is this kosher, or should we use mech-specific OIDs? Here's what we're talking about as for User Name Form: -------------------------------------------- 2.1. User Name Form This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) user_name(1)}. The recommended symbolic name for this type is "GSS_BPAM_NT_USER_NAME". This name type is used to indicate a named user on a local, distributed, or federated system. The elements included within this name representation are as follows, proceeding from the beginning of the string: 1. One principal name component. Arbitrary octets may be included within the principal name component, with the following constraints and special considerations: A. The `@` character is restricted. B. The ASCII newline, tab, backspace, null, and other non- printable characters SHOULD NOT be generated. Peers MAY accept such characters. 2. Optionally, a `@` character, signifying that a realm name immediately follows. If no realm name element is included, the local realm name is assumed. The `@` character is restricted from appearing within the realm name. Interpretation of the realm name is application specific. Peers MUST be prepared to interpret a user name without a specified realm. Peers MAY ignore the realm name if a non-federated authentication system is in use. -------------------------------------------- Thanks, Wesley Leggette From Nicolas.Williams@sun.com Wed Mar 25 20:21:22 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 5E86328C19F for ; Wed, 25 Mar 2009 20:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.346, 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 uL8D-2WhzMe4 for ; Wed, 25 Mar 2009 20:21:21 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id C40993A689D for ; Wed, 25 Mar 2009 20:21:20 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2Q3MDAb015002 for ; Thu, 26 Mar 2009 03:22:13 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 n2Q3MCrG025495 for ; Wed, 25 Mar 2009 21:22:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2Q35O2m012044; Wed, 25 Mar 2009 22:05:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2Q35Jac012043; Wed, 25 Mar 2009 22:05:19 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 25 Mar 2009 22:05:19 -0500 From: Nicolas Williams To: Wesley Leggette Subject: Re: Name type for new mechanism Message-ID: <20090326030519.GO9992@Sun.COM> References: 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" , Jason Resch 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, 26 Mar 2009 03:21:22 -0000 On Wed, Mar 25, 2009 at 09:04:16PM -0500, Wesley Leggette wrote: > Our mech requires three name forms: user name, host-based service, and > account identifier. > > My questions: > > 1. We take "account identifier" to be an account UUID/GUID because we make > use of this form in our application. Is it reasonable to require this in a > mechanism in general, or is this more a SHOULD sort of thing? I think it's fine to REQUIRE support for it, but since in any security context there are only two names involved (the initiator's and the acceptor's) the question I find interesting is: When would an application use "user name" and when "account identifier"? > 2. We support federated systems and as such allow a "realm" to be indicated. > However, our current implementation interprets a user name or service-based > host similiarly to Kerberos but uses the OIDs for mechanism-independent name > forms. Is this kosher, or should we use mech-specific OIDs? You should define mechanism-specific name types, or, if these are sufficiently similar to Kerberos V's, then reuse those. But it's probably OK (if not strictly so) for a mechanism implementation to support mechanism-specific syntaxes with GSS_C_NT_USER_NAME (it's certainly for name_type == GSS_C_NO_OID). > Here's what we're talking about as for User Name Form: > > 2.1. User Name Form > > This name form shall be represented by the Object Identifier {iso(1) > member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) > generic(1) user_name(1)}. The recommended symbolic name for this > type is "GSS_BPAM_NT_USER_NAME". > > This name type is used to indicate a named user on a local, > distributed, or federated system. The elements included within this > name representation are as follows, proceeding from the beginning of > the string: > > 1. One principal name component. Arbitrary octets may be included > within the principal name component, with the following > constraints and special considerations: > > A. The `@` character is restricted. > > B. The ASCII newline, tab, backspace, null, and other non- > printable characters SHOULD NOT be generated. Peers MAY > accept such characters. Is the username UTF-8? What stringprep will you use for it? (Same questions re: password.) > 2. Optionally, a `@` character, signifying that a realm name > immediately follows. If no realm name element is included, the > local realm name is assumed. The `@` character is restricted > from appearing within the realm name. It's not so much that '@' in a realm name is problematic, but '@' in a username -- I've seen that be requested, e.g., in the case of SSHv2. Now, typically one can determine a realm from a user's domainname, so this is not really an issue, but if you disallow '@' in realms then you can support: user@ -> user in local realm user@domain@ -> user@domain in local realm user@domain-or-realm -> resolve a realm name user@domain@realm -> user@domain in given realm user@realm@@ -> user in given realm > Interpretation of the realm name is application specific. Peers MUST > be prepared to interpret a user name without a specified realm. > Peers MAY ignore the realm name if a non-federated authentication > system is in use. I find this confusing. If an application specifies a realm then the peer had better know about it, right? Having the acceptor ignore the realm if it doesn't know it seems wrong. Nico -- From jhutz@cmu.edu Thu Mar 26 08:36: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 2098D3A6E00 for ; Thu, 26 Mar 2009 08:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.562 X-Spam-Level: X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=2.038, 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 YKE-uaatuP-6 for ; Thu, 26 Mar 2009 08:36:38 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 1271C3A6ABB for ; Thu, 26 Mar 2009 08:36:38 -0700 (PDT) Received: from dhcp-1245.meeting.ietf.org (dhcp-45d1.meeting.ietf.org [130.129.69.209]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n2QFbHqS007195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 11:37:24 -0400 (EDT) Date: Thu, 26 Mar 2009 08:37:17 -0700 From: Jeffrey Hutzelman To: Nicolas Williams , Leif Johansson Subject: Re: naming extensions outstanding issues take 2 Message-ID: <9A77558C7AC56CC00EE108F0@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903251908.n2PJ86tK018328@mx01.srv.cs.cmu.edu> References: <200903251928.07425.leifj@it.su.se> <200903251908.n2PJ86tK018328@mx01.srv.cs.cmu.edu> 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.185.41 Cc: kitten@ietf.org, jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:36:39 -0000 --On Wednesday, March 25, 2009 01:58:44 PM -0500 Nicolas Williams wrote: >> 2. If we want "strings", how should they be represented, gss_buffer_t * >> or const char * ? I've hear arguments for both - Love I think said he >> preferred buffers over const char* and Nico may have stated his >> preference for the latter. > > I prefer buffers too because these will be returned by the mechanism and > may not be constants: the name may not be known to the mechanism, but > derived from a typed-hole in the mechanism's PDUs, like krb5 authz-data. > But the buffer contents should be strings -- US-ASCII or UTF-8 strings > to be specific. Agree. RFC2744 already defines how memory management works for buffers, and uses them in every case where the API needs to return a string -- there are currently no cases where a char * is used for this. >> 3. if we want "strings", what constraints do we want to place on those >> strings: any null terminated string or a specific syntax? My suggestion >> is that we say the string SHOULD contain a URI but MAY contain any >> string and add a note on how to achieve maximum interoperability. We >> may want to add a list of mandatory-to-implement attributes associated >> with each underlying technology. My reason for URIs is that >> each OID is a URN (urn:oid:...) is a URI so by referencing URIs we >> will be covering (imo) all the significant use-cases. > > I'm fine with URIs. I would just say that they _are_ URI's, rather than playing the "it SHOULD be a URI but use whatever you want" game. All that will do is lead to interop problems. Simply requiring that they always be URI's provides good assurance that there won't be collisions, leaves several avenues open for naming private extensions (register a domain, get an OID arc, etc). It also eliminates the need to create any sort of registry, since it builds on existing registries. -- Jeff From jhutz@cmu.edu Thu Mar 26 08:45:17 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AC43A6A1F for ; Thu, 26 Mar 2009 08:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=1.630, 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 mZlMIfP1KxVw for ; Thu, 26 Mar 2009 08:45:16 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 779BB3A6897 for ; Thu, 26 Mar 2009 08:45:16 -0700 (PDT) Received: from dhcp-1245.meeting.ietf.org (dhcp-45d1.meeting.ietf.org [130.129.69.209]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n2QFjVpj007500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 11:46:03 -0400 (EDT) Date: Thu, 26 Mar 2009 08:45:31 -0700 From: Jeffrey Hutzelman To: Nicolas Williams , Wesley Leggette Subject: Re: Name type for new mechanism Message-ID: In-Reply-To: <200903260322.n2Q3MJAu025843@mx02.srv.cs.cmu.edu> References: <200903260322.n2Q3MJAu025843@mx02.srv.cs.cmu.edu> 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.185.41 Cc: kitten@ietf.org, Jason Resch , jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:45:17 -0000 --On Wednesday, March 25, 2009 10:05:19 PM -0500 Nicolas Williams wrote: >> 2. We support federated systems and as such allow a "realm" to be >> indicated. However, our current implementation interprets a user name or >> service-based host similiarly to Kerberos but uses the OIDs for >> mechanism-independent name forms. Is this kosher, or should we use >> mech-specific OIDs? > > You should define mechanism-specific name types, or, if these are > sufficiently similar to Kerberos V's, then reuse those. But it's > probably OK (if not strictly so) for a mechanism implementation to > support mechanism-specific syntaxes with GSS_C_NT_USER_NAME (it's > certainly for name_type == GSS_C_NO_OID). If the mechanism supports a name type with the syntax and semantics of GSS_C_NT_USER_NAME, then it should use that OID. Kerberos supports a name type that is unique to Kerberos, because it actually _has_ names whose syntax and semantics are unique to Kerberos. A mechanism that identifies users with a simple username should just use GSS_C_NT_USER_NAME. However, the name type described assigns mechanism-specific semantics to the '@' character which are not part of those defined for GSS_C_NT_USER_NAME. Thus, it is a different name type and needs its own OID. > I find this confusing. If an application specifies a realm then the > peer had better know about it, right? Having the acceptor ignore the > realm if it doesn't know it seems wrong. Agree. -- Jeff From leifj@it.su.se Fri Mar 27 10:14: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 0C0E23A6819 for ; Fri, 27 Mar 2009 10:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.001 X-Spam-Level: X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_SE=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 CqvaWUHSlRmM for ; Fri, 27 Mar 2009 10:14:34 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 1FB4A3A6808 for ; Fri, 27 Mar 2009 10:14:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id B72D03BEF7; Fri, 27 Mar 2009 18:15:27 +0100 (CET) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08019-01-59; Fri, 27 Mar 2009 18:15:27 +0100 (CET) Received: from k2.mnt.se (dhcp-17de.meeting.ietf.org [130.129.23.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id E93AE3BEA9; Fri, 27 Mar 2009 18:15:26 +0100 (CET) From: Leif Johansson To: Jeffrey Hutzelman Subject: Re: naming extensions outstanding issues take 2 Date: Fri, 27 Mar 2009 18:15:22 +0100 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200903251928.07425.leifj@it.su.se> <200903251908.n2PJ86tK018328@mx01.srv.cs.cmu.edu> <9A77558C7AC56CC00EE108F0@atlantis.pc.cs.cmu.edu> In-Reply-To: <9A77558C7AC56CC00EE108F0@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1816205.jOfzEaibzc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903271815.23407.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se 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: Fri, 27 Mar 2009 17:14:35 -0000 --nextPart1816205.jOfzEaibzc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > I would just say that they _are_ URI's, rather than playing the "it SHOULD > be a URI but use whatever you want" game. All that will do is lead to > interop problems. Simply requiring that they always be URI's provides go= od > assurance that there won't be collisions, leaves several avenues open for > naming private extensions (register a domain, get an OID arc, etc). It > also eliminates the need to create any sort of registry, since it builds = on > existing registries. > > -- Jeff I guess I agree too - urn:x-foo:bla is just as good an identifier as bla an= d=20 it contains the information that it is experimental in nature.=20 Cheers Leif --nextPart1816205.jOfzEaibzc 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) iEYEABECAAYFAknNCasACgkQ8Jx8FtbMZnf97ACdHAcq8eF00DebncRGS+I7Awr0 OBYAnjXwrUhRWdZBzFTI9hAaGpwClKTi =S2mZ -----END PGP SIGNATURE----- --nextPart1816205.jOfzEaibzc-- From Martin.Rex@sap.com Fri Mar 27 15:10:29 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEAB3A67DB for ; Fri, 27 Mar 2009 15:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.66 X-Spam-Level: X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.589, 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 3A399SZoOdIp for ; Fri, 27 Mar 2009 15:10:28 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4CCBF3A67D8 for ; Fri, 27 Mar 2009 15:10:28 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n2RMBJMX019317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 23:11:19 +0100 (MET) From: Martin Rex Message-Id: <200903272211.n2RMBJiK029628@fs4113.wdf.sap.corp> Subject: Re: Name type for new mechanism To: wleggette@cleversafe.com (Wesley Leggette) Date: Fri, 27 Mar 2009 23:11:19 +0100 (MET) In-Reply-To: from "Wesley Leggette" at Mar 25, 9 09:04:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: kitten@ietf.org, jresch@cleversafe.com X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:10:29 -0000 Wesley Leggette wrote: > > I am current writing an I-D for our password mechanism, which we are calling > "Basic Password Authentication Mechanism". > > Our mech requires three name forms: user name, host-based service, and > account identifier. > > My questions: > > 1. We take "account identifier" to be an account UUID/GUID because we make > use of this form in our application. Is it reasonable to require this in a > mechanism in general, or is this more a SHOULD sort of thing? It is perfectly OK to require specific name type in a gssapi mechanism spec. Such a mechanism-specific nametype MUST use its own nametype OID. If you're the mechanism spec author of a new gssapi mechanism, then you can assign the OID yourself and define the exact semantics. For GSS-API v2, one actually needs two mechanism-specific nametypes defined: one printable and one binary canonical. (In case you're wondering where to get an OID from -- its usually much easier to obtain an entire OID arc for free from the IANA registry SNMP private enterprises, than to officially "lease" an OID arc for a significant yearly fee from your (companies) national ISO member body). The username and userid nametypes in the high-level gssapi spec are specifically for use of the notion of "users" as seen by the local OS, which, on traditional Unix, is a host-local account. The exact semantics of the "username" are dictated by the OS. On Windows, a "username" as seen by the OS is case-INsensitive. The exact syntax and semantics of a mechanism-specific nametype, such as a Kerberos Principal Name is defined by the Kerberos 5 gssapi mechanism. Kerberos Principal Names are case-sensitive. In that respect, - if a Kerberos gssapi mechanism is passed a printable name along with a GSS_C_NT_USER_NAME nametype can process it in an case-insensitive fashion _IF_ usernames are case-insensitive for the underyling OS. - if a Kerberos gssapi mechanism is passed a printable name along with a GSS_C_NT_USER_NAME nametype and parses it as a Kerberos Principal name instead, that is, for inputs to gss_import_name, still under the "be liberal in what you accept" umbrella because of the "similarity" and traditions of how to derive kerberos principal names. - a printable output of gss_display_name() along with GSS_C_NT_USER_NAME should only be done for one of the following: - printable names that were imported with that nametype and are still completely unprocessed - printable names that were imported with that nametype and processed only by username-related functions of the underlying OS - printables names that were originally created from username-related functions of the underlying OS On Windows, the Username as seen by the OS is the representation returned from "GetUserName" or "GetUserNameEx(NameSamCompatible)" (the other Name formats known the GetUserNameEx() would all count as seperate distinct nametypes). - if the representation of a printable name of type GSS_C_NT_USER_NAME is transformed in a mechanism-specific fashion, then the result belongs to a different (mechanism-specific) namespace / nametype. - if a Kerberos gssapi mechanism is passed a printable name along with GSS_C_KRB5_NT_PRINCIPAL_NAME (as defined by rfc1964 2.1.1) and processes it in a case-INsensitive fashion, it is likely broken (I admit that I don't know what kind of hacks were "common" in "krb5_parse_name()" at the time rfc-1964 was published, so the exact meaning of rfc1964 2.1.1 looks quite fuzzy in that respect). - > > 2. We support federated systems and as such allow a "realm" to be indicated. > However, our current implementation interprets a user name or service-based > host similiarly to Kerberos but uses the OIDs for mechanism-independent name > forms. Is this kosher, or should we use mech-specific OIDs? I would strongly recommend that you define a new nametype (and therefore assign a new nametype OID) for that purpose, UNLESS you plan to completely conform to the syntactic rules of an existing mechanism-specific nametype like a Kerberos Principal Name--and use only a normative reference to the Kerberos Principal Name nametype of the Kerberos GSS-API mechanism spec (rfc1964 for the nametype). > > Here's what we're talking about as for User Name Form: > > 2.1. User Name Form > > This name form shall be represented by the Object Identifier {iso(1) > member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) > generic(1) user_name(1)}. The recommended symbolic name for this > type is "GSS_BPAM_NT_USER_NAME". Assigning your own symbolic name is probably a good idea, but you MUST assign your own OID for the nametype, abusing > > This name type is used to indicate a named user on a local, > distributed, or federated system. The elements included within this > name representation are as follows, proceeding from the beginning of > the string: > > 1. One principal name component. Arbitrary octets may be included > within the principal name component, with the following > constraints and special considerations: > > A. The `@` character is restricted. > > B. The ASCII newline, tab, backspace, null, and other non- > printable characters SHOULD NOT be generated. Peers MAY > accept such characters. > > 2. Optionally, a `@` character, signifying that a realm name > immediately follows. If no realm name element is included, the > local realm name is assumed. The `@` character is restricted > from appearing within the realm name. > You can make that part of the definition of a mechanism-specific nametype. In order to implement a "exported binary canonical name" you have to address a few more things: - are your names going to be case-sensitive or case-INsensitive, and if the latter, what is the canonical representation and how is canonicalization to be performed exactly. - what character set or code page will your implementation use, and what is the character set / codepage in the binary canonical names? rfc-2743 (gss-api c-bindings) has a historical affiliation with iso-latin1 > > Interpretation of the realm name is application specific. Peers MUST > be prepared to interpret a user name without a specified realm. > Peers MAY ignore the realm name if a non-federated authentication > system is in use. For the acceptor, this would be "non-portable" behaviour in the GSS-API architecture. In the GSS-API architecture, the acceptor (usually the server) obtains the authenticated name of the initiator as a result of a successfuly security context establishment handshake via the src_name parameter of gss_accept_sec_context(). GSS-API aware "portable" application (Servers) will export that resulting src_name as binary canonical name and look it up in an ACL. On the initiator side it is much more common to start with a memorized non-ambiguous representation of the targets name and use a secure directory service or have a secure transformation of that name be transformed withing gss_init_sec_context() -- in case that the initiator _really_ cares about actually authenticating the acceptor. (It is, however, not so uncommon that initiators care little about target authentication and use some kind of weak identification scheme for the target instead, e.g. by blindly deriving the target/acceptor name from network endpoint addresses, ignore ambiguities, or perform or allow insecure transformations on the name. For simple gss-api mechanisms, which perform only a uni-directional authentication of the initiator to the acceptor, the "target_name" parameter to gss_init_sec_context() may be omitted (per GSS-API v2 spec). If not omitted, it ought to be ignored by the gssapi mechanism. There are gssapi mechanism, such as Kerberos 5 (rfc1964/rfc4121), which always require a correct target_name parameter to be supplied to gss_init_sec_context(), even when ONLY uni-directional authentication is requested and performed. (That is a constraint of the underlying mechanism design.) -Martin