doc: Add RFC documents

1 files changed, 3027 insertions, 0 deletions

diff --git a/doc/rfc/rfc4758.txt b/doc/rfc/rfc4758.txt
new file mode 100644
index 0000000..05e8250
--- /dev/null
+++ b/doc/rfc/rfc4758.txt
@@ -0,0 +1,3027 @@
+
+
+
+
+
+
+Network Working Group                                        M. Nystroem
+Request for Comments: 4758                                  RSA Security
+Category: Informational                                    November 2006
+
+
+       Cryptographic Token Key Initialization Protocol (CT-KIP)
+                         Version 1.0 Revision 1
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2006).
+
+Abstract
+
+   This document constitutes Revision 1 of Cryptographic Token Key
+   Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories'
+   One-Time Password Specifications (OTPS) series.  The body of this
+   document, except for the intellectual property considerations
+   section, is taken from the CT-KIP Version 1.0 document, but comments
+   received during the IETF review are reflected; hence, the status of a
+   revised version.  As no "bits-on-the-wire" have changed, the protocol
+   specified herein is compatible with CT-KIP Version 1.0.
+
+   CT-KIP is a client-server protocol for initialization (and
+   configuration) of cryptographic tokens.  The protocol requires
+   neither private-key capabilities in the cryptographic tokens, nor an
+   established public-key infrastructure.  Provisioned (or generated)
+   secrets will only be available to the server and the cryptographic
+   token itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                      [Page 1]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Scope ......................................................4
+      1.2. Background .................................................4
+      1.3. Document Organization ......................................5
+   2. Acronyms and Notation ...........................................5
+      2.1. Acronyms ...................................................5
+      2.2. Notation ...................................................5
+   3. CT-KIP ..........................................................6
+      3.1. Overview ...................................................6
+      3.2. Entities ...................................................7
+      3.3. Principles of Operation ....................................7
+      3.4. The CT-KIP One-Way Pseudorandom Function, CT-KIP-PRF ......10
+           3.4.1. Introduction .......................................10
+           3.4.2. Declaration ........................................11
+      3.5. Generation of Cryptographic Keys for Tokens ...............11
+      3.6. Encryption of Pseudorandom Nonces Sent from the
+           CT-KIP Client .............................................12
+      3.7. CT-KIP Schema Basics ......................................13
+           3.7.1. Introduction .......................................13
+           3.7.2. General XML Schema Requirements ....................13
+           3.7.3. The AbstractRequestType Type .......................13
+           3.7.4. The AbstractResponseType type ......................14
+           3.7.5. The StatusCode Type ................................14
+           3.7.6. The IdentifierType Type ............................16
+           3.7.7. The NonceType Type .................................16
+           3.7.8. The ExtensionsType and the
+                  AbstractExtensionType Types ........................17
+      3.8. CT-KIP Messages ...........................................17
+           3.8.1. Introduction .......................................17
+           3.8.2. CT-KIP Initialization ..............................17
+           3.8.3. The CT-KIP Client's Initial PDU ....................18
+           3.8.4. The CT-KIP server's initial PDU ....................20
+           3.8.5. The CT-KIP Client's Second PDU .....................23
+           3.8.6. The CT-KIP Server's Final PDU ......................24
+      3.9. Protocol Extensions .......................................27
+           3.9.1. The ClientInfoType Type ............................27
+           3.9.2. The ServerInfoType Type ............................28
+           3.9.3. The OTPKeyConfigurationDataType Type ...............28
+   4. Protocol Bindings ..............................................29
+      4.1. General Requirement .......................................29
+      4.2. HTTP/1.1 binding for CT-KIP ...............................29
+           4.2.1. Introduction .......................................29
+           4.2.2. Identification of CT-KIP Messages ..................29
+           4.2.3. HTTP Headers .......................................29
+           4.2.4. HTTP Operations ....................................30
+           4.2.5. HTTP Status Codes ..................................30
+
+
+
+Nystroem                     Informational                      [Page 2]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+           4.2.6. HTTP Authentication ................................31
+           4.2.7. Initialization of CT-KIP ...........................31
+           4.2.8. Example Messages ...................................31
+   5. Security considerations ........................................32
+      5.1. General ...................................................32
+      5.2. Active Attacks ............................................32
+           5.2.1. Introduction .......................................32
+           5.2.2. Message Modifications ..............................32
+           5.2.3. Message Deletion ...................................34
+           5.2.4. Message Insertion ..................................34
+           5.2.5. Message Replay .....................................34
+           5.2.6. Message Reordering .................................35
+           5.2.7. Man in the Middle ..................................35
+      5.3. Passive Attacks ...........................................35
+      5.4. Cryptographic Attacks .....................................35
+      5.5. Attacks on the Interaction between CT-KIP and User
+           Authentication ............................................36
+   6. Intellectual Property Considerations ...........................36
+   7. References .....................................................37
+      7.1. Normative References ......................................37
+      7.2. Informative References ....................................37
+   Appendix A. CT-KIP Schema .........................................39
+   Appendix B. Examples of CT-KIP Messages ...........................46
+      B.1. Introduction ..............................................46
+      B.2. Example of a CT-KIP Initialization (Trigger) Message ......46
+      B.3. Example of a <ClientHello> Message ........................46
+      B.4. Example of a <ServerHello> Message ........................47
+      B.5. Example of a <ClientNonce> Message ........................47
+      B.6. Example of a <ServerFinished> Message .....................48
+   Appendix C. Integration with PKCS #11 .............................48
+   Appendix D. Example CT-KIP-PRF Realizations .......................48
+      D.1. Introduction ..............................................48
+      D.2. CT-KIP-PRF-AES ............................................48
+           D.2.1. Identification .....................................48
+           D.2.2. Definition .........................................49
+           D.2.3. Example ............................................50
+      D.3. CT-KIP-PRF-SHA256 .........................................50
+           D.3.1. Identification .....................................50
+           D.3.2. Definition .........................................51
+           D.3.3. Example ............................................52
+   Appendix E. About OTPS ............................................53
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                      [Page 3]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+1.  Introduction
+
+   Note: This document is Revision 1 of CT-KIP Version 1.0 [12] from RSA
+   Laboratories' OTPS series.
+
+1.1.  Scope
+
+   This document describes a client-server protocol for initialization
+   (and configuration) of cryptographic tokens.  The protocol requires
+   neither private-key capabilities in the cryptographic tokens, nor an
+   established public-key infrastructure.
+
+   The objectives of this protocol are:
+
+   o  To provide a secure method of initializing cryptographic tokens
+      with secret keys without exposing generated, secret material to
+      any other entities than the server and the cryptographic token
+      itself,
+
+   o  To avoid, as much as possible, any impact on existing
+      cryptographic token manufacturing processes,
+
+   o  To provide a solution that is easy to administer and scales well.
+
+   The mechanism is intended for general use within computer and
+   communications systems employing connected cryptographic tokens (or
+   software emulations thereof).
+
+1.2.  Background
+
+   A cryptographic token may be a handheld hardware device, a hardware
+   device connected to a personal computer through an electronic
+   interface such as USB, or a software module resident on a personal
+   computer, which offers cryptographic functionality that may be used,
+   e.g., to authenticate a user towards some service.  Increasingly,
+   these tokens work in a connected fashion, enabling their programmatic
+   initialization as well as programmatic retrieval of their output
+   values.  This document intends to meet the need for an open and
+   interoperable mechanism to programmatically initialize and configure
+   connected cryptographic tokens.  A companion document entitled "A
+   PKCS #11 Mechanism for the Cryptographic Token Key Initialization
+   Protocol" [2] describes an application-programming interface suitable
+   for use with this mechanism.
+
+
+
+
+
+
+
+
+Nystroem                     Informational                      [Page 4]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+1.3.  Document Organization
+
+   The organization of this document is as follows:
+
+   o  Section 1 is an introduction.
+
+   o  Section 2 defines some notation used in this document.
+
+   o  Section 3 defines the protocol mechanism in detail.
+
+   o  Section 4 defines a binding of the protocol to transports.
+
+   o  Section 5 provides security considerations.
+
+   o  Appendix A defines the XML schema for the protocol mechanism,
+      Appendix B gives example messages, and Appendix C discusses
+      integration with PKCS #11 [3].
+
+   o  Appendix D provides example realizations of an abstract
+      pseudorandom function defined in Section 3.
+
+   o  Appendix E provides general information about the One-Time
+      Password Specifications.
+
+2.  Acronyms and Notation
+
+2.1.  Acronyms
+
+   MAC      Message Authentication Code
+
+   PDU      Protocol Data Unit
+
+   PRF      Pseudo-Random Function
+
+   CT-KIP   Cryptographic Token Key Initialization Protocol (the
+            protocol mechanism described herein)
+
+2.2.  Notation
+
+   ||       String concatenation
+
+   [x]      Optional element x
+
+   A ^ B    Exclusive-or operation on strings A and B (A and B of equal
+            length)
+
+   K_AUTH   Secret key used for authentication purposes
+
+
+
+
+Nystroem                     Informational                      [Page 5]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   K_TOKEN  Secret key used for token computations, generated in CT-KIP
+
+   K_SERVER Public key of CT-KIP server
+
+   K_SHARED Secret key shared between the cryptographic token and the
+            CT-KIP server
+
+   K        Key used to encrypt R_C (either K_SERVER or K_SHARED)
+
+   R        Pseudorandom value chosen by the cryptographic token and
+            used for MAC computations
+
+   R_C      Pseudorandom value chosen by the cryptographic token
+
+   R_S      Pseudorandom value chosen by the CT-KIP server
+
+   The following typographical convention is used in the body of the
+   text: <XMLElement>.
+
+3.  CT-KIP
+
+3.1.  Overview
+
+   The CT-KIP is a client-server protocol for the secure initialization
+   of cryptographic tokens.  The protocol is meant to provide high
+   assurance for both the server and the client (cryptographic token)
+   that generated keys have been correctly and randomly generated and
+   not exposed to other entities.  The protocol does not require the
+   existence of a public-key infrastructure.
+
+   +---------------+                            +---------------+
+   |               |                            |               |
+   | CT-KIP client |                            | CT-KIP server |
+   |               |                            |               |
+   +---------------+                            +---------------+
+           |                                            |
+           |        [ <---- CT-KIP trigger ---- ]       |
+           |                                            |
+           |        ------- Client Hello ------->       |
+           |                                            |
+           |        <------ Server Hello --------       |
+           |                                            |
+           |        ------- Client Nonce ------->       |
+           |                                            |
+           |        <----- Server Finished ------       |
+
+   Figure 1: The 4-pass CT-KIP protocol (with optional preceding
+   trigger)
+
+
+
+Nystroem                     Informational                      [Page 6]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+3.2.  Entities
+
+   In principle, the protocol involves a CT-KIP client and a CT-KIP
+   server.
+
+   It is assumed that a desktop/laptop or a wireless device (e.g., a
+   mobile phone or a PDA) will host an application communicating with
+   the CT-KIP server as well as the cryptographic token, and
+   collectively, the cryptographic token and the communicating
+   application form the CT-KIP client.  When there is a need to point
+   out if an action is to be performed by the communicating application
+   or by the token the text will make this explicit.
+
+   The manner in which the communicating application will transfer CT-
+   KIP protocol elements to and from the cryptographic token is
+   transparent to the CT-KIP server.  One method for this transfer is
+   described in [2].
+
+3.3.  Principles of Operation
+
+   To initiate a CT-KIP session, a user may use a browser to connect to
+   a web server running on some host.  The user may then identify (and
+   authenticate) herself (through some means that essentially are out of
+   scope for this document) and possibly indicate how the CT-KIP client
+   shall contact the CT-KIP server.  There are also other alternatives
+   for CT-KIP session initiation, such as the CT-KIP client being pre-
+   configured to contact a certain CT-KIP server, or the user being
+   informed out-of-band about the location of the CT-KIP server.  In any
+   event, once the location of the CT-KIP server is known, the CT-KIP
+   client and the CT-KIP server engage in a 4-pass protocol in which:
+
+   a.  The CT-KIP client provides information to the CT-KIP server about
+       the cryptographic token's identity, supported CT-KIP versions,
+       cryptographic algorithms supported by the token and for which
+       keys may be generated using this protocol, and encryption and MAC
+       algorithms supported by the cryptographic token for the purposes
+       of this protocol.
+
+   b.  Based on this information, the CT-KIP server provides a random
+       nonce, R_S, to the CT-KIP client, along with information about
+       the type of key to generate, the encryption algorithm chosen to
+       protect sensitive data sent in the protocol.  In addition, it
+       provides either information about a shared secret key to use for
+       encrypting the cryptographic token's random nonce (see below), or
+       its own public key.  The length of the nonce R_S may depend on
+       the selected key type.
+
+
+
+
+
+Nystroem                     Informational                      [Page 7]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   c.  The cryptographic token generates a random nonce R_C and encrypts
+       it using the selected encryption algorithm and with a key K that
+       is either the CT-KIP server's public key K_SERVER, or a shared
+       secret key K_SHARED as indicated by the CT-KIP server.  The
+       length of the nonce R_C may depend on the selected key type.  The
+       CT-KIP client then sends the encrypted random nonce to the CT-KIP
+       server.  The token also calculates a cryptographic key K_TOKEN of
+       the selected type from the combination of the two random nonces
+       R_S and R_C, the encryption key K, and possibly some other data,
+       using the CT-KIP-PRF function defined herein.
+
+   d.  The CT-KIP server decrypts R_C, calculates K_TOKEN from the
+       combination of the two random nonces R_S and R_C, the encryption
+       key K, and possibly some other data, using the CT-KIP-PRF
+       function defined herein.  The server then associates K_TOKEN with
+       the cryptographic token in a server-side data store.  The intent
+       is that the data store later on will be used by some service that
+       needs to verify or decrypt data produced by the cryptographic
+       token and the key.
+
+   e.  Once the association has been made, the CT-KIP server sends a
+       confirmation message to the CT-KIP client.  The confirmation
+       message includes an identifier for the generated key and may also
+       contain additional configuration information, e.g., the identity
+       of the CT-KIP server.
+
+   f.  Upon receipt of the CT-KIP server's confirmation message, the
+       cryptographic token associates the provided key identifier with
+       the generated key K_TOKEN, and stores the provided configuration
+       data, if any.
+
+   Note: Conceptually, although R_C is one pseudorandom string, it may
+   be viewed as consisting of two components, R_C1 and R_C2, where R_C1
+   is generated during the protocol run, and R_C2 can be generated at
+   the cryptographic token manufacturing time and stored in the
+   cryptographic token.  In that case, the latter string, R_C2, should
+   be unique for each cryptographic token for a given manufacturer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                      [Page 8]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   +----------------------+    +-------+     +----------------------+
+   |    +------------+    |    |       |     |                      |
+   |    | Server key |    |    |       |     |                      |
+   | +<-|  Public    |------>------------->-------------+---------+ |
+   | |  |  Private   |    |    |       |     |          |         | |
+   | |  +------------+    |    |       |     |          |         | |
+   | |        |           |    |       |     |          |         | |
+   | V        V           |    |       |     |          V         V |
+   | |   +---------+      |    |       |     |        +---------+ | |
+   | |   | Decrypt |<-------<-------------<-----------| Encrypt | | |
+   | |   +---------+      |    |       |     |        +---------+ | |
+   | |      |  +--------+ |    |       |     |            ^       | |
+   | |      |  | Server | |    |       |     |            |       | |
+   | |      |  | Random |--->------------->------+  +----------+  | |
+   | |      |  +--------+ |    |       |     |   |  | Client   |  | |
+   | |      |      |      |    |       |     |   |  | Random   |  | |
+   | |      |      |      |    |       |     |   |  +----------+  | |
+   | |      |      |      |    |       |     |   |        |       | |
+   | |      V      V      |    |       |     |   V        V       | |
+   | |   +------------+   |    |       |     | +------------+     | |
+   | +-->| CT-KIP PRF |   |    |       |     | | CT-KIP PRF |<----+ |
+   |     +------------+   |    |       |     | +------------+       |
+   |           |          |    |       |     |       |              |
+   |           V          |    |       |     |       V              |
+   |       +-------+      |    |       |     |   +-------+          |
+   |       |  Key  |      |    |       |     |   |  Key  |          |
+   |       +-------+      |    |       |     |   +-------+          |
+   |       +-------+      |    |       |     |   +-------+          |
+   |       |Key Id |-------->------------->------|Key Id |          |
+   |       +-------+      |    |       |     |   +-------+          |
+   +----------------------+    +-------+     +----------------------+
+        CT-KIP Server        CT-KIP Client     CT-KIP Client (Token)
+                               (PC Host)
+
+   Figure 2: Principal data flow for CT-KIP key generation - using
+   public server key
+
+   The inclusion of the two random nonces R_S and R_C in the key
+   generation provides assurance to both sides (the token and the CT-KIP
+   server) that they have contributed to the key's randomness and that
+   the key is unique.  The inclusion of the encryption key K ensures
+   that no man-in-the-middle may be present, or else the cryptographic
+   token will end up with a key different from the one stored by the
+   legitimate CT-KIP server.
+
+   Note: A man-in-the middle (in the form of corrupt client software or
+   a mistakenly contacted server) may present his own public key to the
+   token.  This will enable the attacker to learn the client's version
+
+
+
+Nystroem                     Informational                      [Page 9]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   of K_TOKEN.  However, the attacker is not able to persuade the
+   legitimate server to derive the same value for K_TOKEN, since K_TOKEN
+   is a function of the public key involved, and the attacker's public
+   key must be different than the correct server's (or else the attacker
+   would not be able to decrypt the information received from the
+   client).  Therefore, once the attacker is no longer "in the middle",
+   the client and server will detect that they are "out of synch" when
+   they try to use their keys.  Therefore, in the case of encrypting R_C
+   with K_SERVER, it is important to verify that K_SERVER really is the
+   legitimate server's key.  One way to do this is to independently
+   validate a newly generated K_TOKEN against some validation service at
+   the server (e.g., by using a connection independent from the one used
+   for the key generation).
+
+   The CT-KIP server may couple an initial user authentication to the
+   CT-KIP execution in several ways to ensure that a generated K_TOKEN
+   ends up associated with the correct token and user.  One way is to
+   provide a one-time value to the user or CT-KIP client after
+   successful user authentication and require this value to be used when
+   contacting the CT-KIP service (in effect coupling the user
+   authentication with the subsequent CT-KIP protocol run).  This value
+   could, for example, be placed in a <TriggerNonce> element of the CT-
+   KIP initialization trigger (if triggers are used; see Section 4.2.7).
+   Another way is for the user to provide a token identifier which will
+   later be used in the CT-KIP protocol to the server during the
+   authentication phase.  The server may then include this token
+   identifier in the CT-KIP initialization trigger.  It is also
+   legitimate for a CT-KIP client to initiate a CT-KIP protocol run
+   without having received an initialization message from a server, but
+   in this case any provided token identifier shall not be accepted by
+   the server unless the server has access to a unique token key for the
+   identified token and that key will be used in the protocol.  Whatever
+   the method, the CT-KIP server must ensure that a generated key is
+   associated with the correct token and, if applicable, the correct
+   user.  For a further discussion of this and threats related to man-
+   in-the-middle attacks in this context, see Section 5.5.
+
+3.4.  The CT-KIP One-Way Pseudorandom Function, CT-KIP-PRF
+
+3.4.1.  Introduction
+
+   The general requirements on CT-KIP-PRF are the same as on keyed hash
+   functions: It shall take an arbitrary length input, and be one-way
+   and collision-free (for a definition of these terms, see, e.g., [4]).
+   Further, the CT-KIP-PRF function shall be capable of generating a
+   variable-length output, and its output shall be unpredictable even if
+   other outputs for the same key are known.
+
+
+
+
+Nystroem                     Informational                     [Page 10]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   It is assumed that any realization of CT-KIP-PRF takes three input
+   parameters: A secret key k, some combination of variable data, and
+   the desired length of the output.  Examples of the variable data
+   include, but are not limited to, a current token counter value, the
+   current token time, and a challenge.  The combination of variable
+   data can, without loss of generalization, be considered as a salt
+   value (see PKCS #5 Version 2.0 [5], Section 4), and this
+   characterization of CT-KIP-PRF should fit all actual PRF algorithms
+   implemented by tokens.  From the point of view of this specification,
+   CT-KIP-PRF is a "black-box" function that, given the inputs,
+   generates a pseudorandom value.
+
+   Separate specifications may define the implementation of CT-KIP-PRF
+   for various types of cryptographic tokens.  Appendix D contains two
+   example realizations of CT-KIP-PRF.
+
+3.4.2.  Declaration
+
+   CT-KIP-PRF (k, s, dsLen)
+
+   Input:
+
+   k     secret key in octet string format
+
+   s     octet string of varying length consisting of variable data
+         distinguishing the particular string being derived
+
+   dsLen desired length of the output
+
+   Output:
+
+   DS    pseudorandom string, dsLen-octets long
+
+   For the purposes of this document, the secret key k shall be 16
+   octets long.
+
+3.5.  Generation of Cryptographic Keys for Tokens
+
+   In CT-KIP, keys are generated using the CT-KIP-PRF function, a secret
+   random value R_C chosen by the CT-KIP client, a random value R_S
+   chosen by the CT-KIP server, and the key k used to encrypt R_C.  The
+   input parameter s of CT-KIP-PRF is set to the concatenation of the
+   (ASCII) string "Key generation", k, and R_S, and the input parameter
+   dsLen is set to the desired length of the key, K_TOKEN (the length of
+   K_TOKEN is given by the key's type):
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 11]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   dsLen = (desired length of K_TOKEN)
+
+   K_TOKEN = CT-KIP-PRF (R_C, "Key generation" || k || R_S, dsLen)
+
+   When computing K_TOKEN above, the output of CT-KIP-PRF may be subject
+   to an algorithm-dependent transform before being adopted as a key of
+   the selected type.  One example of this is the need for parity in DES
+   keys.
+
+3.6.  Encryption of Pseudorandom Nonces Sent from the CT-KIP Client
+
+   CT-KIP client random nonce(s) are either encrypted with the public
+   key provided by the CT-KIP server or by a shared secret key.  For
+   example, in the case of a public RSA key, an RSA encryption scheme
+   from PKCS #1 [6] may be used.
+
+   In the case of a shared secret key, to avoid dependence on other
+   algorithms, the CT-KIP client may use the CT-KIP-PRF function
+   described herein with the shared secret key K_SHARED as input
+   parameter k (in this case, K_SHARED should be used solely for this
+   purpose), the concatenation of the (ASCII) string "Encryption" and
+   the server's nonce R_S as input parameter s, and dsLen set to the
+   length of R_C:
+
+   dsLen = len(R_C)
+
+   DS = CT-KIP-PRF(K_SHARED, "Encryption" || R_S, dsLen)
+
+   This will produce a pseudorandom string DS of length equal to R_C.
+   Encryption of R_C may then be achieved by XOR-ing DS with R_C:
+
+   Enc-R_C = DS ^ R_C
+
+   The CT-KIP server will then perform the reverse operation to extract
+   R_C from Enc-R_C.
+
+   Note: It may appear that an attacker, who learns a previous value of
+   R_C, may be able to replay the corresponding R_S and, hence, learn a
+   new R_C as well.  However, this attack is mitigated by the
+   requirement for a server to show knowledge of K_AUTH (see below) in
+   order to successfully complete a key re-generation.
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 12]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+3.7.  CT-KIP Schema Basics
+
+3.7.1.  Introduction
+
+   Core parts of the XML schema for CT-KIP, found in Appendix A, are
+   explained in this section.  Specific protocol message elements are
+   defined in Section 3.8.  Examples can be found in Appendix B.
+
+   The XML format for CT-KIP messages have been designed to be
+   extensible.  However, it is possible that the use of extensions will
+   harm interoperability; therefore, any use of extensions should be
+   carefully considered.  For example, if a particular implementation
+   relies on the presence of a proprietary extension, then it may not be
+   able to interoperate with independent implementations that have no
+   knowledge of this extension.
+
+   XML types defined in this sub-section are not CT-KIP messages; rather
+   they provide building blocks that are used by CT-KIP messages.
+
+3.7.2.  General XML Schema Requirements
+
+   Some CT-KIP elements rely on the parties being able to compare
+   received values with stored values.  Unless otherwise noted, all
+   elements in this document that have the XML Schema "xs:string" type,
+   or a type derived from it, must be compared using an exact binary
+   comparison.  In particular, CT-KIP implementations must not depend on
+   case-insensitive string comparisons, normalization or trimming of
+   white space, or conversion of locale-specific formats such as
+   numbers.
+
+   Implementations that compare values that are represented using
+   different character encodings must use a comparison method that
+   returns the same result as converting both values to the Unicode
+   character encoding, Normalization Form C [1], and then performing an
+   exact binary comparison.
+
+   No collation or sorting order for attributes or element values is
+   defined.  Therefore, CT-KIP implementations must not depend on
+   specific sorting orders for values.
+
+3.7.3.  The AbstractRequestType Type
+
+   All CT-KIP requests are defined as extensions to the abstract
+   AbstractRequestType type.  The elements of the AbstractRequestType,
+   therefore, apply to all CT-KIP requests.  All CT-KIP requests must
+   contain a Version attribute.  For this version of this specification,
+   Version shall be set to "1.0".
+
+
+
+
+Nystroem                     Informational                     [Page 13]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   <xs:complexType name="AbstractRequestType" abstract="true">
+     <xs:attribute name="Version" type="VersionType"
+      use="required"/>
+   </xs:complexType>
+
+3.7.4.  The AbstractResponseType type
+
+   All CT-KIP responses are defined as extensions to the abstract
+   AbstractResponseType type.  The elements of the AbstractResponseType,
+   therefore, apply to all CT-KIP responses.  All CT-KIP responses
+   contain a Version attribute indicating the version that was used.  A
+   Status attribute, which indicates whether the preceding request was
+   successful or not must also be present.  Finally, all responses may
+   contain a SessionID attribute identifying the particular CT-KIP
+   session.  The SessionID attribute needs only be present if more than
+   one roundtrip is required for a successful protocol run (this is the
+   case with the protocol version described herein).
+
+   <xs:complexType name="AbstractResponseType" abstract="true">
+     <xs:attribute name="Version" type="VersionType" use="required"/>
+     <xs:attribute name="SessionID" type="IdentifierType"/>
+     <xs:attribute name="Status" type="StatusCode" use="required"/>
+   </xs:complexType>
+
+3.7.5.  The StatusCode Type
+
+   The StatusCode type enumerates all possible return codes:
+
+   <xs:simpleType name="StatusCode">
+     <xs:restriction base="xs:string">
+       <xs:enumeration value="Continue"/>
+       <xs:enumeration value="Success"/>
+       <xs:enumeration value="Abort"/>
+       <xs:enumeration value="AccessDenied"/>
+       <xs:enumeration value="MalformedRequest"/>
+       <xs:enumeration value="UnknownRequest"/>
+       <xs:enumeration value="UnknownCriticalExtension"/>
+       <xs:enumeration value="UnsupportedVersion"/>
+       <xs:enumeration value="NoSupportedKeyTypes"/>
+       <xs:enumeration value="NoSupportedEncryptionAlgorithms"/>
+       <xs:enumeration value="NoSupportedMACAlgorithms"/>
+       <xs:enumeration value="InitializationFailed"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+   Upon transmission or receipt of a message for which the Status
+   attribute's value is not "Success" or "Continue", the default
+   behavior, unless explicitly stated otherwise below, is that both the
+
+
+
+Nystroem                     Informational                     [Page 14]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   CT-KIP server and the CT-KIP client shall immediately terminate the
+   CT-KIP session.  CT-KIP servers and CT-KIP clients must delete any
+   secret values generated as a result of failed runs of the CT-KIP
+   protocol.  Session identifiers may be retained from successful or
+   failed protocol runs for replay detection purposes, but such retained
+   identifiers shall not be reused for subsequent runs of the protocol.
+
+   When possible, the CT-KIP client should present an appropriate error
+   message to the user.
+
+   These status codes are valid in all CT-KIP-Response messages unless
+   explicitly stated otherwise.
+
+   o  "Continue" indicates that the CT-KIP server is ready for a
+      subsequent request from the CT-KIP client.  It cannot be sent in
+      the server's final message.
+
+   o  "Success" indicates successful completion of the CT-KIP session.
+      It can only be sent in the server's final message.
+
+   o  "Abort" indicates that the CT-KIP server rejected the CT-KIP
+      client's request for unspecified reasons.
+
+   o  "AccessDenied" indicates that the CT-KIP client is not authorized
+      to contact this CT-KIP server.
+
+   o  "MalformedRequest" indicates that the CT-KIP server failed to
+      parse the CT-KIP client's request.
+
+   o  "UnknownRequest" indicates that the CT-KIP client made a request
+      that is unknown to the CT-KIP server.
+
+   o  "UnknownCriticalExtension" indicates that a critical CT-KIP
+      extension (see below) used by the CT-KIP client was not supported
+      or recognized by the CT-KIP server.
+
+   o  "UnsupportedVersion" indicates that the CT-KIP client used a CT-
+      KIP protocol version not supported by the CT-KIP server.  This
+      error is only valid in the CT-KIP server's first response message.
+
+   o  "NoSupportedKeyTypes" indicates that the CT-KIP client only
+      suggested key types that are not supported by the CT-KIP server.
+      This error is only valid in the CT-KIP server's first response
+      message.  Note that the error will only occur if the CT-KIP server
+      does not support any of the CT-KIP client's suggested key types.
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 15]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   o  "NoSupportedEncryptionAlgorithms" indicates that the CT-KIP client
+      only suggested encryption algorithms that are not supported by the
+      CT-KIP server.  This error is only valid in the CT-KIP server's
+      first response message.  Note that the error will only occur if
+      the CT-KIP server does not support any of the CT-KIP client's
+      suggested encryption algorithms.
+
+   o  "NoSupportedMACAlgorithms" indicates that the CT-KIP client only
+      suggested MAC algorithms that are not supported by the CT-KIP
+      server.  This error is only valid in the CT-KIP server's first
+      response message.  Note that the error will only occur if the CT-
+      KIP server does not support any of the CT-KIP client's suggested
+      MAC algorithms.
+
+   o  "InitializationFailed" indicates that the CT-KIP server could not
+      generate a valid key given the provided data.  When this status
+      code is received, the CT-KIP client should try to restart CT-KIP,
+      as it is possible that a new run will succeed.
+
+3.7.6.  The IdentifierType Type
+
+   The IdentifierType type is used to identify various CT-KIP elements,
+   such as sessions, users, and services.  Identifiers must not be
+   longer than 128 octets.
+
+   <xs:simpleType name="IdentifierType">
+     <xs:restriction base="xs:string">
+       <xs:maxLength value="128"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+3.7.7.  The NonceType Type
+
+   The NonceType type is used to carry pseudorandom values in CT-KIP
+   messages.  A nonce, as the name implies, must be used only once.  For
+   each CT-KIP message that requires a nonce element to be sent, a fresh
+   nonce shall be generated each time.  Nonce values must be at least 16
+   octets long.
+
+   <xs:simpleType name="NonceType">
+     <xs:restriction base="xs:base64Binary">
+       <xs:minLength value="16"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 16]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+3.7.8.  The ExtensionsType and the AbstractExtensionType Types
+
+   The ExtensionsType type is a list of type-value pairs that define
+   optional CT-KIP features supported by a CT-KIP client or server.
+   Extensions may be sent with any CT-KIP message.  Please see the
+   description of individual CT-KIP messages in Section 3.8 of this
+   document for applicable extensions.  Unless an extension is marked as
+   Critical, a receiving party need not be able to interpret it.  A
+   receiving party is always free to disregard any (non-critical)
+   extensions.
+
+   <xs:complexType name="AbstractExtensionsType">
+     <xs:sequence maxOccurs="unbounded">
+       <xs:element name="Extension" type="AbstractExtensionType"/>
+     </xs:sequence>
+   </xs:complexType>
+
+   <xs:complexType name="AbstractExtensionType" abstract="true">
+     <xs:attribute name="Critical" type="xs:boolean"/>
+   </xs:complexType>
+
+3.8.  CT-KIP Messages
+
+3.8.1.  Introduction
+
+   In this section, CT-KIP messages, including their parameters,
+   encodings and semantics are defined.
+
+3.8.2.  CT-KIP Initialization
+
+   The CT-KIP server may initialize the CT-KIP protocol by sending a
+   <CT-KIPTrigger> message.  This message may, e.g., be sent in response
+   to a user requesting token initialization in a browsing session.
+
+   <xs:complexType name="InitializationTriggerType">
+     <xs:sequence>
+       <xs:element name="TokenID" type="xs:base64Binary" minOccurs="0"/>
+       <xs:element name="KeyID" type="xs:base64Binary" minOccurs="0"/>
+       <xs:element name="TokenPlatformInfo"
+         type="TokenPlatformInfoType" minOccurs="0"/>
+       <xs:element name="TriggerNonce" type="NonceType"/>
+       <xs:element name="CT-KIPURL" type="xs:anyURI" minOccurs="0"/>
+       <xs:any namespace="##other" processContents="strict"
+         minOccurs="0"/>
+     </xs:sequence>
+     <xs:attribute name="id" type="xs:ID"/>
+   </xs:complexType>
+
+
+
+
+Nystroem                     Informational                     [Page 17]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   <xs:element name="CT-KIPTrigger" type="CT-KIPTriggerType"/>
+
+   <xs:complexType name="CT-KIPTriggerType">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+          Message used to trigger the device to initiate a
+          CT-KIP run.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:sequence>
+       <xs:choice>
+         <xs:element name="InitializationTrigger"
+           type="InitializationTriggerType"/>
+         <xs:any nameSpace="##other" processContents="strict"/>
+       </xs:choice>
+     </xs:sequence>
+     <xs:attribute name="Version" type="ct-kip:VersionType"/>
+   </xs:complexType>
+
+   The <CT-KIPTrigger> element is intended for the CT-KIP client and may
+   inform the CT-KIP client about the identifier for the token that is
+   to be initialized, and, optionally, of the identifier for the key on
+   that token.  The latter would apply when re-seeding.  The trigger
+   always contains a nonce to allow the server to couple the trigger
+   with a later CT-KIP <ClientHello> request.  Finally, the trigger may
+   contain a URL to use when contacting the CT-KIP server.  The <xs:any>
+   elements are for future extensibility.  Any provided <TokenID> or
+   <KeyID> values shall be used by the CT-KIP client in the subsequent
+   <ClientHello> request.  The optional <TokenPlatformInfo> element
+   informs the CT-KIP client about the characteristics of the intended
+   token platform, and applies in the public-key variant of CT-KIP in
+   situations when the client potentially needs to decide which one of
+   several tokens to initialize.
+
+   The Version attribute shall be set to "1.0" for this version of CT-
+   KIP.
+
+3.8.3.  The CT-KIP Client's Initial PDU
+
+   This message is the initial message sent from the CT-KIP client to
+   the CT-KIP server.
+
+   <xs:element name="ClientHello" type="ClientHelloPDU"/>
+
+   <xs:complexType name="ClientHelloPDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+          Message sent from CT-KIP client to CT-KIP server to
+
+
+
+Nystroem                     Informational                     [Page 18]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+          initiate a CT-KIP session.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractRequestType">
+         <xs:sequence>
+           <xs:element name="TokenID"
+             type="xs:base64Binary" minOccurs="0"/>
+           <xs:element name="KeyID"
+             type="xs:base64Binary" minOccurs="0"/>
+           <xs:element name="ClientNonce"
+             type="NonceType" minOccurs="0"/>
+           <xs:element name= "TriggerNonce"
+             type="NonceType" minOccurs="0"/>
+           <xs:element name="SupportedKeyTypes"
+             type="AlgorithmsType"/>
+           <xs:element name="SupportedEncryptionAlgorithms"
+             type="AlgorithmsType"/>
+           <xs:element name="SupportedMACAlgorithms"
+             type="AlgorithmsType"/>
+           <xs:element name="Extensions"
+             type="ExtensionsType" minOccurs="0"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   The components of this message have the following meaning:
+
+   o  Version: (attribute inherited from the AbstractRequestType type)
+      The highest version of this protocol the client supports.  Only
+      version one ("1.0") is currently specified.
+
+   o  <TokenID>: An identifier for the cryptographic token (allows the
+      server to find, e.g., a correct shared secret for MACing
+      purposes).  The identifier shall only be present if such shared
+      secrets exist or if the identifier was provided by the server in a
+      <CT-KIPTrigger> element (see Section 4.2.7 below).  In the latter
+      case, it must have the same value as the identifier provided in
+      that element.
+
+   o  <KeyID>: An identifier for the key that will be overwritten if the
+      protocol run is successful.  The identifier shall only be present
+      if the key exists or was provided by the server in a
+      <CT-KIPTrigger> element (see Section 4.2.7 below).  In the latter
+      case, it must have the same value as the identifier provided in
+      that element.
+
+
+
+
+Nystroem                     Informational                     [Page 19]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   o  <ClientNonce>: This is the nonce R, which, when present, shall be
+      used by the server when calculating MAC values (see below).  It is
+      recommended that clients include this element whenever the <KeyID>
+      element is present.
+
+   o  <TriggerNonce>: This optional element shall be present if and only
+      if the CT-KIP run was initialized with a <CT-KIPTrigger> message
+      (see Section 4.2.7 below), and shall, in that case, have the same
+      value as the <TriggerNonce> child of that message.  A server using
+      nonces in this way must verify that the nonce is valid and that
+      any token or key identifier values provided in the <CT-KIPTrigger>
+      message match the corresponding identifier values in the
+      <ClientHello> message.
+
+   o  <SupportedKeyTypes>: A sequence of URIs indicating the key types
+      for which the token is willing to generate keys through CT-KIP.
+
+   o  <SupportedEncryptionAlgorithms>: A sequence of URIs indicating the
+      encryption algorithms supported by the cryptographic token for the
+      purposes of CT-KIP.  The CT-KIP client may indicate the same
+      algorithm both as a supported key type and as an encryption
+      algorithm.
+
+   o  <SupportedMACAlgorithms>: A sequence of URIs indicating the MAC
+      algorithms supported by the cryptographic token for the purposes
+      of CT-KIP.  The CT-KIP client may indicate the same algorithm both
+      as an encryption algorithm and as a MAC algorithm (e.g., http://
+      www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
+      ct-kip#ct-kip-prf-aes defined in Appendix D)
+
+   o  <Extensions>: A sequence of extensions.  One extension is defined
+      for this message in this version of CT-KIP: the ClientInfoType
+      (see Section 3.9.1).
+
+3.8.4.  The CT-KIP server's initial PDU
+
+   This message is the first message sent from the CT-KIP server to the
+   CT-KIP client (assuming a trigger message has not been sent to
+   initiate the protocol, in which case, this message is the second
+   message sent from the CT-KIP server to the CT-KIP client).  It is
+   sent upon reception of a <ClientHello> message.
+
+   <xs:element name="ServerHello" type="ServerHelloPDU"/>
+
+   <xs:complexType name="ServerHelloPDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Message sent from CT-KIP server to CT-KIP
+
+
+
+Nystroem                     Informational                     [Page 20]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+         client in response to a received ClientHello
+         PDU.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractResponseType">
+         <xs:sequence minOccurs="0">
+           <xs:element name="KeyType"
+             type="AlgorithmType"/>
+           <xs:element name="EncryptionAlgorithm"
+             type="AlgorithmType"/>
+           <xs:element name="MacAlgorithm"
+             type="AlgorithmType"/>
+           <xs:element name="EncryptionKey"
+             type="ds:KeyInfoType"/>
+           <xs:element name="Payload"
+             type="PayloadType"/>
+           <xs:element name="Extensions"
+             type="ExtensionsType" minOccurs="0"/>
+           <xs:element name="Mac" type="MacType"
+             minOccurs="0"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+
+   <xs:complexType name="PayloadType">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Currently, only the nonce is defined.  In future versions,
+         other payloads may be defined, e.g., for one-roundtrip
+         initialization protocols.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:choice>
+       <xs:element name="Nonce" type="NonceType"/>
+       <any namespace="##other" processContents="strict"/>
+     </xs:choice>
+   </xs:complexType>
+
+   <xs:complexType name="MacType">
+     <xs:simpleContent>
+       <xs:extension base="xs:base64Binary">
+         <xs:attribute name="MacAlgorithm" type="xs:anyURI"/>
+       </xs:extension>
+     </xs:simpleContent>
+   </xs:complexType>
+
+
+
+Nystroem                     Informational                     [Page 21]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   The components of this message have the following meaning:
+
+   o  Version: (attribute inherited from the AbstractResponseType type)
+      The version selected by the CT-KIP server.  May be lower than the
+      version indicated by the CT-KIP client, in which case, local
+      policy at the client will determine whether or not to continue the
+      session.
+
+   o  SessionID: (attribute inherited from the AbstractResponseType
+      type) An identifier for this session.
+
+   o  Status: (attribute inherited from the abstract
+      AbstractResponseType type) Return code for the <ClientHello>.  If
+      Status is not "Continue", only the Status and Version attributes
+      will be present; otherwise, all the other elements must be present
+      as well.
+
+   o  <KeyType>: The type of the key to be generated.
+
+   o  <EncryptionAlgorithm>: The encryption algorithm to use when
+      protecting R_C.
+
+   o  <MacAlgorithm>: The MAC algorithm to be used by the CT-KIP server.
+
+   o  <EncryptionKey>: Information about the key to use when encrypting
+      R_C.  It will either be the server's public key (the <ds:KeyValue>
+      alternative of ds:KeyInfoType) or an identifier for a shared
+      secret key (the <ds:KeyName> alternative of ds:KeyInfoType).
+
+   o  <Payload>: The actual payload.  For this version of the protocol,
+      only one payload is defined: the pseudorandom string R_S.
+
+   o  <Extensions>: A list of server extensions.  Two extensions are
+      defined for this message in this version of CT-KIP: the
+      ClientInfoType and the ServerInfoType (see Section 3.9).
+
+   o  <Mac>: The MAC must be present if the CT-KIP run will result in
+      the replacement of an existing token key with a new one (i.e., if
+      the <KeyID> element was present in the <ClientHello> message).  In
+      this case, the CT-KIP server must prove to the cryptographic token
+      that it is authorized to replace it.  The MAC value shall be
+      computed on the (ASCII) string "MAC 1 computation", the client's
+      nonce R (if sent), and the server's nonce R_S using an
+      authentication key K_AUTH that should be a special authentication
+      key used only for this purpose but may be the current K_TOKEN.
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 22]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+      The MAC value may be computed by using the CT-KIP-PRF function of
+      Section 3.4, in which case the input parameter s shall be set to
+      the concatenation of the (ASCII) string "MAC 1 computation", R (if
+      sent by the client), and R_S, and k shall be set to K_AUTH.  The
+      input parameter dsLen shall be set to the length of R_S:
+
+      dsLen = len(R_S)
+
+      MAC = CT-KIP-PRF (K_AUTH, "MAC 1 computation" || [R ||] R_S,
+      dsLen)
+
+      The CT-KIP client must verify the MAC if the successful execution
+      of the protocol will result in the replacement of an existing
+      token key with a newly generated one.  The CT-KIP client must
+      terminate the CT-KIP session if the MAC does not verify, and must
+      delete any nonces, keys, and/or secrets associated with the failed
+      run of the CT-KIP protocol.
+
+      The MacType's MacAlgorithm attribute shall, when present, identify
+      the negotiated MAC algorithm.
+
+3.8.5.  The CT-KIP Client's Second PDU
+
+   This message contains the nonce chosen by the cryptographic token,
+   R_C, encrypted by the specified encryption key and encryption
+   algorithm.
+
+   <xs:element name="ClientNonce" type="ClientNoncePDU"/>
+
+   <xs:complexType name="ClientNoncePDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Second message sent from CT-KIP client to
+         CT-KIP server in a CT-KIP session.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractRequestType">
+         <xs:sequence>
+           <xs:element name="EncryptedNonce"
+             type="xs:base64Binary"/>
+           <xs:element name="Extensions"
+             type="ExtensionsType" minOccurs="0"/>
+         </xs:sequence>
+         <xs:attribute name="SessionID" type="IdentifierType"
+           use="required"/>
+       </xs:extension>
+     </xs:complexContent>
+
+
+
+Nystroem                     Informational                     [Page 23]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   </xs:complexType>
+
+   The components of this message have the following meaning:
+
+   o  Version: (inherited from the AbstractRequestType type) Shall be
+      the same version as in the <ServerHello> message.
+
+   o  SessionID: Shall have the same value as the SessionID attribute in
+      the received <ServerHello> message.
+
+   o  <EncryptedNonce>: The nonce generated and encrypted by the token.
+      The encryption shall be made using the selected encryption
+      algorithm and identified key, and as specified in Section 3.4.
+
+   o  <Extensions>: A list of extensions.  Two extensions are defined
+      for this message in this version of CT-KIP: the ClientInfoType and
+      the ServerInfoType (see Section 3.9).
+
+3.8.6.  The CT-KIP Server's Final PDU
+
+   This message is the last message of a two roundtrip CT-KIP exchange.
+   The CT-KIP server sends this message to the CT-KIP client in response
+   to the <ClientNonce> message.
+
+   <xs:element name="ServerFinished" type="ServerFinishedPDU"/>
+
+   <xs:complexType name="ServerFinishedPDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Final message sent from CT-KIP server to
+         CT-KIP client in a CT-KIP session.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractResponseType">
+         <xs:sequence minOccurs="0">
+           <xs:element name="TokenID"
+             type="xs:base64Binary"/>
+           <xs:element name="KeyID"
+             type="xs:base64Binary"/>
+           <xs:element name="KeyExpiryDate"
+             type="xs:dateTime" minOccurs="0"/>
+           <xs:element name="ServiceID"
+             type="IdentifierType" minOccurs="0"/>
+           <xs:element name="ServiceLogo"
+             type="LogoType" minOccurs="0"/>
+           <xs:element name="UserID"
+             type="IdentifierType" minOccurs="0"/>
+
+
+
+Nystroem                     Informational                     [Page 24]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+           <xs:element name="Extensions"
+             type="ExtensionsType" minOccurs="0"/>
+           <xs:element name="Mac"
+             type="MacType"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   The components of this message have the following meaning:
+
+   o  Version: (inherited from the AbstractResponseType type) The CT-KIP
+      version used in this session.
+
+   o  SessionID: (inherited from the AbstractResponseType type) The
+      previously established identifier for this session.
+
+   o  Status: (inherited from the AbstractResponseType type) Return code
+      for the <ServerFinished> message.  If Status is not "Success",
+      only the Status, SessionID, and Version attributes will be present
+      (the presence of the SessionID attribute is dependent on the type
+      of reported error); otherwise, all the other elements must be
+      present as well.  In this latter case, the <ServerFinished>
+      message can be seen as a "Commit" message, instructing the
+      cryptographic token to store the generated key and associate the
+      given key identifier with this key.
+
+   o  <TokenID>: An identifier for the token carrying the generated key.
+      Must have the same value as the <TokenID> element of the
+      <ClientHello> message, if one was provided.  When assigned by the
+      CT-KIP server, the <TokenID> element shall be unique within the
+      domain of the CT-KIP server.
+
+   o  <KeyID>: An identifier for the newly generated key.  The
+      identifier shall be globally unique.  Must have the same value as
+      any key identifier provided by the CT-KIP client in the
+      <ClientHello> message.
+
+      The reason for requiring globally unique key identifiers is that
+      it avoids potential conflicts when associating key holders with
+      key identifiers.  One way of achieving global uniqueness with
+      reasonable certainty is to hash the combination of the issuer's
+      fully qualified domain name with an (issuer-specific) serial
+      number, assuming that each issuer makes sure their serial numbers
+      never repeat.
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 25]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+      CT-KIP clients must support key identifiers at least 64 octets
+      long.  CT-KIP servers should not generate key identifiers longer
+      than 64 octets.
+
+   o  <KeyExpiryDate>: This optional element provides the date and time
+      after which the generated key should be treated as expired and
+      invalid.
+
+   o  <ServiceID>: An optional identifier for the service that has
+      stored the generated key.  The cryptographic token may store this
+      identifier associated with the key in order to simplify later
+      lookups.  The identifier shall be a printable string.
+
+   o  <ServiceLogo>: This optional element provides a graphical logo
+      image for the service that can be displayed in user interfaces,
+      e.g., to help a user select a certain key.  The logo should
+      contain an image within the size range of 60 pixels wide by 45
+      pixels high, and 200 pixels wide by 150 pixels high.  The required
+      MimeType attribute of this type provides information about the
+      MIME type of the image.  This specification supports both the JPEG
+      and GIF image formats (with MIME types of "image/jpeg" and "image/
+      gif").
+
+   o  <UserID>: An optional identifier for the user associated with the
+      generated key in the authentication service.  The cryptographic
+      token may store this identifier associated with the generated key
+      in order to enhance later user experiences.  The identifier shall
+      be a printable string.
+
+   o  <Extensions>: A list of extensions chosen by the CT-KIP server.
+      For this message, this version of CT-KIP defines two extensions,
+      the OTPKeyConfigurationDataType and the ClientInfoType (see
+      Section 3.9).
+
+   o  <Mac>: To avoid a false "Commit" message causing the token to end
+      up in an initialized state for which the server does not know the
+      stored key, <ServerFinished> messages must always be authenticated
+      with a MAC.  The MAC shall be made using the already established
+      MAC algorithm.  The MAC value shall be computed on the (ASCII)
+      string "MAC 2 computation" and R_C using an authentication key
+      K_AUTH.  Again, this should be a special authentication key used
+      only for this purpose, but may also be an existing K_TOKEN.  (In
+      this case, implementations must protect against attacks where
+      K_TOKEN is used to pre-compute MAC values.)  If no authentication
+      key is present in the token, and no K_TOKEN existed before the CT-
+      KIP run, K_AUTH shall be the newly generated K_TOKEN.
+
+
+
+
+
+Nystroem                     Informational                     [Page 26]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+      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 2 computation" and R_C, and the parameter dsLen shall
+      be set to the length of R_C:
+
+      dsLen = len(R_C)
+
+      MAC = CT-KIP-PRF (K_AUTH, "MAC 2 computation" || R_C, dsLen)
+
+      When receiving a <ServerFinished> message with Status = "Success"
+      for which the MAC verifies, the CT-KIP client shall associate the
+      generated key K_TOKEN with the provided key identifier and store
+      this data permanently.  After this operation, it shall not be
+      possible to overwrite the key unless knowledge of an authorizing
+      key is proven through a MAC on a later <ServerHello> (and
+      <ServerFinished>) message.
+
+      The CT-KIP client must verify the MAC.  The CT-KIP client must
+      terminate the CT-KIP session if the MAC does not verify, and must,
+      in this case, also delete any nonces, keys, and/or secrets
+      associated with the failed run of the CT-KIP protocol.
+
+      The MacType's MacAlgorithm attribute shall, when present, identify
+      the negotiated MAC algorithm.
+
+3.9.  Protocol Extensions
+
+3.9.1.  The ClientInfoType Type
+
+   When present in a <ClientHello> or a <ClientNonce> message, the
+   optional ClientInfoType extension contains CT-KIP client-specific
+   information.  CT-KIP servers must support this extension.  CT-KIP
+   servers must not attempt to interpret the data it carries and, if
+   received, must include it unmodified in the current protocol run's
+   next server response.  Servers need not retain the ClientInfoType's
+   data after that response has been generated.
+
+   <xs:complexType name="ClientInfoType">
+     <xs:complexContent>
+       <xs:extension base="AbstractExtensionType">
+         <xs:sequence>
+           <xs:element name="Data"
+             type="xs:base64Binary"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+Nystroem                     Informational                     [Page 27]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+3.9.2.  The ServerInfoType Type
+
+   When present, the optional ServerInfoType extension contains CT-KIP
+   server-specific information.  This extension is only valid in
+   <ServerHello> messages for which Status = "Continue".  CT-KIP clients
+   must support this extension.  CT-KIP clients must not attempt to
+   interpret the data it carries and, if received, must include it
+   unmodified in the current protocol run's next client request (i.e.,
+   the <ClientNonce> message).  CT-KIP clients need not retain the
+   ServerInfoType's data after that request has been generated.  This
+   extension may be used, e.g., for state management in the CT-KIP
+   server.
+
+   <xs:complexType name="ServerInfoType">
+     <xs:complexContent>
+       <xs:extension base="AbstractExtensionType">
+         <xs:sequence>
+           <xs:element name="Data"
+             type="xs:base64Binary"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+3.9.3.  The OTPKeyConfigurationDataType Type
+
+   The optional OTPKeyConfigurationDataType extension contains
+   additional key configuration data for OTP keys:
+
+   <xs:complexType name="OTPKeyConfigurationDataType">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         This extension is only valid in ServerFinished
+         PDUs.  It carries additional configuration data
+         that an OTP token should use (subject to local
+         policy) when generating OTP values with a newly
+         generated OTP key.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="ExtensionType">
+         <xs:sequence>
+           <xs:element name="OTPFormat"
+             type="OTPFormatType"/>
+           <xs:element name="OTPLength"
+             type="xs:positiveInteger"/>
+           <xs:element name="OTPMode"
+             type="OTPModeType" minOccurs="0"/>
+
+
+
+Nystroem                     Informational                     [Page 28]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   This extension is only valid in <ServerFinished> messages.  It
+   carries additional configuration data that the cryptographic token
+   should use (subject to local policy) when generating OTP values from
+   the newly generated OTP key.  The components of this extension have
+   the following meaning:
+
+   o  OTPFormat: The default format of OTPs produced with this key.
+
+   o  OTPLength: The default length of OTPs produced with this key.
+
+   o  OTPMode: The default mode of operation when producing OTPs with
+      this key.
+
+4.  Protocol Bindings
+
+4.1.  General Requirement
+
+   CT-KIP assumes a reliable transport.
+
+4.2.  HTTP/1.1 binding for CT-KIP
+
+4.2.1.  Introduction
+
+   This section presents a binding of the previous messages to HTTP/1.1
+   [7].  Note that the HTTP client normally will be different from the
+   CT-KIP client, i.e., the HTTP client will only exist to "proxy" CT-
+   KIP messages from the CT-KIP client to the CT-KIP server.  Likewise,
+   on the HTTP server side, the CT-KIP server may receive CT-KIP PDUs
+   from a "front-end" HTTP server.
+
+4.2.2.  Identification of CT-KIP Messages
+
+   The MIME-type for all CT-KIP messages shall be
+
+   application/vnd.otps.ct-kip+xml
+
+4.2.3.  HTTP Headers
+
+   HTTP proxies must not cache responses carrying CT-KIP messages.  For
+   this reason, the following holds:
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 29]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   o  When using HTTP/1.1, requesters should:
+
+      *  Include a Cache-Control header field set to "no-cache,
+         no-store".
+
+      *  Include a Pragma header field set to "no-cache".
+
+   o  When using HTTP/1.1, responders should:
+
+      *  Include a Cache-Control header field set to "no-cache,
+         no-must-revalidate, private".
+
+      *  Include a Pragma header field set to "no-cache".
+
+      *  NOT include a Validator, such as a Last-Modified or ETag
+         header.
+
+   There are no other restrictions on HTTP headers, besides the
+   requirement to set the Content-Type header value to application/
+   vnd.otps.ct-kip+xml.
+
+4.2.4.  HTTP Operations
+
+   Persistent connections as defined in HTTP/1.1 are assumed but not
+   required.  CT-KIP requests are mapped to HTTP POST operations.  CT-
+   KIP responses are mapped to HTTP responses.
+
+4.2.5.  HTTP Status Codes
+
+   A CT-KIP HTTP responder that refuses to perform a message exchange
+   with a CT-KIP HTTP requester should return a 403 (Forbidden)
+   response.  In this case, the content of the HTTP body is not
+   significant.  In the case of an HTTP error while processing a CT-KIP
+   request, the HTTP server must return a 500 (Internal Server Error)
+   response.  This type of error should be returned for HTTP-related
+   errors detected before control is passed to the CT-KIP processor, or
+   when the CT-KIP processor reports an internal error (for example, the
+   CT-KIP XML namespace is incorrect, or the CT-KIP schema cannot be
+   located).  If the type of a CT-KIP request cannot be determined, the
+   CT-KIP responder must return a 400 (Bad request) response.
+
+   In these cases (i.e., when the HTTP response code is 4xx or 5xx), the
+   content of the HTTP body is not significant.
+
+   Redirection status codes (3xx) apply as usual.
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 30]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   Whenever the HTTP POST is successfully invoked, the CT-KIP HTTP
+   responder must use the 200 status code and provide a suitable CT-KIP
+   message (possibly with CT-KIP error information included) in the HTTP
+   body.
+
+4.2.6.  HTTP Authentication
+
+   No support for HTTP/1.1 authentication is assumed.
+
+4.2.7.  Initialization of CT-KIP
+
+   The CT-KIP server may initialize the CT-KIP protocol by sending an
+   HTTP response with Content-Type set to application/
+   vnd.otps.ct-kip+xml and response code set to 200 (OK).  This message
+   may, e.g., be sent in response to a user requesting token
+   initialization in a browsing session.  The initialization message may
+   carry data in its body.  If this is the case, the data shall be a
+   valid instance of a <CT-KIPTrigger> element.
+
+4.2.8.  Example Messages
+
+   a.  Initialization from CT-KIP server:
+
+   HTTP/1.1 200 OK
+   Cache-Control: no-store
+   Content-Type: application/vnd.otps.ct-kip+xml
+   Content-Length: <some value>
+
+   CT-KIP initialization data in XML form...
+
+   b.  Initial request from CT-KIP client:
+
+   POST http://example.com/cgi-bin/CT-KIP-server HTTP/1.1
+   Cache-Control: no-store
+   Pragma: no-cache
+   Host: example.com
+   Content-Type: application/vnd.otps.ct-kip+xml
+   Content-Length: <some value>
+
+   CT-KIP data in XML form (supported version, supported algorithms...)
+
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 31]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   c.  Initial response from CT-KIP server:
+
+   HTTP/1.1 200 OK
+   Cache-Control: no-store
+   Content-Type: application/vnd.otps.ct-kip+xml
+   Content-Length: <some other value>
+
+   CT-KIP data in XML form (server random nonce, server public key, ...)
+
+5.  Security considerations
+
+5.1.  General
+
+   CT-KIP is designed to protect generated key material from exposure.
+   No other entities than the CT-KIP server and the cryptographic token
+   will have access to a generated K_TOKEN if the cryptographic
+   algorithms used are of sufficient strength and, on the CT-KIP client
+   side, generation and encryption of R_C and generation of K_TOKEN take
+   place as specified and in the token.  This applies even if malicious
+   software is present in the CT-KIP client.  However, as discussed in
+   the following, CT-KIP does not protect against certain other threats
+   resulting from man-in-the-middle attacks and other forms of attacks.
+   CT-KIP should, therefore, be run over a transport providing privacy
+   and integrity, such as HTTP over Transport Layer Security (TLS) with
+   a suitable ciphersuite, when such threats are a concern.  Note that
+   TLS ciphersuites with anonymous key exchanges are not suitable in
+   those situations.
+
+5.2.  Active Attacks
+
+5.2.1.  Introduction
+
+   An active attacker may attempt to modify, delete, insert, replay or
+   reorder messages for a variety of purposes including service denial
+   and compromise of generated key material.  Sections 5.2.2 through
+   5.2.7 analyze these attack scenarios.
+
+5.2.2.  Message Modifications
+
+   Modifications to a <CT-KIPTrigger> message will either cause denial-
+   of-service (modifications of any of the identifiers or the nonce) or
+   the CT-KIP client to contact the wrong CT-KIP server.  The latter is
+   in effect a man-in-the-middle attack and is discussed further in
+   Section 5.2.7.
+
+   An attacker may modify a <ClientHello> message.  This means that the
+   attacker could indicate a different key or token than the one
+   intended by the CT-KIP client, and could also suggest other
+
+
+
+Nystroem                     Informational                     [Page 32]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   cryptographic algorithms than the ones preferred by the CT-KIP
+   client, e.g., cryptographically weaker ones.  The attacker could also
+   suggest earlier versions of the CT-KIP protocol, in case these
+   versions have been shown to have vulnerabilities.  These
+   modifications could lead to an attacker succeeding in initializing or
+   modifying another token than the one intended (i.e., the server
+   assigning the generated key to the wrong token), or gaining access to
+   a generated key through the use of weak cryptographic algorithms or
+   protocol versions.  CT-KIP implementations may protect against the
+   latter by having strict policies about what versions and algorithms
+   they support and accept.  The former threat (assignment of a
+   generated key to the wrong token) is not possible when the shared-key
+   variant of CT-KIP is employed (assuming existing shared keys are
+   unique per token) but is possible in the public-key variant.
+   Therefore, CT-KIP servers must not accept unilaterally provided token
+   identifiers in the public-key variant.  This is also indicated in the
+   protocol description.  In the shared-key variant, however, an
+   attacker may be able to provide the wrong identifier (possibly also
+   leading to the incorrect user being associated with the generated
+   key) if the attacker has real-time access to the token with the
+   identified key.  In other words, the generated key is associated with
+   the correct token but the token is associated with the incorrect
+   user.  See further Section 5.5 for a discussion of this threat and
+   possible countermeasures.
+
+   An attacker may also modify a <ServerHello> message.  This means that
+   the attacker could indicate different key types, algorithms, or
+   protocol versions than the legitimate server would, e.g.,
+   cryptographically weaker ones.  The attacker could also provide a
+   different nonce than the one sent by the legitimate server.  Clients
+   will protect against the former through strict adherence to policies
+   regarding permissible algorithms and protocol versions.  The latter
+   (wrong nonce) will not constitute a security problem, as a generated
+   key will not match the key generated on the legitimate server.  Also,
+   whenever the CT-KIP run would result in the replacement of an
+   existing key, the <Mac> element protects against modifications of
+   R_S.
+
+   Modifications of <ClientNonce> messages are also possible.  If an
+   attacker modifies the SessionID attribute, then, in effect, a switch
+   to another session will occur at the server, assuming the new
+   SessionID is valid at that time on the server.  It still will not
+   allow the attacker to learn a generated K_TOKEN since R_C has been
+   wrapped for the legitimate server.  Modifications of the
+   <EncryptedNonce> element, e.g., replacing it with a value for which
+   the attacker knows an underlying R'C, will not result in the client
+   changing its pre-CT-KIP state, since the server will be unable to
+   provide a valid MAC in its final message to the client.  The server
+
+
+
+Nystroem                     Informational                     [Page 33]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   may, however, end up storing K'TOKEN rather than K_TOKEN.  If the
+   token has been associated with a particular user, then this could
+   constitute a security problem.  For a further discussion about this
+   threat, and a possible countermeasure, see Section 5.5 below.  Note
+   that use of Secure Socket Layer (SSL) or TLS does not protect against
+   this attack if the attacker has access to the CT-KIP client (e.g.,
+   through malicious software, "trojans").
+
+   Finally, attackers may also modify the <ServerFinished> message.
+   Replacing the <Mac> element will only result in denial-of-service.
+   Replacement of any other element may cause the CT-KIP client to
+   associate, e.g., the wrong service with the generated key.  CT-KIP
+   should be run over a transport providing privacy and integrity when
+   this is a concern.
+
+5.2.3.  Message Deletion
+
+   Message deletion will not cause any other harm than denial-of-
+   service, since a token shall not change its state (i.e., "commit" to
+   a generated key) until it receives the final message from the CT-KIP
+   server and successfully has processed that message, including
+   validation of its MAC.  A deleted <ServerFinished> message will not
+   cause the server to end up in an inconsistent state vis-a-vis the
+   token if the server implements the suggestions in Section 5.5.
+
+5.2.4.  Message Insertion
+
+   An active attacker may initiate a CT-KIP run at any time, and suggest
+   any token identifier.  CT-KIP server implementations may receive some
+   protection against inadvertently initializing a token or
+   inadvertently replacing an existing key or assigning a key to a token
+   by initializing the CT-KIP run by use of the <CT-KIPTrigger>.  The
+   <TriggerNonce> element allows the server to associate a CT-KIP
+   protocol run with, e.g., an earlier user-authenticated session.  The
+   security of this method, therefore, depends on the ability to protect
+   the <TriggerNonce> element in the CT-KIP initialization message.  If
+   an eavesdropper is able to capture this message, he may race the
+   legitimate user for a key initialization.  CT-KIP over a transport
+   providing privacy and integrity, coupled with the recommendations in
+   Section 5.5, is recommended when this is a concern.
+
+   Insertion of other messages into an existing protocol run is seen as
+   equivalent to modification of legitimately sent messages.
+
+5.2.5.  Message Replay
+
+   Attempts to replay a previously recorded CT-KIP message will be
+   detected, as the use of nonces ensures that both parties are live.
+
+
+
+Nystroem                     Informational                     [Page 34]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+5.2.6.  Message Reordering
+
+   An attacker may attempt to re-order messages but this will be
+   detected, as each message is of a unique type.
+
+5.2.7.  Man in the Middle
+
+   In addition to other active attacks, an attacker posing as a man in
+   the middle may be able to provide his own public key to the CT-KIP
+   client.  This threat and countermeasures to it are discussed in
+   Section 3.3.  An attacker posing as a man-in-the-middle may also be
+   acting as a proxy and, hence, may not interfere with CT-KIP runs but
+   still learn valuable information; see Section 5.3.
+
+5.3.  Passive Attacks
+
+   Passive attackers may eavesdrop on CT-KIP runs to learn information
+   that later on may be used to impersonate users, mount active attacks,
+   etc.
+
+   If CT-KIP is not run over a transport providing privacy, a passive
+   attacker may learn:
+
+   o  What tokens a particular user is in possession of;
+
+   o  The identifiers of keys on those tokens and other attributes
+      pertaining to those keys, e.g., the lifetime of the keys; and
+
+   o  CT-KIP versions and cryptographic algorithms supported by a
+      particular CT-KIP client or server.
+
+   Whenever the above is a concern, CT-KIP should be run over a
+   transport providing privacy.  If man-in-the-middle attacks for the
+   purposes described above are a concern, the transport should also
+   offer server-side authentication.
+
+5.4.  Cryptographic Attacks
+
+   An attacker with unlimited access to an initialized token may use the
+   token as an "oracle" to pre-compute values that later on may be used
+   to impersonate the CT-KIP server.  Sections 3.6 and 3.8 contain
+   discussions of this threat and steps recommended to protect against
+   it.
+
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 35]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+5.5.  Attacks on the Interaction between CT-KIP and User Authentication
+
+   If keys generated in CT-KIP will be associated with a particular user
+   at the CT-KIP server (or a server trusted by, and communicating with
+   the CT-KIP server), then in order to protect against threats where an
+   attacker replaces a client-provided encrypted R_C with his own R'C
+   (regardless of whether the public-key variant or the shared-secret
+   variant of CT-KIP is employed to encrypt the client nonce), the
+   server should not commit to associate a generated K_TOKEN with the
+   given token (user) until the user simultaneously has proven both
+   possession of a token containing K_TOKEN and some out-of-band
+   provided authenticating information (e.g., a temporary password).
+   For example, if the token is a one-time password token, the user
+   could be required to authenticate with both a one-time password
+   generated by the token and an out-of-band provided temporary PIN in
+   order to have the server "commit" to the generated token value for
+   the given user.  Preferably, the user should perform this operation
+   from another host than the one used to initialize the token, in order
+   to minimize the risk of malicious software on the client interfering
+   with the process.
+
+   Another threat arises when an attacker is able to trick a user to
+   authenticate to the attacker rather than to the legitimate service
+   before the CT-KIP protocol run.  If successful, the attacker will
+   then be able to impersonate the user towards the legitimate service,
+   and subsequently receive a valid CT-KIP trigger.  If the public-key
+   variant of CT-KIP is used, this may result in the attacker being able
+   to (after a successful CT-KIP protocol run) impersonate the user.
+   Ordinary precautions must, therefore, be in place to ensure that
+   users authenticate only to legitimate services.
+
+6.  Intellectual Property Considerations
+
+   RSA and SecurID 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                     Informational                     [Page 36]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+7.  References
+
+7.1.  Normative References
+
+   [1]   Davis, M. and M. Duerst, "Unicode Normalization Forms",
+         March 2001,
+         <http://www.unicode.org/unicode/reports/tr15/tr15-21.html>.
+
+7.2.  Informative References
+
+   [2]   RSA Laboratories, "PKCS #11 Mechanisms for the Cryptographic
+         Token Key Initialization Protocol", PKCS #11 Version 2.20
+         Amendment 2, December 2005, <ftp://ftp.rsasecurity.com/pub/
+         pkcs/pkcs-11/v2-20/pkcs-11v2-20a2.pdf>.
+
+   [3]   RSA Laboratories, "Cryptographic Token Interface Standard",
+         PKCS #11 Version 2.20, June 2004, <ftp://ftp.rsasecurity.com/
+         pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf>.
+
+   [4]   RSA Laboratories, "Frequently Asked Questions About Today's
+         Cryptography. Version 4.1", 2000, <http://www.rsasecurity.com/
+         rsalabs/faq/files/rsalabs_faq41.pdf>.
+
+   [5]   RSA Laboratories, "Password-Based Cryptography Standard",
+         PKCS #5 Version 2.0, March 1999,
+         <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf>.
+
+   [6]   RSA Laboratories, "RSA Cryptography Standard", PKCS #1 Version
+         2.1, June 2002,
+         <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf>.
+
+   [7]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+   [8]   National Institute of Standards and Technology, "Specification
+         for the Advanced Encryption Standard (AES)", FIPS 197,
+         November 2001,
+         <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
+
+   [9]   Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+         for Message Authentication", RFC 2104, February 1997.
+
+   [10]  Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC.  In Fast
+         Software Encryption, FSE 2003, pages 129 - 153.
+         Springer-Verlag", 2003,
+         <http://crypt.cis.ibaraki.ac.jp/omac/docs/omac.pdf>.
+
+
+
+
+Nystroem                     Informational                     [Page 37]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   [11]  National Institute of Standards and Technology, "Secure Hash
+         Standard", FIPS 197, February 2004, <http://csrc.nist.gov/
+         publications/fips/fips180-2/fips180-2withchangenotice.pdf>.
+
+   [12]  RSA Laboratories, "Cryptographic Token Key Initialization
+         Protocol", OTPS Version 1.0, December 2005,
+         <ftp://ftp.rsasecurity.com/pub/otps/ct-kip/ct-kip-v1-0.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 38]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+Appendix A.  CT-KIP Schema
+
+   <xs:schema
+     targetNamespace=
+     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
+     xmlns:xs="http://www.w3.org/2001/XMLSchema"
+     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+     xmlns=
+     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#">
+
+   <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
+     schemaLocation=
+     "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
+   xmldsig-core-schema.xsd"/>
+
+   <!-- Basic types -->
+
+   <xs:complexType name="AbstractRequestType" abstract="true">
+     <xs:attribute name="Version" type="VersionType" use="required"/>
+   </xs:complexType>
+
+   <xs:complexType name="AbstractResponseType" abstract="true">
+     <xs:attribute name="Version" type="VersionType" use="required"/>
+     <xs:attribute name="SessionID" type="IdentifierType"/>
+     <xs:attribute name="Status" type="StatusCode" use="required"/>
+   </xs:complexType>
+
+   <xs:simpleType name="StatusCode">
+     <xs:restriction base="xs:string">
+       <xs:enumeration value="Continue"/>
+       <xs:enumeration value="Success"/>
+       <xs:enumeration value="Abort"/>
+       <xs:enumeration value="AccessDenied"/>
+       <xs:enumeration value="MalformedRequest"/>
+       <xs:enumeration value="UnknownRequest"/>
+       <xs:enumeration value="UnknownCriticalExtension"/>
+       <xs:enumeration value="UnsupportedVersion"/>
+       <xs:enumeration value="NoSupportedKeyTypes"/>
+       <xs:enumeration value="NoSupportedEncryptionAlgorithms"/>
+       <xs:enumeration value="NoSupportedMACAlgorithms"/>
+       <xs:enumeration value="InitializationFailed"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+   <xs:simpleType name="VersionType">
+     <xs:restriction base="xs:string">
+       <xs:pattern value="\d{1,2}\.\d{1,3}"/>
+     </xs:restriction>
+
+
+
+Nystroem                     Informational                     [Page 39]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   </xs:simpleType>
+
+   <xs:simpleType name="IdentifierType">
+     <xs:restriction base="xs:string">
+       <xs:maxLength value="128"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+   <xs:simpleType name="NonceType">
+     <xs:restriction base="xs:base64Binary">
+       <xs:length value="16"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+   <xs:complexType name="LogoType">
+     <xs:simpleContent>
+       <xs:extension base="xs:base64Binary">
+         <xs:attribute name="MimeType" type="MimeTypeType"
+         use="required"/>
+       </xs:extension>
+     </xs:simpleContent>
+   </xs:complexType>
+
+   <xs:simpleType name="MimeTypeType">
+     <xs:restriction base="xs:string">
+       <xs:enumeration value="image/jpeg"/>
+       <xs:enumeration value="image/gif"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+   <!-- Algorithms are identified through URIs -->
+   <xs:complexType name="AlgorithmsType">
+     <xs:sequence maxOccurs="unbounded">
+       <xs:element name="Algorithm" type="AlgorithmType"/>
+     </xs:sequence>
+   </xs:complexType>
+
+   <xs:simpleType name="AlgorithmType">
+     <xs:restriction base="xs:anyURI"/>
+   </xs:simpleType>
+
+   <xs:complexType name="MacType">
+     <xs:simpleContent>
+       <xs:extension base="xs:base64Binary">
+         <xs:attribute name="MacAlgorithm"
+         type="xs:anyURI"/>
+       </xs:extension>
+     </xs:simpleContent>
+
+
+
+Nystroem                     Informational                     [Page 40]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   </xs:complexType>
+
+   <!-- CT-KIP extensions (for future use) -->
+   <xs:complexType name="ExtensionsType">
+     <xs:sequence maxOccurs="unbounded">
+       <xs:element name="Extension" type="AbstractExtensionType"/>
+     </xs:sequence>
+   </xs:complexType>
+
+   <xs:complexType name="AbstractExtensionType" abstract="true">
+     <xs:attribute name="Critical" type="xs:boolean"/>
+   </xs:complexType>
+
+   <xs:complexType name="ClientInfoType">
+     <xs:complexContent>
+       <xs:extension base="AbstractExtensionType">
+         <xs:sequence>
+           <xs:element name="Data" type="xs:base64Binary"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   <xs:complexType name="ServerInfoType">
+     <xs:complexContent>
+       <xs:extension base="AbstractExtensionType">
+         <xs:sequence>
+           <xs:element name="Data" type="xs:base64Binary"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   <xs:complexType name="OTPKeyConfigurationDataType">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         This extension is only valid in ServerFinished PDUs.  It
+         carries additional configuration data that an OTP token should
+         use (subject to local policy) when generating OTP values from a
+         newly generated OTP key.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractExtensionType">
+         <xs:sequence>
+           <xs:element name="OTPFormat" type="OTPFormatType"/>
+           <xs:element name="OTPLength" type="xs:positiveInteger"/>
+           <xs:element name="OTPMode" type="OTPModeType" minOccurs="0"/>
+
+
+
+Nystroem                     Informational                     [Page 41]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   <xs:simpleType name="OTPFormatType">
+     <xs:restriction base="xs:string">
+       <xs:enumeration value="Decimal"/>
+       <xs:enumeration value="Hexadecimal"/>
+       <xs:enumeration value="Alphanumeric"/>
+       <xs:enumeration value="Binary"/>
+     </xs:restriction>
+   </xs:simpleType>
+
+   <xs:complexType name="OTPModeType">
+     <xs:choice maxOccurs="unbounded">
+       <xs:element name="Time" type="TimeType"/>
+       <xs:element name="Counter"/>
+       <xs:element name="Challenge"/>
+       <xs:any namespace="##other" processContents="strict"/>
+     </xs:choice>
+   </xs:complexType>
+
+   <xs:complexType name="TimeType">
+     <xs:complexContent>
+       <xs:restriction base="xs:anyType">
+         <xs:attribute name="TimeInterval" type="xs:positiveInteger"/>
+       </xs:restriction>
+     </xs:complexContent>
+   </xs:complexType>
+
+   <xs:complexType name="PayloadType">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+       </xs:documentation>
+     </xs:annotation>
+     <xs:choice>
+       <xs:element name="Nonce" type="NonceType"/>
+       <xs:any namespace="##other" processContents="strict"/>
+     </xs:choice>
+   </xs:complexType>
+
+   <xs:simpleType name="PlatformType">
+     <xs:restriction base="xs:string">
+       <xs:enumeration value="Hardware"/>
+       <xs:enumeration value="Software"/>
+       <xs:enumeration value="Unspecified"/>
+     </xs:restriction>
+
+
+
+Nystroem                     Informational                     [Page 42]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   </xs:simpleType>
+
+   <xs:complexType name="TokenPlatformInfoType">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Carries token platform information helping the client to select
+         a suitable token.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:attribute name="KeyLocation" type="PlatformType"/>
+     <xs:attribute name="AlgorithmLocation" type="PlatformType"/>
+   </xs:complexType>
+
+   <xs:complexType name="InitializationTriggerType">
+     <xs:sequence>
+       <xs:element name="TokenID" type="xs:base64Binary" minOccurs="0"/>
+       <xs:element name="KeyID" type="xs:base64Binary" minOccurs="0"/>
+       <xs:element name="TokenPlatformInfo" type="TokenPlatformInfoType"
+         minOccurs="0"/>
+       <xs:element name="TriggerNonce" type="NonceType"/>
+       <xs:element name="CT-KIPURL" type="xs:anyURI" minOccurs="0"/>
+       <xs:any namespace="##other" processContents="strict"
+         minOccurs="0"/>
+     </xs:sequence>
+   </xs:complexType>
+
+   <!-- CT-KIP PDUs -->
+
+   <!-- CT-KIP trigger -->
+   <xs:element name="CT-KIPTrigger" type="CT-KIPTriggerType"/>
+
+   <xs:complexType name="CT-KIPTriggerType">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Message used to trigger the device to initiate a CT-KIP run.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:sequence>
+       <xs:choice>
+         <xs:element name="InitializationTrigger"
+         type="InitializationTriggerType"/>
+         <xs:any namespace="##other" processContents="strict"/>
+       </xs:choice>
+     </xs:sequence>
+     <xs:attribute name="Version" type="VersionType"/>
+   </xs:complexType>
+
+   <!-- ClientHello PDU -->
+
+
+
+Nystroem                     Informational                     [Page 43]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   <xs:element name="ClientHello" type="ClientHelloPDU"/>
+
+   <xs:complexType name="ClientHelloPDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Message sent from CT-KIP client to CT-KIP server to initiate an
+         CT-KIP session.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractRequestType">
+         <xs:sequence>
+           <xs:element name="TokenID" type="xs:base64Binary"
+             minOccurs="0"/>
+           <xs:element name="KeyID" type="xs:base64Binary"
+             minOccurs="0"/>
+           <xs:element name="ClientNonce" type="NonceType"
+             minOccurs="0"/>
+           <xs:element name="TriggerNonce" type="NonceType"
+             minOccurs="0"/>
+           <xs:element name="SupportedKeyTypes" type="AlgorithmsType"/>
+           <xs:element name="SupportedEncryptionAlgorithms"
+             type="AlgorithmsType"/>
+           <xs:element name="SupportedMACAlgorithms"
+             type="AlgorithmsType"/>
+           <xs:element name="Extensions" type="ExtensionsType"
+             minOccurs="0"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   <!-- ServerHello PDU -->
+   <xs:element name="ServerHello" type="ServerHelloPDU"/>
+
+   <xs:complexType name="ServerHelloPDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Message sent from CT-KIP server to CT-KIP client in response to
+         a received ClientHello PDU.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractResponseType">
+         <xs:sequence minOccurs="0">
+           <xs:element name="KeyType" type="AlgorithmType"/>
+           <xs:element name="EncryptionAlgorithm" type="AlgorithmType"/>
+           <xs:element name="MacAlgorithm" type="AlgorithmType"/>
+
+
+
+Nystroem                     Informational                     [Page 44]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+           <xs:element name="EncryptionKey" type="ds:KeyInfoType"/>
+           <xs:element name="Payload" type="PayloadType"/>
+           <xs:element name="Extensions" type="ExtensionsType"
+             minOccurs="0"/>
+           <xs:element name="Mac" type="MacType" minOccurs="0"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   <!-- ClientNonce PDU -->
+   <xs:element name="ClientNonce" type="ClientNoncePDU"/>
+
+   <xs:complexType name="ClientNoncePDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Second message sent from CT-KIP client to CT-KIP server to
+         convey the client's chosen secret.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractRequestType">
+         <xs:sequence>
+           <xs:element name="EncryptedNonce" type="xs:base64Binary"/>
+           <xs:element name="Extensions" type="ExtensionsType"
+             minOccurs="0"/>
+         </xs:sequence>
+         <xs:attribute name="SessionID" type="IdentifierType"
+           use="required"/>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   <!-- ServerFinished PDU -->
+   <xs:element name="ServerFinished" type="ServerFinishedPDU"/>
+   <xs:complexType name="ServerFinishedPDU">
+     <xs:annotation>
+       <xs:documentation xml:lang="en">
+         Final message sent from CT-KIP server to CT-KIP client in an
+         CT-KIP session.
+       </xs:documentation>
+     </xs:annotation>
+     <xs:complexContent>
+       <xs:extension base="AbstractResponseType">
+         <xs:sequence minOccurs="0">
+           <xs:element name="TokenID" type="xs:base64Binary"/>
+           <xs:element name="KeyID" type="xs:base64Binary"/>
+           <xs:element name="KeyExpiryDate" type="xs:dateTime"
+
+
+
+Nystroem                     Informational                     [Page 45]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+             minOccurs="0"/>
+           <xs:element name="ServiceID" type="IdentifierType"
+             minOccurs="0"/>
+           <xs:element name="ServiceLogo" type="LogoType"
+             minOccurs="0"/>
+           <xs:element name="UserID" type="IdentifierType"
+             minOccurs="0"/>
+           <xs:element name="Extensions" type="ExtensionsType"
+             minOccurs="0"/>
+           <xs:element name="Mac" type="MacType"/>
+         </xs:sequence>
+       </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+   </xs:schema>
+
+Appendix B.  Examples of CT-KIP Messages
+
+B.1.  Introduction
+
+   All examples are syntactically correct.  MAC and cipher values are
+   fictitious, however.  The examples illustrate a complete CT-KIP
+   exchange, starting with an initialization (trigger) message from the
+   server.
+
+B.2.  Example of a CT-KIP Initialization (Trigger) Message
+
+   <CT-KIPTrigger
+     xmlns=
+     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
+     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+     Version="1.0">
+     <InitializationTrigger>
+       <TokenID>12345678</TokenID>
+       <TriggerNonce>112dsdfwf312asder394jw==</TriggerNonce>
+     </InitializationTrigger>
+   </CT-KIPTrigger>
+
+B.3.  Example of a <ClientHello> Message
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <ClientHello
+     xmlns=
+     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
+     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+     Version="1.0">
+     <TokenID>12345678</TokenID>
+
+
+
+Nystroem                     Informational                     [Page 46]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+    <TriggerNonce>112dsdfwf312asder394jw==</TriggerNonce>
+     <SupportedKeyTypes>
+       <Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas
+   /2005/09/otps-wst#SecurID-AES</Algorithm>
+     </SupportedKeyTypes>
+     <SupportedEncryptionAlgorithms>
+       <Algorithm>http://www.w3.org/2001/04/xmlenc#rsa-1_5</Algorithm>
+       <Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
+   2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
+     </SupportedEncryptionAlgorithms>
+     <SupportedMACAlgorithms>
+       <Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
+   2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
+     </SupportedMACAlgorithms>
+   </ClientHello>
+
+B.4.  Example of a <ServerHello> Message
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <ServerHello
+     xmlns=
+   "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
+     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+     Version="1.0" SessionID="4114" Status="Success">
+     <KeyType>http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
+   otps-wst#SecurID-AES</KeyType>
+     <EncryptionAlgorithm>http://www.rsasecurity.com/rsalabs/otps/
+   schemas/2005/12/ct-kip#ct-kip-prf-aes</EncryptionAlgorithm>
+     <MacAlgorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
+   2005/12/ct-kip#ct-kip-prf-aes</MacAlgorithm>
+     <EncryptionKey>
+       <ds:KeyName>KEY-1</ds:KeyName>
+     </EncryptionKey>
+     <Payload>
+       <Nonce>qw2ewasde312asder394jw==</Nonce>
+     </Payload>
+   </ServerHello>
+
+B.5.  Example of a <ClientNonce> Message
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <ClientNonce
+     xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas/
+   2005/12/ct-kip#"
+     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+     Version="1.0" SessionID="4114">
+     <EncryptedNonce>vXENc+Um/9/NvmYKiHDLaErK0gk=</EncryptedNonce>
+
+
+
+Nystroem                     Informational                     [Page 47]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   </ClientNonce>
+
+B.6.  Example of a <ServerFinished> Message
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <ServerFinished
+     xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas/
+   2005/12/ct-kip#"
+     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+     Version="1.0" SessionID="4114" Status="Success">
+     <TokenID>12345678</TokenID>
+     <KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
+     <KeyID>43212093</KeyID>
+     <ServiceID>Example Enterprise Name</ServiceID>
+     <UserID>exampleLoginName</UserID>
+     <Extensions>
+       <Extension xsi:type="OTPKeyConfigurationDataType">
+         <OTPFormat>Decimal</OTPFormat>
+         <OTPLength>6</OTPLength>
+         <OTPMode><Time/></OTPMode>
+       </Extension>
+     </Extensions>
+     <Mac>miidfasde312asder394jw==</Mac>
+   </ServerFinished>
+
+Appendix C.  Integration with PKCS #11
+
+   A CT-KIP client that needs to communicate with a connected
+   cryptographic token to perform a CT-KIP exchange may use PKCS #11 [3]
+   as a programming interface.  When performing CT-KIP with a
+   cryptographic token using the PKCS #11 programming interface, the
+   procedure described in [2], Appendix B, is recommended.
+
+Appendix D.  Example CT-KIP-PRF Realizations
+
+D.1.  Introduction
+
+   This example appendix defines CT-KIP-PRF in terms of AES [8] and HMAC
+   [9].
+
+D.2.  CT-KIP-PRF-AES
+
+D.2.1.  Identification
+
+   For tokens supporting this realization of CT-KIP-PRF, the following
+   URI may be used to identify this algorithm in CT-KIP:
+
+   http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
+
+
+
+Nystroem                     Informational                     [Page 48]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   ct-kip#ct-kip-prf-aes
+
+   When this URI is used to identify the encryption algorithm to use,
+   the method for encryption of R_C values described in Section 3.6
+   shall be used.
+
+D.2.2.  Definition
+
+   CT-KIP-PRF-AES (k, s, dsLen)
+
+   Input:
+
+   k     encryption key to use
+
+   s     octet string consisting of randomizing material.  The length of
+         the string s is sLen.
+
+   dsLen desired length of the output
+
+   Output:
+
+   DS    a pseudorandom string, dsLen-octets long
+
+   Steps:
+
+   1.  Let bLen be the output block size of AES in octets:
+
+       bLen = (AES output block length in octets)
+
+       (normally, bLen = 16)
+
+   2.  If dsLen > (2**32 - 1) * bLen, output "derived data too long" and
+       stop
+
+   3.  Let n be the number of bLen-octet blocks in the output data,
+       rounding up, and let j be the number of octets in the last block:
+
+       n = ROUND( dsLen / bLen )
+
+       j = dsLen - (n - 1) * bLen
+
+   4.  For each block of the pseudorandom string DS, apply the function
+       F defined below to the key k, the string s and the block index to
+       compute the block:
+
+       B1 = F (k, s, 1) ,
+
+       B2 = F (k, s, 2) ,
+
+
+
+Nystroem                     Informational                     [Page 49]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+       ...
+
+       Bn = F (k, s, n)
+
+   The function F is defined in terms of the OMAC1 construction from
+   [10], using AES as the block cipher:
+
+   F (k, s, i) = OMAC1-AES (k, INT (i) || s)
+
+   where INT (i) is a four-octet encoding of the integer i, most
+   significant octet first, and the output length of OMAC1 is set to
+   bLen.
+
+   Concatenate the blocks and extract the first dsLen octets to produce
+   the desired data string DS:
+
+   DS = B1 || B2 || ... || Bn<0..j-1>
+
+   Output the derived data DS.
+
+D.2.3.  Example
+
+   If we assume that dsLen = 16, then:
+
+   n = 16 / 16 = 1
+
+   j = 16 - (1 - 1) * 16 = 16
+
+   DS = B1 = F (k, s, 1) = OMAC1-AES (k, INT (1) || S)
+
+D.3.  CT-KIP-PRF-SHA256
+
+D.3.1.  Identification
+
+   For tokens supporting this realization of CT-KIP-PRF, the following
+   URI may be used to identify this algorithm in CT-KIP:
+
+   http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
+   ct-kip#ct-kip-prf-sha256
+
+   When this URI is used to identify the encryption algorithm to use,
+   the method for encryption of R_C values described in Section 3.6
+   shall be used.
+
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 50]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+D.3.2.  Definition
+
+   CT-KIP-PRF-SHA256 (k, s, dsLen)
+
+   Input:
+
+   k     encryption key to use
+
+   s     octet string consisting of randomizing material.  The length of
+         the string s is sLen
+
+   dsLen desired length of the output
+
+   Output:
+
+   DS    a pseudorandom string, dsLen-octets long
+
+   Steps:
+
+   1.  Let bLen be the output size in octets of SHA-256 [11] (no
+       truncation is done on the HMAC output):
+
+       bLen = 32
+
+   2.  If dsLen > (2**32 - 1) bLen, output "derived data too long" and
+       stop
+
+   3.  Let n be the number of bLen-octet blocks in the output data,
+       rounding up, and let j be the number of octets in the last block:
+
+       n = ROUND ( dsLen / bLen )
+
+       j = dsLen - (n - 1) * bLen
+
+   4.  For each block of the pseudorandom string DS, apply the function
+       F defined below to the key k, the string s and the block index to
+       compute the block:
+
+       B1 = F (k, s, 1) ,
+
+       B2 = F (k, s, 2) ,
+
+       ...
+
+       Bn = F (k, s, n)
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 51]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+   The function F is defined in terms of the HMAC construction from [9],
+   using SHA-256 as the digest algorithm:
+
+   F (k, s, i) = HMAC-SHA256 (k, INT (i) || s)
+
+   where INT (i) is a four-octet encoding of the integer i, most
+   significant octet first, and the output length of HMAC is set to
+   bLen.
+
+   Concatenate the blocks and extract the first dsLen octets to produce
+   the desired data string DS:
+
+   DS = B1 || B2 || ... || Bn<0..j-1>
+
+   Output the derived data DS.
+
+D.3.3.  Example
+
+   If we assume that sLen = 256 (two 128-octet long values) and dsLen =
+   16, then:
+
+   n = ROUND ( 16 / 32 ) = 1
+
+   j = 16 - (1 - 1) * 32 = 16
+
+   B1 = F (k, s, 1) = HMAC-SHA256 (k, INT (1) || s )
+
+   DS = B1<0 ... 15>
+
+   That is, the result will be the first 16 octets of the HMAC output.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 52]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+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 Laboratories
+   174 Middlesex Turnpike
+   Bedford, MA  01730 USA
+   otps-editor@rsasecurity.com
+   http://www.rsasecurity.com/rsalabs/
+
+Author's Address
+
+   Magnus Nystroem
+   RSA Security
+
+   EMail: magnus@rsasecurity.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 53]
+
+RFC 4758             CT-KIP Version 1.0 Revision 1         November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Nystroem                     Informational                     [Page 54]
+