idnits 2.17.1 draft-ietf-kitten-pkinit-freshness-02.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 (December 11, 2015) is 3052 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 215 -- Looks like a reference, but probably isn't: '1' on line 216 -- Looks like a reference, but probably isn't: '2' on line 219 -- Looks like a reference, but probably isn't: '3' on line 222 -- Looks like a reference, but probably isn't: '4' on line 227 == Missing Reference: 'This RFC' is mentioned on line 252, 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: June 13, 2016 Microsoft Corporation 6 December 11, 2015 8 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) 9 Freshness Extension 10 draft-ietf-kitten-pkinit-freshness-02 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 June 13, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. Interoperability Considerations . . . . . . . . . . . . . . . 6 70 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 by adding a padata element with padata-type 169 PA_AS_FRESHNESS and padata-value of the freshness token to the 170 METHOD-DATA object. 172 2.3. Generation of KRB_AS_REQ Message 174 After the client receives the KRB-ERROR message containing a 175 freshness token, it extracts the PA_AS_FRESHNESS padata-value field 176 of the PA-DATA structure as an opaque data blob. The PA_AS_FRESHNESS 177 padata-value field of the PA-DATA structure SHALL then be added as an 178 opaque blob in the freshnessToken field when the client generates the 179 PKAuthenticator for the PA_PK_AS_REQ message. This ensures that the 180 freshness token value will be included in the signed data portion of 181 the KRB_AS_REQ value. 183 2.4. Receipt of KRB_AS_REQ Message 185 After validating the PA_PK_AS_REQ message normally, the KDC will 186 validate the freshnessToken value in the PKAuthenticator in an 187 implementation-specific way. If the freshness token is not valid, 188 the KDC MUST return KDC_ERR_PREAUTH_EXPIRED [RFC6113] with 189 PA_AS_FRESHNESS. Since the freshness tokens are validated by KDCs in 190 the same realm, standardizing the contents of the freshness token is 191 not a concern for interoperability. 193 2.5. Receipt of second KRB_ERROR Message 195 If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that 196 includes a freshness token, it MUST retry using the new freshness 197 token. 199 3. PreAuthentication Data Types 201 The following are the new PreAuthentication data types: 203 +----------------------+-------------------+ 204 | Padata and Data Type | Padata-type Value | 205 +----------------------+-------------------+ 206 | PA_AS_FRESHNESS | TBD | 207 +----------------------+-------------------+ 209 4. Extended PKAuthenticator 211 The PKAuthenticator structure specified in Section 3.2.1 [RFC4556] is 212 extended to include a new freshnessToken as follows: 214 PKAuthenticator ::= SEQUENCE { 215 cusec [0] INTEGER (0..999999), 216 ctime [1] KerberosTime, 217 -- cusec and ctime are used as in [RFC4120], for 218 -- replay prevention. 219 nonce [2] INTEGER (0..4294967295), 220 -- Chosen randomly; this nonce does not need to 221 -- match with the nonce in the KDC-REQ-BODY. 222 paChecksum [3] OCTET STRING OPTIONAL, 223 -- MUST be present. 224 -- Contains the SHA1 checksum, performed over 225 -- KDC-REQ-BODY. 226 ..., 227 freshnessToken [4] OCTET STRING OPTIONAL, 228 -- PA_AS_FRESHNESS padata value as recieved from the 229 -- KDC. MUST be present if sent by KDC 230 ... 231 } 233 5. Acknowledgements 235 Douglas E. Engert, Sam Hartman, Henry B. Hotz, Nikos 236 Mavrogiannopoulos, Martin Rex, Nico Williams, and Tom Yu were key 237 contributors to the discovery of the freshness issue in PKINIT. 239 Sam Hartman,Greg Hudson, Jeffrey Hutzelman, Nathan Ide, Benjamin 240 Kaduk, Bryce Nordgren, Magnus Nystrom, Nico Williams and Tom Yu 241 reviewed the document and provided suggestions for improvements. 243 6. IANA Considerations 245 IANA is requested to assign numbers for PA_AS_FRESHNESS listed in the 246 Kerberos Parameters registry Pre-authentication and Typed Data as 247 follows: 249 +------+-----------------+------------+ 250 | Type | Value | Reference | 251 +------+-----------------+------------+ 252 | TBD | PA_AS_FRESHNESS | [This RFC] | 253 +------+-----------------+------------+ 255 7. Security Considerations 257 The freshness token SHOULD include signing, encrypting or sealing 258 data from the KDC to determine authenticity and prevent tampering. 260 Freshness tokens serve to guarantee that the client had the key when 261 constructing the AS-REQ. They are not required to be single use 262 tokens or bound to specific AS exchanges. Part of the reason the 263 token is opaque is to allow KDC implementers the freedom to add 264 additional functionality as long as the "freshness" guarantee 265 remains. 267 8. Interoperability Considerations 269 Since the client treats the KDC provided data blob as opaque, 270 changing the contents will not impact existing clients. Thus 271 extensions to the freshness token do not impact client 272 interoperability. 274 Clients SHOULD NOT reuse freshness tokens across multiple exchanges. 275 There is no guarantee that a KDC will allow a once-valid token to be 276 used again. Thus clients that do not retry with a new freshness 277 token may not be compatible with KDCs depending on how they choose to 278 implement "freshness" validation. 280 Since upgrading clients takes time, implementers may consider 281 allowing both freshness-token based exchanges as well as "legacy" 282 exchanges without use of freshness tokens. However, until freshness 283 tokens are required by the realm, existing risks of pre-generated 284 PKAuthenticators will remain. 286 9. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 294 Kerberos Network Authentication Service (V5)", RFC 4120, 295 DOI 10.17487/RFC4120, July 2005, 296 . 298 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 299 Authentication in Kerberos (PKINIT)", RFC 4556, 300 DOI 10.17487/RFC4556, June 2006, 301 . 303 [RFC5349] Zhu, L., Jaganathan, K., and K. Lauter, "Elliptic Curve 304 Cryptography (ECC) Support for Public Key Cryptography for 305 Initial Authentication in Kerberos (PKINIT)", RFC 5349, 306 DOI 10.17487/RFC5349, September 2008, 307 . 309 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 310 Kerberos Pre-Authentication", RFC 6113, 311 DOI 10.17487/RFC6113, April 2011, 312 . 314 Authors' Addresses 316 Michiko Short (editor) 317 Microsoft Corporation 318 USA 320 Email: michikos@microsoft.com 322 Seth Moore 323 Microsoft Corporation 324 USA 326 Email: sethmo@microsoft.com 327 Paul Miller 328 Microsoft Corporation 329 USA 331 Email: paumil@microsoft.com