Apply patch from upstream Heimdal for encoding fix
authorbjk <bjk@FreeBSD.org>
Fri, 13 Dec 2013 03:09:29 +0000 (03:09 +0000)
committerbjk <bjk@FreeBSD.org>
Fri, 13 Dec 2013 03:09:29 +0000 (03:09 +0000)
commitd7ee8f3e6e6f4a898a30017648c3478b3f4dad17
treec5e1b1af19210d11eba52054b6b3f659d14eaf07
parent7a0c976f7e101a3ce3af15861c1a9cd1bd8df649
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: hrs (mentor, src committer)
MFC after: 3 days
crypto/heimdal/lib/gssapi/krb5/prf.c