1 2 3 4 5 6 7 8 9 10 11Kerberos Working Group Matt Crawford 12Internet Draft Fermilab 13 21 October 2006 14 15 Passwordless Initial Authentication to Kerberos 16 by Hardware Preauthentication 17 <draft-ietf-krb-wg-hw-auth-04.txt> 18 19 20 21Status of this Memo 22 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 32 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet- Drafts as 36 reference material or to cite them other than as "work in progress." 37 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html. 40 41 To view the list Internet-Draft Shadow Directories, see 42 http://www.ietf.org/shadow.html. 43 44 45Abstract 46 47 This document specifies an extension to the Kerberos protocol for 48 performing initial authentication of a user without using that 49 user's long-lived password. Any "hardware preauthentication" method 50 may be employed instead of the password, and the key of another 51 principal must be nominated to encrypt the returned credential. 52 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 56 57 58Expires April 26, 2007 Crawford [Page 1] 59 60Internet Draft Passwordless Hardware Authentication 21 October 2006 61 62 63 document are to be interpreted as described in [KWORD]. 64 65 661. Motivation 67 68 Many sites using Kerberos for authentication have users who are 69 often, or even always, away from the site. Sometimes these users 70 may need to connect to their site while they have no immediate 71 access to a trustworthy computer with Kerberos software or any other 72 trusted secure remote-access mechanism. Requiring hardware 73 preauthentication in addition to a password for all such users is an 74 incomplete solution because an eavesdropper with access to both the 75 remote users' path to the host in the site and that host's path to 76 the KDC can still steal the user's credential. 77 78 This document specifies a method by which a Kerberos application 79 server can request that a KDC authenticate a user using a hardware 80 preauthentication method and use a key held by the server in the 81 decryption of the KDC's reply, in place of the user's password. 82 83 842. Definitions 85 86 The following terms used here are defined in [KRB5] and [KRB5bis]: 87 88 KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ, 89 KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc- 90 options, padata-type, padata-value. 91 92 These terms are defined in [KRB5bis]: 93 94 PA-SAM-CHALLENGE, PA-SAM-CHALLENGE2, PA-SAM-RESPONSE, PA-SAM- 95 RESPONSE2. 96 97 The term "service" denotes some Kerberos service which normally 98 requires a client/server authentication exchange [KRB5] for access 99 and which is capable of both communicating with the KDC's 100 Authentication Service and interacting with the user to the extent 101 required to carry out a single-use authentication mechanism (SAM). 102 It must have access to some principal's long-lived key. Telnet and 103 FTP services are examples. 104 105 The Kerberos Authentication Service will be denoted by "AS" to avoid 106 confusion with the service. 107 108 109 110 111 112 113 114Expires April 26, 2007 Crawford [Page 2] 115 116Internet Draft Passwordless Hardware Authentication 21 October 2006 117 118 1193. Method 120 121 This mechanism is intended to be employed when a user connects to a 122 service which normally allows only Kerberos-authenticated access. 123 When the service determines that the user will not authenticate (for 124 example, it receives a telnet "WONT AUTHENTICATION" command 125 [TELAUTH], or an FTP "USER" command without a preceding "AUTH" 126 command [FTPSEC]), it may accept a user principal name and attempt 127 to perform passwordless hardware authentication in the following 128 manner. 129 130 1313.1. Initial AS Request and reply 132 133 The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5] 134 message with the flag OPT-HARDWARE-AUTH set in the kdc-options 135 field, in addition to any other desired options and lifetimes. The 136 service sends this message to a KDC. If the KDC's policy permits 137 this form of authentication for the user named in the request, and 138 the request is acceptable in all other respects, the KDC determines 139 what hardware preauthentication methods are available for the user 140 principal and constructs a KRB_ERROR message with the error-code set 141 to KDC_ERR_PREAUTH_REQUIRED. The e-data field of this KRB_ERROR 142 message contains a sequence of PA-DATA which includes an element 143 with padata-type equal to PA-ALT-PRINC and an empty padata-value. 144 In addition to that are any elements needed for hardware 145 preauthentication of the user. Typically this will include an 146 element with padata-type PA-SAM-CHALLENGE or PA-SAM-CHALLENGE2 and 147 padata-value appropriate to the authentication method. 148 149 1503.2. Second AS Request 151 152 The service, upon receiving the KRB_ERROR message from the KDC, must 153 process the PA-ALT-PRINC element by selecting a principal whose 154 long-lived key it has access to, and which is in the same realm as 155 the client. This principal will be referred to as the alternate 156 principal. It processes the PA-SAM-CHALLENGE normally, except that 157 whenever the user's long-lived (password-derived) encryption key is 158 called for, it uses the alternate principal's key instead. 159 160 The service constructs a second KRB_AS_REQ, again with the OPT- 161 HARDWARE-AUTH flag set in the kdc-options field, and this time with 162 a padata field which includes at least these two PA-DATA items, in 163 this order: 164 165 One with padata-type equal to PA-ALT-PRINC and as padata-value 166 the encoded PrincipalName of the alternate principal, 167 168 169 170Expires April 26, 2007 Crawford [Page 3] 171 172Internet Draft Passwordless Hardware Authentication 21 October 2006 173 174 175 One with padata-type appropriate for hardware token-based 176 preauthentication, such as PA-SAM-RESPONSE or PA-SAM-RESPONSE2, 177 and padata-value constructed as it would be for normal hardware 178 preauthentication, but with the alternate principal's key used 179 in place of the user's key. 180 181 Other PA-DATA may be present before, between or after these items. 182 183 The service sends this second KRB_AS_REQ to a KDC. 184 185 1863.3. Final AS Reply 187 188 The KDC begins processing the AS request normally. When the PA-ALT- 189 PRINC field is encountered, the KDC does the following: 190 191 First, if this use of the alternate principal named in the 192 request is against local policy, or if the alternate principal 193 does not exist in the database, a KRB_ERROR message with error- 194 code KDC_ERR_PREAUTH_FAILED is returned and processing ends. 195 196 Then, the alternate principal's key is fetched from the database 197 and held for use in subsequent processing. It will be needed to 198 process the PA-SAM-RESPONSE, PA-SAM-RESPONSE2, or similar 199 preauthentication data, and to encrypt the enc-part of the 200 KRB_AS_REP if authentication is successful. 201 202 The remainder of the AS request processing is normal, with the noted 203 substitution of the alternate principal's key for the user's. 204 205 The service, upon receiving a KRB_AS_REP, uses the alternate 206 principal's key to decrypt the enc-part, saves the user's credential 207 and takes appropriate measures to ensure that the KRB_AS_REP came 208 from a legitimate KDC and not an imposter. 209 210 2114. IANA Considerations 212 213 No new naming or numbering spaces are created by this specification. 214 Two values from existing spaces are defined in [KRB5bis] for the 215 mechanism of this document: 216 217 The flag OPT-HARDWARE-AUTH is bit 11 in the kdc-options field of 218 a KDC-REQ-BODY. 219 220 The preauthentication type PA-ALT-PRINC is denoted by padata- 221 type 24. 222 223 224 225 226Expires April 26, 2007 Crawford [Page 4] 227 228Internet Draft Passwordless Hardware Authentication 21 October 2006 229 230 2315. Security Considerations 232 233 There are no means provided here for protecting the traffic between 234 the user and the service, so it may be susceptible to eavesdropping, 235 hijacking and alteration. This authentication mechanism is not 236 intended to be used as an alternative to the Kerberos client/server 237 authentication exchange, but as an improvement over making an 238 unprotected connection with a Kerberos password alone, or a password 239 plus a single-use authenticator. 240 241 The alternate principal's key MUST be involved in construction of 242 the PA-SAM-RESPONSE (or PA-SAM-RESPONSE2) padata-value, to prevent 243 an adversary constructing a KRB_AS_REQ using that data but a 244 different alternate principal. In practice, this means that the 245 response data alone must not determine the encryption key for the 246 padata-value. 247 248 A service impersonator can obtain a presumably-valid SAM response 249 from the user which may (or may not) be usable for impersonating the 250 user at a later time. And of course in the case of successful 251 authentication the service obtains access to the user's credentials. 252 As always, if the service host is compromised, so are the 253 credentials; but, with this mechanism, at least the service host 254 never has access to the user's password. 255 256 A service host which accepts a Kerberos password for access 257 typically protects itself against an impostor KDC by using the 258 received ticket-granting credential to get a ticket for a service 259 for which it has the key. This step may be unnecessary when the 260 service host has already successfully used such a key to decrypt the 261 ticket-granting credential itself. 262 263 Use of this authentication method employs the service's long-term 264 key, providing more ciphertext in that key to an eavesdropper. This 265 key is generally of better quality than a password-derived key and 266 any remaining concerns about the strength of the KRB_AS_REP are 267 better addressed by a general mechanism applicable to all AS 268 exchanges. 269 270 2716. Acknowledgments 272 273 The first implementation of this extension grew from a beginning by 274 Ken Hornstein, which in turn was built on code released by the MIT 275 Kerberos Team. 276 277 278 279 280 281 282Expires April 26, 2007 Crawford [Page 5] 283 284Internet Draft Passwordless Hardware Authentication 21 October 2006 285 286 2877. References 288 289 [FTPSEC] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 290 2228. 291 292 [KRB5] Kohl, J., and C. Neuman, "The Kerberos Network 293 Authentication Service (V5)", RFC 1510. 294 295 [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The 296 Kerberos Network Authentication Service (V5)", RFC 4120. 297 298 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 299 Requirement Levels," RFC 2119, March 1997. 300 301 [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option", 302 RFC 2941. 303 3048. Author's Address 305 306 Matt Crawford 307 Fermilab MS 368 308 PO Box 500 309 Batavia, IL 60510 310 USA 311 312 Phone: +1 630 840-3461 313 EMail: crawdad@fnal.gov 314 315Disclaimer of Validity 316 317 This document and the information contained herein are provided on 318 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 319 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 320 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 321 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 322 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 325 326Copyright Statement 327 328 Copyright (C) The Internet Trust (2006). This document is subject 329 to the rights, licenses and restrictions contained in BCP 78, and 330 except as set forth therein, the authors retain all their rights. 331 332 333 Acknowledgment 334 335 336 337 338Expires April 26, 2007 Crawford [Page 6] 339 340Internet Draft Passwordless Hardware Authentication 21 October 2006 341 342 343 Funding for the RFC Editor function is currently provided by the 344 Internet Society. 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394Expires April 26, 2007 Crawford [Page 7] 395