One document matched: draft-williams-kitten-krb5-extra-rt-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2743 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY rfc4120 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY rfc4121 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4121.xml">
<!ENTITY x680 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.CCITT.X680.2002.xml">
<!ENTITY x690 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.CCITT.X690.2002.xml">
<!ENTITY rfc3530 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3530.xml">
<!ENTITY rfc4251 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4251.xml">
]>
<rfc docName="draft-williams-kitten-krb5-extra-rt-04" ipr="trust200902" category="std" updates="4121">
<front>
<title abbrev="Kerberos Extra AP">Negotiation of Extra Security Context Tokens for Kerberos V5 Generic Security Services Mechanism</title>
<author initials="N." surname="Williams" fullname="Nicolas Williams">
<organization abbrev="Cryptonector">Cryptonector, LLC</organization>
<address>
<email>nico@cryptonector.com</email>
</address>
</author>
<author initials="R." surname="Dowdeswell" fullname="Roland Charles Dowdeswell">
<organization abbrev="Dowdeswell Security Architecture">Dowdeswell Security Architecture</organization>
<address>
<email>elric@imrryr.org</email>
</address>
</author>
<date month="November" year="2014"/>
<area>
Security Area
</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This Internet-Draft proposes an extension to the Kerberos V5 security mechanism for the Generic Security Services Application Programming Interface (GSS-API) for using extra security context tokens in order to recover from certain errors. Other benefits include: user-to-user authentication, authenticated errors, replay cache avoidance, and others.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="d1e300">
<t>
The Kerberos V5 <xref target="RFC4120"/> AP protocol, and therefore the Kerberos V5 GSS-API <xref target="RFC2743"/> mechanism <xref target="RFC4121"/> security context token exchange, is a one-round trip protocol. Occasionally there are errors that the protocol could recover from by using an additional round trip, but until now there was no way to execute such an additional round trip. For many application protocols the failure of the Kerberos AP protocol is fatal, requiring closing TCP connections and starting over; often there is no automatic recovery.</t>
<t>
This document proposes a negotiation of additional security context tokens for automatic recovery from certain errors. This is done in a backwards-compatible way, thus retaining the existing mechanism OID for the Kerberos V5 GSS mechanism. This also enables other new features.</t>
<t>
New features enabled by this extension include:</t>
<t>
<list style="symbols">
<t>
error recovery (see <xref target="sec_Recoverable_Errors_and"/>)</t>
<t>
user-to-user authentication (see <xref target="sub_User_to_User_Authentication"/>)</t>
<t>
some authenticated errors (see <xref target="sub_Authenticated_Errors"/>)</t>
<t>
replay cache avoidance (see <xref target="sub_Replay_Cache_Avoidance"/>)</t>
<t>
acceptor clock skew correction (see <xref target="sec_Acceptor_Clock_Skew"/>)</t>
<t>
symmetric authorization data flows</t>
</list>
</t>
<t>
No new interfaces are needed for GSS-API applications to use the features added in this document.</t>
<section title="Conventions used in this document" anchor="d1e371">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="New Protocol Elements" anchor="d1e386">
<t>
We introduce the following new protocol elements. A partial ASN.1 <xref target="CCITT.X680.2002"/> module (for inclusion in the base Kerberos ASN.1 module) is given in <xref target="sub_ASN_1_for_New"/>, and references to its contents are made below.</t>
<t>
<list style="symbols">
<t>
a new ap-options flag for use in the clear-text part of AP-REQs to indicate the desire for an extra round trip if need be;</t>
<t>
a new authorization data (AD) element for integrity protection of ap-options;</t>
<t>
a new AD element for use in Authenticators for quoting back a challenge from the acceptor;</t>
<t>
a new PDU: KRB-ERROR2, also known as AP-REP2, with additional fields and support for integrity- (and confidentiality-)protected errors and optional <spanx>key confirmation</spanx> :
<list style="symbols"><t>
a flag is used to indicate which key is used to encrypt the KRB-ERROR2's private part, as in some cases there can be two keys to choose from;</t><t>
when no key available for encrypting the private part of a KRB-ERROR2, the null enctype is used.</t></list>
</t>
</list>
</t>
<t>
These elements are used to construct security context token exchanges with potentially more than two context tokens.</t>
<t>
All context tokens are to be prefixed with the InitialContextToken pseudo-ASN.1/DER header from RFC2743, section 3.1, just as RFCs 1964 and 4121 require of the first two context tokens.</t>
<section title="Fields of KRB-ERROR2" anchor="d1e434">
<t>
The new KRB-ERROR2 PDU is defined in <xref target="sub_ASN_1_for_New"/>. The fields of the KRB-ERROR2 encrypted part have the following purpose/semantics:</t>
<t>
<list style="hanging">
<t hangText="continue-challenge">
A challenge to be quoted back in any subsequent context tokens.</t>
<t hangText="stime">
The acceptor's current time.</t>
<t hangText="susec">
Microsecond portion of the acceptor's current time.</t>
<t hangText="subkey">
The acceptor's sub-session key. This MUST be absent when the KRB-ERROR2 enc-part is “encrypted” in the null enctype and key or when the acceptor failed to decrypt the initiator's Authenticator (but, obviously, succeeded at decrypting the Ticket); otherwise it MUST be present.</t>
<t hangText="seq-number">
The acceptor's initial per-message token sequence number. This MUST be absent when the subkey is absent; otherwise it MUST be present.</t>
<t hangText="error-code">
When zero-valued, the KRB-ERROR2 is not an error token, but a key-confirmation that requires continuation with an additional AP-REQ.</t>
<t hangText="e-flags">
Indicates whether the KRB-ERROR2 is final (error token) or not.</t>
<t hangText="e-text">
A human-readable string (in any language and script) description of the error, if any.</t>
<t hangText="e-data">
Currently unused but specified for extensibility reasons. SHOULD be absent and MUST be ignored.</t>
<t hangText="e-typed-data">
TYPED-DATA; see <xref target="RFC4120"/>. Currently unused but specified for extensibility reasons. SHOULD be absent and MUST be ignored.</t>
<t hangText="your-addresses">
The initiator's network address(es) as seen on the acceptor side. Currently unused due to insufficient GSS-API interfaces, but specified for extensibility reasons. SHOULD be absent, MUST be ignored.</t>
<t hangText="ad-data">
Authorization-data. This is intended for symmetry, so that acceptors can assert authorization data to the initiator just as the initiator can assert authorization data to the acceptor. (For example, this might be useful in user-to-user authentication.) When present this has the same semantics as in the AP-REQ's Authenticator, but in the opposite direction.</t>
<t hangText="tgt">
A TGT for use in user-to-user authentication.</t>
</list>
</t>
</section>
<section title="Distinction between KRB-ERROR2 and AP-REP2 PDUs" anchor="d1e521">
<t>
The ASN.1 does not distinguish between KRB-ERROR2 and AP-REP2 PDUs. A KRB-ERROR2 can serve either or both, the purpose of conveying error information, as well as the purpose of completing the acceptor's side of the context token exchange and providing key confirmation. We could have used three distinct PDUs instead of one.</t>
<t>
It is true that a KRB-ERROR2 that only serves the purpose of final key confirmation without continuation could have a different ASN.1 type for its encrypted part, and a different application tag, however, there seems to be little value in this. Distinguishing between errors with and without key confirmation is even less valuable. Therefore we do not distinguish these three possible PDUs.</t>
</section>
</section>
<section title="Negotiation and Use of Extra Context Tokens" anchor="d1e533">
<t>
In the following text “initiator” refers to the mechanism's initiator functionality (invoked via GSS_Init_sec_context()), and “acceptor” refers to the mechanism's acceptor functionality (invoked via GSS_Accept_sec_context()).</t>
<t>
To use this feature, the Kerberos GSS mechanism MUST act as follows:</t>
<t>
<list style="symbols">
<t>
To request this feature, initiators SHALL add the new ap-options flag to their AP-REQs.
<list style="symbols"><t>
And the initiators SHALL repeat the ap-options in the new AD-AP-OPTIONS AD type in the Authenticator.</t></list>
</t>
<t>
Acceptors that wish to request an additional security context token can only do so when initiators indicate support for it, and MUST do so by returning a KRB-ERROR2. The encrypted part of the KRB-ERROR2 SHALL be encrypted in a key derived (with key usage <TBD>) from one of the following keys: the sub-session key from the AP-REQ's Authenticator (use-initiator-subkey) if it could be decrypted, else the session key from the Ticket (use-ticket-session-key), if it could be decrypted, else the null enc-type/key (use-null-enctype).</t>
<t>
Any KRB-ERROR2 emitted by the acceptor SHALL have the continue-needed e-flag set when the GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED to the application, and in this case the token ID SHALL be 02 00 (KRB_AP_REP, even though the token isn't actually an AP-REP) (see <xref target="RFC4121"/> section 4.1).</t>
<t>
When it consumes a KRB-ERROR2, GSS_Init_sec_context() can return an error (GSS_S_FAILURE) and optionally output an error token, or it can attempt recovery (see <xref target="sec_Recoverable_Errors_and"/>) and output a new AP-REQ security context token.
<list style="symbols"><t>
Any error token output by GSS_Init_sec_context() MUST be a KRB-ERROR2, and GSS_Init_sec_context() MUST return GSS_S_FAILURE.</t><t>
The initiator MUST quote the challenge from the KRB-ERROR2 using an AD-CONTINUE-CHALLENGE (see below) authorization data element in any AP-REQ or KRB-ERROR2 response to the acceptor's KRB-ERROR2.</t><t>
When GSS_Init_sec_context() outputs a new AP-REQ security context token, it SHALL return GSS_S_CONTINUE_NEEDED if the application requested mutual authentication and the previous acceptor security context token was a recoverable error (rather than a request for one more AP-REQ), else it SHALL return GSS_S_COMPLETE.</t><t>
When GSS_Init_sec_context() returns an error and the acceptor is awaiting a security context token, GSS_Init_sec_context() MAY generate a KRB-ERROR2 or KRB-ERROR to send to the acceptor.</t></list>
</t>
<t>
Acceptors MUST reject additional AP-REQs which do not have a challenge response nonce matching the one sent by the acceptor in the previous KRB-ERROR2.</t>
<t>
Acceptors MUST reject initial security context tokens that contain a challenge response nonce.</t>
<t>
When GSS_Accept_sec_context() returns an error and outputs an error token, the token MUST be either a KRB-ERROR or a KRB-ERROR2, with the latter having the continue-needed flag cleared.</t>
</list>
</t>
<t>
All non-recoverable KRB-ERROR2 tokens SHALL use the token ID 03 00.</t>
<t>
Additional AP-REQs produced by the authenticator MUST have the mutual-required ap-options flag set when a) the application requested mutual authentication, and b) the acceptor's KRB-ERROR2 did not supply the required key confirmation. The acceptor MUST respond to the client's last AP-REQ with an AP-REP when the mutual-required ap-options flag is set or when the GSS_C_MUTUAL_FLAG is set in the “checksum 0x8003”, otherwise GSS_Accept_sec_context() MUST NOT produce a response token when it returns GSS_S_COMPLETE.</t>
<section title="Number of Security Context Tokens" anchor="d1e601">
<t>
The first AP-REQ may well result in an error; the second generally should not. Therefore acceptors SHOULD return a fatal error when a second error results in one security context establishment attempt, except when the first error is that the initiator should use user-to-user authentication. This limits the maximum number of round trips to two (not user-to-user) or three (user-to-user).</t>
<t>
The mechanism SHOULD impose some limit on the maximum number of security context tokens. For the time being that limit is six.</t>
<t>
Note that in the user-to-user cases (see <xref target="sub_User_to_User_Authentication"/>) it's possible to have up to three round trips under normal conditions if, for example, the acceptor wishes to avoid the use of replay caches (see <xref target="sub_Replay_Cache_Avoidance"/>), or if the initiator's clock is too skewed, for example.</t>
</section>
<section title="Possible Context Token Sequences" anchor="d1e623">
<t>
The following successful security context token exchange sequences are possible:</t>
<t>
<list style="symbols">
<t>
One token (per-RFC4121; mutual authentication not requested): AP-REQ.
<list style="symbols"><t>
In principle this can yield an error token in the case of errors, per-RFC2743.</t></list>
</t>
<t>
Two tokens (per-RFC4121; mutual authentication requested): AP-REQ and AP-REP.</t>
<t>
Two tokens (per-RFC4121; mutual authentication requested): AP-REQ and KRB-ERROR.</t>
<t>
Two tokens (per-RFC4121; mutual authentication requested): AP-REQ and KRB-ERROR2 (non-recoverable error, or recoverable error but the acceptor mechanism is configured to not continue).</t>
<t>
Two tokens (per-RFC4121; mutual authentication requested): AP-REQ and KRB-ERROR2 (recoverable error for the acceptor, but not for the initiator, or the initiator application abandons the partially-established security context).</t>
<t>
Three tokens: AP-REQ, KRB-ERROR2 (recoverable error), AP-REQ.
<list style="symbols"><t>
The initiator indicates it supports multiple round trips, and a recoverable error results on the acceptor side.</t><t>
Either the initiator did not request mutual authentication, or the KRB-ERROR2 supplied the necessary key confirmation.</t></list>
</t>
<t>
Three tokens: AP-REQ, KRB-ERROR2 (no error, continue needed), AP-REQ.
<list style="symbols"><t>
The initiator indicates it supports multiple round trips, and its Authenticator and Ticket decrypt correctly on the acceptor side, but the acceptor wants to continue, e.g., to avoid the need for a replay cache (see <xref target="sub_Replay_Cache_Avoidance"/>).</t><t>
This can happen in any recoverable error case where the initiator's Authenticator (and Ticket) decrypt successfully on the acceptor side.</t></list>
</t>
<t>
Four tokens: AP-REQ, KRB-ERROR2 (recoverable error), AP-REQ, AP-REP.
<list style="symbols"><t>
The initiator wanted mutual authentication and a recoverable error occurred where the KRB-ERROR2 could not provide key confirmation, leading to the second round trip.</t><t>
This can happen in any recoverable error case where the initiator's Authenticator did not decrypt successfully.</t><t>
This can also happen in the user-to-user case.</t><t>
This case provides replay cache avoidance without a fifth token because the acceptor provides a challenge in its first (KRB-ERROR2) token and the initiator completes the challenges in its second token.</t></list>
</t>
<t>
Five tokens: AP-REQ, KRB-ERROR2 (with user-to-user TGT), AP-REQ, KRB-ERROR2 (recoverable error), AP-REQ.
<list style="symbols"><t>
The initiator does not want mutual authentication, the acceptor wants user-to-user authentication, and the initiator's second AP-REQ elicits a recoverable error.</t></list>
</t>
<t>
Six tokens: AP-REQ, KRB-ERROR2 (with user-to-user TGT), AP-REQ, KRB-ERROR2 (recoverable error), AP-REQ, AP-REP.
<list style="symbols"><t>
The initiator wants mutual authentication, the acceptor wants user-to-user authentication, and the initiator's second AP-REQ elicits a recoverable error; none of the KRB-ERROR2 tokens was a key-confirmation token.</t></list>
</t>
</list>
</t>
<t>
Other context token sequences might be possible in the future.</t>
<t>
In the above sequences the AP-REP tokens can be AP-REP2 tokens as well.</t>
</section>
<section title="Per-Message Token Sequence Numbers" anchor="d1e717">
<t>
It is REQUIRED that each real AP-REQ in a single security token exchange specify the same start sequence number as preceding AP-REQs in the same security context token exchange.</t>
</section>
<section title="Early PROT_READY State" anchor="d1e726">
<t>
The GSS-API allows security mechanisms to support the use of per-message tokens prior to full security context establishment. In this section we'll call this “early PROT_READY”. Early PROT_READY is optional for the GSS-API and for implementations of mechanisms that support it.</t>
<t>
The Kerberos V GSS mechanism supports this in the two-token exchange, with the initiator being PROT_READY before consuming the AP-REP. This extension also supports early PROT_READY, which works as follows:</t>
<t>
<list style="numbers">
<t>
The initiator asserts a sub-session key in each AP-REQ that does not follow a key-confirmation KRB-ERROR2, and GSS_Init_sec_context() sets the prot_ready_state return flag on the first call.
<list style="numbers"><t>
If there are multiple such AP-REQs in a security context token exchange, then each such AP-REQ must assert the same sub-session key.</t><t>
Subsequent AP-REQs need not carry a sub-session key; acceptors MUST ignore sub-session keys from subsequent AP-REQs.</t></list>
</t>
<t>
GSS_Accept_sec_context() MUST NOT set the prot_ready_state return flag until it has successfully decrypted an AP-REQ's Ticket and Authenticator from the initiator. If the acceptor requests additional context tokens and signals PROT_READY at that point, then it too will be PROT_READY.</t>
</list>
</t>
<t>
Replay protection for early prot_ready per-message tokens depends on the initiator always generating a fresh sub-session key for every security context's initial context token, on the acceptor always generating a fresh sub-session key for its key confirmation token, and on either a replay cache or the challenge/response token provided for in this document:</t>
<t>
<list style="symbols">
<t>
An attacker cannot replay an early per-message token without also replaying the corresponding initial security context token (as otherwise the initiator-asserted sub-session keys won't match), and replay protection for the initial security context token provides replay protection for any subsequent early per-message tokens.</t>
<t>
Per-message tokens made after full security context establishment are protected against replay by the use of the acceptor's sub-session key hierarchy (since the initiator must then use that key).</t>
<t>
AP-REPs and key-confirmation KRB-ERROR2s are protected against replays to initiators by the use of the initiator's sub-session key.</t>
<t>
Initial security context tokens (and error-recovery AP-REQs) are protected against replay either by a replay cache on the acceptor side, or by the use of additional context tokens for challenge/response replay cache avoidance (see <xref target="sub_Replay_Cache_Avoidance"/>).</t>
</list>
</t>
</section>
<section title="Other Requirements, Recommendations, and Non-Requirements" anchor="d1e773">
<t>
All error PDUs in an AP exchange where the AP-REQ has the continue-needed-ok ap-options flag MUST be KRB-ERROR2 PDUs.</t>
<t>
Whenever an acceptor is able to decrypt the Ticket from an AP-REQ and yet wishes or has to output a KRB-ERROR2, then the enc-part of the KRB-ERROR2 MUST be encrypted in either the initiator's sub-session key (from the Authenticator) or the Ticket's session key (if the acceptor could not decrypt the Authenticator).</t>
</section>
</section>
<section title="ASN.1 Module for New Protocol Elements" anchor="sub_ASN_1_for_New">
<t>
A partial ASN.1 module appears below. This ASN.1 is to be used as if it were part of the base Kerberos ASN.1 module (see RFC4120), therefore the encoding rules to be used are the Distinguished Encoding Rules (DER) <xref target="CCITT.X690.2002"/>, and the environment is one of explicit tagging.</t>
<t>
</t>
<t>
<figure anchor="magicparlabel-302" title="ASN.1 module (with explicit tagging)">
<artwork> KerberosExtraContextTokens DEFINITIONS ::=
BEGIN
EXPORTS ad-continue-challenge,
AD-CONTINUE-CHALLENGE,
KrbErrorEncPartFlags,
KRB-ERROR2,
ErrorFlags;
IMPORTS UInt32, Int32, KerberosTime,
Microseconds, KerberosFlags,
Checksum, EncryptedData,
EncryptionKey, KerberosString,
AuthorizationData, TYPED-DATA,
HostAddresses, Ticket FROM KERBEROS5;
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2),
-- continue-needed-ok(TBD)
-- Challenge (for use in Authenticator)
ad-continue-challenge Int32 ::= -5 -- <TBD>
AD-CONTINUE-CHALLENGE ::= OCTET STRING
-- AP options, integrity-protected
ad-ap-options Int32 ::= -6 -- <TBD>
AD-AP-OPTIONS ::= KerberosFlags
KrbErrorEncPartFlags ::= ENUMERATED {
use-null-enctype(0),
use-initiator-subkey(1),
use-ticket-session-key(2),
...
}
-- Application tag TBD
KRB-ERROR2 ::= [APPLICATION 55] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (55), -- TBD
enc-part-key [2] KrbErrorEncPartFlags,
enc-part [3] EncryptedData -- EncKRBErrorPart
}
-- Alias type name
AP-REP2 ::= KRB-ERROR2
ErrorFlags ::= ENUMERATED {
final(0),
continue-needed(1),
...
}
-- Application tag TBD
EncKRBErrorPart ::= [APPLICATION 56] SEQUENCE {
continue-challenge [0] AD-CHALLENGE-RESPONSE,
stime [1] KerberosTime,
susec [2] Microseconds,
subkey [3] EncryptionKey OPTIONAL,
seq-number [4] UInt32 OPTIONAL,
error-code [5] Int32,
e-flags [6] ErrorFlags,
e-text [7] UTF8String OPTIONAL,
e-data [8] OCTET STRING OPTIONAL,
e-typed-data [9] TYPED-DATA OPTIONAL,
-- For recovery from KRB_AP_ERR_BADADDR:
your-addresses [10] HostAddresses OPTIONAL,
ad-data [11] AuthorizationData OPTIONAL,
tgt [12] Ticket OPTIONAL, -- for user2user
...
}
END</artwork>
</figure>
</t>
</section>
<section title="Recoverable Errors and Error Recovery" anchor="sec_Recoverable_Errors_and">
<t>
The following Kerberos errors can be recovered from automatically using this protocol:</t>
<t>
<list style="symbols">
<t>
KRB_AP_ERR_TKT_EXPIRED: the initiator should get a new service ticket;</t>
<t>
KRB_AP_ERR_TKT_NYV: the initiator should get a new service ticket;</t>
<t>
KRB_AP_ERR_REPEAT: the initiator should build a new AP-REQ;</t>
<t>
KRB_AP_ERR_SKEW: see <xref target="sec_Acceptor_Clock_Skew"/>;</t>
<t>
KRB_AP_ERR_BADKEYVER: the initiator should get a new service ticket;</t>
<t>
KRB_AP_PATH_NOT_ACCEPTED: the initiator should get a new service ticket using a different transit path;</t>
<t>
KRB_AP_ERR_INAPP_CKSUM: the initiator should try again with a different checksum type.</t>
</list>
</t>
<t>
Error codes that denote PDU corruption (and/or an active attack) can also be recovered from by attempting a new AP-REQ, though subsequent AP-REQs may fail for the same reason:</t>
<t>
<list style="symbols">
<t>
KRB_AP_ERR_BAD_INTEGRITY</t>
<t>
KRB_AP_ERR_BADVERSION</t>
<t>
KRB_AP_ERR_BADMATCH</t>
<t>
KRB_AP_ERR_MSG_TYPE</t>
<t>
KRB_AP_ERR_MODIFIED</t>
</list>
</t>
<t>
Other error codes that may be recovered from:</t>
<t>
<list style="symbols">
<t>
KRB_AP_ERR_BADADDR: the acceptor SHOULD include a list of one or more client network addresses as reported by the operating system, but if the acceptor does not then the continue-needed e-flag MUST NOT be included and the error must be final.</t>
</list>
</t>
<section title="Authenticated Errors" anchor="sub_Authenticated_Errors">
<t>
The following errors, at least, can be authenticated in AP exchanges:</t>
<t>
<list style="symbols">
<t>
KRB_AP_ERR_TKT_EXPIRED</t>
<t>
KRB_AP_ERR_TKT_NYV</t>
<t>
KRB_AP_ERR_REPEAT</t>
<t>
KRB_AP_ERR_SKEW</t>
<t>
KRB_AP_PATH_NOT_ACCEPTED</t>
<t>
KRB_AP_ERR_INAPP_CKSUM</t>
<t>
KRB_AP_ERR_BADADDR</t>
</list>
</t>
</section>
</section>
<section title="Replay Cache Avoidance" anchor="sub_Replay_Cache_Avoidance">
<t>
By using an additional AP-REQ and a challenge/response nonce, this protocol is immune to replays of AP-REQ PDUs and does not need a replay cache. Acceptor implementations MUST not insert Authenticators from extra round trips into a replay cache when there are no other old implementations on the same host (and with access to the same acceptor credentials) that ignore critical authorization data or which don't know to reject initial AP-REQs that contain a challenge response nonce.</t>
<t>
In the replay cache avoidance case where there's no actual error (e.g., time skew) the acceptor's KRB-ERROR2 will have KDC_ERR_NONE as the error code, with the continue-needed e-flag.</t>
<section title="Replay Cache Avoidance without Extensions" anchor="d1e935">
<t>
Many Kerberos services can avoid the use of a replay cache altogether, but it's tricky to know when it's safe to do so. For Kerberos it's safe to not use a replay cache for AP-REQs/Authenticators when either:</t>
<t>
<list style="symbols">
<t>
the application doesn't require replay detection at all and
<list style="symbols"><t>
no other acceptor/service application shares the same long-term service keys for its service principal</t></list>
</t>
</list>
</t>
<t>
or</t>
<t>
<list style="symbols">
<t>
the application protocol always has the initiator/client send the first per-message token (or KRB-SAFE/PRIV PDU) which can then function as a challenge response, and
<list style="symbols"><t>
no other acceptor/service application shares the same long-term service keys for its service principal</t></list>
</t>
</list>
</t>
<t>
It is difficult to establish the second part of the above conjunctions programmatically. In practice this is best left as a local configuration matted on a per-service name basis.</t>
<t>
For example, it's generally safe for NFSv4 <xref target="RFC3530"/> to not use a replay cache for the Kerberos GSS mechanism, but it is possible for multiple Kerberos host-based service principals on the same host to share the same keys, therefore in practice, the analysis for NFSv4 requires more analysis. The same is true for SSHv2 <xref target="RFC4251"/> (SSHv2 implementations share the same service principal as other non-GSS Kerberos applications that do sometimes need a replay cache).</t>
</section>
</section>
<section title="User-to-User Authentication" anchor="sub_User_to_User_Authentication">
<t>
There are two user2user authentication cases:</t>
<t>
<list style="numbers">
<t>
the KDC only allows a service principal to use user2user authentication,</t>
<t>
the service principal does not know its long-term keys or otherwise wants to use user2user authentication even though the KDC vended a service ticket.</t>
</list>
</t>
<t>
In the first case the initiator knows this because the KDC returns KDC_ERR_MUST_USE_USER2USER. The initiator cannot make a valid AP-REQ in this case, yet it must send some sort of initial security context token! For this case we propose that the initiator make an AP-REQ with a Ticket with zero-length enc-part (and null enctype) and a zero-length authenticator (and null enctype). The acceptor will fail to process the AP-REQ, of course, and SHOULD respond with a continue-needed KRB-ERROR2 (using the null enc-type for the enc-part) that includes a TGT for the acceptor.</t>
<t>
In the second case the initiator does manage to get a real service ticket for the acceptor but the acceptor nonetheless wishes to use user2user authentication.</t>
<t>
In both cases the acceptor responds with a KRB-ERROR2 with the KRB_AP_ERR_USER_TO_USER_REQUIRED error code and including a TGT for itself.</t>
<t>
In both cases the initiator then does a TGS request with a second ticket to get a new, user2user Ticket. Then the initiator makes a new AP-REQ using the new Ticket, and proceeds.</t>
</section>
<section title="Acceptor Clock Skew Correction" anchor="sec_Acceptor_Clock_Skew">
<t>
An initiator in possession of a (short-lived) valid service ticket for a given service principal... must have had little clock skew relative to the service principal's realm's KDC(s), or the initiator must have been able to correct its local clock skew. But the acceptor's clock might be skewed, yielding a KRB_AP_ERR_SKEW error with a challenge. The client could recover from this by requesting a new service ticket with this challenge as an authorization data element. The acceptor should be able to verify this in the subsequent AP-REQ, and then it should be able to detect that its clock is skewed and to estimate by how much.</t>
</section>
<section title="Security Considerations" anchor="d1e1025">
<t>
This document deals with security.</t>
<t>
The new KRB-ERROR2 PDU is cryptographically distinguished from the original mechanism's acceptor success security context token (AP-REQ).</t>
<t>
Not every KRB-ERROR2 can be integrity protected. This is unavoidable.</t>
<t>
Because in the base Kerberos V5 GSS-API security mechanism all errors are unauthenticated, and because even with this specification some elements are unauthenticated, it is possible for an attacker to cause one peer to think that the security context token exchange has failed while the other thinks it will continue. This can cause an acceptor to waste resources while waiting for additional security context tokens from the initiator. This is not really a new problem, however: acceptor applications should already have suitable timeouts on security context establishment.</t>
<t>
There is a binding of preceding security context tokens in each additional AP-REQ, via the challenge-response nonce. This binding is weak, and does not detect all modifications of unauthenticated plaintext in preceding security context tokens.</t>
<t>
<cref>
We could use the GSS_EXTS_FINISHED extension from draft-ietf-kitten-iakerb to implement a strong binding of all context tokens.</cref>
</t>
<t>
Early prot_ready per-message tokens have security considerations that are beyond the scope of this document and which are not exhaustively described elsewhere yet. Use only with care.</t>
</section>
<section title="IANA Considerations" anchor="d1e1053">
<t>
<cref>
Various allocations are required...</cref>
</t>
</section>
</middle>
<back>
<references title="Normative References">&rfc2119;
&rfc2743;
&rfc4120;
&rfc4121;
&x680;
&x690;
</references>
<references title="Informative References">&rfc3530;
&rfc4251;
<reference anchor="I-D.swift-win2k-krb-user2user"><front><title>User to User Kerberos Authentication using GSS-API</title><author initials="M." surname="Swift" fullname="Michael Swift"><organization/></author><author initials="J." surname="Brezak" fullname="John Brezak"><organization/></author><author initials="P." surname="Moore" fullname="Patrick Moore"><organization/></author><date month="February" day="21" year="2011"/><abstract><t>The security model of the web platform has evolved over time to meet the needs of new applications and to correct earlier mistakes. Although web security has evolved largely organically, the security model has converged towards a handful of key concepts. This document presents those concepts and provides advice to designers of new pieces of the web platform.</t></abstract></front><seriesInfo name="Internet-Draft" value="draft-swift-win2k-krb-user2user-03"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-swift-win2k-krb-user2user-03.txt"/></reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:12:08 |