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@14063 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2004-07-22 08:19:34 +00:00
parent b0e590f895
commit db76c6366f
2 changed files with 1726 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

767
doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt Normal file
View File

@@ -0,0 +1,767 @@
Kerberos Working Group Karthik Jaganathan
Internet Draft Larry Zhu
Document: draft-ietf-krb-wg-kerberos-referrals-04.txt John Brezak
Category: Standards Track Microsoft
Mike Swift
University of Washington
Jonathan Trostle
Cisco Systems
Expires: January 2005
Generating KDC Referrals to locate Kerberos realms
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC-2026 [1].
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.
Abstract
The draft documents a method for a Kerberos Key Distribution Center
(KDC) to respond to client requests for Kerberos tickets when the
client does not have detailed configuration information on the realms
of users or services. The KDC will handle requests for principals in
other realms by returning either a referral error or a cross-realm
TGT to another realm on the referral path. The clients will use this
referral information to reach the realm of the target principal and
then receive the ticket.
Conventions used in this document
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 RFC-2119 [2].
1. Introduction
Jaganathan [Page 1]
KDC Referrals January 2005
Current implementations of the Kerberos AS and TGS protocols, as
defined in [3], use principal names constructed from a known user or
service name and realm. A service name is typically constructed from
a name of the service and the DNS host name of the computer that is
providing the service. Many existing deployments of Kerberos use a
single Kerberos realm where all users and services would be using the
same realm. However in an environment where there are multiple
trusted Kerberos realms, the client needs to be able to determine
what realm a particular user or service is in before making an AS or
TGS request. Traditionally this requires client configuration to make
this possible.
When having to deal with multiple trusted realms, users are forced to
know what realm they are in before they can obtain a ticket granting
ticket (TGT) with an AS request. However, in many cases the user
would like to use a more familiar name that is not directly related
to the realm of their Kerberos principal name. A good example of this
is an RFC-821 style email name [4]. This document describes a
mechanism that would allow a user to specify a user principal name
that is an alias for the user's Kerberos principal name. In practice
this would be the name that the user specifies to obtain a TGT from a
Kerberos KDC. The user principal name no longer has a direct
relationship with the Kerberos principal or realm. Thus the
administrator is able to move the user's principal to other realms
without the user having to know that it happened.
Once a user has a TGT, they would like to be able to access services
in any trusted Kerberos realm. To do this requires that the client be
able to determine what realm the target service principal is in
before making the TGS request. Current implementations of Kerberos
typically have a table that maps DNS host names to corresponding
Kerberos realms. In order for this to work on the client, each
application canonicalizes the host name of the service, for example
by doing a DNS lookup followed by a reverse lookup using the returned
IP address. The returned primary host name is then used in the
construction of the principal name for the target service. In order
for the correct realm to be added for the target host, the mapping
table [domain_to_realm] is consulted for the realm corresponding to
the DNS host name. The corresponding realm is then used to complete
the target service principal name.
This traditional mechanism requires that each client have very
detailed configuration information about the hosts that are providing
services and their corresponding realms. Having client side
configuration information can be very costly from an administration
point of view - especially if there are many realms and computers in
the environment.
Jaganathan [Page 2]
KDC Referrals January 2005
There are also cases where specific DNS aliases (local names) have
been setup in an organization to refer to a server in another
organization (remote server). The server has different DNS names in
each organization and each organization has a Kerberos realm that is
configured to service DNS names within that organization. Ideally
users are able to authenticate to the server in the other
organization using the local server name. This would mean that the
local realm be able to produce a ticket to the remote server under
its name. You could give that remote server an identity in the local
realm and then have that remote server maintain a separate secret for
each alias it is known as. Alternatively you could arrange to have
the local realm issue a referral to the remote realm and notify the
requesting client of the server's remote name that should be used in
order to request a ticket.
This draft proposes a solution for these problems and simplifies
administration by minimizing the configuration information needed on
each computer using Kerberos. Specifically it describes a mechanism
to allow the KDC to handle canonicalization of names, provide for
principal aliases for users and services and provide a mechanism for
the KDC to determine the trusted realm authentication path by being
able to generate referrals to other realms in order to locate
principals.
To rectify these problems, this draft introduces three new kinds of
KDC referrals:
1. AS ticket referrals, in which the client doesn't know which realm
contains a user account.
2. TGS ticket referrals, in which the client doesn't know which realm
contains a server account.
3. Cross realm shortcut referrals, in which the KDC chooses the next
path on a referral chain
2. Requesting a referral
In order to request referrals defined in section 5, 6, and 7, the
Kerberos client MUST explicitly request the canonicalize KDC option
(bit 15) [3] for the AS-REQ or TGS-REQ. This flag indicates to the
KDC that the client is prepared to receive a reply that contains a
principal name other than the one requested.
KDCOptions ::= KerberosFlags
-- canonicalize (15)
-- other KDCOptions values omitted
The client should expect, when sending names with the "canonicalize"
KDC option, that names in the KDC's reply MAY be different than the
Jaganathan [Page 3]
KDC Referrals January 2005
name in the request. A referral ticket is a cross realm TGT that is
returned when the sname of the ticket is not the sname in the request
[3].
3. Realm Organization Model
This draft assumes that the world of principals is arranged on
multiple levels: the realm, the enterprise, and the world. A KDC may
issue tickets for any principal in its realm or cross-realm tickets
for realms with which it has a direct trust relationship. The KDC
also has access to a trusted name service that can resolve any name
from within its enterprise into a realm. This trusted name service
removes the need to use an un-trusted DNS lookup for name resolution.
For example, consider the following configuration, where lines
indicate trust relationships:
MS.COM
/ \
/ \
OFFICE.MS.COM NTDEV.MS.COM
In this configuration, all users in the MS.COM enterprise could have
a principal name such as alice@MS.COM, with the same realm portion.
In addition, servers at MS.COM should be able to have DNS host names
from any DNS domain independent of what Kerberos realm their
principals reside in.
4. Client Name Canonicalization
A client account may have multiple principal names. More useful,
though, is a globally unique name that allows unification of email
and security principal names. For example, all users at MS may have a
client principal name of the form "joe@MS.COM" even though the
principals are contained in multiple realms. This global name is
again an alias for the true client principal name, which indicates
what realm contains the principal. Thus, accounts "alice" in the
realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
"alice@MS.COM" and "bob@MS.COM".
This utilizes a new client principal name type, as the AS-REQ message
only contains a single realm field, and the realm portion of this
name doesn't correspond to any Kerberos realm. Thus, the entire name
"alice@MS.COM" is transmitted as a single component in the client
name field of the AS-REQ message, with a name type of NT-ENTERPRISE
[3]. The KDC will recognize this name type and then transform the
Jaganathan [Page 4]
KDC Referrals January 2005
requested name into the true principal name. The true principal name
can be using a name type different from the requested name type.
Typically the true principal name will be a NT-PRINCIPAL [3].
If the "canonicalize" KDC option is set, then the KDC MAY change the
client principal name and type in the AS response and ticket returned
from the name type of the client name in the request. For example the
AS request may specify a client name of "bob@MS.COM" as an NT-
PRINCIPAL with the "canonicalize" KDC option set and the KDC will
return with a client name of "104567" as a NT-UID.
5. Client Referrals
The simplest form of ticket referral is for a user requesting a
ticket using an AS-REQ. In this case, the client machine will send
the AS-REQ to a convenient trusted realm, for example the realm of
the client machine. In the case of the name alice@MS.COM, the client
MAY optimistically choose to send the request to MS.COM. The realm in
the AS-REQ is always the name of the realm that the request is for as
specified in [3].
The KDC will try to lookup the name in its local account database. If
the account is present in the realm of the request, it SHOULD return
a KDC reply structure with the appropriate ticket.
If the account is not present in the realm specified in the request
and the "canonicalize" KDC option is set, the KDC will try to lookup
the entire name, alice@MS.COM, using a name service. If this lookup
is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
[3]. If the lookup is successful, it MUST return an error
KDC_ERR_WRONG_REALM [3] and in the error message the crealm field
will contain either the true realm of the client or another realm
that MAY have better information about the client's true realm. The
client MUST NOT use a cname returned from a referral.
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
new AS request with the same client principal name used to generate
the first referral to the realm specified by the realm field of the
Kerberos error message from the first request. The client SHOULD
repeat these steps until it finds the true realm of the client. To
avoid infinite referral loops, an implementation should limit the
number of referrals. A suggested limit is 5 referrals before giving
up. In Microsoft's current implementation through the use of global
catalogs any domain in one forest is reachable from any other domain
in the same forest or another trusted forest with 3 or less
referrals.
6. Service Referrals
Jaganathan [Page 5]
KDC Referrals January 2005
The primary problem in service referrals is that the KDC must return
a referral ticket rather than an error message as is done in AS
ticket referrals. There needs to be a place to include in the TGS-REP
information about what realm contains the service. This is done by
returning information about the service name in the pre-
authentication data field of the KDC reply [3].
If the KDC resolves the service principal name into a principal in
the realm specified by the service realm name, it will return a
normal ticket.
If the "canonicalize" flag in the KDC options is not set, the KDC
MUST only look up the name as a normal principal name in the
specified service realm. If the "canonicalize" flag in the KDC
options is set and the KDC doesn't find the principal locally, the
KDC MAY return a cross-realm ticket granting ticket to the next hop
on the trust path towards a realm that may be able to resolve the
principal name.
When a referral TGT is returned, the KDC MUST return the target realm
for the referral TGT as an KDC supplied pre-authentication data
element in the response. The pre-authentication data MUST be
encrypted using the sub-session key from the authenticator if present
or the session key from the ticket. The pre-authentication data
contains the referred realm, and if known, the real principal name.
PA-SERVER-REFERRAL 25
PA-SERVER-REFERRAL-DATA ::= EncryptedData
-- ServerReferalData --
ServerReferralData ::= SEQUENCE {
referred-realm [0] Realm,
-- target realm of the referral TGT
referred-name [1] PrincipalName OPTIONAL,
-- service principal name, MAY differ
-- from the server name in the request
...
}
Clients MUST NOT process referral tickets if the KDC response does
not contain the PA-SERVER-REFERRAL.
If applicable to the encryption type, the key usage value for the
encryption key used by PA-SERVER-REFERRAL is 26 if the session key
from the ticket is used or 27 if a sub-session key is used.
If the referred-name field is present, the client MUST use that name
Jaganathan [Page 6]
KDC Referrals January 2005
in a subsequent TGS request to the service realm when following the
referral.
The client will use this information to request a chain of cross-
realm ticket granting tickets until it reaches the realm of the
service, and can then expect to receive a valid service ticket.
However an implementation should limit the number of referrals that
it processes to avoid infinite referral loops. A suggested limit is 5
referrals before giving up.
Here is an example of a client requesting a service ticket for a
service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
+NC = Canonicalize KDCOption set
+PA-REFERRAL = returned PA-SERVER-REFERRAL
C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to OFFICE.MS.COM
S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
containing MS.COM as the referred realm with no referred name
C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to MS.COM
S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
containing NTDEV.MS.COM as the referred realm with no referred
name
C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to NTDEV.MS.COM
S: TGS-REP sname=server/foo.ntdev.ms.com@NTDEV.MS.COM
7. Cross Realm Routing
The current Kerberos protocol requires the client to explicitly
request a cross-realm TGT for each pair of realms on a referral
chain. As a result, the client need to be aware of the trust
hierarchy and of any short-cut trusts (those that aren't parent-
child trusts).
Instead, using this referral routing mechanism, The KDC will
determine the best path for the client and return a cross-realm TGT
as the referral TGT, and the target realm for this TGT in the PA-
SERVER-REFERRAL of the KDC reply.
If the "canonicalize" KDC option is not set, the KDC MUST NOT return
a referral ticket. Clients MUST NOT process referral tickets if the
KDC response does not contain the PA-SERVER-REFERRAL.
8. Compatibility with earlier implementations of name canonicalization
The Microsoft Windows 2000 and Windows 2003 releases included an
earlier form of name-canonicalization [5]. Here are the differences:
1) The TGS referral data is returned inside of the KDC message as
Jaganathan [Page 7]
KDC Referrals January 2005
"encrypted pre-authentication data".
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL,
encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
}
2) The preauth data type definition in the encrypted preauth data is
as follows:
PA-SVR-REFERRAL-INFO 20
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
referred-name [1] PrincipalName OPTIONAL,
referred-realm [0] Realm
}
9. Security Considerations
In the case of TGS requests the client may be vulnerable to a denial
of service attack by an attacker that replays replies from previous
requests. The client can verify that the request was one of its own
by checking the client-address field or authtime field, though, so
the damage is limited and detectable.
For the AS exchange case, it is important that the logon mechanism
not trust a name that has not been used to authenticate the user.
For example, the name that the user enters as part of a logon
exchange may not be the name that the user authenticates as, given
that the KDC_ERR_WRONG_REALM error may have been returned. The
relevant Kerberos naming information for logon (if any), is the
client name and client realm in the service ticket targeted at the
workstation that was obtained using the user's initial TGT.
How the client name and client realm is mapped into a local account
for logon is a local matter, but the client logon mechanism MUST use
additional information such as the client realm and/or authorization
Jaganathan [Page 8]
KDC Referrals January 2005
attributes from the service ticket presented to the workstation by
the user, when mapping the logon credentials to a local account on
the workstation.
10. Acknowledgements
The authors wish to thank Ken Raeburn for his comments and
suggestions.
11. References
11.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos-
clarifications. Work in progress.
[4] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
1982.
11.2 Informative References
[5] Trostle, J., Kosinovsky, I., and Swift, M., "Implementation of
Crossrealm Referral Handling in the MIT Kerberos Client", In Network
and Distributed System Security Symposium, February 2001.
12. Author's Addresses
Karthik Jaganathan
Microsoft
One Microsoft Way
Redmond, Washington
Email: karthikj@Microsoft.com
Larry Zhu
Microsoft
One Microsoft Way
Redmond, Washington
Email: lzhu@Microsoft.com
Michael Swift
University of Washington
Jaganathan [Page 9]
KDC Referrals January 2005
Seattle, Washington
Email: mikesw@cs.washington.edu
John Brezak
Microsoft
One Microsoft Way
Redmond, Washington
Email: jbrezak@Microsoft.com
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@cisco.com
Jaganathan [Page 10]
KDC Referrals January 2005
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Jaganathan [Page 11]

959
doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt Normal file
View File

@@ -0,0 +1,959 @@
Kerberos Working Group K. Raeburn
Document: draft-raeburn-krb-rijndael-krb-07.txt MIT
July 19, 2004
expires January 19, 2005
AES Encryption for Kerberos 5
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 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.
Abstract
The US National Institute of Standards and Technology has chosen a
new Advanced Encryption Standard, which is significantly faster and
(it is believed) more secure than the old DES algorithm. This
document is a specification for the addition of this algorithm to the
Kerberos cryptosystem suite.
1. Introduction
This document defines encryption key and checksum types for Kerberos
5 using the AES algorithm recently chosen by NIST. These new types
support 128-bit block encryption, and key sizes of 128 or 256 bits.
Using the "simplified profile" of [KCRYPTO], we can define a pair of
encryption and checksum schemes. AES is used with cipher text
stealing to avoid message expansion, and SHA-1 [SHA1] is the
associated checksum function.
Raeburn [Page 1]
INTERNET DRAFT July 2004
2. Conventions Used in this Document
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 RFC 2119 [KEYWORDS].
3. Protocol Key Representation
The profile in [KCRYPTO] treats keys and random octet strings as
conceptually different. But since the AES key space is dense, we can
use any bit string of appropriate length as a key. We use the byte
representation for the key described in [AES], where the first bit of
the bit string is the high bit of the first byte of the byte string
(octet string) representation.
4. Key Generation From Pass Phrases or Random Data
Given the above format for keys, we can generate keys from the
appropriate amounts of random data (128 or 256 bits) by simply
copying the input string.
To generate an encryption key from a pass phrase and salt string, we
use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
indicated below, to generate an intermediate key (of the same length
as the desired final key), which is then passed into the DK function
with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function
produces a "random octet string", hence the application of the
random-to-key function even though it's effectively a simple identity
operation.) The resulting key is the user's long-term key for use
with the encryption algorithm in question.
tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
key = DK(tkey, "kerberos")
The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
passphrase and salt, as described in Appendix B.1 to PKCS#5.
The number of iterations is specified by the string-to-key parameters
supplied. The parameter string is four octets indicating an unsigned
number in big-endian order. This is the number of iterations to be
performed. If the value is 00 00 00 00, the number of iterations to
be performed is 4294967296 (2**32). (Thus the minimum expressable
iteration count is 1.)
For environments where slower hardware is the norm, implementations
of protocols such as Kerberos may wish to limit the number of
iterations to prevent a spoofed response supplied by an attacker from
Raeburn [Page 2]
INTERNET DRAFT July 2004
consuming lots of client-side CPU time; if such a limit is
implemented, it SHOULD be no less than 50000. Even for environments
with fast hardware, 4 billion iterations is likely to take a fairly
long time; much larger bounds might still be enforced, and it might
be wise for implementations to permit interruption of this operation
by the user if the environment allows for it.
If the string-to-key parameters are not supplied, the value used is
00 00 10 00 (decimal 4096, indicating 4096 iterations).
Note that this is not a requirement, nor even a recommendation, for
this value to be used in "optimistic preauthentication" (e.g.,
attempting timestamp-based preauthentication using the user's long-
term key, without having first communicated with the KDC) in the
absence of additional information, nor as a default value for sites
to use for their principals' long-term keys in their Kerberos
database. It is simply the interpretation of the absence of the
string-to-key parameter field when the KDC has had an opportunity to
provide it.
Sample test vectors are given in appendix B.
5. Cipher Text Stealing
Cipher block chaining is used to encrypt messages. Unlike previous
Kerberos cryptosystems, we use cipher text stealing to handle the
possibly partial final block of the message.
Cipher text stealing is described on pages 195-196 of [AC], and
section 8 of [RC5]; it has the advantage that no message expansion is
done during encryption of messages of arbitrary sizes as is typically
done in CBC mode with padding. Some errata for [RC5] are listed in
appendix A, and are considered part of the cipher text stealing
technique as used here.
Cipher text stealing, as defined in [RC5], assumes that more than one
block of plain text is available. If exactly one block is to be
encrypted, that block is simply encrypted with AES (also known as ECB
mode). Input of less than one block is padded at the end to one
block; the values of the padding bits are unspecified.
(Implementations MAY use all-zero padding, but protocols MUST NOT
rely on the result being deterministic. Implementations MAY use
random padding, but protocols MUST NOT rely on the result not being
deterministic. Note that in most cases, the Kerberos encryption
profile will add a random confounder independent of this padding.)
For consistency, cipher text stealing is always used for the last two
blocks of the data to be encrypted, as in [RC5]. If the data length
Raeburn [Page 3]
INTERNET DRAFT July 2004
is a multiple of the block size, this is equivalent to plain CBC mode
with the last two cipher text blocks swapped.
A test vector is given in appendix B.
The initial vector carried out from one encryption for use in a
following encryption is the next to last block of the encryption
output; this is the encrypted form of the last plaintext block. When
decrypting, the next to last block of the supplied ciphertext is
carried forward as the next initial vector.
6. Kerberos Algorithm Profile Parameters
This is a summary of the parameters to be used with the simplified
algorithm profile described in [KCRYPTO]:
+--------------------------------------------------------------------+
| protocol key format 128- or 256-bit string |
| |
| string-to-key function PBKDF2+DK with variable |
| iteration count (see |
| above) |
| |
| default string-to-key parameters 00 00 10 00 |
| |
| key-generation seed length key size |
| |
| random-to-key function identity function |
| |
| hash function, H SHA-1 |
| |
| HMAC output size, h 12 octets (96 bits) |
| |
| message block size, m 1 octet |
| |
| encryption/decryption functions, AES in CBC-CTS mode |
| E and D (cipher block size 16 |
| octets), with next to |
| last block as CBC-style |
| ivec |
+--------------------------------------------------------------------+
Using this profile with each key size gives us two each of encryption
and checksum algorithm definitions.
Raeburn [Page 4]
INTERNET DRAFT July 2004
7. Assigned Numbers
The following encryption type numbers are assigned:
+--------------------------------------------------------------------+
| encryption types |
+--------------------------------------------------------------------+
| type name etype value key size |
+--------------------------------------------------------------------+
| aes128-cts-hmac-sha1-96 17 128 |
| aes256-cts-hmac-sha1-96 18 256 |
+--------------------------------------------------------------------+
The following checksum type numbers are assigned:
+--------------------------------------------------------------------+
| checksum types |
+--------------------------------------------------------------------+
| type name sumtype value length |
+--------------------------------------------------------------------+
| hmac-sha1-96-aes128 15 96 |
| hmac-sha1-96-aes256 16 96 |
+--------------------------------------------------------------------+
These checksum types will be used with the corresponding encryption
types defined above.
8. Security Considerations
This new algorithm has not been around long enough to receive the
decades of intense analysis that DES has received. It is possible
that some weakness exists that has not been found by the
cryptographers analyzing these algorithms before and during the AES
selection process.
The use of the HMAC function has drawbacks for certain pass phrase
lengths. For example, a pass phrase longer than the hash function
block size (64 bytes, for SHA-1) is hashed to a smaller size (20
bytes) before applying the main HMAC algorithm. However, entropy is
generally sparse in pass phrases, especially in long ones, so this
may not be a problem in the rare cases of users with long pass
phrases.
Also, generating a 256-bit key from a pass phrase of any length may
be deceptive, since the effective entropy in pass-phrase-derived key
cannot be nearly that large, given the properties of the string-to-
key function described here.
Raeburn [Page 5]
INTERNET DRAFT July 2004
The iteration count in PBKDF2 appears to be useful primarily as a
constant multiplier for the amount of work required for an attacker
using brute-force methods. Unfortunately, it also multiplies, by the
same amount, the work needed by a legitimate user with a valid
password. Thus the work factor imposed on an attacker (who may have
many powerful workstations at his disposal) must be balanced against
the work factor imposed on the legitimate user (who may have a PDA or
cell phone); the available computing power on either side increases
as time goes on, as well. A better way to deal with the brute-force
attack is through preauthentication mechanisms that provide better
protection of the user's long-term key. Use of such mechanisms is
out of scope for this document.
If a site does wish to use this means of protection against a brute-
force attack, the iteration count should be chosen based on the
facilities available to both attacker and legitimate user, and the
amount of work the attacker should be required to perform to acquire
the key or password.
As an example:
The author's tests on a 2GHz Pentium 4 system indicated that in
one second, nearly 90000 iterations could be done, producing a
256-bit key. This was using the SHA-1 assembly implementation
from OpenSSL, and a pre-release version of the PBKDF2 code for
MIT's Kerberos package, on a single system. No attempt was made
to do multiple hashes in parallel, so we assume an attacker doing
so can probably do at least 100000 iterations per second --
rounded up to 2**17, for ease of calculation. For simplicity, we
also assume the final AES encryption step costs nothing.
Paul Leach estimates [LEACH] that a password-cracking dictionary
may have on the order of 2**21 entries, with capitalization,
punctuation, and other variations contributing perhaps a factor of
2**11, giving a ballpark estimate of 2**32.
Thus, for a known iteration count N and a known salt string, an
attacker with some number of computers comparable to the author's
would need roughly N*2**15 CPU seconds to convert the entire
dictionary plus variations into keys.
An attacker using a dozen such computers for a month would have
roughly 2**25 CPU seconds available. So using 2**12 (4096)
iterations would mean an attacker with a dozen such computers
dedicated to a brute-force attack against a single key (actually,
any password-derived keys sharing the same salt and iteration
count) would process all the variations of the dictionary entries
in four months, and on average, would likely find the user's
Raeburn [Page 6]
INTERNET DRAFT July 2004
password in two months.
Thus, if this form of attack is of concern, an iteration count a
few orders of magnitude higher should be chosen, and users should
be required to change their passwords every few months. Perhaps
several orders of magnitude, since many users will tend to use the
shorter and simpler passwords (as much as they can get away with,
given a site's password quality checks) that the attacker would
likely try first.
Since this estimate is based on currently available CPU power, the
iteration counts used for this mode of defense should be increased
over time, at perhaps 40%-60% each year or so.
Note that if the attacker has a large amount of storage available,
intermediate results could be cached, saving a lot of work for the
next attack with the same salt and a greater number of iterations
than had been run at the point where the intermediate results were
saved. Thus, it would be wise to generate a new random salt
string when passwords are changed. The default salt string,
derived from the principal name, only protects against the use of
one dictionary of keys against multiple users.
If the PBKDF2 iteration count can be spoofed by an intruder on the
network, and the limit on the accepted iteration count is very high,
the intruder may be able to introduce a form of denial of service
attack against the client by sending a very high iteration count,
causing the client to spend a great deal of CPU time computing an
incorrect key.
An intruder spoofing the KDC reply, providing a low iteration count,
and reading the client's reply from the network may be able to reduce
the work needed in the brute-force attack outlined above. Thus,
implementations may wish to enforce lower bounds on the number of
iterations that will be used.
Since threat models and typical end-user equipment will vary widely
from site to site, allowing site-specific configuration of such
bounds is recommended.
Any benefit against other attacks specific to the HMAC or SHA-1
algorithms is probably achieved with a fairly small number of
iterations.
In the "optimistic preauthentication" case mentioned in section 3,
the client may attempt to produce a key without first communicating
with the KDC. If the client has no additional information, it can
only guess as to the iteration count to be used. Even such
Raeburn [Page 7]
INTERNET DRAFT July 2004
heuristics as "iteration count X was used to acquire tickets for the
same principal only N hours ago" can be wrong. Given the
recommendation above for increasing the iteration counts used over
time, it is impossible to recommend any specific default value for
this case; allowing site-local configuration is recommended. (If the
lower and upper bound checks described above are implemented, the
default count for optimistic preauthentication should be between
those bounds.)
Cipher text stealing mode, since it requires no additional padding in
most cases, will reveal the exact length of each message being
encrypted, rather than merely bounding it to a small range of
possible lengths as in CBC mode. Such obfuscation should not be
relied upon at higher levels in any case; if the length must be
obscured from an outside observer, it should be done by intentionally
varying the length of the message to be encrypted.
9. IANA Considerations
Kerberos encryption and checksum type values used in section 7 were
previously reserved in [KCRYPTO] for the mechanisms defined in this
document. The registries should be updated to list this document as
the reference.
10. Acknowledgements
Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
Leach, Marcus Watts, Larry Zhu and others for feedback on earlier
versions of this document.
A. Errata for RFC 2040 section 8
(Copied from the RFC Editor's errata web site on July 8, 2004.)
Reported By: Bob Baldwin; baldwin@plusfive.com
Date: Fri, 26 Mar 2004 06:49:02 -0800
In Section 8, Description of RC5-CTS, of the encryption method, it says:
1. Exclusive-or Pn-1 with the previous ciphertext
block, Cn-2, to create Xn-1.
It should say:
1. Exclusive-or Pn-1 with the previous ciphertext
block, Cn-2, to create Xn-1. For short messages where
Cn-2 does not exist, use IV.
Raeburn [Page 8]
INTERNET DRAFT July 2004
Reported By: Bob Baldwin; baldwin@plusfive.com
Date: Mon, 22 Mar 2004 20:26:40 -0800
In Section 8, first paragraph, second sentence says:
This mode handles any length of plaintext and produces ciphertext
whose length matches the plaintext length.
In Section 8, first paragraph, second sentence should read:
This mode handles any length of plaintext longer than one
block and produces ciphertext whose length matches the
plaintext length.
In Section 8, step 6 of the decryption method says:
6. Decrypt En to create Pn-1.
In Section 8, step 6 of the decryption method should read:
6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
For short messages where Cn-2 does not exist, use the IV.
B. Sample test vectors
Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
included below.
Iteration count = 1
Pass phrase = "password"
Salt = "ATHENA.MIT.EDUraeburn"
128-bit PBKDF2 output:
cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
128-bit AES key:
42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
256-bit PBKDF2 output:
cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
256-bit AES key:
fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
Raeburn [Page 9]
INTERNET DRAFT July 2004
Iteration count = 2
Pass phrase = "password"
Salt="ATHENA.MIT.EDUraeburn"
128-bit PBKDF2 output:
01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
128-bit AES key:
c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
256-bit PBKDF2 output:
01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
256-bit AES key:
a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
Iteration count = 1200
Pass phrase = "password"
Salt = "ATHENA.MIT.EDUraeburn"
128-bit PBKDF2 output:
5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
128-bit AES key:
4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
256-bit PBKDF2 output:
5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
256-bit AES key:
55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
Iteration count = 5
Pass phrase = "password"
Salt=0x1234567878563412
128-bit PBKDF2 output:
d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
128-bit AES key:
e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
256-bit PBKDF2 output:
d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
256-bit AES key:
97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
(This test is based on values given in [PECMS].)
Raeburn [Page 10]
INTERNET DRAFT July 2004
Iteration count = 1200
Pass phrase = (64 characters)
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Salt="pass phrase equals block size"
128-bit PBKDF2 output:
13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
128-bit AES key:
59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
256-bit PBKDF2 output:
13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
256-bit AES key:
89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
Iteration count = 1200
Pass phrase = (65 characters)
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Salt = "pass phrase exceeds block size"
128-bit PBKDF2 output:
9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
128-bit AES key:
cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
256-bit PBKDF2 output:
9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
256-bit AES key:
d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
Iteration count = 50
Pass phrase = g-clef (0xf09d849e)
Salt = "EXAMPLE.COMpianist"
128-bit PBKDF2 output:
6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
128-bit AES key:
f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
256-bit PBKDF2 output:
6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
256-bit AES key:
4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
Some test vectors for CBC with cipher text stealing, using an initial
vector of all-zero.
Raeburn [Page 11]
INTERNET DRAFT July 2004
AES 128-bit key:
0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
IV:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input:
0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
0010: 20
Output:
0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
0010: 97
Next IV:
0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
IV:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input:
0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
Output:
0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
Next IV:
0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
IV:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input:
0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
Output:
0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
Next IV:
0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
IV:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input:
0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
Output:
0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
0010: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
Next IV:
0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
Raeburn [Page 12]
INTERNET DRAFT July 2004
IV:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input:
0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
Output:
0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
0010: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
Next IV:
0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
IV:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input:
0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
Output:
0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
0030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
Next IV:
0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
Normative References
[AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
and Sons, New York, 1996.
[AES] National Institute of Standards and Technology, U.S. Department
of Commerce, "Advanced Encryption Standard", Federal Information
Processing Standards Publication 197, Washington, DC, November 2001.
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002. Work in
progress.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
Raeburn [Page 13]
INTERNET DRAFT July 2004
RC5-CTS Algorithms", RFC 2040, October 1996.
[SHA1] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", Federal Information
Processing Standards Publication 180-1, Washington, DC, April 1995.
Informative References
[LEACH] Leach, P., email to IETF Kerberos working group mailing list,
5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail.
[PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
December 2001.
Author's Address
Kenneth Raeburn
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139
raeburn@mit.edu
IPR notices
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Raeburn [Page 14]
INTERNET DRAFT July 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
Notes to RFC Editor
The reference entry for [KCRYPTO] lists the draft name, not the RFC
number. This should be replaced with the RFC info when available.
Raeburn [Page 15]