Network Working Group M. Nystroem Internet-Draft RSA, The Security Division of EMC Intended status: Informational S. Machani Expires: August 27, 2007 Diversinet Corp. February 23, 2007 Extensions to CT-KIP to support one- and two-pass key initialization draft-nystrom-keyprov-ct-kip-two-pass-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Nystroem & Machani Expires August 27, 2007 [Page 1] Internet-Draft 1- and 2-pass CT-KIP February 2007 Abstract This document describes extensions to the Cryptographic Token Key Initialization Protocol (CT-KIP) to support one-pass (i.e. one message) and two-pass (i.e. one round-trip) cryptographic token key initialization. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Document organization . . . . . . . . . . . . . . . . . . 4 2. Acronyms and notation . . . . . . . . . . . . . . . . . . . . 5 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. One- and two-pass CT-KIP . . . . . . . . . . . . . . . . . . . 6 3.1. Protocol flow . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. One-pass CT-KIP . . . . . . . . . . . . . . . . . . . 6 3.1.2. Two-pass CT-KIP . . . . . . . . . . . . . . . . . . . 6 3.2. Extensions to the message . . . . . . . . . 6 3.3. Extensions to the message . . . . . . . . 7 3.3.1. The KeyInitializationDataType extension . . . . . . . 7 3.3.2. The AuthenticationDataType extension . . . . . . . . . 8 3.4. MAC calculations . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. One-pass CT-KIP . . . . . . . . . . . . . . . . . . . 9 3.4.2. Two-pass CT-KIP . . . . . . . . . . . . . . . . . . . 11 4. Security considerations . . . . . . . . . . . . . . . . . . . 12 4.1. Applicability of 4-pass CT-KIP security considerations . . 12 4.2. Security considerations specific to 1- and 2-pass CT-KIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Client contributions to K_TOKEN entropy . . . . . . . 12 4.2.2. Replay protection . . . . . . . . . . . . . . . . . . 12 4.2.3. Key confirmation . . . . . . . . . . . . . . . . . . . 13 4.2.4. Server authentication . . . . . . . . . . . . . . . . 13 4.2.5. Key protection in the passphrase profile . . . . . . . 13 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Intellectual property considerations . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative references . . . . . . . . . . . . . . . . . . . 18 8.2. Informative references . . . . . . . . . . . . . . . . . . 18 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Key initialization profiles of CT-KIP . . . . . . . . 22 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 22 B.2. Key transport profile . . . . . . . . . . . . . . . . . . 22 B.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 22 Nystroem & Machani Expires August 27, 2007 [Page 2] Internet-Draft 1- and 2-pass CT-KIP February 2007 B.2.2. Identification . . . . . . . . . . . . . . . . . . . . 22 B.2.3. Payloads . . . . . . . . . . . . . . . . . . . . . . . 22 B.3. Key wrap profile . . . . . . . . . . . . . . . . . . . . . 23 B.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 23 B.3.2. Identification . . . . . . . . . . . . . . . . . . . . 23 B.3.3. Payloads . . . . . . . . . . . . . . . . . . . . . . . 24 B.4. Passphrase-based key wrap profile . . . . . . . . . . . . 25 B.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25 B.4.2. Identification . . . . . . . . . . . . . . . . . . . . 25 B.4.3. Payloads . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix C. Example messages . . . . . . . . . . . . . . . . . . 27 C.1. Note regarding the examples . . . . . . . . . . . . . . . 27 C.2. Example of a message indicating support for two-pass CT-KIP . . . . . . . . . . . . . . . . . . . 27 C.3. Example of a message using the key transport profile . . . . . . . . . . . . . . . . . . . . 29 C.4. Example of a message using the key wrap profile . . . . . . . . . . . . . . . . . . . . . . . 31 C.5. Example of a message using the passphrase-based key wrap profile . . . . . . . . . . . . 32 Appendix D. Integration with PKCS #11 . . . . . . . . . . . . . . 34 D.1. The 2-pass variant . . . . . . . . . . . . . . . . . . . . 34 D.2. The 1-pass variant . . . . . . . . . . . . . . . . . . . . 36 Appendix E. About OTPS . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 42 Nystroem & Machani Expires August 27, 2007 [Page 3] Internet-Draft 1- and 2-pass CT-KIP February 2007 1. Introduction 1.1. Scope This document describes extensions to the Cryptographic Token Key Initialization Protocol (CT-KIP) [1] to support one-pass (i.e. one message) and two-pass (i.e. one round-trip) cryptographic token key initialization. 1.2. Background There are several deployment scenarios where it would be beneficial to have one- or two-pass versions of CT-KIP. These include situations where a direct communication between the OTP token and the CT-KIP server is not possible, where work-flow constraints otherwise would limit real-time communications (e.g. needs for administrators to authorize processes), or where network latency or other design constraints (such as when initialization of tokens using existing seeds from legacy systems is required) makes a four-pass version less suitable. This document tries to meet the needs of these scenarios by describing extensions to CT-KIP for the initialization of cryptographic tokens in one round-trip or less. 1.3. Document organization The organization of this document is as follows: o Section 1 is an introduction. o Section 2 defines acronyms and notation used in this document. o Section 3 defines extensions to CT-KIP. o Section 4 discusses security considerations. o Appendix A presents the XML schema. considerations. o Appendix B contains key initialization profiles for the 1- and 2-pass versions of CT-KIP defined herein. o Appendix C provides example messages. o Appendix D discusses integration with PKCS #11 [2]. o Appendix E provides general information about the One-Time Password Specifications. Nystroem & Machani Expires August 27, 2007 [Page 4] Internet-Draft 1- and 2-pass CT-KIP February 2007 2. Acronyms and notation 2.1. Acronyms MAC Cryptographic Token Key Initialization Protocol 2.2. Notation || String concatenation ID_C Identifier for CT-KIP client ID_S Identifier for CT-KIP server K_AUTH Secret key used for authentication purposes in 4-pass CT- KIP K_MAC Secret key used for key confirmation and authentication purposes, generated in CT-KIP K_TOKEN Secret key used for token computations, generated in CT-KIP K_CLIENT Public key of the cryptographic token K_SHARED Secret key shared between the cryptographic token and the CT-KIP server K_DERIVED Secret key derived from a passphrase that is known to both the cryptographic token or user and the CT-KIP server R Pseudorandom value chosen by the cryptographic token and used for MAC computations The following typographical convention is used in the body of the text: . Nystroem & Machani Expires August 27, 2007 [Page 5] Internet-Draft 1- and 2-pass CT-KIP February 2007 3. One- and two-pass CT-KIP 3.1. Protocol flow 3.1.1. One-pass CT-KIP In one-pass CT-KIP, the server simply sends a message to the CT-KIP client. In this case, there is no exchange of the , , and CT-KIP messages, and hence there is no way for the client to express supported algorithms or key types. Before attempting one-pass CT-KIP, the server must therefore have prior knowledge not only that the client is able and willing to accept this variant of CT-KIP, but also of algorithms and key types supported by the client. Outside the specific cases where one-pass CT-KIP is desired, clients should be constructed and configured to only accept CT-KIP server messages in response to client-initiated transactions. 3.1.2. Two-pass CT-KIP In two-pass CT-KIP, the client's initial message is directly followed by a message. There is no exchange of the message or the message. Essentially, two-pass CT-KIP is a transport of key material from the CT-KIP server to the CT-KIP client. However, as the two-pass variant of CT-KIP consists of one round trip to the server, the client is still able to specify algorithm preferences and supported key types in the message. Note that the CT-KIP "trigger" message defined in [1] may be used to trigger the client's sending of the message. 3.2. Extensions to the message A new extension is defined for this message. The extension signals client support for the two-pass version of CT-KIP, informs the server of supported two-pass variants, and provides optional payload data to the CT-KIP server. The payload is sent in an opportunistic fashion, and may be discarded by the CT-KIP server if the server does not support the two-pass variant the payload is associated with. Depending on the client's policy, this extension may or may not have the Critical attribute set to true. If Critical is not set to "true" then a CT-KIP server may ignore the extension and proceed with ordinary 4-pass CT-KIP. Otherwise, the server must find a suitable two-pass variant or else the protocol run will fail. Nystroem & Machani Expires August 27, 2007 [Page 6] Internet-Draft 1- and 2-pass CT-KIP February 2007 This extension is only valid in ClientHello PDUs. It informs the server of the client's support for the two-pass version of CT-KIP, and carries optional payload data associated with each supported two-pass key initialization method The elements of this type have the following meaning: o : A two-pass key initialization method supported by the CT-KIP client. Multiple supported methods may be present, in which case they shall be listed in order of precedence. o : An optional payload associated with each supported key initialization method. Since the syntax is a shorthand for , any well-formed payloads can be carried in this element. A CT-KIP client that indicates support for two-pass CT-KIP must also include the nonce R in its message (this will enable the client to verify that the CT-KIP server it is communicating with is alive). 3.3. Extensions to the message 3.3.1. The KeyInitializationDataType extension This extension carries an identifier for the selected key initialization method as well as key initialization method-dependent payload data. Servers may include this extension in a message that is being sent in response to a received message if and only if that message contained a TwoPassSupportType Nystroem & Machani Expires August 27, 2007 [Page 7] Internet-Draft 1- and 2-pass CT-KIP February 2007 extension and the client indicated support for the selected key initialization method. Servers must include this extension in a message that is sent as a 1-pass CT-KIP. This extension is only valid in ServerFinished PDUs. It contains key initialization data and its presence results in a two-pass (or one-pass, if no ClientHello was sent) CT-KIP exchange. The elements of this type have the following meaning: o : A two-pass key initialization method supported by the CT-KIP client. o : An payload associated with the key initialization method. Since the syntax is a shorthand for , any well-formed payloads can be carried in this element. 3.3.2. The AuthenticationDataType extension This extension must be included by the CT-KIP server when a successful 1- or 2-pass protocol run will result in an existing key being replaced. The extension contains a MAC proving to the token that the server knows the value of the key it is about to replace. Nystroem & Machani Expires August 27, 2007 [Page 8] Internet-Draft 1- and 2-pass CT-KIP February 2007 This extension is only valid in ServerFinished PDUs. It contains a MAC authenticating the CT-KIP server to the token. The element of this type has the following meaning: o : The authenticating MAC and optional additional information (e.g. MAC algorithm). See further Section 3.4. 3.4. MAC calculations 3.4.1. One-pass CT-KIP 3.4.1.1. Key confirmation In one-pass CT-KIP, the server is required to include an identifier, ID_S, for itself (in the element) in the message. The MAC value in the message shall be computed on the (ASCII) string "MAC 1 computation", the server identifier ID_S, and an usigned integer value I, using a MAC key K_MAC. The value I must be monotonically increasing and guaranteed not to be used again by this server towards this token. It could for example be the number of seconds since some point in time with sufficient granularity, a counter value, or a combination of the two where the counter value is reset for each new time value. In contrast to [1], the MAC key K_MAC shall be provided together with K_TOKEN to the token, and hence there is no need for a K_AUTH for key confirmation purposes. Note 1: The integer I does not necessarily need to be maintained per token by the CT-KIP server (it is enough if the server can guarantee that the same value is never being sent twice to the same token). Note 2: An extension is planned to [1] to allow for generation of a K_MAC in addition to K_TOKEN in 4-pass CT-KIP. Nystroem & Machani Expires August 27, 2007 [Page 9] Internet-Draft 1- and 2-pass CT-KIP February 2007 If CT-KIP-PRF is used as the MAC algorithm, then the input parameter s shall consist of the concatenation of the (ASCII) string "MAC 1 computation", ID_S, and I. The parameter dsLen shall be set to at least 16 (i.e. the length of the MAC shall be at least 16 octets): dsLen >= 16 MAC = CT-KIP-PRF (K_MAC, "MAC 1 computation" || ID_S || I, dsLen) The server shall provide I to the client in the Nonce attribute of the element of the message using the following extension of the CT-KIP MacType: 3.4.1.2. Server authentication As discussed in Section 3.3.2, servers need to authenticate themselves when attempting to replace an existing K_TOKEN. In 1-pass CT-KIP, servers authenticate themselves by including a second MAC value in the AuthenticationDataType extension. The MAC value in the AuthenticationDataType extension shall be computed on the (ASCII) string "MAC 1 computation", the server identifier ID_S, and a new value I', I' > I, using the existing MAC key K_MAC' (the MAC key that existed before this protocol run). The MAC algorithm shall be the same as the algorithm used for key confirmation purposes. If CT-KIP-PRF is used as the MAC algorithm, then the input parameter s shall consist of the concatenation of the (ASCII) string "MAC 1 computation" ID_S, and I'. The parameter dsLen shall be set to at least 16 (i.e. the length of the MAC shall be at least 16 octets): dsLen >= 16 MAC = CT-KIP-PRF (K_MAC', "MAC 1 computation" || ID_S || I', dsLen) The server shall provide I' to the client in the Nonce attribute of the element of the AuthenticationDataType extension. If the protocol run is successful, the client stores I' as the new value of I for this server. Nystroem & Machani Expires August 27, 2007 [Page 10] Internet-Draft 1- and 2-pass CT-KIP February 2007 3.4.2. Two-pass CT-KIP 3.4.2.1. Key confirmation In two-pass CT-KIP, the client is required to include a nonce R in the message. Further, the server is required to include an identifier, ID_S, for itself (in the element) in the message. The MAC value in the message shall be computed on the (ASCII) string "MAC 1 computation", the server identifier ID_S, and R using a MAC key K_MAC. Again, in contrast with [1], this key shall be provided together with K_TOKEN to the token, and hence there is no need for a K_AUTH for key confirmation purposes. If CT-KIP-PRF is used as the MAC algorithm, then the input parameter s shall consist of the concatenation of the (ASCII) string "MAC 1 computation" and R, and the parameter dsLen shall be set to the length of R: dsLen = len(R) MAC = CT-KIP-PRF (K_MAC, "MAC 1 computation" || ID_S || R, dsLen) 3.4.2.2. Server authentication As discussed in Section 3.3.2, servers need to authenticate themselves when attempting to replace an existing K_TOKEN. In 2-pass CT-KIP, servers authenticate themselves by including a second MAC value in the AuthenticationDataType extension. The MAC value in the AuthenticationDataType extension shall be computed on the (ASCII) string "MAC 1 computation", the server identifier ID_S, and R, using the existing MAC key K_MAC' (the MAC key that existed before this protocol run). The MAC algorithm shall be the same as the algorithm used for key confirmation purposes. If CT-KIP-PRF is used as the MAC algorithm, then the input parameter s shall consist of the concatenation of the (ASCII) string "MAC 1 computation" ID_S, and R. The parameter dsLen shall be set to at least 16 (i.e. the length of the MAC shall be at least 16 octets): dsLen >= 16 MAC = CT-KIP-PRF (K_MAC', "MAC 1 computation" || ID_S || R, dsLen) Nystroem & Machani Expires August 27, 2007 [Page 11] Internet-Draft 1- and 2-pass CT-KIP February 2007 4. Security considerations 4.1. Applicability of 4-pass CT-KIP security considerations This document extends [1], and therefore, the security considerations discussed in [1] apply here as well, with the following exceptions: o Message re-ordering attacks cannot occur since in the CT-KIP variants described in this document each party sends at most one message each. o The attack described in Section 5.5 of [1] where the attacker replaces a client-provided R_C with his own R'C does not apply as the client does not provide any entropy to K_TOKEN in the 1- and 2-pass variants discussed here. The attack as such (and its countermeasures) still applies, however, as it essentially is a man-in-the-middle attack. In addition, the 1- and 2-pass CT-KIP variants described in this document warrant some further security considerations that are discussed in the following. 4.2. Security considerations specific to 1- and 2-pass CT-KIP 4.2.1. Client contributions to K_TOKEN entropy In 4-pass CT-KIP, both the client and the server provide randomizing material to K_TOKEN , in a manner that allows both parties to verify that they did contribute to the resulting key. In the 1- and 2-pass CT-KIP versions defined herein, only the server contributes to the entropy of K_TOKEN. This means that a broken or compromised (pseudo-)random number generator in the server may cause more damage than it would in the 4-pass variant. Server implementations should therefore take extreme care to ensure that this situation does not occur. 4.2.2. Replay protection A 4-pass CT-KIP client knows that a server it is communicating with is "live" since the server must create a MAC on information sent by the client. The same is true for 2-pass CT-KIP thanks to the requirement that the client sends R in the message and that the server includes R in the MAC computation. In 1-pass CT-KIP clients (tokens) that record the latest I used by a particular server (as identified by ID_S) will be able to detect replays. Nystroem & Machani Expires August 27, 2007 [Page 12] Internet-Draft 1- and 2-pass CT-KIP February 2007 4.2.3. Key confirmation 4-pass CT-KIP servers provide key confirmation through the MAC on R_C in the message. In the 1- and 2-pass CT-KIP variants described herein, key confirmation is provided by the MAC including I (in the 1-pass case) or R (2-pass case), using K_MAC. 4.2.4. Server authentication CT-KIP servers must authenticate themselves whenever a successful CT- KIP 1- or 2-pass protocol run would result in an existing K_TOKEN being replaced by a K_TOKEN', or else a denial-of-service attack where an unauthorized CT-KIP server replaces a K_TOKEN with another key would be possible. In 1- and 2-pass CT-KIP servers authenticate by including the AuthenticationDataType extension containing a MAC as described in Section 3.4 above. 4.2.5. Key protection in the passphrase profile The passphrase-based key wrap profile uses the PBKDF2 function from [3] to generate an encryption key from a passphrase and salt string. The derived key, K_DERIVED is used by the server to encrypt K_TOKEN and by the token to decrypt the newly delivered K_TOKEN. It is important to note that passphrase-based encryption is generally limited in the security that it provides despite the use of salt and iteration count in PBKDF2 to increase the complexity of attack. Implementations should therefore take additional measures to strengthen the security of the passphrase-based key wrap profile. The following measures should be considered where applicable: o The passphrase should be selected well, and usage guidelines such as the ones in [9] should be taken into account. o A different passphrase should be used for every key initialization wherever possible (the use of a global passphrase for a batch of tokens should be avoided, for example). One way to achieve this is to use randomly-generated passphrases. o The passphrase should be protected well if stored on the server and/or on the token and should be delivered to the token's user using secure methods. o User pre-authentication should be implemented to ensure that K_TOKEN is not delivered to a rogue recipient. o The iteration count in PBKDF2 should be high to impose more work for an attacker using brute-force methods (see [3] for recommendations). However, it must be noted that the higher the Nystroem & Machani Expires August 27, 2007 [Page 13] Internet-Draft 1- and 2-pass CT-KIP February 2007 count, the more work is required on the legitimate token to decrypt the newly delivered K_TOKEN. Servers may use relatively low iteration counts to accommodate tokens with limited processing power such as some PDA and cell phones when other security measures are implemented and the security of the passphrase-based key wrap method is not weakened. o Transport level security (e.g. TLS) should be used where possible to protect a 2-pass or 1-pass protocol run. Transport level security provides a second layer of protection for the newly generated K_TOKEN. Nystroem & Machani Expires August 27, 2007 [Page 14] Internet-Draft 1- and 2-pass CT-KIP February 2007 5. IANA considerations This document does not contain any considerations for IANA. Nystroem & Machani Expires August 27, 2007 [Page 15] Internet-Draft 1- and 2-pass CT-KIP February 2007 6. Intellectual property considerations RSA and RSA Security are registered trademarks or trademarks of RSA Security Inc. in the United States and/or other countries. The names of other products and services mentioned may be the trademarks of their respective owners. Nystroem & Machani Expires August 27, 2007 [Page 16] Internet-Draft 1- and 2-pass CT-KIP February 2007 7. Acknowledgements Thanks to all the participants at the OTPS workshops where this document has been discussed and on the OTPS mailing list for their review and comments related to this document. Nystroem & Machani Expires August 27, 2007 [Page 17] Internet-Draft 1- and 2-pass CT-KIP February 2007 8. References 8.1. Normative references [1] Nystroem, M., "Cryptographic Token Key Initialization Protocol", RFC 4758, November 2006, . [2] RSA Laboratories, "Cryptographic Token Interface Standard", PKCS #11 Version 2.20, June 2004, . [3] RSA Laboratories, "Password-Based Cryptography Standard", PKCS #5 Version 2.0, March 1999, . [4] W3C, "XML Signature Syntax and Processing", W3C Recommendation, February 2002, . [5] W3C, "XML Encryption Syntax and Processing", W3C Recommendation, December 2002, . [6] RSA Laboratories, "XML Schema for PKCS #5 Version 2.0", PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT), October 2006, . [7] RSA Laboratories, "PKCS #11 Mechanisms for the Cryptographic Token Key Initialization Protocol", PKCS #11 Version 2.20 Amd.2, December 2005, . [8] RSA Laboratories, "RSA Cryptography Standard", PKCS #1 Version 2.1, June 2002, . 8.2. Informative references [9] National Institute of Standards and Technology, "Password Usage", FIPS 112, May 1985, . Nystroem & Machani Expires August 27, 2007 [Page 18] Internet-Draft 1- and 2-pass CT-KIP February 2007 Appendix A. XML Schema !-- $Revision: 1.7 $ $Date: 2006/10/14 18:52:48 $ --> Nystroem & Machani Expires August 27, 2007 [Page 19] Internet-Draft 1- and 2-pass CT-KIP February 2007 This extension is only valid in ClientHello PDUs. It informs the server of the client's support for the two-pass version of CT-KIP, and carries optional payload data associated with each supported two-pass key initialization method. This extension is only valid in ServerFinished PDUs. It contains key initialization data and its presence results in a two-pass (or one-pass, if no ClientHello was sent) CT-KIP exchange. This extension is only valid in ServerFinished PDUs. It contains a MAC authenticating the CT-KIP server to the token. Nystroem & Machani Expires August 27, 2007 [Page 20] Internet-Draft 1- and 2-pass CT-KIP February 2007 Nystroem & Machani Expires August 27, 2007 [Page 21] Internet-Draft 1- and 2-pass CT-KIP February 2007 Appendix B. Key initialization profiles of CT-KIP B.1. Introduction This appendix introduces three profiles of CT-KIP for key initialization. They may all be used for two- as well as one-pass initialization of cryptographic tokens. Further profiles may be defined by external entities or through the OTPS process. B.2. Key transport profile B.2.1. Introduction This profile initializes the cryptographic token with a symmetric key, K_TOKEN, through key transport and key derivation. The key transport is carried out using a public key, K_CLIENT, whose private key part resides in the token as the transport key. A key K from which two keys, K_TOKEN and K_MAC are derived shall be transported. B.2.2. Identification This profile shall be identified with the following URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/ ct-kip#transport B.2.3. Payloads In the two-pass version of CT-KIP, the client shall send a payload associated with this key initialization method. The payload shall be of type ds:KeyInfoType ([4]), and only those choices of the ds: KeyInfoType that identify a public key are allowed. The ds: X509Certificate option of the ds:X509Data alternative is recommended when the public key corresponding to the private key on the cryptographic token has been certified. The server payload associated with this key initialization method shall be of type xenc:EncryptedKeyType ([5]), and only those encryption methods utilizing a public key that are supported by the CT-KIP client (as indicated in the element of the message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP) are allowed as values for the element. Further, in the case of 2-pass CT-KIP, the element shall contain the same value (i.e. identify the same public key) as the of the corresponding supported key initialization method in the message that triggered the response. The element may be present, but shall, when present, Nystroem & Machani Expires August 27, 2007 [Page 22] Internet-Draft 1- and 2-pass CT-KIP February 2007 contain the same value as the element of the message. The Type attribute of the xenc:EncryptedKeyType shall be present and shall identify the type of the wrapped token key. The type shall be one of the types supported by the CT-KIP client (as reported in the of the preceding message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP). The transported key shall consist of two parts of equal length. The first half constitutes K_MAC and the second half constitutes K_TOKEN. The length of K_TOKEN (and hence also the length of K_MAC) is determined by the type of K_TOKEN. CT-KIP servers and tokens supporting this profile must support the http://www.w3.org/2001/04/xmlenc#rsa-1_5 key-wrapping mechanism defined in [5]. When this profile is used, the MacAlgorithm attribute of the element of the message must be present and must identify the selected MAC algorithm. The selected MAC algorithm must be one of the MAC algorithms supported by the CT-KIP client (as indicated in the element of the message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP). The MAC shall be calculated as described in Section 3.4 In addition, CT-KIP servers must include the AuthenticationDataType extension (see further Section 3.4) in their messages whenever a successful protocol run will result in an existing K_TOKEN being replaced. B.3. Key wrap profile B.3.1. Introduction This profile initializes the cryptographic token with a symmetric key, K_TOKEN, through key wrap and key derivation. The key wrap shall be carried out using a (symmetric) key-wrapping key, K_SHARED, known in advance by both the token and the CT-KIP server. A key K from which two keys, K_TOKEN and K_MAC are derived shall be wrapped. B.3.2. Identification This profile shall be identified with the following URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/ct-kip#wrap Nystroem & Machani Expires August 27, 2007 [Page 23] Internet-Draft 1- and 2-pass CT-KIP February 2007 B.3.3. Payloads In the 2-pass version of CT-KIP, the client shall send a payload associated with this key initialization method. The payload shall be of type ds:KeyInfoType ([4]), and only those choices of the ds: KeyInfoType that identify a symmetric key are allowed. The ds: KeyName alternative is recommended. The server payload associated with this key initialization method shall be of type xenc:EncryptedKeyType ([5]), and only those encryption methods utilizing a symmetric key that are supported by the CT-KIP client (as indicated in the element of the message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP) are allowed as values for the element. Further, in the case of 2-pass CT-KIP, the element shall contain the same value (i.e. identify the same symmetric key) as the of the corresponding supported key initialization method in the message that triggered the response. The element may be present, and shall, when present, contain the same value as the element of the message. The Type attribute of the xenc: EncryptedKeyType shall be present and shall identify the type of the wrapped token key. The type shall be one of the types supported by the CT-KIP client (as reported in the of the preceding message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP). The wrapped key shall consist of two parts of equal length. The first half constitutes K_MAC and the second half constitutes K_TOKEN. The length of K_TOKEN (and hence also the length of K_MAC) is determined by the type of K_TOKEN. CT-KIP servers and tokens supporting this profile must support the http://www.w3.org/2001/04/xmlenc#kw-aes128 key-wrapping mechanism defined in [5]. When this profile is used, the MacAlgorithm attribute of the element of the message must be present and must identify the selected MAC algorithm. The selected MAC algorithm must be one of the MAC algorithms supported by the CT-KIP client (as indicated in the element of the message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP). The MAC shall be calculated as described in Section 3.4 In addition, CT-KIP servers must include the AuthenticationDataType extension (see further Section 3.4) in their messages whenever a successful protocol run will result in an Nystroem & Machani Expires August 27, 2007 [Page 24] Internet-Draft 1- and 2-pass CT-KIP February 2007 existing K_TOKEN being replaced. B.4. Passphrase-based key wrap profile B.4.1. Introduction This profile is a variation of the key wrap profile. It initializes the cryptographic token with a symmetric key, K_TOKEN, through key wrap and key derivation, using a passphrase-derived key-wrapping key, K_DERIVED. The passphrase is known in advance by both the token user and the CT-KIP server. To preserve the property of not exposing K_TOKEN to any other entity than the CT_KIP server and the token itself, the method should be employed only when the token contains facilities (e.g. a keypad) for direct entry of the passphrase. A key K from which two keys, K_TOKEN and K_MAC are derived shall be wrapped. B.4.2. Identification This profile shall be identified with the following URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/ ct-kip#passphrase-wrap B.4.3. Payloads In the 2-pass version of CT-KIP, the client shall send a payload associated with this key initialization method. The payload shall be of type ds:KeyInfoType ([4]). The ds:KeyName option shall be used and the key name shall identify the passphrase that will be used by the server to generate the key-wrapping key. As an example, the identifier could be a user identifier or a registration identifier issued by the server to the user during a session preceding the CT- KIP protocol run. The server payload associated with this key initialization method shall be of type xenc:EncryptedKeyType ([5]), and only those encryption methods utilizing a passphrase to derive the key-wrapping key that are supported by the CT-KIP client (as indicated in the element of the message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP) are allowed as values for the element. Further, in the case of 2-pass CT-KIP, the element shall contain the same value (i.e. identify the same passphrase) as the of the corresponding supported key initialization method in the message that triggered the response. The element may be present, and shall, when present, contain the same value as the element of the Nystroem & Machani Expires August 27, 2007 [Page 25] Internet-Draft 1- and 2-pass CT-KIP February 2007 message. The Type attribute of the xenc: EncryptedKeyType shall be present and shall identify the type of the wrapped token key. The type shall be one of the types supported by the CT-KIP client (as reported in the of the preceding message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP). The wrapped key shall consist of two parts of equal length. The first half constitutes K_MAC and the second half constitutes K_TOKEN. The length of K_TOKEN (and hence also the length of K_MAC) is determined by the type of K_TOKEN. CT-KIP servers and tokens supporting this profile must support the PBES2 password based encryption scheme defined in [3] (and identified as http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in [6]), the PBKDF2 passphrase-based key derivation function also defined in [3] (and identified as http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 in [6]), and the http://www.w3.org/2001/04/xmlenc#kw-aes128 key-wrapping mechanism defined in [5]. When this profile is used, the MacAlgorithm attribute of the element of the message must be present and must identify the selected MAC algorithm. The selected MAC algorithm must be one of the MAC algorithms supported by the CT-KIP client (as indicated in the element of the message in the case of 2-pass CT-KIP, or as otherwise known in the case of 1-pass CT-KIP). The MAC shall be calculated as described in Section 3.4 In addition, CT-KIP servers must include the AuthenticationDataType extension (see further Section 3.4) in their messages whenever a successful protocol run will result in an existing K_TOKEN being replaced. Nystroem & Machani Expires August 27, 2007 [Page 26] Internet-Draft 1- and 2-pass CT-KIP February 2007 Appendix C. Example messages C.1. Note regarding the examples All examples are syntactically correct. MAC and cipher values are fictitious however. The examples illustrate a complete two-pass CT- KIP exchange. The server messages may also constitute the only messages in a one-pass CT-KIP exchange. C.2. Example of a message indicating support for two-pass CT-KIP The client indicates support both for the two-pass key transport variant as well as the two-pass key wrap variant. Nystroem & Machani Expires August 27, 2007 [Page 27] Internet-Draft 1- and 2-pass CT-KIP February 2007 12345678 112dsdfwf312asder394jw== http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/ otps-wst#SecurID-AES http://www.w3.org/2001/04/xmlenc#rsa-1_5 http://www.w3.org/2001/04/xmlenc#kw-aes128 http://www.rsasecurity.com/rsalabs/otps/schemas /2005/12/ct-kip#ct-kip-prf-aes http://www.rsasecurity.com/rsalabs/otps/schemas /2005/12/ct-kip#ct-kip-prf-aes http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/ ct-kip#wrap Key-001 http://www.rsasecurity.com/rsalabs/otps/schemas /2005/12/ct-kip#transport miib Nystroem & Machani Expires August 27, 2007 [Page 28] Internet-Draft 1- and 2-pass CT-KIP February 2007 C.3. Example of a message using the key transport profile In this example, the server responds to the previous request using the key transport profile. Nystroem & Machani Expires August 27, 2007 [Page 29] Internet-Draft 1- and 2-pass CT-KIP February 2007 12345678 43212093 2009-09-16T03:02:00Z Example Enterprise Name exampleLoginName http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/ ct-kip#transport miib abcd 43212093 Decimal 6 miidfasde312asder394jw== Nystroem & Machani Expires August 27, 2007 [Page 30] Internet-Draft 1- and 2-pass CT-KIP February 2007 C.4. Example of a message using the key wrap profile In this example, the server responds to the previous request using the key wrap profile. 12345678 43212093 2009-09-16T03:02:00Z Example Enterprise Name exampleLoginName http://www.rsasecurity.com/rsalabs/otps/schemas /2006/05/ct-kip#wrap Key-001 abcd 43212093 Decimal 6 miidfasde312asder394jw== Nystroem & Machani Expires August 27, 2007 [Page 31] Internet-Draft 1- and 2-pass CT-KIP February 2007 C.5. Example of a message using the passphrase-based key wrap profile In this example, the server responds to the previous request using the passphrase-based key wrap profile. 12345678 43212093 2009-09-16T03:02:00Z Example Enterprise Name exampleLoginName http://www.rsasecurity.com/rsalabs/otps/schemas/2006/03 /ct-kip#passphrase-wrap 32113435 1024 128 Nystroem & Machani Expires August 27, 2007 [Page 32] Internet-Draft 1- and 2-pass CT-KIP February 2007 Passphrase1 ZWcLvpFoXNHAG+lx3+Rww/Sic+o 43212093 Decimal 6 miidfasde312asder394jw== Nystroem & Machani Expires August 27, 2007 [Page 33] Internet-Draft 1- and 2-pass CT-KIP February 2007 Appendix D. Integration with PKCS #11 D.1. The 2-pass variant A suggested procedure to perform 2-pass CT-KIP with a cryptographic token through the PKCS #11 interface using the mechanisms defined in [7] is as follows (see also [1]): a. On the client side, 1. The client selects a suitable slot and token (e.g. through use of the or the element of the CT- KIP trigger message). 2. A nonce R is generated, e.g. by calling C_SeedRandom and C_GenerateRandom. 3. The client sends its first message to the server, including the nonce R. b. On the server side, 1. A generic key K = K_TOKEN | K _MAC (where '|' denotes concatenation) is generated, e.g. by calling C_GenerateKey (using key type CKK_GENERIC_SECRET). The template for K shall allow it to be exported (but only in wrapped form, i.e. CKA_SENSITIVE shall be set to CK_TRUE and CKA_EXTRACTABLE shall also be set to CK_TRUE), and also to be used for further key derivation. From K, a token key K_TOKEN of suitable type is derived by calling C_DeriveKey using the PKCS #11 mechanism CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to the first bit of the generic secret key (i.e. set to 0). Likewise, a MAC key K_MAC is derived from K by calling C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism, this time setting CK_EXTRACT_PARAMS to the length of K (in bits) divided by two. 2. The server wraps K with either the token's public key K_CLIENT, the shared secret key K_SHARED, or the derived shared secret key K_DERIVED by using C_WrapKey. If use of the CT-KIP key wrap algorithm has been negotiated then the CKM_KIP_WRAP mechanism shall be used to wrap K. When calling C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure shall be set to NULL_PTR. The pSeed parameter in the CK_KIP_PARAMS structure shall point to the nonce R provided by the CT-KIP client, and the ulSeedLen parameter shall indicate the length of R. The hWrappingKey parameter in the call to C_WrapKey shall be set to refer to the wrapping key. Nystroem & Machani Expires August 27, 2007 [Page 34] Internet-Draft 1- and 2-pass CT-KIP February 2007 3. Next, the server needs to calculate a MAC using K_MAC. If use of the CT-KIP MAC algorithm has been negotiated, then the MAC is calculated by calling C_SignInit with the CKM_KIP_MAC mechanism followed by a call to C_Sign. In the call to C_SignInit, K_MAC shall be the signature key, the hKey parameter in the CK_KIP_PARAMS structure shall be set to NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure shall be set to NULL_PTR, and the ulSeedLen parameter shall be set to zero. In the call to C_Sign, the pData parameter shall be set to the concatenation of the string ID_S and the nonce R, and the ulDataLen parameter shall be set to the length of the concatenated string. The desired length of the MAC shall be specified through the pulSignatureLen parameter and shall be set to the length of R. 4. If the server also needs to authenticate its message (due to an existing K_TOKEN being replaced), the server shall calculate a second MAC. Again, if use of the CT-KIP MAC algorithm has been negotiated, then the MAC is calculated by calling C_SignInit with the CKM_KIP_MAC mechanism followed by a call to C_Sign. In this call to C_SignInit, the K_MAC existing before this CT-KIP protocol run shall be the signature key, the hKey parameter in the CK_KIP_PARAMS structure shall be set to NULL, the pSeed parameter of the CT_KIP_PARAMS structure shall be set to NULL_PTR, and the ulSeeidLen parameter shall be set to zero. In the call to C_Sign, the pData parameter shall be set to the concatenation of the string ID_S and the nonce R, and the ulDataLen parameter shall be set to the length of concatenated string. The desired length of the MAC shall be specified through the pulSignatureLen parameter and shall be set to the length of R. 5. The server sends its message to the client, including the wrapped key K, the MAC and possibly also the authenticating MAC. c. On the client side, 1. The client calls C_UnwrapKey to receive a handle to K. After this, the client calls C_DeriveKey twice: Once to derive K_TOKEN and once to derive K_MAC. The client shall use the same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same mechanism parameters as used by the server above. When calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter shall be used to set additional key attributes in accordance with local policy and as negotiated and expressed in the protocol. In particular, the value of the element in Nystroem & Machani Expires August 27, 2007 [Page 35] Internet-Draft 1- and 2-pass CT-KIP February 2007 the server's response message may be used as CKA_ID for K_TOKEN. The key K shall be destroyed after deriving K_TOKEN and K_MAC. 2. The MAC is verified in a reciprocal fashion as it was generated by the server. If use of the CKM_KIP_MAC mechanism has been negotiated, then in the call to C_VerifyInit, the hKey parameter in the CK_KIP_PARAMS structure shall be set to NULL_PTR, the pSeed parameter shall be set to NULL_PTR, and ulSeedLen shall be set to 0. The hKey parameter of C_VerifyInit shall refer to K_MAC. In the call to C_Verify, pData shall be set to the concatenation of the string ID_S and the nonce R, and the ulDataLen parameter shall be set to the length of the concatenated string, pSignature to the MAC value received from the server, and ulSignatureLen to the length of the MAC. If the MAC does not verify the protocol session ends with a failure. The token shall be constructed to not "commit" to the new K_TOKEN or the new K_MAC unless the MAC verifies. 3. If an authenticating MAC was received (required if the new K_TOKEN will replace an existing key on the token), then it is verified in a similar vein but using the K_MAC associated with this server and existing before the protocol run. Again, if the MAC does not verify the protocol session ends with a failure, and the token must be constructed no to "commit" to the new K_TOKEN or the new K_MAC unless the MAC verifies. D.2. The 1-pass variant A suggested procedure to perform 1-pass CT-KIP with a cryptographic token through the PKCS #11 interface using the mechanisms defined in [7] is as follows (see also [1]): a. On the server side, 1. A generic key K = K_TOKEN | K _MAC (where '|' denotes concatenation) is generated, e.g. by calling C_GenerateKey (using key type CKK_GENERIC_SECRET). The template for K shall allow it to be exported (but only in wrapped form, i.e. CKA_SENSITIVE shall be set to CK_TRUE and CKA_EXTRACTABLE shall also be set to CK_TRUE), and also to be used for further key derivation. From K, a token key K_TOKEN of suitable type is derived by calling C_DeriveKey using the PKCS #11 mechanism CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to the first bit of the generic secret key (i.e. set to 0). Likewise, a MAC key K_MAC is derived from K Nystroem & Machani Expires August 27, 2007 [Page 36] Internet-Draft 1- and 2-pass CT-KIP February 2007 by calling C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism, this time setting CK_EXTRACT_PARAMS to the length of K (in bits) divided by two. 2. The server wraps K with either the token's public key, K_CLIENT, the shared secret key, K_SHARED, or the derived shared secret key, K_DERIVED by using C_WrapKey. If use of the CT-KIP key wrap algorithm has been negotiated, then the CKM_KIP_WRAP mechanism shall be used to wrap K. When calling C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure shall be set to NULL_PTR. The pSeed parameter in the CK_KIP_PARAMS structure shall point to the octet-string representation of an integer I whose value shall be incremented before each protocol run, and the ulSeedLen parameter shall indicate the length of the octet-string representation of I. The hWrappingKey parameter in the call to C_WrapKey shall be set to refer to the wrapping key. Note: The integer-to-octet string conversion shall be made using the I2OSP primitive from [8]. There shall be no leading zeros. 3. For the server's message to the client, if use of the CT-KIP MAC algorithm has been negotiated, then the MAC is calculated by calling C_SignInit with the CKM_KIP_MAC mechanism followed by a call to C_Sign. In the call to C_SignInit, K_MAC shall be the signature key, the hKey parameter in the CK_KIP_PARAMS structure shall be set to NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure shall be set to NULL_PTR, and the ulSeedLen parameter shall be set to zero. In the call to C_Sign, the pData parameter shall be set to the concatenation of the string ID_S and the octet-string representation of the integer I, and the ulDataLen parameter shall be set to the length of concatenated string. The desired length of the MAC shall be specified through the pulSignatureLen parameter as usual, and shall be equal to, or greater than, sixteen (16). 4. If the server also needs to authenticate its message (due to an existing K_TOKEN being replaced), the server calculates a second MAC. If the CT-KIP MAC mechanism is used, the server does this by calling C_SignInit with the CKM_KIP_MAC mechanism followed by a call to C_Sign. In the call to C_SignInit, the K_MAC existing on the token before this protocol run shall be the signature key, the hKey parameter in the CK_KIP_PARAMS structure shall be set to NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure shall be set to NULL_PTR, and the ulSeedLen parameter shall be set to zero. In the call to C_Sign, the pData parameter shall be Nystroem & Machani Expires August 27, 2007 [Page 37] Internet-Draft 1- and 2-pass CT-KIP February 2007 set to the concatenation of the string ID_S and the octet- string representation of the integer I+1 (i.e. I shall be incremented before each use), and the ulDataLen parameter shall be set to the length of the concatenated string. The desired length of the MAC shall be specified through the pulSignatureLen parameter as usual, and shall be equal to, or greater than, sixteen (16). 5. The server sends its message to the client, including the MAC and possibly also the authenticating MAC. b. On the client side, 1. The client calls C_UnwrapKey to receive a handle to K. After this, the client calls C_DeriveKey twice: Once to derive K_TOKEN and once to derive K_MAC. The client shall use the same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same mechanism parameters as used by the server above. When calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter shall be used to set additional key attributes in accordance with local policy and as negotiated and expressed in the protocol. In particular, the value of the element in the server's response message may be used as CKA_ID for K_TOKEN. The key K shall be destroyed after deriving K_TOKEN and K_MAC. 2. The MAC is verified in a reciprocal fashion as it was generated by the server. If use of the CKM_KIP_MAC mechanism has been negotiated, then in the call to C_VerifyInit, the hKey parameter in the CK_KIP_PARAMS structure shall be set to NULL_PTR, the pSeed parameter shall be set to NULL_PTR, and ulSeedLen shall be set to 0. The hKey parameter of C_VerifyInit shall refer to K_MAC. In the call to C_Verify, pData shall be set to the concatenation of the string ID_S and the octet-string representation of the provided value for I, and the ulDataLen parameter shall be set to the length of the concatenated string, pSignature to the MAC value received from the server, and ulSignatureLen to the length of the MAC. If the MAC does not verify or if the provided value of I is not larger than any stored value I' for the identified server ID_S the protocol session ends with a failure. The token shall be constructed to not "commit" to the new K_TOKEN or the new K_MAC unless the MAC verifies. If the verification succeeds, the token shall store the provided value of I as a new I' for ID_S. Nystroem & Machani Expires August 27, 2007 [Page 38] Internet-Draft 1- and 2-pass CT-KIP February 2007 3. If an authenticating MAC was received (required if K_TOKEN will replace an existing key on the token), it is verified in a similar vein but using the K_MAC existing before the protocol run. Again, if the MAC does not verify the protocol session ends with a failure, and the token must be constructed no to "commit" to the new K_TOKEN or the new K_MAC unless the MAC verifies. Nystroem & Machani Expires August 27, 2007 [Page 39] Internet-Draft 1- and 2-pass CT-KIP February 2007 Appendix E. About OTPS The One-Time Password Specifications are documents produced by RSA Laboratories in cooperation with secure systems developers for the purpose of simplifying integration and management of strong authentication technology into secure applications, and to enhance the user experience of this technology. Further development of the OTPS series will occur through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. As for our PKCS documents, results may also be submitted to standards forums. For more information, contact: OTPS Editor RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 USA otps-editor@rsasecurity.com http://www.rsasecurity.com/rsalabs/ Nystroem & Machani Expires August 27, 2007 [Page 40] Internet-Draft 1- and 2-pass CT-KIP February 2007 Authors' Addresses Magnus Nystroem RSA, The Security Division of EMC Email: magnus@rsasecurity.com Salah Machani Diversinet Corp. Email: smachani@diversinet.com Nystroem & Machani Expires August 27, 2007 [Page 41] Internet-Draft 1- and 2-pass CT-KIP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nystroem & Machani Expires August 27, 2007 [Page 42]