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-03

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 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

The Kerberos V5 [RFC4120] AP protocol, and therefore the Kerberos V5 GSS-API [RFC2743] 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].

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.

No new interface is needed for GSS-API applications to use this feature. 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()).

To use this feature, the Kerberos GSS mechanism MUST act as follows:

[CREF1]Perhaps we should use a checksum 0x8003 [RFC4121] extension instead of authorization data in the authenticator.

2.1. Error Recovery

The following Kerberos errors can be recovered from automatically using this protocol:

Error codes that denote PDU corruption (and/or an active attack) can also be recovered from by attempting a new AP-REQ:

Other error codes that may be recovered from:

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.2.1. Security Token Sequences

The following successful security context token exchange sequences are possible:

2.3. PROT_READY

It is REQUIRED that each AP-REQ in a security context token exchange assert an initiator sub-session key, possibly different from preceding AP-REQs in the same exchange. Each AP-REQ's initiator sub-session key in a security context token exchange MUST 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.

2.4. Per-Message Token Sequence Numbers

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.

2.4.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.

[CREF2]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.

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)

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.

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.

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).

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.

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.

[CREF3]We could use the GSS_EXTS_FINISHED extension from draft-ietf-kitten-iakerb to implement a strong binding of all context tokens.

8. IANA Considerations

[CREF4]Various allocations are required...

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.
[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", Internet-Draft draft-swift-win2k-krb-user2user-03, February 2011.

Authors' Addresses

Nicolas Williams Cryptonector, LLC EMail: nico@cryptonector.com
Roland Charles Dowdeswell Dowdeswell Security Architecture EMail: elric@imrryr.org