From kitten-bounces@lists.ietf.org Tue May 03 01:16:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSplU-00069e-Vw; Tue, 03 May 2005 01:16:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSplR-00060H-5M for kitten@megatron.ietf.org; Tue, 03 May 2005 01:16: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 BAA06623 for ; Tue, 3 May 2005 01:16:08 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSpzF-0006Ph-5N for kitten@ietf.org; Tue, 03 May 2005 01:30:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 May 2005 22:15:59 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j435FpKx026004; Mon, 2 May 2005 22:15:51 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 2 May 2005 22:19:37 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69051E8A4F@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 PRF drafts Thread-Index: AcVMNhlgZCix1bQFRduD1k9i53ZLpgDYmPdA From: "Salowey, Joe" To: "Nicolas Williams" , "Jeffrey Altman" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 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 Here are some comments on the GSS-PRF draft. =20 1. GSS_C_PRF_KEY_PARTIAL - you might want to mention that there should only be one key specified as GSS_C_PRF_KEY_PARTIAL so that if a mechanism happened to take a few round trips (perhaps contributing to the complete key material) to complete you are sure that the call always uses the same key value. Ok this is mentioned at the end of the section, you might re-organized this so it is discussed in the same place.=20 2. I think this is stated, but I want to make sure that if you call the function on a context with the same parameters multiple times you get the same results each time. =20 3. In the security considerations, is there anything that can be said of the keys generated from partial context after a context has completed? In particular since mutual authentication has not happened at the time the keys were generated is data protected under those keys valid if the context complete successfully? Is it worth mentioning that the in addition to forward protection that the derived material from different inputs must be computationally independent from one another and from any keys used for the GSS-WRAP and GSS-MIC calls (i.e. so if you know the input and corresponding key material that it is not computationally feasible to compute the material for another input)? It probably should also state that the GSS_C_PRF_KEY_DEFAULT and GSS_C_PRF_KEY_PARTIAL MUST be derived from secret key material and not just public data. =20 4. In general I think this looks good for what might be useful in EAP. When we were working on key derivation for EAP we broke the input data into a part that was a standard tag that identified the purpose of the key material and a part that was instance specific data. This was to prevent the same data from being used for two different key usages resulting in a key collision. This was important because it was possible that one consumer of key material was unaware of what another consumer was requesting. It also provided a way to control access to certain key material. In GSS-API perhaps this is not a problem since the consumers will in general be part of the same application/process (although I suppose the context can be exported). =20 5. We should probably chat a bit more about how this could fit with EAP offline. =20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Thursday, April 28, 2005 2:01 PM > To: Jeffrey Altman > Cc: kitten@ietf.org > Subject: Updated I-Ds location Re: Extended One Week: WGLC=20 > GSS PRF and GSSKRB5 PRF drafts >=20 > On Thu, Apr 28, 2005 at 09:09:30AM -0400, Jeffrey Altman wrote: > > The working group last call on the two PRF related=20 > documents is being=20 > > extended until Thursday May 5th. Yesterday there was extensive=20 > > off-list discussion on the drafts among Nico Williams, Ken Raeburn,=20 > > Tom Yu, and Jeffrey Hutzelman. Nico has agreed to post new=20 > versions=20 > > of the drafts to a web site and summarize for the list the=20 > discussions=20 > > in order that consensus can be reached on the changes prior to=20 > > submission to the Internet-Drafts editor. >=20 > 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 >=20 > I'll generate some cleaned up diff output and post it. >=20 > Changes include: >=20 > - I-D nits, typo fixes >=20 > - 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 >=20 > - cleaned up text on minimum and minimum maximum input and=20 > output data > sizes that must be supported >=20 > > I look forward to the rest of the working group being able=20 > to review=20 > > the work. >=20 > Me too. >=20 > Nico > --=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten >=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 03 01:35:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSq3l-0003jZ-73; Tue, 03 May 2005 01:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSq3j-0003dz-F7 for kitten@megatron.ietf.org; Tue, 03 May 2005 01:35:03 -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 BAA08259 for ; Tue, 3 May 2005 01:35:00 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSqHW-0006lo-Cu for kitten@ietf.org; Tue, 03 May 2005 01:49:18 -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 j435Yxi7006905 for ; Mon, 2 May 2005 23:34:59 -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 j435Ywf0011290 for ; Mon, 2 May 2005 23:34: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 j435YvXk002609; Tue, 3 May 2005 00:34:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j435YrCv002608; Tue, 3 May 2005 00:34:53 -0500 (CDT) Date: Tue, 3 May 2005 00:34:53 -0500 From: Nicolas Williams To: "Salowey, Joe" Message-ID: <20050503053452.GT28366@binky.Central.Sun.COM> Mail-Followup-To: "Salowey, Joe" , Jeffrey Altman , kitten@ietf.org References: <7210B31550AC934A8637D6619739CE69051E8A4F@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE69051E8A4F@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: kitten@ietf.org Subject: Re: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 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 Mon, May 02, 2005 at 10:19:37PM -0700, Salowey, Joe wrote: > Here are some comments on the GSS-PRF draft. > > 1. GSS_C_PRF_KEY_PARTIAL - you might want to mention that there should > only be one key specified as GSS_C_PRF_KEY_PARTIAL so that if a > mechanism happened to take a few round trips (perhaps contributing to > the complete key material) to complete you are sure that the call always > uses the same key value. Ok this is mentioned at the end of the > section, you might re-organized this so it is discussed in the same > place. I'll think about moving or re-organizing that text so that this requirement can be found where prf_key is discussed. But it's bloody short text already... :) > 2. I think this is stated, but I want to make sure that if you call the > function on a context with the same parameters multiple times you get > the same results each time. The last paragraph of section 2 of the -03 I put up on mediacast says: ... Mechanisms that support GSS_C_PRF_KEY_PARTIAL MUST use the same PRF and key material, for any given security context and prf_key, both, before and after full context establishment, and the PRF and key material negotiation MUST be authenticated when the security context is fully established. > 3. In the security considerations, is there anything that can be said of > the keys generated from partial context after a context has completed? > In particular since mutual authentication has not happened at the time > the keys were generated is data protected under those keys valid if the > context complete successfully? The text above requires that upon full establishment the key material used for GSS_C_PRF_KEY_PARTIAL must be authenticated. I left out any verbiage about mutual authentication because that is optional, but I thought that what is meant by "MUST be authenticated" should be clear -- if not I can come up with additional text that does make it clear. > Is it worth mentioning that the in addition to forward protection that > the derived material from different inputs must be computationally > independent from one another and from any keys used for the GSS-WRAP and > GSS-MIC calls (i.e. so if you know the input and corresponding key > material that it is not computationally feasible to compute the material > for another input)? It probably should also state that the > GSS_C_PRF_KEY_DEFAULT and GSS_C_PRF_KEY_PARTIAL MUST be derived from > secret key material and not just public data. Agreed. I'll work up some text. > 4. In general I think this looks good for what might be useful in EAP. > When we were working on key derivation for EAP we broke the input data > into a part that was a standard tag that identified the purpose of the > key material and a part that was instance specific data. This was to > prevent the same data from being used for two different key usages > resulting in a key collision. This was important because it was > possible that one consumer of key material was unaware of what another > consumer was requesting. It also provided a way to control access to > certain key material. In GSS-API perhaps this is not a problem since > the consumers will in general be part of the same application/process > (although I suppose the context can be exported). Right. Applications that pass exported contexts around should coordinate what input they pass to GSS_Pseudo_random(). A convention of prefixing a usage tag to the input data can always be applied by GSS applications if they may make multiple unrelated calls to GSS_Pseudo_random(). Making such a usage tag an input parameter to the function doesn't necessarily mean that proper use of it will be made, and because apps can fashion one where necessary it seems like overkill to add such a parameter. The security considerations text already stresses the need to use different input data for separate invocations on the same context. Perhaps we should point out the "prepend a usage indicator" approach... Alternatively we could add a per-call, per-context call counter that is used as a usage indicator, but this would impose PRF call ordering on the application, which seems like a bad idea. > 5. We should probably chat a bit more about how this could fit with EAP > offline. Yes. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 03 14:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1vO-0000uy-UV; Tue, 03 May 2005 14:15:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1vN-0000us-3B for kitten@megatron.ietf.org; Tue, 03 May 2005 14:15:13 -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 OAA17284 for ; Tue, 3 May 2005 14:15:09 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT29E-0000P8-QN for kitten@ietf.org; Tue, 03 May 2005 14:29:35 -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 j43IF4jG000702 for ; Tue, 3 May 2005 11:15: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 j43IF0f0021052 for ; Tue, 3 May 2005 12:15:02 -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 j43IF08V003278; Tue, 3 May 2005 13:15:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j43IExZb003277; Tue, 3 May 2005 13:14:59 -0500 (CDT) Date: Tue, 3 May 2005 13:14:59 -0500 From: Nicolas Williams To: "Salowey, Joe" , Jeffrey Altman , kitten@ietf.org Message-ID: <20050503181458.GO11194@binky.Central.Sun.COM> Mail-Followup-To: "Salowey, Joe" , Jeffrey Altman , kitten@ietf.org References: <7210B31550AC934A8637D6619739CE69051E8A4F@e2k-sea-xch2.sea-alpha.cisco.com> <20050503053452.GT28366@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503053452.GT28366@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: Re: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 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 Tue, May 03, 2005 at 12:34:52AM -0500, Nicolas Williams wrote: > On Mon, May 02, 2005 at 10:19:37PM -0700, Salowey, Joe wrote: > > Is it worth mentioning that the in addition to forward protection that > > the derived material from different inputs must be computationally > > independent from one another and from any keys used for the GSS-WRAP and > > GSS-MIC calls (i.e. so if you know the input and corresponding key > > material that it is not computationally feasible to compute the material > > for another input)? It probably should also state that the > > GSS_C_PRF_KEY_DEFAULT and GSS_C_PRF_KEY_PARTIAL MUST be derived from > > secret key material and not just public data. > > Agreed. I'll work up some text. I think the existing requirement that the function be a pseudo-random function obtains the desired computational independence of GSS_PRF() outputs for different inputs. In the paragraph that reads: This function applies the established context's mechanism's keyed PRF function, using the desired key identified by '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. I propose to change "...keyed with key material..." to "...keyed with secret key material...," a rather trivial change :) I propose the addition of "[the] PRF and/or its input key material must be computationally independent from the keys and/or cryptographic operations used by the mechanism for per-message tokens (MICs and wraps)" at the end of the same paragraph. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 05 14:25:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTl2U-0000KI-AT; Thu, 05 May 2005 14:25:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTl2S-0000HE-Ay for kitten@megatron.ietf.org; Thu, 05 May 2005 14:25: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 OAA27255 for ; Thu, 5 May 2005 14:25:30 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTlGm-0008PY-Lh for kitten@ietf.org; Thu, 05 May 2005 14:40:22 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j45IPLeA011354 for ; Thu, 5 May 2005 18:25:21 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j45IP0ZO002828 for ; Thu, 5 May 2005 18:25:21 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050511252125754 for ; Thu, 05 May 2005 11:25:21 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 11:25:20 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 11:25:20 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 14:24:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 May 2005 14:24:30 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929011958EC@pysmsx401.amr.corp.intel.com> Thread-Topic: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 PRF drafts Thread-Index: AcVRncwNu4gFr7wvSK+4VLYJU74V8QAACV9AAABZ5WA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 05 May 2005 18:24:59.0376 (UTC) FILETIME=[BEDD6F00:01C5519F] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: Subject: FW: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 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 After a verbal discussion with Joe and Nico, we came up with the idea of augmenting the normative reference list in GSS PRF draft with Handbook of Applied Cryptography, by Menezes, van Oorschot and Vanstone, CRC Press, ISBN: 0-8493-8523-7. 5th printing in 2001. Chapter 5 deals with Pseudorandom sequences. Still enough math, but with a practical bent, usable by somebody who wants to design one. Also, I just went through "kitten-krb5-gss-prf-03" and found it OK. Tnx! Regards, Uri _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 05 16:37:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn6K-0001eO-2F; Thu, 05 May 2005 16:37:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn6J-0001eJ-Ed for kitten@megatron.ietf.org; Thu, 05 May 2005 16:37:39 -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 QAA11717 for ; Thu, 5 May 2005 16:37:36 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnKe-0006jh-JG for kitten@ietf.org; Thu, 05 May 2005 16:52:29 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1DFC1E0063; Thu, 5 May 2005 16:37:32 -0400 (EDT) To: "Blumenthal, Uri" References: <3DEC199BD7489643817ECA151F7C5929011958EC@pysmsx401.amr.corp.intel.com> From: Sam Hartman Date: Thu, 05 May 2005 16:37:31 -0400 In-Reply-To: <3DEC199BD7489643817ECA151F7C5929011958EC@pysmsx401.amr.corp.intel.com> (Uri Blumenthal's message of "Thu, 5 May 2005 14:24:30 -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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org Subject: Re: FW: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 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 >>>>> "Blumenthal," == Blumenthal, Uri writes: Blumenthal,> After a verbal discussion with Joe and Nico, we came Blumenthal,> up with the idea of augmenting the normative Blumenthal,> reference list in GSS PRF draft with Blumenthal,> Handbook of Applied Cryptography, by Menezes, van Blumenthal,> Oorschot and Vanstone, CRC Press, ISBN: Blumenthal,> 0-8493-8523-7. 5th printing in 2001. Blumenthal,> Chapter 5 deals with Pseudorandom sequences. Still Blumenthal,> enough math, but with a practical bent, usable by Blumenthal,> somebody who wants to design one. A pseudo-random sequence isn't really the same thing as a PRF is it? Or does their definition of sequence include arbitrary indexing which I guess would be close enough. This seems like an informative not normative reference. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 05 16:40:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn8p-0002ea-QG; Thu, 05 May 2005 16:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTn8l-0002eA-Tq for kitten@megatron.ietf.org; Thu, 05 May 2005 16:40:12 -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 QAA12340 for ; Thu, 5 May 2005 16:40:08 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnN8-0006wo-9u for kitten@ietf.org; Thu, 05 May 2005 16:55:02 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EC2ECE0063; Thu, 5 May 2005 16:40:05 -0400 (EDT) To: "Salowey, Joe" References: <7210B31550AC934A8637D6619739CE69051E8A4F@e2k-sea-xch2.sea-alpha.cisco.com> From: Sam Hartman Date: Thu, 05 May 2005 16:40:05 -0400 In-Reply-To: <7210B31550AC934A8637D6619739CE69051E8A4F@e2k-sea-xch2.sea-alpha.cisco.com> (Joe Salowey's message of "Mon, 2 May 2005 22:19:37 -0700") 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: 01485d64dfa90b45a74269b3ca9d5574 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 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 These look reasonable as well. I have not actually done an AD review yet though. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 05 17:12:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTndY-0008Oy-EL; Thu, 05 May 2005 17:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTndW-0008Os-By for kitten@megatron.ietf.org; Thu, 05 May 2005 17:11:58 -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 RAA18031 for ; Thu, 5 May 2005 17:11:55 -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 1DTnrs-00011n-5R for kitten@ietf.org; Thu, 05 May 2005 17:26:49 -0400 Received: from [128.149.196.242] (dhcp-149-196-242.jpl.nasa.gov [128.149.196.242]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j45LBqHZ028644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 May 2005 17:11:53 -0400 (EDT) Message-ID: <427A8CA8.3050200@columbia.edu> Date: Thu, 05 May 2005 14:14:16 -0700 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, Kerberos WG 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: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: WGLC Cancelled - GSS PRF and GSS-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="===============0654257767==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0654257767== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070206060704050100090907" This is a cryptographically signed message in MIME format. --------------ms070206060704050100090907 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The WGLC on the GSS PRF and GSS-KRB5 PRF has not resulted in consensus on the existing documents. Several sets of discussions have resulted in changes to the document for which I want to see a new set of documents be published. A new WGLC will be announced in a later date. Jeffrey Altman --------------ms070206060704050100090907 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 DxcNMDUwNTA1MjExNDE2WjAjBgkqhkiG9w0BCQQxFgQU0T3xp0ll+6K7t+7jbEhCzj1FCSYw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAkn769tsTGlWmoqZTlkRutEjgFhzJMFaOPzsqTfaw 9FD8+WpqyW5MnrXjJzBTVqafISz069Q8WBGTqoAak1KDq6s7rIciCjnQ4Eqj9apkVkfr8US5 omT+WUq5Tjf1yNuO/goKaPRVG90z0BBMeTWaBQEjNREE1x0MBiSTDbXhea9wQuykkqX9bVnS T5VcPnQPJrSsRVnoUnDXavdD8g1yvDCOwocqQYQ7rErXAuQ4Qp1B3OrxxINNq/YvUwC1iv3K nsjx44wzU3H6sUOydIoAt9RSxAA7WwvlaZeNwH7FUQ6g3UdyEvZhdhzgWMJOSu/I22YpDQ9E wH9cTk3ccFV5uwAAAAAAAA== --------------ms070206060704050100090907-- --===============0654257767== 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 --===============0654257767==-- From kitten-bounces@lists.ietf.org Fri May 06 12:08:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5Np-0000f1-Ae; Fri, 06 May 2005 12:08:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5No-0000et-IU for kitten@megatron.ietf.org; Fri, 06 May 2005 12:08:56 -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 MAA05082 for ; Fri, 6 May 2005 12:08:53 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU5cJ-0007NF-Vz for kitten@ietf.org; Fri, 06 May 2005 12:23:57 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j46G8hZS023812; Fri, 6 May 2005 16:08:44 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j46G8d8u000453; Fri, 6 May 2005 16:08:43 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050609084310668 ; Fri, 06 May 2005 09:08:43 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:08:40 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:08:39 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 12:08:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 May 2005 12:08:02 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901195E00@pysmsx401.amr.corp.intel.com> Thread-Topic: FW: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 PRF drafts Thread-Index: AcVRskmfQSBpdoVYR62ZGhSCFwwhMwAP+4yg From: "Blumenthal, Uri" To: "Sam Hartman" X-OriginalArrivalTime: 06 May 2005 16:08:37.0863 (UTC) FILETIME=[DCB75F70:01C55255] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: FW: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 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 Blumenthal,> Handbook of Applied Cryptography, by Menezes, van Blumenthal,> Oorschot and Vanstone, CRC Press, ISBN: Blumenthal,> 0-8493-8523-7. 5th printing in 2001. Blumenthal,> Chapter 5 deals with Pseudorandom sequences. Still Blumenthal,> enough math, but with a practical bent, usable by Blumenthal,> somebody who wants to design one. > A pseudo-random sequence isn't really the same thing as a PRF is it? No, a pseudo-random sequence is an OUTPUT of a pseudo-random Generator or a pseudo-random Function, doesn't matter. Note that ANSI standardized PRG (ANSI X9.17), not PRF. PRG takes input S (seed or key). PRF takes inputs S (seed or key) and I (index), which allows direct access to "bits of potentially huge pseudorandom sequence which is not feasible to scan bit-by-bit" (quoting from Goldreich's "Foundations of Cryptography"). PRFs can be constructed from any PRGs (this theorem and its proof are in Goldreich's book). Texts dealing with PRF and PRG would normally end up talking about PR sequences, because that's what determines whether what you've constructed is in fact a PR*. > Or does their definition of sequence include arbitrary indexing which > I guess would be close enough. A PR sequence doesn't have to be indexed. It's a matter of convenience and usability - some applications require it and some don't. > This seems like an informative not normative reference. This comment probably applies to both GGM paper and this book reference. BTW, 'twould probably be good to add Oded Goldreich's book "Foundations of Cryptography". _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 12 19:24:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWN2z-0002pi-EU; Thu, 12 May 2005 19:24:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWN2x-0002pa-Cm for kitten@megatron.ietf.org; Thu, 12 May 2005 19:24:51 -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 TAA19822 for ; Thu, 12 May 2005 19:24: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 1DWNIm-0000us-2R for kitten@ietf.org; Thu, 12 May 2005 19:41:12 -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 j4CNOnjG008892 for ; Thu, 12 May 2005 16:24:49 -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 j4CNOmEN009280 for ; Thu, 12 May 2005 17:24:49 -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 j4CNOmUM025604 for ; Thu, 12 May 2005 18:24:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4CNOmJV025603 for kitten@ietf.org; Thu, 12 May 2005 18:24:48 -0500 (CDT) Date: Thu, 12 May 2005 18:24:48 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050512232448.GB25534@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: 2eba37fe9c77781b0ecb0a74d8c65128 Cc: Subject: New PRF I-Ds (-03s) have been submitted 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 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 13 15:48:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWg9E-00014y-7E; Fri, 13 May 2005 15:48:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWg99-00013V-Gw; Fri, 13 May 2005 15:48:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21731; Fri, 13 May 2005 15:48:28 -0400 (EDT) Message-Id: <200505131948.PAA21731@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 13 May 2005 15:48:28 -0400 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : A PRF API extension for the GSS-API Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-prf-03.txt Pages : 9 Date : 2005-5-13 This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Programming Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that don't or cannot use GSS-API per- message MIC (message integrity check) and wrap tokens for session protection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-gssapi-prf-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-prf-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-13155945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-prf-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-prf-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-13155945.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From kitten-bounces@lists.ietf.org Fri May 13 15:48:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWg9R-0001B2-3t; Fri, 13 May 2005 15:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWg9M-00015w-Hw; Fri, 13 May 2005 15:48:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21780; Fri, 13 May 2005 15:48:42 -0400 (EDT) Message-Id: <200505131948.PAA21780@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 13 May 2005 15:48:42 -0400 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : A PRF for the Kerberos V GSS-API Mechanism Author(s) : N. Williams Filename : draft-ietf-kitten-krb5-gssapi-prf-03.txt Pages : 6 Date : 2005-5-13 This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Programming Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-krb5-gssapi-prf-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-13155953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-krb5-gssapi-prf-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-13155953.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From kitten-bounces@lists.ietf.org Mon May 16 15:40:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlSV-0007Fs-51; Mon, 16 May 2005 15:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlSR-0007EI-4n; Mon, 16 May 2005 15:40:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29987; Mon, 16 May 2005 15:40:52 -0400 (EDT) Message-Id: <200505161940.PAA29987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 16 May 2005 15:40:51 -0400 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-naming-exts-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-naming-exts-00.txt Pages : 20 Date : 2005-6-16 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming and authorization model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-gssapi-naming-exts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-naming-exts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-16152033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-naming-exts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-naming-exts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-16152033.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From kitten-bounces@lists.ietf.org Mon May 16 16:56:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmdw-0003kf-CW; Mon, 16 May 2005 16:56:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmdt-0003js-Qf; Mon, 16 May 2005 16:56:50 -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 QAA19620; Mon, 16 May 2005 16:56:47 -0400 (EDT) Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmuU-0001lr-RB; Mon, 16 May 2005 17:14:00 -0400 Received: from ([90.152.53.181]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.37427570; Mon, 16 May 2005 16:55:55 -0400 Received: from mail pickup service by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC; Mon, 16 May 2005 15:55:55 -0500 Received: from 01al10015010026.ad.bls.com ([90.152.5.102]) by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 May 2005 14:51:52 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by 01al10015010026.ad.bls.com (SAVSMTP 3.1.7.47) with SMTP id M2005051614515229970 for ; Mon, 16 May 2005 14:51:52 -0500 Received: from ([132.151.6.71]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.51092927; Mon, 16 May 2005 15:51:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlSU-0007F0-2r; Mon, 16 May 2005 15:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlSR-0007EI-4n; Mon, 16 May 2005 15:40:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29987; Mon, 16 May 2005 15:40:52 -0400 (EDT) Message-Id: <200505161940.PAA29987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 16 May 2005 15:40:51 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-esp: ESP<-125>=RBL:<-139> RDNS:<0> SHA:<13> UHA:<0> SLS:<0> BAYES:<1> SPF:<0> NigeriaScam Dictionary (TRU7):<0> Obscenities Dictionary (TRU7):<0> BellSouth Spam SS:<0> URL Dictionary (TRU7):<0> Embed HTML Dictionary (TRU7):<0> CAN-SPAM Compliance Dictionary (TRU7):<0> Porn Dictionary (TRU7):<0> Spam Dictionary (TRU7):<0> HTML Dictionary (TRU7):<0> X-OriginalArrivalTime: 16 May 2005 19:51:52.0640 (UTC) FILETIME=[B4C1A400:01C55A50] X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-naming-exts-00.txt X-BeenThere: kitten@lists.ietf.org Reply-To: internet-drafts@ietf.org 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-naming-exts-00.txt Pages : 20 Date : 2005-6-16 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming and authorization model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-gssapi-naming-exts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-naming-exts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-16152033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-naming-exts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-naming-exts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-16152033.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart 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 --NextPart-- From kitten-bounces@lists.ietf.org Wed May 18 12:26:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRNJ-0001fc-3E; Wed, 18 May 2005 12:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRNH-0001ee-Td for kitten@megatron.ietf.org; Wed, 18 May 2005 12:26: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 MAA08540 for ; Wed, 18 May 2005 12:26:20 -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 1DYReF-0008Kv-Sr for kitten@ietf.org; Wed, 18 May 2005 12:43:57 -0400 Received: from [18.18.2.77] (CHRIS-TEST-2.MIT.EDU [18.18.2.77]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4IGQLkP021904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 18 May 2005 12:26:21 -0400 (EDT) Message-ID: <428B58A8.5050800@columbia.edu> Date: Wed, 18 May 2005 11:00:56 -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.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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="===============1587339407==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1587339407== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010407040907020905030809" This is a cryptographically signed message in MIME format. --------------ms010407040907020905030809 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Overall I believe this document is ready for last call. I do have one concern though. In the Security Considerations a technical unit of measurement is used for which I am aware of no agreed upon standard definition, the "handful". I do not feel comfortable with a Security Consideration that recommends a pinch of this and a touch of that. Jeffrey Altman --------------ms010407040907020905030809 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 DxcNMDUwNTE4MTUwMDU2WjAjBgkqhkiG9w0BCQQxFgQUVE8vEtmAPWtdjUdLW2wIlPfpO/Uw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAoJD34Z7W3uQ7GBy8FqIhCrX7VRmQ16c4xrij4Wne dGpbpnUl8k7NaE1YBjQJvz1K6I28PZa1TAgdcW8v+t+tyrDGHYCy7QqfHqkopFgh/8PE3nvK 8eqtowOYvOKYnuXXZEUjlj2OFKdpaHpcGcRpN0MrYkB0yNQa8CZ+wm4Ga01WSCZ3MuqhDcMJ mQ2ib7HVmvUjzWsHZLt2eeUzo/sRvKGzQFxJF/7GJNtASL2AVg3ktEb+7c/wLeA+rV6FCkux /pYpRNeYRsEbhIDdwIzpxv+9GIIdt76qOzPCokB6tjXBAv4Yz9gz3jtupzKu5iVLyiM7T6RV 8JVY7Mljb/y/owAAAAAAAA== --------------ms010407040907020905030809-- --===============1587339407== 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 --===============1587339407==-- From kitten-bounces@lists.ietf.org Wed May 18 12:41:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRbR-00070u-7G; Wed, 18 May 2005 12:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRbP-00070p-VG for kitten@megatron.ietf.org; Wed, 18 May 2005 12:41:00 -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 MAA10641 for ; Wed, 18 May 2005 12:40:56 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYRsO-0000f2-AO for kitten@ietf.org; Wed, 18 May 2005 12:58:33 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa13836; 18 May 2005 12:40 EDT Date: Wed, 18 May 2005 12:40:26 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , kitten@ietf.org Message-ID: <5FC9684E73FC65A679BF2713@sirius.fac.cs.cmu.edu> In-Reply-To: <428B58A8.5050800@columbia.edu> References: <428B58A8.5050800@columbia.edu> Originator-Info: login-token=Mulberry:017q7dalgWUt46+VXrISwN2YUgFJV14lZbIwvPJC4=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Wednesday, May 18, 2005 11:00:56 AM -0400 Jeffrey Altman wrote: > Overall I believe this document is ready for last call. I do have one > concern though. In the Security Considerations a technical unit of > measurement is used for which I am aware of no agreed upon standard > definition, the "handful". I do not feel comfortable with a Security > Consideration that recommends a pinch of this and a touch of that. I see nothing about pinches or touches; only handfuls. I see no problem with using a somewhat vague term in this instance, since the point is not to make a specific recommendation that "more than X uses per context is bad", but rather to suggest that making a few calls per context is OK, but making them continuously across a long connection is not. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 18 17:14:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVsJ-0001kX-SW; Wed, 18 May 2005 17:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVsI-0001kS-UL for kitten@megatron.ietf.org; Wed, 18 May 2005 17:14: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 RAA21176 for ; Wed, 18 May 2005 17:14:35 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYW9E-0000MJ-UP for kitten@ietf.org; Wed, 18 May 2005 17:32:14 -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 j4ILETjO014176 for ; Wed, 18 May 2005 15:14:30 -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 j4ILES06005685 for ; Wed, 18 May 2005 15:14: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 j4ILESPg023627; Wed, 18 May 2005 16:14:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4ILENAA023626; Wed, 18 May 2005 16:14:23 -0500 (CDT) Date: Wed, 18 May 2005 16:14:23 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20050518211423.GD23553@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Jeffrey Altman , kitten@ietf.org References: <428B58A8.5050800@columbia.edu> <5FC9684E73FC65A679BF2713@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FC9684E73FC65A679BF2713@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Wed, May 18, 2005 at 12:40:26PM -0400, Jeffrey Hutzelman wrote: > > > On Wednesday, May 18, 2005 11:00:56 AM -0400 Jeffrey Altman > wrote: > > >Overall I believe this document is ready for last call. I do have one > >concern though. In the Security Considerations a technical unit of > >measurement is used for which I am aware of no agreed upon standard > >definition, the "handful". I do not feel comfortable with a Security > >Consideration that recommends a pinch of this and a touch of that. > > I see nothing about pinches or touches; only handfuls. Thanks for the laughs :) > I see no problem with using a somewhat vague term in this instance, since > the point is not to make a specific recommendation that "more than X uses > per context is bad", but rather to suggest that making a few calls per > context is OK, but making them continuously across a long connection is not. That text does need some cleanup, and the real issue is that the GSS-API can't enforce any limits on the useful lifetime of PRF output used for cryptographic purposes. So, I propose replacing that paragraph with: Care should be taken not to exceed the useful lifetime of GSS_Pseudo_random() output, particularly when used for cryptographic purposes. Specifically, applications should limit use of cryptographic keys derived from GSS_Pseudo_random() output to the original lifetime of the security contexts to which GSS_Pseudo_random() is applied. That seems much more specific -- no handfuls, pinches or touches. Cheers, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 18 17:22:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVzZ-0004DM-N1; Wed, 18 May 2005 17:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVzW-0004D5-U3 for kitten@megatron.ietf.org; Wed, 18 May 2005 17:22:12 -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 RAA21951 for ; Wed, 18 May 2005 17:22:08 -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 1DYWGX-0000eo-K1 for kitten@ietf.org; Wed, 18 May 2005 17:39:46 -0400 Received: from [18.18.5.70] (WEST-NINETYTWO-SEVENTY.MIT.EDU [18.18.5.70]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4ILM8sl014123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 18 May 2005 17:22:08 -0400 (EDT) Message-ID: <428BB2B2.4050502@columbia.edu> Date: Wed, 18 May 2005 17:25:06 -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: <428B58A8.5050800@columbia.edu> <5FC9684E73FC65A679BF2713@sirius.fac.cs.cmu.edu> <20050518211423.GD23553@binky.Central.Sun.COM> In-Reply-To: <20050518211423.GD23553@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: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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="===============0499221955==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0499221955== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090707050206030605040107" This is a cryptographically signed message in MIME format. --------------ms090707050206030605040107 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > > That text does need some cleanup, and the real issue is that the GSS-API > can't enforce any limits on the useful lifetime of PRF output used for > cryptographic purposes. So, I propose replacing that paragraph with: > > Care should be taken not to exceed the useful lifetime of > GSS_Pseudo_random() output, particularly when used for cryptographic > purposes. Specifically, applications should limit use of > cryptographic keys derived from GSS_Pseudo_random() output to the > original lifetime of the security contexts to which > GSS_Pseudo_random() is applied. > > That seems much more specific -- no handfuls, pinches or touches. Nico: I am much happier with the proposed text. Does anyone else have any comments? Jeffrey Altman --------------ms090707050206030605040107 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 DxcNMDUwNTE4MjEyNTA2WjAjBgkqhkiG9w0BCQQxFgQU9wzbRwBQs+csstJhXS2rcX19PWsw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAhMV4MCQR8LgR2+2vF/B2XF6IV8JBbBi3nbZX+kzm GSvQgqfXIIpvVb14qbuYiOd0YpmXkb3OpsgoXESB1cCCDYM83rqKOduCWf7lPOOxCSpFPDsy pFembvBErSTfDHkkrEOq0a2T1Jd9cIzYz5UwGt9OPHzgKGhwGayZUqwhflBc5ldxKAbCslak xm0ZiRHB/rF8qJrbcy0TKpEWNYVbRsVxqSOjng7rMtXXFq3iPWrGFQSjCKhjDKOyj2KYcpAS ZtyA+5+tqyFbrr2hUwxqbSiRZtnqSrzSq1se+XeMAAFQ7M1iREnlW/RMnSGVw1Qmgby+JUIG J5WgpPzMafGGIwAAAAAAAA== --------------ms090707050206030605040107-- --===============0499221955== 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 --===============0499221955==-- From kitten-bounces@lists.ietf.org Thu May 19 12:43:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYo7I-0000AA-3m; Thu, 19 May 2005 12:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYo7G-0000A4-Rb for kitten@megatron.ietf.org; Thu, 19 May 2005 12:43: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 MAA23367 for ; Thu, 19 May 2005 12:43:19 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYoOR-0007U0-L3 for kitten@ietf.org; Thu, 19 May 2005 13:01:08 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa17153; 19 May 2005 12:42 EDT Date: Thu, 19 May 2005 12:42:31 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , kitten@ietf.org Message-ID: <1ACA1CCA2FAF6B4FF000BEE5@sirius.fac.cs.cmu.edu> In-Reply-To: <428BB2B2.4050502@columbia.edu> References: <428B58A8.5050800@columbia.edu> <5FC9684E73FC65A679BF2713@sirius.fac.cs.cmu.edu> <20050518211423.GD23553@binky.Central.Sun.COM> <428BB2B2.4050502@columbia.edu> Originator-Info: login-token=Mulberry:01HmE2xojJqzpqrK5HUd9mNbXTbfGlla+L1mQrVOE=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Wednesday, May 18, 2005 05:25:06 PM -0400 Jeffrey Altman wrote: > Nicolas Williams wrote: >> >> That text does need some cleanup, and the real issue is that the GSS-API >> can't enforce any limits on the useful lifetime of PRF output used for >> cryptographic purposes. So, I propose replacing that paragraph with: >> >> Care should be taken not to exceed the useful lifetime of >> GSS_Pseudo_random() output, particularly when used for cryptographic >> purposes. Specifically, applications should limit use of >> cryptographic keys derived from GSS_Pseudo_random() output to the >> original lifetime of the security contexts to which >> GSS_Pseudo_random() is applied. >> >> That seems much more specific -- no handfuls, pinches or touches. > > Nico: > > I am much happier with the proposed text. Does anyone else have any > comments? I have no problem with adding that text, but it sounds like it addresses a different problem than the paragraph Nico proposes to replace. The existing text appears to be concerned about the amount of data which the PRF can safely be used to generate. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 19 13:59:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpIp-0005Xe-Cx; Thu, 19 May 2005 13:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpIm-0005XE-W3 for kitten@megatron.ietf.org; Thu, 19 May 2005 13:59:21 -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 NAA29983 for ; Thu, 19 May 2005 13:59:19 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpZy-0001Bv-Du for kitten@ietf.org; Thu, 19 May 2005 14:17:07 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4JHx7bm006277; Thu, 19 May 2005 17:59:07 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4JHx0k2026009; Thu, 19 May 2005 17:59:07 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005051910590612429 ; Thu, 19 May 2005 10:59:06 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 10:59:06 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 10:59:05 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 13:59:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2005 13:58:18 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> Thread-Topic: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt Thread-Index: AcVckmlX96h3fF7RSQqjFu5Vi46/QQACFl7Q From: "Blumenthal, Uri" To: "Jeffrey Hutzelman" , "Jeffrey Altman" , X-OriginalArrivalTime: 19 May 2005 17:59:04.0327 (UTC) FILETIME=[71C44970:01C55C9C] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org >>> That text does need some cleanup, and the real issue is that the GSS-API >>> can't enforce any limits on the useful lifetime of PRF output used for >>> cryptographic purposes. So, I propose replacing that paragraph with: >>> >>> Care should be taken not to exceed the useful lifetime of >>> GSS_Pseudo_random() output, particularly when used for cryptographic >>> purposes. Specifically, applications should limit use of >>> cryptographic keys derived from GSS_Pseudo_random() output to the >>> original lifetime of the security contexts to which >>> GSS_Pseudo_random() is applied. >>> >>> That seems much more specific -- no handfuls, pinches or touches. >> >> I am much happier with the proposed text. Does anyone else have any >> comments? > >I have no problem with adding that text, but it sounds like it addresses a=20 >different problem than the paragraph Nico proposes to replace. The=20 >existing text appears to be concerned about the amount of data which the=20 >PRF can safely be used to generate. I like the above text (let it stay), but agree with Jeff - we need something else in addition. Could say something along the lines of: Care should be taken not to exceed the amount of data that PRF can safely generate. This amount naturally depends on the mechanisms used. :-) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 13:24:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGf7-0007Qy-5R; Mon, 23 May 2005 13:24:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGf3-0007Qt-JR for kitten@megatron.ietf.org; Mon, 23 May 2005 13:24: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 NAA16189 for ; Mon, 23 May 2005 13:24:12 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGx1-0004j2-Jb for kitten@ietf.org; Mon, 23 May 2005 13:42: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 j4NHOA0R005959 for ; Mon, 23 May 2005 11:24:10 -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 j4NHO9ER004280 for ; Mon, 23 May 2005 11:24:10 -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 j4NHO9Ym027542; Mon, 23 May 2005 12:24:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NHO7OJ027541; Mon, 23 May 2005 12:24:07 -0500 (CDT) Date: Mon, 23 May 2005 12:24:07 -0500 From: Nicolas Williams To: "Blumenthal, Uri" Message-ID: <20050523172407.GB27516@binky.Central.Sun.COM> Mail-Followup-To: "Blumenthal, Uri" , Jeffrey Hutzelman , Jeffrey Altman , kitten@ietf.org References: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Thu, May 19, 2005 at 01:58:18PM -0400, Blumenthal, Uri wrote: > >>> That text does need some cleanup, and the real issue is that the > GSS-API > >>> can't enforce any limits on the useful lifetime of PRF output used > for > >>> cryptographic purposes. So, I propose replacing that paragraph > with: > >>> > >>> Care should be taken not to exceed the useful lifetime of > >>> GSS_Pseudo_random() output, particularly when used for > cryptographic > >>> purposes. Specifically, applications should limit use of > >>> cryptographic keys derived from GSS_Pseudo_random() output to the > >>> original lifetime of the security contexts to which > >>> GSS_Pseudo_random() is applied. > >>> > >>> That seems much more specific -- no handfuls, pinches or touches. > >> > >> I am much happier with the proposed text. Does anyone else have any > >> comments? > > > >I have no problem with adding that text, but it sounds like it > addresses a > >different problem than the paragraph Nico proposes to replace. The > >existing text appears to be concerned about the amount of data which > the > >PRF can safely be used to generate. > > I like the above text (let it stay), but agree with Jeff - we need > something > else in addition. Could say something along the lines of: > > Care should be taken not to exceed the amount of data that PRF > can > safely generate. > > This amount naturally depends on the mechanisms used. :-) This is a consideration for mechanisms as much as for applications. Mechanisms should not allow the PRF to output more than is safe. The mechanism-specific aspect of it is already handled in section 2. Applications should not overuse the PRF. So, how about: Applications should not overuse the PRF. What constitutes overuse of the PRF may vary by mechanism and other details (such as what key strength has been negotiated by the mechanisms), therefore we cannot give precise advice, but, to be certain, limiting calls to GSS_Pseudo_random() to a very small number, such as one, or two calls, should suffice. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 14:15:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHSH-0005TB-Ls; Mon, 23 May 2005 14:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHSE-0005SG-50 for kitten@megatron.ietf.org; Mon, 23 May 2005 14:15: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 OAA22446 for ; Mon, 23 May 2005 14:15:04 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHkD-0006ru-15 for kitten@ietf.org; Mon, 23 May 2005 14:33:41 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4NIEl6l022015; Mon, 23 May 2005 18:14:47 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4NIEIZS002877; Mon, 23 May 2005 18:14:47 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052311144605081 ; Mon, 23 May 2005 11:14:46 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 11:14:46 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 11:14:46 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 14:14:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 14:13:55 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012EB35C@pysmsx401.amr.corp.intel.com> Thread-Topic: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt Thread-Index: AcVfvD9TjrqnaTNrTuWbNUcjBCVF5wABrLuA From: "Blumenthal, Uri" To: "Nicolas Williams" X-OriginalArrivalTime: 23 May 2005 18:14:44.0779 (UTC) FILETIME=[4BF8DFB0:01C55FC3] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Sounds fine. Do we want to elaborate, like explain that since PRF is a PSEUDO-random function, it does have a [usually rather long] cycle after which the values start repeating, and we're trying to avoid it? -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Monday, May 23, 2005 1:24 PM To: Blumenthal, Uri Cc: Jeffrey Hutzelman; Jeffrey Altman; kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt On Thu, May 19, 2005 at 01:58:18PM -0400, Blumenthal, Uri wrote: > >>> That text does need some cleanup, and the real issue is that the > GSS-API > >>> can't enforce any limits on the useful lifetime of PRF output used > for > >>> cryptographic purposes. So, I propose replacing that paragraph > with: > >>> > >>> Care should be taken not to exceed the useful lifetime of > >>> GSS_Pseudo_random() output, particularly when used for > cryptographic > >>> purposes. Specifically, applications should limit use of > >>> cryptographic keys derived from GSS_Pseudo_random() output to the > >>> original lifetime of the security contexts to which > >>> GSS_Pseudo_random() is applied. > >>> > >>> That seems much more specific -- no handfuls, pinches or touches. > >> > >> I am much happier with the proposed text. Does anyone else have any > >> comments? > > > >I have no problem with adding that text, but it sounds like it > addresses a=20 > >different problem than the paragraph Nico proposes to replace. The=20 > >existing text appears to be concerned about the amount of data which > the=20 > >PRF can safely be used to generate. >=20 > I like the above text (let it stay), but agree with Jeff - we need > something > else in addition. Could say something along the lines of: >=20 > Care should be taken not to exceed the amount of data that PRF > can > safely generate. >=20 > This amount naturally depends on the mechanisms used. :-) This is a consideration for mechanisms as much as for applications. Mechanisms should not allow the PRF to output more than is safe. The mechanism-specific aspect of it is already handled in section 2. Applications should not overuse the PRF. So, how about: Applications should not overuse the PRF. What constitutes overuse of the PRF may vary by mechanism and other details (such as what key strength has been negotiated by the mechanisms), therefore we cannot give precise advice, but, to be certain, limiting calls to GSS_Pseudo_random() to a very small number, such as one, or two calls, should suffice. Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 14:28:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHeu-0007RG-7E; Mon, 23 May 2005 14:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHes-0007RB-QN for kitten@megatron.ietf.org; Mon, 23 May 2005 14:28: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 OAA24882 for ; Mon, 23 May 2005 14:28:09 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHwt-0007VA-Lu for kitten@ietf.org; Mon, 23 May 2005 14:46:48 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j4NIS7c6024091; Mon, 23 May 2005 14:28:07 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j4NIRtlW017937 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 23 May 2005 14:28:00 -0400 (EDT) In-Reply-To: <20050523172407.GB27516@binky.Central.Sun.COM> References: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> <20050523172407.GB27516@binky.Central.Sun.COM> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8b86b17bc57df644c97b4795017c1531@mit.edu> From: Ken Raeburn Date: Mon, 23 May 2005 14:27:52 -0400 To: Nicolas Williams X-Mailer: Apple Mail (2.622) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On May 23, 2005, at 13:24, Nicolas Williams wrote: > So, how about: > > Applications should not overuse the PRF. What constitutes overuse > of > the PRF may vary by mechanism and other details (such as what key > strength has been negotiated by the mechanisms), therefore we cannot > give precise advice, but, to be certain, limiting calls to > GSS_Pseudo_random() to a very small number, such as one, or two > calls, should suffice. One or two calls? That sounds really weak. I would hope one or two dozen -- or one or two thousand -- should be possible for even the weakest cryptosystem without compromising security. Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 14:39:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHpj-0000En-23; Mon, 23 May 2005 14:39:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHpi-0000Ei-2q for kitten@megatron.ietf.org; Mon, 23 May 2005 14:39:22 -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 OAA26094 for ; Mon, 23 May 2005 14:39:20 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaI7i-0007y6-PJ for kitten@ietf.org; Mon, 23 May 2005 14:58:00 -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 j4NIdJGJ007638 for ; Mon, 23 May 2005 11:39:19 -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 j4NIdI02019063 for ; Mon, 23 May 2005 12:39:18 -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 j4NIdIYv027574; Mon, 23 May 2005 13:39:18 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NIdIuR027573; Mon, 23 May 2005 13:39:18 -0500 (CDT) Date: Mon, 23 May 2005 13:39:18 -0500 From: Nicolas Williams To: Ken Raeburn Message-ID: <20050523183918.GD27516@binky.Central.Sun.COM> Mail-Followup-To: Ken Raeburn , kitten@ietf.org References: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> <20050523172407.GB27516@binky.Central.Sun.COM> <8b86b17bc57df644c97b4795017c1531@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b86b17bc57df644c97b4795017c1531@mit.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, May 23, 2005 at 02:27:52PM -0400, Ken Raeburn wrote: > On May 23, 2005, at 13:24, Nicolas Williams wrote: > >So, how about: > > > > Applications should not overuse the PRF. What constitutes overuse > >of > > the PRF may vary by mechanism and other details (such as what key > > strength has been negotiated by the mechanisms), therefore we cannot > > give precise advice, but, to be certain, limiting calls to > > GSS_Pseudo_random() to a very small number, such as one, or two > > calls, should suffice. > > One or two calls? That sounds really weak. I would hope one or two > dozen -- or one or two thousand -- should be possible for even the > weakest cryptosystem without compromising security. But we can't really say, can we -- the mechs should, and then, for the krb5 mech the recommendation will depend on enctypes used, which the application doesn't know about and has not control over. Perhaps the text shouldn't say "one or two" or any number. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 14:46:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHwo-0001E6-7W; Mon, 23 May 2005 14:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHwm-0001E1-Rk for kitten@megatron.ietf.org; Mon, 23 May 2005 14:46: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 OAA26610 for ; Mon, 23 May 2005 14:46:39 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIEn-0008EL-OY for kitten@ietf.org; Mon, 23 May 2005 15:05:19 -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 j4NIkc0R022778 for ; Mon, 23 May 2005 12:46:38 -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 j4NIkb06023280 for ; Mon, 23 May 2005 12:46:38 -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 j4NIkbZG027581; Mon, 23 May 2005 13:46:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NIkbOp027580; Mon, 23 May 2005 13:46:37 -0500 (CDT) Date: Mon, 23 May 2005 13:46:37 -0500 From: Nicolas Williams To: "Blumenthal, Uri" Message-ID: <20050523184637.GE27516@binky.Central.Sun.COM> Mail-Followup-To: "Blumenthal, Uri" , Jeffrey Hutzelman , Jeffrey Altman , kitten@ietf.org References: <3DEC199BD7489643817ECA151F7C5929012EB35C@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEC199BD7489643817ECA151F7C5929012EB35C@pysmsx401.amr.corp.intel.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, May 23, 2005 at 02:13:55PM -0400, Blumenthal, Uri wrote: > Sounds fine. Do we want to elaborate, like explain that since PRF is a > PSEUDO-random function, it does have a [usually rather long] cycle after > which the values start repeating, and we're trying to avoid it? I don't care -- as long as we get done with this pair of I-Ds :) Also, I'm not sure that the period is the issue here -- for each call the periodicity issue is handled already in section 2. The issue is that at some point a PRF can start leaking data. I imagine GSS_Pseudo_random() being used to make an XOR encryption pad, for example -- after a while but well before the underlying PRG/PRF's period is reached we may have other weaknesses in it leak information through the pad, parts of which might be recoverable by attackers that know any of the plaintext being encrypted. IANAC, but this seems difficult to explain, particularly in the generic function definition, rather than in the mechanims'. So I think vague text is the best I can do here, though I welcome suggestions -- I'm sure others can do better than :) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 15:28:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIbT-0000YL-R7; Mon, 23 May 2005 15:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIbS-0000Y7-PU for kitten@megatron.ietf.org; Mon, 23 May 2005 15:28:42 -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 PAA01762 for ; Mon, 23 May 2005 15:28:41 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaItU-0001II-3b for kitten@ietf.org; Mon, 23 May 2005 15:47:21 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j4NJSbc6017736; Mon, 23 May 2005 15:28:37 -0400 (EDT) Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j4NJSQlW011394 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 23 May 2005 15:28:30 -0400 (EDT) In-Reply-To: <20050523183918.GD27516@binky.Central.Sun.COM> References: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> <20050523172407.GB27516@binky.Central.Sun.COM> <8b86b17bc57df644c97b4795017c1531@mit.edu> <20050523183918.GD27516@binky.Central.Sun.COM> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8be468c6263ddef7b2c78d11f57f9b96@mit.edu> From: Ken Raeburn Date: Mon, 23 May 2005 15:28:22 -0400 To: Nicolas Williams X-Mailer: Apple Mail (2.622) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On May 23, 2005, at 14:39, Nicolas Williams wrote: >> One or two calls? That sounds really weak. I would hope one or two >> dozen -- or one or two thousand -- should be possible for even the >> weakest cryptosystem without compromising security. > > But we can't really say, can we -- the mechs should, and then, for the > krb5 mech the recommendation will depend on enctypes used, which the > application doesn't know about and has not control over. > > Perhaps the text shouldn't say "one or two" or any number. In the end, it does all come down to the security of the individual cryptosystem specification. But I think one that can't handle a few thousand PRF calls (of small blocks, not unbounded size) is either horribly weak, or has a PRF function which is exceedingly weak compared to the rest of the cryptosystem. (But since we consider the PRF a part of the cryptosystem, it could be argued that the latter is just a special case of the former. And with a horribly weak cryptosystem, you're just doomed...) ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 15:36:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIis-0001fN-R3; Mon, 23 May 2005 15:36:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIir-0001fI-Cj for kitten@megatron.ietf.org; Mon, 23 May 2005 15:36:21 -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 PAA02284 for ; Mon, 23 May 2005 15:36:19 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaJ0s-0001W3-EF for kitten@ietf.org; Mon, 23 May 2005 15:55:00 -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 j4NJaIjO013055 for ; Mon, 23 May 2005 13:36:18 -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 j4NJaHEN010395 for ; Mon, 23 May 2005 13:36: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 j4NJaHMl027690; Mon, 23 May 2005 14:36:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NJaHcp027689; Mon, 23 May 2005 14:36:17 -0500 (CDT) Date: Mon, 23 May 2005 14:36:17 -0500 From: Nicolas Williams To: Ken Raeburn Message-ID: <20050523193616.GH27516@binky.Central.Sun.COM> Mail-Followup-To: Ken Raeburn , kitten@ietf.org References: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> <20050523172407.GB27516@binky.Central.Sun.COM> <8b86b17bc57df644c97b4795017c1531@mit.edu> <20050523183918.GD27516@binky.Central.Sun.COM> <8be468c6263ddef7b2c78d11f57f9b96@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8be468c6263ddef7b2c78d11f57f9b96@mit.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, May 23, 2005 at 03:28:22PM -0400, Ken Raeburn wrote: > On May 23, 2005, at 14:39, Nicolas Williams wrote: > >>One or two calls? That sounds really weak. I would hope one or two > >>dozen -- or one or two thousand -- should be possible for even the > >>weakest cryptosystem without compromising security. > > > >But we can't really say, can we -- the mechs should, and then, for the > >krb5 mech the recommendation will depend on enctypes used, which the > >application doesn't know about and has not control over. > > > >Perhaps the text shouldn't say "one or two" or any number. > > In the end, it does all come down to the security of the individual > cryptosystem specification. But I think one that can't handle a few > thousand PRF calls (of small blocks, not unbounded size) is either > horribly weak, or has a PRF function which is exceedingly weak compared > to the rest of the cryptosystem. (But since we consider the PRF a part > of the cryptosystem, it could be argued that the latter is just a > special case of the former. And with a horribly weak cryptosystem, > you're just doomed...) Ok, so shall I s/one, or two/one, or two thousand/? :) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 17:12:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKDr-0002mu-OP; Mon, 23 May 2005 17:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKDp-0002mj-SL for kitten@megatron.ietf.org; Mon, 23 May 2005 17:12:25 -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 RAA21481 for ; Mon, 23 May 2005 17:12:23 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKVs-000172-1S for kitten@ietf.org; Mon, 23 May 2005 17:31:05 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4NLCF6l025232; Mon, 23 May 2005 21:12:15 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4NLCFZ4012817; Mon, 23 May 2005 21:12:15 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052314121427231 ; Mon, 23 May 2005 14:12:14 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 14:11:59 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 14:11:59 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 17:11:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 17:11:01 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012EB583@pysmsx401.amr.corp.intel.com> Thread-Topic: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt Thread-Index: AcVfzu6aJkDbXy8eT9yyJgXJa2BsWwAC7HpQ From: "Blumenthal, Uri" To: "Nicolas Williams" , "Ken Raeburn" X-OriginalArrivalTime: 23 May 2005 21:11:50.0176 (UTC) FILETIME=[0933CA00:01C55FDC] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org IMHO if a PRF can handle only a dozen or so calls - it's so cryptographically weak that it doesn't belong anyway. It should suffice for us to mention the reason why the user may want to limit the amount of PRF output. I don't think a good PRF would leak any material except for when its period is reached (a good PRF won't have short cycles either). So we can drop giving concrete numbers (after all, if we don't know the underlying crypto - we can't tell how many bits the resulting PRF can safely output), but just say that because of , and the user should take care and limit the number of PRF invocations/output bits. Does this make sense? -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Nicolas Williams Sent: Monday, May 23, 2005 3:36 PM To: Ken Raeburn Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt On Mon, May 23, 2005 at 03:28:22PM -0400, Ken Raeburn wrote: > On May 23, 2005, at 14:39, Nicolas Williams wrote: > >>One or two calls? That sounds really weak. I would hope one or two > >>dozen -- or one or two thousand -- should be possible for even the > >>weakest cryptosystem without compromising security. > > > >But we can't really say, can we -- the mechs should, and then, for the > >krb5 mech the recommendation will depend on enctypes used, which the > >application doesn't know about and has not control over. > > > >Perhaps the text shouldn't say "one or two" or any number. >=20 > In the end, it does all come down to the security of the individual=20 > cryptosystem specification. But I think one that can't handle a few=20 > thousand PRF calls (of small blocks, not unbounded size) is either=20 > horribly weak, or has a PRF function which is exceedingly weak compared=20 > to the rest of the cryptosystem. (But since we consider the PRF a part=20 > of the cryptosystem, it could be argued that the latter is just a=20 > special case of the former. And with a horribly weak cryptosystem,=20 > you're just doomed...) Ok, so shall I s/one, or two/one, or two thousand/? :) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org 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 Mon May 23 17:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKHk-0003Ov-IZ; Mon, 23 May 2005 17:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKHh-0003Om-SS for kitten@megatron.ietf.org; Mon, 23 May 2005 17:16:27 -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 RAA21812 for ; Mon, 23 May 2005 17:16:23 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKZk-0001Ie-1k for kitten@ietf.org; Mon, 23 May 2005 17:35:05 -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 j4NLGN0R000673 for ; Mon, 23 May 2005 15:16:23 -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 j4NLGMEN006625 for ; Mon, 23 May 2005 15:16:23 -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 j4NLG9I2027871; Mon, 23 May 2005 16:16:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NLG7Y8027870; Mon, 23 May 2005 16:16:07 -0500 (CDT) Date: Mon, 23 May 2005 16:16:07 -0500 From: Nicolas Williams To: "Blumenthal, Uri" Message-ID: <20050523211607.GX27516@binky.Central.Sun.COM> Mail-Followup-To: "Blumenthal, Uri" , Ken Raeburn , kitten@ietf.org References: <3DEC199BD7489643817ECA151F7C5929012EB583@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEC199BD7489643817ECA151F7C5929012EB583@pysmsx401.amr.corp.intel.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, Ken Raeburn Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, May 23, 2005 at 05:11:01PM -0400, Blumenthal, Uri wrote: > IMHO if a PRF can handle only a dozen or so calls - it's so > cryptographically weak that it doesn't belong anyway. It should suffice > for us to mention the reason why the user may want to limit the amount > of PRF output. > > I don't think a good PRF would leak any material except for when its > period is reached (a good PRF won't have short cycles either). > > So we can drop giving concrete numbers (after all, if we don't know the > underlying crypto - we can't tell how many bits the resulting PRF can > safely output), but just say that because of , and the user > should take care and limit the number of PRF invocations/output bits. > > Does this make sense? Ok. Text please? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 17:19:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKL2-0003tT-5B; Mon, 23 May 2005 17:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKL0-0003t8-0X for kitten@megatron.ietf.org; Mon, 23 May 2005 17:19:50 -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 RAA22275 for ; Mon, 23 May 2005 17:19:47 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKd3-0001WL-1K for kitten@ietf.org; Mon, 23 May 2005 17:38:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 May 2005 14:19:39 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4NLJUlw018604; Mon, 23 May 2005 14:19:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 14:23:30 -0700 Message-ID: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt Thread-Index: AcVfz3yL68dTgcH3RYmnwcmRpG7ZtAADQ/ng From: "Salowey, Joe" To: "Nicolas Williams" , "Ken Raeburn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org It seems that this text and discussion really belongs in draft-ietf-kitten-gssapi-prf since the concerns are not Kerberos mechanism specific. =20 =20 Joe > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Monday, May 23, 2005 12:36 PM > To: Ken Raeburn > Cc: kitten@ietf.org > Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt >=20 > On Mon, May 23, 2005 at 03:28:22PM -0400, Ken Raeburn wrote: > > On May 23, 2005, at 14:39, Nicolas Williams wrote: > > >>One or two calls? That sounds really weak. I would hope=20 > one or two=20 > > >>dozen -- or one or two thousand -- should be possible for=20 > even the=20 > > >>weakest cryptosystem without compromising security. > > > > > >But we can't really say, can we -- the mechs should, and then, for=20 > > >the > > >krb5 mech the recommendation will depend on enctypes used,=20 > which the=20 > > >application doesn't know about and has not control over. > > > > > >Perhaps the text shouldn't say "one or two" or any number. > >=20 > > In the end, it does all come down to the security of the individual=20 > > cryptosystem specification. But I think one that can't=20 > handle a few=20 > > thousand PRF calls (of small blocks, not unbounded size) is either=20 > > horribly weak, or has a PRF function which is exceedingly weak=20 > > compared to the rest of the cryptosystem. (But since we=20 > consider the=20 > > PRF a part of the cryptosystem, it could be argued that the=20 > latter is=20 > > just a special case of the former. And with a horribly weak=20 > > cryptosystem, you're just doomed...) >=20 > Ok, so shall I s/one, or two/one, or two thousand/? :) >=20 > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten >=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 17:23:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKP0-00050W-Dc; Mon, 23 May 2005 17:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKOy-00050R-U4 for kitten@megatron.ietf.org; Mon, 23 May 2005 17:23:56 -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 RAA23134 for ; Mon, 23 May 2005 17:23:54 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKh2-0001tO-58 for kitten@ietf.org; Mon, 23 May 2005 17:42:36 -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 j4NLNtGJ014805 for ; Mon, 23 May 2005 14:23:55 -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 j4NLNsEP011268 for ; Mon, 23 May 2005 15:23:54 -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 j4NLNrPx027906; Mon, 23 May 2005 16:23:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NLNrG9027905; Mon, 23 May 2005 16:23:53 -0500 (CDT) Date: Mon, 23 May 2005 16:23:53 -0500 From: Nicolas Williams To: "Salowey, Joe" Message-ID: <20050523212353.GB27890@binky.Central.Sun.COM> Mail-Followup-To: "Salowey, Joe" , Ken Raeburn , kitten@ietf.org References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: kitten@ietf.org, Ken Raeburn Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, May 23, 2005 at 02:23:30PM -0700, Salowey, Joe wrote: > It seems that this text and discussion really belongs in > draft-ietf-kitten-gssapi-prf since the concerns are not Kerberos > mechanism specific. That is the I-D we're actually discussing. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 17:43:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKhl-0005VR-AN; Mon, 23 May 2005 17:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKhj-0005VA-8J for kitten@megatron.ietf.org; Mon, 23 May 2005 17:43: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 RAA28231 for ; Mon, 23 May 2005 17:43:16 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DaKzl-00040G-Mk for kitten@ietf.org; Mon, 23 May 2005 18:01:59 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa11371; 23 May 2005 17:42 EDT Date: Mon, 23 May 2005 17:42:45 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , "Salowey, Joe" Message-ID: <73536362073536C9CB12738E@sirius.fac.cs.cmu.edu> In-Reply-To: <20050523212353.GB27890@binky.Central.Sun.COM> References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha. cisco.com> <20050523212353.GB27890@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01cnMXeNzbjOy+vo/5pfFH5wnlTqP5p5Df6EXdqPM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Ken Raeburn Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Monday, May 23, 2005 04:23:53 PM -0500 Nicolas Williams wrote: > On Mon, May 23, 2005 at 02:23:30PM -0700, Salowey, Joe wrote: >> It seems that this text and discussion really belongs in >> draft-ietf-kitten-gssapi-prf since the concerns are not Kerberos >> mechanism specific. > > That is the I-D we're actually discussing. Yeah, can't you tell from the message subjects? :-) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 18:13:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLAf-0004uH-DH; Mon, 23 May 2005 18:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLAd-0004uC-Ip for kitten@megatron.ietf.org; Mon, 23 May 2005 18:13: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 SAA03649 for ; Mon, 23 May 2005 18:13:08 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLSf-0005bX-TD for kitten@ietf.org; Mon, 23 May 2005 18:31:51 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4NMD0YE019052; Mon, 23 May 2005 22:13:00 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4NMCtvc016308; Mon, 23 May 2005 22:13:00 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052315125930230 ; Mon, 23 May 2005 15:13:00 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:13:00 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:12:59 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 18:12:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 18:11:56 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929012EB5EC@pysmsx401.amr.corp.intel.com> Thread-Topic: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt Thread-Index: AcVf3K5H1kc44RcbQVOD44Ar0dFSTQABv1Yg From: "Blumenthal, Uri" To: "Nicolas Williams" X-OriginalArrivalTime: 23 May 2005 22:12:45.0447 (UTC) FILETIME=[8BE9E170:01C55FE4] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Ken Raeburn Subject: RE: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Darn... You start giving advices, and now they demand the actual text from you! Next you know they'll ask for an implementation! :-) How about: Pseudorandom functions by their nature are capable of producing only limited amount of cryptographically secure output. The exact amount of output that one can safely use, unfortunately varies from one PRF to another (which prevents us from recommending specific numbers). Because of this, we recommend that unless you really know what you are doing (i.e. you are a cryptographer and are qualified to pass judgement on cryptographic functions in areas of period, presence of short cycles, etc) - you limit the amount of the PRF output to the necessary minimum.=20 Don't forget to edit my English! :-) -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Monday, May 23, 2005 5:16 PM To: Blumenthal, Uri Cc: Ken Raeburn; kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt On Mon, May 23, 2005 at 05:11:01PM -0400, Blumenthal, Uri wrote: > IMHO if a PRF can handle only a dozen or so calls - it's so > cryptographically weak that it doesn't belong anyway. It should suffice > for us to mention the reason why the user may want to limit the amount > of PRF output. >=20 > I don't think a good PRF would leak any material except for when its > period is reached (a good PRF won't have short cycles either). >=20 > So we can drop giving concrete numbers (after all, if we don't know the > underlying crypto - we can't tell how many bits the resulting PRF can > safely output), but just say that because of , and the user > should take care and limit the number of PRF invocations/output bits. >=20 > Does this make sense? Ok. Text please? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 18:20:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLHY-00062Z-3j; Mon, 23 May 2005 18:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLHV-00062R-Ni for kitten@megatron.ietf.org; Mon, 23 May 2005 18:20:17 -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 SAA04594 for ; Mon, 23 May 2005 18:20:15 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DaLZW-0005xH-Kn for kitten@ietf.org; Mon, 23 May 2005 18:38:57 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa11401; 23 May 2005 18:20 EDT Date: Mon, 23 May 2005 18:20:04 -0400 From: Jeffrey Hutzelman To: "Blumenthal, Uri" , Nicolas Williams Message-ID: In-Reply-To: <3DEC199BD7489643817ECA151F7C5929012EB5EC@pysmsx401.amr.corp.intel.com> References: <3DEC199BD7489643817ECA151F7C5929012EB5EC@pysmsx401.amr.corp.int el.com> Originator-Info: login-token=Mulberry:01yQS6MzNsL6cVTzK0/ILqomB28V5QODM2eeiY/4Q=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Ken Raeburn Subject: RE: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Monday, May 23, 2005 06:11:56 PM -0400 "Blumenthal, Uri" wrote: > Darn... You start giving advices, and now they demand the actual text > from you! Next you know they'll ask for an implementation! :-) > > How about: > > Pseudorandom functions by their nature are capable of producing only > limited amount of cryptographically secure output. The exact amount of > output that one can safely use, unfortunately varies from one PRF to > another (which prevents us from recommending specific numbers). Because > of this, we recommend that unless you really know what you are doing > (i.e. you are a cryptographer and are qualified to pass judgement on > cryptographic functions in areas of period, presence of short cycles, > etc) - you limit the amount of the PRF output to the necessary minimum. This is pretty good. s/limited amount/limited amounts/ s/ - /, / and maybe "limit the amount of PRF output used" ? -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 18:24:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLLp-0006cN-Ln; Mon, 23 May 2005 18:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLLn-0006cI-Mq for kitten@megatron.ietf.org; Mon, 23 May 2005 18:24: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 SAA04999 for ; Mon, 23 May 2005 18:24:39 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLdo-00065k-8f for kitten@ietf.org; Mon, 23 May 2005 18:43:21 -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 j4NMOcjO028080 for ; Mon, 23 May 2005 16:24:38 -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 j4NMOcEN013270 for ; Mon, 23 May 2005 16:24:38 -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 j4NMOcXa027990; Mon, 23 May 2005 17:24:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NMOcTx027989; Mon, 23 May 2005 17:24:38 -0500 (CDT) Date: Mon, 23 May 2005 17:24:38 -0500 From: Nicolas Williams To: "Blumenthal, Uri" Message-ID: <20050523222438.GC27936@binky.Central.Sun.COM> Mail-Followup-To: "Blumenthal, Uri" , Ken Raeburn , kitten@ietf.org References: <3DEC199BD7489643817ECA151F7C5929012EB5EC@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEC199BD7489643817ECA151F7C5929012EB5EC@pysmsx401.amr.corp.intel.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, Ken Raeburn Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, May 23, 2005 at 06:11:56PM -0400, Blumenthal, Uri wrote: > Darn... You start giving advices, and now they demand the actual text > from you! Next you know they'll ask for an implementation! :-) Text will do, thanks :) > How about: > > Pseudorandom functions by their nature are capable of producing only > limited amount of cryptographically secure output. The exact amount of > output that one can safely use, unfortunately varies from one PRF to > another (which prevents us from recommending specific numbers). Because > of this, we recommend that unless you really know what you are doing > (i.e. you are a cryptographer and are qualified to pass judgement on > cryptographic functions in areas of period, presence of short cycles, > etc) - you limit the amount of the PRF output to the necessary minimum. > > Don't forget to edit my English! :-) Ok, edited: Pseudo-random functions, by their very nature, are capable of producing only limited amounts of cryptographically secure output. The exact amount of output that one can safely use will vary by mechanism, therefore we cannot recommend specific limits on applications' uses of GSS_Pseudo_random(). Because of this we recommend that applications that are not mechanism-specific should limit consumption of GSS_Pseudo_random() output to the minimum they may need. To which I'd add: It is expected that callers of GSS_Pseudo_random() will use its output to key other cryptosystems; for these applications the minimum GSS_Pseudo_random() output needed by such applications can be expected to be well within the margin of safety of GSS_Pseudo_random() output. Are we happy? :) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 18:44:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLeY-0001Y8-0N; Mon, 23 May 2005 18:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLeW-0001Y2-SI for kitten@megatron.ietf.org; Mon, 23 May 2005 18:44:04 -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 SAA07718 for ; Mon, 23 May 2005 18:44:02 -0400 (EDT) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLwZ-0007B1-NF for kitten@ietf.org; Mon, 23 May 2005 19:02:45 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA22709; Tue, 24 May 2005 00:43:38 +0200 (MESZ) From: Martin Rex Message-Id: <200505232243.AAA00980@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 24 May 2005 00:43:37 +0200 (MET DST) In-Reply-To: <20050523222438.GC27936@binky.Central.Sun.COM> from "Nicolas Williams" at May 23, 5 05:24:38 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, raeburn@MIT.EDU Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org As with a similar discussion on krb-ietf list how a KDC cert should be verified in PKINIT, we should not ignore the fact that the affected spec (here) is going to be normative for both, the gssapi mechanism implementor and the application gssapi caller, and those two will have an entirely different background and needs. So I would suggest to actually quantify (a) what the mechanism implementor must provide as a minimum to be at all useful (b) what the application caller can rely on to be safely available. I think that a number in the range of 1000-2000 should be good. I would indicate to the gssapi implementor that a secure PRF is necessary, and it would indicate to the application caller that this function is not designed to produce a Stream-cipher like pseudo random pad which it can (ab)use to XOR large piles of application data. We should add a reference to the document draft-eastlake-randomness2-10.txt that is sitting on the Editor's queue: Date: Mon, 07 Feb 2005 17:31:14 -0500 Subject: Protocol Action: 'Randomness Requirements for Security' to BCP Sender: ietf-announce-bounces@ietf.org The IESG has approved the following document: - 'Randomness Requirements for Security ' as a BCP This document contains lots of useful information about cryptographic randomness. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 19:03:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLx8-0002Ix-MD; Mon, 23 May 2005 19:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLx6-0002Ir-SP for kitten@megatron.ietf.org; Mon, 23 May 2005 19:03:17 -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 TAA11642 for ; Mon, 23 May 2005 19:03:14 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaMF9-0000NA-PS for kitten@ietf.org; Mon, 23 May 2005 19:21:57 -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 j4NN3DME020470 for ; Mon, 23 May 2005 16:03:13 -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 j4NN3CEN002059 for ; Mon, 23 May 2005 17:03: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 j4NN3CCM028042; Mon, 23 May 2005 18:03:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4NN3C6j028041; Mon, 23 May 2005 18:03:12 -0500 (CDT) Date: Mon, 23 May 2005 18:03:12 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20050523230311.GE27936@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , uri.blumenthal@intel.com, kitten@ietf.org, raeburn@MIT.EDU References: <20050523222438.GC27936@binky.Central.Sun.COM> <200505232243.AAA00980@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505232243.AAA00980@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org, raeburn@MIT.EDU Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Tue, May 24, 2005 at 12:43:37AM +0200, Martin Rex wrote: > As with a similar discussion on krb-ietf list how a KDC cert should > be verified in PKINIT, we should not ignore the fact that the affected > spec (here) is going to be normative for both, the gssapi mechanism > implementor and the application gssapi caller, and those two > will have an entirely different background and needs. > > So I would suggest to actually quantify > (a) what the mechanism implementor must provide as a minimum > to be at all useful That's already there, in section 2 of draft-ietf-kitten-gssapi-prf-03.txt: Mechanisms MUST be able to output at least up to 2^14 octets. If the implementation cannot produce the desired output due to lack of resources then it MUST output what it can and still return GSS_S_COMPLETE. Perhaps we should sprinkle "cryptographically safe" there. > (b) what the application caller can rely on to be safely available. I think the application should be prepared to fail if there's not enough PRF output, or if the PRF is not available. > We should add a reference to the document draft-eastlake-randomness2-10.txt > that is sitting on the Editor's queue: With respect to what? The input to the PRF? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 19:13:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaM7C-0004Zk-83; Mon, 23 May 2005 19:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaM79-0004ZM-1l for kitten@megatron.ietf.org; Mon, 23 May 2005 19:13: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 TAA12693 for ; Mon, 23 May 2005 19:13:36 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaMPC-0000pw-Fj for kitten@ietf.org; Mon, 23 May 2005 19:32:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8E8D6E0063; Mon, 23 May 2005 19:13:14 -0400 (EDT) To: "Blumenthal, Uri" References: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> <20050523172407.GB27516@binky.Central.Sun.COM> From: Sam Hartman Date: Mon, 23 May 2005 19:13:14 -0400 In-Reply-To: <20050523172407.GB27516@binky.Central.Sun.COM> (Nicolas Williams's message of "Mon, 23 May 2005 12:24:07 -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: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, May 19, 2005 at 01:58:18PM -0400, Blumenthal, Uri Nicolas> wrote: >> >>> That text does need some cleanup, and the real issue is >> that the GSS-API >>> can't enforce any limits on the useful >> lifetime of PRF output used for >>> cryptographic purposes. >> So, I propose replacing that paragraph with: >> >>> >> >>> Care should be taken not to exceed the useful lifetime of >> >>> GSS_Pseudo_random() output, particularly when used for >> cryptographic >>> purposes. Specifically, applications should >> limit use of >>> cryptographic keys derived from >> GSS_Pseudo_random() output to the >>> original lifetime of the >> security contexts to which >>> GSS_Pseudo_random() is applied. >> >>> >> >>> That seems much more specific -- no handfuls, pinches or >> touches. >> >> >> >> I am much happier with the proposed text. Does anyone else >> have any >> comments? >> > >> >I have no problem with adding that text, but it sounds like it >> addresses a >different problem than the paragraph Nico proposes >> to replace. The >existing text appears to be concerned about >> the amount of data which the >PRF can safely be used to >> generate. >> >> I like the above text (let it stay), but agree with Jeff - we >> need something else in addition. Could say something along the >> lines of: >> >> Care should be taken not to exceed the amount of data that PRF >> can safely generate. >> >> This amount naturally depends on the mechanisms used. :-) Nicolas> This is a consideration for mechanisms as much as for Nicolas> applications. Nicolas> Mechanisms should not allow the PRF to output more than Nicolas> is safe. I'm not sure that this is true. I think it is a system level concern and like Uri's original text. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 23 19:55:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMlL-0002nh-6e; Mon, 23 May 2005 19:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaMlI-0002nO-TV for kitten@megatron.ietf.org; Mon, 23 May 2005 19:55: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 TAA15432 for ; Mon, 23 May 2005 19:55:05 -0400 (EDT) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaN3M-0002RN-FG for kitten@ietf.org; Mon, 23 May 2005 20:13:49 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id BAA25917; Tue, 24 May 2005 01:54:57 +0200 (MESZ) From: Martin Rex Message-Id: <200505232354.BAA02708@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 24 May 2005 01:54:57 +0200 (MET DST) In-Reply-To: <20050523230311.GE27936@binky.Central.Sun.COM> from "Nicolas Williams" at May 23, 5 06:03:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Tue, May 24, 2005 at 12:43:37AM +0200, Martin Rex wrote: > > As with a similar discussion on krb-ietf list how a KDC cert should > > be verified in PKINIT, we should not ignore the fact that the affected > > spec (here) is going to be normative for both, the gssapi mechanism > > implementor and the application gssapi caller, and those two > > will have an entirely different background and needs. > > > > We should add a reference to the document draft-eastlake-randomness2-10.txt > > that is sitting on the Editor's queue: > > With respect to what? The input to the PRF? You got me, I'm not following my own advice. This reference should be guidance for gssapi mechanism implementors that provide PRF output based on the cryptographic session key. It may not be necessary for gssapi mechanisms where the implementation details are public or even part of a public/published spec. But you should not underestimate the number of gssapi mechanisms that don't have a formal spec of any kind, there are plenty of them. GSS-API is primarily a spec for an API and only secondarily a framework for independent interoperable mechanism implementations based on common public spec. And in order to provide a useful standard for the application writers, the spec will have to provide some guidance on behaviour for proprietary gssapi mechanisms and a level of expectation for the application writers. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 24 13:26:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadAY-0007Id-Bj; Tue, 24 May 2005 13:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadAW-0007IX-Gi for kitten@megatron.ietf.org; Tue, 24 May 2005 13:26: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 NAA20739 for ; Tue, 24 May 2005 13:26:11 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DadSi-0004Yn-9R for kitten@ietf.org; Tue, 24 May 2005 13:45:04 -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 j4OHQA0R013378 for ; Tue, 24 May 2005 11:26:10 -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 j4OHQAEN027319 for ; Tue, 24 May 2005 11:26:10 -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 j4OHQAEl028690; Tue, 24 May 2005 12:26:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4OHQ9xw028689; Tue, 24 May 2005 12:26:09 -0500 (CDT) Date: Tue, 24 May 2005 12:26:09 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20050524172609.GK27936@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20050523230311.GE27936@binky.Central.Sun.COM> <200505232354.BAA02708@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505232354.BAA02708@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Tue, May 24, 2005 at 01:54:57AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Tue, May 24, 2005 at 12:43:37AM +0200, Martin Rex wrote: > > > As with a similar discussion on krb-ietf list how a KDC cert should > > > be verified in PKINIT, we should not ignore the fact that the affected > > > spec (here) is going to be normative for both, the gssapi mechanism > > > implementor and the application gssapi caller, and those two > > > will have an entirely different background and needs. > > > > > > We should add a reference to the document draft-eastlake-randomness2-10.txt > > > that is sitting on the Editor's queue: > > > > With respect to what? The input to the PRF? > > You got me, I'm not following my own advice. > > This reference should be guidance for gssapi mechanism implementors > that provide PRF output based on the cryptographic session key. There's already plenty of text on what properties a mechanism's GSS_Pseudo_random() must have. Or do you see anything missing? And as for randomness, that is a core consideration for the mechanisms and totally out of scope here as GSS_Pseudo_random() can only use keys already exchanged by the mechanism during security context establishment and already considered, by the mechanism, good enough for per-message protection services. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 24 13:27:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadBy-0007Xe-PY; Tue, 24 May 2005 13:27:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DadBw-0007XZ-U4 for kitten@megatron.ietf.org; Tue, 24 May 2005 13:27: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 NAA20993 for ; Tue, 24 May 2005 13:27:41 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DadU9-0004e1-Sl for kitten@ietf.org; Tue, 24 May 2005 13:46:35 -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 j4OHRg0R015500 for ; Tue, 24 May 2005 11:27:42 -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 j4OHRgEN028327 for ; Tue, 24 May 2005 11:27:42 -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 j4OHReWN028697; Tue, 24 May 2005 12:27:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4OHRd3T028696; Tue, 24 May 2005 12:27:39 -0500 (CDT) Date: Tue, 24 May 2005 12:27:39 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050524172739.GL27936@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , "Blumenthal, Uri" , kitten@ietf.org References: <3DEC199BD7489643817ECA151F7C5929012AA5E9@pysmsx401.amr.corp.intel.com> <20050523172407.GB27516@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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, May 23, 2005 at 07:13:14PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> This is a consideration for mechanisms as much as for > Nicolas> applications. > > Nicolas> Mechanisms should not allow the PRF to output more than > Nicolas> is safe. > > > I'm not sure that this is true. I think it is a system level concern > and like Uri's original text. I'm losing track. Can we some sense of whether this is ready for WG Last Call? We seem to be arguing about security considerations only, rather than over any technical details. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 25 11:00:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaxMZ-0000Ji-UO; Wed, 25 May 2005 11:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaxMY-0000J9-5C for kitten@megatron.ietf.org; Wed, 25 May 2005 11:00:02 -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 LAA19152 for ; Wed, 25 May 2005 11:00:00 -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 1Daxew-0008FA-Ev for kitten@ietf.org; Wed, 25 May 2005 11:19:03 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4PExvda020857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 May 2005 10:59:57 -0400 (EDT) Message-ID: <429493A6.2040708@columbia.edu> Date: Wed, 25 May 2005 11:03:02 -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: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> 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: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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="===============0495594550==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0495594550== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000408000003080605070004" This is a cryptographically signed message in MIME format. --------------ms000408000003080605070004 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Actually, the question I raised was on the krb5 prf draft since that is where the current text is located. I would like a consensus call on the following questions. (1) Add this text to the security considerations section of the general prf draft: Pseudorandom functions by their nature are capable of producing only limited amounts of cryptographically secure output. The exact amount of output that one can safely use, unfortunately varies from one PRF to another (which prevents us from recommending specific numbers). Because of this, we recommend that unless you really know what you are doing (i.e. you are a cryptographer and are qualified to pass judgement on cryptographic functions in areas of period, presence of short cycles, etc), you limit the amount of the PRF output used to the necessary minimum. (2) Remove from the security consideration section of the krb5 prf draft: Care should be taken not to exceed the useful lifetime of an established security context's session key's useful lifetime as implementations are not required to prevent overuse of the GSS_Pseudo_random() function. This can effectively be achieved by limiting the number of GSS_Pseudo_random() calls to, say, a handful of calls per-security context. Jeffrey Altman Salowey, Joe wrote: > It seems that this text and discussion really belongs in > draft-ietf-kitten-gssapi-prf since the concerns are not Kerberos > mechanism specific. > > Joe --------------ms000408000003080605070004 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 DxcNMDUwNTI1MTUwMzAyWjAjBgkqhkiG9w0BCQQxFgQUKSpBm1DB/srkPgOFN/MPPHE/m6ww UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAtvwPkm35sd6g4SoDgRCisAJOH+4h60MJ5xfyelvH pzYj5ADCPDzj28mk/FtQBumxnWZOS5NT6ajMDzQ65Z49SPjqRveley2M/xoJAGU3YczVxytM hRunBBleEIuAbvWyfJR+7vTdXw4ktbRudN1I+5JWhA+k9dh6x0hs/cnsvbLkS+6qbzRV2wji lmbKMda0wlUKFYoAprLEBg6eQrKTvsAd4MlsW7ldGtQpzcbBGbsmsEbDVqBgYYVDQtfh6bEa yHAPaAk1jD8I/AJqgXOj4t+wpuLwNMXCJ6vN/+3n8tUUSP7Cln8V5Ocqtx5fqHQ3V5uAvybp pvxNrqLxSR9A1wAAAAAAAA== --------------ms000408000003080605070004-- --===============0495594550== 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 --===============0495594550==--