Subject: PRF for crypto graph--selecting among options

From: Sam Hartman <[email-masked]>
Date: Sun, 15 Dec 2002 23:43:11 -0500

As Ken Raeburn discussed in Atlanta, an issue regarding the crypto
draft and pseudo-random functions for keying has come up.  We've
discovered that all the schemes we've been discussing for preauth, the
SAM draft and at least one use of the Kerberos crypto framework
outside the IETF  would benefit from a PRF being made available as one
of the operations of a crypto system.

For the simplified profile, we already have a limited-use PRF in the
form of the dr function.  It is not ideal in that it does not take
arbitrary length inputs and that it involves n-fold.  

We are trying to decide between two options.

Option 1 is to have the PRF in the simplified profile be unrelated to
the definition of dr and dk.  The PRF would be implemented as prf(x) =
e(h(x)) Where e is the block cipher and h is the keyed hash.  For both
e and h the protocol key is used.

There are two problems with this approach.  First, it means that our
usage for setting up specific keys is different from our usage for the
prf.  We believe that both usages are secure but there is unnecessary
duplication.  Another problem is that it breaks the wire encoding for
the SAM draft.  That's sort of unfortunate since Ken Hornstein has
just deployed code based on that draft and contributed it to MIT for
inclusion in our next release.

Option 2 is to  define the PRF for the simplified profile as follows:
prf(x) is defined on two cases.  If x is one block or shorter, then
the result is e(n-fold(x)), otherwise the result is e(h(x)).

We can then define dk in terms of the prf.

The advantage of this option is that it solves the problems of option
1.  Unfortunately it comes with its own problems.  First, it
introduces complexity into the definition of the PRF; we haven't
really escaped the difference that kd and the general prf are
differenet, we just pushed it down a level.  The second problem is
that it has significant security considerations.  Since dk and the prf
use the same core, it is possible for a poorly designed protocol to
expose the protocol key instead of just a specific key.  Since we only
anticipate the prf being used for keying operations, this risk could
be handled by clear advice in the security considerations section.
The third problem is that having a discontinuity in the definition of
the function on the block length boundary places an unusual
requirement on the hash function.  It is important that it not be too
easy to find collisions between the hash and the n-fold or the
function fails to be a prf.  I suspect this is true for any hash we'd
use in practice, but it's certainly an odd requirement to have to
state.

We'd appreciate advice from the working group on which option to
adopt.  I believe that Ken Raeburn favors option 1.  I feel that
there's not a clear right answer here and so we should see if the WG
has any input.

--Sam

---

From: Clifford Neuman <[email-masked]>
Date: Fri, 20 Dec 2002 08:35:37 -0800

This is to alert members of the working group that the new version of
the clarifications document will be out later today.

I will announce it to this list and submit it to internet-drafts.  I
will include a diff from the previous version, and it would be helpful
if those that have time can review the changes over the weekend.  

If there are still issues that I did not catch, then I will make those
changes and resubmit to internet drafts probably before they have
issued the first one I sent.

Clifford Neuman