1INTERNET-DRAFT Ken Hornstein 2<draft-ietf-krb-wg-kerberos-sam-02.txt> Naval Research Laboratory 3Updates: RFC 1510 Ken Renard 4October 27, 2003 WareOnEarth 5 Clifford Newman 6 ISI 7 Glen Zorn 8 Cisco Systems 9 10 11 12 Integrating Single-use Authentication Mechanisms with Kerberos 13 14 150. Status Of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. Internet-Drafts are working documents of 18 the Internet Engineering Task Force (IETF), its areas, and its 19 working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 21 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other docu- 24 ments at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as ``work in pro- 26 gress.'' 27 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- 30 dow Directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 32 Rim). 33 34 The distribution of this memo is unlimited. It is filed as 35 <draft-ietf-krb-wg-kerberos-sam-02.txt>, and expires April 27, 36 2004. Please send comments to the authors. 37 38 391. Abstract 40 This document defines extensions to the Kerberos protocol specifi- 41 cation [RFC1510] which provide a method by which a variety of 42 single-use authentication mechanisms may be supported within the 43 protocol. The method defined specifies a standard fashion in which 44 the preauthentication data and error data fields in Kerberos mes- 45 sages may be used to support single-use authentication mechanisms. 46 47 482. Terminology 49 To simplify the following discussion, we will define those terms 50 which may be unfamiliar to the audience or specific to the discus- 51 sion itself. 52 53 Single-use Preauthentication Data (SPD): Data sent in the padata- 54 value field of a Kerberos V5 message proving that knowledge of 55 56 57 58Hornstein, Renard, Newman, Zorn [Page 1] 59 60 61 62 63 64INTERNET-DRAFT October 27, 2003 65 66 67 certain unique information is held by a principal. This informa- 68 tion may or may not be identical to the single-use authentication 69 data input to the client. For example, in the case of S/Key, the 70 principal might input a one-time password (in any of several 71 forms); the knowledge of this one-time password is taken to indi- 72 cate knowledge of the principal's secret passphrase. Similarly, 73 the SPD may or may not contain the provided single-use authentica- 74 tion data. For instance, if a given single-use authentication 75 mechanism includes a token which generates an encryption key for a 76 supported cryptosystem, that key could be used to encrypt portions 77 of the SPD before transmission. As long as the verification pro- 78 cess of the mechanism was capable of independently generating the 79 same key, the successful decryption of the SPD would provide 80 assurance that the originator of the message was in possession of 81 the token, as well as whatever information the token required to 82 generate the encryption key. 83 84 Single-use Authentication Mechanism (SAM): A system for generating 85 and verifying authentication data which is usable only once. 86 87 Single-use Authentication Data (SAD): SAM-specific data provided 88 by a principal as input to client software to be used in the crea- 89 tion of SPD. 90 91 923. Motivation and Scope 93 Several single-use authentication mechanisms are currently in 94 widespread use, including hardware-based schemes from vendors such 95 as Enigma Logic, CRYPTOCard, and Security Dynamics and software- 96 based methods like S/Key [RFC1760]. The hardware-based schemes 97 typically require that the authenticating user carry a small, 98 credit-card-sized electronic device (called a token) which is used 99 to generate unique authentication data. Some tokens require the 100 user to enter data into the device. This input may take the form 101 of a Personal Identification Number (PIN), a server-generated chal- 102 lenge string or both. Other tokens do not use a challenge-response 103 technique, instead spontaneously generating new and unique authen- 104 tication data every few seconds. These tokens are usually time- 105 synchronized with a server. The use of one-time passwords and 106 token cards as an authentication mechanism has steadily increased 107 over the past few years; in addition, the Internet Architecture 108 Board has encouraged the use of SAMs to improve Internet security 109 [RFC1636]. 110 111 The widespread acceptance of Kerberos within the Internet community 112 has produced considerable demand for the integration of SAM tech- 113 nology with the authentication protocol. Several currently avail- 114 able implementations of Kerberos include support for some types of 115 token cards, but the implementations are either not interoperable, 116 or would require the release of source code (not always an option) 117 to make them interoperate. This memo attempts to remedy that prob- 118 lem by specifying a method in which SAM data may be securely tran- 119 sported in Kerberos V5 messages in a standard, extensible fashion. 120 This document does not, however, attempt to precisely specify 121 122 123 124Hornstein, Renard, Newman, Zorn [Page 2] 125 126 127 128 129 130INTERNET-DRAFT October 27, 2003 131 132 133 either the generation or verification of SAM data, since this is 134 likely to be SAM-specific; nor does it dictate the conditions under 135 which SAM data must be included in Kerberos messages, since we con- 136 sider this to be a matter of local policy. 137 138 A primary reason for using a SAM with Kerberos is to reduce the 139 threat from common attacks on Kerberos passwords (poorly chosen 140 passwords, password guessing, etc). If passwords are used in com- 141 bination with SAM authentication data, users must still adhere to 142 sensible password policies and safe practices regarding the selec- 143 tion, secrecy, and maintenance of their passwords. Depending on 144 the specific mechanism used, the purpose of the SAD is to augment 145 (or sometimes replace) the use of a password as a secret key. 146 147 1484. Generic Approach - Two Models 149 As outlined above, there are essentially two types of single-use 150 authentication mechanisms: challenge/response and time-based. In 151 order to support challenge/response mechanisms, the Kerberos Key 152 Distribution Center (KDC) must communicate the appropriate chal- 153 lenge string to the user, via the client software. Furthermore, 154 some challenge/response mechanisms require tight synchronization 155 between all instances of the KDC and the client. One example is 156 S/Key and its variants. If the KDC and client do not perform the 157 same number of message digest iterations, the protocol will fail; 158 worse, it might be possible for an eavesdropping attacker to cap- 159 ture a valid S/Key passcode and replay it to a KDC replica which 160 had an outdated iteration number. In the time-based case, no chal- 161 lenge is required. This naturally gives rise to two modes of 162 client behavior, described below. 163 164 1654.1 Challenge/Response Model 166 The client begins with an initial KRB_AS_REQ message to the KDC, 167 possibly using existing preauthentication methods (PA-ENC-TIMESTAMP 168 (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on 169 whether preauthentication is used, the user may or may not be 170 prompted at this time for a Kerberos password. If (for example) 171 encrypted timestamp preauthentication is used, then the user will 172 be prompted; on the other hand, if no preauthentication is in use 173 the prompt for the password may be deferred (possibly forever). 174 Note that the use of preauthentication here may allow an offline 175 guessing attack against the Kerberos password separate from the 176 SPD. However, if the use of a SAM is required, then the password 177 by itself is not sufficient for authentication. (Specify character 178 strings as UTF-8) 179 180 The KDC will determine in an implementation- and policy-dependent 181 fashion if the client is required to utilize a single-use authenti- 182 cation mechanism. For example, the implementation may use IP 183 address screening to require principals authenticating from outside 184 a firewall to use a SAM, while principals on the inside need not. 185 If SAM usage is required, then the KDC will respond with a 186 KRB_ERROR message, with the error-code field set to 187 188 189 190Hornstein, Renard, Newman, Zorn [Page 3] 191 192 193 194 195 196INTERNET-DRAFT October 27, 2003 197 198 199 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1 200 structure that is a sequence of PA-DATA fields. 201 202 If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the 203 client should re-execute the authentication protocol from the 204 beginning, directing messages to another of the KDCs for the realm. 205 This is done to allow some methods to require that a single KDC be 206 used for SAM authentication when tight synchronization is needed 207 between all replicas and the KDC database propagation code does not 208 provide such synchronization. The corresponding padata-value will 209 contain an encoded sequence of host addresses [RFC1510], from which 210 the client must choose the KDC to be contacted next. The PA-SAM- 211 REDIRECT is defined as: 212 213 214 PA-SAM-REDIRECT ::= HostAddresses 215 216 217 Client implementations SHOULD check the addresses in the PA-SAM- 218 REDIRECT and verify that they are a subset of the KDC addresses 219 that they have been configured for that realm. 220 221 If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then 222 if one of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the 223 exchange will continue as described in section 5, below. 224 225 Note that some Kerberos implementations support an older preauthen- 226 tication mechanism with the padata types PA-SAM-CHALLENGE and PA- 227 SAM-RESPONSE. That protocol is depreciated and not defined here. 228 229 2304.2 Time-based Model 231 For mechanisms where no challenge is required, the user (or the 232 client software being utilized) may or may not know a priori 233 whether SAM usage is required. If it does not know, then the ini- 234 tial exchange may proceed as above. If it is known that a use of a 235 single-use authentication mechanism is required then the first 236 exchange can be skipped and the authentication will continue as 237 follows. 238 239 2405. SAM Preauthentication 241 242 An optional SAM-CHALLENGE-2 may be sent from the KDC to the client 243 and the client will send a SAM-RESPONSE-2 as pre-authentication 244 data in the KRB-AS-REQ. The details of the messages follow. 245 2465.1 SAM-CHALLENGE-2 247 248 Prior to performing preauthentication using a single-use authenti- 249 cation mechanism, the client must know whether a challenge is 250 required (if the client doesn't have this information prior to its 251 sending the first KRB_AS_REQ message, it will be informed of the 252 requirement by the KDC, as described in section 4.1). The client 253 254 255 256Hornstein, Renard, Newman, Zorn [Page 4] 257 258 259 260 261 262INTERNET-DRAFT October 27, 2003 263 264 265 does NOT need to know the specific type of SAM in use. If a chal- 266 lenge is required the client will be sent the challenge by the KDC. 267 This means that a client supporting SAMs will be able to work with 268 new methods without modification. The challenge, as well as all 269 other prompts mentioned herein, can be internationalized by the KDC 270 on a per-principal basis. 271 272 If a KRB_ERROR message is received from the KDC indicating that SAM 273 usage is required, that message will include in its e-data field a 274 PA-DATA structure that encodes information about the SAM to be 275 used. This includes whether a challenge is required, and if so, 276 the challenge itself; and informational data about the type of SAM 277 that is in use, and how to prompt for the SAD. The SAM type is 278 informational only and does not affect the behavior of the client. 279 The prompt is also informational and may be presented to the user 280 by the client, or it may be safely ignored. 281 282 The ASN.1 definition for the SAM challenge is: 283 284 PA-SAM-CHALLENGE-2 ::= SEQUENCE { 285 sam-body[0] PA-SAM-CHALLENGE-2-BODY, 286 sam-cksum[1] SEQUENCE (1..MAX) OF Checksum, 287 ... 288 } 289 290 PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE { 291 sam-type[0] INTEGER (0..4294967295), 292 sam-flags[1] SAMFlags, 293 sam-type-name[2] GeneralString OPTIONAL, 294 sam-track-id[3] GeneralString OPTIONAL, 295 -- Key usage of 26 296 sam-challenge-label[4] GeneralString OPTIONAL, 297 sam-challenge[5] GeneralString OPTIONAL, 298 sam-response-prompt[6] GeneralString OPTIONAL, 299 sam-pk-for-sad[7] OCTET STRING OPTIONAL, 300 sam-nonce[8] INTEGER (0..4294967295), 301 sam-etype[9] INTEGER (0..4294967295), 302 ... 303 } 304 305 SAMFlags ::= BIT STRING (SIZE (32..MAX)) 306 -- use-sad-as-key(0) 307 -- send-encrypted-sad(1) 308 -- must-pk-encrypt-sad(2) 309 3105.1.1 SAM-TYPE and SAM-TYPE-NAME Fields 311 312 The sam-type field is informational only, but it must be specified 313 and sam-type values must be registered with the IANA. 314 315 Initially defined values of the sam-type codes are: 316 317 PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic 318 PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways 319 320 321 322Hornstein, Renard, Newman, Zorn [Page 5] 323 324 325 326 327 328INTERNET-DRAFT October 27, 2003 329 330 331 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0 332 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key 333 PA_SAM_TYPE_SECURID 5 -- Security Dynamics 334 PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard 335 336 PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and 337 PA_SAM_TYPE_CRYPTOCARD represent popular token cards. 338 PA_SAM_TYPE_SKEY is the traditional S/Key protocol, in which the 339 SAD verifier does not have knowledge of the principal's S/Key 340 secret. PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the 341 same SAD and PC software or hardware device, but where the zeroth 342 key (the S/Key secret) is actually stored on, and can be used by, 343 the SAD verifier to independently generate the correct authentica- 344 tion data. 345 346 Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of 347 S/Key, viz., that the information required to generate the SAD need 348 not be stored on the host; but since the SAD verifier (which may be 349 the KDC) is assumed to be more secure than other hosts on the net- 350 work, it may be acceptable to give up this advantage in some situa- 351 tions. The advantage of using this S/Key variant is that the secu- 352 rity of the network protocol is strengthened since the SAD need not 353 be sent from the client to the KDC. Thus, the SAD can be used as 354 part of the key used to encrypt the encrypted parts of both the SPD 355 and the KRB_AS_REP message, rather than being sent protected by the 356 principal's Kerberos secret key which may have been previously 357 exposed to an attacker (see section 6, below). In any case, there 358 is a definite advantage to being interoperable with the S/Key algo- 359 rithm. 360 361 Due to the volatility of, and rapid developments in, the area of 362 single-use authentication mechanisms (both software-only and 363 hardware supported), any subsequently defined sam-type codes will 364 be maintained by the IANA. 365 366 The optional sam-type-name field is a UTF-8 character string for 367 informational use only. It may be used by the client to display a 368 short description of the type of single-use authentication mechan- 369 ism to be used. 370 3715.1.2 SAM-FLAGS Field 372 373 The sam-flags field indicates whether the SAD is known by the KDC 374 (in which case it can be used as part of the encryption key for the 375 ensuing KRB_AS_REP message), or if it must be provided to the KDC 376 in a recoverable manner. If it is known to the KDC, use-sad-as-key 377 indicates that the SAD alone will be used to generate the encryp- 378 tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages, 379 and that the user will not need to also enter a password. We 380 recommend that this option only be used if the SAD will be used to 381 generate adequate keying material (sufficient length, secrecy, ran- 382 domness) for the cryptographic algorithm used. If the single-use 383 authentication data is not known (and cannot be generated or 384 discovered) by the KDC, then send-encrypted-sad flag will be set, 385 386 387 388Hornstein, Renard, Newman, Zorn [Page 6] 389 390 391 392 393 394INTERNET-DRAFT October 27, 2003 395 396 397 indicating that the SAD must be sent to the KDC encrypted under the 398 principal's secret key. If neither use-sad-as-key nor send- 399 encrypted-sad are set, the client may assume that the KDC knows the 400 SAD, but the Kerberos password should be used along with the 401 passcode in the derivation of the encryption key (see below). No 402 more than one of the send-encrypted-sad and use-sad-as-key flags 403 should be in a SAM-CHALLENGE-2. 404 405 The must-pk-encrypt-sad flag is reserved for future use. If this 406 flag is set and a client does not support the must-pk-encrypt-sad 407 option (to be defined in a separate document), the client will not 408 be able to complete the authentication and must notify the user. 409 4105.1.3 SAM-CHECKSUM Field 411 412 The sam-cksum field contains a sequence of at least one crypto- 413 graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence. 414 If the send-encrypted-sad flag is set, the key to be used for this 415 checksum is the client's long-term secret. If the use-sad-as-key 416 flag is set, then the SAD alone will be used as the key. If nei- 417 ther flag is set, then the key used for this checksum is derived 418 from the SAD and the user's password (see section 5.2). 419 420 The checksum algorithm to be used for this is the mandatory check- 421 sum associated with the encryption algorithm specified in the sam- 422 etype field, with a key usage of 25. 423 424 In some cases there may be more than one valid SAD; some preauthen- 425 tication mechanisms may have a range of valid responses. In that 426 case, the KDC may elect to return multiple checksums, one for each 427 possible SAD response. The number of possible responses of course 428 depends on the mechanism and site policy. In the case where multi- 429 ple checksums are returned, the client MUST try each checksum in 430 turn until one of the checksums is verified successfully. Note 431 that in the non-send-encrypted-sad case the checksum cannot be ver- 432 ified until the user enters in the SAD, but if no checksum can be 433 verified, the client MUST not send a response but instead return an 434 error to the user. 435 436 The sam-cksum field is generated by calculating the specified 437 checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence. 438 439 If no checksum is included, or is of the wrong type, or none are 440 found which are correct, the client MUST abort the dialogue with 441 the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM, 442 KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes- 443 sages. 444 4455.1.4 SAM-TRACK-ID Field 446 447 The optional sam-track-id field may be returned by the KDC in the 448 KRB_ERROR message. If present, the client MUST copy this field 449 into the corresponding field of the SAM response sent in the subse- 450 quent KRB_AS_REQ message. This field may be used by the KDC to 451 452 453 454Hornstein, Renard, Newman, Zorn [Page 7] 455 456 457 458 459 460INTERNET-DRAFT October 27, 2003 461 462 463 match challenges and responses. It might be a suitably encoded 464 integer, or even be encrypted data with the KDC state encoded so 465 that the KDC doesn't have to maintain the state internally. Note 466 that when a KDC supplies a sam-track-id, it MUST link the sam- 467 track-id with the sam-nonce field to prevent spoofing of the sam- 468 track-id field. 469 470 The key usage type 26 is reserved for use to encrypt the sam- 471 track-id data. The key used to encrypt the sam-track-id is 472 mechanism-dependent. 473 4745.1.5 SAM-CHALLENGE-LABEL Field 475 476 The sam-challenge-label field is informational and optional. If it 477 is included, is will be an UTF-8 encoded character. If present, a 478 client may choose to precede the presentation of the challenge with 479 this string. For example, if the challenge is 135773 and the 480 string in the sam-challenge-label field is "Enter the following 481 number on your card", the client may choose to display to the user: 482 483 Enter the following number on your card: 135773 484 485 If no challenge label was presented, or if the client chooses to 486 ignore it, the client might display instead: 487 488 Challenge from authentication server: 135773 489 490 Internationalization is supported by allowing customization of the 491 challenge label and other strings on a per-principal basis. Note 492 that this character string should be encoded using UTF-8. 493 4945.1.6 SAM-CHALLENGE Field 495 496 The optional sam-challenge field contains a string that will be 497 needed by the user to generate a suitable response. If the sam- 498 challenge field is left out, it indicates that the SAM in use does 499 not require a challenge, and that the authorized user should be 500 able to produce the correct SAD without one. If the sam-challenge 501 field is present, it is the data that is used by the SAD generator 502 to create the SAD to be used in the production of the SPD to be 503 included in the response. 504 5055.1.7 SAM-RESPONSE-PROMPT Field 506 507 The sam-response-prompt field is informational and optional. If 508 present, a client may choose to precede the prompt for the response 509 with the specified string. 510 511 Passcode: 512 5135.1.8 SAM-PK-FOR-SAD Field 514 515 sam-pk-for-sad is an optional field. It is included in the 516 interest of future extensability of the protocol to the use of 517 518 519 520Hornstein, Renard, Newman, Zorn [Page 8] 521 522 523 524 525 526INTERNET-DRAFT October 27, 2003 527 528 529 public-key cryptography. 530 5315.1.9 SAM-NONCE Field 532 533 The sam-nonce is a KDC-supplied nonce and should conform to the 534 specification of the nonce field in a KRB_KDC_REQ message 535 [RFC1510]. 536 537 Challenge/Response mechanisms MUST link the nonce field with the 538 sam-track-id (if one is included) to prevent replay of the sam- 539 track-id field. 540 5415.1.10 SAM-ETYPE Field 542 543 The sam-etype field contains the encryption type to be used by the 544 client for all encrypted fields in the PA-SAM-RESPONSE-2 message. 545 The KDC should pick an appropriate encryption algorithm based on 546 the encryption algorithms listed in the client's initial 547 KRB_AS_REQ. 548 5495.2 Obtaining SAM Authentication Data 550 551 If the client is performing SAM preauthentication in the initial 552 message, without receipt of a PA-SAM-CHALLENGE-2 (i.e. without 553 waiting for the KRB_ERROR message), and the SAM in use does not 554 require a challenge, the client will prompt for the SAD in an 555 application-specific manner. 556 557 Once the user has been prompted for and entered the SAD (and possi- 558 bly the Kerberos password), the client will derive a key to be used 559 to encrypt the preauthentication data for a KRB_AS_REQ message. 560 This key will be determined as follows: 561 562 By default, the key is derived from the password and the SAD 563 by running each through the string_to_key function [RFC1510] 564 separately; i.e., K1 = string_to_key(password) and K2 = 565 string_to_key(SAD). When the keys are both DES or 3DES, 566 keys K1 and K2 will be combined using the algorithm 567 described in Appendix B, ``DES/3DES Key Combination Algo- 568 rithm''. For all other encryption algorithms, the algorithm 569 described in Appendix A, ``Key Combination Algorithm'' shall 570 be used. Note that this algorithm is not commutative; an 571 implementation MUST insure that K1 is the key corresponding 572 to the user's long-term password, and K2 is the output from 573 the SAD. In either case, the salt used by the string_to_key 574 algorithm for the SAD shall be the same salt as used for the 575 user's password. 576 577 If the send-encrypted-sad flag is set, the key will be 578 derived by running the Kerberos password though the 579 string_to_key function in the normal fashion. 580 581 If the use-sad-as-key flag is set and the integrity of the 582 PA-SAM-CHALLENGE-2 PADATA field can be verified using the 583 584 585 586Hornstein, Renard, Newman, Zorn [Page 9] 587 588 589 590 591 592INTERNET-DRAFT October 27, 2003 593 594 595 sam-cksum field, then the SAD is run through the 596 string_to_key function and the result is used as the encryp- 597 tion key for the request. WARNING: the use of single-use 598 authentication data in this manner is NOT recommended unless 599 the range of the SAD is large enough to make an exhaustive 600 off-line search impractical and the risks involved in the 601 use of SAD alone are fully considered. Also, note that 602 without the availability to the KDC of a relatively static, 603 unique secret key shared with the user, the only mechanisms 604 that can be used to protect the integrity of the PA-SAM- 605 CHALLENGE-2 PADATA field are based on either public key 606 cryptography or the KDC's a priori knowledge of the SAD 607 itself. In the latter case, the client must obtain the SAD 608 from the user and use it to verify the integrity of the 609 challenge before the new KRB_AS_REQ message is sent. 610 611 The sam-pk-for-sad field is reserved for future use. If 612 this field is not empty and the client does not support the 613 use of public-key encryption for SAD (to be defined in a 614 separate document), the client will not be able to complete 615 the authentication and must notify the user. 616 6175.3 SAM-RESPONSE PA-DATA 618 619 The client will then send another KRB_AS_REQ message to the KDC, 620 but with a padata field with padata-type equal to PA-SAM-RESPONSE-2 621 and padata-value defined as follows: 622 623 PA-SAM-RESPONSE-2 ::= SEQUENCE { 624 sam-type[0] INTEGER (0..4294967295), 625 sam-flags[1] SAMFlags, 626 sam-track-id[2] GeneralString OPTIONAL, 627 sam-enc-nonce-or-sad[3] EncryptedData, 628 -- PA-ENC-SAM-RESPONSE-ENC 629 -- Key usage of 27 630 sam-nonce[4] INTEGER (0..4294967295), 631 ... 632 } 633 634 PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE { 635 sam-nonce[0] INTEGER (0..4294967295), 636 sam-sad[1] GeneralString OPTIONAL, 637 ... 638 } 639 640 The source of the data included in the PA-SAM-RESPONSE-2 structure 641 depends upon whether or not a KRB_ERROR message was received by the 642 client from the KDC. 643 6445.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields 645 646 If an error reply was received, the sam-type, sam-flags, and sam- 647 nonce fields will contain copies of the same fields from the error 648 message. 649 650 651 652Hornstein, Renard, Newman, Zorn [Page 10] 653 654 655 656 657 658INTERNET-DRAFT October 27, 2003 659 660 661 If no error reply was received (i.e., the client knows that a 662 single-use authentication mechanism is to be used), the sam-type 663 field must be set to a value chosen from the list of registered 664 sam-type codes. 665 666 The value of the sam-flags field may vary depending upon the type 667 of SAM in use, but in all cases the must-pk-encrypt-sad flag must 668 be zero. If the send-encrypted-sad flag is set, the sam-sad field 669 must contain the entered single-use authentication data (see Sec- 670 tion 5.3.3). 671 6725.3.2 SAM-TRACK-ID Field 673 674 Note that if there is no sam-track-id in the request, it MUST be 675 omitted in the response. Otherwise, the sam-track-id data MUST be 676 copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2. 677 6785.3.3 SAM-ENC-NONCE-OR-SAD 679 680 The sam-enc-nonce-or-sad field represends the results of the preau- 681 thentication process. It contains the encrypted SAD or a SAD- 682 encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted 683 with the SAD, password + SAD, or password (based on the sam-flags) 684 with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes- 685 sage are populated as follows: 686 687 The sam-nonce contains the nonce from the SAM-CHALLENGE-2. This is 688 the same as the unencrypted sam-nonce described in section 5.2.2. 689 690 The sam-sad field contains the SAD if send-encrypted-sad is set in 691 the sam-flags. Otherwise, it is omitted. 692 6935.4 Verification of the SAM-RESPONSE-2 694 695 Upon receipt the KDC validates this PADATA in much the same way 696 that it validates the PA-ENC-TS preauthentication method except 697 that it uses the SAD (if available, and possibly in conjunction 698 with saved state information or portions of the preauthentication 699 data) to determine the correct key(s) required to verify the 700 encrypted data. Note that if the KDC uses the sam-track-id field 701 to encode its state, the SAM-verification routine is responsible 702 for including information in that field to detect modification or 703 replay by an attacker. 704 7055.5 KRB5-AS-REP 706 707 The rest of the processing of the request proceeds normally, except 708 that instead of being encrypted in the user's secret key, the 709 KRB_AS_REP message is encrypted in the key obtained above. Note, 710 however, that some single-use authentication mechanisms may require 711 further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication; 712 for example, in order to allow the server to resynchronize with the 713 drifting clock on a time-based token card. In these cases the KDC 714 may respond with another KRB_ERROR message containing a different 715 716 717 718Hornstein, Renard, Newman, Zorn [Page 11] 719 720 721 722 723 724INTERNET-DRAFT October 27, 2003 725 726 727 sam-type value, along with appropriate prompts and/or challenges. 728 This sequence of exchanges will continue until authentication 729 either succeeds or fails. 730 7316. Requirements for Single-use Authentication Mechanisms 732 733 Single-Use Authentication Mechanisms vary in their capabilities. 734 To aid implementers, we summarize here how various types of SAMs 735 would operate using this protocool. 736 737 If a SAM system can provide a SAD or a sequence of valid SADs to 738 the KDC, then the implementation SHOULD NOT set the send- 739 encrypted-sad flag. This SAM system should provide the SAD to the 740 KDC, which will combine it with the user's long-term key (password) 741 to generate the key used to generate the checksum placed in the 742 sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined 743 key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes- 744 sage by using it to decrypt the sam-enc-nonce-or-sad field and as 745 the key to encrypt the KRB-AS-REP. If a SAM system returns a range 746 of valid responses, each response can be used to generate a valid 747 checksum which can be placed in the sam-cksum sequence. 748 749 If a SAM system can generate enough entropy, it can set the use- 750 sad-as-key field to use the SAD solely as keying material, but it 751 should be noted that most SAM systems that require the user to 752 enter in a response do not have enough entropy to replace the 753 user's long-term key. The most likely consumer of use-sad-as-key 754 is a hardware token which communicates a key directly with Kerberos 755 client software. With or without the use of use-sad-as-key, this 756 is the preferred method as it protects against offline dictionary 757 attacks against the user's password. 758 759 If a SAM system cannot provide a SAD or a sequence of SADs to the 760 KDC, then the send-encrypted-sad flag must be set. In this case, 761 the SAD will be encrypted using the user's long-term key in the 762 PA-SAM-RESPONSE-2 message. It should be noted that this is a 763 weaker solution, as it does not protect the user's password against 764 offline dictionary attacks, and any additional entropy provided by 765 the SAM system cannot be used. 766 7677. Security considerations 768 769 Single-use authentication mechanisms requiring the use of the 770 send-encrypted-sad option are discouraged as their use on the net- 771 work is less secure than the case where a combination of the users 772 password and SAD is used as the encryption key. In particular, 773 when the send-encrypted-sad option is used, an attacker who 774 observes the response and is in possession of the users' secret key 775 (which doesn't change from login to login) can use the key to 776 decrypt the response and obtain the single-use authentication data. 777 This is dependent on the SAM technology used. 778 779 If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field 780 but the client software being used does not support public-key 781 782 783 784Hornstein, Renard, Newman, Zorn [Page 12] 785 786 787 788 789 790INTERNET-DRAFT October 27, 2003 791 792 793 cryptography, it is possible that legitimate users may be denied 794 service. 795 796 An attacker in possession of the users encryption key (again, which 797 doesn't change from login to login) might be able to 798 generate/modify a SAM challenge and attach the appropriate check- 799 sum. This affects the security of both the send-encrypted-sad 800 option and the must-pk-encrypt-sad option. 801 802 8038. Expiration 804 This Internet-Draft expires on April 27, 2004. 805 806 8079. References 808 809 [RFC1510] 810 The Kerberos Network Authentication System; Kohl and Neuman; 811 September 1993. 812 813 [RFC1760] 814 The S/Key One-Time Password System; Haller; February 1995 815 816 [RFC1636] 817 Report of IAB Workshop on Security in the Internet Architec- 818 ture; Braden, Clark, Crocker and Huitema; June 1994 819 820 [KCRYPTO] 821 Encryption and Checksum Specifications for Kerberos 5; Rae- 822 burn; May 2002 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850Hornstein, Renard, Newman, Zorn [Page 13] 851 852 853 854 855 856INTERNET-DRAFT October 27, 2003 857 858 85910. Authors' Addresses 860 Ken Hornstein 861 Naval Research Laboratory 862 4555 Overlook Avenue 863 Washington, DC 20375 864 865 Phone: 202-404-4765 866 EMail: kenh@cmf.nrl.navy.mil 867 868 869 Ken Renard 870 WareOnEarth 871 6849 Old Dominion Dr, Suite 365 872 Annandale, VA 22003 873 874 Phone: 703-622-3469 875 EMail: kdrenard@wareonearth.com 876 877 878 B. Clifford Neuman 879 USC/Information Sciences Institute 880 4676 Admiralty Way #1001 881 Marina del Rey, CA 90292-6695 882 883 Phone: 310-822-1511 884 EMail: bcn@isi.edu 885 886 887 Glen Zorn 888 Cisco Systems 889 500 108th Ave NE 890 Suite 500 891 Bellevue, WA 98004 892 893 Phone: 425-344-8113 894 EMail: gwz@cisco.com 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916Hornstein, Renard, Newman, Zorn [Page 14] 917 918 919 920 921 922INTERNET-DRAFT October 27, 2003 923 924 925Appendix A - Key combination algorithm 926 927 Definitions: 928 929 prf - Pseudo-random function that outputs an octet string based on 930 an input key and a input octet string (defined in [KCRYPTO]) 931 932 ^ - Exclusive-OR operation 933 934 random-to-key - Generates an encryption key from random input 935 (defined in [KCRYPTO]) 936 937 Given two input keys, K1 and K2, where K1 is derived from the 938 user's long-term password, and K2 is derived from the SAD, output 939 key (K3) is derived as follows: 940 941 Two sequence of octets, R1 and R2, shall be produced for each key 942 K1 and K2. R1 and R2 will be generated by iterating over calls to 943 prf() until enough bits are generated as needed by the random-to- 944 key function for the encryption type specified for K3. 945 946 The octet-string parameter to the prf() function shall be the ASCII 947 string "CombineA" for K1, and "CombineB" for K2. These have the 948 following byte values: 949 { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x41 } 950 { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x42 } 951 952 Furthermore, on each iteration both octet-strings will have 953 appended to them the iteration count in the form of an ASCII, base 954 10, numeral. The iteration count shall start at zero. The format 955 of the iteration count is equivalant to the C language "%d" format 956 to the printf() function call. Pseudo code implementing this fol- 957 lows: 958 959 count = 0; 960 while ( bits < required_bits) { 961 sprintf(A1, "CombineA%d", count); 962 sprintf(A2, "CombineB%d", count); 963 R1 += prf(K1, A1); 964 R2 += prf(K2, A2); 965 count++; 966 } 967 968 When R1 and R2 have been generated, they are truncated if the they 969 are longer than the length required by random-to-key. The key is 970 then generated as follows: 971 972 K3 = random-to-key(R1 ^ R2) 973 974 975 976 977 978 979 980 981 982Hornstein, Renard, Newman, Zorn [Page 15] 983 984 985 986 987 988INTERNET-DRAFT October 27, 2003 989 990 991 Appendix B - DES/3DES Key combination algorithm 992 993 Definitions: 994 995 DR - generate "random" data from an encryption key (defined in 996 [KCRYPTO]) 997 998 n-fold - "stretches" or "shrinks" a sequence bits to a specified 999 size (defined in [KCRYPTO]) 1000 1001 random-to-key - Generates an encryption key from random input 1002 (defined in [KCRYPTO]) 1003 1004 DK - Derive-Key, defined in [KCRYPTO]) 1005 1006 CombineConstant - The ASCII encoding of the string "combine", 1007 which is defined as the following byte string: 1008 1009 { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 } 1010 1011 Note: | means "concatenate" 1012 1013 Given two input keys, K1 and K2, the Combine-Key function is as 1014 follows: 1015 1016 R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1)) 1017 1018 rnd = n-fold(R1 | R2) 1019 1020 tkey = random-to-key(rnd) 1021 1022 Combine-Key(K1, K2) = DK(tkey, CombineConstant) 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048Hornstein, Renard, Newman, Zorn [Page 16] 1049 1050