oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

x

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@17825 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2006-07-10 17:03:52 +00:00
parent ecd86630af
commit c2de386016
1 changed files with 728 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

728
doc/standardisation/draft-richards-otp-kerberos-00.txt Normal file
View File

@@ -0,0 +1,728 @@
Network Working Group G. Richards
Internet-Draft RSA Security UK Ltd.
Expires: December 4, 2006 June 2, 2006
OTP Kerberos
draft-richards-otp-kerberos-00
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 December 4, 2006.
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 December 4, 2006 [Page 1]
Internet-Draft OTP Kerberos June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 3
2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. OTP Hardening . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 5
3. OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 6
3.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 6
3.2. PA-OTP-RESPONSE . . . . . . . . . . . . . . . . . . . . . 7
3.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 8
3.4. PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Active attacks . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Denial of service attacks . . . . . . . . . . . . . . . . 9
5.3. Use of Hardening Value . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Richards Expires December 4, 2006 [Page 2]
Internet-Draft OTP Kerberos June 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, which generates one-time passwords that may be
used to authenticate a user towards some service. This document
describes an extensions to Kerberos V5 [RFC4120] to support pre-
authentication using a OTPs.
In this proposal, the KDC sends the client information on which token
to be used and how the OTP is to be generated. The client then uses
the OTP value instead of the conventional password to generate the
timestamp encryption key and sends the encrypted timestamp along with
information on the OTP to the KDC in in pre-authentication data of a
KRB_AS_REQ. The KDC then uses the OTP information provided by the
client to generate the same encryption key, allowing it to verify the
timestamp.
This proposal is partially based upon previous work on integrating
single-use authentication mechanisms into Kerberos [NeZoHo98] 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 the first 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 possibly containing 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 with:
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 contains information on the type of OTP required
and the token to be used to generate it. The client uses this
Richards Expires December 4, 2006 [Page 3]
Internet-Draft OTP Kerberos June 2006
information to locate the token and generate the OTP which is used,
instead of the user's password, to generate an encryption key and
encrypt a timestamp.
The encrypted timestamp is then sent to the KDC as pre-auth data in a
second KRB_AS_REQ in the standard manner but additional information
on the OTP and the key derivation is also sent in a PA-OTP-RESPONSE.
The KDC then uses the information in the PA-OTP-RESPONSE to generate
the same key as the client allowing it to validate the encrypted
timestamp. 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. OTP Hardening
Since OTPs may be relatively short, it is important to slow down an
attacker sufficiently so that it is economically unattractive to
brute-force search for an OTP given an observed OTP-Kerberos
exchange. One way to do this is to derive the Kerberos user key from
the OTP instead of the password in the same manner as described in
[RFC3962] but to use a high number of iterated hashes of the OTP in
the PBKDF2 key derivation function from [RFC2898]. Another is for
the client to include a hardening value unknown to the attacker in
the key derivation.
Unlike the a traditional "salt" value which is normally sent in the
clear, this hardening value will instead be transferred from the KDC
to the client in encrypted form. When the client receives a PA-OTP-
CHALLENGE from a KDC it will search for an associated hardening
value. If it finds a value then it will use it in the key derivation
as specified in Section 2.4.
Richards Expires December 4, 2006 [Page 4]
Internet-Draft OTP Kerberos June 2006
The use of a hardening value will influence the iteration count used
by the client in the random-to-key calculation. The value sent by
the KDC in the s2kparams of the ETYPE-INFO2 pre-authentication type
specifies the value used if there is no hardening value stored on the
client for the server. If the client has a hardening value stored
for the server, then the iteration count of 1 SHOULD be used as the
security of the scheme is provided through the hardening value. If
the client does not have a hardening value stored, then it SHOULD set
the iteration count in the key derivation to the maximum value that
is both supported by the KDC and permitted by any local policy
constraints. The identifier of any hardening value used and the
value of the iteration count are sent by the client to the KDC in a
PA-OTP_RESPONSE included in the KRB_AS_REQ.
When the KDC receives a PA-OTP-RESPONSE, it will use the identifier
to locate the hardening value. If a hardening value is found then it
will be used along with the iterationCount to generate the user key.
If the hardening value identifier is omitted then only the
iterationCount SHALL be used. If a hardening value identifier is
included but the corresponding value could not be found then the KDC
SHALL respond with a KDC_ERR_PREAUTH_REQUIRED error as described
above but SHALL set the noHardening flag in the PA-OTP-CHALLENGE.
The hardening value to be used by the client in the next KRB_AS_REQ
will be sent by the KDC in a PA-OTP-CONFIRM contained in the
KRB_AS_REP. The inclusion of a PA-OTP-CONFIRM is only REQUIRED if
the client did not use a hardening value to generate the timestamp
encryption key. However, it is RECOMMENDED that it be included in
all such responses to ensure that a new hardening value is used in
all client requests.
2.4. Key Derivation
The encryption key used to encrypt the time stamp SHALL be generated
using the PBKDF2 password-based key derivation function as specified
in [RFC3962]. Conformant KDCs MUST support at least one of the
encryption types aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96
defined in [RFC3962] and MUST return PA-ETYPE-INFO2 pre-
authentication types with the corresponding etype values.
In order to use the hardening scheme described in Section 2.3, the
information provided by the KDC in the ETYPE-INFO2 pre-authentication
type SHALL be used by the client as follows:
o If the client does not have a hardening value associated with the
KDC then the number of iterations specified in the s2kparams SHALL
be used. If the client has a hardening value then an iteration
count of 1 SHALL be used instead.
Richards Expires December 4, 2006 [Page 5]
Internet-Draft OTP Kerberos June 2006
o The salt value SHALL have the hardening value concatenated if
there is one associated with the KDC.
tkey = random-to-key(PBKDF2(OTP, salt|hardening,
iteration_count, key_length))
key = DK(tkey, "kerberos")
3. OTP Kerberos Types
3.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
an OTP and how to use the OTP in the generation of the key used to
encrypt the pre-authentication data.
PA-OTP-CHALLENGE ::= SEQUENCE {
flags ChallengeFlags
otp-challenge[0] OCTET STRING OPTIONAL,
otp-length [1] INTEGER OPTIONAL,
otp-service [2] UTF8String OPTIONAL,
otp-keyID [3] OCTET STRING OPTIONAL,
otp-algID [4] INTEGER OPTIONAL
}
ChallengeFlags ::= KerberosFlags
-- noHardening (0),
noHardening
If the noHardening flag is set then the client MUST NOT use any
stored hardening value in the key derivation. Instead, it MUST
use the iteration count provided by the KDC.
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.
Richards Expires December 4, 2006 [Page 6]
Internet-Draft OTP Kerberos June 2006
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 hardening
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-algiID to locate the
appropriate key.
otp-algID
The identifier of the algorithm to use when generating the OTP.
3.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.
PA-OTP-RESPONSE ::= SEQUENCE {
iterationCount[0] INTEGER OPTIONAL,
identifier [1] OCTET STRING OPTIONAL,
otp-challenge [2] 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
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3)
}
iterationCount
The actual value of the iteration count used by the client in the
key derivation. If omitted then the specified or default
iteration count is used. If present then it will generally be
less than the value used in the string-to-key parameters if a
Richards Expires December 4, 2006 [Page 7]
Internet-Draft OTP Kerberos June 2006
hardening value is used.
identifier
An octet string identifying the hardening value used by the client
in the key derivation. If omitted then no hardening was used.
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.
3.3. PA-OTP-CONFIRM
Pre-authentication type returned by the KDC in a KRB_AS_REP if the
client requires a new hardening value.
PA-OTP-CONFIRM ::= SEQUENCE {
identifier OCTET STRING,
encHardeningValue EncryptedData -- EncHardeningValue
}
EncHardeningValue ::= OCTET STRING SIZE (16..MAX)
identifier
An octet string identifying the hardening value used by the client
in the key derivation.
encHardeningValue
The hardening value that the client SHOULD use in future key
derivations. It is encrypted as described in section 5.2.9 of
[RFC4120] using the current user key as derived by the KDC from
the OTP.
Richards Expires December 4, 2006 [Page 8]
Internet-Draft OTP Kerberos June 2006
3.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.
PA-ENC-PIN ::= EncryptedData -- PA-ENC-PIN-ENC
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 pin field MUST be present
and the presence of this pre-auth type indicates that the user's PIN
has been changed to the value contained within the pin field.
If the pin field is omitted then this pre-auth type indicates that
the user must change their PIN using the PIN change service and that
the KDC will only issue tickets for the PIN change service until the
PIN has been changed.
If the pin field is present and the systemPin flag is not set then
the user must change their PIN subject to the restrictions of the
other fields or may alternatively use the returned PIN.
4. IANA Considerations
A registry may be required for the otp-AlgID values as introduced in
Section 3.1. No other IANA actions are anticipated.
5. Security Considerations
5.1. Active attacks
<<TBD: Could an attacker change the iteration count in the PA-
ETYPE_INFO2? >>
5.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
Richards Expires December 4, 2006 [Page 9]
Internet-Draft OTP Kerberos June 2006
disregarding PA-OTP-RESPONSE elements with an iteration count value
higher than some pre- or dynamically- (depending on load) set number.
5.3. Use of Hardening Value
As described in Section 2.3, the use of a hardening value will slow
down an attacker's search for a matching OTP. The ability to
transfer a hardening 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 due to a high iteration
count, subsequent authentications will be efficient, while at the
same time more secure, since a pre-shared, 128 bits long, hardening
value will not be easily found by an attacker.
If a client does not have a hardening value for a KDC then it will
have to generate the user key using only an iteration count. 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
hardening value. For this reason, initial exchanges with KDC servers
SHOULD occur in a secure environment, and if not, the iteration count
MUST be significantly higher than for messages where a pre-shared
hardening value is used. 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.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
2000 Kerberos Change Password and Set Password Protocols",
RFC 3244, February 2002.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
Richards Expires December 4, 2006 [Page 10]
Internet-Draft OTP Kerberos June 2006
6.2. Informative References
[NeZoHo98]
Neuman, C., Zorn, G., Trostle, J., and K. Horstein,
"Integrating Single-use Authentication Mechanisms with
Kerberos", draft-ietf-cat-kerberos-password-04 (work in
progress), November 1998.
Richards Expires December 4, 2006 [Page 11]
Internet-Draft OTP Kerberos June 2006
Author's Address
Gareth Richards
RSA Security UK Ltd.
RSA House
Western Road
Bracknell, Berkshire RG12 1RT
UK
Email: grichards@rsasecurity.com
Richards Expires December 4, 2006 [Page 12]
Internet-Draft OTP Kerberos June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Richards Expires December 4, 2006 [Page 13]