INTERNET-DRAFT Clifford Neuman ISI Updates: RFC 1510 Glen Zorn April 12, 1995 CyberSAFE Corporation Integrating One-time Passwords with Kerberos 0. Status Of this Memo This document is an Internet-Draft. 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 , and expires October 12, 1995. Please send comments to the authors. 1. Abstract This document defines extensions to the Kerberos protocol specifi- cation (RFC 1510, "The Kerberos Network Authentication Service (V5)", September 1993) which provide a method by which a variety of one-time password mechanisms may be supported within the protocol. The method defined specifies a standard fashion in which the preau- thentication data and error data fields in Kerberos messages may be used to transport one-time password data. 2. Motivation One-time (or single use) passwords are, as the name suggests, pass- words which may be used at most once as a means of authentication. Several one-time password mechanisms are currently in widespread use, including hardware-based schemes from vendors such as Enigma Logic, Digital Pathways and Security Dynamics and software-based mechanisms like S/Key. 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 Neuman & Zorn [Page 1] INTERNET-DRAFT April 12, 1995 the one-time password. Some tokens require the user to enter data into the device. This input may take the form of a Personal Iden- tification Number (PIN), a server-generated challenge string or both. The token uses the challenge string to help generate the single-use password. Other tokens do not use a challenge-response technique, instead spontaneously generating a new, unique password 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 one-time passwords to improve Internet security. The popularity of the Kerberos authentication protocol is also increasing, and with it the demand for the integration of one-time password technology. Several currently available 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 intero- perate. This memo attempts to remedy that problem. For the sake of brevity, "one-time password" will often be abbreviated to "passcode" in the remainder of this document. 3. Generic Approach - Two Models As outlined above, there are essentially two types of passcode mechanisms: challenge/response and time-based. In order to support challenge/response mechanisms, the Kerberos Key Distribution Center (KDC) must communicate the appropriate challenge 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 eavesdopping attacker to capture a valid S/Key passcode and replay it to a KDC replica which had an outdated iteration number. In the time-based case, no challenge is required. This naturally gives rise to two modes of client behavior, described below. 3.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 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. Note that the use of preauthentication here may allow an offline guessing attack against the Kerberos password separate from the one-time passcode, but if a passcode is required, then the password by itself is not sufficient Neuman & Zorn [Page 2] INTERNET-DRAFT April 12, 1995 for authentication. The KDC will determine in an implementation-dependent fashion if the client is required to present a one time passcode. For exam- ple, the implementation may use IP address screening to require principals authenticating from outside a firewall to use passcodes, while principals on the inside need not. If a passcode is required, then the KDC will respond with a KRB_ERROR message, with the error-code field set to 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-OT-PASSCODE- 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 passcode authentication if tight synchroni- zation is needed between all replicas, and the KDC database propo- gation code does not provide such synchronization. The correspond- ing padata-value will contain an encoded sequence of host addresses (see RFC 1510, section 5.2), from which the client must choose the KDC to be contacted next. Otherwise, if one of the PA-DATA fields has the type PA-OT- PASSCODE-CHALLENGE, the exchange will continue as described in sec- tion 4, below. 3.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 a one time password is required. If it does not know, then the initial exchange may proceed as above. If it is known that a one time password is required then the first exchange can be skipped and the authentication will continue as follows. 4. Authentication Using Passcodes Prior to performing preauthentication using a single use password, 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 3.1). The client does NOT need to know the specific kind of passcode in use. If a challenge is required the client will be sent the challenge by the KDC. This means that a client supporting one-time passwords will be able to work with new methods without modification. Internationalization is sup- ported by allowing customization of the challenge label and other strings on a per-principal basis by the KDC. If a KRB_ERROR message is received from the KDC indicating that a passcode is required, that message will include in its e-data field Neuman & Zorn [Page 3] INTERNET-DRAFT April 12, 1995 a PA-DATA structure that encodes information about the passcode that is needed. This includes whether a challenge is required, and if so, the challenge itself; and information about the type of passcode that is needed, and how to prompt for the passcode. The type of the passcode 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 passcode challenge is: PA-OT-PASSCODE-CHALLENGE ::= SEQUENCE { otpc-type[0] INTEGER, otpc-flags[1] OTPCFlags, otpc-type-name[2] GeneralString OPTIONAL, otpc-track-id[3] GeneralString OPTIONAL, otpc-challenge-label[4] GeneralString OPTIONAL, otpc-challenge[5] GeneralString OPTIONAL, otpc-response-prompt[6] GeneralString OPTIONAL, otpc-pk-for-passcode[7] EncryptionKey OPTIONAL, otpc-nonce[8] INTEGER OPTIONAL, otpc-cksum[9] Checksum OPTIONAL } OTPCFlags ::= BIT STRING { use-passcode-as-key[0], send-encrypted-passcode[1], must-pk-encrypt-passcode[2] } The otpc-type field is informational only, but it must be specified and otpc-type values must be registered with the IANA. Initially defined values of the otpc-type codes are: PA_OTPC_TYPE_ENIGMA 1 -- Enigma Logic PA_OTPC_TYPE_DIGI_PATH 2 -- Digital Pathways PA_OTPC_TYPE_SKEY_K0 3 -- S/key where KDC has key 0 PA_OTPC_TYPE_SKEY 4 -- Traditional S/Key PA_OTPC_TYPE_SECURID 5 -- Security Dynamics PA_OTPC_TYPE_SECURID, PA_OTPC_TYPE_DIGI_PATH and PA_OTPC_TYPE_ENIGMA are popular token cards. PA_OTPC_TYPE_SKEY is the traditional S/Key protocol, in which the KDC will not know the passcode. PA_OTPC_TYPE_SKEY_K0 is a variant of S/Key that uses the same passcodes 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 KDC to generate the correct passcode. Note that using PA_OTPC_TYPE_SKEY_K0 gives up one advantage of S/Key, viz., that the information required to generate the key need not be stored on the host; but since the KDC is assumed to be more secure than other hosts on the network, it may be acceptable to give up this advantage in some situations. The advantage of using Neuman & Zorn [Page 4] INTERNET-DRAFT April 12, 1995 the S/Key variant is that the security of the network protocol is strengthened since the passcode is known by the KDC and can be used as part of the key used to encrypt the KRB_AS_REP message, rather than being sent protected by an encryption key that has been sub- ject to possible prior exposure to an attacker (see section 5, below). In any case, interoperability with the S/Key algorithm is important. Due to the volatility of, and rapid developments in, the area of one-time password mechanisms (both software-only and hardware sup- ported) any additional defined otpc-type codes will be maintained by the IANA. The otpc-flags field indicates whether the passcode is known by the KDC (in which case it can be used as part of the encryption key for the response), or if it must be provided to the KDC in a recover- able manner. If it is known to the KDC, use-passcode-as-key indi- cates that the passcode 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 not be used, and that the user also enter a password, but for some situations, demonstration of knowledge of the passcode alone may be acceptable. If the passcode is not known by the KDC, then send-encrypted-passcode will be set, indicating that the passcode must be sent to the KDC encrypted under the key used in the response. If neither use-passcode-as-key nor send-encrypted-passcode are set, the client may assume that the KDC knows the passcode, but the Kerberos password should be used along with the passcode in the derivation of the encryption key (see below). The must-pk-encrypt-passcode flag is reserved for future use. If this flag is set and a client does not support the must-pk-encrypt-passcode option (to be defined in a separate docu- ment), the client will not be able to complete the authentication and must notify the user. Note that there are specific constraints on the integrity of the PA-OT-PASSCODE-CHALLENGE when some of these options are specified. In particular, if any of these flags are set, a cryptographic checksum must be present and verified. If absent, or the checksum does not match the request, the challenge must be considered invalid and the user notified. The optional otpc-type-name field is informational only. It may be used by the client to display a short description of the type of passcode required. The optional otpc-track-id field may be returned by the KDC in the KRB_ERROR message. If present, the client should copy this field into the corresponding field of the challenge response sent in the subsequent KRB_AS_REQ message. This field may be used by the KDC to 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. Neuman & Zorn [Page 5] INTERNET-DRAFT April 12, 1995 The otpc-challenge-label field is informational and optional. If present, a client may choose to precede the presentation of the challenge with the label. For example, if the challenge is 135773 and the string in the otpc-challenge-label field is "Enter the fol- lowing 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 If the otpc-checksum field is empty the otpc-challenge-label should be ignored, since in that case it may have been modified by an adversary. The optional otpc-challenge field contains a string that will be needed by the user to generate a suitable response. If the otpc- challenge field is left out, it indicates that the type of passcode in use does not require a challenge, and that the authorized user should be able to enter the correct passcode without one. If the otpc-challenge field is present, it is the data that is input to the one time password mechanism to generate the response. The otpc-response-prompt field is informational and optional. If present, a client may choose to precede the prompt for the response with the specified string; however, it should not be used if the otpc-checksum field is empty, since in that case the prompt may have been modified by an adversary. If this field is empty the prompt displayed will be hardcoded into the application, such as Passcode: otpc-pk-for-passcode is an optional field. It is included in the interest of future extensability of the protocol to the use of public-key cryptography. The otpc-nonce field is optional. If present, it should conform to the specification of the nonce field in a KRB_KDC_REQ message (see RFC 1510, section 5.4.1). The optional otpc-cksum field contains a cryptographic checksum of the preceding fields, protected using the same key as that used for preauthentication in the intial KRB_AS_REQ message. While any secure checksum method may be used, the RSA-MD5-DES type is recom- mended and must be supported by the client. This field should always be present if the initial KRB_AS_REQ message included a form of cryptographic preauthentication (such as PA_ENC_TIMESTAMP). If the intial message included preauthentication, but this field is missing in the response, the client should reject the response. If this field is present, the client should verify its correctness: if the otpc-cksum field is present in the KRB_ERROR message, but not Neuman & Zorn [Page 6] INTERNET-DRAFT April 12, 1995 verified by the client, then an attacker can change the message contents at will. Such a change could cause unexpected instruc- tions to be displayed to the user in the prompt string, or allow the denial of service through the presentation of an invalid chal- lenge. Another effect of a change might be to effect a limited chosen plaintext attack on the Kerberos password where the attacker picks the nonce, and the challenge. Note that it is possible for the KDC to generate a cryptographic checksum for this message using the users' secret key even though no cryptographic preauthentication was present in the initial AS_REQ message. Doing so, however, makes material available which enables an offline guessing attack against the key. If the client is performing passcode preauthentication in the ini- tial message, without receipt of a PA-OT-PASSCODE-CHALLENGE (i.e. without waiting for the KRB_ERROR message), and the passcode scheme in use does not require a challenge, the client will prompt for the passcode in an application-specific manner. Once the user has been prompted for and entered the passcode (and possibly the 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 passcode by running each through the string_to_key function (see RFC 1510, section 6.3.4) separately; i.e., K1 = string_to_key(password) and K2 = string_to_key(passcode). The K1 and K2 are then combined to form a single key K in a manner specific to the type of key being generated. For DES keys, K will be formed by XORing K1 and K2, then correcting the parity of K. If the result matches a "weak" or "semiweak" key as described in the DES specification, it is XORed with the hexadecimal constant 00000000000000F0. If the send-encrypted-passcode flag is set, the key will be derived by running the password though the string_to_key function in the normal fashion. If the use-passcode-as-key flag is set and the integrity of the PA-OT-PASSCODE-CHALLENGE PADATA field can be verified using the otpc-cksum field, then the passcode is run through the string_to_key function and the result is used as the encryption key for the request. WARNING: the use of a passcode in this manner is NOT recommended unless the range of the passcode is large enough to make an exhaustive off- line search impractical and the risks involved in the use of a passcode alone are fully considered. Also, note that without the availabilty 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-OT- PASSCODE-CHALLENGE PADATA field are based on either public key cryptography or the KDC's knowledge of the passcode Neuman & Zorn [Page 7] INTERNET-DRAFT April 12, 1995 itself. In the latter case, the client must obtain the passcode from the user and use it to verify the integrity of the challenge before the new KRB_AS_REQ message is sent. The otpc-pk-for-passcode 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 passcodes (to be defined in a separate document), the client will not be able to complete the authentication and must notify the user. The client will then send another KRB_AS_REQ message to the KDC, but with a padata field with padata-type equal to PA-OTP-RESPONSE and padata-value defined as follows: PA-OT-PASSCODE-RESPONSE ::= SEQUENCE { otpc-type[0] INTEGER, otpc-flags[1] OTPCFlags, otpc-track-id[2] GeneralString OPTIONAL, otpc-enc-nonce-or-ts[3] EncryptedData -- PA-ENC-PASSCODE-RESPONSE-ENC, otpc-nonce[4] INTEGER OPTIONAL, otpc-patimestamp[5] KerberosTime OPTIONAL } PA-ENC-PASSCODE-RESPONSE-ENC ::= SEQUENCE { otpc-nonce[0] INTEGER OPTIONAL, patimestamp[1] KerberosTime OPTIONAL, pausec[2] INTEGER OPTIONAL, otpc-passcode[3] GeneralString OPTIONAL } The source of the data included in the PA-OT-PASSCODE-RESPONSE structure depends upon whether or not a KRB_ERROR message was received by the client from the KDC. If an error reply was received, the otpc-type and otpc-flags fields will contain copies of the same fields from the error message. If the otpc-nonce field was present in the KRB_ERROR message, then the PA-ENC-PASSCODE-RESPONSE-ENC structure returned to the KDC will include that value, encrypted as described above, the otpc_nonce field in the KRB_AS_REQ message will contain a plaintext copy of the same value and the otpc-patimestamp field of the message will be empty. If a KRB_ERROR message was received but the otpc-nonce field was omitted from it, the encrypted data will contain a times- tamp encrypted in the same manner, the otpc-patimestamp field will contain an unencrypted copy of the same value, and the otpc-nonce field will be empty. In either case, if the send-encrypted- passcode flag is set in the otpc-flags field of the error message, the otpc-passcode field must contain the entered passcode. If no error reply was received (i.e., the client knows that a one- time password mechanism is to be used), the otpc-type field must be set to a value chosen from the list of registered otpc-type codes. Neuman & Zorn [Page 8] INTERNET-DRAFT April 12, 1995 The value of the otpc-flags field may vary depending upon the type of passcode in use, but in all cases the must-pk-encrypt-passcode flag must be zero. If the send-encrypted-passcode flag is set, the otpc-passcode field must contain the entered passcode. Upon receipt the KDC validates this PADATA in much the same way that it validates the PA-ENC-TS preauthentication method except that it determines the appropriate passcode and uses it (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 otpc- track-id field to encode its state, the KDC is responsible for including information in that field to detect modification or replay by an attacker. The rest of the processing of the request proceeds normally, except that instead of being encrypted in the users password, the KRB_AS_REP message is encrypted in the key obtained above. Note, however, that some one-time password 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 otpc-type value, along with appropriate prompts and/or challenges. This sequence of exchanges will continue until authentication either succeeds or fails. 5. Limitations Passcode implementations requiring the use of the send-encrypted- passcode option are discouraged as their use on the network is less secure than the case where a combination of the users password and passcode is used as the encryption key. In particular, when the send-encrypted-passcode option is used, an attacker who observes the response and is in possession of the users' encryption key (which doesn't change from login to login) can use the key to decrypt the response and obtain the passcode. If the KDC sets the must-pk-encrypt-passcode flag of the otpc-flags field but the client software being used does not support public- key cryptography, it is possible that bona-fide 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 passcode challenge and attach the appropriate checksum. This affects the security of both the send-encrypted- passcode option and the must-pk-encrypt option. 6. Expiration This Internet-Draft expires on October 12, 1995. Neuman & Zorn [Page 9] INTERNET-DRAFT April 12, 1995 7. Authors' Addresses 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 CyberSAFE Corporation 2443 152nd Avenue N.E. Redmond, WA 98052 Phone: 206-883-8721 EMail: gwz@cybersafe.com Neuman & Zorn [Page 10]