Negotiation of Extra Round Trip for Kerberos V5 Generic Security Services Mechanism
draft-williams-kitten-krb5-extra-rt-00

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 an extra pair of security context tokens in order to recover from certain errors. Other benefits include: user2user authentication, authenticated errors (in some cases), and more.

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 August 5, 2013.

Copyright Notice

Copyright (c) 2013 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
• 1.1. Conventions used in this document
• 2. Negotiation
• 2.1. Use in Non-GSS Applications
• 2.2. Number of Round Trips
• 2.3. User-to-User Authentication
• 2.4. ASN.1 for New Protocol Elements
• 2.5. Other Features
• 2.5.1. Acceptor Name Redirection
• 2.5.2. Fast Re-Authentication Acceptor Ticket Issuance
• 2.6. Replay Cache Avoidance
• 2.7. Other Requirements, Recommendations, and Non-Requirements
• 3. Security Considerations
• 4. IANA Considerations
• 5. Informative References
• 6. Normative References
• Authors' Addresses

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 an additional round trip 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 user2user authentication and authenticated errors, and provide a way to avoid the use of 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. An ASN.1 module is given in Section 2.4, and references to its contents are made below.

• a new ap-options flag for use in the cleartext part of AP-REQs to indicate the desire for an extra round trip if need be;
• a new Authorization-Data element for use in Authenticators to also indicate the desire for an extra round trip if need be;
• a new Authorization-Data element for use in Authenticators for quoting back a challenge nonce from the acceptor;
• a new PDU: KRB-ERROR2, with additional fields and support for authenticated errors.

To use this feature, initiators and acceptors MUST act as follows:

• To request this feature, initiators SHALL add the new authorization-data element (in an AD-IF-RELEVANT container) with empty ad-value to their Authenticators, and they SHALL add the new ap-options flag to their AP-REQs.
• Acceptors that wish to request an additional round trip SHOULD do so when initiators indicate support for it, and 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, the session key from the Ticket, if it could be decrypted, or the null enctype and null key. The KRB-ERROR2 in this case SHALL have a the continue-needed e-flag set. The acceptor SHALL also return GSS_S_CONTINUE_NEEDED to the application.
• Initiators that request this feature and receive a KRB-ERROR2 SHALL attempt to recover.
• Initiators that request this feature and receive a KRB-ERROR2 with the ke-continue-needed e-flag set MUST attempt to recover and MUST 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 (see below) authorization data element, and this MUST NOT be wrapped in an AD-IF-RELEVANT container.

• Initiators that support this feature and successfully recover from a KRB-ERROR or KRB-ERROR2 SHALL return GSS_S_CONTINUE_NEEDED. Otherwise they MUST generate a KRB-ERROR to send to the acceptor and return an error to the application.

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

• KRB_AP_ERR_TKT_EXPIRED: the initiator should get a new service ticket
• KRB_AP_ERR_TKT_NYV: the initiator should get a new service ticket
• KRB_AP_ERR_REPEAT: the initiator should build a new AP-REQ
• 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
• KRB_AP_ERR_BADKEYVER: the initiator should get a new service ticket
• KRB_AP_PATH_NOT_ACCEPTED: the initiator should get a new service ticket using a different transit path

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

• KRB_AP_ERR_BAD_INTEGRITY
• KRB_AP_ERR_BADVERSION
• KRB_AP_ERR_BADMATCH
• KRB_AP_ERR_MSG_TYPE
• KRB_AP_ERR_MODIFIED

Other error codes that may be recovered from:

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

It is also possible for an acceptor to request that the initiator re-authenticate but to a different service principal, in which case the error code SHALL be KRB_AP_ERR_NOT_US, the KRB-ERROR2 encrypted part MUST be encrypted in the sub-session key from the Authenticator, and the sname and realm fields of the KRB-ERROR2 MUST be present.

2.1. Use in Non-GSS Applications

We only specify multiple round trips for the GSS mechanism and application case. We believe that some non-GSS Kerberos applications may also benefit from this extension.

2.2. Number of Round Trips

At most two round trips should be needed in general. Implementations MUST impose a limit of either two or three round trips. An initiator that rejects an additional round-trip MUST respond with a KRB-ERROR2.

2.3. 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 invalid ticket (really, the enc-part of the Ticket will contain some OCTET STRING of length 1 or longer, but no longer than the minimum ciphertext length for the enctype listed in the EncryptedData) and authenticator (an OCTET STRING of length 1 or longer, but no longer than the minimum ciphertext length for some enctype supported by the initiator). The acceptor will fail to process the AP-REQ, of course, both because the Ticket and Authenticator embedded in it are not valid, and because the acceptor will likely not possess the key to decrypt a real Ticket. The acceptor SHOULD respond with a continue-needed KRB-ERROR2 (using the null enctype 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 this case the acceptor responds with a KRB-ERROR2, using either the null enctype for the enc-part, or the initiator's sub-session key, and includes 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.

2.4. ASN.1 for New Protocol Elements

An ASN.1 module appears below.

 APOptions       ::= KerberosFlags
         – reserved(0),
         – use-session-key(1),
         – mutual-required(2) 
         – continue-needed-ok(TBD)
 
 ad-continue-needed-ok Int32 ::= <TBD>
        – indicate extra round trip support 
 ad-continue-nonce     Int32 ::= <TBD>
        – ad-value is challenge nonce from KRB-ERROR2
 td-continue-needed    Int32 ::= <TBD>
        – indicate that extra round trip is expected
 td-continue-failed    Int32 ::= <TBD>
        – indicate protocol failure
 
 KrbErrorEncPartFlags ::= KerberosFlags
         – reserved(0)  [XXX sounds like 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)
         – use-other-sname(2)
         – user2user(3)
 
 EncAPRepPart    ::= [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,
         caddrs          [8] HostAddresses OPTIONAL,
         saddrs          [9] HostAddresses OPTIONAL,
         tgt            [10] Ticket OPTIONAL, – for user2user
         ticket         [11] Ticket OPTIONAL, – fast-re-auth
         srealm         [12] Realm OPTIONAL,  – service realm
         sname          [13] PrincipalName OPTIONAL,
         redir-srealm   [14] Realm OPTIONAL,
         redir-sname    [15] PrincipalName OPTIONAL,
}