Network Working Group N. Williams Internet-Draft Cryptonector Updates: RFC4121 (if approved) R. Dowdeswell Intended status: Standards Track Dowdeswell Security Architecture Expires: August 18, 2013 February 14, 2013 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 18, 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 Williams & Dowdeswell Expires August 18, 2013 [Page 1] Internet-Draft Kerberos Extra AP February 2013 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. Use in Non-GSS Applications . . . . . . . . . . . . . . . 6 2.2. Number of Round Trips . . . . . . . . . . . . . . . . . . 6 2.3. User-to-User Authentication . . . . . . . . . . . . . . . 6 2.4. ASN.1 for New Protocol Elements . . . . . . . . . . . . . 7 2.5. Other Features . . . . . . . . . . . . . . . . . . . . . . 8 2.5.1. Acceptor Name Redirection . . . . . . . . . . . . . . . . 8 2.5.2. Fast Re-Authentication Acceptor Ticket Issuance . . . . . 8 2.6. Replay Cache Avoidance . . . . . . . . . . . . . . . . . . 9 2.7. Other Requirements, Recommendations, and Non-Requirements . . . . . . . . . . . . . . . . . . . . . 9 3. Security Considerations . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 5. Informative References . . . . . . . . . . . . . . . . . . 12 6. Normative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 Williams & Dowdeswell Expires August 18, 2013 [Page 2] Internet-Draft Kerberos Extra AP February 2013 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]. Williams & Dowdeswell Expires August 18, 2013 [Page 3] Internet-Draft Kerberos Extra AP February 2013 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. o 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; o a new Authorization-Data element for use in Authenticators to also 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. To use this feature, initiators and acceptors MUST act as follows: o 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. o 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. o Initiators that request this feature and receive a KRB-ERROR2 SHALL attempt to recover. o 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. Williams & Dowdeswell Expires August 18, 2013 [Page 4] Internet-Draft Kerberos Extra AP February 2013 o 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: 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 Error codes that denote PDU corruption (and/or an active attack) can 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. 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 Williams & Dowdeswell Expires August 18, 2013 [Page 5] Internet-Draft Kerberos Extra AP February 2013 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. Williams & Dowdeswell Expires August 18, 2013 [Page 6] Internet-Draft Kerberos Extra AP February 2013 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 ::= - indicate extra round trip support ad-continue-nonce Int32 ::= - ad-value is challenge nonce from KRB-ERROR2 td-continue-needed Int32 ::= - indicate that extra round trip is expected td-continue-failed Int32 ::= - 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 ] SEQUENCE { pvno [0] INTEGER (5), msg-type [1] INTEGER (), 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 ] SEQUENCE { challenge-nonce [0] OCTET STRING (16), stime [1] KerberosTime, susec [2] Microseconds, error-code [3] Int32, e-flags [4] ErrorFlags, Williams & Dowdeswell Expires August 18, 2013 [Page 7] Internet-Draft Kerberos Extra AP February 2013 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, } Figure 1: ASN.1 module (with explicit tagging) 2.5. Other Features Two other features are supported: o acceptor name redirection; o acceptor-issued service ticket (for the same acceptor name) issuance. 2.5.1. Acceptor Name Redirection In some use cases, such as clusters, for example, an acceptor may wish to ask the initiator to use a different name (and ticket) for the acceptor. This is indicated by setting the redir-srealm and redir-sname fields of a continue-needed KRB-ERROR2. The KRB-ERROR2's enc-part MUST be encrypted in the initiator's sub-session key, and initiators MUST ignore the redir-srealm and redir-sname fields of any KRB-ERROR2 where the enc-part is encrypted in the null enctype. Because the acceptor's name redirection is authenticated to the initiator, it is safe for the initiator to get a service ticket for the new name and re-try authentication with it. 2.5.2. Fast Re-Authentication Acceptor Ticket Issuance In view of future extensions where the Kerberos AP protocol may be extended to use public key agreement protocols -which will likely be slow-, we provide a field in the KRB-ERROR2 where the acceptor may include a Ticket for itself, minted by the acceptor using a secret key of its choosing. This service ticket may be used to speed up future otherwise-slow AP exchanges. Williams & Dowdeswell Expires August 18, 2013 [Page 8] Internet-Draft Kerberos Extra AP February 2013 2.6. Replay Cache Avoidance By using an additional round trip and a challenge/response nonce, this protocol is inmune to replays of AP-REQ PDUs. Acceptor implementations MAY not enter 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. By the same token, acceptors that support this feature MUST reject initial security context tokens that contain a challenge response nonce. 2.7. 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 AP-REQ) or the Ticket's session key (if the acceptor could not decrypt the Authenticator), and the srealm and sname fields MUST be set to be the same as the realm and sname fields from the Ticket. Whenever an initiator receives a KRB-ERROR2 with enc-part encrypted in either the initiator's sub-session key or the Ticket's session key, then the initiator SHOULD check that the srealm and sname fields of the KRB-ERROR2 encrypted part match the ones used in the initiator's AP-REQ's Ticket (XXX what should the initiator do if these don't match?!). ... Williams & Dowdeswell Expires August 18, 2013 [Page 9] Internet-Draft Kerberos Extra AP February 2013 3. Security Considerations This document deals with security. [XXX Note the resource using attacks that are feasible when we have multiple round-trips and note that they are nothing new and nothing to worry about because services should already have timeouts on pre- authenticated protocol phases, and even post-authentication.] Williams & Dowdeswell Expires August 18, 2013 [Page 10] Internet-Draft Kerberos Extra AP February 2013 4. IANA Considerations This document has no IANA considerations. Williams & Dowdeswell Expires August 18, 2013 [Page 11] Internet-Draft Kerberos Extra AP February 2013 5. Informative References Williams & Dowdeswell Expires August 18, 2013 [Page 12] Internet-Draft Kerberos Extra AP February 2013 6. 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. Williams & Dowdeswell Expires August 18, 2013 [Page 13] Internet-Draft Kerberos Extra AP February 2013 Authors' Addresses Nicolas Williams Cryptonector, LLC Email: nico@cryptonector.com Roland Charles Dowdeswell Dowdeswell Security Architecture Email: elric@imrryr.org Williams & Dowdeswell Expires August 18, 2013 [Page 14]