Subject: [kitten] krb5 gss_pseudo_random implementation/spec variance

From: Greg Hudson <[email-masked]>
Date: Wed, 11 Dec 2013 16:12:44 -0500

RFC 4402 defines the output of gss_pseudo_random using a function named
PRF+, defined as:

         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)

         Tn = pseudo-random(K, n || S)

   where '||' is the concatenation operator, 'n' is encoded as a network
   byte order 32-bit unsigned binary number, truncate(L, S) truncates
   the input octet string S to length L, and pseudo-random() is the
   Kerberos V pseudo-random function [RFC3961].

So the successive calls to RFC 3961 input should have input like:

   00 00 00 01 <gss_pseudo_random input>
   00 00 00 02 <gss_pseudo_random input>
   .
   .
   .

The MIT krb5 implementation (present since release 1.8 in early 2010)
starts at 00 00 00 00 instead of 00 00 00 01.

The Heimdal implementation (present since release 1.4 in late 2010) also
starts at 00 00 00 00.  Heimdal encoded the counter in little-endian,
but this was changed to big-endian on master on 2013-10-30.  Because
both implementations start at zero, the difference in endianness
doesn't cause a discrepancy in the first block of output.

Shishi does not appear to have an implementation.  I don't think Solaris
does either.  I'm not sure whether Microsoft has an implementation (they
don't provide a GSSAPI implementation to my knowledge, but maybe there
is an SSPI function which is supposed to be compatible?) or if Oracle
has one in JGSS.

Has anyone else run across this variance?  If all implementations begin
at 00 00 00 00, then this is similar to the KeyExchange vs. KEYEXCHANGE
issue with RFC 6112: the constants involved are arbitrary and it would
be more painful to change the implementations than the spec.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Dec 2013 19:14:28 -0500 (EST)

> be more painful to change the implementations than the spec.

Meaning that we should submit an erratum and accordingly get told to 
re-issue the document?

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Dec 2013 18:33:17 -0600

I think we should submit an I-D with a) the update to the original, b)
test vectors.  (b) is difficult because we have no standard way to get
a security context with specific keys in it.  We really should
standardize something like the lucid context stuff specifically so
that a) we could publish test vectors for the mechanism, b) re-use
RFC4121 tokens in other non-Kerberos mechanisms.

Nico
--