1INTERNET-DRAFT Jonathan Trostle 2draft-ietf-cat-kerberos-extra-tgt-02.txt Cisco Systems 3Updates: RFC 1510 Michael M. Swift 4expires January 30, 2000 University of WA 5 6 7 Extension to Kerberos V5 For Additional Initial Encryption 8 90. Status Of This Memo 10 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 13 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 18 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 24 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 30 311. Abstract 32 33 This document defines an extension to the Kerberos protocol 34 specification (RFC 1510) [1] to enable a preauthentication field in 35 the AS_REQ message to carry a ticket granting ticket. The session 36 key from this ticket granting ticket will be used to 37 cryptographically strengthen the initial exchange in either the 38 conventional Kerberos V5 case or in the case the user stores their 39 encrypted private key on the KDC [2]. 40 41 422. Motivation 43 44 In Kerberos V5, the initial exchange with the KDC consists of the 45 AS_REQ and AS_REP messages. For users, the encrypted part of the 46 AS_REP message is encrypted in a key derived from a password. 47 Although a password policy may be in place to prevent dictionary 48 attacks, brute force attacks may still be a concern due to 49 insufficient key length. 50 51 This draft specifies an extension to the Kerberos V5 protocol to 52 allow a ticket granting ticket to be included in an AS_REQ message 53 preauthentication field. The session key from this ticket granting 54 ticket will be used to cryptographically strengthen the initial 55 56 exchange in either the conventional Kerberos V5 case or in the case 57 the user stores their encrypted private key on the KDC [2]. The 58 session key from the ticket granting ticket is combined with the 59 user password key (key K2 in the encrypted private key on KDC 60 option) using HMAC to obtain a new triple des key that is used in 61 place of the user key in the initial exchange. The ticket granting 62 ticket could be obtained by the workstation using its host key. 63 643. The Extension 65 66 The following new preauthentication type is proposed: 67 68 PA-EXTRA-TGT 22 69 70 The preauthentication-data field contains a ticket granting ticket 71 encoded as an ASN.1 octet string. The server realm of the ticket 72 granting ticket must be equal to the realm in the KDC-REQ-BODY of 73 the AS_REQ message. In the absence of a trust relationship, the 74 local Kerberos client should send the AS_REQ message without this 75 extension. 76 77 In the conventional (non-pkinit) case, we require the RFC 1510 78 PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message. 79 If neither it or the PA-PK-KEY-REQ preauthentication field is 80 included in the AS_REQ message, the KDC will reply with a 81 KDC_ERR_PREAUTH_FAILED error message. 82 83 We propose the following new etypes: 84 85 des3-cbc-md5-xor 16 86 des3-cbc-sha1-xor 17 87 88 The encryption key is obtained by: 89 90 (1) Obtaining an output M from the HMAC-SHA1 function [3] using 91 the user password key (the key K2 in the encrypted private 92 key on KDC option of pkinit) as the text and the triple des 93 session key as the K input in HMAC: 94 95 M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1. 96 97 The session key from the accompanying ticket granting ticket 98 must be a triple des key when one of the triple des xor 99 encryption types is used. 100 (2) Concatenate the output M (20 bytes) with the first 8 non-parity 101 bits of the triple-des ticket granting ticket session key to 102 get 168 bits that will be used for the new triple-des encryption 103 key. 104 (3) Set the parity bits of the resulting key. 105 106 The resulting triple des key is used to encrypt the timestamp 107 for the PA-ENC-TIMESTAMP preauthentication value (or in the 108 encrypted private key on KDC option of pkinit, it is used in 109 place of the key K2 to both sign in the PA-PK-KEY-REQ and for 110 encryption in the PA-PK-KEY-REP preauthentication types). 111 112 If the KDC decrypts the encrypted timestamp and it is not within 113 the appropriate clock skew period, the KDC will reply with the 114 KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if 115 the above ticket granting ticket fails to decrypt properly, or if 116 it is not a valid ticket. 117 118 The KDC will create the shared triple des key from the ticket 119 granting ticket session key and the user password key (the key K2 120 in the encrypted private key on KDC case) using HMAC as specified 121 above and use it to validate the AS_REQ message and then to 122 encrypt the encrypted part of the AS_REP message (use it in place 123 of the key K2 for encryption in the PA-PK-KEY-REP preauthentication 124 field). 125 126 Local workstation policy will determine the exact behaviour of 127 the Kerberos client with respect to the extension protocol. For 128 example, the client should consult policy to decide when to use 129 use the extension. This policy could be dependent on the user 130 identity, or whether the workstation is in the same realm as the 131 user. One possibility is for the workstation logon to fail if 132 the extension is not used. Another possibility is for the KDC 133 to set a flag in tickets issued when this extension is used. 134 135 A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a 136 preauthentication field containing a ticket granting ticket, 137 a randomly generated subkey encrypted in the session key from 138 the ticket, and a timestamp structure encrypted in the user 139 password and then the randomly generated subkey was proposed. 140 Some advantages of the current proposal are that the KDC has two 141 fewer decryptions to perform per request and the client does not 142 have to generate a random key. 143 1444. Bibliography 145 146 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 147 Service (V5). Request for Comments 1510. 148 149 [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle. 150 Public Key Cryptography for Initial Authentication in Kerberos. 151 ftp://ds.internic.net/internet-drafts/ 152 draft-ietf-cat-kerberos-pkinit-08.txt 153 154 [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for 155 Message Authentication. Request for Comments 2104. 156 157 [4] J. Pato. Using Pre-authentication to Avoid Password Guessing 158 Attacks. OSF DCE SIG Request for Comments 26.0. 159 1605. Acknowledgement: We thank Ken Hornstein for some helpful comments. 161 1626. Expires January 30, 2000. 163 1647. Authors' Addresses 165 166 Jonathan Trostle 167 170 W. Tasman Dr. 168 San Jose, CA 95134, U.S.A. 169 170 Email: jtrostle@cisco.com 171 Phone: (408) 527-6201 172 173 Michael Swift 174 Email: mikesw@cs.washington.edu 175