idnits 2.17.1 draft-ietf-krb-wg-kerberos-sam-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 == 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 16 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 305 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 171: '... implementations SHOULD check the addr...' RFC 2119 keyword, line 233: '... sam-type-name[2] GeneralString OPTIONAL,...' RFC 2119 keyword, line 234: '... sam-track-id[3] GeneralString OPTIONAL,...' RFC 2119 keyword, line 236: '... sam-challenge-label[4] GeneralString OPTIONAL,...' RFC 2119 keyword, line 237: '... sam-challenge[5] GeneralString OPTIONAL,...' (14 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 15 has weird spacing: '...), its areas...' == Line 20 has weird spacing: '... months and ...' == Line 21 has weird spacing: '...-Drafts as...' == Line 22 has weird spacing: '...ference mater...' == Line 31 has weird spacing: '...tion of this ...' == (300 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 515 -- Looks like a reference, but probably isn't: '1' on line 516 -- Looks like a reference, but probably isn't: '2' on line 506 -- Looks like a reference, but probably isn't: '3' on line 507 -- Looks like a reference, but probably isn't: '4' on line 510 -- Looks like a reference, but probably isn't: '5' on line 237 -- Looks like a reference, but probably isn't: '6' on line 238 -- Looks like a reference, but probably isn't: '7' on line 239 -- Looks like a reference, but probably isn't: '8' on line 240 -- Looks like a reference, but probably isn't: '9' on line 241 ** 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: 16 errors (**), 0 flaws (~~), 11 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ken Hornstein 2 Naval Research Laboratory 3 Updates: RFC 1510 Ken Renard 4 July 15, 2004 WareOnEarth 5 Clifford Newman 6 ISI 7 Glen Zorn 8 Cisco Systems 10 Integrating Single-use Authentication Mechanisms with Kerberos 12 0. Status Of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. Internet-Drafts are working documents of 15 the Internet Engineering Task Force (IETF), its areas, and its 16 working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other docu- 21 ments at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as ``work in pro- 23 gress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- 27 dow Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 The distribution of this memo is unlimited. It is filed as 32 , and expires January 19, 33 2005. Please send comments to the authors. 35 1. Abstract 36 This document defines extensions to the Kerberos protocol specifi- 37 cation [RFC1510] which provide a method by which a variety of 38 single-use authentication mechanisms may be supported within the 39 protocol. The method defined specifies a standard fashion in which 40 the preauthentication data and error data fields in Kerberos mes- 41 sages may be used to support single-use authentication mechanisms. 43 2. Terminology 44 To simplify the following discussion, we will define those terms 45 which may be unfamiliar to the audience or specific to the discus- 46 sion itself. 48 Single-use Preauthentication Data (SPD): Data sent in the padata- 49 value field of a Kerberos V5 message proving that knowledge of 50 certain unique information is held by a principal. This informa- 51 tion may or may not be identical to the single-use authentication 52 data input to the client. For example, in the case of S/Key, the 53 principal might input a one-time password (in any of several 54 forms); the knowledge of this one-time password is taken to indi- 55 cate knowledge of the principal's secret passphrase. Similarly, 56 the SPD may or may not contain the provided single-use authentica- 57 tion data. For instance, if a given single-use authentication 58 mechanism includes a token which generates an encryption key for a 59 supported cryptosystem, that key could be used to encrypt portions 60 of the SPD before transmission. As long as the verification pro- 61 cess of the mechanism was capable of independently generating the 62 same key, the successful decryption of the SPD would provide 63 assurance that the originator of the message was in possession of 64 the token, as well as whatever information the token required to 65 generate the encryption key. 67 Single-use Authentication Mechanism (SAM): A system for generating 68 and verifying authentication data which is usable only once. 70 Single-use Authentication Data (SAD): SAM-specific data provided 71 by a principal as input to client software to be used in the crea- 72 tion of SPD. 74 3. Motivation and Scope 75 Several single-use authentication mechanisms are currently in 76 widespread use, including hardware-based schemes from vendors such 77 as Enigma Logic, CRYPTOCard, and Security Dynamics and software- 78 based methods like S/Key [RFC1760]. The hardware-based schemes 79 typically require that the authenticating user carry a small, 80 credit-card-sized electronic device (called a token) which is used 81 to generate unique authentication data. Some tokens require the 82 user to enter data into the device. This input may take the form 83 of a Personal Identification Number (PIN), a server-generated chal- 84 lenge string or both. Other tokens do not use a challenge-response 85 technique, instead spontaneously generating new and unique authen- 86 tication data every few seconds. These tokens are usually time- 87 synchronized with a server. The use of one-time passwords and 88 token cards as an authentication mechanism has steadily increased 89 over the past few years; in addition, the Internet Architecture 90 Board has encouraged the use of SAMs to improve Internet security 91 [RFC1636]. 93 The widespread acceptance of Kerberos within the Internet community 94 has produced considerable demand for the integration of SAM tech- 95 nology with the authentication protocol. Several currently avail- 96 able implementations of Kerberos include support for some types of 97 token cards, but the implementations are either not interoperable, 98 or would require the release of source code (not always an option) 99 to make them interoperate. This memo attempts to remedy that prob- 100 lem by specifying a method in which SAM data may be securely tran- 101 sported in Kerberos V5 messages in a standard, extensible fashion. 102 This document does not, however, attempt to precisely specify 103 either the generation or verification of SAM data, since this is 104 likely to be SAM-specific; nor does it dictate the conditions under 105 which SAM data must be included in Kerberos messages, since we con- 106 sider this to be a matter of local policy. 108 A primary reason for using a SAM with Kerberos is to reduce the 109 threat from common attacks on Kerberos passwords (poorly chosen 110 passwords, password guessing, etc). If passwords are used in com- 111 bination with SAM authentication data, users must still adhere to 112 sensible password policies and safe practices regarding the selec- 113 tion, secrecy, and maintenance of their passwords. Depending on 114 the specific mechanism used, the purpose of the SAD is to augment 115 (or sometimes replace) the use of a password as a secret key. 117 4. Generic Approach - Two Models 118 As outlined above, there are essentially two types of single-use 119 authentication mechanisms: challenge/response and time-based. In 120 order to support challenge/response mechanisms, the Kerberos Key 121 Distribution Center (KDC) must communicate the appropriate chal- 122 lenge string to the user, via the client software. Furthermore, 123 some challenge/response mechanisms require tight synchronization 124 between all instances of the KDC and the client. One example is 125 S/Key and its variants. If the KDC and client do not perform the 126 same number of message digest iterations, the protocol will fail; 127 worse, it might be possible for an eavesdropping attacker to cap- 128 ture a valid S/Key passcode and replay it to a KDC replica which 129 had an outdated iteration number. In the time-based case, no chal- 130 lenge is required. This naturally gives rise to two modes of 131 client behavior, described below. 133 4.1 Challenge/Response Model 134 The client begins with an initial KRB_AS_REQ message to the KDC, 135 possibly using existing preauthentication methods (PA-ENC-TIMESTAMP 136 (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on 137 whether preauthentication is used, the user may or may not be 138 prompted at this time for a Kerberos password. If (for example) 139 encrypted timestamp preauthentication is used, then the user will 140 be prompted; on the other hand, if no preauthentication is in use 141 the prompt for the password may be deferred (possibly forever). 142 Note that the use of preauthentication here may allow an offline 143 guessing attack against the Kerberos password separate from the 144 SPD. However, if the use of a SAM is required, then the password 145 by itself is not sufficient for authentication. (Specify character 146 strings as UTF-8) 148 The KDC will determine in an implementation- and policy-dependent 149 fashion if the client is required to utilize a single-use authenti- 150 cation mechanism. For example, the implementation may use IP 151 address screening to require principals authenticating from outside 152 a firewall to use a SAM, while principals on the inside need not. 153 If SAM usage is required, then the KDC will respond with a 154 KRB_ERROR message, with the error-code field set to 155 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1 156 structure that is a sequence of PA-DATA fields. 158 If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the 159 client should re-execute the authentication protocol from the 160 beginning, directing messages to another of the KDCs for the realm. 161 This is done to allow some methods to require that a single KDC be 162 used for SAM authentication when tight synchronization is needed 163 between all replicas and the KDC database propagation code does not 164 provide such synchronization. The corresponding padata-value will 165 contain an encoded sequence of host addresses [RFC1510], from which 166 the client must choose the KDC to be contacted next. The PA-SAM- 167 REDIRECT is defined as: 169 PA-SAM-REDIRECT ::= HostAddresses 171 Client implementations SHOULD check the addresses in the PA-SAM- 172 REDIRECT and verify that they are a subset of the KDC addresses 173 that they have been configured for that realm. 175 If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then 176 if one of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the 177 exchange will continue as described in section 5, below. 179 Note that some Kerberos implementations support an older preauthen- 180 tication mechanism with the padata types PA-SAM-CHALLENGE and PA- 181 SAM-RESPONSE. That protocol is depreciated and not defined here. 183 4.2 Time-based Model 184 For mechanisms where no challenge is required, the user (or the 185 client software being utilized) may or may not know a priori 186 whether SAM usage is required. If it does not know, then the ini- 187 tial exchange may proceed as above. If it is known that a use of a 188 single-use authentication mechanism is required then the first 189 exchange can be skipped and the authentication will continue as 190 follows. 192 5. SAM Preauthentication 194 An optional SAM-CHALLENGE-2 may be sent from the KDC to the client 195 and the client will send a SAM-RESPONSE-2 as pre-authentication 196 data in the KRB-AS-REQ. The details of the messages follow. 198 5.1 SAM-CHALLENGE-2 200 Prior to performing preauthentication using a single-use authenti- 201 cation mechanism, the client must know whether a challenge is 202 required (if the client doesn't have this information prior to its 203 sending the first KRB_AS_REQ message, it will be informed of the 204 requirement by the KDC, as described in section 4.1). The client 205 does NOT need to know the specific type of SAM in use. If a chal- 206 lenge is required the client will be sent the challenge by the KDC. 207 This means that a client supporting SAMs will be able to work with 208 new methods without modification. The challenge, as well as all 209 other prompts mentioned herein, can be internationalized by the KDC 210 on a per-principal basis. 212 If a KRB_ERROR message is received from the KDC indicating that SAM 213 usage is required, that message will include in its e-data field a 214 PA-DATA structure that encodes information about the SAM to be 215 used. This includes whether a challenge is required, and if so, 216 the challenge itself; and informational data about the type of SAM 217 that is in use, and how to prompt for the SAD. The SAM type is 218 informational only and does not affect the behavior of the client. 219 The prompt is also informational and may be presented to the user 220 by the client, or it may be safely ignored. 222 The ASN.1 definition for the SAM challenge is: 224 PA-SAM-CHALLENGE-2 ::= SEQUENCE { 225 sam-body[0] PA-SAM-CHALLENGE-2-BODY, 226 sam-cksum[1] SEQUENCE (1..MAX) OF Checksum, 227 ... 228 } 230 PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE { 231 sam-type[0] INTEGER (0..4294967295), 232 sam-flags[1] SAMFlags, 233 sam-type-name[2] GeneralString OPTIONAL, 234 sam-track-id[3] GeneralString OPTIONAL, 235 -- Key usage of 26 236 sam-challenge-label[4] GeneralString OPTIONAL, 237 sam-challenge[5] GeneralString OPTIONAL, 238 sam-response-prompt[6] GeneralString OPTIONAL, 239 sam-pk-for-sad[7] OCTET STRING OPTIONAL, 240 sam-nonce[8] INTEGER (0..4294967295), 241 sam-etype[9] INTEGER (0..4294967295), 242 ... 243 } 245 SAMFlags ::= BIT STRING (SIZE (32..MAX)) 246 -- use-sad-as-key(0) 247 -- send-encrypted-sad(1) 248 -- must-pk-encrypt-sad(2) 250 5.1.1 SAM-TYPE and SAM-TYPE-NAME Fields 252 The sam-type field is informational only, but it must be specified 253 and sam-type values must be registered with the IANA. 255 Initially defined values of the sam-type codes are: 257 PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic 258 PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways 259 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0 260 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key 261 PA_SAM_TYPE_SECURID 5 -- Security Dynamics 262 PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard 264 PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and 265 PA_SAM_TYPE_CRYPTOCARD represent popular token cards. 266 PA_SAM_TYPE_SKEY is the traditional S/Key protocol, in which the 267 SAD verifier does not have knowledge of the principal's S/Key 268 secret. PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the 269 same SAD and PC software or hardware device, but where the zeroth 270 key (the S/Key secret) is actually stored on, and can be used by, 271 the SAD verifier to independently generate the correct authentica- 272 tion data. 274 Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of 275 S/Key, viz., that the information required to generate the SAD need 276 not be stored on the host; but since the SAD verifier (which may be 277 the KDC) is assumed to be more secure than other hosts on the net- 278 work, it may be acceptable to give up this advantage in some situa- 279 tions. The advantage of using this S/Key variant is that the secu- 280 rity of the network protocol is strengthened since the SAD need not 281 be sent from the client to the KDC. Thus, the SAD can be used as 282 part of the key used to encrypt the encrypted parts of both the SPD 283 and the KRB_AS_REP message, rather than being sent protected by the 284 principal's Kerberos secret key which may have been previously 285 exposed to an attacker (see section 6, below). In any case, there 286 is a definite advantage to being interoperable with the S/Key algo- 287 rithm. 289 Due to the volatility of, and rapid developments in, the area of 290 single-use authentication mechanisms (both software-only and 291 hardware supported), any subsequently defined sam-type codes will 292 be maintained by the IANA. 294 The optional sam-type-name field is a UTF-8 character string for 295 informational use only. It may be used by the client to display a 296 short description of the type of single-use authentication mechan- 297 ism to be used. 299 5.1.2 SAM-FLAGS Field 301 The sam-flags field indicates whether the SAD is known by the KDC 302 (in which case it can be used as part of the encryption key for the 303 ensuing KRB_AS_REP message), or if it must be provided to the KDC 304 in a recoverable manner. If it is known to the KDC, use-sad-as-key 305 indicates that the SAD alone will be used to generate the encryp- 306 tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages, 307 and that the user will not need to also enter a password. We 308 recommend that this option only be used if the SAD will be used to 309 generate adequate keying material (sufficient length, secrecy, ran- 310 domness) for the cryptographic algorithm used. If the single-use 311 authentication data is not known (and cannot be generated or 312 discovered) by the KDC, then send-encrypted-sad flag will be set, 313 indicating that the SAD must be sent to the KDC encrypted under the 314 principal's secret key. If neither use-sad-as-key nor send- 315 encrypted-sad are set, the client may assume that the KDC knows the 316 SAD, but the Kerberos password should be used along with the 317 passcode in the derivation of the encryption key (see below). No 318 more than one of the send-encrypted-sad and use-sad-as-key flags 319 should be in a SAM-CHALLENGE-2. 321 The must-pk-encrypt-sad flag is reserved for future use. If this 322 flag is set and a client does not support the must-pk-encrypt-sad 323 option (to be defined in a separate document), the client will not 324 be able to complete the authentication and must notify the user. 326 5.1.3 SAM-CHECKSUM Field 328 The sam-cksum field contains a sequence of at least one crypto- 329 graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence. 330 If the send-encrypted-sad flag is set, the key to be used for this 331 checksum is the client's long-term secret. If the use-sad-as-key 332 flag is set, then the SAD alone will be used as the key. If nei- 333 ther flag is set, then the key used for this checksum is derived 334 from the SAD and the user's password (see section 5.2). 336 The checksum algorithm to be used for this is the mandatory check- 337 sum associated with the encryption algorithm specified in the sam- 338 etype field, with a key usage of 25. 340 In some cases there may be more than one valid SAD; some preauthen- 341 tication mechanisms may have a range of valid responses. In that 342 case, the KDC may elect to return multiple checksums, one for each 343 possible SAD response. The number of possible responses of course 344 depends on the mechanism and site policy. In the case where multi- 345 ple checksums are returned, the client MUST try each checksum in 346 turn until one of the checksums is verified successfully. Note 347 that in the non-send-encrypted-sad case the checksum cannot be ver- 348 ified until the user enters in the SAD, but if no checksum can be 349 verified, the client MUST not send a response but instead return an 350 error to the user. 352 The sam-cksum field is generated by calculating the specified 353 checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence. 355 If no checksum is included, or is of the wrong type, or none are 356 found which are correct, the client MUST abort the dialogue with 357 the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM, 358 KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes- 359 sages. 361 5.1.4 SAM-TRACK-ID Field 363 The optional sam-track-id field may be returned by the KDC in the 364 KRB_ERROR message. If present, the client MUST copy this field 365 into the corresponding field of the SAM response sent in the subse- 366 quent KRB_AS_REQ message. This field may be used by the KDC to 367 match challenges and responses. It might be a suitably encoded 368 integer, or even be encrypted data with the KDC state encoded so 369 that the KDC doesn't have to maintain the state internally. Note 370 that when a KDC supplies a sam-track-id, it MUST link the sam- 371 track-id with the sam-nonce field to prevent spoofing of the sam- 372 track-id field. 374 The key usage type 26 is reserved for use to encrypt the sam- 375 track-id data. The key used to encrypt the sam-track-id is 376 mechanism-dependent. 378 5.1.5 SAM-CHALLENGE-LABEL Field 380 The sam-challenge-label field is informational and optional. If it 381 is included, is will be an UTF-8 encoded character. If present, a 382 client may choose to precede the presentation of the challenge with 383 this string. For example, if the challenge is 135773 and the 384 string in the sam-challenge-label field is "Enter the following 385 number on your card", the client may choose to display to the user: 387 Enter the following number on your card: 135773 389 If no challenge label was presented, or if the client chooses to 390 ignore it, the client might display instead: 392 Challenge from authentication server: 135773 394 Internationalization is supported by allowing customization of the 395 challenge label and other strings on a per-principal basis. Note 396 that this character string should be encoded using UTF-8. 398 5.1.6 SAM-CHALLENGE Field 400 The optional sam-challenge field contains a string that will be 401 needed by the user to generate a suitable response. If the sam- 402 challenge field is left out, it indicates that the SAM in use does 403 not require a challenge, and that the authorized user should be 404 able to produce the correct SAD without one. If the sam-challenge 405 field is present, it is the data that is used by the SAD generator 406 to create the SAD to be used in the production of the SPD to be 407 included in the response. 409 5.1.7 SAM-RESPONSE-PROMPT Field 411 The sam-response-prompt field is informational and optional. If 412 present, a client may choose to precede the prompt for the response 413 with the specified string. 415 Passcode: 417 5.1.8 SAM-PK-FOR-SAD Field 419 sam-pk-for-sad is an optional field. It is included in the 420 interest of future extensability of the protocol to the use of 421 public-key cryptography. 423 5.1.9 SAM-NONCE Field 425 The sam-nonce is a KDC-supplied nonce and should conform to the 426 specification of the nonce field in a KRB_KDC_REQ message 427 [RFC1510]. 429 Challenge/Response mechanisms MUST link the nonce field with the 430 sam-track-id (if one is included) to prevent replay of the sam- 431 track-id field. 433 5.1.10 SAM-ETYPE Field 435 The sam-etype field contains the encryption type to be used by the 436 client for all encrypted fields in the PA-SAM-RESPONSE-2 message. 437 The KDC should pick an appropriate encryption algorithm based on 438 the encryption algorithms listed in the client's initial 439 KRB_AS_REQ. 441 5.2 Obtaining SAM Authentication Data 443 If the client is performing SAM preauthentication in the initial 444 message, without receipt of a PA-SAM-CHALLENGE-2 (i.e. without 445 waiting for the KRB_ERROR message), and the SAM in use does not 446 require a challenge, the client will prompt for the SAD in an 447 application-specific manner. 449 Once the user has been prompted for and entered the SAD (and possi- 450 bly the Kerberos password), the client will derive a key to be used 451 to encrypt the preauthentication data for a KRB_AS_REQ message. 452 This key will be determined as follows: 454 By default, the key is derived from the password and the SAD 455 by running each through the string_to_key function [RFC1510] 456 separately; i.e., K1 = string_to_key(password) and K2 = 457 string_to_key(SAD). When the keys are both DES or 3DES, 458 keys K1 and K2 will be combined using the algorithm 459 described in Appendix B, ``DES/3DES Key Combination Algo- 460 rithm''. For all other encryption algorithms, the algorithm 461 described in Appendix A, ``Key Combination Algorithm'' shall 462 be used. Note that this algorithm is not commutative; an 463 implementation MUST insure that K1 is the key corresponding 464 to the user's long-term password, and K2 is the output from 465 the SAD. In either case, the salt used by the string_to_key 466 algorithm for the SAD shall be the same salt as used for the 467 user's password. 469 If the send-encrypted-sad flag is set, the key will be 470 derived by running the Kerberos password though the 471 string_to_key function in the normal fashion. 473 If the use-sad-as-key flag is set and the integrity of the 474 PA-SAM-CHALLENGE-2 PADATA field can be verified using the 475 sam-cksum field, then the SAD is run through the 476 string_to_key function and the result is used as the encryp- 477 tion key for the request. WARNING: the use of single-use 478 authentication data in this manner is NOT recommended unless 479 the range of the SAD is large enough to make an exhaustive 480 off-line search impractical and the risks involved in the 481 use of SAD alone are fully considered. Also, note that 482 without the availability to the KDC of a relatively static, 483 unique secret key shared with the user, the only mechanisms 484 that can be used to protect the integrity of the PA-SAM- 485 CHALLENGE-2 PADATA field are based on either public key 486 cryptography or the KDC's a priori knowledge of the SAD 487 itself. In the latter case, the client must obtain the SAD 488 from the user and use it to verify the integrity of the 489 challenge before the new KRB_AS_REQ message is sent. 491 The sam-pk-for-sad field is reserved for future use. If 492 this field is not empty and the client does not support the 493 use of public-key encryption for SAD (to be defined in a 494 separate document), the client will not be able to complete 495 the authentication and must notify the user. 497 5.3 SAM-RESPONSE PA-DATA 499 The client will then send another KRB_AS_REQ message to the KDC, 500 but with a padata field with padata-type equal to PA-SAM-RESPONSE-2 501 and padata-value defined as follows: 503 PA-SAM-RESPONSE-2 ::= SEQUENCE { 504 sam-type[0] INTEGER (0..4294967295), 505 sam-flags[1] SAMFlags, 506 sam-track-id[2] GeneralString OPTIONAL, 507 sam-enc-nonce-or-sad[3] EncryptedData, 508 -- PA-ENC-SAM-RESPONSE-ENC 509 -- Key usage of 27 510 sam-nonce[4] INTEGER (0..4294967295), 511 ... 512 } 514 PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE { 515 sam-nonce[0] INTEGER (0..4294967295), 516 sam-sad[1] GeneralString OPTIONAL, 517 ... 518 } 520 The source of the data included in the PA-SAM-RESPONSE-2 structure 521 depends upon whether or not a KRB_ERROR message was received by the 522 client from the KDC. 524 5.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields 526 If an error reply was received, the sam-type, sam-flags, and sam- 527 nonce fields will contain copies of the same fields from the error 528 message. 530 If no error reply was received (i.e., the client knows that a 531 single-use authentication mechanism is to be used), the sam-type 532 field must be set to a value chosen from the list of registered 533 sam-type codes. 535 The value of the sam-flags field may vary depending upon the type 536 of SAM in use, but in all cases the must-pk-encrypt-sad flag must 537 be zero. If the send-encrypted-sad flag is set, the sam-sad field 538 must contain the entered single-use authentication data (see Sec- 539 tion 5.3.3). 541 5.3.2 SAM-TRACK-ID Field 543 Note that if there is no sam-track-id in the request, it MUST be 544 omitted in the response. Otherwise, the sam-track-id data MUST be 545 copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2. 547 5.3.3 SAM-ENC-NONCE-OR-SAD 549 The sam-enc-nonce-or-sad field represends the results of the preau- 550 thentication process. It contains the encrypted SAD or a SAD- 551 encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted 552 with the SAD, password + SAD, or password (based on the sam-flags) 553 with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes- 554 sage are populated as follows: 556 The sam-nonce contains the nonce from the SAM-CHALLENGE-2. This is 557 the same as the unencrypted sam-nonce described in section 5.2.2. 559 The sam-sad field contains the SAD if send-encrypted-sad is set in 560 the sam-flags. Otherwise, it is omitted. 562 5.4 Verification of the SAM-RESPONSE-2 564 Upon receipt the KDC validates this PADATA in much the same way 565 that it validates the PA-ENC-TS preauthentication method except 566 that it uses the SAD (if available, and possibly in conjunction 567 with saved state information or portions of the preauthentication 568 data) to determine the correct key(s) required to verify the 569 encrypted data. Note that if the KDC uses the sam-track-id field 570 to encode its state, the SAM-verification routine is responsible 571 for including information in that field to detect modification or 572 replay by an attacker. 574 5.5 KRB5-AS-REP 576 The rest of the processing of the request proceeds normally, except 577 that instead of being encrypted in the user's secret key, the 578 KRB_AS_REP message is encrypted in the key obtained above. Note, 579 however, that some single-use authentication mechanisms may require 580 further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication; 581 for example, in order to allow the server to resynchronize with the 582 drifting clock on a time-based token card. In these cases the KDC 583 may respond with another KRB_ERROR message containing a different 584 sam-type value, along with appropriate prompts and/or challenges. 585 This sequence of exchanges will continue until authentication 586 either succeeds or fails. 588 6. Requirements for Single-use Authentication Mechanisms 590 Single-Use Authentication Mechanisms vary in their capabilities. 591 To aid implementers, we summarize here how various types of SAMs 592 would operate using this protocool. 594 If a SAM system can provide a SAD or a sequence of valid SADs to 595 the KDC, then the implementation SHOULD NOT set the send- 596 encrypted-sad flag. This SAM system should provide the SAD to the 597 KDC, which will combine it with the user's long-term key (password) 598 to generate the key used to generate the checksum placed in the 599 sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined 600 key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes- 601 sage by using it to decrypt the sam-enc-nonce-or-sad field and as 602 the key to encrypt the KRB-AS-REP. If a SAM system returns a range 603 of valid responses, each response can be used to generate a valid 604 checksum which can be placed in the sam-cksum sequence. 606 If a SAM system can generate enough entropy, it can set the use- 607 sad-as-key field to use the SAD solely as keying material, but it 608 should be noted that most SAM systems that require the user to 609 enter in a response do not have enough entropy to replace the 610 user's long-term key. The most likely consumer of use-sad-as-key 611 is a hardware token which communicates a key directly with Kerberos 612 client software. With or without the use of use-sad-as-key, this 613 is the preferred method as it protects against offline dictionary 614 attacks against the user's password. 616 If a SAM system cannot provide a SAD or a sequence of SADs to the 617 KDC, then the send-encrypted-sad flag must be set. In this case, 618 the SAD will be encrypted using the user's long-term key in the 619 PA-SAM-RESPONSE-2 message. It should be noted that this is a 620 weaker solution, as it does not protect the user's password against 621 offline dictionary attacks, and any additional entropy provided by 622 the SAM system cannot be used. 624 7. Security considerations 626 Single-use authentication mechanisms requiring the use of the 627 send-encrypted-sad option are discouraged as their use on the net- 628 work is less secure than the case where a combination of the users 629 password and SAD is used as the encryption key. In particular, 630 when the send-encrypted-sad option is used, an attacker who 631 observes the response and is in possession of the users' secret key 632 (which doesn't change from login to login) can use the key to 633 decrypt the response and obtain the single-use authentication data. 634 This is dependent on the SAM technology used. 636 If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field 637 but the client software being used does not support public-key 638 cryptography, it is possible that legitimate users may be denied 639 service. 641 An attacker in possession of the users encryption key (again, which 642 doesn't change from login to login) might be able to 643 generate/modify a SAM challenge and attach the appropriate check- 644 sum. This affects the security of both the send-encrypted-sad 645 option and the must-pk-encrypt-sad option. 647 8. Expiration 648 This Internet-Draft expires on January 19, 2004. 650 9. References 652 [RFC1510] 653 The Kerberos Network Authentication System; Kohl and Neuman; 654 September 1993. 656 [RFC1760] 657 The S/Key One-Time Password System; Haller; February 1995 659 [RFC1636] 660 Report of IAB Workshop on Security in the Internet Architec- 661 ture; Braden, Clark, Crocker and Huitema; June 1994 663 [KCRYPTO] 664 Encryption and Checksum Specifications for Kerberos 5; Rae- 665 burn; May 2002 667 10. Authors' Addresses 668 Ken Hornstein 669 Naval Research Laboratory 670 4555 Overlook Avenue 671 Washington, DC 20375 673 Phone: 202-404-4765 674 EMail: kenh@cmf.nrl.navy.mil 676 Ken Renard 677 WareOnEarth 678 6849 Old Dominion Dr, Suite 365 679 Annandale, VA 22003 681 Phone: 703-622-3469 682 EMail: kdrenard@wareonearth.com 684 B. Clifford Neuman 685 USC/Information Sciences Institute 686 4676 Admiralty Way #1001 687 Marina del Rey, CA 90292-6695 689 Phone: 310-822-1511 690 EMail: bcn@isi.edu 692 Glen Zorn 693 Cisco Systems 694 500 108th Ave NE 695 Suite 500 696 Bellevue, WA 98004 698 Phone: 425-344-8113 699 EMail: gwz@cisco.com 701 Appendix A - Key combination algorithm 703 Definitions: 705 prf - Pseudo-random function that outputs an octet string based on 706 an input key and a input octet string (defined in [KCRYPTO]) 708 ^ - Exclusive-OR operation 710 random-to-key - Generates an encryption key from random input 711 (defined in [KCRYPTO]) 713 Given two input keys, K1 and K2, where K1 is derived from the 714 user's long-term password, and K2 is derived from the SAD, output 715 key (K3) is derived as follows: 717 Two sequence of octets, R1 and R2, shall be produced for each key 718 K1 and K2. R1 and R2 will be generated by iterating over calls to 719 prf() until enough bits are generated as needed by the random-to- 720 key function for the encryption type specified for K3. 722 The octet-string parameter to the prf() function shall be the ASCII 723 string "CombineA" for K1, and "CombineB" for K2. These have the 724 following byte values: 725 { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x41 } 726 { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x42 } 728 Furthermore, on each iteration both octet-strings will have 729 appended to them the iteration count in the form of an ASCII, base 730 10, numeral. The iteration count shall start at zero. The format 731 of the iteration count is equivalant to the C language "%d" format 732 to the printf() function call. Pseudo code implementing this fol- 733 lows: 735 count = 0; 736 while ( bits < required_bits) { 737 sprintf(A1, "CombineA%d", count); 738 sprintf(A2, "CombineB%d", count); 739 R1 += prf(K1, A1); 740 R2 += prf(K2, A2); 741 count++; 742 } 744 When R1 and R2 have been generated, they are truncated if the they 745 are longer than the length required by random-to-key. The key is 746 then generated as follows: 748 K3 = random-to-key(R1 ^ R2) 750 Appendix B - DES/3DES Key combination algorithm 752 Definitions: 754 DR - generate "random" data from an encryption key (defined in 755 [KCRYPTO]) 757 n-fold - "stretches" or "shrinks" a sequence bits to a specified 758 size (defined in [KCRYPTO]) 760 random-to-key - Generates an encryption key from random input 761 (defined in [KCRYPTO]) 763 DK - Derive-Key, defined in [KCRYPTO]) 765 CombineConstant - The ASCII encoding of the string "combine", 766 which is defined as the following byte string: 768 { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 } 770 Note: | means "concatenate" 772 Given two input keys, K1 and K2, the Combine-Key function is as 773 follows: 775 R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1)) 777 rnd = n-fold(R1 | R2) 779 tkey = random-to-key(rnd) 781 Combine-Key(K1, K2) = DK(tkey, CombineConstant)