From db76c6366f2b851d08a54be32c930e77a94b93e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Thu, 22 Jul 2004 08:19:34 +0000 Subject: [PATCH] x git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14063 ec53bebd-3082-4978-b11e-865c3cabbd6b --- ...raft-ietf-krb-wg-kerberos-referrals-04.txt | 767 ++++++++++++++ .../draft-raeburn-krb-rijndael-krb-07.txt | 959 ++++++++++++++++++ 2 files changed, 1726 insertions(+) create mode 100644 doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt create mode 100644 doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt new file mode 100644 index 000000000..98d97a377 --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt @@ -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] \ No newline at end of file diff --git a/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt b/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt new file mode 100644 index 000000000..c0d9ba60d --- /dev/null +++ b/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt @@ -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] \ No newline at end of file