idnits 2.17.1 draft-ietf-cat-kerberos-passwords-04.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 12 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 12 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 237 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 200: '... sam-type-name[2] GeneralString OPTIONAL,...' RFC 2119 keyword, line 201: '... sam-track-id[3] GeneralString OPTIONAL,...' RFC 2119 keyword, line 202: '... sam-challenge-label[4] GeneralString OPTIONAL,...' RFC 2119 keyword, line 203: '... sam-challenge[5] GeneralString OPTIONAL,...' RFC 2119 keyword, line 204: '... sam-response-prompt[6] 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 14 has weird spacing: '...-Drafts are ...' == 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 ...' == (232 more instances...) (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 444 -- Looks like a reference, but probably isn't: '1' on line 445 -- Looks like a reference, but probably isn't: '2' on line 446 -- Looks like a reference, but probably isn't: '3' on line 447 -- Looks like a reference, but probably isn't: '4' on line 433 -- Looks like a reference, but probably isn't: '5' on line 435 -- Looks like a reference, but probably isn't: '6' on line 436 -- Looks like a reference, but probably isn't: '7' on line 205 -- Looks like a reference, but probably isn't: '8' on line 206 -- Looks like a reference, but probably isn't: '9' on line 207 ** 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 Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 13 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 November 18, 1998 Microsoft Corporation 6 Jonathan Trostle 7 CyberSAFE Corporation 8 Ken Hornstein 9 ITT/NRL 11 Integrating Single-use Authentication Mechanisms with Kerberos 13 0. Status Of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working 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 May 11, 33 1999. 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 cer- 50 tain unique information is held by a principal. This information 51 may or may not be identical to the single-use authentication data 52 input to the client. For example, in the case of S/Key, the prin- 53 cipal might input a one-time password (in any of several forms); 54 the knowledge of this one-time password is taken to indicate 55 knowledge of the principal's secret passphrase. Similarly, the SPD 56 may or may not contain the provided single-use authentication data. 57 For instance, if a given single-use authentication mechanism 58 includes a token which generates an encryption key for a supported 59 cryptosystem, that key could be used to encrypt portions of the SPD 60 before transmission. As long as the verification process of the 61 mechanism was capable of independently generating the same key, the 62 successful decryption of the SPD would provide assurance that the 63 originator of the message was in possession of the token, as well 64 as whatever information the token required to generate the encryp- 65 tion 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, Digital Pathways and Security Dynamics and 78 software-based methods like S/Key [RFC1760]. The hardware-based 79 schemes typically require that the authenticating user carry a 80 small, credit-card-sized electronic device (called a token) which 81 is used to generate unique authentication data. Some tokens 82 require the user to enter data into the device. This input may 83 take the form of a Personal Identification Number (PIN), a server- 84 generated challenge string or both. Other tokens do not use a 85 challenge-response technique, instead spontaneously generating new 86 and unique authentication data every few seconds. These tokens are 87 usually time-synchronized with a server. The use of one-time pass- 88 words and token cards as an authentication mechanism has steadily 89 increased over the past few years; in addition, the Internet Archi- 90 tecture Board has encouraged the use of SAMs to improve Internet 91 security [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 4. Generic Approach - Two Models 109 As outlined above, there are essentially two types of single-use 110 authentication mechanisms: challenge/response and time-based. In 111 order to support challenge/response mechanisms, the Kerberos Key 112 Distribution Center (KDC) must communicate the appropriate chal- 113 lenge string to the user, via the client software. Furthermore, 114 some challenge/response mechanisms require tight synchronization 115 between all instances of the KDC and the client. One example is 116 S/Key and its variants. If the KDC and client do not perform the 117 same number of message digest iterations, the protocol will fail; 118 worse, it might be possible for an eavesdopping attacker to capture 119 a valid S/Key passcode and replay it to a KDC replica which had an 120 outdated iteration number. In the time-based case, no challenge is 121 required. This naturally gives rise to two modes of client 122 behavior, described below. 124 4.1 Challenge/Response Model 125 The client begins with an initial KRB_AS_REQ message to the KDC, 126 possibly using existing preauthentication methods (PA-ENC-TIMESTAMP 127 (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on 128 whether preauthentication is used, the user may or may not be 129 prompted at this time for a Kerberos password. If (for example) 130 encrypted timestamp preauthentication is used, then the user will 131 be prompted; on the other hand, if no preauthentication is in use 132 the prompt for the password may be deferred (possibly forever). 133 Note that the use of preauthentication here may allow an offline 134 guessing attack against the Kerberos password separate from the 135 SPD. However, if the use of a SAM is required, then the password 136 by itself is not sufficient for authentication. (Specify character 137 strings as UTF-8) 139 The KDC will determine in an implementation- and policy-dependent 140 fashion if the client is required to utilize a single-use authenti- 141 cation mechanism. For example, the implementation may use IP 142 address screening to require principals authenticating from outside 143 a firewall to use a SAM, while principals on the inside need not. 144 If SAM usage is required, then the KDC will respond with a 145 KRB_ERROR message, with the error-code field set to 146 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1 147 structure that is a sequence of PA-DATA fields. 149 If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the 150 client should re-execute the authentication protocol from the 151 beginning, directing messages to another of the KDCs for the realm. 152 This is done to allow some methods to require that a single KDC be 153 used for SAM authentication when tight synchronization is needed 154 between all replicas and the KDC database propagation code does not 155 provide such synchronization. The corresponding padata-value will 156 contain an encoded sequence of host addresses [RFC1510], from which 157 the client must choose the KDC to be contacted next. 159 Otherwise, if one of the PA-DATA fields has the type PA-SAM- 160 CHALLENGE, the exchange will continue as described in section 5, 161 below. 163 4.2 Time-based Model 164 For mechanisms where no challenge is required, the user (or the 165 client software being utilized) may or may not know a priori 166 whether SAM usage is required. If it does not know, then the ini- 167 tial exchange may proceed as above. If it is known that a use of a 168 single-use authentication mechanism is required then the first 169 exchange can be skipped and the authentication will continue as 170 follows. 172 5. Authentication Using Passcodes 173 Prior to performing preauthentication using a single-use authenti- 174 cation mechanism, the client must know whether a challenge is 175 required (if the client doesn't have this information prior to its 176 sending the first KRB_AS_REQ message, it will be informed of the 177 requirement by the KDC, as described in section 4.1). The client 178 does NOT need to know the specific type of SAM in use. If a chal- 179 lenge is required the client will be sent the challenge by the KDC. 180 This means that a client supporting SAMs will be able to work with 181 new methods without modification. The challenge, as well as all 182 other prompts mentioned herein, can be internationalized by the KDC 183 on a per-principal basis. 185 If a KRB_ERROR message is received from the KDC indicating that SAM 186 usage is required, that message will include in its e-data field a 187 PA-DATA structure that encodes information about the SAM to be 188 used. This includes whether a challenge is required, and if so, 189 the challenge itself; and informational data about the type of SAM 190 that is in use, and how to prompt for the SAD. The SAM type is 191 informational only and does not affect the behavior of the client. 192 The prompt is also informational and may be presented to the user 193 by the client, or it may be safely ignored. 195 The ASN.1 definition for the SAM challenge is: 197 PA-SAM-CHALLENGE ::= SEQUENCE { 198 sam-type[0] INTEGER, 199 sam-flags[1] SAMFlags, 200 sam-type-name[2] GeneralString OPTIONAL, 201 sam-track-id[3] GeneralString OPTIONAL, 202 sam-challenge-label[4] GeneralString OPTIONAL, 203 sam-challenge[5] GeneralString OPTIONAL, 204 sam-response-prompt[6] GeneralString OPTIONAL, 205 sam-pk-for-sad[7] EncryptionKey OPTIONAL, 206 sam-nonce[8] INTEGER OPTIONAL, 207 sam-cksum[9] Checksum OPTIONAL 208 } 210 SAMFlags ::= BIT STRING { 211 use-sad-as-key[0], 212 send-encrypted-sad[1], 213 must-pk-encrypt-sad[2] 214 } 216 The sam-type field is informational only, but it must be specified 217 and sam-type values must be registered with the IANA. 219 Initially defined values of the sam-type codes are: 221 PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic 222 PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways 223 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0 224 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key 225 PA_SAM_TYPE_SECURID 5 -- Security Dynamics 226 PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard 228 PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and 229 PA_SAM_TYPE_CRYPTOCARD represent popular token cards. 230 PA_SAM_TYPE_SKEY is the traditional S/Key protocol, in which the 231 SAD verifier does not have knowledge of the principal's S/Key 232 secret. PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the 233 same SAD and PC software or hardware device, but where the zeroth 234 key (the S/Key secret) is actually stored on, and can be used by, 235 the SAD verifier to independently generate the correct authentica- 236 tion data. 238 Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of 239 S/Key, viz., that the information required to generate the SAD need 240 not be stored on the host; but since the SAD verifier (which may be 241 the KDC) is assumed to be more secure than other hosts on the net- 242 work, it may be acceptable to give up this advantage in some situa- 243 tions. The advantage of using this S/Key variant is that the secu- 244 rity of the network protocol is strengthened since the SAD need not 245 be sent from the client to the KDC. Thus, the SAD can be used as 246 part of the key used to encrypt the encrypted parts of both the SPD 247 and the KRB_AS_REP message, rather than being sent protected by the 248 principal's Kerberos secret key which may have been previously 249 exposed to an attacker (see section 6, below). In any case, there 250 is a definite advantage to being interoperable with the S/Key algo- 251 rithm. 253 Due to the volatility of, and rapid developments in, the area of 254 single-use authentication mechanisms (both software-only and 255 hardware supported), any subsequently defined sam-type codes will 256 be maintained by the IANA. 258 The sam-flags field indicates whether the SAD is known by the KDC 259 (in which case it can be used as part of the encryption key for the 260 ensuing KRB_AS_REP message), or if it must be provided to the KDC 261 in a recoverable manner. If it is known to the KDC, use-sad-as-key 262 indicates that the SAD alone will be used to generate the encryp- 263 tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages, 264 and that the user will not need to also enter a password. We 265 recommend that this option not be used, and that the principal also 266 enter the Kerberos password, but for some situations, presentation 267 of the SAD alone may be acceptable. If the single-use authentica- 268 tion data is not known (and cannot be generated or discovered) by 269 the KDC, then send-encrypted-sad flag will be set, indicating that 270 the SAD must be sent to the KDC encrypted under the principal's 271 secret key. If neither use-sad-as-key nor send-encrypted-sad are 272 set, the client may assume that the KDC knows the SAD, but the Ker- 273 beros password should be used along with the passcode in the 274 derivation of the encryption key (see below). The must-pk- 275 encrypt-sad flag is reserved for future use. If this flag is set 276 and a client does not support the must-pk-encrypt-sad option (to be 277 defined in a separate document), the client will not be able to 278 complete the authentication and must notify the user. 280 Note that there are specific constraints on the integrity of the 281 PA-SAM-CHALLENGE when some of these options are specified. In par- 282 ticular, if any of these flags are set, a cryptographic checksum 283 must be present and verified. If absent, or the checksum does not 284 match the request, the challenge must be considered invalid and the 285 user notified. 287 The optional sam-type-name field is a UTF-8 character string for 288 informational use only. It may be used by the client to display a 289 short description of the type of single-use authentication mechan- 290 ism to be used. 292 The optional sam-track-id field may be returned by the KDC in the 293 KRB_ERROR message. If present, the client should copy this field 294 into the corresponding field of the SAM response sent in the subse- 295 quent KRB_AS_REQ message. This field may be used by the KDC to 296 match challenges and responses. It might be a suitably encoded 297 integer, or even be encrypted data with the KDC state encoded so 298 that the KDC doesn't have to maintain the state internally. 300 The sam-challenge-label field is informational and optional. If it 301 is included, is will be an UTF-8 encoded character. If present, a 302 client may choose to precede the presentation of the challenge with 303 this string. For example, if the challenge is 135773 and the 304 string in the sam-challenge-label field is "Enter the following 305 number on your card", the client may choose to display to the user: 307 Enter the following number on your card: 135773 309 If no challenge label was presented, or if the client chooses to 310 ignore it, the client might display instead: 312 Challenge from authentication server: 135773 314 If the sam-checksum field is empty the sam-challenge-label should 315 be ignored, since in that case it may have been modified by an 316 adversary. Internationalization is supported by allowing customi- 317 zation of the challenge label and other strings on a per-principal 318 basis. Note that this character string should be encoded using 319 UTF-8. 321 The optional sam-challenge field contains a string that will be 322 needed by the user to generate a suitable response. If the sam- 323 challenge field is left out, it indicates that the SAM in use does 324 not require a challenge, and that the authorized user should be 325 able to produce the correct SAD without one. If the sam-challenge 326 field is present, it is the data that is used by the SAD generator 327 to create the SAD to be used in the production of the SPD to be 328 included in the response. 330 The sam-response-prompt field is informational and optional. If 331 present, a client may choose to precede the prompt for the response 332 with the specified string; however, it should not be used if the 333 sam-checksum field is empty, since in that case the prompt may have 334 been modified by an adversary. If this field is empty the prompt 335 displayed will be hardcoded into the application, such as 337 Passcode: 339 sam-pk-for-sad is an optional field. It is included in the 340 interest of future extensability of the protocol to the use of 341 public-key cryptography. 343 The sam-nonce field is optional. If present, it should conform to 344 the specification of the nonce field in a KRB_KDC_REQ message 345 [RFC1510]. 347 The optional sam-cksum field contains a cryptographic checksum of 348 the preceding fields, protected using the same key as that used for 349 preauthentication in the initial KRB_AS_REQ message. While any 350 secure checksum method may be used, the RSA-MD5-DES type is recom- 351 mended and must be supported by the client. This field should 352 always be present if the initial KRB_AS_REQ message included a form 353 of cryptographic preauthentication (such as PA_ENC_TIMESTAMP). If 354 the initial message included preauthentication, but this field is 355 missing in the response, the client should reject the response. If 356 this field is present, the client should verify its correctness: 358 if the sam-cksum field is present in the KRB_ERROR message, but not 359 verified by the client, then an attacker can change the message 360 contents at will. Such a change could cause unexpected instruc- 361 tions to be displayed to the user in the prompt string, or allow 362 the denial of service through the presentation of an invalid chal- 363 lenge. Another effect of a change might be to effect a limited 364 chosen plaintext attack on the Kerberos password where the attacker 365 picks the nonce, and the challenge. 367 Note that it is possible for the KDC to generate a cryptographic 368 checksum for this message using the users' secret key even though 369 no cryptographic preauthentication was present in the initial 370 AS_REQ message. Doing so, however, makes material available which 371 enables an offline guessing attack against that key. 373 If the client is performing SAM preauthentication in the initial 374 message, without receipt of a PA-SAM-CHALLENGE (i.e. without wait- 375 ing for the KRB_ERROR message), and the SAM in use does not require 376 a challenge, the client will prompt for the SAD in an application- 377 specific manner. 379 Once the user has been prompted for and entered the SAD (and possi- 380 bly the Kerberos password), the client will derive a key to be used 381 to encrypt the preauthentication data for a KRB_AS_REQ message. 382 This key will be determined as follows: 384 By default, the key is derived from the password and the SAD 385 by running each through the string_to_key function [RFC1510] 386 separately; i.e., K1 = string_to_key(password) and K2 = 387 string_to_key(SAD). The K1 and K2 are then combined to form 388 a single key K in a manner specific to the type of key being 389 generated. For DES keys, K will be formed by XORing K1 and 390 K2, then correcting the parity of K. If the result matches 391 a "weak" or "semiweak" key as described in the DES specifi- 392 cation, it is XORed with the hexadecimal constant 393 00000000000000F0. 395 If the send-encrypted-sad flag is set, the key will be 396 derived by running the Kerberos password though the 397 string_to_key function in the normal fashion. 399 If the use-sad-as-key flag is set and the integrity of the 400 PA-SAM-CHALLENGE PADATA field can be verified using the 401 sam-cksum field, then the SAD is run through the 402 string_to_key function and the result is used as the encryp- 403 tion key for the request. WARNING: the use of single-use 404 authentication data in this manner is NOT recommended unless 405 the range of the SAD is large enough to make an exhaustive 406 off-line search impractical and the risks involved in the 407 use of SAD alone are fully considered. Also, note that 408 without the availability to the KDC of a relatively static, 409 unique secret key shared with the user, the only mechanisms 410 that can be used to protect the integrity of the PA-SAM- 411 CHALLENGE PADATA field are based on either public key 412 cryptography or the KDC's a priori knowledge of the SAD 413 itself. In the latter case, the client must obtain the SAD 414 from the user and use it to verify the integrity of the 415 challenge before the new KRB_AS_REQ message is sent. 417 The sam-pk-for-sad field is reserved for future use. If 418 this field is not empty and the client does not support the 419 use of public-key encryption for SAD (to be defined in a 420 separate document), the client will not be able to complete 421 the authentication and must notify the user. 423 The client will then send another KRB_AS_REQ message to the KDC, 424 but with a padata field with padata-type equal to PA-SAM-RESPONSE 425 and padata-value defined as follows: 427 PA-SAM-RESPONSE ::= SEQUENCE { 428 sam-type[0] INTEGER, 429 sam-flags[1] SAMFlags, 430 sam-track-id[2] GeneralString OPTIONAL, 431 sam-enc-key[3] EncryptedData 432 -- PA-ENC-SAM-KEY, 433 sam-enc-nonce-or-ts[4] EncryptedData 434 -- PA-ENC-SAM-RESPONSE-ENC, 435 sam-nonce[5] INTEGER OPTIONAL, 436 sam-patimestamp[6] KerberosTime OPTIONAL 437 } 439 PA-ENC-SAM-KEY ::= SEQUENCE { 440 sam-key[0] EncryptionKey 441 } 443 PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE { 444 sam-nonce[0] INTEGER OPTIONAL, 445 sam-timestamp[1] KerberosTime OPTIONAL, 446 sam-usec[2] INTEGER OPTIONAL, 447 sam-sad[3] GeneralString OPTIONAL 448 } 450 The source of the data included in the PA-SAM-RESPONSE structure 451 depends upon whether or not a KRB_ERROR message was received by the 452 client from the KDC. 454 If an error reply was received, the sam-type and sam-flags fields 455 will contain copies of the same fields from the error message. If 456 the sam-nonce field was present in the KRB_ERROR message, then the 457 PA-ENC-SAM-RESPONSE-ENC structure returned to the KDC will include 458 that value, encrypted as described above, the nonce field in the 459 KRB_AS_REQ message will contain a plaintext copy of the same value 460 and the sam-timestamp field in the PA-ENC-SAM-RESPONSE-ENC struc- 461 ture will be empty. If a sam-timestamp is present in the PA-ENC- 462 SAM-RESPONSE, the sam-patimestamp field must be supplied in the 463 PA-SAM-RESPONSE. If a KRB_ERROR message was received but the sam- 464 nonce field was omitted from it, the encrypted data will contain a 465 timestamp encrypted in the same manner, the sam-patimestamp field 466 will contain an unencrypted copy of the same value, and the sam- 467 nonce field will be empty. In either case, if the send-encrypted- 468 sad flag is set in the sam-flags field of the error message, the 469 sam-sad field must contain the entered single-use authentication 470 data. 472 If no error reply was received (i.e., the client knows that a 473 single-use authentication mechanism is to be used), the sam-type 474 field must be set to a value chosen from the list of registered 475 sam-type codes. 477 The value of the sam-flags field may vary depending upon the type 478 of SAM in use, but in all cases the must-pk-encrypt-sad flag must 479 be zero. If the send-encrypted-sad flag is set, the sam-sad field 480 must contain the entered single-use authentication data. 482 Note that is there is no sam-track-id in the request, it should be 483 omitted in the response. 485 The sam-enc-key field is reserved for future use. 487 Upon receipt the KDC validates this PADATA in much the same way 488 that it validates the PA-ENC-TS preauthentication method except 489 that it uses the SAD (if available, and possibly in conjunction 490 with saved state information or portions of the preauthentication 491 data) to determine the correct key(s) required to verify the 492 encrypted data. Note that if the KDC uses the sam-track-id field 493 to encode its state, the KDC is responsible for including informa- 494 tion in that field to detect modification or replay by an attacker. 496 The rest of the processing of the request proceeds normally, except 497 that instead of being encrypted in the user's secret key, the 498 KRB_AS_REP message is encrypted in the key obtained above. Note, 499 however, that some single-use authentication mechanisms may require 500 further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication; 501 for example, in order to allow the server to resynchronize with the 502 drifting clock on a time-based token card. In these cases the KDC 503 may respond with another KRB_ERROR message containing a different 504 sam-type value, along with appropriate prompts and/or challenges. 505 This sequence of exchanges will continue until authentication 506 either succeeds or fails. 508 6. Security considerations 509 Single-use authentication mechanisms requiring the use of the 510 send-encrypted-sad option are discouraged as their use on the net- 511 work is less secure than the case where a combination of the users 512 password and SAD is used as the encryption key. In particular, 513 when the send-encrypted-sad option is used, an attacker who 514 observes the response and is in possession of the users' secret key 515 (which doesn't change from login to login) can use the key to 516 decrypt the response and obtain the single-use authentication data. 517 This is dependent on the SAM technology used. 519 If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field 520 but the client software being used does not support public-key 521 cryptography, it is possible that legitimate users may be denied 522 service. 524 An attacker in possession of the users encryption key (again, which 525 doesn't change from login to login) might be able to 526 generate/modify a SAM challenge and attach the appropriate check- 527 sum. This affects the security of both the send-encrypted-sad 528 option and the must-pk-encrypt-sad option. 530 7. Expiration 531 This Internet-Draft expires on Feburary 11, 1999. 533 8. References 535 [RFC1510] 536 The Kerberos Network Authentication System; Kohl and Neuman; 537 September 1993. 539 [RFC1760] 540 The S/Key One-Time Password System; Haller; February 1995 542 [RFC1636] 543 Report of IAB Workshop on Security in the Internet Architec- 544 ture; Braden, Clark, Crocker and Huitema; June 1994 546 9. Authors' Addresses 547 B. Clifford Neuman 548 USC/Information Sciences Institute 549 4676 Admiralty Way #1001 550 Marina del Rey, CA 90292-6695 552 Phone: 310-822-1511 553 EMail: bcn@isi.edu 555 Glen Zorn 556 Microsoft Corporation 557 One Microsoft Way 558 Redmond, WA 98052 560 Phone: 206-703-1559 561 EMail: glennz@microsoft.com 563 Ken Hornstein 564 ITT/US Naval Research Lab 565 4555 Overlook Avenue 566 Washington, DC 20375 568 Phone: 202-404-4765 569 EMail: kenh@cmf.nrl.navy.mil