INTERNET-DRAFT Clifford Neuman ISI Updates: RFC 1510 Glen Zorn November 28, 1994 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 June 3, 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 November 28, 1994 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 Activity 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 with it. Several currently available implemen- tations 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 represents an attempt 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 some 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. Note, however, that the KDC is not required to know which mode the client is using, nor is the client required to support both modes: if the client supports just the challenge/response model, the protocol will still work (at the expense of one extra exchange of messages with the KDC). 3.1 Challenge/Response Model The client begins with an initial KRB_AS_REQ message to the KDC, using whatever form of preauthentication is common (none, PA_ENC_TIMESTAMP (encrypted timestamp), PA_OSF_DCE (DCE), etc.). Depending on the type of preauthentication used, the user may or may not be prompted at this time for her Kerberos password. If (for example) encrypted timestamp preauthentication is used, then the user will be prompted; on the other hand, if no Neuman & Zorn [Page 2] INTERNET-DRAFT November 28, 1994 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 that if a passcode is required, then the password by itself is not sufficient for authentication. If the client is required to present a one time passcode, 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 contain- ing 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-TO-PRIMARY, the client should re-execute the authentica- tion protocol from the beginning, directing messages to the primary KDC for the realm. This is done to allow some methods to require that a single KDC be used for passcode authentication if tight syn- chronization is needed between all replicas, and the KDC database propogation code does not provide such synchronization. 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; otherwise, the KDC will respond as specified by RFC 1510. 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 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 other than to know whether it requires a challenge. This means that a client supporting one-time passwords will be able to work with new methods without modifica- tion. If a KRB_ERROR message was received from the KDC indicating that a passcode is required, that message includes in its e-data field a PA-DATA structure that encodes information about the passcode that is needed. This includes whether a challenge is required, if so, what the challenge is, and informational data 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 Neuman & Zorn [Page 3] INTERNET-DRAFT November 28, 1994 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 INTEGER, otpc-flags OTPCFlags, otpc-type-name GeneralString OPTIONAL, otpc-track-id GeneralString OPTIONAL, otpc-challenge-label GeneralString OPTIONAL, otpc-challenge GeneralString OPTIONAL, otpc-response-prompt GeneralString OPTIONAL, otpc-pk-for-passcode EncryptionKey OPTIONAL, otpc-nonce INTEGER OPTIONAL, otpc-cksum 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. The values that are presently defined 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_ENIGMA, PA_OTPC_TYPE_DIGI_PATH and PA_OTPC_TYPE_SECURID are popular token cards. [NOTE: It will probably be necessary to fine-tune this list, since some vendors offer more than one type of device, each of which may require a different algorithm for verification.] 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 the correct passcode. [NOTE: Using PA_OTPC_TYPE_SKEY_K0 gives up one advantage of S/Key, e.g., that the information needed to generate the key 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 this S/Key variant Neuman & Zorn [Page 4] INTERNET-DRAFT November 28, 1994 is that security of the network protocol is stronger since the passcode is known by the KDC and can be used as part of the encyp- tion key, rather than being sent protected by an encryption key that has been subject to possible prior exposure to an attacker (see the limitations section). In any case, there seems to be a definite advantage to being interoperable with the S/Key algo- rithm.] 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. 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). If must-pk-encrypt-passcode is set, then the passcode must additionally be encrypted in the public key returned by the KDC in the otpc-pk-for-passcode field. 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 specified, a crypyographic 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. [NOTE: The flags (and their interpretations) provide generality, but complicate things considerably. Should some be dropped in the interest of simplicity?] 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. 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; however, it should not be used if the otpc-checksum field is empty, since in that case it may have been modified by an adversary. 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 Neuman & Zorn [Page 5] INTERNET-DRAFT November 28, 1994 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 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. Otherwise the prompt displayed will be hardcoded into the application, such as Passcode: [NOTE: Are the otpc-challenge-label and otpc-response-prompt fields useful if the KRB_ERROR message isn't integrity-protected?] otpc-pk-for-passcode is an optional field containing a public key generated by the KDC and returned to the client for use in encrypt- ing the passcode before returning it to the server. This addi- tional encryption is intended for use with passcode mechanisms in which the passcode is not known by the KDC. Its purpose is to prevent an attacker who has already obtained the users password from also obtaining the passcode, which might otherwise be possible by eavesdropping on the exchange (if the passcode had been encrypted solely in the user's password). If this field is present, its integrity must be assured by a checksum. [NOTE: The otpc-pk-for-passcode field and its use are not fully specified. This is basically a placeholder for future use.] 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. This field should always be present if the initial KRB_AS_REQ message included a type of cryptographic Neuman & Zorn [Page 6] INTERNET-DRAFT November 28, 1994 preauthentication (such as PA_ENC_TIMESTAMP). If the intial mes- sage 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 verified by the client, then an attacker can change the message contents at will. Such a change could cause unexpected instructions to be displayed to the user in the prompt string, or allow the denial of service through the proffering of an invalid challenge. 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: 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 available material which enables an offline guessing attack against the key. Is this acceptable? Should the use of the otpc-cksum field be allowed or prohibited in the absence of cryptographic preauthentication? Should it be left as a matter of realm policy? Feedback is encouraged.] 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 passcode and possi- bly 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 runnning each through the string_to_key function (see RFC 1510, Section 6.3.4) separately, then XORing the results. 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 itself. In the latter case, the client must obtain the passcode from the user and use it to verify the integrity Neuman & Zorn [Page 7] INTERNET-DRAFT November 28, 1994 of the challenge before the new KRB_AS_REQ message is sent. If the otpc-pk-for-passcode field is not empty, the client sup- ports public key cryptography, and the integrity of the PA-OT- PASSCODE-CHALLENGE PADATA field can be verified, then the response will be encrypted twice: first, in the key from the otpc-pk-for-passcode field; and next, in the conventional key obtained in the manner described above. 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 INTEGER, otpc-track-id GeneralString OPTIONAL, otpc-enc-nonce-or-ts EncryptedData -- PA-ENC-PASSCODE-RESPONSE-ENC, otpc-nonce INTEGER OPTIONAL otpc-patimestamp KerberosTime OPTIONAL } PA-ENC-PASSCODE-RESPONSE-ENC ::= CHOICE { otpc-nonce INTEGER, SEQUENCE { patimestamp KerberosTime, pausec INTEGER } } The source of the data included in the PA-OT-PASSCODE-RESPONSE struc- ture 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 field will contain a copy of the otpc-type field 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 either no KRB_ERROR message was received or the otpc-nonce field was omitted from it, the encrypted data will contain a timestamp 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. 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 conjunc- tion 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 prevent modification or replay by an attacker. Neuman & Zorn [Page 8] INTERNET-DRAFT November 28, 1994 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. 5. Limitations If the passcode implementation on the KDC results in the sending of PA-OT-PASSCODE-REDIRECT-TO-PRIMARY, the availability of the KDC for clients using such a passcode is limited to the availablility of the single primary KDC, and the benefits of replication of the KDC are lost. 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 do decrypt the response and obtain the passcode. It also appears to be the case that an attacker in possession of the users encryption key (again, which doesn't change from login to login) would 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. We would like input on whether these options should be dropped entirely, whether there is sufficient need or potential need to integrate such forms of passcodes that we leave it but with a warn- ing, or whether there are better options for integrity protecting the challenge (e.g. eventually a digital signature generated using the KDC's RSA private key, but that introduces the problem of the certification of the KDC's public key). 6. Expiration This Internet-Draft expires on June 3, 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 Neuman & Zorn [Page 9] INTERNET-DRAFT November 28, 1994 2443 152nd Avenue N.E. Redmond, WA 98052 Phone: 206-883-8721 EMail: gwz@cybersafe.com Neuman & Zorn [Page 10]