idnits 2.17.1 draft-ietf-kitten-pkinit-freshness-01.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 (March 6, 2015) is 3339 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 217 -- Looks like a reference, but probably isn't: '1' on line 218 -- Looks like a reference, but probably isn't: '2' on line 221 -- Looks like a reference, but probably isn't: '3' on line 224 -- Looks like a reference, but probably isn't: '4' on line 229 == Missing Reference: 'This RFC' is mentioned on line 254, 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: September 7, 2015 Microsoft Corporation 6 March 6, 2015 8 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) 9 Freshness Extension 10 draft-ietf-kitten-pkinit-freshness-01 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 which 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 September 7, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. Interoperability Considerations . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 The Kerberos PKINIT extension [RFC4556] defines two schemes for using 78 asymmetric cryptography in a Kerberos preauthenticator. One uses 79 Diffie-Hellman key exchange and the other depends on public key 80 encryption. The public key encryption scheme is less commonly used 81 for two reasons: 83 o Elliptic Curve Cryptography (ECC) Support for PKINIT [RFC5349] 84 only specified Elliptic Curve Diffie-Hellman (ECDH) key agreement 85 so it cannot be used for public key encryption. 87 o Public key encryption requires certificates with an encryption key 88 which is not deployed on many existing smart cards. 90 In the Diffie-Hellman exchange, the client uses its private key only 91 to sign the AuthPack structure specified in Section 3.2.1 of 92 [RFC4556] which is performed before any traffic is sent to the KDC. 93 Thus a client can generate requests with future times in the 94 PKAuthenticator, and then send those requests at those future times. 95 Unless the time is outside the validity period of the client's 96 certificate, the KDC will validate the PKAuthenticator and return a 97 TGT the client can use without possessing the private key. 99 As a result, a client performing PKINIT with the Diffie-Hellman key 100 exchange does not prove current possession of the private key being 101 used for authentication. It proves only prior use of that key. 102 Ensuring that the client has current possession of the private key 103 requires that the signed PKAuthenticator data include information 104 that the client could not have predicted. 106 1.1. Kerberos message flow using KRB_AS_REQ without pre-authentication 108 Today some password-based AS exchanges [RFC4120] depend on the client 109 sending a KRB_AS_REQ without pre-authentication to trigger the KDC to 110 provide the Kerberos client with information needed to complete an AS 111 exchange such as the supported encryption types and salt values (see 112 the message flow below): 114 KDC Client 116 <---- AS-REQ without pre-authentication 117 KRB-ERROR ----> 119 <---- AS-REQ 120 AS-REP ----> 122 <---- TGS-REQ 123 TGS-REP ----> 125 Figure 1 127 We can use this mechanism in PKInit for KDCs to provide data which 128 the client returns as part of the KRB_AS_REQ to ensure that the 129 PA_PK_AS_REQ [RFC4556] was not pregenerated. 131 1.2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 2. Message Exchanges 139 The following summarizes the message flow with extensions to 140 [RFC4120] and [RFC4556] required to support a KDC provided freshness 141 token during the initial request for a ticket: 143 1. The client generates a KRB_AS_REQ as specified in Section 2.9.3 144 [RFC4120] without an authenticator which includes the freshness 145 token request to the KDC. 147 2. The KDC generates a KRB_ERROR as specified in Section 3.1.3 of 148 [RFC4120] providing a freshness token. 150 3. The client receives the error as specified in Section 3.1.4 of 151 [RFC4120] and includes the freshness token as part of the 152 KRB_AS_REQ as specified in [RFC4120] and [RFC4556]. 154 4. The KDC receives and validates the KRB_AS_REQ as specified in 155 Section 3.2.2 [RFC4556] then additionally validates the freshness 156 token. 158 5. The KDC and client continue as specified in [RFC4120] and 159 [RFC4556]. 161 2.1. Generation of KRB_AS_REQ Message 163 The client indicates support of freshness tokens by adding a 164 PA_AS_FRESHNESS padata type with an empty octet string as the padata- 165 value. 167 2.2. Generation of KRB_ERROR Message 169 The KDC will respond by adding a PA_AS_FRESHNESS padata type with the 170 freshness token as the padata-value to the 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_FAILED with PA_AS_FRESHNESS. 189 Since the freshness tokens are validated by KDCs in the same realm, 190 standardizing the contents of the freshness token is not a concern 191 for interoperability. 193 2.5. Receipt of second KRB_ERROR Message 195 Clients SHOULD retry in the cases when receiving a 196 KDC_ERR_PREAUTH_FAILED KRB_ERROR message which includes a freshness 197 token where there is a possibility that there was too much delay 198 between the client receiving the freshness token and sending the 199 PA_PK_AS_REQ message. 201 3. PreAuthentication Data Types 203 The following are the new PreAuthentication data types: 205 +----------------------+-------------------+ 206 | Padata and Data Type | Padata-type Value | 207 +----------------------+-------------------+ 208 | PA_AS_FRESHNESS | TBD | 209 +----------------------+-------------------+ 211 4. Extended PKAuthenticator 213 The PKAuthenticator structure specified in Section 3.2.1 [RFC4556] is 214 extended to include a new freshnessToken as follows: 216 PKAuthenticator ::= SEQUENCE { 217 cusec [0] INTEGER (0..999999), 218 ctime [1] KerberosTime, 219 -- cusec and ctime are used as in [RFC4120], for 220 -- replay prevention. 221 nonce [2] INTEGER (0..4294967295), 222 -- Chosen randomly; this nonce does not need to 223 -- match with the nonce in the KDC-REQ-BODY. 224 paChecksum [3] OCTET STRING OPTIONAL, 225 -- MUST be present. 226 -- Contains the SHA1 checksum, performed over 227 -- KDC-REQ-BODY. 228 ..., 229 freshnessToken [4] OCTET STRING OPTIONAL, 230 -- PA_AS_FRESHNESS padata value as recieved from the 231 -- KDC. MUST be present if sent by KDC 232 ... 233 } 235 5. Acknowledgements 237 Henry B. Hotz, Nico Williams, Sam Hartman, Tom Yu, Martin Rex, and 238 Douglas E. Engert were key contributors to the discover of the 239 freshness issue in PKINIT. 241 Greg Hudson, Nathan Ide, Benjamin Kaduk, Magnus Nystrom, Nico 242 Williams and Tom Yu reviewed the document and provided suggestions 243 for improvements. 245 6. IANA Considerations 247 IANA is requested to assign numbers for PA_AS_FRESHNESS listed in the 248 Kerberos Parameters registry Pre-authentication and Typed Data as 249 follows: 251 +------+-----------------+------------+ 252 | Type | Value | Reference | 253 +------+-----------------+------------+ 254 | TBD | PA_AS_FRESHNESS | [This RFC] | 255 +------+-----------------+------------+ 257 7. Security Considerations 259 The freshness token SHOULD include signing, encrypting or sealing 260 data from the KDC to determine authenticity and prevent tampering. 261 Kerberos error messages are not integrity protected unless 262 authenticated using Kerberos FAST [RFC6113]. Even if FAST is 263 required to provide integrity protection, a different KDC would not 264 be able to validate freshness tokens without some kind of shared 265 database. 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 9. References 276 9.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 282 Kerberos Network Authentication Service (V5)", RFC 4120, 283 July 2005. 285 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 286 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 288 [RFC5349] Zhu, L., Jaganathan, K., and K. Lauter, "Elliptic Curve 289 Cryptography (ECC) Support for Public Key Cryptography for 290 Initial Authentication in Kerberos (PKINIT)", RFC 5349, 291 September 2008. 293 9.2. Informative References 295 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 296 Kerberos Pre-Authentication", RFC 6113, April 2011. 298 Authors' Addresses 300 Michiko Short (editor) 301 Microsoft Corporation 302 USA 304 Email: michikos@microsoft.com 306 Seth Moore 307 Microsoft Corporation 308 USA 310 Email: sethmo@microsoft.com 312 Paul Miller 313 Microsoft Corporation 314 USA 316 Email: paumil@microsoft.com