Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.txt

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 23 May 2005 22:24 UTC

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 <kitten@ietf.org>; 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 <kitten@ietf.org>; 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 <kitten@ietf.org>; 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 <Nicolas.Williams@sun.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Message-ID: <20050523222438.GC27936@binky.Central.Sun.COM>
Mail-Followup-To: "Blumenthal, Uri" <uri.blumenthal@intel.com>, Ken Raeburn <raeburn@MIT.EDU>, 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 <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 <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=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