idnits 2.17.1 draft-ietf-kitten-pkinit-freshness-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4556]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2016) is 2983 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 224 -- Looks like a reference, but probably isn't: '1' on line 225 -- Looks like a reference, but probably isn't: '2' on line 228 -- Looks like a reference, but probably isn't: '3' on line 231 -- Looks like a reference, but probably isn't: '4' on line 236 == Missing Reference: 'This RFC' is mentioned on line 261, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5349 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kitten Working Group M. Short, Ed. 3 Internet-Draft S. Moore 4 Intended status: Standards Track P. Miller 5 Expires: August 27, 2016 Microsoft Corporation 6 February 24, 2016 8 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) 9 Freshness Extension 10 draft-ietf-kitten-pkinit-freshness-03 12 Abstract 14 This document describes how to further extend the Public Key 15 Cryptography for Initial Authentication in Kerberos (PKINIT) 16 extension [RFC4556] to exchange an opaque data blob that a KDC can 17 validate to ensure that the client is currently in possession of the 18 private key during a PKINIT AS exchange. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 27, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Kerberos message flow using KRB_AS_REQ without pre- 56 authentication . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Generation of KRB_AS_REQ Message . . . . . . . . . . . . 4 60 2.2. Generation of KRB_ERROR Message . . . . . . . . . . . . . 4 61 2.3. Generation of KRB_AS_REQ Message . . . . . . . . . . . . 4 62 2.4. Receipt of KRB_AS_REQ Message . . . . . . . . . . . . . . 4 63 2.5. Receipt of second KRB_ERROR Message . . . . . . . . . . . 5 64 3. PreAuthentication Data Types . . . . . . . . . . . . . . . . 5 65 4. Extended PKAuthenticator . . . . . . . . . . . . . . . . . . 5 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. Interoperability Considerations . . . . . . . . . . . . . . . 7 70 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The Kerberos PKINIT extension [RFC4556] defines two schemes for using 76 asymmetric cryptography in a Kerberos preauthenticator. One uses 77 Diffie-Hellman key exchange and the other depends on public key 78 encryption. The public key encryption scheme is less commonly used 79 for two reasons: 81 o Elliptic Curve Cryptography (ECC) Support for PKINIT [RFC5349] 82 only specified Elliptic Curve Diffie-Hellman (ECDH) key agreement, 83 so it cannot be used for public key encryption. 85 o Public key encryption requires certificates with an encryption 86 key, that is not deployed on many existing smart cards. 88 In the Diffie-Hellman exchange, the client uses its private key only 89 to sign the AuthPack structure (specified in Section 3.2.1 of 90 [RFC4556]), that is performed before any traffic is sent to the KDC. 91 Thus a client can generate requests with future times in the 92 PKAuthenticator, and then send those requests at those future times. 93 Unless the time is outside the validity period of the client's 94 certificate, the KDC will validate the PKAuthenticator and return a 95 TGT the client can use without possessing the private key. 97 As a result, a client performing PKINIT with the Diffie-Hellman key 98 exchange does not prove current possession of the private key being 99 used for authentication. It proves only prior use of that key. 100 Ensuring that the client has current possession of the private key 101 requires that the signed PKAuthenticator data include information 102 that the client could not have predicted. 104 1.1. Kerberos message flow using KRB_AS_REQ without pre-authentication 106 Today, password-based AS exchanges [RFC4120] often begin with the 107 client sending a KRB_AS_REQ without pre-authentication. When the 108 principal requires pre-authentication, the KDC responds with a 109 KRB_ERROR containing information needed to complete an AS exchange, 110 such as the supported encryption types and salt values. This message 111 flow is illustrated below: 113 KDC Client 115 <---- AS-REQ without pre-authentication 116 KRB-ERROR ----> 118 <---- AS-REQ 119 AS-REP ----> 121 <---- TGS-REQ 122 TGS-REP ----> 124 Figure 1 126 We can use a similar message flow with PKINIT, allowing the KDC to 127 provide a token for the client to include in its KRB_AS_REQ to ensure 128 that the PA_PK_AS_REQ [RFC4556] was not pregenerated. 130 1.2. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 2. Message Exchanges 138 The following summarizes the message flow with extensions to 139 [RFC4120] and [RFC4556] required to support a KDC-provided freshness 140 token during the initial request for a ticket: 142 1. The client generates a KRB_AS_REQ as specified in Section 2.9.3 143 [RFC4120] that contains no PA_PK_AS_REQ and includes a freshness 144 token request. 146 2. The KDC generates a KRB_ERROR as specified in Section 3.1.3 of 147 [RFC4120] providing a freshness token. 149 3. The client receives the error as specified in Section 3.1.4 of 150 [RFC4120], extracts the freshness token, and includes it as part 151 of the KRB_AS_REQ as specified in [RFC4120] and [RFC4556]. 153 4. The KDC receives and validates the KRB_AS_REQ as specified in 154 Section 3.2.2 [RFC4556], then additionally validates the 155 freshness token. 157 5. The KDC and client continue as specified in [RFC4120] and 158 [RFC4556]. 160 2.1. Generation of KRB_AS_REQ Message 162 The client indicates support of freshness tokens by adding a padata 163 element with padata-type PA_AS_FRESHNESS and padata-value of an empty 164 octet string. 166 2.2. Generation of KRB_ERROR Message 168 The KDC will respond with a KRB_ERROR [RFC4120] message with the 169 error-code KDC_ERR_PREAUTH_REQUIRED [RFC4120] and adding a padata 170 element with padata-type PA_AS_FRESHNESS and padata-value of the 171 freshness token to the METHOD-DATA object. 173 2.3. Generation of KRB_AS_REQ Message 175 After the client receives the KRB-ERROR message containing a 176 freshness token, it extracts the PA_AS_FRESHNESS padata-value field 177 of the PA-DATA structure as an opaque data blob. The PA_AS_FRESHNESS 178 padata-value field of the PA-DATA structure SHALL then be added as an 179 opaque blob in the freshnessToken field when the client generates the 180 PKAuthenticator for the PA_PK_AS_REQ message. This ensures that the 181 freshness token value will be included in the signed data portion of 182 the KRB_AS_REQ value. 184 2.4. Receipt of KRB_AS_REQ Message 186 If the realm requires freshness and the PA_PK_AS_REQ message does not 187 contain the freshness token, the KDC MUST return a KRB_ERROR 188 [RFC4120] message with the error-code KDC_ERR_PREAUTH_REQUIRED 189 [RFC4120] with a padata element with padata-type PA_AS_FRESHNESS and 190 padata-value of the freshness token to the METHOD-DATA object. 192 When the PA_PK_AS_REQ message contains a freshness token, after 193 validating the PA_PK_AS_REQ message normally, the KDC will validate 194 the freshnessToken value in the PKAuthenticator in an implementation- 195 specific way. If the freshness token is not valid, the KDC MUST 196 return a KRB_ERROR [RFC4120] message with the error-code 197 KDC_ERR_PREAUTH_EXPIRED [RFC6113]. The e-data field of the error 198 contains a METHOD-DATA object [RFC4120] which specifies a valid 199 PA_AS_FRESHNESS padata-value. Since the freshness tokens are 200 validated by KDCs in the same realm, standardizing the contents of 201 the freshness token is not a concern for interoperability. 203 2.5. Receipt of second KRB_ERROR Message 205 If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that 206 includes a freshness token, it MUST retry using the new freshness 207 token. 209 3. PreAuthentication Data Types 211 The following are the new PreAuthentication data types: 213 +----------------------+-------------------+ 214 | Padata and Data Type | Padata-type Value | 215 +----------------------+-------------------+ 216 | PA_AS_FRESHNESS | TBD | 217 +----------------------+-------------------+ 219 4. Extended PKAuthenticator 220 The PKAuthenticator structure specified in Section 3.2.1 [RFC4556] is 221 extended to include a new freshnessToken as follows: 223 PKAuthenticator ::= SEQUENCE { 224 cusec [0] INTEGER (0..999999), 225 ctime [1] KerberosTime, 226 -- cusec and ctime are used as in [RFC4120], for 227 -- replay prevention. 228 nonce [2] INTEGER (0..4294967295), 229 -- Chosen randomly; this nonce does not need to 230 -- match with the nonce in the KDC-REQ-BODY. 231 paChecksum [3] OCTET STRING OPTIONAL, 232 -- MUST be present. 233 -- Contains the SHA1 checksum, performed over 234 -- KDC-REQ-BODY. 235 ..., 236 freshnessToken [4] OCTET STRING OPTIONAL, 237 -- PA_AS_FRESHNESS padata value as recieved from the 238 -- KDC. MUST be present if sent by KDC 239 ... 240 } 242 5. Acknowledgements 244 Douglas E. Engert, Sam Hartman, Henry B. Hotz, Nikos 245 Mavrogiannopoulos, Martin Rex, Nico Williams, and Tom Yu were key 246 contributors to the discovery of the freshness issue in PKINIT. 248 Sam Hartman, Greg Hudson, Jeffrey Hutzelman, Nathan Ide, Benjamin 249 Kaduk, Bryce Nordgren, Magnus Nystrom, Nico Williams and Tom Yu 250 reviewed the document and provided suggestions for improvements. 252 6. IANA Considerations 254 IANA is requested to assign numbers for PA_AS_FRESHNESS listed in the 255 Kerberos Parameters registry Pre-authentication and Typed Data as 256 follows: 258 +------+-----------------+------------+ 259 | Type | Value | Reference | 260 +------+-----------------+------------+ 261 | TBD | PA_AS_FRESHNESS | [This RFC] | 262 +------+-----------------+------------+ 264 7. Security Considerations 266 The freshness token SHOULD include signing, encrypting or sealing 267 data from the KDC to determine authenticity and prevent tampering. 269 Freshness tokens serve to guarantee that the client had the key when 270 constructing the AS-REQ. They are not required to be single use 271 tokens or bound to specific AS exchanges. Part of the reason the 272 token is opaque is to allow KDC implementers the freedom to add 273 additional functionality as long as the "freshness" guarantee 274 remains. 276 8. Interoperability Considerations 278 Since the client treats the KDC provided data blob as opaque, 279 changing the contents will not impact existing clients. Thus 280 extensions to the freshness token do not impact client 281 interoperability. 283 Clients SHOULD NOT reuse freshness tokens across multiple exchanges. 284 There is no guarantee that a KDC will allow a once-valid token to be 285 used again. Thus clients that do not retry with a new freshness 286 token may not be compatible with KDCs depending on how they choose to 287 implement "freshness" validation. 289 Since upgrading clients takes time, implementers may consider 290 allowing both freshness-token based exchanges as well as "legacy" 291 exchanges without use of freshness tokens. However, until freshness 292 tokens are required by the realm, existing risks of pre-generated 293 PKAuthenticators will remain. 295 9. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 303 Kerberos Network Authentication Service (V5)", RFC 4120, 304 DOI 10.17487/RFC4120, July 2005, 305 . 307 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 308 Authentication in Kerberos (PKINIT)", RFC 4556, 309 DOI 10.17487/RFC4556, June 2006, 310 . 312 [RFC5349] Zhu, L., Jaganathan, K., and K. Lauter, "Elliptic Curve 313 Cryptography (ECC) Support for Public Key Cryptography for 314 Initial Authentication in Kerberos (PKINIT)", RFC 5349, 315 DOI 10.17487/RFC5349, September 2008, 316 . 318 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 319 Kerberos Pre-Authentication", RFC 6113, 320 DOI 10.17487/RFC6113, April 2011, 321 . 323 Authors' Addresses 325 Michiko Short (editor) 326 Microsoft Corporation 327 USA 329 Email: michikos@microsoft.com 331 Seth Moore 332 Microsoft Corporation 333 USA 335 Email: sethmo@microsoft.com 337 Paul Miller 338 Microsoft Corporation 339 USA 341 Email: paumil@microsoft.com