INTERNET-DRAFT Clifford Neuman
<draft-ietf-cat-kerberos-passwords-00.txt> 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
<draft-ietf-cat-kerberos-passwords-00.txt>, 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]
