Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Dec 2013 05:59:42 +0000 (UTC)
From:      Benjamin Kaduk <bjk@freebsd.org>
To:        freebsd-hackers@freebsd.org
Subject:   incorrect counter encoding for gss_pseudo_random()
Message-ID:  <alpine.BSF.2.00.1312120552080.19629@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
Hi all,

I recently stumbled upon an interoperability issue between our in-tree 
Heimdal and MIT krb5's implementation of gss_pseudo_random(); the issue is 
known at upstream Heimdal and was patched back in October.

I would like to pull in the fix from upstream, the patch and proposed 
commit message appear below.  Am I correct in thinking that the patch 
would be appropriate to MFC?

Thanks,

Ben

==============
Apply patch from upstream Heimdal for encoding fix

RFC 4402 specifies the implementation of the gss_pseudo_random()
function for the krb5 mechanism (and the C bindings therein).
The implementation uses a PRF+ function that concatenates the output
of individual krb5 pseudo-random operations produced with a counter
and seed.  The original implementation of this function in Heimdal
incorrectly encoded the counter as a little-endian integer, but the
RFC specifies the counter encoding as big-endian.  The implementation
initializes the counter to zero, so the first block of output (16 octets,
for the modern AES enctypes 17 and 18) is unchanged.  (RFC 4402 specifies
that the counter should begin at 1, but both existing implementations
begin with zero and it looks like the standard will be re-issued, with
test vectors, to begin at zero.)

This is upstream's commit f85652af868e64811f2b32b815d4198e7f9017f6,
from 13 October, 2013:
% Fix krb5's gss_pseudo_random() (n is big-endian)
%
% The first enctype RFC3961 prf output length's bytes are correct because
% the little- and big-endian representations of unsigned zero are the
% same.  The second block of output was wrong because the counter was not
% being encoded as big-endian.
%
% This change could break applications.  But those applications would not
% have been interoperating with other implementations anyways (in
% particular: MIT's).

==============================
Index: crypto/heimdal/lib/gssapi/krb5/prf.c
===================================================================
--- crypto/heimdal/lib/gssapi/krb5/prf.c	(revision 259245)
+++ crypto/heimdal/lib/gssapi/krb5/prf.c	(working copy)
@@ -119,7 +119,7 @@
      while(dol > 0) {
  	size_t tsize;

-	_gsskrb5_encode_om_uint32(num, input.data);
+	_gsskrb5_encode_be_om_uint32(num, input.data);

  	ret = krb5_crypto_prf(context, crypto, &input, &output);
  	if (ret) {
@@ -133,7 +133,7 @@

  	tsize = min(dol, output.length);
  	memcpy(p, output.data, tsize);
-	p += output.length;
+	p += tsize;
  	dol -= tsize;
  	krb5_data_free(&output);
  	num++;



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1312120552080.19629>