idnits 2.17.1 draft-ietf-krb-wg-hw-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 current Internet-Drafts. ** 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 (July 10, 2001) is 8324 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) == Outdated reference: A later version (-10) exists of draft-ietf-cat-kerberos-revisions-08 -- Possible downref: Normative reference to a draft: ref. 'KRBREV' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kerberos Working Group Crawford 2 Internet Draft Fermilab 3 July 10, 2001 5 Passwordless Initial Authentication to Kerberos 6 by Hardware Preauthentication 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 To view the list Internet-Draft Shadow Directories, see 23 http://www.ietf.org/shadow.html. 25 Abstract 27 This document specifies an extension to the Kerberos protocol for 28 performing initial authentication of a user without using that 29 user's long-lived password. Any "hardware preauthentication" method 30 may be employed instead of the password, and the key of another 31 principal must be nominated to encrypt the returned credential. 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [KWORD]. 37 1. Motivation 39 Many sites using Kerberos for authentication have users who are 40 often, or even always, away from the site. Sometimes these users 41 may need to connect to their site while they have no immediate 42 access to a computer with Kerberos software or any other trusted 43 secure remote-access mechanism. Requiring hardware 44 preauthentication in addition to a password for all such users is an 45 incomplete solution because an eavesdropper with access to both the 46 remote users' path to the host in the site and that host's path to 47 the KDC can still steal the user's credential. 49 This document specifies a method by which a Kerberos application 50 server can request that a KDC authenticate a user using a hardware 51 preauthentication method and use a key held by the server for 52 decryption of the KDC's reply, in place of the user's password. 54 2. Definitions 56 The following terms used here are defined in [KRB5]: 58 KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ, 59 KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc- 60 options, method-data, method-type. 62 These terms are defined in [KRBREV]: 64 PA-SAM-CHALLENGE, PA-SAM-RESPONSE. 66 The term "service" denotes some Kerberos service which normally 67 requires a client/server authentication exchange [KRB5] for access 68 and which is capable of both communicating with the KDC's 69 Authentication Service and interacting with the user to the extent 70 required to carry out a single-use authentication mechanism (SAM). 71 It must have access to some principal's long-lived key. Telnet and 72 FTP services are examples. 74 The Kerberos Authentication Service will be denoted by "AS" to avoid 75 confusion with the service. 77 3. Method 79 This mechanism is intended to be employed when a user connects to a 80 service which normally allows only Kerberos-authenticated access. 81 When the service determines that the user will not authenticate (for 82 example, it receives a telnet "WONT AUTHENTICATION" command 83 [TELAUTH], or an FTP "USER" command without a preceding "AUTH" 84 command [FTPSEC]), it may accept a user principal name and attempt 85 to perform passwordless hardware authentication in the following 86 manner. 88 3.1. Initial AS Request and reply 90 The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5] 91 message with the flag OPT-HARDWARE-AUTH set in the kdc-options 92 field, in addition to any other desired options and lifetimes. The 93 service sends this message to a KDC. If the KDC's policy permits 94 this form of authentication for the user named in the request, and 95 the request is acceptable in all other respects, the KDC determines 96 what hardware preauthentication methods are available for the user 97 principal and constructs a KRB_ERROR message with the error-code set 98 to KDC_ERR_PREAUTH_REQUIRED. The e-data field of this KRB_ERROR 99 message contains a sequence of PA-DATA which includes an element 100 with method-type PA-ALT-PRINC and no method-data. In addition to 101 that are any elements needed for hardware preauthentication of the 102 user. Typically this will consist of an element with method-type 103 PA-SAM-CHALLENGE and method-data appropriate to the authentication 104 method. 106 3.2. Second AS Request 108 The service, upon receiving the KRB_ERROR message from the KDC, must 109 process the PA-ALT-PRINC element by selecting a principal whose 110 long-lived key it has access to, and which is in the same realm as 111 the client. This principal will be referred to as the alternate 112 principal. It processes the PA-SAM-CHALLENGE normally, except that 113 whenever the user's long-lived (password-derived) encryption key is 114 called for, it uses the alternate principal's key instead. 116 The service constructs a second KRB_AS_REQ, again with the OPT- 117 HARDWARE-AUTH flag set in the kdc-options field, and this time with 118 a padata field which includes at least these two PA-DATA items, in 119 this order: 121 One with padata-type equal to PA-ALT-PRINC and as padata-value 122 the encoded PrincipalName of the alternate principal, 124 One with padata-type equal to PA-SAM-RESPONSE and padata-value 125 constructed as it would be for normal hardware 126 preauthentication, but with the alternate principal's key used 127 in place of the user's key. 129 Other PA-DATA may be present before, between or after these items. 131 The service sends this second KRB_AS_REQ to a KDC. 133 3.3. Final AS Reply 135 The KDC begins processing the AS request normally. When the PA- 136 ALT-PRINC field is encountered, the KDC does the following: 138 First, if this use of the alternate principal named in the 139 request is against local policy, or if the alternate principal 140 does not exist in the database, a KRB_ERROR message with error- 141 code KDC_ERR_PREAUTH_FAILED is returned and processing ends. 143 Then, the alternate principal's key is fetched from the database 144 and held for use in subsequent processing. It will be needed to 145 process the PA-SAM-RESPONSE and to encrypt the enc-part of the 146 KRB_AS_REP if authentication is successful. 148 The remainder of the AS request processing is normal, with the noted 149 substitution of the alternate principal's key for the user's. 151 The service, upon receiving a KRB_AS_REP, uses the alternate 152 principal's key to decrypt the enc-part, saves the user's credential 153 and takes appropriate measures to ensure that the KRB_AS_REP came 154 from a legitimate KDC and not an imposter. 156 4. IANA Considerations 158 As of this writing, management of Kerberos protocol parameters has 159 not been delegated to IANA. No new naming or numbering spaces are 160 created by this specification. Two new values from existing spaces 161 are defined: 163 The flag OPT-HARDWARE-AUTH is bit number 11 of the kdc-options 164 field of a KDC-REQ-BODY [KRB5]. 166 The preauthentication type PA-ALT-PRINC is denoted by padata- 167 type (TBA). 169 5. Security Considerations 171 There are no means provided here for protecting the traffic between 172 the user and the service, so it may be susceptible to eavesdropping, 173 hijacking and alteration. This authentication mechanism is not 174 intended to be used as an alternative to the Kerberos client/server 175 authentication exchange, but as an improvement over making an 176 unprotected connection with a Kerberos password alone, or a password 177 plus a single-use authenticator. 179 The alternate principal's key MUST be involved in construction of 180 the PA-SAM-RESPONSE padata-value, to prevent an adversary 181 constructing a KRB_AS_REQ using that data but a different alternate 182 principal. In practice, this means that the response data alone 183 must not determine the encryption key for the padata-value. 185 A service impersonator can obtain a presumably-valid SAM response 186 from the user which may (or may not) be usable for impersonating the 187 user at a later time. And of course in the case of successful 188 authentication the service obtains access to the user's credentials. 189 As always, if the service host is compromised, so are the 190 credentials -- but at least the service host never has access to the 191 user's password. 193 A service host which accepts a Kerberos password for access 194 typically protects itself against an impostor KDC by using the 195 received ticket-granting credential to get a ticket for a service 196 for which it has the key. This step may be unnecessary when the 197 service host has already successfully used such a key to decrypt the 198 ticket-granting credential itself. 200 6. Acknowledgments 202 The first implementation of this extension grew from a beginning by 203 Ken Hornstein, which in turn was built on code released by the MIT 204 Kerberos developers. 206 7. References 208 [FTPSEC] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 209 2228. 211 [KRB5] Kohl, J., and C. Neuman, "The Kerberos Network 212 Authentication Service (V5)", RFC 1510. 214 [KRBREV] Neuman, C., Kohl, J., Ts'o, T., Raeburn, K. and Tom Yu, 215 "The Kerberos Network Authentication Service (V5)", Work 216 in progress. (Currently draft-ietf-cat-kerberos- 217 revisions-08.txt.) 219 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 220 Requirement Levels," RFC 2119, March 1997. 222 [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option", 223 RFC 2941. 225 8. Author's Address 227 Matt Crawford 228 Fermilab MS 368 229 PO Box 500 230 Batavia, IL 60510 231 USA 233 Phone: +1 630 840-3461 234 EMail: crawdad@fnal.gov