idnits 2.17.1 draft-ietf-krb-wg-kerberos-sam-00.txt: ** The Abstract section seems to be numbered 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 292 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([RFC1510]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 172: '... implementations SHOULD check the addr...' RFC 2119 keyword, line 228: '... sam-type-name[2] GeneralString OPTIONAL,...' RFC 2119 keyword, line 229: '... sam-track-id[3] GeneralString OPTIONAL,...' RFC 2119 keyword, line 230: '... sam-challenge-label[4] GeneralString OPTIONAL,...' RFC 2119 keyword, line 231: '... sam-challenge[5] GeneralString OPTIONAL,...' (10 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 16 has weird spacing: '...), its areas...' == Line 21 has weird spacing: '... months and ...' == Line 22 has weird spacing: '...-Drafts as...' == Line 23 has weird spacing: '...ference mater...' == Line 32 has weird spacing: '...tion of this ...' == (287 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In some cases there may be more than one valid SAD; some preauthen-tication mechanisms may have a range of valid responses. In that case, the KDC may elect to return multiple checksums, one for each possible SAD response. The number of possible responses of course depends on the mechanism and site policy. In the case where multi-ple checksums are returned, the client MUST try each checksum in turn until one of the checksums is verified successfully. Note that in the non-send-encrypted-sad case the checksum cannot be ver-ified until the user enters in the SAD, but if no checksum can be verified, the client MUST not send a response but instead return an error to the user. (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 507 -- Looks like a reference, but probably isn't: '1' on line 508 -- Looks like a reference, but probably isn't: '2' on line 499 -- Looks like a reference, but probably isn't: '3' on line 500 -- Looks like a reference, but probably isn't: '4' on line 502 -- Looks like a reference, but probably isn't: '5' on line 231 -- Looks like a reference, but probably isn't: '6' on line 232 -- Looks like a reference, but probably isn't: '7' on line 233 -- Looks like a reference, but probably isn't: '8' on line 234 -- Looks like a reference, but probably isn't: '9' on line 235 -- Looks like a reference, but probably isn't: '10' on line 236 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1760 ** Downref: Normative reference to an Informational RFC: RFC 1636 -- Possible downref: Non-RFC (?) normative reference: ref. 'KCRYPTO' Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Clifford Neuman 3 ISI 4 Updates: RFC 1510 Glen Zorn 5 September 18, 2002 Cisco Systems 6 Ken Hornstein 7 Naval Research Laboratory 8 Ken Renard 9 WareOnEarth 11 Integrating Single-use Authentication Mechanisms with Kerberos 13 0. Status Of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. Internet-Drafts are working documents of 16 the Internet Engineering Task Force (IETF), its areas, and its 17 working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other docu- 22 ments at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as ``work in pro- 24 gress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 The distribution of this memo is unlimited. It is filed as 33 , and expires December 22, 2002. 34 Please send comments to the authors. 36 1. Abstract 37 This document defines extensions to the Kerberos protocol specifi- 38 cation [RFC1510] which provide a method by which a variety of 39 single-use authentication mechanisms may be supported within the 40 protocol. The method defined specifies a standard fashion in which 41 the preauthentication data and error data fields in Kerberos mes- 42 sages may be used to support single-use authentication mechanisms. 44 2. Terminology 45 To simplify the following discussion, we will define those terms 46 which may be unfamiliar to the audience or specific to the discus- 47 sion itself. 49 Single-use Preauthentication Data (SPD): Data sent in the padata- 50 value field of a Kerberos V5 message proving that knowledge of 51 certain unique information is held by a principal. This informa- 52 tion may or may not be identical to the single-use authentication 53 data input to the client. For example, in the case of S/Key, the 54 principal might input a one-time password (in any of several 55 forms); the knowledge of this one-time password is taken to indi- 56 cate knowledge of the principal's secret passphrase. Similarly, 57 the SPD may or may not contain the provided single-use authentica- 58 tion data. For instance, if a given single-use authentication 59 mechanism includes a token which generates an encryption key for a 60 supported cryptosystem, that key could be used to encrypt portions 61 of the SPD before transmission. As long as the verification pro- 62 cess of the mechanism was capable of independently generating the 63 same key, the successful decryption of the SPD would provide 64 assurance that the originator of the message was in possession of 65 the token, as well as whatever information the token required to 66 generate the encryption key. 68 Single-use Authentication Mechanism (SAM): A system for generating 69 and verifying authentication data which is usable only once. 71 Single-use Authentication Data (SAD): SAM-specific data provided 72 by a principal as input to client software to be used in the crea- 73 tion of SPD. 75 3. Motivation and Scope 76 Several single-use authentication mechanisms are currently in 77 widespread use, including hardware-based schemes from vendors such 78 as Enigma Logic, CRYPTOCard, and Security Dynamics and software- 79 based methods like S/Key [RFC1760]. The hardware-based schemes 80 typically require that the authenticating user carry a small, 81 credit-card-sized electronic device (called a token) which is used 82 to generate unique authentication data. Some tokens require the 83 user to enter data into the device. This input may take the form 84 of a Personal Identification Number (PIN), a server-generated chal- 85 lenge string or both. Other tokens do not use a challenge-response 86 technique, instead spontaneously generating new and unique authen- 87 tication data every few seconds. These tokens are usually time- 88 synchronized with a server. The use of one-time passwords and 89 token cards as an authentication mechanism has steadily increased 90 over the past few years; in addition, the Internet Architecture 91 Board has encouraged the use of SAMs to improve Internet security 92 [RFC1636]. 94 The widespread acceptance of Kerberos within the Internet community 95 has produced considerable demand for the integration of SAM tech- 96 nology with the authentication protocol. Several currently avail- 97 able implementations of Kerberos include support for some types of 98 token cards, but the implementations are either not interoperable, 99 or would require the release of source code (not always an option) 100 to make them interoperate. This memo attempts to remedy that prob- 101 lem by specifying a method in which SAM data may be securely tran- 102 sported in Kerberos V5 messages in a standard, extensible fashion. 103 This document does not, however, attempt to precisely specify 104 either the generation or verification of SAM data, since this is 105 likely to be SAM-specific; nor does it dictate the conditions under 106 which SAM data must be included in Kerberos messages, since we con- 107 sider this to be a matter of local policy. 109 A primary reason for using a SAM with Kerberos is to reduce the 110 threat from common attacks on Kerberos passwords (poorly chosen 111 passwords, password guessing, etc). If passwords are used in com- 112 bination with SAM authentication data, users must still adhere to 113 sensible password policies and safe practices regarding the selec- 114 tion, secrecy, and maintenance of their passwords. Depending on 115 the specific mechanism used, the purpose of the SAD is to augment 116 (or sometimes replace) the use of a password as a secret key. 118 4. Generic Approach - Two Models 119 As outlined above, there are essentially two types of single-use 120 authentication mechanisms: challenge/response and time-based. In 121 order to support challenge/response mechanisms, the Kerberos Key 122 Distribution Center (KDC) must communicate the appropriate chal- 123 lenge string to the user, via the client software. Furthermore, 124 some challenge/response mechanisms require tight synchronization 125 between all instances of the KDC and the client. One example is 126 S/Key and its variants. If the KDC and client do not perform the 127 same number of message digest iterations, the protocol will fail; 128 worse, it might be possible for an eavesdopping attacker to capture 129 a valid S/Key passcode and replay it to a KDC replica which had an 130 outdated iteration number. In the time-based case, no challenge is 131 required. This naturally gives rise to two modes of client 132 behavior, described below. 134 4.1 Challenge/Response Model 135 The client begins with an initial KRB_AS_REQ message to the KDC, 136 possibly using existing preauthentication methods (PA-ENC-TIMESTAMP 137 (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on 138 whether preauthentication is used, the user may or may not be 139 prompted at this time for a Kerberos password. If (for example) 140 encrypted timestamp preauthentication is used, then the user will 141 be prompted; on the other hand, if no preauthentication is in use 142 the prompt for the password may be deferred (possibly forever). 143 Note that the use of preauthentication here may allow an offline 144 guessing attack against the Kerberos password separate from the 145 SPD. However, if the use of a SAM is required, then the password 146 by itself is not sufficient for authentication. (Specify character 147 strings as UTF-8) 149 The KDC will determine in an implementation- and policy-dependent 150 fashion if the client is required to utilize a single-use authenti- 151 cation mechanism. For example, the implementation may use IP 152 address screening to require principals authenticating from outside 153 a firewall to use a SAM, while principals on the inside need not. 154 If SAM usage is required, then the KDC will respond with a 155 KRB_ERROR message, with the error-code field set to 156 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1 157 structure that is a sequence of PA-DATA fields. 159 If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the 160 client should re-execute the authentication protocol from the 161 beginning, directing messages to another of the KDCs for the realm. 162 This is done to allow some methods to require that a single KDC be 163 used for SAM authentication when tight synchronization is needed 164 between all replicas and the KDC database propagation code does not 165 provide such synchronization. The corresponding padata-value will 166 contain an encoded sequence of host addresses [RFC1510], from which 167 the client must choose the KDC to be contacted next. The PA-SAM- 168 REDIRECT is defined as: 170 PA-SAM-REDIRECT ::= HostAddresses 172 Client implementations SHOULD check the addresses in the PA-SAM- 173 REDIRECT and verify that they are a subset of the KDC addresses 174 that they have been configured for that realm. 176 If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then 177 if one of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the 178 exchange will continue as described in section 5, below. 180 Note that some Kerberos implementations support an older preauthen- 181 tication mechanism with the padata types PA-SAM-CHALLENGE and PA- 182 SAM-RESPONSE. That protocol is depreciated and not defined here. 184 4.2 Time-based Model 185 For mechanisms where no challenge is required, the user (or the 186 client software being utilized) may or may not know a priori 187 whether SAM usage is required. If it does not know, then the ini- 188 tial exchange may proceed as above. If it is known that a use of a 189 single-use authentication mechanism is required then the first 190 exchange can be skipped and the authentication will continue as 191 follows. 193 5. SAM Preauthentication 195 An optional SAM-CHALLENGE-2 may be sent from the KDC to the client 196 and the client will send a SAM-RESPONSE-2 as pre-authentication 197 data in the KRB-AS-REQ. The details of the messages follow. 199 5.1 SAM-CHALLENGE-2 201 Prior to performing preauthentication using a single-use authenti- 202 cation mechanism, the client must know whether a challenge is 203 required (if the client doesn't have this information prior to its 204 sending the first KRB_AS_REQ message, it will be informed of the 205 requirement by the KDC, as described in section 4.1). The client 206 does NOT need to know the specific type of SAM in use. If a chal- 207 lenge is required the client will be sent the challenge by the KDC. 208 This means that a client supporting SAMs will be able to work with 209 new methods without modification. The challenge, as well as all 210 other prompts mentioned herein, can be internationalized by the KDC 211 on a per-principal basis. 213 If a KRB_ERROR message is received from the KDC indicating that SAM 214 usage is required, that message will include in its e-data field a 215 PA-DATA structure that encodes information about the SAM to be 216 used. This includes whether a challenge is required, and if so, 217 the challenge itself; and informational data about the type of SAM 218 that is in use, and how to prompt for the SAD. The SAM type is 219 informational only and does not affect the behavior of the client. 220 The prompt is also informational and may be presented to the user 221 by the client, or it may be safely ignored. 223 The ASN.1 definition for the SAM challenge is: 225 PA-SAM-CHALLENGE-2 ::= SEQUENCE { 226 sam-type[0] INTEGER, 227 sam-flags[1] SAMFlags, 228 sam-type-name[2] GeneralString OPTIONAL, 229 sam-track-id[3] GeneralString OPTIONAL, 230 sam-challenge-label[4] GeneralString OPTIONAL, 231 sam-challenge[5] GeneralString OPTIONAL, 232 sam-response-prompt[6] GeneralString OPTIONAL, 233 sam-pk-for-sad[7] EncryptionKey OPTIONAL, 234 sam-nonce[8] INTEGER, 235 sam-cksum[9] SEQUENCE OF Checksum, 236 sam-etype[10] INTEGER, 237 ... 238 } 240 SAMFlags ::= BIT STRING { 241 use-sad-as-key[0], 242 send-encrypted-sad[1], 243 must-pk-encrypt-sad[2], 244 ... 245 } 247 5.1.1 SAM-TYPE and SAM-TYPE-NAME Fields 249 The sam-type field is informational only, but it must be specified 250 and sam-type values must be registered with the IANA. 252 Initially defined values of the sam-type codes are: 254 PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic 255 PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways 256 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0 257 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key 258 PA_SAM_TYPE_SECURID 5 -- Security Dynamics 259 PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard 261 PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and 262 PA_SAM_TYPE_CRYPTOCARD represent popular token cards. 263 PA_SAM_TYPE_SKEY is the traditional S/Key protocol, in which the 264 SAD verifier does not have knowledge of the principal's S/Key 265 secret. PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the 266 same SAD and PC software or hardware device, but where the zeroth 267 key (the S/Key secret) is actually stored on, and can be used by, 268 the SAD verifier to independently generate the correct authentica- 269 tion data. 271 Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of 272 S/Key, viz., that the information required to generate the SAD need 273 not be stored on the host; but since the SAD verifier (which may be 274 the KDC) is assumed to be more secure than other hosts on the net- 275 work, it may be acceptable to give up this advantage in some situa- 276 tions. The advantage of using this S/Key variant is that the secu- 277 rity of the network protocol is strengthened since the SAD need not 278 be sent from the client to the KDC. Thus, the SAD can be used as 279 part of the key used to encrypt the encrypted parts of both the SPD 280 and the KRB_AS_REP message, rather than being sent protected by the 281 principal's Kerberos secret key which may have been previously 282 exposed to an attacker (see section 6, below). In any case, there 283 is a definite advantage to being interoperable with the S/Key algo- 284 rithm. 286 Due to the volatility of, and rapid developments in, the area of 287 single-use authentication mechanisms (both software-only and 288 hardware supported), any subsequently defined sam-type codes will 289 be maintained by the IANA. 291 The optional sam-type-name field is a UTF-8 character string for 292 informational use only. It may be used by the client to display a 293 short description of the type of single-use authentication mechan- 294 ism to be used. 296 5.1.2 SAM-FLAGS Field 298 The sam-flags field indicates whether the SAD is known by the KDC 299 (in which case it can be used as part of the encryption key for the 300 ensuing KRB_AS_REP message), or if it must be provided to the KDC 301 in a recoverable manner. If it is known to the KDC, use-sad-as-key 302 indicates that the SAD alone will be used to generate the encryp- 303 tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages, 304 and that the user will not need to also enter a password. We 305 recommend that this option only be used if the SAD will be used to 306 generate adequate keying material (sufficient length, secrecy, ran- 307 domness) for the cryptographic algorithm used. If the single-use 308 authentication data is not known (and cannot be generated or 309 discovered) by the KDC, then send-encrypted-sad flag will be set, 310 indicating that the SAD must be sent to the KDC encrypted under the 311 principal's secret key. If neither use-sad-as-key nor send- 312 encrypted-sad are set, the client may assume that the KDC knows the 313 SAD, but the Kerberos password should be used along with the 314 passcode in the derivation of the encryption key (see below). No 315 more than one of the send-encrypted-sad and use-sad-as-key flags 316 shoudl be in a SAM-CHALLENGE-2. 318 The must-pk-encrypt-sad flag is reserved for future use. If this 319 flag is set and a client does not support the must-pk-encrypt-sad 320 option (to be defined in a separate document), the client will not 321 be able to complete the authentication and must notify the user. 323 5.1.3 SAM-CHECKSUM Field 325 The sam-cksum field contains a sequence of at least one crypto- 326 graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence. 327 If the send-encrypted-sad flag is set, the key to be used for this 328 checksum is the client's long-term secret. If the use-sad-as-key 329 flag is set, then the SAD alone will be used as the key. If nei- 330 ther flag is set, then the key used for this checksum is derived 331 from the SAD and the user's password (see section 5.2). 333 The checksum algorithm to be used for this is the mandatory check- 334 sum associated with the encryption algorithm specified in the sam- 335 etype field, with a key usage of 25. 337 In some cases there may be more than one valid SAD; some preauthen- 338 tication mechanisms may have a range of valid responses. In that 339 case, the KDC may elect to return multiple checksums, one for each 340 possible SAD response. The number of possible responses of course 341 depends on the mechanism and site policy. In the case where multi- 342 ple checksums are returned, the client MUST try each checksum in 343 turn until one of the checksums is verified successfully. Note 344 that in the non-send-encrypted-sad case the checksum cannot be ver- 345 ified until the user enters in the SAD, but if no checksum can be 346 verified, the client MUST not send a response but instead return an 347 error to the user. 349 The sam-cksum field is generated by encoding the entire SAM- 350 CHALLENGE-2 sequence with a zero-length sam-cksum sequence. The 351 checksums are calculated over this encoding, and the SAM- 352 CHALLENGE-2 sequence is reencoded with all of the checksums in 353 place. Checksum verification is done by reencoding the decoded 354 SAM-CHALLENGE-2 sequence with a zero-length sam-cksum and trying 355 checksums until a valid one is found. 357 If no checksum is included, or is of the wrong type, or none are 358 found which are correct, the client MUST abort the dialogue with 359 the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM, 360 KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes- 361 sages. 363 5.1.4 SAM-TRACK-ID Field 365 The optional sam-track-id field may be returned by the KDC in the 366 KRB_ERROR message. If present, the client MUST copy this field 367 into the corresponding field of the SAM response sent in the subse- 368 quent KRB_AS_REQ message. This field may be used by the KDC to 369 match challenges and responses. It might be a suitably encoded 370 integer, or even be encrypted data with the KDC state encoded so 371 that the KDC doesn't have to maintain the state internally. Note 372 that when a KDC supplies a sam-track-id, it MUST link the sam- 373 track-id with the sam-nonce field to prevent spoofing of the sam- 374 track-id field. 376 The key usage type 26 is reserved for use to encrypt the sam- 377 track-id data. The key used to encrypt the sam-track-id is 378 mechanism-dependent. 380 5.1.5 SAM-CHALLENGE-LABEL Field 382 The sam-challenge-label field is informational and optional. If it 383 is included, is will be an UTF-8 encoded character. If present, a 384 client may choose to precede the presentation of the challenge with 385 this string. For example, if the challenge is 135773 and the 386 string in the sam-challenge-label field is "Enter the following 387 number on your card", the client may choose to display to the user: 389 Enter the following number on your card: 135773 391 If no challenge label was presented, or if the client chooses to 392 ignore it, the client might display instead: 394 Challenge from authentication server: 135773 396 Internationalization is supported by allowing customization of the 397 challenge label and other strings on a per-principal basis. Note 398 that this character string should be encoded using UTF-8. 400 5.1.6 SAM-CHALLENGE Field 402 The optional sam-challenge field contains a string that will be 403 needed by the user to generate a suitable response. If the sam- 404 challenge field is left out, it indicates that the SAM in use does 405 not require a challenge, and that the authorized user should be 406 able to produce the correct SAD without one. If the sam-challenge 407 field is present, it is the data that is used by the SAD generator 408 to create the SAD to be used in the production of the SPD to be 409 included in the response. 411 5.1.7 SAM-RESPONSE-PROMPT Field 413 The sam-response-prompt field is informational and optional. If 414 present, a client may choose to precede the prompt for the response 415 with the specified string. 417 Passcode: 419 5.1.8 SAM-PK-FOR-SAD Field 421 sam-pk-for-sad is an optional field. It is included in the 422 interest of future extensability of the protocol to the use of 423 public-key cryptography. 425 5.1.9 SAM-NONCE Field 427 The sam-nonce is a KDC-supplied nonce and should conform to the 428 specification of the nonce field in a KRB_KDC_REQ message 429 [RFC1510]. 431 Challenge/Response mechanisms MUST link the nonce field with the 432 sam-track-id (if one is included) to prevent replay of the sam- 433 track-id field. 435 5.1.10 SAM-ETYPE Field 437 The sam-etype field contains the encryption type to be used by the 438 client for all encrypted fields in the PA-SAM-RESPONSE-2 message. 439 The KDC should pick an appropriate encryption algorithm based on 440 the encryption algorithms listed in the client's initial 441 KRB_AS_REQ. 443 5.2 Obtaining SAM Authentication Data 445 If the client is performing SAM preauthentication in the initial 446 message, without receipt of a PA-SAM-CHALLENGE-2 (i.e. without 447 waiting for the KRB_ERROR message), and the SAM in use does not 448 require a challenge, the client will prompt for the SAD in an 449 application-specific manner. 451 Once the user has been prompted for and entered the SAD (and possi- 452 bly the Kerberos password), the client will derive a key to be used 453 to encrypt the preauthentication data for a KRB_AS_REQ message. 454 This key will be determined as follows: 456 By default, the key is derived from the password and the SAD 457 by running each through the string_to_key function [RFC1510] 458 separately; i.e., K1 = string_to_key(password) and K2 = 459 string_to_key(SAD). The K1 and K2 are then combined to form 460 a single key K using the algorithm described in Appendix A. 462 If the send-encrypted-sad flag is set, the key will be 463 derived by running the Kerberos password though the 464 string_to_key function in the normal fashion. 466 If the use-sad-as-key flag is set and the integrity of the 467 PA-SAM-CHALLENGE-2 PADATA field can be verified using the 468 sam-cksum field, then the SAD is run through the 469 string_to_key function and the result is used as the encryp- 470 tion key for the request. WARNING: the use of single-use 471 authentication data in this manner is NOT recommended unless 472 the range of the SAD is large enough to make an exhaustive 473 off-line search impractical and the risks involved in the 474 use of SAD alone are fully considered. Also, note that 475 without the availability to the KDC of a relatively static, 476 unique secret key shared with the user, the only mechanisms 477 that can be used to protect the integrity of the PA-SAM- 478 CHALLENGE-2 PADATA field are based on either public key 479 cryptography or the KDC's a priori knowledge of the SAD 480 itself. In the latter case, the client must obtain the SAD 481 from the user and use it to verify the integrity of the 482 challenge before the new KRB_AS_REQ message is sent. 484 The sam-pk-for-sad field is reserved for future use. If 485 this field is not empty and the client does not support the 486 use of public-key encryption for SAD (to be defined in a 487 separate document), the client will not be able to complete 488 the authentication and must notify the user. 490 5.3 SAM-RESPONSE PA-DATA 492 The client will then send another KRB_AS_REQ message to the KDC, 493 but with a padata field with padata-type equal to PA-SAM-RESPONSE-2 494 and padata-value defined as follows: 496 PA-SAM-RESPONSE-2 ::= SEQUENCE { 497 sam-type[0] INTEGER, 498 sam-flags[1] SAMFlags, 499 sam-track-id[2] GeneralString OPTIONAL, 500 sam-enc-nonce-or-sad[3] EncryptedData 501 -- PA-ENC-SAM-RESPONSE-ENC, 502 sam-nonce[4] INTEGER, 503 ... 504 } 506 PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE { 507 sam-nonce[0] INTEGER, 508 sam-sad[1] GeneralString OPTIONAL, 509 ... 510 } 512 The source of the data included in the PA-SAM-RESPONSE-2 structure 513 depends upon whether or not a KRB_ERROR message was received by the 514 client from the KDC. 516 5.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields 518 If an error reply was received, the sam-type, sam-flags, and sam- 519 nonce fields will contain copies of the same fields from the error 520 message. 522 If no error reply was received (i.e., the client knows that a 523 single-use authentication mechanism is to be used), the sam-type 524 field must be set to a value chosen from the list of registered 525 sam-type codes. 527 The value of the sam-flags field may vary depending upon the type 528 of SAM in use, but in all cases the must-pk-encrypt-sad flag must 529 be zero. If the send-encrypted-sad flag is set, the sam-sad field 530 must contain the entered single-use authentication data (see 531 Section 5.3.3). 533 5.3.2 SAM-TRACK-ID Field 535 Note that is there is no sam-track-id in the request, it should be 536 omitted in the response. Otherwise, the sam-track-id data must be 537 copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2. 539 5.3.3 SAM-ENC-NONCE-OR-SAD 541 The sam-enc-nonce-or-sad field represends the results of the preau- 542 thentication process. It contains the encrypted SAD or a SAD- 543 encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted 544 with the SAD, password + SAD, or password (based on the sam-flags) 545 with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes- 546 sage are populated as follows: 548 The sam-nonce contains the nonce from the SAM-CHALLENGE-2. This is 549 the same as the unencrypted sam-nonce described in section 5.2.2. 551 The sam-sad field contains the SAD if send-encrypted-sad is set in 552 the sam-flags. Otherwise, it is omitted. 554 5.4 Verification of the SAM-RESPONSE-2 556 Upon receipt the KDC validates this PADATA in much the same way 557 that it validates the PA-ENC-TS preauthentication method except 558 that it uses the SAD (if available, and possibly in conjunction 559 with saved state information or portions of the preauthentication 560 data) to determine the correct key(s) required to verify the 561 encrypted data. Note that if the KDC uses the sam-track-id field 562 to encode its state, the SAM-verification routine is responsible 563 for including information in that field to detect modification or 564 replay by an attacker. 566 5.5 KRB5-AS-REP 568 The rest of the processing of the request proceeds normally, except 569 that instead of being encrypted in the user's secret key, the 570 KRB_AS_REP message is encrypted in the key obtained above. Note, 571 however, that some single-use authentication mechanisms may require 572 further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication; 573 for example, in order to allow the server to resynchronize with the 574 drifting clock on a time-based token card. In these cases the KDC 575 may respond with another KRB_ERROR message containing a different 576 sam-type value, along with appropriate prompts and/or challenges. 577 This sequence of exchanges will continue until authentication 578 either succeeds or fails. 580 6. Requirements for Single-use Authentication Mechanisms 582 Single-Use Authentication Mechanisms vary in their capabilities. 583 To aid implementers, we summarize here how various types of SAMs 584 would operate using this protocool. 586 If a SAM system can provide a SAD or a sequence of valid SADs to 587 the KDC, then the implementation should NOT set the send- 588 encrypted-sad flag. This SAM system should provide the SAD to the 589 KDC, which will combine it with the user's long-term key (password) 590 to generate the key used to generate the checksum placed in the 591 sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined 592 key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes- 593 sage by using it to decrypt the sam-enc-nonce-or-sad field and as 594 the key to encrypt the KRB-AS-REP. If a SAM system returns a range 595 of valid responses, each response can be used to generate a valid 596 checksum which can be placed in the sam-cksum sequence. 598 If a SAM system can generate enough entropy, it can set the use- 599 sad-as-key field to use the SAD solely as keying material, but it 600 should be noted that most SAM systems that require the user to 601 enter in a response do not have enough entropy to replace the 602 user's long-term key. The most likely consumer of use-sad-as-key 603 is a hardware token which communicates a key directly with Kerberos 604 client software. With or without the use of use-sad-as-key, this 605 is the preferred method as it protects against offline dictionary 606 attacks against the user's password. 608 If a SAM system cannot provide a SAD or a sequence of SADs to the 609 KDC, then the send-encrypted-sad flag must be set. In this case, 610 the SAD will be encrypted using the user's long-term key in the 611 PA-SAM-RESPONSE-2 message. It should be noted that this is a 612 weaker solution, as it does not protect the user's password against 613 offline dictionary attacks, and any additional entropy provided by 614 the SAM system cannot be used. 616 7. Security considerations 618 Single-use authentication mechanisms requiring the use of the 619 send-encrypted-sad option are discouraged as their use on the net- 620 work is less secure than the case where a combination of the users 621 password and SAD is used as the encryption key. In particular, 622 when the send-encrypted-sad option is used, an attacker who 623 observes the response and is in possession of the users' secret key 624 (which doesn't change from login to login) can use the key to 625 decrypt the response and obtain the single-use authentication data. 626 This is dependent on the SAM technology used. 628 If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field 629 but the client software being used does not support public-key 630 cryptography, it is possible that legitimate users may be denied 631 service. 633 An attacker in possession of the users encryption key (again, which 634 doesn't change from login to login) might be able to 635 generate/modify a SAM challenge and attach the appropriate check- 636 sum. This affects the security of both the send-encrypted-sad 637 option and the must-pk-encrypt-sad option. 639 8. Expiration 640 This Internet-Draft expires on December 22, 2002. 642 9. References 644 [RFC1510] 645 The Kerberos Network Authentication System; Kohl and Neuman; 646 September 1993. 648 [RFC1760] 649 The S/Key One-Time Password System; Haller; February 1995 651 [RFC1636] 652 Report of IAB Workshop on Security in the Internet Architec- 653 ture; Braden, Clark, Crocker and Huitema; June 1994 655 [KCRYPTO] 656 Encryption and Checksum Specifications for Kerberos 5; Rae- 657 burn; May 2002 659 10. Authors' Addresses 660 B. Clifford Neuman 661 USC/Information Sciences Institute 662 4676 Admiralty Way #1001 663 Marina del Rey, CA 90292-6695 665 Phone: 310-822-1511 666 EMail: bcn@isi.edu 668 Glen Zorn 669 Cisco Systems 670 500 108th Ave NE 671 Suite 500 672 Bellevue, WA 98004 674 Phone: 425-344-8113 675 EMail: gwz@cisco.com 677 Ken Hornstein 678 Naval Research Laboratory 679 4555 Overlook Avenue 680 Washington, DC 20375 682 Phone: 202-404-4765 683 EMail: kenh@cmf.nrl.navy.mil 685 Ken Renard 686 WareOnEarth 687 6849 Old Dominion Dr, Suite 365 688 Annandale, VA 22003 690 Phone: 703-622-3469 691 EMail: kdrenard@wareonearth.com 693 Appendix A - Key combination algorithm 695 Definitions: 697 DR - generate "random" data from an encryption key (defined in 698 [KCRYPTO]) 700 n-fold - "stretches" or "shrinks" a sequence bits to a specified 701 size (defined in [KCRYPTO]) 703 random-to-key - Generates an encryption key from random input 704 (defined in [KCRYPTO]) 706 DK - Derive-Key, defined in [KCRYPTO]) 708 CombineConstant - The ASCII encoding of the string "combine", which 709 is defined as the following byte string: 711 { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 } 713 Note: | means "concatenate" 715 Given two input keys, K1 and K2, the Combine-Key function is as 716 follows: 718 R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1)) 720 rnd = n-fold(R1 | R2) 722 tkey = random-to-key(rnd) 724 Combine-Key(K1, K2) = DK(tkey, CombineConstant)