IETF Logo Mail Archive

[kitten] krb5 gss_pseudo_random implementation/spec variance

Greg Hudson <ghudson@MIT.EDU> Wed, 11 December 2013 21:13 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17061A1F5D for <kitten@ietfa.amsl.com>; Wed, 11 Dec 2013 13:13:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.103
X-Spam-Level:
X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcDoEMpL8eQn for <kitten@ietfa.amsl.com>; Wed, 11 Dec 2013 13:13:13 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0501AD694 for <kitten@ietf.org>; Wed, 11 Dec 2013 13:13:13 -0800 (PST)
X-AuditID: 1209190c-b7f7f6d000000bbd-f9-52a8d5636d4d
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 16.7C.03005.365D8A25; Wed, 11 Dec 2013 16:13:07 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id rBBLD6nL007088 for <kitten@ietf.org>; Wed, 11 Dec 2013 16:13:07 -0500
Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rBBLD5dN012021 for <kitten@ietf.org>; Wed, 11 Dec 2013 16:13:06 -0500
From: Greg Hudson <ghudson@MIT.EDU>
To: kitten@ietf.org
Date: Wed, 11 Dec 2013 16:12:44 -0500
Message-ID: <x7d61qv852r.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixG6nrpt8dUWQwY0bChZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxretC9gKZvJW3Ow6z9bAuIKri5GDQ0LARKJnt2YXIyeQKSZx 4d56ti5GLg4hgdlMEn1bjjBCOMcZJVafvcgC4XQwSXye+pANpIVNQFni4NlvLCC2iICwxO6t 75hBbGEBG4lvcx6AxVkEVCW2fekHi/MKGEqs72pig7AFJU7OfAJWwyygJXHj30umCYw8s5Ck ZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKXmlK6iREUHJySPDsY3xxUOsQo wMGoxMP74uCKICHWxLLiytxDjJIcTEqivFUXgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeHcc AcrxpiRWVqUW5cOkpDlYlMR5b3LYBwkJpCeWpGanphakFsFkZTg4lCR4Y68ANQoWpaanVqRl 5pQgpJk4OEGG8wANb74MMry4IDG3ODMdIn+KUVFKnPcdSEIAJJFRmgfXC4veV4ziQK8I87aC rOABRj5c9yugwUxAg28HLwcZXJKIkJJqYAzIzTJ9snjXwc9xC7MC90bb9EktjPs+QXbBC4vq hUtPF5/+vTfLRq21Lo4xabei9ITjz58/L7LJuffmnPQDhc0xumfCcq/Z3NY8MTOwNTY04sXh p/d79vf1L+bcbKgzaenR78V5M5uEav49475wfNrhNPlTwv4r4/ve1F++/TBNLefdJXW9lLVK LMUZiYZazEXFiQC2q/23uQIAAA==
Subject: [kitten] krb5 gss_pseudo_random implementation/spec variance
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 21:13:17 -0000

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.

v2.23.0 | Report a Bug | By Email