Greg Hudson
2018-02-13 15:11:29 UTC
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.
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.