Negotiation of Extra Security Context Tokens for Kerberos V5 Generic Security Services Mechanism
draft-williams-kitten-krb5-extra-rt-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Nicolás Williams , Roland C. Dowdeswell | ||
| Last updated | 2014-10-27 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-williams-kitten-krb5-extra-rt-02
Network Working Group N. Williams
Internet-Draft Cryptonector
Updates: 4121 (if approved) R. Dowdeswell
Intended status: Standards Track Dowdeswell Security Architecture
Expires: April 30, 2015 October 27, 2014
Negotiation of Extra Security Context Tokens for Kerberos V5 Generic
Security Services Mechanism
draft-williams-kitten-krb5-extra-rt-02
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Williams & Dowdeswell Expires April 30, 2015 [Page 1]
Internet-Draft Kerberos Extra AP October 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Error Recovery . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Number of Security Context Tokens . . . . . . . . . . . . 6
2.3. PROT_READY . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Negotiation Issues for User-to-User Authentication . . . . 7
3. ASN.1 for New Protocol Elements . . . . . . . . . . . . . 8
4. Replay Cache Avoidance . . . . . . . . . . . . . . . . . . 9
5. User-to-User Authentication . . . . . . . . . . . . . . . 10
6. Other Requirements, Recommendations, and
Non-Requirements . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
Williams & Dowdeswell Expires April 30, 2015 [Page 2]
Internet-Draft Kerberos Extra AP October 2014
1. Introduction
The Kerberos V5 [RFC4120] AP protocol, and therefore the Kerberos V5
GSS mechanism [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. 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. Additionally we add support for user-to-user
authentication and authenticated errors, and provide a way to avoid
the need for replay caching.
1.1. Conventions used in this document
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 [RFC2119].
Williams & Dowdeswell Expires April 30, 2015 [Page 3]
Internet-Draft Kerberos Extra AP October 2014
2. Negotiation
We introduce the following new protocol elements. A partial ASN.1
[CCITT.X680.2002] module (for inclusion in the base Kerberos ASN.1
module) is given in Section 3, and references to its contents are
made below.
o 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;
o a new Authorization-Data element for use in Authenticators for
quoting back a challenge nonce from the acceptor;
o a new PDU: KRB-ERROR2, with additional fields and support for
authenticated errors.
No new interface is needed for GSS-API applications to use this
feature.
To use this feature, the Kerberos GSS mechanism MUST act as follows:
o To request this feature, initiators SHALL add the new ap-options
flag to their AP-REQs.
o 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 one of the following keys: the
sub-session key from the AP-REQ's Authenticator if it could be
decrypted, else the session key from the Ticket, if it could be
decrypted, else the null enc-type/key.
o The KRB-ERROR2 in this case SHALL have a the continue-needed
e-flag set when the acceptor is willing to consume another
security context token from the initiator; the acceptor SHALL also
return GSS_S_CONTINUE_NEEDED to the application in this case.
o Initiators that request this feature and receive a KRB-ERROR2
SHOULD attempt to recover.
o Initiators that request this feature and receive a KRB-ERROR2 with
the continue-needed e-flag set SHOULD attempt to recover and MAY
produce a token to send to the acceptor: either a KRB-ERROR2 if
the initiator failed to recover, or a new AP-REQ (with the
traditional GSS-API pseudo-ASN.1 mechanism OID header).
* In the successful recovery case the initiator MUST quote the
nonce from the KRB-ERROR2 using an AD-CHALLENGE-RESPONSE-NONCE
Williams & Dowdeswell Expires April 30, 2015 [Page 4]
Internet-Draft Kerberos Extra AP October 2014
(see below) authorization data element.
o When it consumes a KRB-ERROR2, GSS_Init_sec_context() can return
an error (GSS_S_FAILURE), or attempt recovery and output a new AP-
REQ security context token.
* 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, else it SHALL
return GSS_S_COMPLETE.
* 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-ERROR to send to the acceptor.
o 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.
o Acceptors MUST reject initial security context tokens that contain
a challenge response nonce.
2.1. Error Recovery
The following Kerberos errors can be recovered from automatically
using this protocol:
o KRB_AP_ERR_TKT_EXPIRED: the initiator should get a new service
ticket;
o KRB_AP_ERR_TKT_NYV: the initiator should get a new service ticket;
o KRB_AP_ERR_REPEAT: the initiator should build a new AP-REQ;
o KRB_AP_ERR_SKEW: the initiator should build a new AP-REQ with time
corrected for the offset between the initiator's and acceptor's
clocks;
o KRB_AP_ERR_BADKEYVER: the initiator should get a new service
ticket;
o KRB_AP_PATH_NOT_ACCEPTED: the initiator should get a new service
ticket using a different transit path;
o KRB_AP_ERR_INAPP_CKSUM: the initiator should try again with a
different checksum type.
Error codes that denote PDU corruption (and/or an active attack) can
Williams & Dowdeswell Expires April 30, 2015 [Page 5]
Internet-Draft Kerberos Extra AP October 2014
also be recovered from by attempting a new AP-REQ:
o KRB_AP_ERR_BAD_INTEGRITY
o KRB_AP_ERR_BADVERSION
o KRB_AP_ERR_BADMATCH
o KRB_AP_ERR_MSG_TYPE
o KRB_AP_ERR_MODIFIED
Other error codes that may be recovered from:
o 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.
2.2. Number of Security Context Tokens
The first AP-REQ may well result in an error; the second 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).
Initiators and acceptors MUST impose some limit on the maximum number
of security context tokens. For the time being that limit is six.
An initiator that rejects an additional round trip MUST respond with
a KRB-ERROR2.
Note that in the user-to-user cases (see Section 5) 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
Section 4), or if the initiator's clock is too skewed, for example.
2.3. PROT_READY
It is REQUIRED that each AP-REQ in a security context token exchange
replace the sub-session key to be used for PROT_READY per-message
tokens. This can conceivably cause failure-to-verify/unwrap errors
for some applications (e.g., using datagram transports), but none
that they shouldn't have been prepared to handle.
Williams & Dowdeswell Expires April 30, 2015 [Page 6]
Internet-Draft Kerberos Extra AP October 2014
2.3.1. Negotiation Issues for User-to-User Authentication
Initiator applications that can negotiate security mechanisms and
which have available an existing user-to-user mechanism
[I-D.swift-win2k-krb-user2user] as well as the Kerberos V5 GSS
mechanism with the user-to-user extension defined here will have a
problem: they may end up negotiating the use of the Kerberos V5 GSS
mechanism and fail to establish a security context because the
acceptor does not support the features defined in this document, but
the application might have succeeded if it had selected the user-to-
user mechanism.
[[anchor1: Question: how should we address this? We could say "give
priority to the user-to-user mechanism", but in some cases that might
require changes to the acceptor side.]]
Williams & Dowdeswell Expires April 30, 2015 [Page 7]
Internet-Draft Kerberos Extra AP October 2014
3. ASN.1 for New Protocol Elements
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) [CCITT.X690.2002], and the environment is one of
explicit tagging.
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2)
-- continue-needed-ok(TBD)
ad-continue-nonce Int32 ::= <TBD>
-- ad-value is challenge nonce from KRB-ERROR2
KrbErrorEncPartFlags ::= KerberosFlags
-- reserved(0) [XXX cargo cult!]
-- use-initiator-subkey(1)
-- use-ticket-session-key(2)
-- use-null-enctype(3)
KRB-ERROR2 ::= [APPLICATION <TBD>] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (<TBD>),
enc-part-key [2] KrbErrorEncPartFlags,
enc-part [3] EncryptedData -- EncKRBErrorPart
}
ErrorFlags ::= KerberosFlags
-- reserved(0) [XXX sounds like cargo cult!]
-- continue-needed(1)
EncKRBErrorPart ::= [APPLICATION <TBD>] SEQUENCE {
challenge-nonce [0] OCTET STRING (16),
stime [1] KerberosTime,
susec [2] Microseconds,
error-code [3] Int32,
e-flags [4] ErrorFlags,
e-text [5] KerberosString OPTIONAL,
e-data [6] OCTET STRING OPTIONAL,
e-typed-data [7] TYPED-DATA OPTIONAL,
tgt [8] Ticket OPTIONAL, -- for user2user
...
}
Figure 1: ASN.1 module (with explicit tagging)
Williams & Dowdeswell Expires April 30, 2015 [Page 8]
Internet-Draft Kerberos Extra AP October 2014
4. Replay Cache Avoidance
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.
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.
Williams & Dowdeswell Expires April 30, 2015 [Page 9]
Internet-Draft Kerberos Extra AP October 2014
5. User-to-User Authentication
There are two user2user authentication cases:
1. the KDC only allows a service principal to use user2user
authentication,
2. 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.
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 an AP-REQ or fail to make even an
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.
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.
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.
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.
Williams & Dowdeswell Expires April 30, 2015 [Page 10]
Internet-Draft Kerberos Extra AP October 2014
6. Other Requirements, Recommendations, and Non-Requirements
All error PDUs in an AP exchange where the AP-REQ has the continue-
needed-ok ap-options flag MUST be KRB-ERROR2 PDUs.
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).
Williams & Dowdeswell Expires April 30, 2015 [Page 11]
Internet-Draft Kerberos Extra AP October 2014
7. Security Considerations
This document deals with security.
There are a number of unauthenticated protocol elements: the
continue-needed-ok flag that the initiator uses to indicate its
willingness to have more than one round trip, and some errors. This
is unavoidable.
The new KRB-ERROR2 PDU is cryptographically distinguished from the
original mechanism's acceptor success security context token (AP-
REQ).
Not every KRB-ERROR2 can be integrity protected.
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.
Williams & Dowdeswell Expires April 30, 2015 [Page 12]
Internet-Draft Kerberos Extra AP October 2014
8. IANA Considerations
[[anchor2: Various allocations are required...]]
Williams & Dowdeswell Expires April 30, 2015 [Page 13]
Internet-Draft Kerberos Extra AP October 2014
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[CCITT.X680.2002]
International Telephone and Telegraph Consultative
Committee, "Abstract Syntax Notation One (ASN.1):
Specification of basic notation", CCITT Recommendation
X.680, July 2002.
[CCITT.X690.2002]
International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002.
9.2. Informative References
[I-D.swift-win2k-krb-user2user]
Swift, M., Brezak, J., and P. Moore, "User to User
Kerberos Authentication using GSS-API",
draft-swift-win2k-krb-user2user-03 (work in progress),
February 2011.
Williams & Dowdeswell Expires April 30, 2015 [Page 14]
Internet-Draft Kerberos Extra AP October 2014
Authors' Addresses
Nicolas Williams
Cryptonector, LLC
Email: nico@cryptonector.com
Roland Charles Dowdeswell
Dowdeswell Security Architecture
Email: elric@imrryr.org
Williams & Dowdeswell Expires April 30, 2015 [Page 15]