Subject: [kitten] etype-info notes

From: Greg Hudson <[email-masked]>
Date: Tue, 13 Feb 2018 10:11:29 -0500

I am mostly sending these notes for archival, although they might be of
interest to some Kerberos implementors.  There are two PKINIT interop
notes mentioned within.

etype-info (PA-ETYPE-INFO and/or PA-ETYPE-INFO2) may appear in a preauth
error or in an AS-REP.  It is intended to give the client the
information it needs to turn a password into an RFC 3961 key.

In the context of RFC 4120, etype-info in a PREAUTH_REQUIRED error is
described as informing encrypted timestamp.  etype-info in an AS-REP is
described as informing the client of string-to-key parameters for the
reply key.  If AS-REP etype-info is sent, "there shall be exactly one
ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in the
AS-REP".  There aren't any cases in RFC 4120 where the reply key is
replaced, so there is no discussion of whether there should be AS-REP
etype-info in that situation or what it should contain.

RFC 4556 (PKINIT) replaces the reply key.  It does not mention
etype-info at all, as PKINIT makes no use of string-to-key or client
long-term keys.  If Diffie-Hellman is used, the enctype of the new reply
key is selected "according to [RFC4120]".  I'm not sure what that should
mean, but a reasonable interpretation is the first request enctype which
the KDC implements.

  Interop note #1: if the client has any long-term keys, the MIT krb5
  KDC sends etype-info in the AS-REP with the enctype of the new reply
  key, but salt information from a client long-term key.  This mixture
  is nonsensical, but mostly harmless since the client won't perform any
  string-to-key operations.

  Interop note #2: the MIT krb5 PKINIT client code should use the AS-REP
  enc-part enctype to generate the reply key.  Instead it relies on
  etype-info in the AS-REP.  If there is no etype-info in the AS-REP, it
  uses etype-info from a previous KDC message, or it assumes the first
  request enctype (which is usually correct, but not guaranteed to be).
  I hope to fix this bug for 1.17 but haven't done so yet.

RFC 6113 more formally introduces the concepts of the initial reply key
and replacing or strengthening it.  It says that etype-info in preauth
errors allows the client to determine the initial reply key (or a set of
them), and suggests that KDCs send only one etype-info element based on
the negotiated enctype so that there can be exactly one initial reply
key.  There is no new discussion of etype-info in AS-REP, so the RFC
4120 restriction on AS-REP etype-info (one element matching the AS-REP
enc-part, if any is sent at all) would seem to stand.

The inability of AS-REP etype-info to describe the initial reply key
could present an obstacle to some hypothetical extensions.  For example,
here is a dummy forward secrecy extension using Diffie-Hellman (finite
field or DH; g is the generator and multiplication is within some DH
group):

  1. The client generates x and sends gx in a pa-data element in every
     AS request.
  2. In the AS-REP, the KDC generates y and sends gy in an AS-REP
     pa-data element.  Both sides compute gxy and strengthen the reply
     key using the result.  During this strengthening the reply key is
     upgraded to the first requested enctype implemented by the KDC.

If no preauth is used, the KDC never gets a chance to describe the
initial reply key in etype-info.  Such an extension would have to
respecify what goes into AS-REP etype-info, or abandon upgrading the
enctype in strengthening so that the AS-REP etype-info can describe the
initial reply key without violating the RFC 4120 restriction.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 13 Feb 2018 16:19:26 -0500

>   I hope to fix this bug for 1.17 but haven't done so yet.

On further investigation, it appears I was partly wrong about this.  The
MIT krb5 PKINIT client will correctly use AS-REP enc-part enctype unless
the KDC sends a different enctype in etype-info in the AS-REP (which
would be in violation of RFC 4120).  Apologies for the noise.