]> CyberLeo.Net >> Repos - FreeBSD/releng/10.0.git/commit
MFS r249447:
authorhrs <hrs@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Mon, 23 Dec 2013 01:24:21 +0000 (01:24 +0000)
committerhrs <hrs@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Mon, 23 Dec 2013 01:24:21 +0000 (01:24 +0000)
commit22bc89cb674347a0e0bdae7d239f312dbc17be55
tree0a5ba05caf3131300aa0e926441e4871b30630d3
parent922a6021ce63fa71da02d8fbab1dd366018d4054
MFS r249447:
  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).

Approved by: re (gjb)

git-svn-id: svn://svn.freebsd.org/base/releng/10.0@259758 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
UPDATING
crypto/heimdal/lib/gssapi/krb5/prf.c