+++ /dev/null
-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]
-