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

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 23 May 2005 18:11:56 -0400

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. 

Don't forget to edit my English! :-)

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, May 23, 2005 5:16 PM
To: Blumenthal, Uri
Cc: Ken Raeburn; [email-masked]
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.
> 
> 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 <a>, <b> and <c> the user
> should take care and limit the number of PRF invocations/output bits.
> 
> Does this make sense?

Ok.  Text please?

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 May 2005 18:20:04 -0400

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 May 2005 17:24:38 -0500

> from you! Next you know they'll ask for an implementation! :-)

Text will do, thanks :)

> 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
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 May 2005 00:43:37 +0200 (MET DST)

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: [email-masked]

  The IESG has approved the following document:

  - 'Randomness Requirements for Security '
     <draft-eastlake-randomness2-10.txt> as a BCP

This document contains lots of useful information about cryptographic
randomness.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 May 2005 18:03:12 -0500

>  (a) what the mechanism implementor must provide as a minimum

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.

> that is sitting on the Editor's queue:

With respect to what?  The input to the PRF?

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 May 2005 01:54:57 +0200 (MET DST)

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 May 2005 12:26:09 -0500

> 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
--