From kitten-bounces@ietf.org Mon Apr 4 16:48:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06154; Mon, 4 Apr 2005 16:48:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYdC-0007XU-9I; Mon, 04 Apr 2005 16:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYEH-0006Yy-Bq; Mon, 04 Apr 2005 16:31:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYEC-0006XW-OY for kitten@megatron.ietf.org; Mon, 04 Apr 2005 16:31:22 -0400 Received: from newodin.ietf.org ([10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01410 for ; Mon, 4 Apr 2005 16:31:19 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DIYEB-0007k0-VD; Mon, 04 Apr 2005 16:31:19 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 04 Apr 2005 16:31:19 -0400 Cc: kitten mailing list , Internet Architecture Board , RFC Editor Subject: Protocol Action: 'The Simple and Protected GSS-API Negotiation Mechanism' to Proposed Standard X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 The IESG has approved the following document: - 'The Simple and Protected GSS-API Negotiation Mechanism ' as a Proposed Standard This document is the product of the Kitten (GSS-API Next Generation) Working Group. The IESG contact persons are Sam Hartman and Russ Housley. Technical Summary This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker forcing the selection of a mechanism not desired by the peers. Working Group Summary At IETF 61, a team of implementors, the WG Chair, and the AD met to validate the approach to providing security and backward compatibility. WGLC in December produced several issues which were subsequently addressed on the mailing list with clear consensus. It is the opinion of the chair that a second WGLC was not required. Consensus was declared on the document on 4 March 2005. Protocol Quality There are three existing implementations of the specified protocol produced by Microsoft, Sun Microsystems and Heimdal although they are not currently available to the public. Interoperability testing has not been reported between implementations of the new specification although participants report that new implementations have been tested against existing SPNEGO implementations. This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification commonly deployed on the Internet. The working group was unable to maintain compatibility with correct implementations of RFC 2478, maintain interoperability with deployed implementations and make reasonable security guarantees. The working group chose to sacrifice interoperability with correct implementations of RFC 2478. This specification was reviewed by Sam Hartman for the IESG. RFC Editor Note Add a reference to RFC 2743 in paragraph 5 of section 1 after the firstmention of per-message integrity services. At the bottom of page 11 insert a warning about ASN.1 encoders. old: This field, if present, contains the service options that are requested to establish the context (the req_flags parameter of GSS_Init_sec_context()). This field is inherited from RFC 2478 and it is not integrity protected. For implementations of this specification the initiator SHOULD omit this reqFlags field, and the acceptor MUST ignore this reqFlags field. new: This field, if present, contains the service options that are requested to establish the context (the req_flags parameter of GSS_Init_sec_context()). This field is inherited from RFC 2478 and it is not integrity protected. For implementations of this specification the initiator SHOULD omit this reqFlags field, and the acceptor MUST ignore this reqFlags field. The size constraint on the ContextFlags ASN.1 type only applies to the abstract type. The ASN.1 DER require that all trailing zero bits be truncated from the encoding of a bit string type whose abstract definition includes named bits. Implementations should not expect to receive exactly 32 bits in an encoding of ContextFlags. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Apr 5 09:13:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18845; Tue, 5 Apr 2005 09:13:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIo0W-0000vC-MT; Tue, 05 Apr 2005 09:22:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DInsA-00073T-By; Tue, 05 Apr 2005 09:13:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIns9-00073O-Qj for kitten@megatron.ietf.org; Tue, 05 Apr 2005 09:13:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18812 for ; Tue, 5 Apr 2005 09:13:35 -0400 (EDT) Received: from luminous.mit.edu ([18.101.1.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIo0I-0000ut-A8 for kitten@ietf.org; Tue, 05 Apr 2005 09:22:03 -0400 Received: by luminous.mit.edu (Postfix, from userid 1000) id 6A79476FE7; Tue, 5 Apr 2005 09:13:33 -0400 (EDT) To: ietf-krb-wg@anl.gov References: <20050331180553.GQ16131@binky.Central.Sun.COM> From: Sam Hartman Date: Tue, 05 Apr 2005 09:13:33 -0400 In-Reply-To: <20050331180553.GQ16131@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 31 Mar 2005 12:05:54 -0600") Message-ID: <87ll7x1i4i.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: Re: enctype negotiation and GSS naming extensions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> At MN I said I did not oppose Larry's Kerberos enctype Nicolas> negotiation proposal. Nicolas> I'm less sure now. Nicolas> You may recall that at the interim meeting at Boulder we Nicolas> decided that extensions would add a typed hole, distinct Nicolas> from authorization-data, to the authenticator and AP-REP. Nicolas> We'd argued over whether it was proper to overload Nicolas> authorization-data and decided that it was not. Nicolas> Larry's proposal overloads authorization-data by using it Nicolas> to transport a client's enctype proposal to the server. Nicolas> I am still inclined to agree that enctype negotiation is Nicolas> an allowable overloading of authorization-data, but the Nicolas> GSS-API naming extensions we're discussing at the KITTEN Nicolas> WG give me pause. I've thought about this for a while and I also think it is reasonable overloading if only because we don't want to tell Larry to wait for extensions. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Apr 5 12:49:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07950; Tue, 5 Apr 2005 12:49:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIrN1-0000Ja-SA; Tue, 05 Apr 2005 12:57:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIrC0-0004eQ-QX; Tue, 05 Apr 2005 12:46:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIrBz-0004eD-DQ for kitten@megatron.ietf.org; Tue, 05 Apr 2005 12:46:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07809 for ; Tue, 5 Apr 2005 12:46:16 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIrKA-0000DV-Bv for kitten@ietf.org; Tue, 05 Apr 2005 12:54:46 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j35GkHX8005346 for ; Tue, 5 Apr 2005 10:46:17 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j35GkCew003502 for ; Tue, 5 Apr 2005 10:46:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j35Gi9NA011172; Tue, 5 Apr 2005 11:44:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j35Gi8oW011171; Tue, 5 Apr 2005 11:44:08 -0500 (CDT) Date: Tue, 5 Apr 2005 11:44:08 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050405164407.GJ16131@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , ietf-krb-wg@anl.gov, kitten@ietf.org References: <20050331180553.GQ16131@binky.Central.Sun.COM> <87ll7x1i4i.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ll7x1i4i.fsf@luminous.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: enctype negotiation and GSS naming extensions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, Apr 05, 2005 at 09:13:33AM -0400, Sam Hartman wrote: > Nicolas> I am still inclined to agree that enctype negotiation is > Nicolas> an allowable overloading of authorization-data, but the > Nicolas> GSS-API naming extensions we're discussing at the KITTEN > Nicolas> WG give me pause. > > I've thought about this for a while and I also think it is reasonable > overloading if only because we don't want to tell Larry to wait for > extensions. Ok, and as a one-time thing a mechanism implementation could filter enctype negotiation AD out in the GSS naming interfaces. I have no remaining objections to Larry's proposal. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Apr 5 13:09:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09449; Tue, 5 Apr 2005 13:09:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIrgr-00010A-4A; Tue, 05 Apr 2005 13:18:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIrVl-0000SB-O9; Tue, 05 Apr 2005 13:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIrVj-0000S6-Sa for kitten@megatron.ietf.org; Tue, 05 Apr 2005 13:06:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09249 for ; Tue, 5 Apr 2005 13:06:40 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIrdu-0000r9-Gr for kitten@ietf.org; Tue, 05 Apr 2005 13:15:11 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 60830E0063; Tue, 5 Apr 2005 13:06:40 -0400 (EDT) To: ietf-krb-wg@anl.gov References: <20050331180553.GQ16131@binky.Central.Sun.COM> <87ll7x1i4i.fsf@luminous.mit.edu> <20050405164407.GJ16131@binky.Central.Sun.COM> From: Sam Hartman Date: Tue, 05 Apr 2005 13:06:40 -0400 In-Reply-To: <20050405164407.GJ16131@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 5 Apr 2005 11:44:08 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org Subject: Re: enctype negotiation and GSS naming extensions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Apr 05, 2005 at 09:13:33AM -0400, Sam Hartman Nicolas> wrote: I am still inclined to agree that enctype Nicolas> negotiation is an allowable overloading of Nicolas> authorization-data, but the GSS-API naming extensions Nicolas> we're discussing at the KITTEN WG give me pause. >> I've thought about this for a while and I also think it is >> reasonable overloading if only because we don't want to tell >> Larry to wait for extensions. Nicolas> Ok, and as a one-time thing a mechanism implementation Nicolas> could filter enctype negotiation AD out in the GSS naming Nicolas> interfaces. Could but should not. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Apr 8 00:57:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12448; Fri, 8 Apr 2005 00:57:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJlhP-0000f4-F7; Fri, 08 Apr 2005 01:06:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlTg-0006pE-Rw; Fri, 08 Apr 2005 00:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlTc-0006ou-7I for kitten@megatron.ietf.org; Fri, 08 Apr 2005 00:52:18 -0400 Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.29.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12188 for ; Fri, 8 Apr 2005 00:52:12 -0400 (EDT) Received: from [10.227.70.101] (user-0cdf825.cable.mindspring.com [24.215.160.69]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j384qDZb018914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 8 Apr 2005 00:52:14 -0400 (EDT) Message-ID: <42560E7B.8070900@columbia.edu> Date: Fri, 08 Apr 2005 00:54:19 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Subject: Proposed Minutes of IETF62 - Please review X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0150026393==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 This is a cryptographically signed message in MIME format. --===============0150026393== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070600020608030307030202" This is a cryptographically signed message in MIME format. --------------ms070600020608030307030202 Content-Type: multipart/mixed; boundary="------------010105070106060302000202" This is a multi-part message in MIME format. --------------010105070106060302000202 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks to Jeff, Nico, and Love for taking notes and scribing. These minutes are really rough but then again the open discussion went so fast that with recordings it was impossible to keep up. Jeffrey Altman --------------010105070106060302000202 Content-Type: text/plain; name="ietf62-kitten-minutes.txt" Content-Disposition: inline; filename="ietf62-kitten-minutes.txt" Content-Transfer-Encoding: 8bit IETF62 Minutes for Kitten Working Group ======================================= Wednesday, March 9 2005 1:00-3:00 Central Standard Time. Chairperson: Jeffrey Altman Thanks to Jeffrey Hutzelman and Nico Williams for Jabber Scribing Thanks to Love Hörnquist Åstrand for taking notes. agenda bashing: no comments Larry Zhu updates on SPNEGO: - sent to IESG, Last Call ends March 22. - implementations include Longhorn beta 1, Heimdal, and a future update to solaris 10 - there is no open issues; please read draft - no questions - first document from kitten, beats the milestone. - a big thanks to Larry Nico Williams update on several documents: - PRF extentions * edits from last meeting folded into -01 * PRF_READY added in -02 * ready for last call (draft-ietf-kitten-gssapi-prf-02.txt) - Kerberos side of PRF, same comments * edits from last meeting folded into -01 * No PRF_READY * don't use PROT_READY * can call PRF as soon as you want. if the PRF isn't ready, the function will return gss_not_avaible. * ready for last call (draft-ietf-kitten-krb5-gssapi-prf-02.txt) - GSS Domain based names * folded in edits from last meeting * Seems to be ready for last call, less review then the PRF documents. should wait if there are some comments. - Kerberos domain names * folded in edits from last meeting * realm derivation changed - realm is derived from the domain part of the domain-based name, not the host part * Seems to be ready for last call, less review then the PRF documents. should wait if there are some comments. - Stackable pseudeo mech and extended mech inquiry APIs * originally a single documetn individual submission draft-williams-gssapi-stackable-pseudo-mechs-00.txt now split into to two: draft-ietf-kitten-extended-mech-inquiry-00.txt draft-ietf-kitten-stackable-pseudo-mechs-00.txt * Both drafts needs review. Esp with the some issues from the document split. * Stackable mechs very simple concept. - Guide to the GSS-APIv3 * Not many changes; just naming draft. - IANA registry draft * currently only has text about what submissions look like. no rules, no initial content. * talked to IANA - they would like to see a section with allocation rules, and an appendix with initial content. * overloading all the information into a single registry may or may not be the right way to do it; I don't know. * like to get some feedback on document * Nico will work with the chair to work out IANA details - Channel bindings draft from NFSv4 WG * for ipsec, we still need to decide what channel bindings are going to be. draft in kitten tells you. this needs some review. * draft not ready for last call * lots of discussion about where the definition of protocol specific bindings belong + hartmans: defining protocol specific channel bindings not in the charter for Kitten or BTNS; and Russ has objected. IPSec is not accepting new work. I think it should be done as ain individual submission. nico: OK, but not what we discussed before. - Comments for Nico: * channel bindings + Love: how can a protocol running on top of gss do channel bindings to gss? + Nico reply: its there in the NFSv4 draft, but could be done better. * IANA + hartmans: uneasy about having to register every gss_ symbol with iana + Chair: this topic needs to go to list, not enough people have read the draft + Matt Peterson: what was IANA's response to being asked to do api registry + Nico: IANA doesn't care about what being registered, then just want to be told how to do it. + Chair: The question is "what do we want to have done by standards actions?" One benefit of registries is having a place people can look + Nico: part of this discussion is to allow for vendor-specific extensions Sam Hartman updates GSS Naming: - draft-ietf-kitten-gss-naming-01.txt - the goal is to be a direction statement to describe the problems we're trying to solve, and approaches we're considering - received a lot of comments from nico - hoping to get comments from Martin Rex, but so far he has never actually responded directly to this draft - I think -02 will be ready for last call. There is one issue I'd like to get some discussion on today. * currrently today, names are atoms - indivisible strings with no structure * one proposal is to turn them into sets and/or sequences + + nico & I think we'll probably need to do that anyway * another proposal... allow us to choose the initiator name based on what target we're talking to. can't currently do that. there is some desire in kerberos to be able to do that * another issue that came up, which we have no closure on yet... + mechanisms that can assert multiple identities + example - X.509 mech, you may have multiple subjectAltName you may want to say which of these names you want to claim for a given context for pure (GSSAPI) v3 mechanisms being used by V3 apps (understand composite names), you probably don't need it do we want something like this for v2 applications + I believe if we can solve that issue, we can last call -02 + nico: how to do that is easy. whether we want to do that is another story I believe spkm had a thing where you could assert a Name in its tokens from a v3 POV, that's irrelevant + unless someone comes forward and says they want to do that, we're not going to. If you care, you need to speak up by end of WGLC. + nico: your draft is informational... + at this time, it doesn't make sense for me to be editor of a document... maybe if my day job had less management work... do we want to poll the room, see people interested in being doc editors? Nico would do a good job, but have lots of docs on your plate + jaltman: I as chair would be more comfortable with load spread out. + matt peterson volunteering someone from his organization + jaltman: no other volunteers Update java and C# bindings - neither of the authors were able to come to this ietf - two new documents: * draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00.txt * draft-ietf-kitten-rfc2853bis-00.txt - c# - submitted from novell, new editor * describes how to morph 2853 java bindings for c# * very little discussion of this doc. novell is in the process of implementing; if others are interested, we'd love to hear your opinions - second doc (RFC2853bis) describes what things in RFC2853 were implemented differently in the Java Class Libraries from what's in the spec. - the document is in good shape. - next step is to merge the two drafts. - nico: do you have an editor for that? - yes; one from Sun (Seema Malkani), one from Novell (Juan Carlos Luciani) - hartmans: a little concerned about style/format of these docs I don't think IETF spec by diff works - the next step is to merge these and rfc2853 into a new doc that would obsolete the old one Open mike: [Editor's note - This discussion did not belong in Kitten] [The contents of this section are stolen from the Jabber logs] joe salowey: the topics that have been coming up lately. ISM WG, enhancements to EAP, EAP has been held to be not applicable we're looking to see if the GSS-API is applicable this is a heads up about interest in this also I'm looking at a number of IETF auth frameworks (SASL, GSS, EAP...), at some point we should look at merging these things some of the GSS v3 enhancements could help (PRF, Naming, ...) sam hartman: so we seem to have some time left joe brought up some interesting points this is very much half-baked, joe's the primary instigator we have a miserable situation in the IETF w/ sec mechs (long list of technologies) and one-off mechs too you know, hash stuff and SSH! and so there's a kind of matrix: if I pick this protocol, what auth techs can I use some are very limited (HTTP has ...) blah, blah and really, the way I want the matrix to look is: regardless of what protocol I pick I can use any mech I want because if I do that I only have to get security right once in my organization so, to get folks thinking about this all these mechs do roughly the same thing you're stopped by small problems of standardization and programming we can do the standardization here so I'm going to compare everything to GSS cause we're here now EAP is like GSS but the server send first token no wrap/unwrap the mechs folks use today have a "key fallout" two keys, actually EAP has a better developed sense of .... naming/channel binding their concept of channel binding may map onto our concept of naming their client ID is weaker than our names but more useful there are stackable pseudo-mechs for EAP and when you do that you need channel bindings between layers they call that cryptographic binding they have a description language for the sec properties of their mechs SASL is like GSS but lacks the PRF, its concept of naming is not as well developed, except when doing GSS it has this funky thing called an authorization ID SASL supports either the client or server as initiators of the exchange this depends on the protocol and the mechanism I think this is even as bad as implementation dependent GSS is a lot like GSS (laughter) For EAP the negotiation model is that the server decides what mech to use for SASL the client generally picks from a list offered by the server w/o downgrade attack ("bidding down") you can abort in the middle of auth for GSS we have SPENGO SPNEGO if you don't know how it works, now's the time to find out! SSH I like the client and server shout at each other offers the client picks one and the server rejects or the key exchange fails the client loses the key exchange ends in two things: a key and an exchange hash and ssh authenticates the server to the client this protocol doesn't have a good concept of naming pubkeys are not named then there's the ssh user authentication protocol this has something like the SASL authz IDthe client tries one mech then the server tells whether we can do this or are done or how to continue the client needs to know what it's tried so it doesn't try again Jeffrey Hutzelman: this is all implementation dependent the client has to keep trying until it can't go on or succeeds Sam: TLS supports pubkey certs, PSK and it supports Kerberos, sortof (details) are there any other actual authentication frameworks in IETF...? MIKEY has some authentication goop Uri Blumenthal: MIKEY is good, but it's multicast specific it's auth deals in multicast key distribution -- Kerberos, EAP, etc... wouldn't be aplicable [details lost] Sam: consider using certs to get access to the multicast stream and consider that MMUSIC uses MIKEY to configure unicast streams if I was an admin I'd be annoyed if MIKEY didn't support the mechanism I wanted [details lost] Sam: I want to be able to use any mechanism in any app Jeffrey Hutzelman: so you want developers to be able to pick the most applicable framework for their protocol, but be able to use any mech Sam: exactly jhutz: so mech gateways Sam: that's one way I want a solution, but I'm not particularly interested in any one of them Joe: I'd rather see these mechs (new mechs) developed together for all frameworks rather than rely on 'gateways' ... Sam: long term I'd like to live in a world where ppl know about gateways and new mechs will work through them all but basically I agree with you that if the gateways are not easily workable, then it might not fly so my assumption is that we can get the gateways to get to the point where they'll meet most folks' needs and then look at mechs-all-at-once Joe: it would be more efficient to design the mechs with these different frameworks in mind Mark: I don't necessarily want to know what mechs I'll be using, I need to know what capabilities I need and what caps each mech offers nico's draft may be a start point it goes a bit deeper than that we need to be able to plug-in mechs the framework implementations have to be pluggable I'm wondering if the WG can do anything about this and refining the semantics of the default mech (GSS_C_NULL_OID) Sam and Mark argue about sysadmin vs. app policy Sam: I think this is moving into a different topic I'm happy to do that, but... Chair: Joe, any more questions? Joe: I'd like to explore the idea of developing mechs in parallel. Sam: want to be able to reuse as much of the mech spec and implementation as possible don't want to have case statements in spec Uri: it would be good if mechs would just perform a few extra tasks export identities, exact crypto protections it uses, key material this is why people are looking at eap Sam: we think we have the generic keying material in the GSS PRF we'd like your review Uri: already sent some comments Nico: quick response to uri for some mechs, we won't know in advance what it uses. e.g. kerberos for others, we know up front what it will use current gssapi qop concept is badly broken Uri: in some protocols, access control is based on identity, accessed object, and under what sort of protection Nico: wow, this is an interesting meeting! Chair: what I was hearing is there's a desire to define a base set of operations on which things can be built is that right? if so, where? not in kitten's charter Bob Morgan: another distinguishing factor is integration model one of sasl's successes is it makes it clear how to integrate into app proto gssapi - not sure what integration model is Sam: gss is clearly a lot of rope all of these frameworks meet different app domains it's interesting that the mechs are very similar, even though the frameworks are very different Bob Morgan: maybe different frameworks come from different needed integration models Sam: if you want an easy integration model, use sasl if you understand your needs really well and have complex requirements, use gss Nico: matt, the default mech/mech set don't have to be global config file as in Solaris the right default is "whatever mechs you have credentials for" the right default mech is "the first one for which you have credentials" Matt Peterson: what if you have creds for more than one mech Nico: either it's nondeterministic or its the first one I know you want this to be app-specific config, but I don't feel not sympathetic - you can make app provide the right oid Matt: ... Nico: what I hear you saying is you want pluggable mechanisms we can't tell people to do that. there are monolithic and pluggable multi-mech implementations, and ther eare single-mech implementations Chair: do you have specific platforms in mind? Matt: for example, aix or some mobile thing, where I want to port my app Chair: you're always going to have something older that doesn't have the functionality Milestones (Chair): - we're not making the milestone on GSS-API _v2_ clarifications * hartmans: as an individual, it's not clear we want to do v2 clarifications * is it worth reviewing and clarifying GSS-APIv2 update 1 * wyllys: It seems like an extra step and maybe not necessary. * jhutz: are you asking if GSS-APIv2 update 2 is worth doing? * no, the clarifications would be for inclusion into the v3 document * wyllys: oh, thats a little different. * all the various little issues that we talked about on the list * we need someone to volunteer to go through the CAT and KRB mailing lists and collect all of the details from the discussions which lead to the formation of this working group * Matt Peterson will assign one of Vintela's people to go over the archive and compile the complaints. * Update this milestone to May 2005. - No need to revise the other milestones since we are making good progress. Done. --------------010105070106060302000202-- --------------ms070600020608030307030202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDA4MDQ1NDE5WjAjBgkqhkiG9w0BCQQxFgQU1pSGA2MZKYP3tLckB+DfDoRLBIMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAbqkKgA91C7FKDYcCD/qi58+ZoEe8NCZpGiHE6WRC TkeuJ+BExNQVvaT6D8NOjURaknXFGQl+e1fMIQFE1acY5L+28X7g/KEBRRH1QrkT7EjtBA16 B991Iwq7jAOOb++i3bS7gBlzwO71siIv3G6iGqyNFm42B/pzVgVLKOtr/Y2tjYFo3/KkeG2l LqDjEOlnMa3HGApM2wMUkuGpbFoFN33CwWfZApWvCT4bQEWASfj0kVvVIL/OIFYfleleqP52 +O0uwijYkCGC879N4n0fe8RYNQOZE458gu0LiZMcDtgynxoFGJ8XwITIfw6k4Oe/NGruVpJO VS5L1DKKT/SQDQAAAAAAAA== --------------ms070600020608030307030202-- --===============0150026393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0150026393==-- From kitten-bounces@ietf.org Mon Apr 11 18:23:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07842; Mon, 11 Apr 2005 18:23:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7TR-0002Kj-RN; Mon, 11 Apr 2005 18:33:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7Hi-0002kD-3i; Mon, 11 Apr 2005 18:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7Hg-0002jR-AI for kitten@megatron.ietf.org; Mon, 11 Apr 2005 18:21:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07665 for ; Mon, 11 Apr 2005 18:21:20 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7R0-0002EZ-T5 for kitten@ietf.org; Mon, 11 Apr 2005 18:31:11 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4D8E1E0063; Mon, 11 Apr 2005 18:21:25 -0400 (EDT) To: kitten@ietf.org From: Sam Hartman Date: Mon, 11 Apr 2005 18:21:24 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: Please consider forward motion on PRF and mechanism attributes X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hi. I'd like to ask the working group to consider trying to move forward the PRF drafts rapidly. In addition, while I don't think we are close to being in a position to know what mechanism attributes we want, I'd love to have consensus on the APIs for accessing mechanism attributes. Having forward progress on these items may end up helping a proposal Joe Salowey is working on. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Apr 11 18:23:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07879; Mon, 11 Apr 2005 18:23:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7TY-0002L4-Dq; Mon, 11 Apr 2005 18:33:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7DP-0002GT-EX; Mon, 11 Apr 2005 18:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7DO-0002Fo-FP for kitten@megatron.ietf.org; Mon, 11 Apr 2005 18:17:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07297 for ; Mon, 11 Apr 2005 18:16:55 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7Mh-00026G-SV for kitten@ietf.org; Mon, 11 Apr 2005 18:26:45 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4EC7BE0063; Mon, 11 Apr 2005 18:16:58 -0400 (EDT) To: kitten@ietf.org From: Sam Hartman Date: Mon, 11 Apr 2005 18:16:58 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Bill told us so: stackable mechs, SPNEGO and substitutions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 During the security review of SPNEGO, Bill brought up a concern. The windows compatibility is only secure if you cannot mechanically transform the mechanism token of one mechanism into the token of another mechanism. I'm concerned that for many stackable mechanisms it would be relatively easy to push or pop something onto the stack and manipulate the tokens without cryptographic knowledge. Also, at least some of the mechanisms we have been discussing in the EAP context would be mechanisms that do not provide integrity unless properly stacked with a mechanism that spins integrity out of raw PRF. In short, there are a lot of security concerns surrounding stacking and negotiation. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Apr 11 18:52:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09643; Mon, 11 Apr 2005 18:52:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7v2-00032K-Hh; Mon, 11 Apr 2005 19:02:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7jf-00084u-SI; Mon, 11 Apr 2005 18:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7je-00084L-7Z for kitten@megatron.ietf.org; Mon, 11 Apr 2005 18:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09528 for ; Mon, 11 Apr 2005 18:50:06 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7so-0002xS-NP for kitten@ietf.org; Mon, 11 Apr 2005 18:59:57 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3BMo1Jx005834 for ; Mon, 11 Apr 2005 15:50:02 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3BMo1eu012792 for ; Mon, 11 Apr 2005 16:50:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3BMluYb007705; Mon, 11 Apr 2005 17:47:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3BMltUs007704; Mon, 11 Apr 2005 17:47:55 -0500 (CDT) Date: Mon, 11 Apr 2005 17:47:55 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050411224755.GE7608@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: kitten@ietf.org Subject: Re: Bill told us so: stackable mechs, SPNEGO and substitutions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On Mon, Apr 11, 2005 at 06:16:58PM -0400, Sam Hartman wrote: > During the security review of SPNEGO, Bill brought up a concern. The > windows compatibility is only secure if you cannot mechanically > transform the mechanism token of one mechanism into the token of > another mechanism. Right. IIRC Bill said this during lunch on Wednesday or Thursday. Bill is correct. As an aside, we first noted such a problem when designing the new Kerberos V GSS mechanism (CFX). We had to figure out how to deal with extensibility. In the end we punted on extensibility but provided the mechanism by which it could be added: we defined a slot where extensions could be requested by the initiator and declared that any such extensions will have to have the acceptor produce a context token that cannot be mechanically transformed into a non-extended context reply token. The issue there, and here, is quite similar: it's about protecting negotiation of security parameters. > I'm concerned that for many stackable mechanisms it would be > relatively easy to push or pop something onto the stack and manipulate > the tokens without cryptographic knowledge. Note that this issue arises, so far, only from negotiation above the GSS-API. SPNEGO, in particular, because of its historic brokenness, is what forces us to consider this. Now. We have two choices: design stackable mechanisms so that the context tokens of composite mechanisms cannot be easily manipulated into context tokens of different mechanisms (e.g., the underlying concrete mechanism's), OR, indicate that a given stackable mechanism doesn't have that property and so SPNEGO should insist on a mechListMIC exchange. > Also, at least some of the mechanisms we have been discussing in the > EAP context would be mechanisms that do not provide integrity unless > properly stacked with a mechanism that spins integrity out of raw PRF. > > In short, there are a lot of security concerns surrounding stacking > and negotiation. Well, you've identified *one* such concern here -- Bill's. We need to think about others though :) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Apr 11 18:54:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09729; Mon, 11 Apr 2005 18:54:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7wu-00034y-64; Mon, 11 Apr 2005 19:04:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7mm-00008g-6A; Mon, 11 Apr 2005 18:53:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7mk-00007e-P3 for kitten@megatron.ietf.org; Mon, 11 Apr 2005 18:53:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09687 for ; Mon, 11 Apr 2005 18:53:19 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7vw-00032g-GL for kitten@ietf.org; Mon, 11 Apr 2005 19:03:09 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3BMrKK2018774 for ; Mon, 11 Apr 2005 16:53:20 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3BMrKeu014505 for ; Mon, 11 Apr 2005 16:53:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3BMpEHe007714; Mon, 11 Apr 2005 17:51:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3BMpESm007713; Mon, 11 Apr 2005 17:51:14 -0500 (CDT) Date: Mon, 11 Apr 2005 17:51:14 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050411225114.GF7608@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org Subject: Re: Please consider forward motion on PRF and mechanism attributes X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Mon, Apr 11, 2005 at 06:21:24PM -0400, Sam Hartman wrote: > > > Hi. I'd like to ask the working group to consider trying to move > forward the PRF drafts rapidly. In addition, while I don't think we > are close to being in a position to know what mechanism attributes we > want, I'd love to have consensus on the APIs for accessing mechanism > attributes. > > Having forward progress on these items may end up helping a proposal > Joe Salowey is working on. As far as I'm concerned the I-Ds are ready for WG LC. That said, we may want to remove the restriction that the krb5 GSS_Prf() cannot be ready prior to full context establishment. Applications that use GSS_Prf() can certainly ensure that they call it in synchronized fashion before OR after full context establishment. I mention this ONLY as a result of your other post today about negotiation and composite mechanisms -- having GSS_Prf() prior to full context establishment could help construct stackable pseudo-mechanisms that protect against manipulation of its context tokens into those of underlying mechanisms'. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Apr 11 19:45:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12480; Mon, 11 Apr 2005 19:45:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8k6-0004GC-FX; Mon, 11 Apr 2005 19:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL8XU-0000ce-Hw; Mon, 11 Apr 2005 19:41:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL8XS-0000bX-Em for kitten@megatron.ietf.org; Mon, 11 Apr 2005 19:41:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12284 for ; Mon, 11 Apr 2005 19:41:34 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8gf-0004AP-KC for kitten@ietf.org; Mon, 11 Apr 2005 19:51:26 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3BNfbXi006094 for ; Mon, 11 Apr 2005 17:41:37 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3BNfaeu014612 for ; Mon, 11 Apr 2005 17:41:36 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3BNdVUq007867; Mon, 11 Apr 2005 18:39:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3BNdV78007866; Mon, 11 Apr 2005 18:39:31 -0500 (CDT) Date: Mon, 11 Apr 2005 18:39:31 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050411233930.GA7862@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: <20050411225114.GF7608@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411225114.GF7608@binky.Central.Sun.COM> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: Re: Please consider forward motion on PRF and mechanism attributes X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Mon, Apr 11, 2005 at 05:51:14PM -0500, Nicolas Williams wrote: > On Mon, Apr 11, 2005 at 06:21:24PM -0400, Sam Hartman wrote: > > > > > > Hi. I'd like to ask the working group to consider trying to move > > forward the PRF drafts rapidly. In addition, while I don't think we > > are close to being in a position to know what mechanism attributes we > > want, I'd love to have consensus on the APIs for accessing mechanism > > attributes. > > > > Having forward progress on these items may end up helping a proposal > > Joe Salowey is working on. > > As far as I'm concerned the I-Ds are ready for WG LC. > > That said, we may want to remove the restriction that the krb5 GSS_Prf() > cannot be ready prior to full context establishment. Applications that > use GSS_Prf() can certainly ensure that they call it in synchronized > fashion before OR after full context establishment. I mention this ONLY > as a result of your other post today about negotiation and composite > mechanisms -- having GSS_Prf() prior to full context establishment could > help construct stackable pseudo-mechanisms that protect against > manipulation of its context tokens into those of underlying mechanisms'. Er, disregard that suggestion -- there's never a partially established security context for the Kerbers V GSS mechanism on the acceptor side... _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Apr 14 15:12:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13724; Thu, 14 Apr 2005 15:12:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9vq-0005Gj-D1; Thu, 14 Apr 2005 15:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9jD-000359-JM; Thu, 14 Apr 2005 15:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9jB-000344-Rc for kitten@megatron.ietf.org; Thu, 14 Apr 2005 15:10:13 -0400 Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.29.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13430 for ; Thu, 14 Apr 2005 15:10:03 -0400 (EDT) Received: from [192.168.1.12] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3EJA3ns012421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Apr 2005 15:10:04 -0400 (EDT) Message-ID: <425EC090.2030604@columbia.edu> Date: Thu, 14 Apr 2005 15:12:16 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Subject: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2006237715==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d This is a cryptographically signed message in MIME format. --===============2006237715== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000309090601060006000306" This is a cryptographically signed message in MIME format. --------------ms000309090601060006000306 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Today begins a Working Group Last Call on the working group drafts: * draft-ietf-kitten-gssapi-prf-02.txt * draft-ietf-kitten-krb5-gssapi-prf-02.txt There are known issues related to ID-Nits failures which will be addressed at the end of the working group last call period prior to submission to the IESG. * draft-ietf-kitten-gssapi-prf-02.txt: - The IANA Considerations section is missing - The boilerplate must be updated to RFC 3978 - The IPR disclosure must be in conformance with BCP 79. * draft-ietf-kitten-krb5-gssapi-prf-02.txt: - The Introductions section is missing - The IANA Considerations section is missing - The boilerplate must be updated to RFC 3978 - The IPR disclosure must be in conformance with BCP 79. In addition, there are two issues which must be addressed for there to be a successful completion of the WGLC. (1) Language Bindings for Java and C# should be provided as part of draft-ietf-kitten-gssapi-prf (2) Appropriate text specifying how the key usage for the Krb5 PRF function will be determined must be added. This WGLC will end on April 28, 2005. Jeffrey Altman --------------ms000309090601060006000306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDE0MTkxMjE2WjAjBgkqhkiG9w0BCQQxFgQUjnGnMVrxWE3OYtwZ6+2epQt7yFsw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAKZSP3u/9c32opNGKdpaPldL8U+vdXA0tX+yzpEVx R+AptNDOM0NubTK/HTC4zfybsnqF+tW7hec3Gq3FTOpuC5CqBdpLc0JimGsc7wOTlCxMLf4P jy/dAaeklX6/vcdo+5mPZh0HzEjxdxBMCypjb5zXJrhzvcFE5g4XHI3e+axako/JYtsPibrt Ki6DsXZn4gnQsEwq8tyYR41Fty2umTA0do82aM6IVQyWrrfmc9J/Cm6zrCGR5Z+RLk4F9FSp 3GwRVowcZYuB+Smqp0+rABeTMw8WLzXFFxUdNmJCc1kexAYas0pSTHFjhbBKX5uvGRsN+tjk GJ9F5Pi+EWVO2QAAAAAAAA== --------------ms000309090601060006000306-- --===============2006237715== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============2006237715==-- From kitten-bounces@ietf.org Thu Apr 14 17:07:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28265; Thu, 14 Apr 2005 17:07:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBiw-00031O-0W; Thu, 14 Apr 2005 17:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBQ8-0000PK-D6; Thu, 14 Apr 2005 16:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBOC-0000GS-Gm for kitten@megatron.ietf.org; Thu, 14 Apr 2005 16:56:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26746 for ; Thu, 14 Apr 2005 16:56:30 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBY8-0002T2-CB for kitten@ietf.org; Thu, 14 Apr 2005 17:06:56 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0DB66E0063; Thu, 14 Apr 2005 16:56:25 -0400 (EDT) To: Jeffrey Altman References: <425EC090.2030604@columbia.edu> From: Sam Hartman Date: Thu, 14 Apr 2005 16:56:25 -0400 In-Reply-To: <425EC090.2030604@columbia.edu> (Jeffrey Altman's message of "Thu, 14 Apr 2005 15:12:16 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> (2) Appropriate text specifying how the key usage for the Jeffrey> Krb5 PRF function will be determined must be added. RFc 3961 does not have keyusage for PRF. Like Nico, I am concerned that our decision not to support prf_ready for the krb5 prf may be problematic. I am not advocating a change now, but I'm concerned that the issue needs more consideration. Clearly as one of the people asking for the PRF documents to move, I should try to form a better opinion during the WGLC. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Apr 14 17:23:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01456; Thu, 14 Apr 2005 17:23:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMByW-0004KB-VZ; Thu, 14 Apr 2005 17:34:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBjb-0004g8-Ia; Thu, 14 Apr 2005 17:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBjY-0004Yq-7e for kitten@megatron.ietf.org; Thu, 14 Apr 2005 17:18:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00353 for ; Thu, 14 Apr 2005 17:18:36 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBtW-0003t2-Lo for kitten@ietf.org; Thu, 14 Apr 2005 17:29:03 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3ELIajG021676 for ; Thu, 14 Apr 2005 14:18:36 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3ELIZac013228 for ; Thu, 14 Apr 2005 15:18:36 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3ELGSiX011151; Thu, 14 Apr 2005 16:16:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3ELGR2R011150; Thu, 14 Apr 2005 16:16:27 -0500 (CDT) Date: Thu, 14 Apr 2005 16:16:27 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050414211627.GB10525@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Altman , kitten@ietf.org References: <425EC090.2030604@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Thu, Apr 14, 2005 at 04:56:25PM -0400, Sam Hartman wrote: > >>>>> "Jeffrey" == Jeffrey Altman writes: > > Jeffrey> (2) Appropriate text specifying how the key usage for the > Jeffrey> Krb5 PRF function will be determined must be added. > > RFc 3961 does not have keyusage for PRF. Note that the key usage in question is for the krb5 _mechanism_'s GSS PRF, not the kcrypto PRF. Given that, what impact does the lack of a key usage for the kcrypto prf have, in your opinion, on this I-D? > Like Nico, I am concerned that our decision not to support prf_ready > for the krb5 prf may be problematic. I am not advocating a change > now, but I'm concerned that the issue needs more consideration. > Clearly as one of the people asking for the PRF documents to move, I > should try to form a better opinion during the WGLC. Please do :) Due to the fact that for the krb5 mechanism there is no such thing, on the _acceptor_ side, as a partially established security context, the only ways I can see to specify a PRF_READY feature would be to either add an argument to GSS_PRF() so a pre-full-establishment key can be used, OR a mechanism-specific extension. I agree that, in light of the recently discussed complication created by SPNEGO, it would be nice to have a PRF_READY feature. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Apr 14 17:38:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03130; Thu, 14 Apr 2005 17:38:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCCj-00059T-4A; Thu, 14 Apr 2005 17:48:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMC1o-0001mX-UV; Thu, 14 Apr 2005 17:37:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMC1l-0001lE-Jl for kitten@megatron.ietf.org; Thu, 14 Apr 2005 17:37:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03063 for ; Thu, 14 Apr 2005 17:37:23 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCBi-00054e-2Z for kitten@ietf.org; Thu, 14 Apr 2005 17:47:50 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8290FE0077; Thu, 14 Apr 2005 17:37:19 -0400 (EDT) To: Jeffrey Altman References: <425EC090.2030604@columbia.edu> <20050414211627.GB10525@binky.Central.Sun.COM> From: Sam Hartman Date: Thu, 14 Apr 2005 17:37:19 -0400 In-Reply-To: <20050414211627.GB10525@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 14 Apr 2005 16:16:27 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Apr 14, 2005 at 04:56:25PM -0400, Sam Hartman Nicolas> wrote: >> >>>>> "Jeffrey" == Jeffrey Altman >> writes: >> Jeffrey> (2) Appropriate text specifying how the key usage for the Jeffrey> Krb5 PRF function will be determined must be added. >> RFc 3961 does not have keyusage for PRF. Nicolas> Note that the key usage in question is for the krb5 Nicolas> _mechanism_'s GSS PRF, not the kcrypto PRF. Given that, Nicolas> what impact does the lack of a key usage for the kcrypto Nicolas> prf have, in your opinion, on this I-D? The kcrypto prf takes a protocol key not a derived key. You don't stick in a key usage number anywhere. Your draft at least claims to use the kcrypto prf in a prf+ construction. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Apr 14 17:47:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03701; Thu, 14 Apr 2005 17:47:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCLk-0005UR-9I; Thu, 14 Apr 2005 17:58:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCA9-0004nY-7f; Thu, 14 Apr 2005 17:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCA6-0004kg-G3 for kitten@megatron.ietf.org; Thu, 14 Apr 2005 17:46:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03588 for ; Thu, 14 Apr 2005 17:46:07 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCK8-0005Oz-LR for kitten@ietf.org; Thu, 14 Apr 2005 17:56:34 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j3ELk6Q1011641 for ; Thu, 14 Apr 2005 14:46:06 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3ELk4ew022526 for ; Thu, 14 Apr 2005 15:46:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3ELhvxJ011177; Thu, 14 Apr 2005 16:43:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3ELhvEE011176; Thu, 14 Apr 2005 16:43:57 -0500 (CDT) Date: Thu, 14 Apr 2005 16:43:57 -0500 From: Nicolas Williams To: ietf-krb-wg@anl.gov, kitten@ietf.org Message-ID: <20050414214357.GM7862@binky.Central.Sun.COM> Mail-Followup-To: ietf-krb-wg@anl.gov, kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [FWD: Comments on the WSS Kerberos Token Profile 1.0, Draft 5] X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 The OASIS Web Services Security Kerberos Token Profile 1.0, Draft 5, recently came to my attention. I have read and reviewed the document and posted my comments to the WSS comment list. Other participants of the IETF KRB and/or KITTEN WGs may be interested in reviewing said draft specification. I note that the IETF has no liaison to OASIS, nor does the OASIS WSS TC have a liaison to the IETF. Nico ----- Forwarded message from Nicolas Williams ----- Date: Thu, 14 Apr 2005 16:35:22 -0500 From: Nicolas Williams To: wss-comment@lists.oasis-open.org Subject: Comments on the WSS Kerberos Token Profile 1.0, Draft 5 The Web Services Security Kerberos Token Profile 1.0, Draft 5 appears, in some ways to be incomplete. Additionally, I believe it is quite unfortunate that the Kerberos V GSS-API mechanism was not used instead. I can understand that the lack of a keying facility may well have led to this unfortunate design, but you should know that the IETF KITTEN WG is currently holding a Working Group Last call on a GSS-API extension for (and corresponding Kerberos V mechanism specification of) a pseudo-random function keyed internally by a GSS-API security context. This new feature of both, the GSS-API and the Kerberos V GSS-API mechanism should provide all the functionality needed by OASIS for a profile such as the one I'm commenting on. Besides my above comment on the non-use of the GSS-API, I have the following comments on Draft 5 of the profile: - Naming There is nothing in the profile about Kerberos V principal naming. What kind of service principal names should be used? Or is this to be specified by applications that use this profile? If so then this should be pointed out. But since this profile seems to be closely connected with SOAP I suspect that naming considerations need to be discussed in the profile. Are non-Kerberos names to be mapped to Kerberos V principal names? If so, how, or where is this specified? - Session key negotiation and key re-use The profile should say whether or not the optional sub-session key in the AP-REQ's Authenticator MAY/SHOULD/MUST be present/absent, which of the Ticket's or Authenticator's session key "wins" when the Authenticator asserts a sub-session key. Assertion of sub-session keys in Authenticators is an excellent approach to key re-use prevention. I'll have to review the other WSS specifications and drafts (and probably SOAP as well) to get a good idea of whether key re-use is prevented elsewhere. I suppose, though I will have to review the other WSS and related W3C specs/drafts to be sure of it, that proper key derivation is done elsewhere. It would be useful, to readers not familiar with OASIS specifications, to mention where key derivation happens, along with references. - Replay protection and mutual authentication This profile says little about replay protection and nothing about mutual authentication. While it may be sensible to leave replay protection to the "mechanisms described in WS-Security" I get the impression from the text in section 4 that there are special considerations related to this particular profile, yet no RFC2119 terminology (MAY/SHOULD/MUST/...) is used to indicate what, if anything, implementors should do. As for mutual authentication, if the "mechanisms described in WS-Security" provide it, then that should be explained in the profile, just as with replay protection. - Error handling This profile does not make use of the KRB-ERROR Kerberos V PDU, nor does it mention any Kerberos V error codes. Instead it refers to error codes "defined in the WS-Security specification" without giving any indication of how Kerberos V error conditions on the server (acceptor) side should be mapped to WSS errors, if at all. - Channel binding Section 4, last paragraph (lines 214-215) says "It should be noted that transport-level security MAY be used to protect the message and the security token." I think this needs some clarification. Why should the AP-REQ message require additional protection from lower layers? From what sorts of attacks? What if no such protection is available? Shouldn't the session key from the AP-REQ be used to provide integrity protection to the S11 header? Or is this text indicating, obliquely I suppose, that it is possible to use this profile for authentication but rely on lower network layers for session protection? If the latter, note that there is a channel binding problem in that more normative text is needed to ensure that the end-points of the lower-layer channel and the application layer are effectively the same, else MITM attacks may be possible. [Note: I assume that the "transport-level security" is secure against MITM attacks, but MITM attacks may be feasible nonetheless by misdirecting the system/application so that one layer or the other it is speaking to an otherwise properly authenticated attacked.] This can be avoided with some additional requirements. - Normative references to soon-to-be-obsoleted documents RFC1510 will be obsoleted as soon as the RFC-Editor publishes draft-ietf-krb-wg-kerberos-clarifications-07.txt as an RFC. That Internet-Draft has already been approved as a Proposed Standard by the IESG. The WSS Kerberos Token Profile should be reviewed with kerberos- clarifications in mind and, if it should not progress from Draft status prior to the publication of kerberos-clarifications as an RFC, then it should be changed to list the new RFC as a normative reference for the Kerberos Network Authentication Service (V5). - General silliness Section 3.5 says that "[when] a Kerberos ticket is referenced as an encryption key, the encryption algorithm MUST be a symmetric encryption algorithm." At first glance this would seem self-evident given the normative reference to RFC1510, but since the encryption in question is not based on Kerberos specifications this is not so obvious, which leads me to ask... ...why not say the same thing in section 3.4? Also, section 2.3 lists terms not used anywhere else in the document, such as 'UCS' and 'UTF-8'. Is the document incomplete, perhaps with regards to internationalization (I18N)? Note that Kerberos V currently can only be interoperably used where principal and realm names are limited to US-ASCII characters (the IETF KRB WG is working on properly internationalizing the protocol). Finally, I will give the IETF KRB and KITTEN WGs a heads-up about this OASIS profile, as their participants may not be aware of this profile and may wish to review and comment on it. Cheers, Nico -- ----- End forwarded message ----- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Apr 14 17:49:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03810; Thu, 14 Apr 2005 17:49:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCNA-0005W6-3c; Thu, 14 Apr 2005 17:59:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCBg-0005MC-Lf; Thu, 14 Apr 2005 17:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCBc-0005J3-Uy for kitten@megatron.ietf.org; Thu, 14 Apr 2005 17:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03698 for ; Thu, 14 Apr 2005 17:47:42 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCLf-0005UN-TY for kitten@ietf.org; Thu, 14 Apr 2005 17:58:09 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3ELlgjO018970 for ; Thu, 14 Apr 2005 15:47:42 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3ELlfew023321 for ; Thu, 14 Apr 2005 15:47:41 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3ELjYRD011184; Thu, 14 Apr 2005 16:45:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3ELjYo6011183; Thu, 14 Apr 2005 16:45:34 -0500 (CDT) Date: Thu, 14 Apr 2005 16:45:34 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050414214534.GC10525@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Altman , kitten@ietf.org References: <425EC090.2030604@columbia.edu> <20050414211627.GB10525@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Thu, Apr 14, 2005 at 05:37:19PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Thu, Apr 14, 2005 at 04:56:25PM -0400, Sam Hartman > Nicolas> wrote: > >> >>>>> "Jeffrey" == Jeffrey Altman > >> writes: > >> > Jeffrey> (2) Appropriate text specifying how the key usage for the > Jeffrey> Krb5 PRF function will be determined must be added. > >> RFc 3961 does not have keyusage for PRF. > > Nicolas> Note that the key usage in question is for the krb5 > Nicolas> _mechanism_'s GSS PRF, not the kcrypto PRF. Given that, > Nicolas> what impact does the lack of a key usage for the kcrypto > Nicolas> prf have, in your opinion, on this I-D? > > The kcrypto prf takes a protocol key not a derived key. You don't > stick in a key usage number anywhere. Your draft at least claims to > use the kcrypto prf in a prf+ construction. Sure, but my I-D can still mandate the use of a derived key, with some key usage, to be used as input to the kcrypto prf. Correct? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Apr 14 17:53:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04132; Thu, 14 Apr 2005 17:53:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCRS-0005jp-AP; Thu, 14 Apr 2005 18:04:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCFP-0006B9-Uo; Thu, 14 Apr 2005 17:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCFO-0006Ap-2h for kitten@megatron.ietf.org; Thu, 14 Apr 2005 17:51:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03960 for ; Thu, 14 Apr 2005 17:51:27 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCPJ-0005dc-MZ for kitten@ietf.org; Thu, 14 Apr 2005 18:01:54 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B0688E0063; Thu, 14 Apr 2005 17:51:22 -0400 (EDT) To: Jeffrey Altman References: <425EC090.2030604@columbia.edu> <20050414211627.GB10525@binky.Central.Sun.COM> <20050414214534.GC10525@binky.Central.Sun.COM> From: Sam Hartman Date: Thu, 14 Apr 2005 17:51:22 -0400 In-Reply-To: <20050414214534.GC10525@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 14 Apr 2005 16:45:34 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Sure, but my I-D can still mandate the use of a derived Nicolas> key, with some key usage, to be used as input to the Nicolas> kcrypto prf. Correct? Not as such. You can mandate anything consistent with RFC 3961. Go look back at the kcrypto operations and make the types match. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Apr 14 18:13:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06441; Thu, 14 Apr 2005 18:13:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCkf-0006Vz-22; Thu, 14 Apr 2005 18:23:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCU5-0001ra-Hq; Thu, 14 Apr 2005 18:06:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCTa-0001nb-85 for kitten@megatron.ietf.org; Thu, 14 Apr 2005 18:06:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05481 for ; Thu, 14 Apr 2005 18:05:59 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCdN-0006H6-J9 for kitten@ietf.org; Thu, 14 Apr 2005 18:16:27 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3EM5xjO000944 for ; Thu, 14 Apr 2005 16:05:59 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3EM5wac013783 for ; Thu, 14 Apr 2005 16:05:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3EM3q39011378; Thu, 14 Apr 2005 17:03:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3EM3qll011377; Thu, 14 Apr 2005 17:03:52 -0500 (CDT) Date: Thu, 14 Apr 2005 17:03:52 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050414220351.GG10525@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Altman , kitten@ietf.org References: <425EC090.2030604@columbia.edu> <20050414211627.GB10525@binky.Central.Sun.COM> <20050414214534.GC10525@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Thu, Apr 14, 2005 at 05:51:22PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> Sure, but my I-D can still mandate the use of a derived > Nicolas> key, with some key usage, to be used as input to the > Nicolas> kcrypto prf. Correct? > > Not as such. You can mandate anything consistent with RFC 3961. Go > look back at the kcrypto operations and make the types match. Ok, well, given that the RFC3961 prf accepts only a protocol-key, then I think we have no choice but to remove the words "and key usage X (TBD)" from the end of the first paragraph of section 2 of draft-ietf-kitten-krb5-gssapi-prf-02.txt. Agreed? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Apr 15 14:02:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27355; Fri, 15 Apr 2005 14:02:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVJO-0003ns-Nn; Fri, 15 Apr 2005 14:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMV5g-0000cr-PT; Fri, 15 Apr 2005 13:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMV5f-0000ce-UD for kitten@megatron.ietf.org; Fri, 15 Apr 2005 13:58:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27059 for ; Fri, 15 Apr 2005 13:58:50 -0400 (EDT) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVFu-0003ZM-IC for kitten@ietf.org; Fri, 15 Apr 2005 14:09:26 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA07866; Fri, 15 Apr 2005 19:58:28 +0200 (MESZ) From: Martin Rex Message-Id: <200504151758.TAA12322@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 15 Apr 2005 19:58:29 +0200 (MET DST) In-Reply-To: <20050414211627.GB10525@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 14, 5 04:16:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > Due to the fact that for the krb5 mechanism there is no such thing, on > the _acceptor_ side, as a partially established security context, the > only ways I can see to specify a PRF_READY feature would be to either > add an argument to GSS_PRF() so a pre-full-establishment key can be > used, OR a mechanism-specific extension. > > I agree that, in light of the recently discussed complication created by > SPNEGO, it would be nice to have a PRF_READY feature. Just a few observations: - When SPNEGO is used, then the PROT_READY option in not available. - Although gss-cfx does not specify a semi-established security context on the acceptor side for the Kerberos GSS-API mechanism, there is an installed base that implements acceptor-side semi-established security contexts (but I don't know whether it supports prot_ready...): Microsoft's user2user authentication, which has been available since original Windows 2000, and had once been documented in "draft-swift-win2k-krb-user2user-xx.txt" Strange--I can only find a -03 document in my archives from oct-2001, but no informational RFC nor a newer draft... - How about adding a parameter which the **application** caller can use to indicate (on the acceptor side) whether it requires a key in sync with the initiators' prot_ready key, or whether it wants a key that is based on the fully established context (i.e. which could be a server-asserted subkey that was established later in the context establishment handshake). The key based on the fully established handshake should be the default. I think this would be a manageable burden for the application writers that want to do krypto on their own to know whether the initiator takes advantage of prot_ready or not. I even think it should be ok for the initiator to *insecurely* tell the acceptor which key/prf to expect (in case there really was ambiguity, which I think there isn't). I do not consider the potential DoS a security problenm, that an active attacker may change an unprotected indicator which key/prf the acceptor should request. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Apr 15 15:21:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06618; Fri, 15 Apr 2005 15:21:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWXn-0000QV-Hv; Fri, 15 Apr 2005 15:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMW8w-0002Rg-FD; Fri, 15 Apr 2005 15:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMW8u-0002Rb-Om for kitten@megatron.ietf.org; Fri, 15 Apr 2005 15:06:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03299 for ; Fri, 15 Apr 2005 15:06:15 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWJ8-0007an-Ub for kitten@ietf.org; Fri, 15 Apr 2005 15:16:52 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3FJ6Ei7028728 for ; Fri, 15 Apr 2005 13:06:14 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3FJ6Daa001017 for ; Fri, 15 Apr 2005 13:06:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3FJ469n011971; Fri, 15 Apr 2005 14:04:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3FJ40or011970; Fri, 15 Apr 2005 14:04:00 -0500 (CDT) Date: Fri, 15 Apr 2005 14:04:00 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20050415190400.GB11875@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org References: <20050414211627.GB10525@binky.Central.Sun.COM> <200504151758.TAA12322@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504151758.TAA12322@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc On Fri, Apr 15, 2005 at 07:58:29PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > Due to the fact that for the krb5 mechanism there is no such thing, on > > the _acceptor_ side, as a partially established security context, the > > only ways I can see to specify a PRF_READY feature would be to either > > add an argument to GSS_PRF() so a pre-full-establishment key can be > > used, OR a mechanism-specific extension. > > > > I agree that, in light of the recently discussed complication created by > > SPNEGO, it would be nice to have a PRF_READY feature. > > Just a few observations: > > - When SPNEGO is used, then the PROT_READY option in not available. Right, but that's not the issue here. See Sam's e-mail with the Subject: "Bill told us so: stackable mechs, SPNEGO and substitutions." Basically, in order to construct composite mechanisms which do not cause problems with the new SPNEGO we need to be able to construct their context tokens so that they are cryptographically protected from being turned into context tokens of their underlying mechanisms. Alternatively, where that can't be ensured, SPNEGO either MUST require the MIC exchange or MUST NOT negotiate such composite mechanisms. So, it'd be nice if we could consider building stackable pseudo- mechanisms such that composite mechanisms made by stacking them over Kerberos V have that cryptographic property mentioned above. In the case of the Kerberos V mechanism we could do that, at least for the reply token, if we had a PRF_READY feature for the GSS_PRF(). But the current form of the GSS_PRF() function does not allow it. > - Although gss-cfx does not specify a semi-established security context > on the acceptor side for the Kerberos GSS-API mechanism, there is > an installed base that implements acceptor-side semi-established > security contexts (but I don't know whether it supports prot_ready...): > > Microsoft's user2user authentication, which has been available > since original Windows 2000, and had once been documented in > "draft-swift-win2k-krb-user2user-xx.txt" > Strange--I can only find a -03 document in my archives from oct-2001, > but no informational RFC nor a newer draft... But u2u is a different mechanism. > - How about adding a parameter which the **application** caller can use to > indicate (on the acceptor side) whether it requires a key in sync > with the initiators' prot_ready key, or whether it wants a key > that is based on the fully established context (i.e. which could > be a server-asserted subkey that was established later in the > context establishment handshake). That is one alternative. I asked whether folks support this. > The key based on the fully established handshake should be the default. Right. > I think this would be a manageable burden for the application writers > that want to do krypto on their own to know whether the initiator > takes advantage of prot_ready or not. I agree. > I even think it should be ok for the initiator to *insecurely* tell > the acceptor which key/prf to expect (in case there really was > ambiguity, which I think there isn't). I do not consider the > potential DoS a security problenm, that an active attacker may > change an unprotected indicator which key/prf the acceptor should request. Probably so. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Apr 15 16:47:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23284; Fri, 15 Apr 2005 16:47:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXsn-0008Ng-65; Fri, 15 Apr 2005 16:57:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXbu-00087M-Ax; Fri, 15 Apr 2005 16:40:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXbs-00086s-Ex for kitten@megatron.ietf.org; Fri, 15 Apr 2005 16:40:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22545 for ; Fri, 15 Apr 2005 16:40:14 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXm7-0007rJ-Ur for kitten@ietf.org; Fri, 15 Apr 2005 16:50:53 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3FKeEjO001579 for ; Fri, 15 Apr 2005 14:40:14 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3FKeDew017698 for ; Fri, 15 Apr 2005 14:40:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3FKc6SC012195; Fri, 15 Apr 2005 15:38:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3FKc5YI012194; Fri, 15 Apr 2005 15:38:05 -0500 (CDT) Date: Fri, 15 Apr 2005 15:38:05 -0500 From: Nicolas Williams To: ietf-krb-wg@anl.gov, kitten@ietf.org Message-ID: <20050415203805.GP7862@binky.Central.Sun.COM> Mail-Followup-To: ietf-krb-wg@anl.gov, kitten@ietf.org References: <20050414214357.GM7862@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050414214357.GM7862@binky.Central.Sun.COM> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: [FWD: Comments on the WSS Kerberos Token Profile 1.0, Draft 5] X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-krb-wg@anl.gov List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Thu, Apr 14, 2005 at 04:43:57PM -0500, Nicolas Williams wrote: > The OASIS Web Services Security Kerberos Token Profile 1.0, Draft 5, > recently came to my attention. I have read and reviewed the document > and posted my comments to the WSS comment list. > > Other participants of the IETF KRB and/or KITTEN WGs may be interested > in reviewing said draft specification. If you're interested in following the resulting thread, the OASIS WS-Security TC web page and mailing list archive URLs are as follows: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss http://lists.oasis-open.org/archives/wss-comment/ http://lists.oasis-open.org/archives/wss-comment/200504/maillist.html Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Apr 15 18:54:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07363; Fri, 15 Apr 2005 18:54:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZsD-0007GH-1u; Fri, 15 Apr 2005 19:05:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZfG-0005vI-P0; Fri, 15 Apr 2005 18:51:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZfE-0005vA-K0 for kitten@megatron.ietf.org; Fri, 15 Apr 2005 18:51:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07316 for ; Fri, 15 Apr 2005 18:51:49 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZpW-00077y-8u for kitten@ietf.org; Fri, 15 Apr 2005 19:02:30 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3FMpojO023875 for ; Fri, 15 Apr 2005 16:51:50 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3FMpnew000213 for ; Fri, 15 Apr 2005 16:51:50 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3FMnfO0012401; Fri, 15 Apr 2005 17:49:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3FMnaXR012400; Fri, 15 Apr 2005 17:49:36 -0500 (CDT) Date: Fri, 15 Apr 2005 17:49:36 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050415224936.GM11875@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <425EC090.2030604@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425EC090.2030604@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: kitten@ietf.org Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 On Thu, Apr 14, 2005 at 03:12:16PM -0400, Jeffrey Altman wrote: > Today begins a Working Group Last Call on the working group > drafts: > > * draft-ietf-kitten-gssapi-prf-02.txt > * draft-ietf-kitten-krb5-gssapi-prf-02.txt > > There are known issues related to ID-Nits failures which will > be addressed at the end of the working group last call period > prior to submission to the IESG. > > * draft-ietf-kitten-gssapi-prf-02.txt: > > - The IANA Considerations section is missing I propose to add such a section claiming that "[this] document has no IANA considerations." > - The boilerplate must be updated to RFC 3978 > > - The IPR disclosure must be in conformance with BCP 79. This will be done. > * draft-ietf-kitten-krb5-gssapi-prf-02.txt: > > - The Introductions section is missing I propose the following: 2. Introduction This document specifies the Kerberos V GSS-API mechanism's pseudo- random funtion corresponding to [GSS-PRF]. The function is a "PRF+" style construction. Alternatively I could rename the section currently named "Kerberos V GSS Mechanism PRF" to "Introduction" :) > - The IANA Considerations section is missing I propose to add such a section claiming that "[this] document has no IANA considerations." > - The boilerplate must be updated to RFC 3978 > > - The IPR disclosure must be in conformance with BCP 79. This will be done. > In addition, there are two issues which must be addressed > for there to be a successful completion of the WGLC. > > (1) Language Bindings for Java and C# should be provided as part > of draft-ietf-kitten-gssapi-prf I have sent Seema and Juan Carlos proposed text, which I include here (ignoring the PRF_READY thread): > (2) Appropriate text specifying how the key usage for the Krb5 > PRF function will be determined must be added. Sam pointed out, indirectly, that no such key usage is needed. I proposed the removal of the text "and key usage X (TBD)" from the the end of the first paragraph of section 2 of draft-ietf-kitten-krb5- gssapi-prf. > This WGLC will end on April 28, 2005. Thanks. I will make a proposal on the PRF_READY issue in a separate post. Cheers, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Apr 15 19:10:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08372; Fri, 15 Apr 2005 19:10:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMa78-00081s-BR; Fri, 15 Apr 2005 19:20:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZkX-0006Iu-Iy; Fri, 15 Apr 2005 18:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZkW-0006Ih-1V for kitten@megatron.ietf.org; Fri, 15 Apr 2005 18:57:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07606 for ; Fri, 15 Apr 2005 18:57:17 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZum-0007PQ-M5 for kitten@ietf.org; Fri, 15 Apr 2005 19:07:58 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3FMvHjO026975 for ; Fri, 15 Apr 2005 16:57:17 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3FMvHew002507 for ; Fri, 15 Apr 2005 16:57:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3FMt9SL012417; Fri, 15 Apr 2005 17:55:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3FMt9eJ012416; Fri, 15 Apr 2005 17:55:09 -0500 (CDT) Date: Fri, 15 Apr 2005 17:55:09 -0500 From: Nicolas Williams To: Jeffrey Altman , kitten@ietf.org Message-ID: <20050415225508.GO11875@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <425EC090.2030604@columbia.edu> <20050415224936.GM11875@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415224936.GM11875@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Re: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Fri, Apr 15, 2005 at 05:49:36PM -0500, Nicolas Williams wrote: > On Thu, Apr 14, 2005 at 03:12:16PM -0400, Jeffrey Altman wrote: > > I have sent Seema and Juan Carlos proposed text, which I include here > (ignoring the PRF_READY thread): Argh -- I forgot to paste that in. Here: How about, for Java: public byte[] prf(byte inBuf[], int outlen) throws GSSException And for C#: public byte[] prf(byte inBuf[], int outlen) ? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Apr 15 19:59:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11168; Fri, 15 Apr 2005 19:59:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMat1-0002BO-HI; Fri, 15 Apr 2005 20:10:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMaTv-0001hT-Hf; Fri, 15 Apr 2005 19:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMaTu-0001hA-8U for kitten@megatron.ietf.org; Fri, 15 Apr 2005 19:44:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10367 for ; Fri, 15 Apr 2005 19:44:13 -0400 (EDT) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMaeB-0001P5-E8 for kitten@ietf.org; Fri, 15 Apr 2005 19:54:52 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 8527F162C4B for ; Fri, 15 Apr 2005 23:44:09 +0000 (GMT) From: Andrew Bartlett To: kitten@ietf.org Date: Sat, 16 Apr 2005 09:44:03 +1000 Message-Id: <1113608643.7488.274.camel@amy.samba4.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0782506325==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --===============0782506325== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WikSN5/dEWK/Jv1jX0eB" --=-WikSN5/dEWK/Jv1jX0eB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm not a kerberos or a GSSAPI guru, simply one who has to clean up various bits of the puzzle that has been placed in front of me regarding the use of GSSAPI on CIFS and other Samba-implemented protocols. In particular, I'm concerned to try and get out of the GSSAPI game, and would some day love to put Samba back outside the 'implements some variant of GSSAPI' box. =20 Currently, Samba implements a very shoddy GSSAPI wrapping, as well as SPNEGO, partly because it requires access to the raw Kerberos session key for use particularly in the CIFS protocol. CIFS uses the Kerberos session key for encrypting specific data portions on DCE/RPC named pipes, as well as to key the SMB signing system. My question is this (because I can't make heads or tails of the draft, sorry): Is the proposed PRF compatible with microsoft's existing use in this area, or will Samba forever-more be making calls to krb5_auth_con_getremotesubkey(context, auth_context, &skey) and krb5_auth_con_getlocalsubkey(context, auth_context, &skey)? Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-WikSN5/dEWK/Jv1jX0eB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCYFHDz4A8Wyi0NrsRAuI0AJ4gplgKl83KkdodTDMNGwvdhm97KQCfZOeK D3TA4adr2urSuw/D6aw6vQo= =pLDo -----END PGP SIGNATURE----- --=-WikSN5/dEWK/Jv1jX0eB-- --===============0782506325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0782506325==-- From kitten-bounces@ietf.org Fri Apr 15 20:16:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11898; Fri, 15 Apr 2005 20:16:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMb9W-0002wO-M9; Fri, 15 Apr 2005 20:27:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMat0-0003kC-ON; Fri, 15 Apr 2005 20:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMasy-0003iu-4f for kitten@megatron.ietf.org; Fri, 15 Apr 2005 20:10:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11654 for ; Fri, 15 Apr 2005 20:10:06 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMb3G-0002aT-DK for kitten@ietf.org; Fri, 15 Apr 2005 20:20:46 -0400 Received: from [192.168.1.12] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3G0A6q1016780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Apr 2005 20:10:06 -0400 (EDT) Message-ID: <42605868.3020901@columbia.edu> Date: Fri, 15 Apr 2005 20:12:24 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Bartlett References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> In-Reply-To: <1113608643.7488.274.camel@amy.samba4.abartlet.net> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1088194674==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a cryptographically signed message in MIME format. --===============1088194674== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060302080600040102000109" This is a cryptographically signed message in MIME format. --------------ms060302080600040102000109 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew: The PRF is not going to be compatible with Microsoft's existing use. The idea behind the PRF is to allow the session keys negotiated by the mechanism to be used to produce additional keys which could then be used safely by the application calling GSS. New PRF generated keys can be generated as needed to satisfy rekeying requirements without requiring that the session shutdown and re-authenticated with GSS. The problem you face is that due to the lack of a functionality like PRF, the CIFS developers were forced to extract the raw krb5 keys for the purpose of providing encryption and data signing. Unless Microsoft chooses to support a PRF based replacement for a future CIFS protocol and you choose to abandon the existing clients, you will have to continue using your existing hacks. Jeffrey Altman Andrew Bartlett wrote: > I'm not a kerberos or a GSSAPI guru, simply one who has to clean up > various bits of the puzzle that has been placed in front of me regarding > the use of GSSAPI on CIFS and other Samba-implemented protocols. > > In particular, I'm concerned to try and get out of the GSSAPI game, and > would some day love to put Samba back outside the 'implements some > variant of GSSAPI' box. > > Currently, Samba implements a very shoddy GSSAPI wrapping, as well as > SPNEGO, partly because it requires access to the raw Kerberos session > key for use particularly in the CIFS protocol. > > CIFS uses the Kerberos session key for encrypting specific data portions > on DCE/RPC named pipes, as well as to key the SMB signing system. > > My question is this (because I can't make heads or tails of the draft, > sorry): Is the proposed PRF compatible with microsoft's existing use in > this area, or will Samba forever-more be making calls to > krb5_auth_con_getremotesubkey(context, auth_context, &skey) and > krb5_auth_con_getlocalsubkey(context, auth_context, &skey)? > > Thanks, > > Andrew Bartlett > > > ------------------------------------------------------------------------ > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms060302080600040102000109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDE2MDAxMjI0WjAjBgkqhkiG9w0BCQQxFgQUlOT3bIGIYDSyg8EUl66i2IawM8Yw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAFwgS9dCSfocEENvKxX6eNvzf49QNyDv6Vw84ICnE oj2ySzM7VGGR/Iv2Icvap3IJt7ZQfMnTly2+vY/3DwPQnp9sCqN8WdTkVIfleLxu7NPv+U92 ESKuMRCFOQEMmeolwnuisKCn8BtrhwPI+pNd/6bb8G09KjtJ+QWW3/KqjMvdyHfxlusxcD7X jgP5a4G75SaCQueR9cwuNgd8Rl2QgZs7fuwyuR0lbVGNSQi0GVX6bZjZtk96G1estDrv5qm7 8Be8FsVourgGtmN1xMVghjSkRQRTaIkl+G46BzlY/CQLHb2iBV2jtkrLwsMvzc+qQsnEbeMT 0VItfjPpeQMvOgAAAAAAAA== --------------ms060302080600040102000109-- --===============1088194674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1088194674==-- From kitten-bounces@ietf.org Fri Apr 15 20:58:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14531; Fri, 15 Apr 2005 20:58:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMboH-00053B-Fc; Fri, 15 Apr 2005 21:09:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMb9x-0005TO-RL; Fri, 15 Apr 2005 20:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMb9v-0005TE-Tr for kitten@megatron.ietf.org; Fri, 15 Apr 2005 20:27:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12500 for ; Fri, 15 Apr 2005 20:27:38 -0400 (EDT) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMbKE-0003X7-It for kitten@ietf.org; Fri, 15 Apr 2005 20:38:18 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 6770C162B6E; Sat, 16 Apr 2005 00:27:38 +0000 (GMT) From: Andrew Bartlett To: Jeffrey Altman In-Reply-To: <42605868.3020901@columbia.edu> References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> Date: Sat, 16 Apr 2005 10:27:32 +1000 Message-Id: <1113611252.7488.282.camel@amy.samba4.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1476038953==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a --===============1476038953== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mFg6zVk938bbYVaukQgL" --=-mFg6zVk938bbYVaukQgL Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-04-15 at 20:12 -0400, Jeffrey Altman wrote: > Andrew: >=20 > The PRF is not going to be compatible with Microsoft's existing use. > The problem you face is that due to the lack of a functionality like > PRF, the CIFS developers were forced to extract the raw krb5 keys > for the purpose of providing encryption and data signing. Unless > Microsoft chooses to support a PRF based replacement for a future > CIFS protocol and you choose to abandon the existing clients, you > will have to continue using your existing hacks. This is disappointing. Can this limitation be more fully described in the draft, so that those that come after me in this game don't waste time on it? My understanding is that particular MIT and Heimdal versions have some other function (I need to look it up again) that should allow me access to the key material, it's just a pity that we can't get a common standard on the point, and that I can't find something that would in theory accommodate future GSSAPI mechs that may be developed. I have no expectation that Microsoft will change on this point, particularly due to the way NTLMSSP is also tied into this mess, let alone the further need to negotiate such a change... Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-mFg6zVk938bbYVaukQgL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD4DBQBCYFv0z4A8Wyi0NrsRAq15AJ9+GKwQC1Gr1rzFNJK1tZefI/BPWACXfClr 0/YpzRK++juFYgpGKDcAaQ== =F4Aq -----END PGP SIGNATURE----- --=-mFg6zVk938bbYVaukQgL-- --===============1476038953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1476038953==-- From kitten-bounces@ietf.org Fri Apr 15 21:32:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16833; Fri, 15 Apr 2005 21:32:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcLA-0006oZ-SP; Fri, 15 Apr 2005 21:43:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMc1l-0002HA-H0; Fri, 15 Apr 2005 21:23:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMc1i-0002Gy-MA for kitten@megatron.ietf.org; Fri, 15 Apr 2005 21:23:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16431 for ; Fri, 15 Apr 2005 21:23:13 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcC1-0006No-O1 for kitten@ietf.org; Fri, 15 Apr 2005 21:33:54 -0400 Received: from [192.168.1.12] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3G1NAtX019000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Apr 2005 21:23:13 -0400 (EDT) Message-ID: <42606977.8070508@columbia.edu> Date: Fri, 15 Apr 2005 21:25:11 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Bartlett References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> In-Reply-To: <1113611252.7488.282.camel@amy.samba4.abartlet.net> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1238290507==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac This is a cryptographically signed message in MIME format. --===============1238290507== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000502030605040701090002" This is a cryptographically signed message in MIME format. --------------ms000502030605040701090002 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Bartlett wrote: > This is disappointing. Can this limitation be more fully described in > the draft, so that those that come after me in this game don't waste > time on it? I do not believe this is a limitation. The GSS PRF and GSS KRB5 PRF drafts do not attempt to address the question of compatibility with the CIFS utilization of NTLM or Kerberos. The purpose of the specification is to provide a secure method of accessing pseudo-random key data which can be used by application level protocols regardless of the underlying mechanism. The mechanisms used in CIFS assume that the application has intimate knowledge of the underlying mechanism. This is not acceptable for a general purpose GSS method. > My understanding is that particular MIT and Heimdal versions have some > other function (I need to look it up again) that should allow me access > to the key material, it's just a pity that we can't get a common > standard on the point, and that I can't find something that would in > theory accommodate future GSSAPI mechs that may be developed. You are thinking of the krb5 mechanism specific extension: OM_uint32 gss_krb5_get_subkey(const gss_ctx_id_t context_handle, krb5_keyblock **key); which exists in Heimdal but not MIT. MIT will support this in a future release to make things easier for Samba but that is off topic for this list. This function cannot be standardized as part of GSS because it is krb5 mechanism specific and depends on the definition of the krb5_keyblock within the krb5 implementation. As there is no standard krb5 api from which to obtain the definition of a krb5_keyblock, it is not possible to generate a public standard. > I have no expectation that Microsoft will change on this point, > particularly due to the way NTLMSSP is also tied into this mess, let > alone the further need to negotiate such a change... I would not be surprised if the GSS PRF were used within future protocols. However, as we all know, once a protocol is deployed it never dies. > Andrew Bartlett Jeffrey Altman --------------ms000502030605040701090002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDE2MDEyNTEyWjAjBgkqhkiG9w0BCQQxFgQUwetztnhPJzfg3abz9YmDyBAK2+Iw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEArEHfoPElx9zSlC9iphKRx0ncb3cZpmxhBW7ej7Qh PTp1IbaCYOvRQl1RfwjT2E4ztSp2EWlxQek+ZMXPRRo9zi+uaU0B4bibJNCW02nVRfmsqI2a 1O1317xw3aVdYGccAxbButxBsVR/UHZpjQfg32txW6yhw9n9ZRj3hNYpkLZEN4Mjg4IvSkFV 4d8HP7/9rPnND8leQuLbSPNlkk4cWaSTeioSlo1PUFnQ+alnwlrgS07lIuM321fk1ZR6vsEd fEv4GGSSRhoZ6o7b26HQYtlnZZ4JVBYVBSNpUzKjzt+/jh1hGWNYTapyCJ9mjU9XNfOFaX6O RVVgmIn8+95ZMwAAAAAAAA== --------------ms000502030605040701090002-- --===============1238290507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1238290507==-- From kitten-bounces@ietf.org Fri Apr 15 21:43:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17486; Fri, 15 Apr 2005 21:43:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcVC-0007Cw-5i; Fri, 15 Apr 2005 21:53:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcHJ-0003oz-1i; Fri, 15 Apr 2005 21:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcHH-0003om-AN for kitten@megatron.ietf.org; Fri, 15 Apr 2005 21:39:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17112 for ; Fri, 15 Apr 2005 21:39:17 -0400 (EDT) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcRa-000776-Hq for kitten@ietf.org; Fri, 15 Apr 2005 21:49:58 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 9745B1638AE; Sat, 16 Apr 2005 01:39:17 +0000 (GMT) From: Andrew Bartlett To: Jeffrey Altman In-Reply-To: <42606977.8070508@columbia.edu> References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> Date: Sat, 16 Apr 2005 11:39:11 +1000 Message-Id: <1113615551.7488.294.camel@amy.samba4.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1432739395==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 --===============1432739395== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FWQgIunmWcdiRGx+B88D" --=-FWQgIunmWcdiRGx+B88D Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-04-15 at 21:25 -0400, Jeffrey Altman wrote: > Andrew Bartlett wrote: >=20 > > This is disappointing. Can this limitation be more fully described in > > the draft, so that those that come after me in this game don't waste > > time on it? >=20 > I do not believe this is a limitation. The GSS PRF and GSS KRB5 PRF > drafts do not attempt to address the question of compatibility with the > CIFS utilization of NTLM or Kerberos. =20 I'm just asking that it be clarified 'this PRF key stream cannot be used to obtain the original session key or it's length'. > The purpose of the specification > is to provide a secure method of accessing pseudo-random key data which > can be used by application level protocols regardless of the underlying > mechanism. >=20 > The mechanisms used in CIFS assume that the application has intimate > knowledge of the underlying mechanism. This is not acceptable for a > general purpose GSS method. Actually, they don't. All I want the GSSAPI stack to communicate to me is the 'session key', where each mech decides in a existing- implementation-compatible way what that means. All I need to get back is a data,length pair. =20 Samba4 has yet another abstraction layer, GENSEC, which simply returns this to the parts of Samba that need a session key, entirely regardless of what mech was selected. There is no intimate knowlege required. > > My understanding is that particular MIT and Heimdal versions have some > > other function (I need to look it up again) that should allow me access > > to the key material, it's just a pity that we can't get a common > > standard on the point, and that I can't find something that would in > > theory accommodate future GSSAPI mechs that may be developed. >=20 > You are thinking of the krb5 mechanism specific extension: >=20 > OM_uint32 gss_krb5_get_subkey(const gss_ctx_id_t context_handle, > krb5_keyblock **key); >=20 > which exists in Heimdal but not MIT. MIT will support this in a future > release to make things easier for Samba but that is off topic for this > list. >=20 > This function cannot be standardized as part of GSS because it is > krb5 mechanism specific and depends on the definition of the > krb5_keyblock within the krb5 implementation. As there is no standard > krb5 api from which to obtain the definition of a krb5_keyblock, it is > not possible to generate a public standard. I really don't care how the key is returned - nor what abstraction is used. What is wrong with using an existing data,length structure from GSSAPI? Nothing here has to be Kerberos specific. Assuming that NTLMSSP became a GSSAPI mech, it would also present the same interface - it certainly does in Samba4, which is where I make exactly this abstraction. > > I have no expectation that Microsoft will change on this point, > > particularly due to the way NTLMSSP is also tied into this mess, let > > alone the further need to negotiate such a change... >=20 > I would not be surprised if the GSS PRF were used within future > protocols. However, as we all know, once a protocol is deployed it > never dies. Indeed, and I had this false hope that someone else might care about making such existing use sane, on a more portable basis. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-FWQgIunmWcdiRGx+B88D Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCYGy/z4A8Wyi0NrsRAihfAJ9a0aYO4aBgxHICtxAtA1EDUNAN4QCfeXaL av4J4r3SWyLzfP8kdaneGE0= =npAo -----END PGP SIGNATURE----- --=-FWQgIunmWcdiRGx+B88D-- --===============1432739395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1432739395==-- From kitten-bounces@ietf.org Fri Apr 15 22:23:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29730; Fri, 15 Apr 2005 22:23:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMd7v-0000l3-SA; Fri, 15 Apr 2005 22:33:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcUd-00055s-Dv; Fri, 15 Apr 2005 21:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcUb-00055c-Vj for kitten@megatron.ietf.org; Fri, 15 Apr 2005 21:53:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17949 for ; Fri, 15 Apr 2005 21:53:04 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMceu-0007ot-4E for kitten@ietf.org; Fri, 15 Apr 2005 22:03:45 -0400 Received: from [192.168.1.12] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3G1r0CI006696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Apr 2005 21:53:03 -0400 (EDT) Message-ID: <42607079.5040002@columbia.edu> Date: Fri, 15 Apr 2005 21:55:05 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Bartlett References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> <1113615551.7488.294.camel@amy.samba4.abartlet.net> In-Reply-To: <1113615551.7488.294.camel@amy.samba4.abartlet.net> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053391225==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a cryptographically signed message in MIME format. --===============1053391225== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020809000407010502070405" This is a cryptographically signed message in MIME format. --------------ms020809000407010502070405 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Bartlett wrote: > Actually, they don't. All I want the GSSAPI stack to communicate to me > is the 'session key', where each mech decides in a existing- > implementation-compatible way what that means. All I need to get back > is a data,length pair. You are making the false assumption that it is safe to take a key generated for one algorithm and use it with another algorithm. Unfortunately, this is not true. The key you obtain from the underlying mechanism can only be safely used with the cipher for which it is intended. The intimate knowledge that you have of the underlying mechanism is the negotiated cipher to which the key belongs. This is part of what is represented in the krb5_keyblock data structure. It is not simply a random bytes and a length. As implementors, we do care about making it easier for Samba to implement compatibility with Microsoft's products. However, the IETF is not the place for that to happen. Samba is only going to be built with a handful of implementations. The Samba team should work with those implementors to provide the interfaces it requires and ensure that the implementations are compatible. Jeffrey Altman --------------ms020809000407010502070405 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDE2MDE1NTA1WjAjBgkqhkiG9w0BCQQxFgQUtbiSEVpgYgyY5Xl3rpwTHRlC1sEw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAmtiT/0QNddOzHuyHOBNOrs9fQvUtSvVgGGQqZc7a rYySYypsb5eZys0tfZ81i8y79m7vT41v8IbkC3D8ZLHGsVHZu8UAl2Ew8MpfqznpLIO+2OPl /PopXjAZfbDgViSOXtQ407XlYW68lrlj+Fl7CJYT2np0r+Y2Mb1t+oh6/uauox3F10LsNBjj ZE61JTprVgfpncx5XDCN50/JIP5IHoUUXSduLGackmaaioA2bH8NMWU1apg/RHna4x2whXyn gC+Hq3DFU8KL7piu9VzuvABousu8fCqKGY3RY7DDbSI8eAjoih+TH8YQ7fAIyLu3zV4eal1c zju07FUorh/BsAAAAAAAAA== --------------ms020809000407010502070405-- --===============1053391225== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1053391225==-- From kitten-bounces@ietf.org Fri Apr 15 22:46:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15540; Fri, 15 Apr 2005 22:46:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMdUJ-0001ry-F0; Fri, 15 Apr 2005 22:56:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMczL-0007fW-1G; Fri, 15 Apr 2005 22:24:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMczJ-0007fH-Ev for kitten@megatron.ietf.org; Fri, 15 Apr 2005 22:24:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01009 for ; Fri, 15 Apr 2005 22:24:47 -0400 (EDT) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMd9d-0000mm-0j for kitten@ietf.org; Fri, 15 Apr 2005 22:35:29 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id BC5A7163822; Sat, 16 Apr 2005 02:24:47 +0000 (GMT) From: Andrew Bartlett To: Jeffrey Altman In-Reply-To: <42607079.5040002@columbia.edu> References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> <1113615551.7488.294.camel@amy.samba4.abartlet.net> <42607079.5040002@columbia.edu> Date: Sat, 16 Apr 2005 12:24:41 +1000 Message-Id: <1113618281.7488.308.camel@amy.samba4.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0642733629==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --===============0642733629== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hRBs9DhllkBhbttPjxQd" --=-hRBs9DhllkBhbttPjxQd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-04-15 at 21:55 -0400, Jeffrey Altman wrote: > Andrew Bartlett wrote: >=20 > > Actually, they don't. All I want the GSSAPI stack to communicate to me > > is the 'session key', where each mech decides in a existing- > > implementation-compatible way what that means. All I need to get back > > is a data,length pair. =20 >=20 > You are making the false assumption that it is safe to take a key > generated for one algorithm and use it with another algorithm. > Unfortunately, this is not true. The key you obtain from the underlying > mechanism can only be safely used with the cipher for which it is > intended. That may be so, but I have no choice but to build upon the false assumptions of others. > The intimate knowledge that you have of the underlying mechanism is > the negotiated cipher to which the key belongs. This is part of what > is represented in the krb5_keyblock data structure. It is not simply > a random bytes and a length. I have no such knowledge, and indeed if somebody had taught Microsoft's developers these little details, they would not have so readily used these keys as raw input into RC4 and DES encryption of short-runs over user-specified data. (Microsoft resets the keystream with the session key at the start of every encryption for these ops). I'm looking for an answer to 'When using GSSAPI in a CIFS context, you can call X to obtain the session keys used'. I'm not asking for a 'this is the best way to design a new protocol', but as the question is at the GSSAPI level, why can't a single GSSAPI way of obtaining those bytes and length be specified? Why should CIFS implementors (which do extend beyond Samba) have to always kludge their way though this problem? > As implementors, we do care about making it easier for Samba to > implement compatibility with Microsoft's products. However, the IETF > is not the place for that to happen. Samba is only going to be built > with a handful of implementations. The Samba team should work with > those implementors to provide the interfaces it requires and ensure > that the implementations are compatible. Samba already has a large collection of 'fix up' functions trying to bridge the large gaps between implementations. I had just hoped I might avoid yet more as we move forward. But I'm moving in both directions - we would much prefer that we can build with any sane, standards conforming implementation of GSSAPI and Keberos, but instead because of this kind of problem, I am instead looking to build with only custom or specified snapshots of Heimdal Kerberos. I am yet to determine where this particular experiment will end. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-hRBs9DhllkBhbttPjxQd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCYHdpz4A8Wyi0NrsRAoArAJ9+CxYF+zPRptTqyyyEi3l8eN/OtQCgp1BY akoFQfUzF4AXgEPAUwwmIsg= =xzyQ -----END PGP SIGNATURE----- --=-hRBs9DhllkBhbttPjxQd-- --===============0642733629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0642733629==-- From kitten-bounces@ietf.org Fri Apr 15 22:52:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19811; Fri, 15 Apr 2005 22:52:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMdaQ-00026w-QZ; Fri, 15 Apr 2005 23:03:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMdCz-0000IP-Pq; Fri, 15 Apr 2005 22:38:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMdCx-0000IF-Td for kitten@megatron.ietf.org; Fri, 15 Apr 2005 22:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10608 for ; Fri, 15 Apr 2005 22:38:53 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMdNG-0001Z2-JF for kitten@ietf.org; Fri, 15 Apr 2005 22:49:35 -0400 Received: from [192.168.1.12] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3G2cqoo029310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Apr 2005 22:38:53 -0400 (EDT) Message-ID: <42607B3A.3010806@columbia.edu> Date: Fri, 15 Apr 2005 22:40:58 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Bartlett References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> <1113615551.7488.294.camel@amy.samba4.abartlet.net> <42607079.5040002@columbia.edu> <1113618281.7488.308.camel@amy.samba4.abartlet.net> In-Reply-To: <1113618281.7488.308.camel@amy.samba4.abartlet.net> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835497167==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a cryptographically signed message in MIME format. --===============1835497167== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010006000207020709010607" This is a cryptographically signed message in MIME format. --------------ms010006000207020709010607 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew: The IETF does not standardize protocols which do things in an insecure way. That is not the purpose of standardization. The purpose of standardization in the IETF is to get vendors to do things in a way which is secure and known to be interoperable. You wrote "we would much prefer that we can build with any sane, standards conforming implementation of GSSAPI" well there is your problem. Microsoft's CIFS is neither "sane" nor an implementation of GSS. I have started a discussion with you on the krbdev@mit.edu mailing list. Let's take this discussion there. I am sure that we can work with you to get the functionality you need into a future release without muddying the GSS standards track. Jeffrey Altman --------------ms010006000207020709010607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDE2MDI0MDU4WjAjBgkqhkiG9w0BCQQxFgQUALzg3qBWCau66uK9exQ6n5hgYpAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEArNIQemOPneFV5rfp9mUNK3hJVCcVIlenj6uV/8ka NAZKj7Uo89bmbIKcrmzhJqjfRKZa5sxRhegpJuiLtxqswGTlMmYOidC+enuXDFlg5ngHJAKE R3vB+frxOQxulinX0/d4yy1iBS1zgv/zZ70Uo7ItCLUxITeYhBAZN1xb0UYcx2N5sNBNzIya mYGjAD1H2o493BXc4H2Jk9t5PAnJKGwkBo7pq6IHQVuiolOjnbnn0MQveWUXApRSrI9Ii1K/ SpcuycM2dsY+ZNu/t9yPruWTjpSeUcQRyBEbPzqk5nefK3JKxy9aDoxrbgO7GGT63dmFc7F9 QFmWrtVHUDMTCQAAAAAAAA== --------------ms010006000207020709010607-- --===============1835497167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1835497167==-- From kitten-bounces@ietf.org Fri Apr 15 23:10:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24561; Fri, 15 Apr 2005 23:10:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMdrU-00033E-Af; Fri, 15 Apr 2005 23:20:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMdSA-0001Ry-Ej; Fri, 15 Apr 2005 22:54:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMdS9-0001RZ-3F for kitten@megatron.ietf.org; Fri, 15 Apr 2005 22:54:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21199 for ; Fri, 15 Apr 2005 22:54:34 -0400 (EDT) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMdcS-0002IV-Ts for kitten@ietf.org; Fri, 15 Apr 2005 23:05:17 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 4FFE8162C38; Sat, 16 Apr 2005 02:54:35 +0000 (GMT) From: Andrew Bartlett To: Jeffrey Altman In-Reply-To: <42607B3A.3010806@columbia.edu> References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> <1113615551.7488.294.camel@amy.samba4.abartlet.net> <42607079.5040002@columbia.edu> <1113618281.7488.308.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> Date: Sat, 16 Apr 2005 12:54:29 +1000 Message-Id: <1113620069.7488.321.camel@amy.samba4.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1000829213==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 --===============1000829213== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FLVQiikUlz9eQpYzcEoZ" --=-FLVQiikUlz9eQpYzcEoZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-04-15 at 22:40 -0400, Jeffrey Altman wrote: > Andrew: >=20 > The IETF does not standardize protocols which do things in an insecure > way. That is not the purpose of standardization. The purpose of > standardization in the IETF is to get vendors to do things in a way > which is secure and known to be interoperable. I wonder how CIFS ever got itself started down the IETF path then ;-) > You wrote "we would much prefer that we can build with any sane, > standards conforming implementation of GSSAPI" well there is your > problem. Microsoft's CIFS is neither "sane" nor an implementation > of GSS. Indeed. And we don't build against Microsoft CIFS to provide GSSAPI, we just have to work with it on the other end of the network. What is the appropriate forum to discuss things I need from any local GSSAPI implementation that I may want Samba to compile (that's what I meant by build) against and use at runtime? > I have started a discussion with you on the krbdev@mit.edu mailing > list. Let's take this discussion there. I am sure that we can work > with you to get the functionality you need into a future release > without muddying the GSS standards track. I'm happy to participate with a discussion there, and while it appears that the 'world' is pretty much 'MIT and Heimdal', it just didn't seem to be the 'right place' to try and discuss 'anybody doing GSSAPI' issues. =20 Oh well, I seem to have a poor track record of picking the right forums (or understanding IETF policies/politics) in the past, so whatever... Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-FLVQiikUlz9eQpYzcEoZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCYH5lz4A8Wyi0NrsRAnEBAJsFR73ZFv192V6j00r7YNqLUcpLbACeIrom jegDxBKDGXpPPuNLKSkYfR0= =pbc3 -----END PGP SIGNATURE----- --=-FLVQiikUlz9eQpYzcEoZ-- --===============1000829213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1000829213==-- From kitten-bounces@ietf.org Fri Apr 15 23:42:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26594; Fri, 15 Apr 2005 23:42:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMeMR-0004bd-86; Fri, 15 Apr 2005 23:52:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMe11-0004Er-I9; Fri, 15 Apr 2005 23:30:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMe0x-0004Ed-QO for kitten@megatron.ietf.org; Fri, 15 Apr 2005 23:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25872 for ; Fri, 15 Apr 2005 23:30:32 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMeBG-00040J-5N for kitten@ietf.org; Fri, 15 Apr 2005 23:41:15 -0400 Received: from jurassic.eng.sun.com ([129.146.85.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3G3UMjG006674; Fri, 15 Apr 2005 20:30:22 -0700 (PDT) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j3G3UHgT479360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 20:30:18 -0700 (PDT) Message-ID: <42608663.2060506@sun.com> Date: Fri, 15 Apr 2005 23:28:35 -0400 From: Wyllys Ingersoll User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Altman References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> <1113615551.7488.294.camel@amy.samba4.abartlet.net> <42607079.5040002@columbia.edu> <1113618281.7488.308.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> In-Reply-To: <42607B3A.3010806@columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > Andrew: > > The IETF does not standardize protocols which do things in an > insecure way. That is not the purpose of standardization. The > purpose of standardization in the IETF is to get vendors to do things > in a way which is secure and known to be interoperable. > > You wrote "we would much prefer that we can build with any sane, > standards conforming implementation of GSSAPI" well there is your > problem. Microsoft's CIFS is neither "sane" nor an implementation of > GSS. > > I have started a discussion with you on the krbdev@mit.edu mailing > list. Let's take this discussion there. I am sure that we can work > with you to get the functionality you need into a future release > without muddying the GSS standards track. I think Nico and I have an interest in pursuing this conversation a bit further as it is eerily similar to a conversation we recently had with a big customer. Certain protocols and specificiations require access to the raw key data, however, the lack of a "standard" Kerberos API and the inability of GSSAPI to provide the necessary interface for extracting this data has become problematic (to say the least). I look forward to following this more on krbdev... -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Sat Apr 16 00:05:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27807; Sat, 16 Apr 2005 00:05:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMejO-0005ye-Lv; Sat, 16 Apr 2005 00:16:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMeX4-0006tr-An; Sat, 16 Apr 2005 00:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMeX1-0006th-TB for kitten@megatron.ietf.org; Sat, 16 Apr 2005 00:03:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27686 for ; Sat, 16 Apr 2005 00:03:40 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMehK-0005pz-Mh for kitten@ietf.org; Sat, 16 Apr 2005 00:14:24 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3G43ejO027956 for ; Fri, 15 Apr 2005 22:03:40 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3G43eac024463 for ; Fri, 15 Apr 2005 22:03:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3G41Vi9012635; Fri, 15 Apr 2005 23:01:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3G41UeS012634; Fri, 15 Apr 2005 23:01:30 -0500 (CDT) Date: Fri, 15 Apr 2005 23:01:30 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050416040130.GU11875@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Andrew Bartlett , kitten@ietf.org References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42606977.8070508@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Fri, Apr 15, 2005 at 09:25:11PM -0400, Jeffrey Altman wrote: > You are thinking of the krb5 mechanism specific extension: > > OM_uint32 gss_krb5_get_subkey(const gss_ctx_id_t context_handle, > krb5_keyblock **key); > > which exists in Heimdal but not MIT. MIT will support this in a future > release to make things easier for Samba but that is off topic for this > list. > > This function cannot be standardized as part of GSS because it is > krb5 mechanism specific and depends on the definition of the > krb5_keyblock within the krb5 implementation. As there is no standard > krb5 api from which to obtain the definition of a krb5_keyblock, it is > not possible to generate a public standard. *That* function cannot be standardized, but *a* function like it that did not use the 'krb5_keyblock' type *could* be made a standard mechanism-specific GSS-API extension. And why not? SPNEGO has mechanism-specific extensions too... I'd have the function output an INTEGER corresponding to the key's enctype and an OCTET STRING corresponding to the key's value. The C-bindings of that would be straightforward. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Sat Apr 16 00:27:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28977; Sat, 16 Apr 2005 00:27:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMf4e-0006yR-KB; Sat, 16 Apr 2005 00:38:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMeZl-0007Bz-ML; Sat, 16 Apr 2005 00:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMeZj-0007Br-Qf for kitten@megatron.ietf.org; Sat, 16 Apr 2005 00:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27862 for ; Sat, 16 Apr 2005 00:06:29 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMek3-0005yx-VN for kitten@ietf.org; Sat, 16 Apr 2005 00:17:12 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3G46Ti7023860 for ; Fri, 15 Apr 2005 22:06:29 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3G46Sac025095 for ; Fri, 15 Apr 2005 22:06:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3G44JVQ012648; Fri, 15 Apr 2005 23:04:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3G44J30012647; Fri, 15 Apr 2005 23:04:19 -0500 (CDT) Date: Fri, 15 Apr 2005 23:04:19 -0500 From: Nicolas Williams To: Wyllys Ingersoll Message-ID: <20050416040419.GV11875@binky.Central.Sun.COM> Mail-Followup-To: Wyllys Ingersoll , Jeffrey Altman , kitten@ietf.org References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42605868.3020901@columbia.edu> <1113611252.7488.282.camel@amy.samba4.abartlet.net> <42606977.8070508@columbia.edu> <1113615551.7488.294.camel@amy.samba4.abartlet.net> <42607079.5040002@columbia.edu> <1113618281.7488.308.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42608663.2060506@sun.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Fri, Apr 15, 2005 at 11:28:35PM -0400, Wyllys Ingersoll wrote: > Jeffrey Altman wrote: > > > Andrew: > > > > The IETF does not standardize protocols which do things in an > > insecure way. That is not the purpose of standardization. The > > purpose of standardization in the IETF is to get vendors to do things > > in a way which is secure and known to be interoperable. > > > > You wrote "we would much prefer that we can build with any sane, > > standards conforming implementation of GSSAPI" well there is your > > problem. Microsoft's CIFS is neither "sane" nor an implementation of > > GSS. > > > > I have started a discussion with you on the krbdev@mit.edu mailing > > list. Let's take this discussion there. I am sure that we can work > > with you to get the functionality you need into a future release > > without muddying the GSS standards track. > > I think Nico and I have an interest in pursuing this conversation a bit > further as it is eerily similar to a conversation we recently had with > a big customer. Certain protocols and specificiations require access > to the raw key data, however, the lack of a "standard" Kerberos API > and the inability of GSSAPI to provide the necessary interface for > extracting this data has become problematic (to say the least). > > I look forward to following this more on krbdev... I think a forum is needed for this discussion, and krbdev is as good as any (KITTEN is not chartered to do this work, so perhaps KITTEN's list is not a good forum, but I'd be happy to take a personal I-D submission to the IETF covering mechanism-specific GSS-API extensions relating to Kerberos V). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 18 16:30:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNctE-0004hl-L4; Mon, 18 Apr 2005 16:30:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNctC-0004hE-PQ for kitten@megatron.ietf.org; Mon, 18 Apr 2005 16:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05254 for ; Mon, 18 Apr 2005 16:30:36 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNd43-0000jy-Jf for kitten@ietf.org; Mon, 18 Apr 2005 16:41:53 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3IKUZi7023500 for ; Mon, 18 Apr 2005 14:30:35 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3IKUYaa009672 for ; Mon, 18 Apr 2005 14:30:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3IKSKeI014101 for ; Mon, 18 Apr 2005 15:28:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3IKSGuM014100 for kitten@ietf.org; Mon, 18 Apr 2005 15:28:16 -0500 (CDT) Date: Mon, 18 Apr 2005 15:28:16 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050418202816.GT11875@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: PRF_READY -- a proposal X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org So, Sam has given us good reasons to add a PROT_READY-like equivalent for PRF_READY that would work for the krb5 mechanism. Martin indicated support for an additional input parameter to GSS_PRF() to support this feature, as did I. I'm now ready to make a specific proposal: - add an input parameter, 'prf_key', of type INTEGER, to GSS_PRF() - in the C, Java and C# bindings the type would be 'int' - add three constant values for this INTEGER field: - GSS_C_PRF_KEY_DEFAULT - GSS_C_PRF_KEY_PARTIAL - GSS_C_PRF_KEY_OTHER - these three constants will correspond, in order, to the fully established krb5 sec context key (acceptor, initiator, ticket session keys, in that order), the partially established krb5 sec context key (initiator, ticket session keys, in that order), and the ticket session key Rationale for INTEGER as the parameter's type, as opposed to BOOLEAN or BIT STRING (i.e., flags): BOOLEAN has too few values considering the fact that in the Kerberos V mechanism there might be up to three keys one might want to use for the PRF, but I can imagine no mechanism in which more than one key could be used for any one call to GSS_PRF(), so a BIT STRING seems inappropriate, which leaves me with INTEGER or some enumerated type, and since RFC2743 does not use any enumerated type, I chose INTEGER. Comments? I'll post text soon. Remember, we're in WGLC. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 18 19:36:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNfmy-0003x2-6x; Mon, 18 Apr 2005 19:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNfmw-0003wx-Uz for kitten@megatron.ietf.org; Mon, 18 Apr 2005 19:36:22 -0400 Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24299 for ; Mon, 18 Apr 2005 19:36:19 -0400 (EDT) Received: from [172.29.5.202] (dhcp-172-29-5-202.kir.corp.google.com [172.29.5.202]) (authenticated bits=0) by lois.corp.google.com (8.13.3/8.13.3) with ESMTP id j3INZNnD007340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Apr 2005 16:35:24 -0700 Message-ID: <42644439.2040608@google.com> Date: Mon, 18 Apr 2005 16:35:21 -0700 From: Mayank Upadhyay User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org First, I apologize for joining this discussion late. I'm concerned that we are rushing to combining the Java and C# bindings in to one document. If we combine the two bindings into one, my feeling is that over time we will end up with a large switch statement written in plain English. The Java bindings in RFC 2853 aim to provide a vast amount of guidance that is relevant to the Java platform. Each and every bit of it that is not applicable to C# will need to have a case that lists the Java behaviour and the C# behaviour separately. Some of the issues that come to mind right away are: 1. Does C# have a provider framework, and can all the JGSS provider APIs be ported to C#? Does the provider framework have the same level of permissions as the Java one? (See the discussion of security providers throughout RFC 2853.) 2. In Java all methods are virtual unless declared final. Not so in C# - all methods are non-virtual unless the virtual keyword is present in its declaration. This means that all RFC2853 classes that have non-final methods will have different behaviour when called in Java and when called in C#. This affects the mechanism implementor in all classes, and it affects the application developer in ChannelBinding, MessageProp, and Oid. 3. The ChannelBinding class can accept both IPv4 and IPv6 addresses in Java. Will that work in C#? 4. The application developer can make his/her own address class that subclasses InetAddress, and pass that to ChannelBindings. Will that work in C#? 5. All references to package org.ietf.jgss in Java already have to be replaced with references to a namespace in C#. Looking forward, there are two enhancements that should be added to the Java version that may not make sense in the C# version: 1. There is enormous interest in getting a service-provider interface published that allows non-default mechanism providers to add their mechanism implementations to any compliant JGSS package. Again, this relies heavily on the availability of a JCA (Java Crypto Architecture) like provider framework. Even if C# adds one at some point in the future, there may be multi-threading issues with the API itself that may vary between the C# (mono, .NET) and Java platforms. 2. After having implemented JGSS in the Java platform we realized there was a need to clarify what credentials cache should be used by default, and how it may be populated. This refers to the Subject class that is associated with the access control context in the JVM. This class, again, is only relevant in Java, and providing guidance on how to integrate JGSS with it makes a great deal of sense for Java programmers. Moreover, there is no guarantee that C# and Java will not diverge significantly, even beyond the issues mentioned above. We should not compare C# and Java to C and C++. The latter two can make do with one set of bindings because one language is (almost) a proper subset of the other. Since the current requirements of the C# draft are very modest and only refer to the core API, I would recommend that they publish a separate document that references the relevant sections of the Java bindings. As the Java bindings evolve, it may not even be necessary to increment the C# bindings because the changes are unlikely to affect the core. Just my 2 cents! -Mayank _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 18 22:45:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNik6-0004vs-6b; Mon, 18 Apr 2005 22:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNik4-0004vn-Jf for kitten@megatron.ietf.org; Mon, 18 Apr 2005 22:45:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06169 for ; Mon, 18 Apr 2005 22:45:34 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNiv0-0007eZ-0f for kitten@ietf.org; Mon, 18 Apr 2005 22:56:54 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3J2jYjG027671 for ; Mon, 18 Apr 2005 19:45:34 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3J2jXaa025315 for ; Mon, 18 Apr 2005 20:45:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3J2hLt1014900 for ; Mon, 18 Apr 2005 21:43:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3J2hKkc014899 for kitten@ietf.org; Mon, 18 Apr 2005 21:43:20 -0500 (CDT) Date: Mon, 18 Apr 2005 21:43:20 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050419024320.GN14150@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: Subject: GSS PRF diffs X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Below are the changes to draft-ietf-kitten-gssapi-prf-02 and draft-ietf-kitten-krb5-gssapi-prf-02, excluding all formatting and boilerplate changes, for: - IANA considerations - missing Introduction section - New GSS_Pseudo_random() inut parameter, 'prf_key' and three constants, GSS_C_PRF_KEY_DEFAULT/PARTIAL/OTHER, and an informative reference to RFC1964/CFX. - Java and C# bindings of GSS_Pseudo_random() - Proper alignment with RFC3961 (removed text about key usages) - Changed reference for kcrypto from I-D to RFC3961 The only change I haven't yet made is a clarifying change that Jeff asked for relating to the maximum and minimum desired_output_len that must be supported. The diffs, then: --- kitten-gss-prf-02.txt Fri Feb 11 15:36:49 2005 +++ kitten-gss-prf-03.txt Mon Apr 18 18:23:57 2005 @@ Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 5 3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1 Normative References . . . . . . . . . . . . . . . . . . . . . 8 - 5.2 Informative References . . . . . . . . . . . . . . . . . . . . 8 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . . 9 + 3.2 Java Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.3 C# Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1 Normative References . . . . . . . . . . . . . . . . . . . . . 10 + 6.2 Informative References . . . . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 ... @@ 3. GSS_Pseudo_random() Inputs: o context CONTEXT handle, + o prf_key INTEGER, o prf_in OCTET STRING, o desired_output_len INTEGER Outputs: o major_status INTEGER, o minor_status INTEGER, o prf_out OCTET STRING Return major_status codes: o GSS_S_COMPLETE indicates no error. o GSS_S_NO_CONTEXT indicates that a null context has been provided as input. o GSS_S_CONTEXT_EXPIRED indicates that an expired context has been provided as input. o GSS_S_UNAVAILABLE indicates that the mechanism lacks support for this function or, if the security context is not fully established, that the context is not ready to compute the PRF. o GSS_S_FAILURE indicates failure or lack of support; the minor status code may provide additional information. This function applies the established context's mechanism's keyed PRF - function to the input data (prf_in), keyed with key material - associated with the given security context and outputs the resulting - octet string (prf_out) of desired_output_len length. + function, using the desired 'prf_key', to the input data ('prf_in'), + keyed with key material associated with the given security context + and outputs the resulting octet string ('prf_out') of + desired_output_len length. + The prf_key can take on the following values: GSS_C_PRF_KEY_DEFAULT, + GSS_C_PRF_KEY_PARTIAL and GSS_C_PRF_KEY_OTHER. This parameter is + intended to identify a key to use when the PRF operation is called on + a partially established security context by one peer and on a fully- + established security context by the other peer -- in some mechanisms, + such as the Kerberos V GSS-API mechanism [RFC1964], this cannot be + avoided when a the GSS_Pseudo_random() operation is needed pre-full + security context establishment. The GSS_C_PRF_KEY_DEFAULT value + corresponds to the best key available at the time that + GSS_Pseudo_random() is caller. GSS_C_PRF_KEY_PARTIAL corresponds to + a key that would be have been used while the security context is + partially established, even if it is fully established when + GSS_Pseudo_random() is called. GSS_C_PRF_KEY_OTHER is intended to + refer to one other possible key, but mechanisms which may make more + than three keys available for use with GSS_Pseudo_random() must + provide other, mechanism-specific values for prk_key. + The output string of this function MUST be a pseudo-random function [GGM1][GGM2] of the input keyed with key material from the established security context -- the chances of getting the same output given different input parameters should be exponentially small. This function, applied to the same inputs by an initiator and - acceptor using the same established context, MUST produce the *same - results* for both, the initiator and acceptor, even if called + acceptor using the same established context, MUST produce the _same + results_ for both, the initiator and acceptor, even if called multiple times for the same context. @@ 3.1 C-Bindings + #define GSS_C_PRF_KEY_DEFAULT 0 + #define GSS_C_PRF_KEY_PARTIAL 1 + #define GSS_C_PRF_KEY_OTHER 2 + OM_uint32 gss_pseudo_random( OM_uint32 *minor_status, gss_ctx_id_t context, + int prf_key, const gss_buffer_t prf_in, ssize_t desired_output_len, gss_buffer_t prf_out ); +3.2 Java Bindings + For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf': + public static final int GSS_C_PRF_KEY_DEFAULT = 0 + public static final int GSS_C_PRF_KEY_PARTIAL = 1 + public static final int GSS_C_PRF_KEY_OTHER = 2 + public byte[] prf(int prf_key, byte inBuf[], int outlen) + throws GSSException +3.3 C# Bindings + For C# GSS_Pseudo_random() maps to a GSSContext method, 'prf': + public static final int GSS_C_PRF_KEY_DEFAULT = 0 + public static final int GSS_C_PRF_KEY_PARTIAL = 1 + public static final int GSS_C_PRF_KEY_OTHER = 2 + public byte[] prf(int prf_key, byte inBuf[], int outlen) @@ +4. IANA Considerations -4. Security Considerations + This document has no IANA considerations. +5. Security Considerations + Care should be taken in properly designing a mechanism's PRF function. GSS mechanisms' PRF functions should use a key derived from contexts' session keys and should preserve the forward security properties of @@ -5. References +6. References -5.1 Normative References +6.1 Normative References @@ -5.2 Informative References +6.2 Informative References @@ + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June 1996. @@ --- draft-ietf-kitten-krb5-gssapi-prf-02.txt +++ draft-ietf-kitten-krb5-gssapi-prf-03.txt @@ Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . . 3 - 2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4 - 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 3 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 6. Normative References . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 @@ +2. Introduction + This document specifies the Kerberos V GSS-API mechanism's pseudo- + random funtion corresponding to [GSS-PRF]. The function is a "PRF+" + style construction. -2. Kerberos V GSS Mechanism PRF +3. Kerberos V GSS Mechanism PRF The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX] shall be the output of a PRF+ function based on the enctype's PRF function keyed with the negotiated session key of the security - context and key usage X (TBD). + context. The security context MUST be fully established, else the mechanism MUST fail with GSS_S_UNAVAILABLE as the major status code and GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code. - This PRF+ MUST be keyed with a key derived, with key usage (TBD), - from the session used by the initiator and acceptor, after the - security context is fully established, to derive keys for per-message - tokens. For the current Kerberos V mechanism [CFX] this means that - the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did - assert such a key, or the initiator's sub-session key otherwise. + This PRF+ MUST be keyed with the key indicated by the 'prf_key' input + parameter as follows: + o GSS_C_PRF_KEY_DEFAULT -- use the sub-session key asserted by the + acceptor, if any, or the sub-session asserted by the initiator, if + any, or the Ticket's session key + + o GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the + initiator, if any, or the Ticket's session key + + o GSS_C_PRF_KEY_OTHER -- use the Ticket's session key + The PRF+ function is a simple counter-based extension of the Kerberos - V pseudo-random function [KRB5-CRYPTO] for the enctype of the - security context's keys: + V pseudo-random function [RFC3961] for the enctype of the security + context's keys: PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn) - Tn = pseudo-random-function(K, n || S) + Tn = pseudo-random(K, n || S) - where '||' is the concatenation operator, 'n' is encoded as a - network byte order 32-bit unsigned binary number, and where - truncate(L, S) truncates the input octet string S to length L. + where '||' is the concatenation operator, 'n' is encoded as a network + byte order 32-bit unsigned binary number, truncate(L, S) truncates + the input octet string S to length L, and pseudo-random() is the + Kerberos V pseudo-random function [RFC3961]. The maximum output size of the Kerberos V mechanism's GSS-API PRF then is, necessarily, 2^32 octets. Implementations MUST support output size of up to 2^14 octets at @@ +4. IANA Considerations + This document has no IANA considerations. -3. Security Considerations +5. Security Considerations @@ -4 Normative References +6. Normative References @@ - [KRB5-CRYPTO] - Raeburn, K., "Encryption and Checksum Specifications for - Kerberos 5". + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 18 22:46:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNikb-0004wq-CQ; Mon, 18 Apr 2005 22:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNikZ-0004wf-UZ for kitten@megatron.ietf.org; Mon, 18 Apr 2005 22:46:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06185 for ; Mon, 18 Apr 2005 22:46:05 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNivU-0007eo-RP for kitten@ietf.org; Mon, 18 Apr 2005 22:57:26 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3J2k5i7003820 for ; Mon, 18 Apr 2005 20:46:05 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3J2k5aa025953 for ; Mon, 18 Apr 2005 20:46:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3J2hr4E014909 for ; Mon, 18 Apr 2005 21:43:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3J2hrb2014908 for kitten@ietf.org; Mon, 18 Apr 2005 21:43:53 -0500 (CDT) Date: Mon, 18 Apr 2005 21:43:53 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050419024353.GA14870@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org References: <20050419024320.GN14150@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419024320.GN14150@binky.Central.Sun.COM> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Cc: Subject: Re: GSS PRF diffs X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org These are proposed changes, of course. Please review, comment. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Apr 19 12:44:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNvpb-0000Lc-52; Tue, 19 Apr 2005 12:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNvpY-0000LA-QB for kitten@megatron.ietf.org; Tue, 19 Apr 2005 12:44:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25617 for ; Tue, 19 Apr 2005 12:44:05 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNw0Z-0005Hd-HM for kitten@ietf.org; Tue, 19 Apr 2005 12:55:34 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 19 Apr 2005 10:43:54 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Tue, 19 Apr 2005 10:43:39 -0600 From: "Juan Carlos Luciani" To: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: Karl Ford Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Mayank, When defining the C# bindings, we at Novell felt that there was no reason = to diverge from the Java bindings. Keeping the C# bindings as close as = possible to the Java bindings meant that developers familiar with the Java bindings = would have an easier time when developing to the C# bindings. We originally set out to produce a document that only published the C# = bindings and we got feedback that it would be better to extend RFC 2853 since the document that we were producing was duplicating a lot of the information present in the RFC. The concerns that you list are valid. I will consider withdrawing the current draft and publishing the C# bindings in their own document. Thanks, Juan Carlos >>> Mayank Upadhyay 04/18/05 5:35 PM >>> First, I apologize for joining this discussion late. I'm concerned that=20 we are rushing to combining the Java and C# bindings in to one document.=20= If we combine the two bindings into one, my feeling is that over time = we=20 will end up with a large switch statement written in plain English. The Java bindings in RFC 2853 aim to provide a vast amount of guidance=20 that is relevant to the Java platform. Each and every bit of it that is=20 not applicable to C# will need to have a case that lists the Java=20 behaviour and the C# behaviour separately. Some of the issues that come=20 to mind right away are: 1. Does C# have a provider framework, and can all the JGSS provider = APIs=20 be ported to C#? Does the provider framework have the same level of=20 permissions as the Java one? (See the discussion of security providers=20 throughout RFC 2853.) 2. In Java all methods are virtual unless declared final. Not so in C# = -=20 all methods are non-virtual unless the virtual keyword is present in = its=20 declaration. This means that all RFC2853 classes that have non-final=20 methods will have different behaviour when called in Java and when=20 called in C#. This affects the mechanism implementor in all classes, = and=20 it affects the application developer in ChannelBinding, MessageProp, = and=20 Oid. 3. The ChannelBinding class can accept both IPv4 and IPv6 addresses in=20 Java. Will that work in C#? 4. The application developer can make his/her own address class that=20 subclasses InetAddress, and pass that to ChannelBindings. Will that = work=20 in C#? 5. All references to package org.ietf.jgss in Java already have to be=20 replaced with references to a namespace in C#. Looking forward, there are two enhancements that should be added to the=20 Java version that may not make sense in the C# version: 1. There is enormous interest in getting a service-provider interface=20 published that allows non-default mechanism providers to add their=20 mechanism implementations to any compliant JGSS package. Again, this=20 relies heavily on the availability of a JCA (Java Crypto Architecture) =20 like provider framework. Even if C# adds one at some point in the=20 future, there may be multi-threading issues with the API itself that = may=20 vary between the C# (mono, .NET) and Java platforms. 2. After having implemented JGSS in the Java platform we realized there=20 was a need to clarify what credentials cache should be used by default,=20 and how it may be populated. This refers to the Subject class that is=20 associated with the access control context in the JVM. This class,=20 again, is only relevant in Java, and providing guidance on how to=20 integrate JGSS with it makes a great deal of sense for Java programmers. Moreover, there is no guarantee that C# and Java will not diverge=20 significantly, even beyond the issues mentioned above. We should not=20 compare C# and Java to C and C++. The latter two can make do with one=20 set of bindings because one language is (almost) a proper subset of the=20 other. Since the current requirements of the C# draft are very modest and only=20 refer to the core API, I would recommend that they publish a separate=20 document that references the relevant sections of the Java bindings. As=20 the Java bindings evolve, it may not even be necessary to increment the=20 C# bindings because the changes are unlikely to affect the core. Just my 2 cents! -Mayank _______________________________________________ Kitten mailing list Kitten@lists.ietf.org=20 https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Apr 19 12:49:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNvur-0001TA-FK; Tue, 19 Apr 2005 12:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNvuq-0001T5-62 for kitten@megatron.ietf.org; Tue, 19 Apr 2005 12:49:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26069 for ; Tue, 19 Apr 2005 12:49:32 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNw5t-0005Um-8S for kitten@ietf.org; Tue, 19 Apr 2005 13:01:01 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3JGnYi7016888 for ; Tue, 19 Apr 2005 10:49:34 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3JGnXew027911 for ; Tue, 19 Apr 2005 10:49:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3JGlMRu015257; Tue, 19 Apr 2005 11:47:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3JGlKrJ015256; Tue, 19 Apr 2005 11:47:20 -0500 (CDT) Date: Tue, 19 Apr 2005 11:47:20 -0500 From: Nicolas Williams To: Juan Carlos Luciani Message-ID: <20050419164720.GE14150@binky.Central.Sun.COM> Mail-Followup-To: Juan Carlos Luciani , mayank+ietf-kitten@google.com, kitten@ietf.org, Karl Ford References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org, mayank+ietf-kitten@google.com, Karl Ford Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Tue, Apr 19, 2005 at 10:43:39AM -0600, Juan Carlos Luciani wrote: > Mayank, > > When defining the C# bindings, we at Novell felt that there was no reason to > diverge from the Java bindings. Keeping the C# bindings as close as possible to > the Java bindings meant that developers familiar with the Java bindings would > have an easier time when developing to the C# bindings. > > We originally set out to produce a document that only published the C# bindings > and we got feedback that it would be better to extend RFC 2853 since the > document that we were producing was duplicating a lot of the information > present in the RFC. > > The concerns that you list are valid. I will consider withdrawing the > current draft and publishing the C# bindings in their own document. WG consensus on the matter hasn't been reached. I for one would like to hear more about why or why not C# bindings shouldn't be in the same doc as Java bindings. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Apr 19 14:07:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNx8b-0000WO-Mc; Tue, 19 Apr 2005 14:07:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNx8a-0000TJ-RR for kitten@megatron.ietf.org; Tue, 19 Apr 2005 14:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03290 for ; Tue, 19 Apr 2005 14:07:50 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNxJc-0008KE-KX for kitten@ietf.org; Tue, 19 Apr 2005 14:19:19 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3JI7njO020705 for ; Tue, 19 Apr 2005 12:07:49 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3JI7lac013821 for ; Tue, 19 Apr 2005 12:07:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3JI5cL3015338; Tue, 19 Apr 2005 13:05:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3JI5ciC015337; Tue, 19 Apr 2005 13:05:38 -0500 (CDT) Date: Tue, 19 Apr 2005 13:05:38 -0500 From: Nicolas Williams To: Mayank Upadhyay Message-ID: <20050419180537.GK14150@binky.Central.Sun.COM> Mail-Followup-To: Mayank Upadhyay , kitten@ietf.org References: <42644439.2040608@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42644439.2040608@google.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: kitten@ietf.org Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Is it really the case that sub-classing is the intended SPI in Java? RFC2853 seems to explicitly leave the SPI out of scope. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 20 14:48:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKFZ-0003YE-6s; Wed, 20 Apr 2005 14:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKFY-0003Y5-1R for kitten@megatron.ietf.org; Wed, 20 Apr 2005 14:48:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07280 for ; Wed, 20 Apr 2005 14:48:33 -0400 (EDT) Received: from 216-239-45-4.google.com ([216.239.45.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOKQm-0004qo-9d for kitten@ietf.org; Wed, 20 Apr 2005 15:00:13 -0400 Received: from [172.29.5.87] (dhcp-172-29-5-87.kir.corp.google.com [172.29.5.87]) (authenticated bits=0) by lois.corp.google.com (8.13.3/8.13.3) with ESMTP id j3KImJuS008202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2005 11:48:19 -0700 Message-ID: <4266A3F2.4010309@google.com> Date: Wed, 20 Apr 2005 11:48:18 -0700 From: Mayank Upadhyay User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <42644439.2040608@google.com> <20050419180537.GK14150@binky.Central.Sun.COM> In-Reply-To: <20050419180537.GK14150@binky.Central.Sun.COM> X-Spam-Score: -3.8 (---) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: kitten@ietf.org Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0464410321==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0464410321== Content-Type: multipart/alternative; boundary="------------040900030204090502040101" This is a multi-part message in MIME format. --------------040900030204090502040101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >Is it really the case that sub-classing is the intended SPI in Java? >RFC2853 seems to explicitly leave the SPI out of scope. > >Nico > > The the impact on inheritance is irrespective of the SPI. Say, an application developer creates a subclass of ChannelBinding that does some special processing of the input parameters and overrides the accessor methods. During context establishment this object is passed to the underlying mechanism. Now, when the underlying mechanism calls /getAcceptorAddress/() or any of the other accessor methods on this object, in C# the behavior they see will be the base class org.ietf.jgss.ChannelBinding, and not the applications developer's intended behavior. This is because the method in the subclass is not declared virtual. The same thing can happen to /MessageProp /and /Oid/. Regarding the SPI, when we started the Java bindings there were export control issues and the JCA provider model was still being 'digested'. So we decided to simply provide hooks for providers but leave the SPI out to be specified in another doc, another time. Ideally, I would like to see the SPI be part of the base document in the future because export control restrictions have been eased and JCA is better understood now. Irrespective of this issue, all of those hooks that refer to provider in RFC 2853 would create compile time issues for the C# API. -Mayank --------------040900030204090502040101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote:
Is it really the case that sub-classing is the intended SPI in Java?
RFC2853 seems to explicitly leave the SPI out of scope.

Nico
The the impact on inheritance is irrespective of the SPI. Say, an application developer creates a subclass of ChannelBinding that does some special processing of the input parameters and overrides the accessor methods. During context establishment this object is passed to the underlying mechanism. Now, when the underlying mechanism calls getAcceptorAddress() or any of the other accessor methods on this object, in C# the behavior they see will be the base class org.ietf.jgss.ChannelBinding, and not the applications developer's intended behavior. This is because the method in the subclass is not declared virtual. The same thing can happen to MessageProp and Oid.

Regarding the SPI, when we started the Java bindings there were export control issues and the JCA provider model was still being 'digested'. So we decided to simply provide hooks for providers but leave the SPI out to be specified in another doc, another time. Ideally, I would like to see the SPI be part of the base document in the future because export control restrictions have been eased and JCA is better understood now. Irrespective of this issue, all of those hooks that refer to provider in RFC 2853 would create compile time issues for the C# API.

-Mayank



--------------040900030204090502040101-- --===============0464410321== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0464410321==-- From kitten-bounces@lists.ietf.org Wed Apr 20 15:13:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKdK-0006bn-7L; Wed, 20 Apr 2005 15:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKdH-0006be-75 for kitten@megatron.ietf.org; Wed, 20 Apr 2005 15:13:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09662 for ; Wed, 20 Apr 2005 15:13:05 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOKoX-0005Y3-5S for kitten@ietf.org; Wed, 20 Apr 2005 15:24:46 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j3KJD4Q1017428 for ; Wed, 20 Apr 2005 12:13:04 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3KJD3ew014845 for ; Wed, 20 Apr 2005 13:13:03 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3KJApqd006703; Wed, 20 Apr 2005 14:10:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3KJAojB006702; Wed, 20 Apr 2005 14:10:50 -0500 (CDT) Date: Wed, 20 Apr 2005 14:10:50 -0500 From: Nicolas Williams To: Juan Carlos Luciani , mayank+ietf-kitten@google.com, kitten@ietf.org, Karl Ford Message-ID: <20050420191050.GH6590@binky.Central.Sun.COM> Mail-Followup-To: Juan Carlos Luciani , mayank+ietf-kitten@google.com, kitten@ietf.org, Karl Ford References: <20050419164720.GE14150@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419164720.GE14150@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Tue, Apr 19, 2005 at 11:47:20AM -0500, Nicolas Williams wrote: > WG consensus on the matter hasn't been reached. > > I for one would like to hear more about why or why not C# bindings > shouldn't be in the same doc as Java bindings. Mayank has made, privately, one technical argument about the lack in C# of an equivalent for the Java stream classes used in the Java bindings. I believe that, if accurate, that may yet turn out to be a very good reason for specifying the bindings for those two languages in separate documents as the differences between one set of bindings an another might differ too much to justify specifying in one document, and the two bindings would probably progress at different rates, thus the specification of one might hold up the other. I would like to know, out of curiosity if nothing else, if there really are any differences between Java and C# that make it impossible to specify the C# bindings of the GSS-API in terms of lexical transformations of the Java bindings, as Juan has attempted. If the C# bindings of the GSS-API cannot be expressed simply and in terms of the Java bindings then I see no strong reason to specify the two in one document. My mind is not entirely made up as I'm still missing information, but the authors of the existing I-Ds seem willing to pursue separate paths. Jeff, do you think we need a consensus call, or is there consensus already? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 20 15:14:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKew-0006lG-HF; Wed, 20 Apr 2005 15:14:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKev-0006lB-Hn for kitten@megatron.ietf.org; Wed, 20 Apr 2005 15:14:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09867 for ; Wed, 20 Apr 2005 15:14:48 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOKqA-0005bZ-LA for kitten@ietf.org; Wed, 20 Apr 2005 15:26:29 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3KJEjjG002847 for ; Wed, 20 Apr 2005 12:14:46 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3KJEiew015529 for ; Wed, 20 Apr 2005 13:14:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3KJCX1t006726; Wed, 20 Apr 2005 14:12:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3KJCX5I006725; Wed, 20 Apr 2005 14:12:33 -0500 (CDT) Date: Wed, 20 Apr 2005 14:12:33 -0500 From: Nicolas Williams To: Juan Carlos Luciani , mayank+ietf-kitten@google.com, kitten@ietf.org, Karl Ford Message-ID: <20050420191232.GK6590@binky.Central.Sun.COM> Mail-Followup-To: Juan Carlos Luciani , mayank+ietf-kitten@google.com, kitten@ietf.org, Karl Ford References: <20050419164720.GE14150@binky.Central.Sun.COM> <20050420191050.GH6590@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420191050.GH6590@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 20, 2005 at 02:10:50PM -0500, Nicolas Williams wrote: > On Tue, Apr 19, 2005 at 11:47:20AM -0500, Nicolas Williams wrote: > > WG consensus on the matter hasn't been reached. > > > > I for one would like to hear more about why or why not C# bindings > > shouldn't be in the same doc as Java bindings. > > Mayank has made, privately, one technical argument about the lack in C# ^^^ a _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 20 15:37:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOL0t-0000hF-7a; Wed, 20 Apr 2005 15:37:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOL0r-0000hA-Eu for kitten@megatron.ietf.org; Wed, 20 Apr 2005 15:37:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11614 for ; Wed, 20 Apr 2005 15:37:28 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOLC8-000612-Ta for kitten@ietf.org; Wed, 20 Apr 2005 15:49:09 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 20 Apr 2005 13:37:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Wed, 20 Apr 2005 13:36:59 -0600 From: "Juan Carlos Luciani" To: , , "Karl Ford" , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Nico, I have decided to submit a new draft defining the C# bindings in one = document. I believe that doing so will make it easier on C# developers in the long = run. The new document will borrow heavily from RFC2853 and give appropriate = credit. I am hoping to have it ready towards the end of next week. As far as the I/O stream class question that you had, C# does classes that = match the Java implementations. Thanks, Juan Carlos >>> Nicolas Williams 04/20/05 1:10 PM >>> On Tue, Apr 19, 2005 at 11:47:20AM -0500, Nicolas Williams wrote: > WG consensus on the matter hasn't been reached. >=20 > I for one would like to hear more about why or why not C# bindings > shouldn't be in the same doc as Java bindings. Mayank has made, privately, one technical argument about the lack in C# of an equivalent for the Java stream classes used in the Java bindings. I believe that, if accurate, that may yet turn out to be a very good reason for specifying the bindings for those two languages in separate documents as the differences between one set of bindings an another might differ too much to justify specifying in one document, and the two bindings would probably progress at different rates, thus the specification of one might hold up the other. I would like to know, out of curiosity if nothing else, if there really are any differences between Java and C# that make it impossible to specify the C# bindings of the GSS-API in terms of lexical transformations of the Java bindings, as Juan has attempted. If the C# bindings of the GSS-API cannot be expressed simply and in terms of the Java bindings then I see no strong reason to specify the two in one document. My mind is not entirely made up as I'm still missing information, but the authors of the existing I-Ds seem willing to pursue separate paths. Jeff, do you think we need a consensus call, or is there consensus already? Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org=20 https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 20 18:16:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DONUq-00047m-MC; Wed, 20 Apr 2005 18:16:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DONUo-00047h-Sr for kitten@megatron.ietf.org; Wed, 20 Apr 2005 18:16:34 -0400 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.29.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28725 for ; Wed, 20 Apr 2005 18:16:32 -0400 (EDT) Received: from [192.168.1.11] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3KMGS4q005017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Apr 2005 18:16:29 -0400 (EDT) Message-ID: <4266D541.6000702@columbia.edu> Date: Wed, 20 Apr 2005 18:18:41 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <20050419164720.GE14150@binky.Central.Sun.COM> <20050420191050.GH6590@binky.Central.Sun.COM> In-Reply-To: <20050420191050.GH6590@binky.Central.Sun.COM> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Cc: Subject: Re: Why combine the Java and C# bindings? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0832205993==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0832205993== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010504080706080809090803" This is a cryptographically signed message in MIME format. --------------ms010504080706080809090803 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Tue, Apr 19, 2005 at 11:47:20AM -0500, Nicolas Williams wrote: > >>WG consensus on the matter hasn't been reached. >> >>I for one would like to hear more about why or why not C# bindings >>shouldn't be in the same doc as Java bindings. > > My mind is not entirely made up as I'm still missing information, but > the authors of the existing I-Ds seem willing to pursue separate paths. > > Jeff, do you think we need a consensus call, or is there consensus > already? I do not believe that we need an explicit consensus call to determine which path is taken for publication of this work. Back in October when the working group was forming there was a weak consensus that the Java and C# bindings should be merged into one update to 2853 because it was argued that the quantity of work necessary to be performed was modest for both. Java required an update because there were factual errors that needed to be corrected. The C# definition was considered to be minor. In the past two weeks there has been significant discussion regarding the merits of this decision. The editors of both the current Java draft and C# draft are in agreement to go separate ways and I do not see any requirements that only a single document be produced. Here is what I would like to see in the coming month: * I would like to see an updated version of draft-ietf-kitten-rfc2853bis-00.txt published that contains all of the text of rfc2853 modified as stated by the aforementioned draft. * I would like to see a revised version of draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00 which is based on rfc2853 but is specific to C# I believe that rfc2853bis can be sent to the IESG in a very short period of time. A revised rfc is justified to correct the factual errors in 2853. This working group will have a large number of changes published in the coming year and I do not want to wait for the conclusion of this working group before an updated Java bindings RFC is published. A third revision to 2853 can be published as we near the end of the working group to collect all of the Java bindings which are produced for forthcoming APIs. In the meantime, supplementary documents such as the PRF drafts will contain bindings for at least C and Java when they are submitted to the IESG. Jeffrey Altman --------------ms010504080706080809090803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDIwMjIxODQxWjAjBgkqhkiG9w0BCQQxFgQU0PutnVfj85l6xOTrJwQidp3D2hAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAKF+H2LBS2qgM/u2q0zSS8OGH8BNKNCHzhLm07oZL xADztdnw9I9NAsR287Y+6pIwnnGsN3RCmrAjTT0oF3l/PShFi9q5P3KRbGz2Qp5dbDrG035Z e+V5K2/8Xt1xi1+q4NDn3/yDM2Q9NrusEoG1uFL8SeoSPrYiab3TiRy87qxp6BWWxDPOGPys d2p64rI5UXOoD7dXrTaeUQnDDwQQcinmAgi3ncikvuYE/RvkEqHtXI3tFgEhyCB0fCObGHuL xCoIqSARveZyZhenUsBzDV2KK7SFjDGPfZQTQJs6v/iZiya+ottWxz6jBen4ADXWVq+nKe27 eQ1j3j6Ba3IWAgAAAAAAAA== --------------ms010504080706080809090803-- --===============0832205993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0832205993==-- From kitten-bounces@lists.ietf.org Thu Apr 21 14:33:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgUG-00088R-7y; Thu, 21 Apr 2005 14:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgUE-00088D-FS for kitten@megatron.ietf.org; Thu, 21 Apr 2005 14:33:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24912 for ; Thu, 21 Apr 2005 14:33:13 -0400 (EDT) Received: from mailman.vintela.com ([192.41.60.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DOgfh-00077w-1K for kitten@ietf.org; Thu, 21 Apr 2005 14:45:06 -0400 Received: (qmail 15508 invoked by uid 6010); 21 Apr 2005 18:33:01 -0000 Received: from mpeterson@vintela.com by mailman.vintela.com by uid 6008 with qmail-scanner-1.20 (clamuko: 0.65. spamassassin: 2.63. Clear:RC:1(10.1.10.5):. Processed in 0.013045 secs); 21 Apr 2005 18:33:01 -0000 Received: from unknown (HELO mail.vintela.com) (10.1.10.5) by mailman.vintela.com with SMTP; 21 Apr 2005 18:33:01 -0000 Received: from mail2k3.vintela.com ([10.1.10.37]) by mail.vintela.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Apr 2005 12:32:28 -0600 Received: from enum.vintela.com ([10.1.40.152]) by mail2k3.vintela.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Apr 2005 12:32:27 -0600 From: Matt Peterson Organization: Vintela, Inc To: kitten@ietf.org Date: Thu, 21 Apr 2005 12:32:20 -0600 User-Agent: KMail/1.7.1 References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> In-Reply-To: <42608663.2060506@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504211232.20480.mpeterson@vintela.com> X-OriginalArrivalTime: 21 Apr 2005 18:32:27.0768 (UTC) FILETIME=[78581F80:01C546A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Hi, > > Jeffrey Altman wrote: > > I have started a discussion with you on the krbdev@mit.edu mailing > > list. Let's take this discussion there. I am sure that we can work > > with you to get the functionality you need into a future release > > without muddying the GSS standards track. So can someone explain why this is a krbdev@mit.edu discussion and not something suited to the kitten list? I don't think it is mudding the waters at all. It seems to me like a legitmate request for generic API functionality. I agree with Nico's post... > On Friday 15 April 2005 22:01, Nicolas Williams wrote: > [snip] > *That* function cannot be standardized, but *a* function like it that > did not use the 'krb5_keyblock' type *could* be made a standard > mechanism-specific GSS-API extension. > > And why not? SPNEGO has mechanism-specific extensions too... > > I'd have the function output an INTEGER corresponding to the key's > enctype and an OCTET STRING corresponding to the key's value. The > C-bindings of that would be straightforward. I think that GSS-API needs to respond to the types of request being made by the Samba team for a usable API. Why can't we talk about standardizing a function instead of shuffling the discussion off to an implementation specific mailing list? -- Matt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 21 14:33:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgUb-00089E-Ex; Thu, 21 Apr 2005 14:33:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgUa-000899-Sb for kitten@megatron.ietf.org; Thu, 21 Apr 2005 14:33:36 -0400 Received: from mailman.vintela.com (mailman.vintela.com [192.41.60.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24933 for ; Thu, 21 Apr 2005 14:33:35 -0400 (EDT) Received: (qmail 15508 invoked by uid 6010); 21 Apr 2005 18:33:01 -0000 Received: from mpeterson@vintela.com by mailman.vintela.com by uid 6008 with qmail-scanner-1.20 (clamuko: 0.65. spamassassin: 2.63. Clear:RC:1(10.1.10.5):. Processed in 0.013045 secs); 21 Apr 2005 18:33:01 -0000 Received: from unknown (HELO mail.vintela.com) (10.1.10.5) by mailman.vintela.com with SMTP; 21 Apr 2005 18:33:01 -0000 Received: from mail2k3.vintela.com ([10.1.10.37]) by mail.vintela.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Apr 2005 12:32:28 -0600 Received: from enum.vintela.com ([10.1.40.152]) by mail2k3.vintela.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Apr 2005 12:32:27 -0600 From: Matt Peterson Organization: Vintela, Inc To: kitten@ietf.org Date: Thu, 21 Apr 2005 12:32:20 -0600 User-Agent: KMail/1.7.1 References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> In-Reply-To: <42608663.2060506@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504211232.20480.mpeterson@vintela.com> X-OriginalArrivalTime: 21 Apr 2005 18:32:27.0768 (UTC) FILETIME=[78581F80:01C546A0] Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Hi, > > Jeffrey Altman wrote: > > I have started a discussion with you on the krbdev@mit.edu mailing > > list. Let's take this discussion there. I am sure that we can work > > with you to get the functionality you need into a future release > > without muddying the GSS standards track. So can someone explain why this is a krbdev@mit.edu discussion and not something suited to the kitten list? I don't think it is mudding the waters at all. It seems to me like a legitmate request for generic API functionality. I agree with Nico's post... > On Friday 15 April 2005 22:01, Nicolas Williams wrote: > [snip] > *That* function cannot be standardized, but *a* function like it that > did not use the 'krb5_keyblock' type *could* be made a standard > mechanism-specific GSS-API extension. > > And why not? SPNEGO has mechanism-specific extensions too... > > I'd have the function output an INTEGER corresponding to the key's > enctype and an OCTET STRING corresponding to the key's value. The > C-bindings of that would be straightforward. I think that GSS-API needs to respond to the types of request being made by the Samba team for a usable API. Why can't we talk about standardizing a function instead of shuffling the discussion off to an implementation specific mailing list? -- Matt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 21 14:39:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgai-0000Sf-Sb; Thu, 21 Apr 2005 14:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgah-0000SJ-LH for kitten@megatron.ietf.org; Thu, 21 Apr 2005 14:39:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25416 for ; Thu, 21 Apr 2005 14:39:54 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgm9-0007IW-Pe for kitten@ietf.org; Thu, 21 Apr 2005 14:51:47 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3LIdqi7021510 for ; Thu, 21 Apr 2005 12:39:52 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3LIdpaa004255 for ; Thu, 21 Apr 2005 12:39:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3LIbdnB007572; Thu, 21 Apr 2005 13:37:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3LIbbjv007571; Thu, 21 Apr 2005 13:37:37 -0500 (CDT) Date: Thu, 21 Apr 2005 13:37:37 -0500 From: Nicolas Williams To: Matt Peterson Message-ID: <20050421183737.GF7361@binky.Central.Sun.COM> Mail-Followup-To: Matt Peterson , kitten@ietf.org References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> <200504211232.20480.mpeterson@vintela.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504211232.20480.mpeterson@vintela.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 21, 2005 at 12:32:20PM -0600, Matt Peterson wrote: > Hi, > > > > Jeffrey Altman wrote: > > > I have started a discussion with you on the krbdev@mit.edu mailing > > > list. Let's take this discussion there. I am sure that we can work > > > with you to get the functionality you need into a future release > > > without muddying the GSS standards track. > > So can someone explain why this is a krbdev@mit.edu discussion and not > something suited to the kitten list? I don't think it is mudding the waters > at all. It seems to me like a legitmate request for generic API > functionality. KITTEN is not charatered to design a raw krb5 mechanism and associated mechanism-specific GSS extensions. Generic GSS extensions, OTOH, do fall under its charter. There's no need to burden the KITTEN list subscribers with talk of a GSS-based API for raw krb5, at least not yet. None of which means that a raw krb5 API based on the GSS-API couldn't be documented in IETF RFCs. All we need is a forum with the right participants, and I do believe that this is pretty close to being the right forum. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 21 14:40:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgbA-0000ZP-1V; Thu, 21 Apr 2005 14:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgb9-0000ZK-Ji for kitten@megatron.ietf.org; Thu, 21 Apr 2005 14:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25458 for ; Thu, 21 Apr 2005 14:40:22 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgmb-0007JX-V3 for kitten@ietf.org; Thu, 21 Apr 2005 14:52:15 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j3LIeKQ1016456 for ; Thu, 21 Apr 2005 11:40:20 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3LIeKaa004476 for ; Thu, 21 Apr 2005 12:40:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3LIc7lk007579; Thu, 21 Apr 2005 13:38:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3LIc7eH007578; Thu, 21 Apr 2005 13:38:07 -0500 (CDT) Date: Thu, 21 Apr 2005 13:38:07 -0500 From: Nicolas Williams To: Matt Peterson Message-ID: <20050421183807.GF14870@binky.Central.Sun.COM> Mail-Followup-To: Matt Peterson , kitten@ietf.org References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> <200504211232.20480.mpeterson@vintela.com> <20050421183737.GF7361@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050421183737.GF7361@binky.Central.Sun.COM> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 21, 2005 at 01:37:37PM -0500, Nicolas Williams wrote: > On Thu, Apr 21, 2005 at 12:32:20PM -0600, Matt Peterson wrote: > > Hi, > > > > > > Jeffrey Altman wrote: > > > > I have started a discussion with you on the krbdev@mit.edu mailing > > > > list. Let's take this discussion there. I am sure that we can work > > > > with you to get the functionality you need into a future release > > > > without muddying the GSS standards track. > > > > So can someone explain why this is a krbdev@mit.edu discussion and not > > something suited to the kitten list? I don't think it is mudding the waters > > at all. It seems to me like a legitmate request for generic API > > functionality. > > KITTEN is not charatered to design a raw krb5 mechanism and associated > mechanism-specific GSS extensions. Generic GSS extensions, OTOH, do > fall under its charter. > > There's no need to burden the KITTEN list subscribers with talk of a > GSS-based API for raw krb5, at least not yet. > > None of which means that a raw krb5 API based on the GSS-API couldn't be > documented in IETF RFCs. All we need is a forum with the right > participants, and I do believe that this is pretty close to being the > right forum. this == krbdev _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 21 14:48:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgj5-0001lp-LS; Thu, 21 Apr 2005 14:48:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgj3-0001lk-Tp for kitten@megatron.ietf.org; Thu, 21 Apr 2005 14:48:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25892 for ; Thu, 21 Apr 2005 14:48:32 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOguX-0007TD-Lo for kitten@ietf.org; Thu, 21 Apr 2005 15:00:26 -0400 Received: from [192.168.1.11] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3LImWPi020503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2005 14:48:32 -0400 (EDT) Message-ID: <4267F60C.7050206@columbia.edu> Date: Thu, 21 Apr 2005 14:50:52 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> <200504211232.20480.mpeterson@vintela.com> <20050421183737.GF7361@binky.Central.Sun.COM> <20050421183807.GF14870@binky.Central.Sun.COM> In-Reply-To: <20050421183807.GF14870@binky.Central.Sun.COM> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "'krbdev@mit.edu'" Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0501845001==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0501845001== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000400050707030203090307" This is a cryptographically signed message in MIME format. --------------ms000400050707030203090307 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Thu, Apr 21, 2005 at 01:37:37PM -0500, Nicolas Williams wrote: > >>On Thu, Apr 21, 2005 at 12:32:20PM -0600, Matt Peterson wrote: >> >>>Hi, >>> >>> >>>>>Jeffrey Altman wrote: >>>>> I have started a discussion with you on the krbdev@mit.edu mailing >>>>> list. Let's take this discussion there. I am sure that we can work >>>>> with you to get the functionality you need into a future release >>>>> without muddying the GSS standards track. >>> >>>So can someone explain why this is a krbdev@mit.edu discussion and not >>>something suited to the kitten list? I don't think it is mudding the waters >>>at all. It seems to me like a legitmate request for generic API >>>functionality. >> >>KITTEN is not charatered to design a raw krb5 mechanism and associated >>mechanism-specific GSS extensions. Generic GSS extensions, OTOH, do >>fall under its charter. >> >>There's no need to burden the KITTEN list subscribers with talk of a >>GSS-based API for raw krb5, at least not yet. >> >>None of which means that a raw krb5 API based on the GSS-API couldn't be >>documented in IETF RFCs. All we need is a forum with the right >>participants, and I do believe that this is pretty close to being the >>right forum. > > > this == krbdev Nico: Thank you for pressing send on your e-mail before I had a chance to press send on mine. Nico is correct on all counts. When the preliminary work on a raw krb5 mechanism and associated GSS extensions get to the point where a proposal can be made for standards action, those participating can do one of the following: * request that the Kerberos working group be re-chartered to do the work * request that a new working group be chartered * submit one or more individual drafts The important part is that the conversation take place in an open forum with the necessary participants. krbdev@mit.edu is targeted at the development of the MIT Kerberos implementation and is also frequented by developers looking to implement or utilize the MIT APIs. Jeffrey Altman --------------ms000400050707030203090307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDIxMTg1MDUyWjAjBgkqhkiG9w0BCQQxFgQUEoKDQGphsRWDNyXNAWi1eHnYkDgw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA1zm+G4MYvQEtXqjyuOHRfjbLXS9cceUw7uUO+fkc e92LKqtw6pGLKWU1FNVQ4mSATP9lAT61W3oLM9q4vuI+iwO1t0FkIGhti22AZfQd9PJM9J1i 0bCNC0ii68MBKF3jJSxbWzPzEXxo/SYU3XxRpbmSpB+UoMikVYF87HyIX4xaN8pDLFIMwHai rtDd0SGg2JgcQ2d1VVyf+gSxLkSOmWQ57EKqJ97R53R4rqo3N/neb/rY82FQcxUm6UohbsJx /++bMKT9bu08iq7skE3mSFZ2uYIfw1vVs2IZZ/AxdJXTyYLhWNXwrYGjci1fTkKHIVVDy3S2 1hS7FPpb9VsJIAAAAAAAAA== --------------ms000400050707030203090307-- --===============0501845001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0501845001==-- From kitten-bounces@lists.ietf.org Thu Apr 21 17:00:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOimU-00088K-Hv; Thu, 21 Apr 2005 17:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOimQ-00087R-4c for kitten@megatron.ietf.org; Thu, 21 Apr 2005 17:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15904 for ; Thu, 21 Apr 2005 17:00:07 -0400 (EDT) Received: from mailman.vintela.com ([192.41.60.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DOixt-00058E-IV for kitten@ietf.org; Thu, 21 Apr 2005 17:12:02 -0400 Received: (qmail 22079 invoked by uid 6010); 21 Apr 2005 20:59:57 -0000 Received: from mpeterson@vintela.com by mailman.vintela.com by uid 6008 with qmail-scanner-1.20 (clamuko: 0.65. spamassassin: 2.63. Clear:RC:1(10.1.10.5):. Processed in 0.012788 secs); 21 Apr 2005 20:59:57 -0000 Received: from unknown (HELO mail.vintela.com) (10.1.10.5) by mailman.vintela.com with SMTP; 21 Apr 2005 20:59:57 -0000 Received: from mail2k3.vintela.com ([10.1.10.37]) by mail.vintela.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Apr 2005 14:54:25 -0600 Received: from enum.vintela.com ([10.1.40.152]) by mail2k3.vintela.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Apr 2005 14:54:24 -0600 From: Matt Peterson Organization: Vintela, Inc To: Nicolas Williams Date: Thu, 21 Apr 2005 14:54:22 -0600 User-Agent: KMail/1.7.1 References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <20050421183737.GF7361@binky.Central.Sun.COM> <20050421183807.GF14870@binky.Central.Sun.COM> In-Reply-To: <20050421183807.GF14870@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504211454.23148.mpeterson@vintela.com> X-OriginalArrivalTime: 21 Apr 2005 20:54:24.0946 (UTC) FILETIME=[4CFA5920:01C546B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Thursday 21 April 2005 12:38, Nicolas Williams wrote: > KITTEN is not charatered to design a raw krb5 mechanism and associated > mechanism-specific GSS extensions. =A0Generic GSS extensions, OTOH, do > fall under its charter. >=20 > There's no need to burden the KITTEN list subscribers with talk of a > GSS-based API for raw krb5, at least not yet. >=20 > None of which means that a raw krb5 API based on the GSS-API couldn't be > documented in IETF RFCs. =A0All we need is a forum with the right > participants, and I do believe that this is pretty close to being the > right forum. > > this =3D=3D krbdev Ok. As a *mechanism-specific GSS extension* moving the discussion to a new= =20 forum makes sense. (I assume the discussion falls outside the scope of=20 ietf-krb-wg charter?) =20 Thanks for the clarification it wasn't clear in the thread (at least me) th= at =20 movement to krbdev was targeted toward the recommendation of a Generic GSS= =20 extension that addressed the CIFS requirement.=20 Will watch the thread on krbdev. Thanks. =2D- Matt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 21 17:32:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjHT-0004HJ-GI; Thu, 21 Apr 2005 17:32:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjHS-0004HB-7M for kitten@megatron.ietf.org; Thu, 21 Apr 2005 17:32:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17284 for ; Thu, 21 Apr 2005 17:32:12 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOjSx-0005kV-CI for kitten@ietf.org; Thu, 21 Apr 2005 17:44:07 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3LLWBjG004209 for ; Thu, 21 Apr 2005 14:32:12 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3LLWBaa027017 for ; Thu, 21 Apr 2005 15:32:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3LLTufi007894; Thu, 21 Apr 2005 16:29:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3LLTunb007893; Thu, 21 Apr 2005 16:29:56 -0500 (CDT) Date: Thu, 21 Apr 2005 16:29:56 -0500 From: Nicolas Williams To: Matt Peterson Message-ID: <20050421212956.GL7361@binky.Central.Sun.COM> Mail-Followup-To: Matt Peterson , kitten@ietf.org References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <20050421183737.GF7361@binky.Central.Sun.COM> <20050421183807.GF14870@binky.Central.Sun.COM> <200504211454.23148.mpeterson@vintela.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504211454.23148.mpeterson@vintela.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 21, 2005 at 02:54:22PM -0600, Matt Peterson wrote: > Ok. As a *mechanism-specific GSS extension* moving the discussion to a new > forum makes sense. (I assume the discussion falls outside the scope of > ietf-krb-wg charter?) Well, you can read the KRB WG's charter yourself and see :), and though I haven't just looked at it, I'm pretty sure that such work would, indeed, not be in scope for that WG. WG charters are not written in stone though, and can be changed. But I think it will be much more productive to proceed with this particular work in krbdev for a while and then pop back up at the IETF, either using individual submissions, a new WG, re-chartering an existing WG -- whatever. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 27 11:11:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQoBy-0007Ts-9M; Wed, 27 Apr 2005 11:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQoBw-0007SY-K0 for kitten@megatron.ietf.org; Wed, 27 Apr 2005 11:11:08 -0400 Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.29.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23481 for ; Wed, 27 Apr 2005 11:11:06 -0400 (EDT) Received: from [192.168.1.11] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3RFB0iI004325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Apr 2005 11:11:01 -0400 (EDT) Message-ID: <426FAC16.3040700@columbia.edu> Date: Wed, 27 Apr 2005 11:13:26 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Cc: Subject: WGLC Reminder: GSS PRF and GSS KRB5 PRF drafts X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1938276264==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1938276264== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070908000904060405000104" This is a cryptographically signed message in MIME format. --------------ms070908000904060405000104 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks. This is a reminder that the working group last call on the PRF drafts is scheduled to end tomorrow. There has up to this point been very little discussion of the content of the drafts and the proposed changes that Nico posted to the list on April 18th. I would appreciate it if folks would review the documents as PRF is crucial to several application protocols which are looking to implement GSS-based security. For a reminder here is a copy of the announcement text: Today begins a Working Group Last Call on the working group drafts: * draft-ietf-kitten-gssapi-prf-02.txt * draft-ietf-kitten-krb5-gssapi-prf-02.txt There are known issues related to ID-Nits failures which will be addressed at the end of the working group last call period prior to submission to the IESG. * draft-ietf-kitten-gssapi-prf-02.txt: - The IANA Considerations section is missing - The boilerplate must be updated to RFC 3978 - The IPR disclosure must be in conformance with BCP 79. * draft-ietf-kitten-krb5-gssapi-prf-02.txt: - The Introductions section is missing - The IANA Considerations section is missing - The boilerplate must be updated to RFC 3978 - The IPR disclosure must be in conformance with BCP 79. In addition, there are two issues which must be addressed for there to be a successful completion of the WGLC. (1) Language Bindings for Java and C# should be provided as part of draft-ietf-kitten-gssapi-prf (2) Appropriate text specifying how the key usage for the Krb5 PRF function will be determined must be added. This WGLC will end on April 28, 2005. Jeffrey Altman --------------ms070908000904060405000104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDI3MTUxMzI3WjAjBgkqhkiG9w0BCQQxFgQU+UxoeB13DTECDbLvdjD6Oq1wLCIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAWchtdgglgeViwNDxPw+7Zn1x+kSqTbG8jLYvU4a7 I/acys/le9/0mk6oMbZHZHcq57EQwv4OSNTLA3YRwN8/eUz65n4LmN1hJlobKFqZTDqTuxvM FozLrJT8xluh9VmSr8YgIc7PKFGLv3B6ACpfKITHumuYJytO6ATGqZP75AXV9YJwhgEoPH48 0oZmQQu89oLcaJABxuq/Wh8N3WFnF/a3brjEhUeyxT+Etz3409CyMmesuqWo5PnlUk0Q2AI3 i59N15Br0vWKUxGnT2eq1eymXOaH0Ey+s1PknBTaenygIIqM1EnbSC9Lh+i9iwB1yzTTfyWz NDrcdF3aDCUYzgAAAAAAAA== --------------ms070908000904060405000104-- --===============1938276264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1938276264==-- From kitten-bounces@lists.ietf.org Thu Apr 28 09:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR8jU-0001IO-IW; Thu, 28 Apr 2005 09:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR8jS-0001FE-E4 for kitten@megatron.ietf.org; Thu, 28 Apr 2005 09:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12262 for ; Thu, 28 Apr 2005 09:07:04 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR8wJ-0001Ud-3v for kitten@ietf.org; Thu, 28 Apr 2005 09:20:24 -0400 Received: from [192.168.1.11] (cpe-24-193-46-55.nyc.res.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3SD73Gk007200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 Apr 2005 09:07:03 -0400 (EDT) Message-ID: <4270E08A.2040802@columbia.edu> Date: Thu, 28 Apr 2005 09:09:30 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <426FAC16.3040700@columbia.edu> In-Reply-To: <426FAC16.3040700@columbia.edu> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: Extended One Week: WGLC GSS PRF and GSS KRB5 PRF drafts X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1414748553==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1414748553== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070907020302010109030605" This is a cryptographically signed message in MIME format. --------------ms070907020302010109030605 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The working group last call on the two PRF related documents is being extended until Thursday May 5th. Yesterday there was extensive off-list discussion on the drafts among Nico Williams, Ken Raeburn, Tom Yu, and Jeffrey Hutzelman. Nico has agreed to post new versions of the drafts to a web site and summarize for the list the discussions in order that consensus can be reached on the changes prior to submission to the Internet-Drafts editor. I look forward to the rest of the working group being able to review the work. Jeffrey Altman --------------ms070907020302010109030605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNDI4MTMwOTMwWjAjBgkqhkiG9w0BCQQxFgQUHVuEGVcHHN8vdsE85g74imBvKYUw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA3Hk6PV9QAZa4Uh2sNKIJ3/Yk19rgEZ1vbLP2V0C2 TWNmGRi/3piyEjaj58EO8PEDVTHG//OFgF4g1GBwTmWVCOWY4dHc18LS+MO3u61k/e33NUZ5 W+U9i/cJWfKBZl4hF0+aYfmllXcJl2hLEnSXiTkPI6WUUNySqcY1ocZTWEOhTeCW04rXN0uC jisC7ji4l96AYzeXOnmz7LPslCLDBblGpsO2LOZ1uHtDtupzBrPUF2LzVmyvFfJvSsyOQOFT DQohbc9m8SFkn5FFpUHJokmzZh3vAqUYUExdACw8ZsomnKpSRYVU5pjW9gchhhy3f9i8NvA3 G3x+pZB7PPjKKAAAAAAAAA== --------------ms070907020302010109030605-- --===============1414748553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1414748553==-- From kitten-bounces@lists.ietf.org Thu Apr 28 17:01:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRG8k-0003it-QB; Thu, 28 Apr 2005 17:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRG8j-0003io-Kz for kitten@megatron.ietf.org; Thu, 28 Apr 2005 17:01:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24685 for ; Thu, 28 Apr 2005 17:01:37 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRGLb-0004zD-4s for kitten@ietf.org; Thu, 28 Apr 2005 17:15:01 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3SL1UjG015798 for ; Thu, 28 Apr 2005 14:01:35 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3SL1Tac025584 for ; Thu, 28 Apr 2005 15:01:30 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3SL1Q9p014268; Thu, 28 Apr 2005 16:01:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3SL1PlN014267; Thu, 28 Apr 2005 16:01:25 -0500 (CDT) Date: Thu, 28 Apr 2005 16:01:25 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050428210125.GX13276@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <426FAC16.3040700@columbia.edu> <4270E08A.2040802@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4270E08A.2040802@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: kitten@ietf.org Subject: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSS KRB5 PRF drafts X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 28, 2005 at 09:09:30AM -0400, Jeffrey Altman wrote: > The working group last call on the two PRF related documents is being > extended until Thursday May 5th. Yesterday there was extensive off-list > discussion on the drafts among Nico Williams, Ken Raeburn, Tom Yu, and > Jeffrey Hutzelman. Nico has agreed to post new versions of the drafts > to a web site and summarize for the list the discussions in order that > consensus can be reached on the changes prior to submission to the > Internet-Drafts editor. http://blogs.sun.com/roller/resources/nico/kitten-gss-prf-03.txt http://blogs.sun.com/roller/resources/nico/kitten-krb5-gss-prf-03.txt I'll generate some cleaned up diff output and post it. Changes include: - I-D nits, typo fixes - addition of 'prf_key' key identifier to GSS_Pseudo_random(), to support a PROT_READY-like feature and generic key identifier constants, GSS_C_PRF_KEY_DEFAULT and GSS_C_PRF_KEY_PARTIAL - cleaned up text on minimum and minimum maximum input and output data sizes that must be supported > I look forward to the rest of the working group being able to review > the work. Me too. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 28 18:52:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRHsL-0001nL-Le; Thu, 28 Apr 2005 18:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRHsK-0001nG-7g for kitten@megatron.ietf.org; Thu, 28 Apr 2005 18:52:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05217 for ; Thu, 28 Apr 2005 18:52:49 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRI5F-0001Cn-Vn for kitten@ietf.org; Thu, 28 Apr 2005 19:06:15 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3SMqkjO015625 for ; Thu, 28 Apr 2005 16:52:46 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j3SMqjac000260 for ; Thu, 28 Apr 2005 16:52:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j3SMqjZI014432; Thu, 28 Apr 2005 17:52:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j3SMqjBX014431; Thu, 28 Apr 2005 17:52:45 -0500 (CDT) Date: Thu, 28 Apr 2005 17:52:45 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050428225245.GA14398@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <426FAC16.3040700@columbia.edu> <4270E08A.2040802@columbia.edu> <20050428210125.GX13276@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428210125.GX13276@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Diffs (was Re: Extended One Week: WGLC GSS PRF and GSS KRB5 PRF drafts) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 28, 2005 at 04:01:25PM -0500, Nicolas Williams wrote: > http://blogs.sun.com/roller/resources/nico/kitten-gss-prf-03.txt > http://blogs.sun.com/roller/resources/nico/kitten-krb5-gss-prf-03.txt > > I'll generate some cleaned up diff output and post it. http://blogs.sun.com/roller/resources/nico/kitten-gss-prf.02_03.diffs http://blogs.sun.com/roller/resources/nico/kitten-krb5-gss-prf.02_03.diffs Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten