mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
7055827b8f
This makes it clearer that we always want to do heimdal changes via the lorikeet-heimdal repository. Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz> Autobuild-User(master): Joseph Sutton <jsutton@samba.org> Autobuild-Date(master): Wed Jan 19 21:41:59 UTC 2022 on sn-devel-184
1233 lines
43 KiB
Plaintext
1233 lines
43 KiB
Plaintext
|
||
|
||
|
||
Network Working Group G. Richards
|
||
Internet-Draft RSA, The Security Division of EMC
|
||
Intended status: Standards Track October 11, 2006
|
||
Expires: April 14, 2007
|
||
|
||
|
||
OTP Kerberos
|
||
draft-richards-otp-kerberos-01
|
||
|
||
Status of this Memo
|
||
|
||
By submitting this Internet-Draft, each author represents that any
|
||
applicable patent or other IPR claims of which he or she is aware
|
||
have been or will be disclosed, and any of which he or she becomes
|
||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||
|
||
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 documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
The list of current Internet-Drafts can be accessed at
|
||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
This Internet-Draft will expire on April 14, 2007.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
Abstract
|
||
|
||
The Kerberos protocol provides a framework authenticating a client
|
||
using the exchange of pre-authentication data. This document
|
||
describes the use of this framework to carry out One Time Password
|
||
(OTP) authentication.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 1]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 3
|
||
2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
2.3. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 4
|
||
3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 4
|
||
3.1. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 4
|
||
3.2. Client Request . . . . . . . . . . . . . . . . . . . . . . 5
|
||
3.3. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 5
|
||
3.4. Client Response . . . . . . . . . . . . . . . . . . . . . 7
|
||
3.5. Verifying the pre-auth Data . . . . . . . . . . . . . . . 7
|
||
3.6. Updating the Secret . . . . . . . . . . . . . . . . . . . 9
|
||
4. Reply Key Generation Algorithms . . . . . . . . . . . . . . . 9
|
||
4.1. Using the OTP Value Directly . . . . . . . . . . . . . . . 9
|
||
4.2. Hardening the OTP Value . . . . . . . . . . . . . . . . . 9
|
||
4.2.1. Using an Iteration Count . . . . . . . . . . . . . . . 10
|
||
4.2.2. Using a Shared Secret and OTP . . . . . . . . . . . . 10
|
||
4.2.3. Using a Password and OTP . . . . . . . . . . . . . . . 11
|
||
4.3. Generating the Key without the OTP . . . . . . . . . . . . 11
|
||
4.3.1. Using the Password . . . . . . . . . . . . . . . . . . 11
|
||
4.3.2. Using a Shared Secret . . . . . . . . . . . . . . . . 11
|
||
5. OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 12
|
||
5.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 12
|
||
5.2. PA-OTP-RESPONSE . . . . . . . . . . . . . . . . . . . . . 13
|
||
5.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 16
|
||
5.4. PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 16
|
||
5.5. OTPChalKeyParam . . . . . . . . . . . . . . . . . . . . . 17
|
||
5.6. OTPRespKeyParam . . . . . . . . . . . . . . . . . . . . . 18
|
||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
|
||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
|
||
7.1. Active attacks . . . . . . . . . . . . . . . . . . . . . . 19
|
||
7.2. Denial of service attacks . . . . . . . . . . . . . . . . 19
|
||
7.3. Use of a Shared Secret Value . . . . . . . . . . . . . . . 19
|
||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
|
||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
|
||
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
|
||
Intellectual Property and Copyright Statements . . . . . . . . . . 22
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 2]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
1. Introduction
|
||
|
||
A One-Time Password (OTP) token may be a handheld hardware device, a
|
||
hardware device connected to a personal computer through an
|
||
electronic interface such as USB or a software module resident on a
|
||
personal computer. All these devices generate one-time passwords
|
||
that may be used to authenticate a user towards some service. This
|
||
document describes extensions to Kerberos V5 [RFC4120] to support
|
||
pre-authentication using an OTP.
|
||
|
||
In this proposal, the KDC sends the client a random nonce,
|
||
information on which OTP token is to be used, how the OTP is to be
|
||
generated using that token and how the Reply Key is to be generated.
|
||
The Reply Key is then used to encrypt the nonce value and the
|
||
encrypted value is returned to the KDC as the pre-authentication
|
||
data. Depending on whether the KDC can obtain the OTP value, the OTP
|
||
value is either used in the generation of the Reply Key or is
|
||
encrypted using the key and returned to the KDC along with the
|
||
encrypted nonce. The encrypted nonce, an optional encrypted OTP
|
||
value and information on how the Reply Key and OTP value were
|
||
generated are sent to the KDC and used by the KDC to generate the
|
||
same Reply Key and decrypt and verify the nonce.
|
||
|
||
This proposal is partially based upon previous work on integrating
|
||
single-use authentication mechanisms into Kerberos [HoReNeZo04] and
|
||
uses the existing password-change extensions to handle PIN change as
|
||
described in [RFC3244].
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119].
|
||
|
||
<< This is an early draft of this document and so is liable to change
|
||
significantly. >>
|
||
|
||
|
||
2. Usage Overview
|
||
|
||
2.1. Pre-Authentication
|
||
|
||
The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
|
||
and KRB_ERROR. The client begins by sending an initial KRB_AS_REQ to
|
||
the KDC that may contain pre-authentication data such as the standard
|
||
Kerberos password data. The KDC will then determine, in an
|
||
implementation dependent fashion, whether OTP authentication is
|
||
required and if it is, it will respond with a KRB_ERROR message
|
||
containing a PA-OTP-CHALLENGE in the PA-DATA.
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 3]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
The PA-OTP-CHALLENGE contains information on how the OTP should be
|
||
generated, how the Reply Key should be generated and a nonce. The
|
||
client uses this information to locate the token and generate the
|
||
OTP, generate the Reply Key and then encrypt the nonce using the
|
||
generated key. Depending on the type of OTP, the Reply Key may be
|
||
generated using the OTP value or alternatively, the generated OTP
|
||
will instead be encrypted along with the nonce using the key.
|
||
|
||
The encrypted nonce along with information on how the OTP and Reply
|
||
Key were generated are then sent to the KDC in a PA-OTP-RESPONSE PA-
|
||
DATA element. The KDC then uses this information to generate the
|
||
same key as the client, allowing it to verify the pre-authentication
|
||
by decrypting the nonce. If the validation succeeds then the KDC
|
||
returns the TGT in a KRB_AS_REP.
|
||
|
||
2.2. PIN Change
|
||
|
||
If, following successful validation of a PA-OTP-RESPONSE in a
|
||
KRB_AS_REQ, the KDC requires that the user changes their PIN then it
|
||
will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP.
|
||
This pre-auth data can be used to return a new PIN to the user if the
|
||
KDC has updated the PIN or to indicate to the user that they must
|
||
change their PIN.
|
||
|
||
In the latter case, user PIN change shall be handled by a PIN change
|
||
service supporting the ChangePasswdData in a KRB_AP_REQ as described
|
||
in [RFC3244]. If such a user PIN change is required then the KDC
|
||
SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
|
||
only issues tickets for the PIN change service until the PIN has been
|
||
changed.
|
||
|
||
2.3. Re-Synchronization
|
||
|
||
It is possible with time and event-based tokens, that the client and
|
||
OTP server will loose synchronization. If, when processing a PA-OTP-
|
||
RESPONSE, the pre-authentication validation fails for this reason
|
||
then the KDC SHALL return a KRB_ERROR message containing a PA-OTP-
|
||
CHALLENGE in the PA-DATA with the "nextOTP" flag set. The setting of
|
||
this flag will cause the client to re-try the authentication using
|
||
the OTP for the next token "state".
|
||
|
||
|
||
3. Pre-Authentication Protocol Details
|
||
|
||
3.1. Shared Secret
|
||
|
||
The method of deriving the Reply Key shall depend upon:
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 4]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
o Whether the OTP is of sufficiently high entropy to generate the
|
||
key alone.
|
||
|
||
o Whether the OTP has insufficient entropy and so must be
|
||
strengthened.
|
||
|
||
o Whether the OTP value used can be obtained by the KDC.
|
||
|
||
If the OTP value is of low entropy then it is important to slow down
|
||
an attacker sufficiently to make it economically unattractive to
|
||
brute-force search for an OTP given an observed OTP-Kerberos
|
||
exchange. If the OTP value cannot be obtained by the KDC then it
|
||
cannot be used in the derivation of the Reply Key but shall be
|
||
encrypted using the generated key rather than used to derive the key
|
||
and so the Reply Key must be derived from some other value. Both of
|
||
these issues can be solved using shared secret value known by the
|
||
client and KDC but unknown to the attacker.
|
||
|
||
This protocol supports the following types of secret:
|
||
|
||
o A pre-shared secret can be established between the client and KDC
|
||
and stored on the client.
|
||
|
||
o Diffie-Hellman key agreement (as defined in [RFC2631]) can be used
|
||
to establish a shared secret value ZZ. The server's public key,
|
||
and the base and prime are stored on the client.
|
||
|
||
The pre-shared secret value or the Diffie-Hellman shared secret
|
||
value, ZZ, are converted to a value of the required length for the
|
||
encryption scheme's random-to-key function using the n-fold function
|
||
(both defined in [RFC3961]).
|
||
|
||
3.2. Client Request
|
||
|
||
The client begins by sending an initial KRB_AS_REQ possibly
|
||
containing other pre-authentication data. If the KDC determines that
|
||
OTP-based pre-authentication is required and the request does not
|
||
contain a PA-OTP-RESPONSE then it will respond as described in
|
||
Section 3.3.
|
||
|
||
Alternatively, if the client has all the necessary information, it
|
||
MAY construct a PA-OTP-RESPONSE as described in Section 3.4 and
|
||
include it in the initial request.
|
||
|
||
3.3. KDC Challenge
|
||
|
||
If the user is required to authenticate using an OTP then the KDC
|
||
SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing:
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 5]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
o An error code of KDC_ERR_PREAUTH_REQUIRED
|
||
|
||
o An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
|
||
|
||
The PA-OTP-CHALLENGE SHALL contain a nonce value to be encrypted by
|
||
the generated Reply Key and it MAY also contain information on how
|
||
the OTP value is to be generated and information on how the Reply Key
|
||
is to be generated in an otp-keyParam element.
|
||
|
||
Use of the otp-keyParam element is OPTIONAL. If it is not present
|
||
the Reply Key SHALL be generated directly from the OTP value as
|
||
specified in Section 4.1 and the OTP value SHALL NOT be included in
|
||
the client response.
|
||
|
||
If the otp-keyParam element is present and the "sendOTP" flag is set
|
||
then the OTP value MUST NOT be used in the generation of the Reply
|
||
Key but it must instead be returned to the KDC encrypted using the
|
||
key. The Reply Key MUST be derived using one of the methods
|
||
described in Section 4.3. If the "sendOTP" flag is not set then the
|
||
OTP value is to be used in the key derivation then the client MUST
|
||
use one of the methods described in Section 4.2.
|
||
|
||
The otp-keyParam element will control the use of a shared secret in
|
||
the key derivation. If the "noSecret" flag is set the the client
|
||
MUST NOT use a secret value in the key derivation. If the "noSecret"
|
||
flag is not set and secret identifier is present then the client MUST
|
||
NOT use any other secret value. If the "noSecret" flag is not set
|
||
and a secret identifier is not present then the client MAY still use
|
||
a value if there is a value associated with the KDC.
|
||
|
||
If the "noSecret" flag is not set and the client can locate a secret
|
||
value for the KDC then the Reply Key will be generated using one of
|
||
the following methods:
|
||
|
||
o If the OTP is to be included in the key derivation then the key
|
||
SHALL be derived as specified in Section 4.2.2.
|
||
|
||
o If the OTP is to be sent encrypted in the response then the key
|
||
SHALL be derived as specified in Section 4.3.2.
|
||
|
||
If the client fails to find a shared secret for the KDC or the
|
||
"noSecret" flag was set in the challenge then the Reply Key will be
|
||
generated using one of the following methods:
|
||
|
||
o If the OTP is to be used in the key derivation then the KDC MAY
|
||
specify an iteration count. If such a value is specified then the
|
||
key SHALL be derived from the OTP as described in Section 4.2.1.
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 6]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
o If the OTP is to be used in the key derivation but an iteration
|
||
count was not specified then the key SHALL be derived from the OTP
|
||
value and the user's Kerberos password as described in
|
||
Section 4.2.3.
|
||
|
||
o If the OTP is to be sent encrypted then the key SHALL be derived
|
||
from the user's Kerberos password as described in section
|
||
Section 4.3.1.
|
||
|
||
3.4. Client Response
|
||
|
||
The client will use the generated Reply Key to encrypt the nonce from
|
||
the KDC challenge and, if required, to encrypt the OTP value. This
|
||
encrypted data SHALL be sent to the KDC in the otp-encData of a PA-
|
||
OTP-RESPONSE PA-DATA element included in a KRB_AS_REQ.
|
||
|
||
This response MAY also include information on how the Reply Key was
|
||
generated in an optional otp-keyParam element. The client MUST NOT
|
||
include this element if the Reply Key was generated directly from the
|
||
OTP value. The element MUST be included if the Reply Key was
|
||
generated using either a secret value or an iteration count and
|
||
contain the secret identifier and iteration count value. If the
|
||
Reply Key was generated using a password then the element MUST be
|
||
present and MUST be empty.
|
||
|
||
The response SHOULD also include information on the generated OTP
|
||
value.
|
||
|
||
3.5. Verifying the pre-auth Data
|
||
|
||
If KRB_AS_REQ contains a PA-OTP-RESPONSE then the KDC will then use
|
||
the information in the otp-keyParam to generate the same Reply Key
|
||
and decrypt the encrypted nonce contained in the otp-encData.
|
||
|
||
If the encrypted OTP value is not included in the otp-encData then
|
||
the Reply Key was generated using the OTP value. The KDC SHALL
|
||
therefore use the OTP information in the PA-OTP-RESPONSE to obtain
|
||
the OTP value for the user and use the value along with the
|
||
information in the otp-keyParam to generate the Reply Key. This
|
||
information SHALL be used as follows:
|
||
|
||
o If the otp-keyParam is not present then the Reply Key SHALL be
|
||
generated directly from the OTP value as described in Section 4.1.
|
||
|
||
o If the otp-keyParam is present but empty then the Reply Key SHALL
|
||
be generated using the OTP value and the user's Kerberos Password
|
||
as described in Section 4.2.3.
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 7]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
o If the otp-keyParam is present and contains a secret identifier
|
||
then the Reply Key SHALL be generated using the OTP value and the
|
||
secret value as described in Section 4.2.2.
|
||
|
||
If the identified secret value can not be found then the KDC SHALL
|
||
respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
|
||
but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
|
||
|
||
o if the otp-keyParam is present and contains an iteration count
|
||
then the Reply Key shall be generated from the OTP value using the
|
||
iteration count value as described in Section 4.2.1.
|
||
|
||
If the encrypted OTP value is included in the otp-encData then the
|
||
Reply Key was not generated using the OTP value but was instead used
|
||
to encrypt the OTP value. The KDC SHALL therefore use the
|
||
information in the otp-keyParam to generate the Reply Key and decrypt
|
||
the OTP value. It SHALL then validate the decrypted value using the
|
||
OTP information included in the response and fail the authentication
|
||
if the value is not valid.
|
||
|
||
This Reply Key SHALL be generated as follows:
|
||
|
||
o If the otp-keyParam is not present the the KDC SHALL fail the pre-
|
||
authentication with an error of KDC_ERR_PREAUTH_FAILED.
|
||
|
||
If the otp-keyParam is omitted then the Reply Key was generated
|
||
directly from the OTP value and so is an error if the OTP value is
|
||
encrypted using the key.
|
||
|
||
o If the otp-keyParam is present but empty then the Reply Key SHALL
|
||
be generated using the user's Kerberos Password as described in
|
||
Section 4.3.1.
|
||
|
||
o If the otp-keyParam is present and contains a secret identifier
|
||
then the Reply Key SHALL be generated using the secret value as
|
||
described in Section 4.3.2.
|
||
|
||
If the identified secret value can not be found then the KDC SHALL
|
||
respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
|
||
but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
|
||
|
||
o If the otp-keyParam is present and contains an iteration count
|
||
then the KDC SHALL fail the authentication with an error of
|
||
KDC_ERR_PREAUTH_FAILED.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 8]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
3.6. Updating the Secret
|
||
|
||
The secret value can be pre-configured on the client but MAY also be
|
||
transferred from the KDC to the client in encrypted form in the PA-
|
||
OTP-CONFIRM of the KRB_AS_REP. If a client receives a new secret
|
||
value in this way then it MUST update any stored value associated
|
||
with the KDC.
|
||
|
||
|
||
4. Reply Key Generation Algorithms
|
||
|
||
4.1. Using the OTP Value Directly
|
||
|
||
If only the OTP value is to be used then the Reply Key SHALL be
|
||
generated by passing the OTP value through string-to-key (defined in
|
||
[RFC3961]).
|
||
|
||
K = string-to-key(OTP)
|
||
|
||
The salt and additional parameters for string-to-key will be as
|
||
defined in section 3.1.3 of [RFC4120].
|
||
|
||
4.2. Hardening the OTP Value
|
||
|
||
If the OTP value requires strengthening then several methods shall be
|
||
supported.
|
||
|
||
o The OTP can be used on its own in the key derivation but run
|
||
through an iteration process many times as described in
|
||
Section 4.2.1.
|
||
|
||
o A secret value, shared between the KDC and client can be used
|
||
along with the OTP value to derive the key as described in
|
||
Section 4.2.2.
|
||
|
||
o The user's Kerberos password can be used along with the OTP value
|
||
in the key derivation as described in Section 4.2.3.
|
||
|
||
A shared secret can only be used if the client supports the storing
|
||
of persistent values and has such a value stored. The other two
|
||
methods could be used to establish a secret value or when client are
|
||
not capable of storing such values.
|
||
|
||
<<Is there value in another mode which uses the Kerberos password in
|
||
conjunction with an iteration-hardened OTP value?>>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 9]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
4.2.1. Using an Iteration Count
|
||
|
||
An initial key is generated by running the OTP value through string-
|
||
to-key.
|
||
|
||
K = string-to-key(OTP)
|
||
|
||
The following key generation process is then repeated iteration count
|
||
times with the resulting key being used as the protocol key for the
|
||
next iteration.
|
||
|
||
A sequence of octets, R, is produced from K by iterating over calls
|
||
to the function pseudo-random (defined in [RFC3961]) and appending
|
||
the results until at least the number of bits required by random-to-
|
||
key have been produced. If the result of the iteration is longer
|
||
than the required length then the result shall be truncated.
|
||
|
||
The octet string parameter for pseudo-random shall be the ASCII
|
||
string "CombineA" with the loop number appended. This string has the
|
||
following byte value:
|
||
|
||
{0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
|
||
|
||
A new key is then generated by running R through random-to-key.
|
||
|
||
K = random-to-key(R)
|
||
|
||
4.2.2. Using a Shared Secret and OTP
|
||
|
||
Two intermediate keys, K1 and K2, shall be generated by running the
|
||
OTP value once through string-to-key and the shared secret through
|
||
random-to-key.
|
||
|
||
K1 = random-to-key(shared secret)
|
||
K2 = string-to-key(OTP)
|
||
|
||
Two sequences of octets, R1 and R2, are then produced from K1 and K2
|
||
by iterating over calls to pseudo-random and appending the results
|
||
until the required number of bits have been generated for random-to-
|
||
key. If the result of the iteration is longer than the required
|
||
length then the result shall be truncated.
|
||
|
||
The octet string parameter for pseudo-random shall be the ASCII
|
||
string "CombineA" for K1 and "CombineB" for K2 with the loop number
|
||
appended. These have the following byte values:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 10]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
{0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
|
||
{0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x42}
|
||
|
||
The final key is then generated by combining R1 and R2 using
|
||
exclusive-OR and running the result through random-to-key.
|
||
|
||
K = random-to-key(R1 ^ R2)
|
||
|
||
<< Check on issue around combining DES keys. >>
|
||
|
||
4.2.3. Using a Password and OTP
|
||
|
||
Two intermediate keys, K1 and K2, shall be generated by running the
|
||
OTP and password through string-to-key.
|
||
|
||
K1 = string-to-key(Password)
|
||
K2 = string-to-key(OTP)
|
||
|
||
The same process as described in Section 4.2.2 is then used to derive
|
||
the final reply key.
|
||
|
||
4.3. Generating the Key without the OTP
|
||
|
||
If the OTP value cannot be used in the derivation of the reply key
|
||
then this protocol supports the following options:
|
||
|
||
o A secret value, shared between the KDC and client can be used to
|
||
derive the key as described in Section 4.3.2.
|
||
|
||
o The user's Kerberos password can be used in the key derivation as
|
||
described in Section 4.3.1.
|
||
|
||
A shared secret can only be used if the client supports the storing
|
||
of persistent values and has such a value stored. The password-only
|
||
method could be used to establish a secret value or when clients are
|
||
not capable of storing such values.
|
||
|
||
4.3.1. Using the Password
|
||
|
||
The Reply Key SHALL be generated by passing the password value
|
||
through string-to-key (defined in [RFC3961]).
|
||
|
||
4.3.2. Using a Shared Secret
|
||
|
||
The reply key shall be generated by running the shared secret value
|
||
through random-to-key.
|
||
|
||
K = random-to-key(shared secret)
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 11]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
5. OTP Kerberos Types
|
||
|
||
5.1. PA-OTP-CHALLENGE
|
||
|
||
This is a pre-authentication type sent by the KDC to the client in a
|
||
KRB_ERROR. It contains information for the client on how to generate
|
||
the OTP and reply key.
|
||
|
||
PA-OTP-CHALLENGE ::= SEQUENCE {
|
||
otp-flags OTPFlags,
|
||
otp-nonce UInt32,
|
||
otp-etype INTEGER,
|
||
otp-track-id [0] OCTET STRING OPTIONAL,
|
||
otp-challenge [1] OCTET STRING OPTIONAL,
|
||
otp-length [2] INTEGER OPTIONAL,
|
||
otp-service [3] UTF8String OPTIONAL,
|
||
otp-keyID [4] OCTET STRING OPTIONAL,
|
||
otp-algID [5] INTEGER OPTIONAL,
|
||
otp-keyParam [6] OTPChalKeyParam OPTIONAL
|
||
}
|
||
|
||
OTPFlags ::= KerberosFlags
|
||
-- nextOTP (0)
|
||
|
||
otp-flags
|
||
If the "nextOTP" flag is set then the OTP calculated SHALL be
|
||
based on the next token "state" rather than the current one. As
|
||
an example, for a time-based token, this means the next time slot.
|
||
For an event-based token, this could mean the next counter value,
|
||
if counter values are used.
|
||
|
||
otp-nonce
|
||
A KDC-supplied nonce value to be encrypted by the client in the
|
||
PA-OTP-RESPONSE.
|
||
|
||
otp-etype
|
||
The encryption type to be used by the client for all encrypted
|
||
fields in the PA-OTP-RESPONSE.
|
||
|
||
otp-track-id
|
||
This optional element is used by the KDC to link a client response
|
||
to the corresponding KDC challenge. If present, this element MUST
|
||
be copied by the client to the corresponding element in the PA-
|
||
OTP-RESPONSE.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 12]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
otp-challenge
|
||
The otp-challenge is used by the KDC to send a challenge value for
|
||
use in the OTP calculation. The challenge is an optional octet
|
||
string that SHOULD be uniquely generated for each request it is
|
||
present in, and SHOULD be eight octets or longer when present.
|
||
When the challenge is not present, the OTP will be calculated on
|
||
the current token state only. The client MAY ignore a provided
|
||
challenge if and only if the OTP token the client is interacting
|
||
with is not capable of including a challenge in the OTP
|
||
calculation. In this case, KDC policies will determine whether to
|
||
accept a provided OTP value or not.
|
||
|
||
otp-length
|
||
The otp-length is used by the KDC to specify the desired length of
|
||
the generated OTP.
|
||
|
||
otp-service
|
||
An identifier of the service supported by the KDC. This value can
|
||
be used by the client to locate information such as the shared
|
||
secret value and OTP key to use.
|
||
|
||
otp-keyID
|
||
The identifier of the OTP key to be used in the OTP calculation.
|
||
If this value is not present then the client SHOULD use other
|
||
values such as the otp-service and otp-algID to locate the
|
||
appropriate key.
|
||
|
||
otp-algID
|
||
The identifier of the algorithm to use when generating the OTP.
|
||
|
||
otp-keyParam
|
||
Information on how the Reply Key should be generated from the OTP
|
||
and shared secret. If the value is not present then the reply key
|
||
MUST be generated directly from the OTP value.
|
||
|
||
<<TBD: Should a checksum be added to allow the client to verify the
|
||
challenge?>>
|
||
|
||
5.2. PA-OTP-RESPONSE
|
||
|
||
This is a pre-authentication type sent by the client to the KDC in a
|
||
KRB_AS_REQ containing the encrypted pre-authentication data. It
|
||
contains information on the OTP used and how the key was generated
|
||
that encrypts the pre-authentication data. This information will
|
||
then allow the KDC to generate the same key and validate the pre-
|
||
authentication data.
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 13]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
PA-OTP-RESPONSE ::= SEQUENCE {
|
||
otp-flags OTPFlags,
|
||
otp-nonce UInt32,
|
||
otp-encData EncryptedData,
|
||
-- PA-ENC-RESPONSE
|
||
-- Key usage of <<TBD>>
|
||
otp-track-id [0] OCTET STRING OPTIONAL,
|
||
otp-challenge [1] OCTET STRING OPTIONAL,
|
||
otp-time [2] KerberosTime OPTIONAL,
|
||
otp-counter [3] OCTET STRING OPTIONAL,
|
||
otp-format [4] OTPFormat OPTIONAL,
|
||
otp-keyID [5] OCTET STRING OPTIONAL,
|
||
otp-keyParam [6] OTPRespKeyParam OPTIONAL
|
||
}
|
||
|
||
|
||
|
||
OTPFormat ::= INTEGER {
|
||
decimal(0),
|
||
hexadecimal(1),
|
||
alphanumeric(2),
|
||
binary(3)
|
||
}
|
||
|
||
|
||
|
||
PA-ENC-RESPONSE ::= SEQUENCE {
|
||
nonce OCTET STRING OPTIONAL,
|
||
otp [0] OCTET STRING OPTIONAL
|
||
}
|
||
|
||
otp-flags
|
||
If the "nextOTP" flag is set then the OTP was calculated based on
|
||
the next token "state" rather than the current one. This flag
|
||
MUST be set if and only if it was set in a corresponding PA-OTP-
|
||
CHALLENGE.
|
||
|
||
otp-nonce
|
||
The nonce value encrypted in the otp-encData. If the PA-OTP-
|
||
RESPONSE is sent as a result of a PA-OTP_CHALLENGE then the value
|
||
MUST be a copy of the corresponding value in the challenge. If no
|
||
challenge was received then the nonce value MUST be generated by
|
||
the client.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 14]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
otp-track-id
|
||
This element MUST be included if and only if an otp-track-id was
|
||
included in the corresponding PA-OTP-CHALLENGE. If included, then
|
||
the value MUST be copied from the PA-OTP-CHALLENGE.
|
||
|
||
otp-challenge
|
||
Value used by the client to send the challenge used in the OTP
|
||
calculation. It MUST be sent to the KDC if and only if the value
|
||
would otherwise be unknown to the KDC. For example, the token or
|
||
client modified or generated challenge.
|
||
|
||
otp-time
|
||
Value used by the client to send the time used in the OTP
|
||
calculation.
|
||
|
||
otp-counter
|
||
The counter value used in the OTP calculation. Use of this
|
||
element is OPTIONAL but it MAY be used by a client to simplify the
|
||
OTP calculations of the KDC to contain the counter value as
|
||
reported by the OTP token.
|
||
|
||
otp-format
|
||
The format of the generated OTP.
|
||
|
||
otp-keyID
|
||
The identifier of the OTP key used.
|
||
|
||
otp-keyParam
|
||
Information on how the reply key was generated from the OTP and
|
||
shared secret. If the value is not present then the reply key was
|
||
generated directly from the OTP value.
|
||
|
||
otp-encData
|
||
The otp-encData field contains the result of the pre-
|
||
authentication process and is encrypted using the generated Reply
|
||
Key. The fields of this element are populated as follows:
|
||
|
||
nonce
|
||
The value of otp-nonce.
|
||
|
||
otp
|
||
The generated OTP value. Present if the "sendOTP" flag is set
|
||
in the challenge.
|
||
|
||
<<TBD: Does the response need something such as an encrypted
|
||
timestamp to protect against replay?>>
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 15]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
5.3. PA-OTP-CONFIRM
|
||
|
||
This is a pre-authentication type returned by the KDC in a KRB_AS_REP
|
||
if the client requires a new shared secret value. The value is
|
||
encrypted as described in section 5.2.9 of [RFC4120] using the
|
||
current reply key as derived by the KDC from the OTP.
|
||
|
||
PA-OTP-CONFIRM ::= SEQUENCE {
|
||
identifier OCTET STRING,
|
||
newSecretValue EncryptedData -- OTPNewSecret
|
||
-- Key usage of <<TBD>>
|
||
}
|
||
|
||
OTPNewSecret ::= CHOICE {
|
||
sharedSecret [0] OCTET STRING,
|
||
dhParams [1] DHParam
|
||
}
|
||
|
||
DHParam ::= SEQUENCE {
|
||
dhParameter DHParameter,
|
||
dhPublic INTEGER
|
||
}
|
||
|
||
identifier
|
||
An octet string identifying the new secret value.
|
||
|
||
newSecretValue
|
||
The new secret data encrypted using the current Reply Key. The
|
||
encrypted data can be of one of the following types:
|
||
|
||
sharedSecret
|
||
A random bit string.
|
||
|
||
dhParams
|
||
A Diffie-Hellman public value, prime and modulus.
|
||
|
||
5.4. PA-ENC-PIN
|
||
|
||
Pre-authentication type returned by the KDC in a KRB_AS_REP if the
|
||
user must change their PIN or if the user's PIN has been changed.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 16]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
PA-ENC-PIN ::= EncryptedData -- PA-ENC-PIN-ENC
|
||
-- Key usage of <<TBD>>
|
||
PA-ENC-PIN-ENC ::= SEQUENCE {
|
||
flags PinFlags,
|
||
pin [0] UTF8String OPTIONAL,
|
||
minLength [1] INTEGER OPTIONAL,
|
||
maxLength [2] INTEGER OPTIONAL
|
||
}
|
||
|
||
PinFlags ::= KerberosFlags
|
||
-- systemSetPin (0)
|
||
|
||
If the "systemSetPin" flag is set then the user's PIN has been
|
||
changed and the new PIN value is contained in the pin field. The PIN
|
||
field MUST therefore be present.
|
||
|
||
If the "systemSetPin" flag is not set then the user's PIN has not
|
||
been changed by the server but it MUST instead be changed by the user
|
||
using the PIN change service. Restrictions on the size of the PIN
|
||
MAY be given by the minLength and maxLength fields. If the pin field
|
||
is present then it contains a PIN value that MAY be used by the user
|
||
when changing the PIN. The KDC MAY only issue tickets for the PIN
|
||
change service until the PIN has been changed.
|
||
|
||
5.5. OTPChalKeyParam
|
||
|
||
This data type can optionally be included by the KDC in a PA-OTP-
|
||
CHALLENGE to instruct the client on how to generate the reply key.
|
||
|
||
This value is included in the challenge if the OTP generated by the
|
||
token is too weak to be used alone in the generation of the key.
|
||
|
||
OTPChalKeyParam ::= SEQUENCE {
|
||
flags ChallengeFlags,
|
||
identifer [0] OCTET STRING OPTIONAL,
|
||
iterationCount [1] INTEGER OPTIONAL
|
||
}
|
||
|
||
ChallengeFlags ::= KerberosFlags
|
||
-- sendOTP (0)
|
||
-- noSecret (1)
|
||
|
||
flags
|
||
Flags controlling the generation of the Reply Key.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 17]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
sendOTP
|
||
If the "sendOTP" flag is set then the client MUST NOT use the
|
||
OTP value to generate the reply key. It must instead use the
|
||
generated key to encrypt the OTP value and include the
|
||
encrypted value in the PA-OTP-RESPONSE.
|
||
|
||
noSecret
|
||
If the "noSecret" flag is set then the client MUST NOT use any
|
||
stored secret value in the derivation of the Reply Key. If the
|
||
"sendOTP" flag is also set then the Kerberos password MUST be
|
||
used. If the "sendOTP" flag is not set then the iteration
|
||
count MUST be used if it is present or the Kerberos password
|
||
MUST be used if the iteration count is not specified.
|
||
|
||
identifier
|
||
Name of the secret that the client SHOULD use to generate the
|
||
reply key.
|
||
|
||
If a secret is specified but cannot be located by the client and
|
||
an iteration count is specified then the client should generate
|
||
the key using the iteration count. If a secret value is specified
|
||
and cannot be located and an iteration count is not specified then
|
||
the reply key MUST be generated using the user's Kerberos
|
||
password.
|
||
|
||
iterationCount
|
||
This value contains the iteration count to use when the generated
|
||
OTP value is used in the derivation of the reply key. This value
|
||
is used by the client if a shared secret is not specified or is
|
||
specified but cannot be found. The value has no meaning if the
|
||
"sendOTP" flag is set.
|
||
|
||
5.6. OTPRespKeyParam
|
||
|
||
This data type can optionally be included by the client in a PA-OTP-
|
||
RESPONSE to inform the KDC of how the reply key was generated.
|
||
|
||
OTPRespKeyParam ::= SEQUENCE {
|
||
iterationCount [0] INTEGER OPTIONAL,
|
||
secret SEQUENCE {
|
||
identifier OCTET STRING,
|
||
dhPublic [1] INTEGER OPTIONAL
|
||
}
|
||
}
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 18]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
iterationCount
|
||
The actual value of the iteration count used by the client in the
|
||
key derivation. If omitted then no iteration was used in the
|
||
derivation of the reply key.
|
||
|
||
secret
|
||
Information on the secret used in the key derivation. If this
|
||
value is omitted then no shared secret was used.
|
||
|
||
identifier
|
||
An octet string identifying the shared secret value used by the
|
||
client in the key derivation.
|
||
dhPublic
|
||
The client's Diffie-Hellman public key. Present only if a
|
||
Diffie-Hellman secret was used.
|
||
|
||
|
||
6. IANA Considerations
|
||
|
||
A registry may be required for the otp-AlgID values as introduced in
|
||
Section 5.1. No other IANA actions are anticipated.
|
||
|
||
|
||
7. Security Considerations
|
||
|
||
7.1. Active attacks
|
||
|
||
<<TBS >>
|
||
|
||
7.2. Denial of service attacks
|
||
|
||
An active attacker may replace the iteration count value in the PA-
|
||
OTP-RESPONSE sent by the client to slow down an authentication
|
||
server. Authentication servers SHOULD protect against this, e.g. by
|
||
disregarding PA-OTP-RESPONSE elements with an iteration count value
|
||
higher than some pre- or dynamically- (depending on load) set number.
|
||
|
||
7.3. Use of a Shared Secret Value
|
||
|
||
As described in Section 3.1, the use of a shared secret value will
|
||
slow down an attacker's search for a matching OTP. The ability to
|
||
transfer such a value in encrypted form from the KDC to the client
|
||
means that, even though there may be an initial computational cost
|
||
for the KDC to authenticate the user if an iteration count is used,
|
||
subsequent authentications will be efficient, while at the same time
|
||
more secure, since a pre-shared, value will not be easily found by an
|
||
attacker.
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 19]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
If a client does not have a pre-configured secret value for a KDC
|
||
then it will have to generate the Reply Key using an iteration count
|
||
or the Kerberos password. If an iteration count is used then an
|
||
attacker observing such a KRB_AS_REQ may, depending on available
|
||
resources, be able to successfully attack that request. Once the
|
||
correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM
|
||
will potentially give the attacker access to the server-provided
|
||
secret value. For this reason, initial exchanges with KDC servers
|
||
SHOULD occur in a secure environment and the lifetime of this value
|
||
must also be calculated with this in mind. Finally, the value MUST
|
||
be securely stored by the client and the KDC, associated with the
|
||
user.
|
||
|
||
|
||
8. References
|
||
|
||
8.1. Normative References
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
|
||
RFC 2631, June 1999.
|
||
|
||
[RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
|
||
2000 Kerberos Change Password and Set Password Protocols",
|
||
RFC 3244, February 2002.
|
||
|
||
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
|
||
Kerberos 5", RFC 3961, February 2005.
|
||
|
||
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
||
Kerberos Network Authentication Service (V5)", RFC 4120,
|
||
July 2005.
|
||
|
||
8.2. Informative References
|
||
|
||
[HoReNeZo04]
|
||
Horstein, K., Renard, K., Neuman, C., and G. Zorn,
|
||
"Integrating Single-use Authentication Mechanisms with
|
||
Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
|
||
progress), July 2004.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 20]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
Author's Address
|
||
|
||
Gareth Richards
|
||
RSA, The Security Division of EMC
|
||
RSA House
|
||
Western Road
|
||
Bracknell, Berkshire RG12 1RT
|
||
UK
|
||
|
||
Email: grichards@rsa.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 21]
|
||
|
||
Internet-Draft OTP Kerberos October 2006
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
Acknowledgment
|
||
|
||
Funding for the RFC Editor function is provided by the IETF
|
||
Administrative Support Activity (IASA).
|
||
|
||
|
||
|
||
|
||
|
||
Richards Expires April 14, 2007 [Page 22]
|
||
|