idnits 2.17.1 draft-ietf-krb-wg-hw-auth-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 259. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([KWORD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 October 2006) is 6369 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) ** Obsolete normative reference: RFC 1510 (ref. 'KRB5') (Obsoleted by RFC 4120, RFC 6649) Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group Matt Crawford 3 Internet Draft Fermilab 4 21 October 2006 6 Passwordless Initial Authentication to Kerberos 7 by Hardware Preauthentication 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html. 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document specifies an extension to the Kerberos protocol for 36 performing initial authentication of a user without using that 37 user's long-lived password. Any "hardware preauthentication" method 38 may be employed instead of the password, and the key of another 39 principal must be nominated to encrypt the returned credential. 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [KWORD]. 45 1. Motivation 47 Many sites using Kerberos for authentication have users who are 48 often, or even always, away from the site. Sometimes these users 49 may need to connect to their site while they have no immediate 50 access to a trustworthy computer with Kerberos software or any other 51 trusted secure remote-access mechanism. Requiring hardware 52 preauthentication in addition to a password for all such users is an 53 incomplete solution because an eavesdropper with access to both the 54 remote users' path to the host in the site and that host's path to 55 the KDC can still steal the user's credential. 57 This document specifies a method by which a Kerberos application 58 server can request that a KDC authenticate a user using a hardware 59 preauthentication method and use a key held by the server in the 60 decryption of the KDC's reply, in place of the user's password. 62 2. Definitions 64 The following terms used here are defined in [KRB5] and [KRB5bis]: 66 KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ, 67 KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc- 68 options, padata-type, padata-value. 70 These terms are defined in [KRB5bis]: 72 PA-SAM-CHALLENGE, PA-SAM-CHALLENGE2, PA-SAM-RESPONSE, PA-SAM- 73 RESPONSE2. 75 The term "service" denotes some Kerberos service which normally 76 requires a client/server authentication exchange [KRB5] for access 77 and which is capable of both communicating with the KDC's 78 Authentication Service and interacting with the user to the extent 79 required to carry out a single-use authentication mechanism (SAM). 80 It must have access to some principal's long-lived key. Telnet and 81 FTP services are examples. 83 The Kerberos Authentication Service will be denoted by "AS" to avoid 84 confusion with the service. 86 3. Method 88 This mechanism is intended to be employed when a user connects to a 89 service which normally allows only Kerberos-authenticated access. 90 When the service determines that the user will not authenticate (for 91 example, it receives a telnet "WONT AUTHENTICATION" command 92 [TELAUTH], or an FTP "USER" command without a preceding "AUTH" 93 command [FTPSEC]), it may accept a user principal name and attempt 94 to perform passwordless hardware authentication in the following 95 manner. 97 3.1. Initial AS Request and reply 99 The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5] 100 message with the flag OPT-HARDWARE-AUTH set in the kdc-options 101 field, in addition to any other desired options and lifetimes. The 102 service sends this message to a KDC. If the KDC's policy permits 103 this form of authentication for the user named in the request, and 104 the request is acceptable in all other respects, the KDC determines 105 what hardware preauthentication methods are available for the user 106 principal and constructs a KRB_ERROR message with the error-code set 107 to KDC_ERR_PREAUTH_REQUIRED. The e-data field of this KRB_ERROR 108 message contains a sequence of PA-DATA which includes an element 109 with padata-type equal to PA-ALT-PRINC and an empty padata-value. 110 In addition to that are any elements needed for hardware 111 preauthentication of the user. Typically this will include an 112 element with padata-type PA-SAM-CHALLENGE or PA-SAM-CHALLENGE2 and 113 padata-value appropriate to the authentication method. 115 3.2. Second AS Request 117 The service, upon receiving the KRB_ERROR message from the KDC, must 118 process the PA-ALT-PRINC element by selecting a principal whose 119 long-lived key it has access to, and which is in the same realm as 120 the client. This principal will be referred to as the alternate 121 principal. It processes the PA-SAM-CHALLENGE normally, except that 122 whenever the user's long-lived (password-derived) encryption key is 123 called for, it uses the alternate principal's key instead. 125 The service constructs a second KRB_AS_REQ, again with the OPT- 126 HARDWARE-AUTH flag set in the kdc-options field, and this time with 127 a padata field which includes at least these two PA-DATA items, in 128 this order: 130 One with padata-type equal to PA-ALT-PRINC and as padata-value 131 the encoded PrincipalName of the alternate principal, 132 One with padata-type appropriate for hardware token-based 133 preauthentication, such as PA-SAM-RESPONSE or PA-SAM-RESPONSE2, 134 and padata-value constructed as it would be for normal hardware 135 preauthentication, but with the alternate principal's key used 136 in place of the user's key. 138 Other PA-DATA may be present before, between or after these items. 140 The service sends this second KRB_AS_REQ to a KDC. 142 3.3. Final AS Reply 144 The KDC begins processing the AS request normally. When the PA-ALT- 145 PRINC field is encountered, the KDC does the following: 147 First, if this use of the alternate principal named in the 148 request is against local policy, or if the alternate principal 149 does not exist in the database, a KRB_ERROR message with error- 150 code KDC_ERR_PREAUTH_FAILED is returned and processing ends. 152 Then, the alternate principal's key is fetched from the database 153 and held for use in subsequent processing. It will be needed to 154 process the PA-SAM-RESPONSE, PA-SAM-RESPONSE2, or similar 155 preauthentication data, and to encrypt the enc-part of the 156 KRB_AS_REP if authentication is successful. 158 The remainder of the AS request processing is normal, with the noted 159 substitution of the alternate principal's key for the user's. 161 The service, upon receiving a KRB_AS_REP, uses the alternate 162 principal's key to decrypt the enc-part, saves the user's credential 163 and takes appropriate measures to ensure that the KRB_AS_REP came 164 from a legitimate KDC and not an imposter. 166 4. IANA Considerations 168 No new naming or numbering spaces are created by this specification. 169 Two values from existing spaces are defined in [KRB5bis] for the 170 mechanism of this document: 172 The flag OPT-HARDWARE-AUTH is bit 11 in the kdc-options field of 173 a KDC-REQ-BODY. 175 The preauthentication type PA-ALT-PRINC is denoted by padata- 176 type 24. 178 5. Security Considerations 180 There are no means provided here for protecting the traffic between 181 the user and the service, so it may be susceptible to eavesdropping, 182 hijacking and alteration. This authentication mechanism is not 183 intended to be used as an alternative to the Kerberos client/server 184 authentication exchange, but as an improvement over making an 185 unprotected connection with a Kerberos password alone, or a password 186 plus a single-use authenticator. 188 The alternate principal's key MUST be involved in construction of 189 the PA-SAM-RESPONSE (or PA-SAM-RESPONSE2) padata-value, to prevent 190 an adversary constructing a KRB_AS_REQ using that data but a 191 different alternate principal. In practice, this means that the 192 response data alone must not determine the encryption key for the 193 padata-value. 195 A service impersonator can obtain a presumably-valid SAM response 196 from the user which may (or may not) be usable for impersonating the 197 user at a later time. And of course in the case of successful 198 authentication the service obtains access to the user's credentials. 199 As always, if the service host is compromised, so are the 200 credentials; but, with this mechanism, at least the service host 201 never has access to the user's password. 203 A service host which accepts a Kerberos password for access 204 typically protects itself against an impostor KDC by using the 205 received ticket-granting credential to get a ticket for a service 206 for which it has the key. This step may be unnecessary when the 207 service host has already successfully used such a key to decrypt the 208 ticket-granting credential itself. 210 Use of this authentication method employs the service's long-term 211 key, providing more ciphertext in that key to an eavesdropper. This 212 key is generally of better quality than a password-derived key and 213 any remaining concerns about the strength of the KRB_AS_REP are 214 better addressed by a general mechanism applicable to all AS 215 exchanges. 217 6. Acknowledgments 219 The first implementation of this extension grew from a beginning by 220 Ken Hornstein, which in turn was built on code released by the MIT 221 Kerberos Team. 223 7. References 225 [FTPSEC] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 226 2228. 228 [KRB5] Kohl, J., and C. Neuman, "The Kerberos Network 229 Authentication Service (V5)", RFC 1510. 231 [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The 232 Kerberos Network Authentication Service (V5)", RFC 4120. 234 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 235 Requirement Levels," RFC 2119, March 1997. 237 [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option", 238 RFC 2941. 240 8. Author's Address 242 Matt Crawford 243 Fermilab MS 368 244 PO Box 500 245 Batavia, IL 60510 246 USA 248 Phone: +1 630 840-3461 249 EMail: crawdad@fnal.gov 251 Disclaimer of Validity 253 This document and the information contained herein are provided on 254 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 255 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 256 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 257 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 258 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 259 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 261 Copyright Statement 263 Copyright (C) The Internet Trust (2006). This document is subject 264 to the rights, licenses and restrictions contained in BCP 78, and 265 except as set forth therein, the authors retain all their rights. 267 Acknowledgment 268 Funding for the RFC Editor function is currently provided by the 269 Internet Society.