idnits 2.17.1 draft-ietf-cat-kerberos-passwords-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) 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 11 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 11 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 a Security Considerations 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.) ** There are 233 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 199: '... sam-type-name[2] GeneralString OPTIONAL,...' RFC 2119 keyword, line 200: '... sam-track-id[3] GeneralString OPTIONAL,...' RFC 2119 keyword, line 201: '... sam-challenge-label[4] GeneralString OPTIONAL,...' RFC 2119 keyword, line 202: '... sam-challenge[5] GeneralString OPTIONAL,...' RFC 2119 keyword, line 203: '... 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 ...' == (228 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) -- Missing reference section? 'RFC1510' on line 523 looks like a reference -- Missing reference section? 'RFC1760' on line 527 looks like a reference -- Missing reference section? 'RFC1636' on line 530 looks like a reference -- Missing reference section? '0' on line 439 looks like a reference -- Missing reference section? '1' on line 440 looks like a reference -- Missing reference section? '2' on line 441 looks like a reference -- Missing reference section? '3' on line 442 looks like a reference -- Missing reference section? '4' on line 428 looks like a reference -- Missing reference section? '5' on line 430 looks like a reference -- Missing reference section? '6' on line 431 looks like a reference -- Missing reference section? '7' on line 204 looks like a reference -- Missing reference section? '8' on line 205 looks like a reference -- Missing reference section? '9' on line 206 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 16 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 August 6, 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 ftp.ietf.org (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 Feburary 33 11, 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 by 71 a principal as input to client software to be used in the creation 72 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, but if the use of a SAM is required, then the password by 136 itself is not sufficient for authentication. 138 The KDC will determine in an implementation- and policy-dependent 139 fashion if the client is required to utilize a single-use authenti- 140 cation mechanism. For example, the implementation may use IP 141 address screening to require principals authenticating from outside 142 a firewall to use a SAM, while principals on the inside need not. 143 If SAM usage is required, then the KDC will respond with a 144 KRB_ERROR message, with the error-code field set to 145 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1 146 structure that is a sequence of PA-DATA fields. 148 If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the 149 client should re-execute the authentication protocol from the 150 beginning, directing messages to another of the KDCs for the realm. 151 This is done to allow some methods to require that a single KDC be 152 used for SAM authentication when tight synchronization is needed 153 between all replicas and the KDC database propagation code does not 154 provide such synchronization. The corresponding padata-value will 155 contain an encoded sequence of host addresses [RFC1510], from which 156 the client must choose the KDC to be contacted next. 158 Otherwise, if one of the PA-DATA fields has the type PA-SAM- 159 CHALLENGE, the exchange will continue as described in section 5, 160 below. 162 4.2 Time-based Model 163 For mechanisms where no challenge is required, the user (or the 164 client software being utilized) may or may not know a priori 165 whether SAM usage is required. If it does not know, then the ini- 166 tial exchange may proceed as above. If it is known that a use of a 167 single-use authentication mechanism is required then the first 168 exchange can be skipped and the authentication will continue as 169 follows. 171 5. Authentication Using Passcodes 172 Prior to performing preauthentication using a single-use authenti- 173 cation mechanism, the client must know whether a challenge is 174 required (if the client doesn't have this information prior to its 175 sending the first KRB_AS_REQ message, it will be informed of the 176 requirement by the KDC, as described in section 4.1). The client 177 does NOT need to know the specific type of SAM in use. If a chal- 178 lenge is required the client will be sent the challenge by the KDC. 179 This means that a client supporting SAMs will be able to work with 180 new methods without modification. The challenge, as well as all 181 other prompts mentioned herein, can be internationalized by the KDC 182 on a per-principal basis. 184 If a KRB_ERROR message is received from the KDC indicating that SAM 185 usage is required, that message will include in its e-data field a 186 PA-DATA structure that encodes information about the SAM to be 187 used. This includes whether a challenge is required, and if so, 188 the challenge itself; and informational data about the type of SAM 189 that is in use, and how to prompt for the SAD. The SAM type is 190 informational only and does not affect the behavior of the client. 191 The prompt is also informational and may be presented to the user 192 by the client, or it may be safely ignored. 194 The ASN.1 definition for the SAM challenge is: 196 PA-SAM-CHALLENGE ::= SEQUENCE { 197 sam-type[0] INTEGER, 198 sam-flags[1] SAMFlags, 199 sam-type-name[2] GeneralString OPTIONAL, 200 sam-track-id[3] GeneralString OPTIONAL, 201 sam-challenge-label[4] GeneralString OPTIONAL, 202 sam-challenge[5] GeneralString OPTIONAL, 203 sam-response-prompt[6] GeneralString OPTIONAL, 204 sam-pk-for-sad[7] EncryptionKey OPTIONAL, 205 sam-nonce[8] INTEGER OPTIONAL, 206 sam-cksum[9] Checksum OPTIONAL 207 } 209 SAMFlags ::= BIT STRING { 210 use-sad-as-key[0], 211 send-encrypted-sad[1], 212 must-pk-encrypt-sad[2] 213 } 215 The sam-type field is informational only, but it must be specified 216 and sam-type values must be registered with the IANA. 218 Initially defined values of the sam-type codes are: 220 PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic 221 PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways 222 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0 223 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key 224 PA_SAM_TYPE_SECURID 5 -- Security Dynamics 225 PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard 227 PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and 228 PA_SAM_TYPE_CRYPTOCARD are popular token cards. PA_SAM_TYPE_SKEY 229 is the traditional S/Key protocol, in which the SAD verifier does 230 not have knowledge of the principal's S/Key secret. 231 PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the same SAD 232 and PC software or hardware device, but where the zeroth key (the 233 S/Key secret) is actually stored on, and can be used by, the SAD 234 verifier to independently generate the correct authentication data. 236 Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of 237 S/Key, viz., that the information required to generate the SAD need 238 not be stored on the host; but since the SAD verifier (which may be 239 the KDC) is assumed to be more secure than other hosts on the net- 240 work, it may be acceptable to give up this advantage in some situa- 241 tions. The advantage of using this S/Key variant is that the secu- 242 rity of the network protocol is strengthened since the SAD need not 243 be sent from the client to the KDC. Thus, the SAD can be used as 244 part of the key used to encrypt the encrypted parts of both the SPD 245 and the KRB_AS_REP message, rather than being sent protected by the 246 principal's Kerberos secret key which may have been previously 247 exposed to an attacker (see section 6, below). In any case, there 248 is a definite advantage to being interoperable with the S/Key algo- 249 rithm. 251 Due to the volatility of, and rapid developments in, the area of 252 single-use authentication mechanisms (both software-only and 253 hardware supported), any subsequently defined sam-type codes will 254 be maintained by the IANA. 256 The sam-flags field indicates whether the SAD is known by the KDC 257 (in which case it can be used as part of the encryption key for the 258 ensuing KRB_AS_REP message), or if it must be provided to the KDC 259 in a recoverable manner. If it is known to the KDC, use-sad-as-key 260 indicates that the SAD alone will be used to generate the encryp- 261 tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages, 262 and that the user will not need to also enter a password. We 263 recommend that this option not be used, and that the principal also 264 enter the Kerberos password, but for some situations, presentation 265 of the SAD alone may be acceptable. If the single-use authentica- 266 tion data is not known (and cannot be generated or discovered) by 267 the KDC, then send-encrypted-sad flag will be set, indicating that 268 the SAD must be sent to the KDC encrypted under the principal's 269 secret key. If neither use-sad-as-key nor send-encrypted-sad are 270 set, the client may assume that the KDC knows the SAD, but the Ker- 271 beros password should be used along with the passcode in the 272 derivation of the encryption key (see below). The must-pk- 273 encrypt-sad flag is reserved for future use. If this flag is set 274 and a client does not support the must-pk-encrypt-sad option (to be 275 defined in a separate document), the client will not be able to 276 complete the authentication and must notify the user. 278 Note that there are specific constraints on the integrity of the 279 PA-SAM-CHALLENGE when some of these options are specified. In par- 280 ticular, if any of these flags are set, a cryptographic checksum 281 must be present and verified. If absent, or the checksum does not 282 match the request, the challenge must be considered invalid and the 283 user notified. 285 The optional sam-type-name field is informational only. It may be 286 used by the client to display a short description of the type of 287 single-use authentication mechanism to be used. 289 The optional sam-track-id field may be returned by the KDC in the 290 KRB_ERROR message. If present, the client should copy this field 291 into the corresponding field of the SAM response sent in the subse- 292 quent KRB_AS_REQ message. This field may be used by the KDC to 293 match challenges and responses. It might be a suitably encoded 294 integer, or even be encrypted data with the KDC state encoded so 295 that the KDC doesn't have to maintain the state internally. 297 The sam-challenge-label field is informational and optional. If 298 present, a client may choose to precede the presentation of the 299 challenge with this string. For example, if the challenge is 300 135773 and the string in the sam-challenge-label field is "Enter 301 the following number on your card", the client may choose to 302 display to the user: 304 Enter the following number on your card: 135773 306 If no challenge label was presented, or if the client chooses to 307 ignore it, the client might display instead: 309 Challenge from authentication server: 135773 311 If the sam-checksum field is empty the sam-challenge-label should 312 be ignored, since in that case it may have been modified by an 313 adversary. Internationalization is supported by allowing customi- 314 zation of the challenge label and other strings on a per-principal 315 basis. 317 The optional sam-challenge field contains a string that will be 318 needed by the user to generate a suitable response. If the sam- 319 challenge field is left out, it indicates that the SAM in use does 320 not require a challenge, and that the authorized user should be 321 able to produce the correct SAD without one. If the sam-challenge 322 field is present, it is the data that is used by the SAD generator 323 to create the SAD to be used in the production of the SPD to be 324 included in the response. 326 The sam-response-prompt field is informational and optional. If 327 present, a client may choose to precede the prompt for the response 328 with the specified string; however, it should not be used if the 329 sam-checksum field is empty, since in that case the prompt may have 330 been modified by an adversary. If this field is empty the prompt 331 displayed will be hardcoded into the application, such as 333 Passcode: 335 sam-pk-for-sad is an optional field. It is included in the 336 interest of future extensability of the protocol to the use of 337 public-key cryptography. 339 The sam-nonce field is optional. If present, it should conform to 340 the specification of the nonce field in a KRB_KDC_REQ message 341 [RFC1510]. 343 The optional sam-cksum field contains a cryptographic checksum of 344 the preceding fields, protected using the same key as that used for 345 preauthentication in the intial KRB_AS_REQ message. While any 346 secure checksum method may be used, the RSA-MD5-DES type is recom- 347 mended and must be supported by the client. This field should 348 always be present if the initial KRB_AS_REQ message included a form 349 of cryptographic preauthentication (such as PA_ENC_TIMESTAMP). If 350 the intial message included preauthentication, but this field is 351 missing in the response, the client should reject the response. If 352 this field is present, the client should verify its correctness: if 353 the sam-cksum field is present in the KRB_ERROR message, but not 354 verified by the client, then an attacker can change the message 355 contents at will. Such a change could cause unexpected 356 instructions to be displayed to the user in the prompt string, or 357 allow the denial of service through the presentation of an invalid 358 challenge. Another effect of a change might be to effect a limited 359 chosen plaintext attack on the Kerberos password where the attacker 360 picks the nonce, and the challenge. 362 Note that it is possible for the KDC to generate a cryptographic 363 checksum for this message using the users' secret key even though 364 no cryptographic preauthentication was present in the initial 365 AS_REQ message. Doing so, however, makes material available which 366 enables an offline guessing attack against that key. 368 If the client is performing SAM preauthentication in the initial 369 message, without receipt of a PA-SAM-CHALLENGE (i.e. without wait- 370 ing for the KRB_ERROR message), and the SAM in use does not require 371 a challenge, the client will prompt for the SAD in an application- 372 specific manner. 374 Once the user has been prompted for and entered the SAD (and possi- 375 bly the Kerberos password), the client will derive a key to be used 376 to encrypt the preauthentication data for a KRB_AS_REQ message. 377 This key will be determined as follows: 379 By default, the key is derived from the password and the SAD 380 by running each through the string_to_key function [RFC1510] 381 separately; i.e., K1 = string_to_key(password) and K2 = 382 string_to_key(SAD). The K1 and K2 are then combined to form 383 a single key K in a manner specific to the type of key being 384 generated. For DES keys, K will be formed by XORing K1 and 385 K2, then correcting the parity of K. If the result matches 386 a "weak" or "semiweak" key as described in the DES specifi- 387 cation, it is XORed with the hexadecimal constant 388 00000000000000F0. 390 If the send-encrypted-sad flag is set, the key will be 391 derived by running the Kerberos password though the 392 string_to_key function in the normal fashion. 394 If the use-sad-as-key flag is set and the integrity of the 395 PA-SAM-CHALLENGE PADATA field can be verified using the 396 sam-cksum field, then the SAD is run through the 397 string_to_key function and the result is used as the encryp- 398 tion key for the request. WARNING: the use of single-use 399 authentication data in this manner is NOT recommended unless 400 the range of the SAD is large enough to make an exhaustive 401 off-line search impractical and the risks involved in the 402 use of SAD alone are fully considered. Also, note that 403 without the availabilty to the KDC of a relatively static, 404 unique secret key shared with the user, the only mechanisms 405 that can be used to protect the integrity of the PA-SAM- 406 CHALLENGE PADATA field are based on either public key cryp- 407 tography or the KDC's a priori knowledge of the SAD itself. 408 In the latter case, the client must obtain the SAD from the 409 user and use it to verify the integrity of the challenge 410 before the new KRB_AS_REQ message is sent. 412 The sam-pk-for-sad field is reserved for future use. If 413 this field is not empty and the client does not support the 414 use of public-key encryption for SAD (to be defined in a 415 separate document), the client will not be able to complete 416 the authentication and must notify the user. 418 The client will then send another KRB_AS_REQ message to the KDC, 419 but with a padata field with padata-type equal to PA-SAM-RESPONSE 420 and padata-value defined as follows: 422 PA-SAM-RESPONSE ::= SEQUENCE { 423 sam-type[0] INTEGER, 424 sam-flags[1] SAMFlags, 425 sam-track-id[2] GeneralString OPTIONAL, 426 sam-enc-key[3] EncryptedData 427 -- PA-ENC-SAM-KEY, 428 sam-enc-nonce-or-ts[4] EncryptedData 429 -- PA-ENC-SAM-RESPONSE-ENC, 430 sam-nonce[5] INTEGER OPTIONAL, 431 sam-patimestamp[6] KerberosTime OPTIONAL 432 } 434 PA-ENC-SAM-KEY ::= SEQUENCE { 435 sam-key[0] EncryptionKey 436 } 438 PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE { 439 sam-nonce[0] INTEGER OPTIONAL, 440 sam-timestamp[1] KerberosTime OPTIONAL, 441 sam-usec[2] INTEGER OPTIONAL, 442 sam-passcode[3] GeneralString OPTIONAL 443 } 445 The source of the data included in the PA-SAM-RESPONSE structure 446 depends upon whether or not a KRB_ERROR message was received by the 447 client from the KDC. 449 If an error reply was received, the sam-type and sam-flags fields 450 will contain copies of the same fields from the error message. If 451 the sam-nonce field was present in the KRB_ERROR message, then the 452 PA-ENC-PASSCODE-RESPONSE-ENC structure returned to the KDC will 453 include that value, encrypted as described above, the otpc_nonce 454 field in the KRB_AS_REQ message will contain a plaintext copy of 455 the same value and the sam-patimestamp field of the message will be 456 empty. If a KRB_ERROR message was received but the sam-nonce field 457 was omitted from it, the encrypted data will contain a timestamp 458 encrypted in the same manner, the sam-patimestamp field will con- 459 tain an unencrypted copy of the same value, and the sam-nonce field 460 will be empty. In either case, if the send-encrypted-sad flag is 461 set in the sam-flags field of the error message, the sam-sad field 462 must contain the entered single-use authentication data. 464 If no error reply was received (i.e., the client knows that a 465 single-use authentication mechanism is to be used), the sam-type 466 field must be set to a value chosen from the list of registered 467 sam-type codes. 469 The value of the sam-flags field may vary depending upon the type 470 of SAM in use, but in all cases the must-pk-encrypt-sad flag must 471 be zero. If the send-encrypted-sad flag is set, the sam-sad field 472 must contain the entered single-use authentication data. 474 The sam-enc-key field is reserved for future use. 476 Upon receipt the KDC validates this PADATA in much the same way 477 that it validates the PA-ENC-TS preauthentication method except 478 that it uses the SAD (if available, and possibly in conjunction 479 with saved state information or portions of the preauthentication 480 data) to determine the correct key(s) required to verify the 481 encrypted data. Note that if the KDC uses the sam-track-id field 482 to encode its state, the KDC is responsible for including informa- 483 tion in that field to detect modification or replay by an attacker. 485 The rest of the processing of the request proceeds normally, except 486 that instead of being encrypted in the users password, the 487 KRB_AS_REP message is encrypted in the key obtained above. Note, 488 however, that some single-use authentication mechanisms may require 489 further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication; 490 for example, in order to allow the server to resynchronize with the 491 drifting clock on a time-based token card. In these cases the KDC 492 may respond with another KRB_ERROR message containing a different 493 sam-type value, along with appropriate prompts and/or challenges. 494 This sequence of exchanges will continue until authentication 495 either succeeds or fails. 497 6. Limitations 498 Single-use authentication mechanisms requiring the use of the 499 send-encrypted-sad option are discouraged as their use on the net- 500 work is less secure than the case where a combination of the users 501 password and SAD is used as the encryption key. In particular, 502 when the send-encrypted-sad option is used, an attacker who 503 observes the response and is in possession of the users' secret key 504 (which doesn't change from login to login) can use the key to 505 decrypt the response and obtain the single-use authentication data. 507 If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field 508 but the client software being used does not support public-key 509 cryptography, it is possible that legitimate users may be denied 510 service. 512 An attacker in possession of the users encryption key (again, which 513 doesn't change from login to login) might be able to 514 generate/modify a SAM challenge and attach the appropriate check- 515 sum. This affects the security of both the send-encrypted-sad 516 option and the must-pk-encrypt-sad option. 518 7. Expiration 519 This Internet-Draft expires on Feburary 11, 1999. 521 8. References 523 [RFC1510] 524 The Kerberos Network Authentication System; Kohl and Neuman; 525 September 1993. 527 [RFC1760] 528 The S/Key One-Time Password System; Haller; February 1995 530 [RFC1636] 531 Report of IAB Workshop on Security in the Internet Architec- 532 ture; Braden, Clark, Crocker and Huitema; June 1994 534 9. Authors' Addresses 535 B. Clifford Neuman 536 USC/Information Sciences Institute 537 4676 Admiralty Way #1001 538 Marina del Rey, CA 90292-6695 540 Phone: 310-822-1511 541 EMail: bcn@isi.edu 543 Glen Zorn 544 Microsoft Corporation 545 One Microsoft Way 546 Redmond, WA 98052 548 Phone: 206-703-1559 549 EMail: glennz@microsoft.com 551 Ken Hornstein 552 ITT/US Naval Research Lab 553 4555 Overlook Avenue 554 Washington, DC 20375 556 Phone: 202-404-4765 557 EMail: kenh@cmf.nrl.navy.mil