INTERNET-DRAFT Ken Hornstein <draft-ietf-krb-wg-kerberos-sam-02.txt> Naval Research Laboratory Updates: RFC 1510 Ken Renard October 27, 2003 WareOnEarth Clifford Newman ISI Glen Zorn Cisco Systems Integrating Single-use Authentication Mechanisms with Kerberos 0. Status Of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in pro- gress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- dow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as <draft-ietf-krb-wg-kerberos-sam-02.txt>, and expires April 27, 2004. Please send comments to the authors. 1. Abstract This document defines extensions to the Kerberos protocol specifi- cation [RFC1510] which provide a method by which a variety of single-use authentication mechanisms may be supported within the protocol. The method defined specifies a standard fashion in which the preauthentication data and error data fields in Kerberos mes- sages may be used to support single-use authentication mechanisms. 2. Terminology To simplify the following discussion, we will define those terms which may be unfamiliar to the audience or specific to the discus- sion itself. Single-use Preauthentication Data (SPD): Data sent in the padata- value field of a Kerberos V5 message proving that knowledge of Hornstein, Renard, Newman, Zorn [Page 1]
INTERNET-DRAFT October 27, 2003 certain unique information is held by a principal. This informa- tion may or may not be identical to the single-use authentication data input to the client. For example, in the case of S/Key, the principal might input a one-time password (in any of several forms); the knowledge of this one-time password is taken to indi- cate knowledge of the principal's secret passphrase. Similarly, the SPD may or may not contain the provided single-use authentica- tion data. For instance, if a given single-use authentication mechanism includes a token which generates an encryption key for a supported cryptosystem, that key could be used to encrypt portions of the SPD before transmission. As long as the verification pro- cess of the mechanism was capable of independently generating the same key, the successful decryption of the SPD would provide assurance that the originator of the message was in possession of the token, as well as whatever information the token required to generate the encryption key. Single-use Authentication Mechanism (SAM): A system for generating and verifying authentication data which is usable only once. Single-use Authentication Data (SAD): SAM-specific data provided by a principal as input to client software to be used in the crea- tion of SPD. 3. Motivation and Scope Several single-use authentication mechanisms are currently in widespread use, including hardware-based schemes from vendors such as Enigma Logic, CRYPTOCard, and Security Dynamics and software- based methods like S/Key [RFC1760]. The hardware-based schemes typically require that the authenticating user carry a small, credit-card-sized electronic device (called a token) which is used to generate unique authentication data. Some tokens require the user to enter data into the device. This input may take the form of a Personal Identification Number (PIN), a server-generated chal- lenge string or both. Other tokens do not use a challenge-response technique, instead spontaneously generating new and unique authen- tication data every few seconds. These tokens are usually time- synchronized with a server. The use of one-time passwords and token cards as an authentication mechanism has steadily increased over the past few years; in addition, the Internet Architecture Board has encouraged the use of SAMs to improve Internet security [RFC1636]. The widespread acceptance of Kerberos within the Internet community has produced considerable demand for the integration of SAM tech- nology with the authentication protocol. Several currently avail- able implementations of Kerberos include support for some types of token cards, but the implementations are either not interoperable, or would require the release of source code (not always an option) to make them interoperate. This memo attempts to remedy that prob- lem by specifying a method in which SAM data may be securely tran- sported in Kerberos V5 messages in a standard, extensible fashion. This document does not, however, attempt to precisely specify Hornstein, Renard, Newman, Zorn [Page 2]
INTERNET-DRAFT October 27, 2003 either the generation or verification of SAM data, since this is likely to be SAM-specific; nor does it dictate the conditions under which SAM data must be included in Kerberos messages, since we con- sider this to be a matter of local policy. A primary reason for using a SAM with Kerberos is to reduce the threat from common attacks on Kerberos passwords (poorly chosen passwords, password guessing, etc). If passwords are used in com- bination with SAM authentication data, users must still adhere to sensible password policies and safe practices regarding the selec- tion, secrecy, and maintenance of their passwords. Depending on the specific mechanism used, the purpose of the SAD is to augment (or sometimes replace) the use of a password as a secret key. 4. Generic Approach - Two Models As outlined above, there are essentially two types of single-use authentication mechanisms: challenge/response and time-based. In order to support challenge/response mechanisms, the Kerberos Key Distribution Center (KDC) must communicate the appropriate chal- lenge string to the user, via the client software. Furthermore, some challenge/response mechanisms require tight synchronization between all instances of the KDC and the client. One example is S/Key and its variants. If the KDC and client do not perform the same number of message digest iterations, the protocol will fail; worse, it might be possible for an eavesdropping attacker to cap- ture a valid S/Key passcode and replay it to a KDC replica which had an outdated iteration number. In the time-based case, no chal- lenge is required. This naturally gives rise to two modes of client behavior, described below. 4.1 Challenge/Response Model The client begins with an initial KRB_AS_REQ message to the KDC, possibly using existing preauthentication methods (PA-ENC-TIMESTAMP (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on whether preauthentication is used, the user may or may not be prompted at this time for a Kerberos password. If (for example) encrypted timestamp preauthentication is used, then the user will be prompted; on the other hand, if no preauthentication is in use the prompt for the password may be deferred (possibly forever). Note that the use of preauthentication here may allow an offline guessing attack against the Kerberos password separate from the SPD. However, if the use of a SAM is required, then the password by itself is not sufficient for authentication. (Specify character strings as UTF-8) The KDC will determine in an implementation- and policy-dependent fashion if the client is required to utilize a single-use authenti- cation mechanism. For example, the implementation may use IP address screening to require principals authenticating from outside a firewall to use a SAM, while principals on the inside need not. If SAM usage is required, then the KDC will respond with a KRB_ERROR message, with the error-code field set to Hornstein, Renard, Newman, Zorn [Page 3]
INTERNET-DRAFT October 27, 2003 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1 structure that is a sequence of PA-DATA fields. If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the client should re-execute the authentication protocol from the beginning, directing messages to another of the KDCs for the realm. This is done to allow some methods to require that a single KDC be used for SAM authentication when tight synchronization is needed between all replicas and the KDC database propagation code does not provide such synchronization. The corresponding padata-value will contain an encoded sequence of host addresses [RFC1510], from which the client must choose the KDC to be contacted next. The PA-SAM- REDIRECT is defined as: PA-SAM-REDIRECT ::= HostAddresses Client implementations SHOULD check the addresses in the PA-SAM- REDIRECT and verify that they are a subset of the KDC addresses that they have been configured for that realm. If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then if one of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the exchange will continue as described in section 5, below. Note that some Kerberos implementations support an older preauthen- tication mechanism with the padata types PA-SAM-CHALLENGE and PA- SAM-RESPONSE. That protocol is depreciated and not defined here. 4.2 Time-based Model For mechanisms where no challenge is required, the user (or the client software being utilized) may or may not know a priori whether SAM usage is required. If it does not know, then the ini- tial exchange may proceed as above. If it is known that a use of a single-use authentication mechanism is required then the first exchange can be skipped and the authentication will continue as follows. 5. SAM Preauthentication An optional SAM-CHALLENGE-2 may be sent from the KDC to the client and the client will send a SAM-RESPONSE-2 as pre-authentication data in the KRB-AS-REQ. The details of the messages follow. 5.1 SAM-CHALLENGE-2 Prior to performing preauthentication using a single-use authenti- cation mechanism, the client must know whether a challenge is required (if the client doesn't have this information prior to its sending the first KRB_AS_REQ message, it will be informed of the requirement by the KDC, as described in section 4.1). The client Hornstein, Renard, Newman, Zorn [Page 4]
INTERNET-DRAFT October 27, 2003 does NOT need to know the specific type of SAM in use. If a chal- lenge is required the client will be sent the challenge by the KDC. This means that a client supporting SAMs will be able to work with new methods without modification. The challenge, as well as all other prompts mentioned herein, can be internationalized by the KDC on a per-principal basis. If a KRB_ERROR message is received from the KDC indicating that SAM usage is required, that message will include in its e-data field a PA-DATA structure that encodes information about the SAM to be used. This includes whether a challenge is required, and if so, the challenge itself; and informational data about the type of SAM that is in use, and how to prompt for the SAD. The SAM type is informational only and does not affect the behavior of the client. The prompt is also informational and may be presented to the user by the client, or it may be safely ignored. The ASN.1 definition for the SAM challenge is: PA-SAM-CHALLENGE-2 ::= SEQUENCE { sam-body[0] PA-SAM-CHALLENGE-2-BODY, sam-cksum[1] SEQUENCE (1..MAX) OF Checksum, ... } PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE { sam-type[0] INTEGER (0..4294967295), sam-flags[1] SAMFlags, sam-type-name[2] GeneralString OPTIONAL, sam-track-id[3] GeneralString OPTIONAL, -- Key usage of 26 sam-challenge-label[4] GeneralString OPTIONAL, sam-challenge[5] GeneralString OPTIONAL, sam-response-prompt[6] GeneralString OPTIONAL, sam-pk-for-sad[7] OCTET STRING OPTIONAL, sam-nonce[8] INTEGER (0..4294967295), sam-etype[9] INTEGER (0..4294967295), ... } SAMFlags ::= BIT STRING (SIZE (32..MAX)) -- use-sad-as-key(0) -- send-encrypted-sad(1) -- must-pk-encrypt-sad(2) 5.1.1 SAM-TYPE and SAM-TYPE-NAME Fields The sam-type field is informational only, but it must be specified and sam-type values must be registered with the IANA. Initially defined values of the sam-type codes are: PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways Hornstein, Renard, Newman, Zorn [Page 5]
INTERNET-DRAFT October 27, 2003 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key PA_SAM_TYPE_SECURID 5 -- Security Dynamics PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and PA_SAM_TYPE_CRYPTOCARD represent popular token cards. PA_SAM_TYPE_SKEY is the traditional S/Key protocol, in which the SAD verifier does not have knowledge of the principal's S/Key secret. PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the same SAD and PC software or hardware device, but where the zeroth key (the S/Key secret) is actually stored on, and can be used by, the SAD verifier to independently generate the correct authentica- tion data. Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of S/Key, viz., that the information required to generate the SAD need not be stored on the host; but since the SAD verifier (which may be the KDC) is assumed to be more secure than other hosts on the net- work, it may be acceptable to give up this advantage in some situa- tions. The advantage of using this S/Key variant is that the secu- rity of the network protocol is strengthened since the SAD need not be sent from the client to the KDC. Thus, the SAD can be used as part of the key used to encrypt the encrypted parts of both the SPD and the KRB_AS_REP message, rather than being sent protected by the principal's Kerberos secret key which may have been previously exposed to an attacker (see section 6, below). In any case, there is a definite advantage to being interoperable with the S/Key algo- rithm. Due to the volatility of, and rapid developments in, the area of single-use authentication mechanisms (both software-only and hardware supported), any subsequently defined sam-type codes will be maintained by the IANA. The optional sam-type-name field is a UTF-8 character string for informational use only. It may be used by the client to display a short description of the type of single-use authentication mechan- ism to be used. 5.1.2 SAM-FLAGS Field The sam-flags field indicates whether the SAD is known by the KDC (in which case it can be used as part of the encryption key for the ensuing KRB_AS_REP message), or if it must be provided to the KDC in a recoverable manner. If it is known to the KDC, use-sad-as-key indicates that the SAD alone will be used to generate the encryp- tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages, and that the user will not need to also enter a password. We recommend that this option only be used if the SAD will be used to generate adequate keying material (sufficient length, secrecy, ran- domness) for the cryptographic algorithm used. If the single-use authentication data is not known (and cannot be generated or discovered) by the KDC, then send-encrypted-sad flag will be set, Hornstein, Renard, Newman, Zorn [Page 6]
INTERNET-DRAFT October 27, 2003 indicating that the SAD must be sent to the KDC encrypted under the principal's secret key. If neither use-sad-as-key nor send- encrypted-sad are set, the client may assume that the KDC knows the SAD, but the Kerberos password should be used along with the passcode in the derivation of the encryption key (see below). No more than one of the send-encrypted-sad and use-sad-as-key flags should be in a SAM-CHALLENGE-2. The must-pk-encrypt-sad flag is reserved for future use. If this flag is set and a client does not support the must-pk-encrypt-sad option (to be defined in a separate document), the client will not be able to complete the authentication and must notify the user. 5.1.3 SAM-CHECKSUM Field The sam-cksum field contains a sequence of at least one crypto- graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence. If the send-encrypted-sad flag is set, the key to be used for this checksum is the client's long-term secret. If the use-sad-as-key flag is set, then the SAD alone will be used as the key. If nei- ther flag is set, then the key used for this checksum is derived from the SAD and the user's password (see section 5.2). The checksum algorithm to be used for this is the mandatory check- sum associated with the encryption algorithm specified in the sam- etype field, with a key usage of 25. 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. The sam-cksum field is generated by calculating the specified checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence. If no checksum is included, or is of the wrong type, or none are found which are correct, the client MUST abort the dialogue with the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM, KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes- sages. 5.1.4 SAM-TRACK-ID Field The optional sam-track-id field may be returned by the KDC in the KRB_ERROR message. If present, the client MUST copy this field into the corresponding field of the SAM response sent in the subse- quent KRB_AS_REQ message. This field may be used by the KDC to Hornstein, Renard, Newman, Zorn [Page 7]
INTERNET-DRAFT October 27, 2003 match challenges and responses. It might be a suitably encoded integer, or even be encrypted data with the KDC state encoded so that the KDC doesn't have to maintain the state internally. Note that when a KDC supplies a sam-track-id, it MUST link the sam- track-id with the sam-nonce field to prevent spoofing of the sam- track-id field. The key usage type 26 is reserved for use to encrypt the sam- track-id data. The key used to encrypt the sam-track-id is mechanism-dependent. 5.1.5 SAM-CHALLENGE-LABEL Field The sam-challenge-label field is informational and optional. If it is included, is will be an UTF-8 encoded character. If present, a client may choose to precede the presentation of the challenge with this string. For example, if the challenge is 135773 and the string in the sam-challenge-label field is "Enter the following number on your card", the client may choose to display to the user: Enter the following number on your card: 135773 If no challenge label was presented, or if the client chooses to ignore it, the client might display instead: Challenge from authentication server: 135773 Internationalization is supported by allowing customization of the challenge label and other strings on a per-principal basis. Note that this character string should be encoded using UTF-8. 5.1.6 SAM-CHALLENGE Field The optional sam-challenge field contains a string that will be needed by the user to generate a suitable response. If the sam- challenge field is left out, it indicates that the SAM in use does not require a challenge, and that the authorized user should be able to produce the correct SAD without one. If the sam-challenge field is present, it is the data that is used by the SAD generator to create the SAD to be used in the production of the SPD to be included in the response. 5.1.7 SAM-RESPONSE-PROMPT Field The sam-response-prompt field is informational and optional. If present, a client may choose to precede the prompt for the response with the specified string. Passcode: 5.1.8 SAM-PK-FOR-SAD Field sam-pk-for-sad is an optional field. It is included in the interest of future extensability of the protocol to the use of Hornstein, Renard, Newman, Zorn [Page 8]
INTERNET-DRAFT October 27, 2003 public-key cryptography. 5.1.9 SAM-NONCE Field The sam-nonce is a KDC-supplied nonce and should conform to the specification of the nonce field in a KRB_KDC_REQ message [RFC1510]. Challenge/Response mechanisms MUST link the nonce field with the sam-track-id (if one is included) to prevent replay of the sam- track-id field. 5.1.10 SAM-ETYPE Field The sam-etype field contains the encryption type to be used by the client for all encrypted fields in the PA-SAM-RESPONSE-2 message. The KDC should pick an appropriate encryption algorithm based on the encryption algorithms listed in the client's initial KRB_AS_REQ. 5.2 Obtaining SAM Authentication Data If the client is performing SAM preauthentication in the initial message, without receipt of a PA-SAM-CHALLENGE-2 (i.e. without waiting for the KRB_ERROR message), and the SAM in use does not require a challenge, the client will prompt for the SAD in an application-specific manner. Once the user has been prompted for and entered the SAD (and possi- bly the Kerberos password), the client will derive a key to be used to encrypt the preauthentication data for a KRB_AS_REQ message. This key will be determined as follows: By default, the key is derived from the password and the SAD by running each through the string_to_key function [RFC1510] separately; i.e., K1 = string_to_key(password) and K2 = string_to_key(SAD). When the keys are both DES or 3DES, keys K1 and K2 will be combined using the algorithm described in Appendix B, ``DES/3DES Key Combination Algo- rithm''. For all other encryption algorithms, the algorithm described in Appendix A, ``Key Combination Algorithm'' shall be used. Note that this algorithm is not commutative; an implementation MUST insure that K1 is the key corresponding to the user's long-term password, and K2 is the output from the SAD. In either case, the salt used by the string_to_key algorithm for the SAD shall be the same salt as used for the user's password. If the send-encrypted-sad flag is set, the key will be derived by running the Kerberos password though the string_to_key function in the normal fashion. If the use-sad-as-key flag is set and the integrity of the PA-SAM-CHALLENGE-2 PADATA field can be verified using the Hornstein, Renard, Newman, Zorn [Page 9]
INTERNET-DRAFT October 27, 2003 sam-cksum field, then the SAD is run through the string_to_key function and the result is used as the encryp- tion key for the request. WARNING: the use of single-use authentication data in this manner is NOT recommended unless the range of the SAD is large enough to make an exhaustive off-line search impractical and the risks involved in the use of SAD alone are fully considered. Also, note that without the availability to the KDC of a relatively static, unique secret key shared with the user, the only mechanisms that can be used to protect the integrity of the PA-SAM- CHALLENGE-2 PADATA field are based on either public key cryptography or the KDC's a priori knowledge of the SAD itself. In the latter case, the client must obtain the SAD from the user and use it to verify the integrity of the challenge before the new KRB_AS_REQ message is sent. The sam-pk-for-sad field is reserved for future use. If this field is not empty and the client does not support the use of public-key encryption for SAD (to be defined in a separate document), the client will not be able to complete the authentication and must notify the user. 5.3 SAM-RESPONSE PA-DATA The client will then send another KRB_AS_REQ message to the KDC, but with a padata field with padata-type equal to PA-SAM-RESPONSE-2 and padata-value defined as follows: PA-SAM-RESPONSE-2 ::= SEQUENCE { sam-type[0] INTEGER (0..4294967295), sam-flags[1] SAMFlags, sam-track-id[2] GeneralString OPTIONAL, sam-enc-nonce-or-sad[3] EncryptedData, -- PA-ENC-SAM-RESPONSE-ENC -- Key usage of 27 sam-nonce[4] INTEGER (0..4294967295), ... } PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE { sam-nonce[0] INTEGER (0..4294967295), sam-sad[1] GeneralString OPTIONAL, ... } The source of the data included in the PA-SAM-RESPONSE-2 structure depends upon whether or not a KRB_ERROR message was received by the client from the KDC. 5.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields If an error reply was received, the sam-type, sam-flags, and sam- nonce fields will contain copies of the same fields from the error message. Hornstein, Renard, Newman, Zorn [Page 10]
INTERNET-DRAFT October 27, 2003 If no error reply was received (i.e., the client knows that a single-use authentication mechanism is to be used), the sam-type field must be set to a value chosen from the list of registered sam-type codes. The value of the sam-flags field may vary depending upon the type of SAM in use, but in all cases the must-pk-encrypt-sad flag must be zero. If the send-encrypted-sad flag is set, the sam-sad field must contain the entered single-use authentication data (see Sec- tion 5.3.3). 5.3.2 SAM-TRACK-ID Field Note that if there is no sam-track-id in the request, it MUST be omitted in the response. Otherwise, the sam-track-id data MUST be copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2. 5.3.3 SAM-ENC-NONCE-OR-SAD The sam-enc-nonce-or-sad field represends the results of the preau- thentication process. It contains the encrypted SAD or a SAD- encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted with the SAD, password + SAD, or password (based on the sam-flags) with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes- sage are populated as follows: The sam-nonce contains the nonce from the SAM-CHALLENGE-2. This is the same as the unencrypted sam-nonce described in section 5.2.2. The sam-sad field contains the SAD if send-encrypted-sad is set in the sam-flags. Otherwise, it is omitted. 5.4 Verification of the SAM-RESPONSE-2 Upon receipt the KDC validates this PADATA in much the same way that it validates the PA-ENC-TS preauthentication method except that it uses the SAD (if available, and possibly in conjunction with saved state information or portions of the preauthentication data) to determine the correct key(s) required to verify the encrypted data. Note that if the KDC uses the sam-track-id field to encode its state, the SAM-verification routine is responsible for including information in that field to detect modification or replay by an attacker. 5.5 KRB5-AS-REP The rest of the processing of the request proceeds normally, except that instead of being encrypted in the user's secret key, the KRB_AS_REP message is encrypted in the key obtained above. Note, however, that some single-use authentication mechanisms may require further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication; for example, in order to allow the server to resynchronize with the drifting clock on a time-based token card. In these cases the KDC may respond with another KRB_ERROR message containing a different Hornstein, Renard, Newman, Zorn [Page 11]
INTERNET-DRAFT October 27, 2003 sam-type value, along with appropriate prompts and/or challenges. This sequence of exchanges will continue until authentication either succeeds or fails. 6. Requirements for Single-use Authentication Mechanisms Single-Use Authentication Mechanisms vary in their capabilities. To aid implementers, we summarize here how various types of SAMs would operate using this protocool. If a SAM system can provide a SAD or a sequence of valid SADs to the KDC, then the implementation SHOULD NOT set the send- encrypted-sad flag. This SAM system should provide the SAD to the KDC, which will combine it with the user's long-term key (password) to generate the key used to generate the checksum placed in the sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes- sage by using it to decrypt the sam-enc-nonce-or-sad field and as the key to encrypt the KRB-AS-REP. If a SAM system returns a range of valid responses, each response can be used to generate a valid checksum which can be placed in the sam-cksum sequence. If a SAM system can generate enough entropy, it can set the use- sad-as-key field to use the SAD solely as keying material, but it should be noted that most SAM systems that require the user to enter in a response do not have enough entropy to replace the user's long-term key. The most likely consumer of use-sad-as-key is a hardware token which communicates a key directly with Kerberos client software. With or without the use of use-sad-as-key, this is the preferred method as it protects against offline dictionary attacks against the user's password. If a SAM system cannot provide a SAD or a sequence of SADs to the KDC, then the send-encrypted-sad flag must be set. In this case, the SAD will be encrypted using the user's long-term key in the PA-SAM-RESPONSE-2 message. It should be noted that this is a weaker solution, as it does not protect the user's password against offline dictionary attacks, and any additional entropy provided by the SAM system cannot be used. 7. Security considerations Single-use authentication mechanisms requiring the use of the send-encrypted-sad option are discouraged as their use on the net- work is less secure than the case where a combination of the users password and SAD is used as the encryption key. In particular, when the send-encrypted-sad option is used, an attacker who observes the response and is in possession of the users' secret key (which doesn't change from login to login) can use the key to decrypt the response and obtain the single-use authentication data. This is dependent on the SAM technology used. If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field but the client software being used does not support public-key Hornstein, Renard, Newman, Zorn [Page 12]
INTERNET-DRAFT October 27, 2003 cryptography, it is possible that legitimate users may be denied service. An attacker in possession of the users encryption key (again, which doesn't change from login to login) might be able to generate/modify a SAM challenge and attach the appropriate check- sum. This affects the security of both the send-encrypted-sad option and the must-pk-encrypt-sad option. 8. Expiration This Internet-Draft expires on April 27, 2004. 9. References [RFC1510] The Kerberos Network Authentication System; Kohl and Neuman; September 1993. [RFC1760] The S/Key One-Time Password System; Haller; February 1995 [RFC1636] Report of IAB Workshop on Security in the Internet Architec- ture; Braden, Clark, Crocker and Huitema; June 1994 [KCRYPTO] Encryption and Checksum Specifications for Kerberos 5; Rae- burn; May 2002 Hornstein, Renard, Newman, Zorn [Page 13]
INTERNET-DRAFT October 27, 2003 10. Authors' Addresses Ken Hornstein Naval Research Laboratory 4555 Overlook Avenue Washington, DC 20375 Phone: 202-404-4765 EMail: kenh@cmf.nrl.navy.mil Ken Renard WareOnEarth 6849 Old Dominion Dr, Suite 365 Annandale, VA 22003 Phone: 703-622-3469 EMail: kdrenard@wareonearth.com B. Clifford Neuman USC/Information Sciences Institute 4676 Admiralty Way #1001 Marina del Rey, CA 90292-6695 Phone: 310-822-1511 EMail: bcn@isi.edu Glen Zorn Cisco Systems 500 108th Ave NE Suite 500 Bellevue, WA 98004 Phone: 425-344-8113 EMail: gwz@cisco.com Hornstein, Renard, Newman, Zorn [Page 14]
INTERNET-DRAFT October 27, 2003 Appendix A - Key combination algorithm Definitions: prf - Pseudo-random function that outputs an octet string based on an input key and a input octet string (defined in [KCRYPTO]) ^ - Exclusive-OR operation random-to-key - Generates an encryption key from random input (defined in [KCRYPTO]) Given two input keys, K1 and K2, where K1 is derived from the user's long-term password, and K2 is derived from the SAD, output key (K3) is derived as follows: Two sequence of octets, R1 and R2, shall be produced for each key K1 and K2. R1 and R2 will be generated by iterating over calls to prf() until enough bits are generated as needed by the random-to- key function for the encryption type specified for K3. The octet-string parameter to the prf() function shall be the ASCII string "CombineA" for K1, and "CombineB" for K2. These have the following byte values: { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x41 } { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x42 } Furthermore, on each iteration both octet-strings will have appended to them the iteration count in the form of an ASCII, base 10, numeral. The iteration count shall start at zero. The format of the iteration count is equivalant to the C language "%d" format to the printf() function call. Pseudo code implementing this fol- lows: count = 0; while ( bits < required_bits) { sprintf(A1, "CombineA%d", count); sprintf(A2, "CombineB%d", count); R1 += prf(K1, A1); R2 += prf(K2, A2); count++; } When R1 and R2 have been generated, they are truncated if the they are longer than the length required by random-to-key. The key is then generated as follows: K3 = random-to-key(R1 ^ R2) Hornstein, Renard, Newman, Zorn [Page 15]
INTERNET-DRAFT October 27, 2003 Appendix B - DES/3DES Key combination algorithm Definitions: DR - generate "random" data from an encryption key (defined in [KCRYPTO]) n-fold - "stretches" or "shrinks" a sequence bits to a specified size (defined in [KCRYPTO]) random-to-key - Generates an encryption key from random input (defined in [KCRYPTO]) DK - Derive-Key, defined in [KCRYPTO]) CombineConstant - The ASCII encoding of the string "combine", which is defined as the following byte string: { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 } Note: | means "concatenate" Given two input keys, K1 and K2, the Combine-Key function is as follows: R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1)) rnd = n-fold(R1 | R2) tkey = random-to-key(rnd) Combine-Key(K1, K2) = DK(tkey, CombineConstant) Hornstein, Renard, Newman, Zorn [Page 16]
