1 2Kerberos Working Group Matt Crawford 3Internet Draft Fermilab 4 10 September 2003 5 6 Passwordless Initial Authentication to Kerberos 7 by Hardware Preauthentication 8 <draft-ietf-krb-wg-hw-auth-03.txt> 9 10 11 12Status of this Memo 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 19 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 24 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 27 28 29Abstract 30 31 This document specifies an extension to the Kerberos protocol for 32 performing initial authentication of a user without using that 33 user's long-lived password. Any "hardware preauthentication" method 34 may be employed instead of the password, and the key of another 35 principal must be nominated to encrypt the returned credential. 36 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [KWORD]. 40 41 421. Motivation 43 44 Many sites using Kerberos for authentication have users who are 45 often, or even always, away from the site. Sometimes these users 46 47 48 49Expires March 15, 2004 Crawford [Page 1] 50 51Internet Draft Passwordless Hardware Authentication 10 September 2003 52 53 54 may need to connect to their site while they have no immediate 55 access to a computer with Kerberos software or any other trusted 56 secure remote-access mechanism. Requiring hardware 57 preauthentication in addition to a password for all such users is an 58 incomplete solution because an eavesdropper with access to both the 59 remote users' path to the host in the site and that host's path to 60 the KDC can still steal the user's credential. 61 62 This document specifies a method by which a Kerberos application 63 server can request that a KDC authenticate a user using a hardware 64 preauthentication method and use a key held by the server in the 65 decryption of the KDC's reply, in place of the user's password. 66 67 682. Definitions 69 70 The following terms used here are defined in [KRB5] and [KRB5bis]: 71 72 KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ, 73 KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc- 74 options, padata-type, padata-value. 75 76 These terms are defined in [KRB5bis]: 77 78 PA-SAM-CHALLENGE, PA-SAM-RESPONSE. 79 80 The term "service" denotes some Kerberos service which normally 81 requires a client/server authentication exchange [KRB5] for access 82 and which is capable of both communicating with the KDC's 83 Authentication Service and interacting with the user to the extent 84 required to carry out a single-use authentication mechanism (SAM). 85 It must have access to some principal's long-lived key. Telnet and 86 FTP services are examples. 87 88 The Kerberos Authentication Service will be denoted by "AS" to avoid 89 confusion with the service. 90 91 923. Method 93 94 This mechanism is intended to be employed when a user connects to a 95 service which normally allows only Kerberos-authenticated access. 96 When the service determines that the user will not authenticate (for 97 example, it receives a telnet "WONT AUTHENTICATION" command 98 [TELAUTH], or an FTP "USER" command without a preceding "AUTH" 99 command [FTPSEC]), it may accept a user principal name and attempt 100 to perform passwordless hardware authentication in the following 101 manner. 102 103 104 105Expires March 15, 2004 Crawford [Page 2] 106 107Internet Draft Passwordless Hardware Authentication 10 September 2003 108 109 1103.1. Initial AS Request and reply 111 112 The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5] 113 message with the flag OPT-HARDWARE-AUTH set in the kdc-options 114 field, in addition to any other desired options and lifetimes. The 115 service sends this message to a KDC. If the KDC's policy permits 116 this form of authentication for the user named in the request, and 117 the request is acceptable in all other respects, the KDC determines 118 what hardware preauthentication methods are available for the user 119 principal and constructs a KRB_ERROR message with the error-code set 120 to KDC_ERR_PREAUTH_REQUIRED. The e-data field of this KRB_ERROR 121 message contains a sequence of PA-DATA which includes an element 122 with padata-type equal to PA-ALT-PRINC and an empty padata-value. 123 In addition to that are any elements needed for hardware 124 preauthentication of the user. Typically this will consist of an 125 element with padata-type PA-SAM-CHALLENGE and padata-value 126 appropriate to the authentication method. 127 128 1293.2. Second AS Request 130 131 The service, upon receiving the KRB_ERROR message from the KDC, must 132 process the PA-ALT-PRINC element by selecting a principal whose 133 long-lived key it has access to, and which is in the same realm as 134 the client. This principal will be referred to as the alternate 135 principal. It processes the PA-SAM-CHALLENGE normally, except that 136 whenever the user's long-lived (password-derived) encryption key is 137 called for, it uses the alternate principal's key instead. 138 139 The service constructs a second KRB_AS_REQ, again with the OPT- 140 HARDWARE-AUTH flag set in the kdc-options field, and this time with 141 a padata field which includes at least these two PA-DATA items, in 142 this order: 143 144 One with padata-type equal to PA-ALT-PRINC and as padata-value 145 the encoded PrincipalName of the alternate principal, 146 147 One with padata-type equal to PA-SAM-RESPONSE and padata-value 148 constructed as it would be for normal hardware 149 preauthentication, but with the alternate principal's key used 150 in place of the user's key. 151 152 Other PA-DATA may be present before, between or after these items. 153 154 The service sends this second KRB_AS_REQ to a KDC. 155 156 157 158 159 160 161Expires March 15, 2004 Crawford [Page 3] 162 163Internet Draft Passwordless Hardware Authentication 10 September 2003 164 165 1663.3. Final AS Reply 167 168 The KDC begins processing the AS request normally. When the PA-ALT- 169 PRINC field is encountered, the KDC does the following: 170 171 First, if this use of the alternate principal named in the 172 request is against local policy, or if the alternate principal 173 does not exist in the database, a KRB_ERROR message with error- 174 code KDC_ERR_PREAUTH_FAILED is returned and processing ends. 175 176 Then, the alternate principal's key is fetched from the database 177 and held for use in subsequent processing. It will be needed to 178 process the PA-SAM-RESPONSE and to encrypt the enc-part of the 179 KRB_AS_REP if authentication is successful. 180 181 The remainder of the AS request processing is normal, with the noted 182 substitution of the alternate principal's key for the user's. 183 184 The service, upon receiving a KRB_AS_REP, uses the alternate 185 principal's key to decrypt the enc-part, saves the user's credential 186 and takes appropriate measures to ensure that the KRB_AS_REP came 187 from a legitimate KDC and not an imposter. 188 189 1904. IANA Considerations 191 192 As of this writing, management of Kerberos protocol parameters has 193 not been delegated to IANA. No new naming or numbering spaces are 194 created by this specification. Two new values from existing spaces 195 are defined: 196 197 The flag OPT-HARDWARE-AUTH is a previously unused bit in the 198 kdc-options field of a KDC-REQ-BODY [KRB5]. The assignment of 199 bit 11 is expected [BCN]. 200 201 The preauthentication type PA-ALT-PRINC is denoted by padata- 202 type 24 [KRB5bis]. 203 204 2055. Security Considerations 206 207 There are no means provided here for protecting the traffic between 208 the user and the service, so it may be susceptible to eavesdropping, 209 hijacking and alteration. This authentication mechanism is not 210 intended to be used as an alternative to the Kerberos client/server 211 authentication exchange, but as an improvement over making an 212 unprotected connection with a Kerberos password alone, or a password 213 plus a single-use authenticator. 214 215 216 217Expires March 15, 2004 Crawford [Page 4] 218 219Internet Draft Passwordless Hardware Authentication 10 September 2003 220 221 222 The alternate principal's key MUST be involved in construction of 223 the PA-SAM-RESPONSE padata-value, to prevent an adversary 224 constructing a KRB_AS_REQ using that data but a different alternate 225 principal. In practice, this means that the response data alone 226 must not determine the encryption key for the padata-value. 227 228 A service impersonator can obtain a presumably-valid SAM response 229 from the user which may (or may not) be usable for impersonating the 230 user at a later time. And of course in the case of successful 231 authentication the service obtains access to the user's credentials. 232 As always, if the service host is compromised, so are the 233 credentials; but at least the service host never has access to the 234 user's password. 235 236 A service host which accepts a Kerberos password for access 237 typically protects itself against an impostor KDC by using the 238 received ticket-granting credential to get a ticket for a service 239 for which it has the key. This step may be unnecessary when the 240 service host has already successfully used such a key to decrypt the 241 ticket-granting credential itself. 242 243 Use of this authentication method employs the service's long-term 244 key, providing more ciphertext in that key to an eavesdropper. This 245 key is generally of better quality than a password-derived key and 246 any remaining concerns about the strength of the KRB_AS_REP are 247 better addressed by a general mechanism applicable to all AS 248 exchanges. 249 250 2516. Acknowledgments 252 253 The first implementation of this extension grew from a beginning by 254 Ken Hornstein, which in turn was built on code released by the MIT 255 Kerberos Team. 256 257 2587. References 259 260 [BCN] Newman, C., private communication. 261 262 [FTPSEC] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 263 2228. 264 265 [KRB5] Kohl, J., and C. Neuman, "The Kerberos Network 266 Authentication Service (V5)", RFC 1510. 267 268 [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The 269 Kerberos Network Authentication Service (V5)", Work in 270 271 272 273Expires March 15, 2004 Crawford [Page 5] 274 275Internet Draft Passwordless Hardware Authentication 10 September 2003 276 277 278 progress. (Currently draft-ietf-krb-wg-kerberos- 279 clarifications-04.txt.) 280 281 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 282 Requirement Levels," RFC 2119, March 1997. 283 284 [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option", 285 RFC 2941. 286 2878. Author's Address 288 289 Matt Crawford 290 Fermilab MS 369 291 PO Box 500 292 Batavia, IL 60510 293 USA 294 295 Phone: +1 630 840-3461 296 EMail: crawdad@fnal.gov 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329Expires March 15, 2004 Crawford [Page 6] 330