Network Working Group                                        M. Nystroem
Internet-Draft                         RSA, The Security Division of EMC
Intended status: Informational                                S. Machani
Expires: August 27, 2007                                Diversinet Corp.
                                                       February 23, 2007


  Extensions to CT-KIP to support one- and two-pass key initialization
                draft-nystrom-keyprov-ct-kip-two-pass-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 27, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Nystroem & Machani       Expires August 27, 2007                [Page 1]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Abstract

   This document describes extensions to the Cryptographic Token Key
   Initialization Protocol (CT-KIP) to support one-pass (i.e. one
   message) and two-pass (i.e. one round-trip) cryptographic token key
   initialization.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Document organization  . . . . . . . . . . . . . . . . . .  4
   2.  Acronyms and notation  . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  One- and two-pass CT-KIP . . . . . . . . . . . . . . . . . . .  6
     3.1.  Protocol flow  . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  One-pass CT-KIP  . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  Two-pass CT-KIP  . . . . . . . . . . . . . . . . . . .  6
     3.2.  Extensions to the <ClientHello> message  . . . . . . . . .  6
     3.3.  Extensions to the <ServerFinished> message . . . . . . . .  7
       3.3.1.  The KeyInitializationDataType extension  . . . . . . .  7
       3.3.2.  The AuthenticationDataType extension . . . . . . . . .  8
     3.4.  MAC calculations . . . . . . . . . . . . . . . . . . . . .  9
       3.4.1.  One-pass CT-KIP  . . . . . . . . . . . . . . . . . . .  9
       3.4.2.  Two-pass CT-KIP  . . . . . . . . . . . . . . . . . . . 11
   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 12
     4.1.  Applicability of 4-pass CT-KIP security considerations . . 12
     4.2.  Security considerations specific to 1- and 2-pass
           CT-KIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       4.2.1.  Client contributions to K_TOKEN entropy  . . . . . . . 12
       4.2.2.  Replay protection  . . . . . . . . . . . . . . . . . . 12
       4.2.3.  Key confirmation . . . . . . . . . . . . . . . . . . . 13
       4.2.4.  Server authentication  . . . . . . . . . . . . . . . . 13
       4.2.5.  Key protection in the passphrase profile . . . . . . . 13
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Intellectual property considerations . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 18
   Appendix A.  XML Schema  . . . . . . . . . . . . . . . . . . . . . 19
   Appendix B.  Key initialization profiles of CT-KIP . . . . . . . . 22
     B.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 22
     B.2.  Key transport profile  . . . . . . . . . . . . . . . . . . 22
       B.2.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 22



Nystroem & Machani       Expires August 27, 2007                [Page 2]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


       B.2.2.  Identification . . . . . . . . . . . . . . . . . . . . 22
       B.2.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 22
     B.3.  Key wrap profile . . . . . . . . . . . . . . . . . . . . . 23
       B.3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 23
       B.3.2.  Identification . . . . . . . . . . . . . . . . . . . . 23
       B.3.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 24
     B.4.  Passphrase-based key wrap profile  . . . . . . . . . . . . 25
       B.4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 25
       B.4.2.  Identification . . . . . . . . . . . . . . . . . . . . 25
       B.4.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 25
   Appendix C.  Example messages  . . . . . . . . . . . . . . . . . . 27
     C.1.  Note regarding the examples  . . . . . . . . . . . . . . . 27
     C.2.  Example of a <ClientHello> message indicating support
           for two-pass CT-KIP  . . . . . . . . . . . . . . . . . . . 27
     C.3.  Example of a <ServerFinished> message using the key
           transport profile  . . . . . . . . . . . . . . . . . . . . 29
     C.4.  Example of a <ServerFinished> message using the key
           wrap profile . . . . . . . . . . . . . . . . . . . . . . . 31
     C.5.  Example of a <ServerFinished> message using the
           passphrase-based key wrap profile  . . . . . . . . . . . . 32
   Appendix D.  Integration with PKCS #11 . . . . . . . . . . . . . . 34
     D.1.  The 2-pass variant . . . . . . . . . . . . . . . . . . . . 34
     D.2.  The 1-pass variant . . . . . . . . . . . . . . . . . . . . 36
   Appendix E.  About OTPS  . . . . . . . . . . . . . . . . . . . . . 40
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
   Intellectual Property and Copyright Statements . . . . . . . . . . 42

























Nystroem & Machani       Expires August 27, 2007                [Page 3]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


1.  Introduction

1.1.  Scope

   This document describes extensions to the Cryptographic Token Key
   Initialization Protocol (CT-KIP) [1] to support one-pass (i.e. one
   message) and two-pass (i.e. one round-trip) cryptographic token key
   initialization.

1.2.  Background

   There are several deployment scenarios where it would be beneficial
   to have one- or two-pass versions of CT-KIP.  These include
   situations where a direct communication between the OTP token and the
   CT-KIP server is not possible, where work-flow constraints otherwise
   would limit real-time communications (e.g. needs for administrators
   to authorize processes), or where network latency or other design
   constraints (such as when initialization of tokens using existing
   seeds from legacy systems is required) makes a four-pass version less
   suitable.

   This document tries to meet the needs of these scenarios by
   describing extensions to CT-KIP for the initialization of
   cryptographic tokens in one round-trip or less.

1.3.  Document organization

   The organization of this document is as follows:

   o  Section 1 is an introduction.

   o  Section 2 defines acronyms and notation used in this document.

   o  Section 3 defines extensions to CT-KIP.

   o  Section 4 discusses security considerations.

   o  Appendix A presents the XML schema. considerations.

   o  Appendix B contains key initialization profiles for the 1- and
      2-pass versions of CT-KIP defined herein.

   o  Appendix C provides example messages.

   o  Appendix D discusses integration with PKCS #11 [2].

   o  Appendix E provides general information about the One-Time
      Password Specifications.



Nystroem & Machani       Expires August 27, 2007                [Page 4]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


2.  Acronyms and notation

2.1.  Acronyms

   MAC       Cryptographic Token Key Initialization Protocol

2.2.  Notation

   ||        String concatenation

   ID_C      Identifier for CT-KIP client

   ID_S      Identifier for CT-KIP server

   K_AUTH    Secret key used for authentication purposes in 4-pass CT-
             KIP

   K_MAC     Secret key used for key confirmation and authentication
             purposes, generated in CT-KIP

   K_TOKEN   Secret key used for token computations, generated in CT-KIP

   K_CLIENT  Public key of the cryptographic token

   K_SHARED  Secret key shared between the cryptographic token and the
             CT-KIP server

   K_DERIVED Secret key derived from a passphrase that is known to both
             the cryptographic token or user and the CT-KIP server

   R         Pseudorandom value chosen by the cryptographic token and
             used for MAC computations

   The following typographical convention is used in the body of the
   text: <XML Element>.
















Nystroem & Machani       Expires August 27, 2007                [Page 5]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


3.  One- and two-pass CT-KIP

3.1.  Protocol flow

3.1.1.  One-pass CT-KIP

   In one-pass CT-KIP, the server simply sends a <ServerFinished>
   message to the CT-KIP client.  In this case, there is no exchange of
   the <ClientHello>, <ServerHello>, and <ClientNonce> CT-KIP messages,
   and hence there is no way for the client to express supported
   algorithms or key types.  Before attempting one-pass CT-KIP, the
   server must therefore have prior knowledge not only that the client
   is able and willing to accept this variant of CT-KIP, but also of
   algorithms and key types supported by the client.

   Outside the specific cases where one-pass CT-KIP is desired, clients
   should be constructed and configured to only accept CT-KIP server
   messages in response to client-initiated transactions.

3.1.2.  Two-pass CT-KIP

   In two-pass CT-KIP, the client's initial <ClientHello> message is
   directly followed by a <ServerFinished> message.  There is no
   exchange of the <ServerHello> message or the <ClientNonce> message.
   Essentially, two-pass CT-KIP is a transport of key material from the
   CT-KIP server to the CT-KIP client.  However, as the two-pass variant
   of CT-KIP consists of one round trip to the server, the client is
   still able to specify algorithm preferences and supported key types
   in the <ClientHello> message.  Note that the CT-KIP "trigger" message
   defined in [1] may be used to trigger the client's sending of the
   <ClientHello> message.

3.2.  Extensions to the <ClientHello> message

   A new extension is defined for this message.  The extension signals
   client support for the two-pass version of CT-KIP, informs the server
   of supported two-pass variants, and provides optional payload data to
   the CT-KIP server.  The payload is sent in an opportunistic fashion,
   and may be discarded by the CT-KIP server if the server does not
   support the two-pass variant the payload is associated with.
   Depending on the client's policy, this extension may or may not have
   the Critical attribute set to true.  If Critical is not set to "true"
   then a CT-KIP server may ignore the extension and proceed with
   ordinary 4-pass CT-KIP.  Otherwise, the server must find a suitable
   two-pass variant or else the protocol run will fail.






Nystroem & Machani       Expires August 27, 2007                [Page 6]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   <xs:complexType name="TwoPassSupportType">
     <xs:annotation>
       <xs:documentation xml:lang="en">
         This extension is only valid in ClientHello PDUs. It informs
         the server of the client's support for the two-pass version of
         CT-KIP, and carries optional payload data associated with each
         supported two-pass key initialization method
       </xs:documentation>
     </xs:annotation>
     <xs:complexContent>
       <xs:extension base="ct-kip:AbstractExtensionType">
         <xs:sequence maxOccurs="unbounded">
           <xs:element name="SupportedKeyInitializationMethod"
           type="xs:anyURI"/>
           <xs:element name="Payload" minOccurs="0"/>
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   The elements of this type have the following meaning:

   o  <SupportedKeyInitializationMethod>: A two-pass key initialization
      method supported by the CT-KIP client.  Multiple supported methods
      may be present, in which case they shall be listed in order of
      precedence.

   o  <Payload>: An optional payload associated with each supported key
      initialization method.  Since the syntax is a shorthand for <xs:
      element name="Payload" type="xs:anyType" minOccurs="0"/>, any
      well-formed payloads can be carried in this element.

   A CT-KIP client that indicates support for two-pass CT-KIP must also
   include the nonce R in its <ClientHello> message (this will enable
   the client to verify that the CT-KIP server it is communicating with
   is alive).

3.3.  Extensions to the <ServerFinished> message

3.3.1.  The KeyInitializationDataType extension

   This extension carries an identifier for the selected key
   initialization method as well as key initialization method-dependent
   payload data.

   Servers may include this extension in a <ServerFinished> message that
   is being sent in response to a received <ClientHello> message if and
   only if that <ClientHello> message contained a TwoPassSupportType



Nystroem & Machani       Expires August 27, 2007                [Page 7]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   extension and the client indicated support for the selected key
   initialization method.  Servers must include this extension in a
   <ServerFinished> message that is sent as a 1-pass CT-KIP.

   <xs:complexType name="KeyInitializationDataType">
     <xs:annotation>
       <xs:documentation xml:lang="en">
         This extension is only valid in ServerFinished PDUs. It
         contains key initialization data and its presence results in a
         two-pass (or one-pass, if no ClientHello was sent) CT-KIP
         exchange.
       </xs:documentation>
     </xs:annotation>
     <xs:complexContent>
       <xs:extension base="ct-kip:AbstractExtensionType">
         <xs:sequence>
           <xs:element name="KeyInitializationMethod" type="xs:anyURI"/>
           <xs:element name="Payload"/>
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   The elements of this type have the following meaning:

   o  <KeyInitializationMethod>: A two-pass key initialization method
      supported by the CT-KIP client.

   o  <Payload>: An payload associated with the key initialization
      method.  Since the syntax is a shorthand for <xs:element
      name="Payload" type="xs:anyType"/>, any well-formed payloads can
      be carried in this element.

3.3.2.  The AuthenticationDataType extension

   This extension must be included by the CT-KIP server when a
   successful 1- or 2-pass protocol run will result in an existing key
   being replaced.  The extension contains a MAC proving to the token
   that the server knows the value of the key it is about to replace.












Nystroem & Machani       Expires August 27, 2007                [Page 8]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   <xs:complexType name="AuthenticationDataType">
     <xs:annotation>
       <xs:documentation xml:lang="en">
         This extension is only valid in ServerFinished PDUs. It
         contains a MAC authenticating the CT-KIP server to the token.
       </xs:documentation>
     </xs:annotation>
     <xs:complexContent>
       <xs:extension base="ct-kip:AbstractExtensionType">
         <xs:sequence>
           <xs:element name="Mac" type="ExtendedMacType"/>
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   The element of this type has the following meaning:

   o  <Mac>: The authenticating MAC and optional additional information
      (e.g.  MAC algorithm).  See further Section 3.4.

3.4.  MAC calculations

3.4.1.  One-pass CT-KIP

3.4.1.1.  Key confirmation

   In one-pass CT-KIP, the server is required to include an identifier,
   ID_S, for itself (in the <ServerID> element) in the <ServerFinished>
   message.  The MAC value in the <ServerFinished> message shall be
   computed on the (ASCII) string "MAC 1 computation", the server
   identifier ID_S, and an usigned integer value I, using a MAC key
   K_MAC.  The value I must be monotonically increasing and guaranteed
   not to be used again by this server towards this token.  It could for
   example be the number of seconds since some point in time with
   sufficient granularity, a counter value, or a combination of the two
   where the counter value is reset for each new time value.  In
   contrast to [1], the MAC key K_MAC shall be provided together with
   K_TOKEN to the token, and hence there is no need for a K_AUTH for key
   confirmation purposes.

   Note 1: The integer I does not necessarily need to be maintained per
   token by the CT-KIP server (it is enough if the server can guarantee
   that the same value is never being sent twice to the same token).

   Note 2: An extension is planned to [1] to allow for generation of a
   K_MAC in addition to K_TOKEN in 4-pass CT-KIP.




Nystroem & Machani       Expires August 27, 2007                [Page 9]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
   s shall consist of the concatenation of the (ASCII) string "MAC 1
   computation", ID_S, and I. The parameter dsLen shall be set to at
   least 16 (i.e. the length of the MAC shall be at least 16 octets):

   dsLen >= 16

   MAC = CT-KIP-PRF (K_MAC, "MAC 1 computation" || ID_S || I, dsLen)

   The server shall provide I to the client in the Nonce attribute of
   the <Mac> element of the <ServerFinished> message using the following
   extension of the CT-KIP MacType:

   <xs:complexType name="ExtendedMacType">
     <xs:simpleContent>
       <xs:extension base="ct-kip:MacType">
         <xs:attribute name="Nonce" type="xs:nonNegativeInteger"
         use="required"/>
       </xs:extension>
     </xs:simpleContent>
   </xs:complexType>

3.4.1.2.  Server authentication

   As discussed in Section 3.3.2, servers need to authenticate
   themselves when attempting to replace an existing K_TOKEN.  In 1-pass
   CT-KIP, servers authenticate themselves by including a second MAC
   value in the AuthenticationDataType extension.  The MAC value in the
   AuthenticationDataType extension shall be computed on the (ASCII)
   string "MAC 1 computation", the server identifier ID_S, and a new
   value I', I' > I, using the existing MAC key K_MAC' (the MAC key that
   existed before this protocol run).  The MAC algorithm shall be the
   same as the algorithm used for key confirmation purposes.

   If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
   s shall consist of the concatenation of the (ASCII) string "MAC 1
   computation" ID_S, and I'.  The parameter dsLen shall be set to at
   least 16 (i.e. the length of the MAC shall be at least 16 octets):

   dsLen >= 16

   MAC = CT-KIP-PRF (K_MAC', "MAC 1 computation" || ID_S || I', dsLen)

   The server shall provide I' to the client in the Nonce attribute of
   the <Mac> element of the AuthenticationDataType extension.  If the
   protocol run is successful, the client stores I' as the new value of
   I for this server.




Nystroem & Machani       Expires August 27, 2007               [Page 10]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


3.4.2.  Two-pass CT-KIP

3.4.2.1.  Key confirmation

   In two-pass CT-KIP, the client is required to include a nonce R in
   the <ClientHello> message.  Further, the server is required to
   include an identifier, ID_S, for itself (in the <ServerID> element)
   in the <ServerFinished> message.  The MAC value in the
   <ServerFinished> message shall be computed on the (ASCII) string "MAC
   1 computation", the server identifier ID_S, and R using a MAC key
   K_MAC.  Again, in contrast with [1], this key shall be provided
   together with K_TOKEN to the token, and hence there is no need for a
   K_AUTH for key confirmation purposes.

   If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
   s shall consist of the concatenation of the (ASCII) string "MAC 1
   computation" and R, and the parameter dsLen shall be set to the
   length of R:

   dsLen = len(R)

   MAC = CT-KIP-PRF (K_MAC, "MAC 1 computation" || ID_S || R, dsLen)

3.4.2.2.  Server authentication

   As discussed in Section 3.3.2, servers need to authenticate
   themselves when attempting to replace an existing K_TOKEN.  In 2-pass
   CT-KIP, servers authenticate themselves by including a second MAC
   value in the AuthenticationDataType extension.  The MAC value in the
   AuthenticationDataType extension shall be computed on the (ASCII)
   string "MAC 1 computation", the server identifier ID_S, and R, using
   the existing MAC key K_MAC' (the MAC key that existed before this
   protocol run).  The MAC algorithm shall be the same as the algorithm
   used for key confirmation purposes.

   If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
   s shall consist of the concatenation of the (ASCII) string "MAC 1
   computation" ID_S, and R. The parameter dsLen shall be set to at
   least 16 (i.e. the length of the MAC shall be at least 16 octets):

   dsLen >= 16

   MAC = CT-KIP-PRF (K_MAC', "MAC 1 computation" || ID_S || R, dsLen)








Nystroem & Machani       Expires August 27, 2007               [Page 11]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


4.  Security considerations

4.1.  Applicability of 4-pass CT-KIP security considerations

   This document extends [1], and therefore, the security considerations
   discussed in [1] apply here as well, with the following exceptions:

   o  Message re-ordering attacks cannot occur since in the CT-KIP
      variants described in this document each party sends at most one
      message each.

   o  The attack described in Section 5.5 of [1] where the attacker
      replaces a client-provided R_C with his own R'C does not apply as
      the client does not provide any entropy to K_TOKEN in the 1- and
      2-pass variants discussed here.  The attack as such (and its
      countermeasures) still applies, however, as it essentially is a
      man-in-the-middle attack.

   In addition, the 1- and 2-pass CT-KIP variants described in this
   document warrant some further security considerations that are
   discussed in the following.

4.2.  Security considerations specific to 1- and 2-pass CT-KIP

4.2.1.  Client contributions to K_TOKEN entropy

   In 4-pass CT-KIP, both the client and the server provide randomizing
   material to K_TOKEN , in a manner that allows both parties to verify
   that they did contribute to the resulting key.  In the 1- and 2-pass
   CT-KIP versions defined herein, only the server contributes to the
   entropy of K_TOKEN.  This means that a broken or compromised
   (pseudo-)random number generator in the server may cause more damage
   than it would in the 4-pass variant.  Server implementations should
   therefore take extreme care to ensure that this situation does not
   occur.

4.2.2.  Replay protection

   A 4-pass CT-KIP client knows that a server it is communicating with
   is "live" since the server must create a MAC on information sent by
   the client.  The same is true for 2-pass CT-KIP thanks to the
   requirement that the client sends R in the <ClientHello> message and
   that the server includes R in the MAC computation.  In 1-pass CT-KIP
   clients (tokens) that record the latest I used by a particular server
   (as identified by ID_S) will be able to detect replays.






Nystroem & Machani       Expires August 27, 2007               [Page 12]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


4.2.3.  Key confirmation

   4-pass CT-KIP servers provide key confirmation through the MAC on R_C
   in the <ServerFinished> message.  In the 1- and 2-pass CT-KIP
   variants described herein, key confirmation is provided by the MAC
   including I (in the 1-pass case) or R (2-pass case), using K_MAC.

4.2.4.  Server authentication

   CT-KIP servers must authenticate themselves whenever a successful CT-
   KIP 1- or 2-pass protocol run would result in an existing K_TOKEN
   being replaced by a K_TOKEN', or else a denial-of-service attack
   where an unauthorized CT-KIP server replaces a K_TOKEN with another
   key would be possible.  In 1- and 2-pass CT-KIP servers authenticate
   by including the AuthenticationDataType extension containing a MAC as
   described in Section 3.4 above.

4.2.5.  Key protection in the passphrase profile

   The passphrase-based key wrap profile uses the PBKDF2 function from
   [3] to generate an encryption key from a passphrase and salt string.
   The derived key, K_DERIVED is used by the server to encrypt K_TOKEN
   and by the token to decrypt the newly delivered K_TOKEN.  It is
   important to note that passphrase-based encryption is generally
   limited in the security that it provides despite the use of salt and
   iteration count in PBKDF2 to increase the complexity of attack.
   Implementations should therefore take additional measures to
   strengthen the security of the passphrase-based key wrap profile.
   The following measures should be considered where applicable:

   o  The passphrase should be selected well, and usage guidelines such
      as the ones in [9] should be taken into account.

   o  A different passphrase should be used for every key initialization
      wherever possible (the use of a global passphrase for a batch of
      tokens should be avoided, for example).  One way to achieve this
      is to use randomly-generated passphrases.

   o  The passphrase should be protected well if stored on the server
      and/or on the token and should be delivered to the token's user
      using secure methods.

   o  User pre-authentication should be implemented to ensure that
      K_TOKEN is not delivered to a rogue recipient.

   o  The iteration count in PBKDF2 should be high to impose more work
      for an attacker using brute-force methods (see [3] for
      recommendations).  However, it must be noted that the higher the



Nystroem & Machani       Expires August 27, 2007               [Page 13]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


      count, the more work is required on the legitimate token to
      decrypt the newly delivered K_TOKEN.  Servers may use relatively
      low iteration counts to accommodate tokens with limited processing
      power such as some PDA and cell phones when other security
      measures are implemented and the security of the passphrase-based
      key wrap method is not weakened.

   o  Transport level security (e.g.  TLS) should be used where possible
      to protect a 2-pass or 1-pass protocol run.  Transport level
      security provides a second layer of protection for the newly
      generated K_TOKEN.








































Nystroem & Machani       Expires August 27, 2007               [Page 14]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


5.  IANA considerations

   This document does not contain any considerations for IANA.
















































Nystroem & Machani       Expires August 27, 2007               [Page 15]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


6.  Intellectual property considerations

   RSA and RSA Security are registered trademarks or trademarks of RSA
   Security Inc. in the United States and/or other countries.  The names
   of other products and services mentioned may be the trademarks of
   their respective owners.













































Nystroem & Machani       Expires August 27, 2007               [Page 16]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


7.  Acknowledgements

   Thanks to all the participants at the OTPS workshops where this
   document has been discussed and on the OTPS mailing list for their
   review and comments related to this document.














































Nystroem & Machani       Expires August 27, 2007               [Page 17]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


8.  References

8.1.  Normative references

   [1]  Nystroem, M., "Cryptographic Token Key Initialization Protocol",
        RFC 4758, November 2006, <http://www.ietf.org/rfc/rfc4758.txt>.

   [2]  RSA Laboratories, "Cryptographic Token Interface Standard",
        PKCS #11 Version 2.20, June 2004,
        <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [3]  RSA Laboratories, "Password-Based Cryptography Standard",
        PKCS #5 Version 2.0, March 1999,
        <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [4]  W3C, "XML Signature Syntax and Processing", W3C Recommendation,
        February 2002,
        <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.

   [5]  W3C, "XML Encryption Syntax and Processing", W3C Recommendation,
        December 2002,
        <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.

   [6]  RSA Laboratories, "XML Schema for PKCS #5 Version 2.0", PKCS #5
        Version 2.0 Amd.1 (FINAL DRAFT), October 2006,
        <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [7]  RSA Laboratories, "PKCS #11 Mechanisms for the Cryptographic
        Token Key Initialization Protocol", PKCS #11 Version 2.20 Amd.2,
        December 2005, <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [8]  RSA Laboratories, "RSA Cryptography Standard", PKCS #1 Version
        2.1, June 2002, <http://www.rsasecurity.com/rsalabs/pkcs/>.

8.2.  Informative references

   [9]  National Institute of Standards and Technology, "Password
        Usage", FIPS 112, May 1985,
        <http://www.itl.nist.gov/fipspubs/fip112.htm>.












Nystroem & Machani       Expires August 27, 2007               [Page 18]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Appendix A.  XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   !-- $Revision: 1.7 $ $Date: 2006/10/14 18:52:48 $ -->

   <!-- Copyright (c) RSA, The Security Division of EMC, 2006. -->
   <!-- All rights reserved. -->
   <!-- License to copy and use this schema file is granted provided
        that it is identified as "RSA One-Time Password
        Specifications (OTPS) Cryptographic Token Key Initialization
        Protocol Version 1.0 Amd.1" in all material mentioning or
        referencing it.

        RSA makes no representations concerning either the
        merchantability of this schema or the suitability of this schema
        for any particular purpose. It is provided "as is" without
        express or implied warranty of any kind.
   -->
   <xs:schema
     targetNamespace="http://www.rsasecurity.com/rsalabs/otps/schemas
       /2006/05/ct-kip-two-pass#"
     xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas
       /2006/05/ct-kip-two-pass#"
     xmlns:ct-kip="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#">

    <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"/>

    <xs:import namespace="http://www.rsasecurity.com/rsalabs/otps/
       schemas/2005/12/ct-kip#"
     schemaLocation="ftp://ftp.rsasecurity.com/pub/otps/ct-kip/
       ct-kip-v1-0.xsd"/>

   <!-- Extended core types -->
   <xs:complexType name="ExtendedMacType">
     <xs:simpleContent>
       <xs:extension base="ct-kip:MacType">
         <xs:attribute name="Nonce" type="xs:nonNegativeInteger"
         use="required"/>
       </xs:extension>
     </xs:simpleContent>
   </xs:complexType>

   <!-- 1- and 2-pass extensions -->



Nystroem & Machani       Expires August 27, 2007               [Page 19]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   <xs:complexType name="TwoPassSupportType">
     <xs:annotation>
       <xs:documentation xml:lang="en">
         This extension is only valid in ClientHello PDUs. It informs
         the server of the client's support for the two-pass version of
         CT-KIP, and carries optional payload data associated with each
         supported two-pass key initialization method.
       </xs:documentation>
     </xs:annotation>
     <xs:complexContent>
       <xs:extension base="ct-kip:AbstractExtensionType">
         <xs:sequence maxOccurs="unbounded">
           <xs:element name="SupportedKeyInitializationMethod"
           type="xs:anyURI"/>
           <xs:element name="Payload" minOccurs="0"/>
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="KeyInitializationDataType">
     <xs:annotation>
       <xs:documentation xml:lang="en">
         This extension is only valid in ServerFinished PDUs. It
         contains key initialization data and its presence results in a
         two-pass (or one-pass, if no ClientHello was sent) CT-KIP
         exchange.
       </xs:documentation>
     </xs:annotation>
     <xs:complexContent>
       <xs:extension base="ct-kip:AbstractExtensionType">
         <xs:sequence>
           <xs:element name="KeyInitializationMethod" type="xs:anyURI"/>
           <xs:element name="Payload"/>
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="AuthenticationDataType">
     <xs:annotation>
       <xs:documentation xml:lang="en">
         This extension is only valid in ServerFinished PDUs. It
         contains a MAC authenticating the CT-KIP server to the token.
       </xs:documentation>
     </xs:annotation>
     <xs:complexContent>
       <xs:extension base="ct-kip:AbstractExtensionType">



Nystroem & Machani       Expires August 27, 2007               [Page 20]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


         <xs:sequence>
           <xs:element name="Mac" type="ExtendedMacType"/>
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   </xs:schema>











































Nystroem & Machani       Expires August 27, 2007               [Page 21]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Appendix B.  Key initialization profiles of CT-KIP

B.1.  Introduction

   This appendix introduces three profiles of CT-KIP for key
   initialization.  They may all be used for two- as well as one-pass
   initialization of cryptographic tokens.  Further profiles may be
   defined by external entities or through the OTPS process.

B.2.  Key transport profile

B.2.1.  Introduction

   This profile initializes the cryptographic token with a symmetric
   key, K_TOKEN, through key transport and key derivation.  The key
   transport is carried out using a public key, K_CLIENT, whose private
   key part resides in the token as the transport key.  A key K from
   which two keys, K_TOKEN and K_MAC are derived shall be transported.

B.2.2.  Identification

   This profile shall be identified with the following URI:

   http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
   ct-kip#transport

B.2.3.  Payloads

   In the two-pass version of CT-KIP, the client shall send a payload
   associated with this key initialization method.  The payload shall be
   of type ds:KeyInfoType ([4]), and only those choices of the ds:
   KeyInfoType that identify a public key are allowed.  The ds:
   X509Certificate option of the ds:X509Data alternative is recommended
   when the public key corresponding to the private key on the
   cryptographic token has been certified.

   The server payload associated with this key initialization method
   shall be of type xenc:EncryptedKeyType ([5]), and only those
   encryption methods utilizing a public key that are supported by the
   CT-KIP client (as indicated in the <SupportedEncryptionAlgorithms>
   element of the <ClientHello> message in the case of 2-pass CT-KIP, or
   as otherwise known in the case of 1-pass CT-KIP) are allowed as
   values for the <xenc:EncryptionMethod> element.  Further, in the case
   of 2-pass CT-KIP, the <ds:KeyInfo> element shall contain the same
   value (i.e. identify the same public key) as the <Payload> of the
   corresponding supported key initialization method in the
   <ClientHello> message that triggered the response.  The
   <CarriedKeyName> element may be present, but shall, when present,



Nystroem & Machani       Expires August 27, 2007               [Page 22]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   contain the same value as the <KeyID> element of the <ServerFinished>
   message.  The Type attribute of the xenc:EncryptedKeyType shall be
   present and shall identify the type of the wrapped token key.  The
   type shall be one of the types supported by the CT-KIP client (as
   reported in the <SupportedKeyTypes> of the preceding <ClientHello>
   message in the case of 2-pass CT-KIP, or as otherwise known in the
   case of 1-pass CT-KIP).  The transported key shall consist of two
   parts of equal length.  The first half constitutes K_MAC and the
   second half constitutes K_TOKEN.  The length of K_TOKEN (and hence
   also the length of K_MAC) is determined by the type of K_TOKEN.

   CT-KIP servers and tokens supporting this profile must support the
   http://www.w3.org/2001/04/xmlenc#rsa-1_5 key-wrapping mechanism
   defined in [5].

   When this profile is used, the MacAlgorithm attribute of the <Mac>
   element of the <ServerFinished> message must be present and must
   identify the selected MAC algorithm.  The selected MAC algorithm must
   be one of the MAC algorithms supported by the CT-KIP client (as
   indicated in the <SupportedMACAlgorithms> element of the
   <ClientHello> message in the case of 2-pass CT-KIP, or as otherwise
   known in the case of 1-pass CT-KIP).  The MAC shall be calculated as
   described in Section 3.4

   In addition, CT-KIP servers must include the AuthenticationDataType
   extension (see further Section 3.4) in their <ServerFinished>
   messages whenever a successful protocol run will result in an
   existing K_TOKEN being replaced.

B.3.  Key wrap profile

B.3.1.  Introduction

   This profile initializes the cryptographic token with a symmetric
   key, K_TOKEN, through key wrap and key derivation.  The key wrap
   shall be carried out using a (symmetric) key-wrapping key, K_SHARED,
   known in advance by both the token and the CT-KIP server.  A key K
   from which two keys, K_TOKEN and K_MAC are derived shall be wrapped.

B.3.2.  Identification

   This profile shall be identified with the following URI:

   http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/ct-kip#wrap







Nystroem & Machani       Expires August 27, 2007               [Page 23]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


B.3.3.  Payloads

   In the 2-pass version of CT-KIP, the client shall send a payload
   associated with this key initialization method.  The payload shall be
   of type ds:KeyInfoType ([4]), and only those choices of the ds:
   KeyInfoType that identify a symmetric key are allowed.  The ds:
   KeyName alternative is recommended.

   The server payload associated with this key initialization method
   shall be of type xenc:EncryptedKeyType ([5]), and only those
   encryption methods utilizing a symmetric key that are supported by
   the CT-KIP client (as indicated in the
   <SupportedEncryptionAlgorithms> element of the <ClientHello> message
   in the case of 2-pass CT-KIP, or as otherwise known in the case of
   1-pass CT-KIP) are allowed as values for the <xenc:EncryptionMethod>
   element.  Further, in the case of 2-pass CT-KIP, the <ds:KeyInfo>
   element shall contain the same value (i.e. identify the same
   symmetric key) as the <Payload> of the corresponding supported key
   initialization method in the <ClientHello> message that triggered the
   response.  The <CarriedKeyName> element may be present, and shall,
   when present, contain the same value as the <KeyID> element of the
   <ServerFinished> message.  The Type attribute of the xenc:
   EncryptedKeyType shall be present and shall identify the type of the
   wrapped token key.  The type shall be one of the types supported by
   the CT-KIP client (as reported in the <SupportedKeyTypes> of the
   preceding <ClientHello> message in the case of 2-pass CT-KIP, or as
   otherwise known in the case of 1-pass CT-KIP).  The wrapped key shall
   consist of two parts of equal length.  The first half constitutes
   K_MAC and the second half constitutes K_TOKEN.  The length of K_TOKEN
   (and hence also the length of K_MAC) is determined by the type of
   K_TOKEN.

   CT-KIP servers and tokens supporting this profile must support the
   http://www.w3.org/2001/04/xmlenc#kw-aes128 key-wrapping mechanism
   defined in [5].

   When this profile is used, the MacAlgorithm attribute of the <Mac>
   element of the <ServerFinished> message must be present and must
   identify the selected MAC algorithm.  The selected MAC algorithm must
   be one of the MAC algorithms supported by the CT-KIP client (as
   indicated in the <SupportedMACAlgorithms> element of the
   <ClientHello> message in the case of 2-pass CT-KIP, or as otherwise
   known in the case of 1-pass CT-KIP).  The MAC shall be calculated as
   described in Section 3.4

   In addition, CT-KIP servers must include the AuthenticationDataType
   extension (see further Section 3.4) in their <ServerFinished>
   messages whenever a successful protocol run will result in an



Nystroem & Machani       Expires August 27, 2007               [Page 24]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   existing K_TOKEN being replaced.

B.4.  Passphrase-based key wrap profile

B.4.1.  Introduction

   This profile is a variation of the key wrap profile.  It initializes
   the cryptographic token with a symmetric key, K_TOKEN, through key
   wrap and key derivation, using a passphrase-derived key-wrapping key,
   K_DERIVED.  The passphrase is known in advance by both the token user
   and the CT-KIP server.  To preserve the property of not exposing
   K_TOKEN to any other entity than the CT_KIP server and the token
   itself, the method should be employed only when the token contains
   facilities (e.g. a keypad) for direct entry of the passphrase.  A key
   K from which two keys, K_TOKEN and K_MAC are derived shall be
   wrapped.

B.4.2.  Identification

   This profile shall be identified with the following URI:

   http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
   ct-kip#passphrase-wrap

B.4.3.  Payloads

   In the 2-pass version of CT-KIP, the client shall send a payload
   associated with this key initialization method.  The payload shall be
   of type ds:KeyInfoType ([4]).  The ds:KeyName option shall be used
   and the key name shall identify the passphrase that will be used by
   the server to generate the key-wrapping key.  As an example, the
   identifier could be a user identifier or a registration identifier
   issued by the server to the user during a session preceding the CT-
   KIP protocol run.

   The server payload associated with this key initialization method
   shall be of type xenc:EncryptedKeyType ([5]), and only those
   encryption methods utilizing a passphrase to derive the key-wrapping
   key that are supported by the CT-KIP client (as indicated in the
   <SupportedEncryptionAlgorithms> element of the <ClientHello> message
   in the case of 2-pass CT-KIP, or as otherwise known in the case of
   1-pass CT-KIP) are allowed as values for the <xenc:EncryptionMethod>
   element.  Further, in the case of 2-pass CT-KIP, the <ds:KeyInfo>
   element shall contain the same value (i.e. identify the same
   passphrase) as the <Payload> of the corresponding supported key
   initialization method in the <ClientHello> message that triggered the
   response.  The <CarriedKeyName> element may be present, and shall,
   when present, contain the same value as the <KeyID> element of the



Nystroem & Machani       Expires August 27, 2007               [Page 25]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   <ServerFinished> message.  The Type attribute of the xenc:
   EncryptedKeyType shall be present and shall identify the type of the
   wrapped token key.  The type shall be one of the types supported by
   the CT-KIP client (as reported in the <SupportedKeyTypes> of the
   preceding <ClientHello> message in the case of 2-pass CT-KIP, or as
   otherwise known in the case of 1-pass CT-KIP).  The wrapped key shall
   consist of two parts of equal length.  The first half constitutes
   K_MAC and the second half constitutes K_TOKEN.  The length of K_TOKEN
   (and hence also the length of K_MAC) is determined by the type of
   K_TOKEN.

   CT-KIP servers and tokens supporting this profile must support the
   PBES2 password based encryption scheme defined in [3] (and identified
   as http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in
   [6]), the PBKDF2 passphrase-based key derivation function also
   defined in [3] (and identified as
   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 in
   [6]), and the http://www.w3.org/2001/04/xmlenc#kw-aes128 key-wrapping
   mechanism defined in [5].

   When this profile is used, the MacAlgorithm attribute of the <Mac>
   element of the <ServerFinished> message must be present and must
   identify the selected MAC algorithm.  The selected MAC algorithm must
   be one of the MAC algorithms supported by the CT-KIP client (as
   indicated in the <SupportedMACAlgorithms> element of the
   <ClientHello> message in the case of 2-pass CT-KIP, or as otherwise
   known in the case of 1-pass CT-KIP).  The MAC shall be calculated as
   described in Section 3.4

   In addition, CT-KIP servers must include the AuthenticationDataType
   extension (see further Section 3.4) in their <ServerFinished>
   messages whenever a successful protocol run will result in an
   existing K_TOKEN being replaced.


















Nystroem & Machani       Expires August 27, 2007               [Page 26]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Appendix C.  Example messages

C.1.  Note regarding the examples

   All examples are syntactically correct.  MAC and cipher values are
   fictitious however.  The examples illustrate a complete two-pass CT-
   KIP exchange.  The server messages may also constitute the only
   messages in a one-pass CT-KIP exchange.

C.2.  Example of a <ClientHello> message indicating support for two-pass
      CT-KIP

   The client indicates support both for the two-pass key transport
   variant as well as the two-pass key wrap variant.





































Nystroem & Machani       Expires August 27, 2007               [Page 27]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <ClientHello
     xmlns:ct-kip=
     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     Version="1.0">
     <TokenID>12345678</TokenID>
     <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.w3.org/2001/04/xmlenc#kw-aes128</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>
     <Extensions>
       <Extension xsi:type="ct-kip:TwoPassSupportType">
         <SupportedKeyInitializationMethod>
         http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
         ct-kip#wrap
         </SupportedKeyInitializationMethod>
         <Payload xsi:type="ds:KeyInfoType">
           <ds:KeyName>Key-001</ds:KeyName>
         </Payload>
        <SupportedKeyInitializationMethod>
        http://www.rsasecurity.com/rsalabs/otps/schemas
        /2005/12/ct-kip#transport
        </SupportedKeyInitializationMethod>
         <Payload xsi:type="ds:KeyInfoType">
           <ds:X509Data>
             <ds:X509Certificate>miib</ds:X509Certificate>
           </ds:X509Data>
         </Payload>
       </Extension>
     </Extensions>
   </ClientHello>





Nystroem & Machani       Expires August 27, 2007               [Page 28]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


C.3.  Example of a <ServerFinished> message using the key transport
      profile

   In this example, the server responds to the previous request using
   the key transport profile.














































Nystroem & Machani       Expires August 27, 2007               [Page 29]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <ServerFinished
     xmlns:ct-kip=
     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
     Version="1.0" SessionID="4114" Status="Success">
     <TokenID>12345678</TokenID>
     <KeyID>43212093</KeyID>
     <KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
     <ServiceID>Example Enterprise Name</ServiceID>
     <UserID>exampleLoginName</UserID>
     <Extensions>
       <Extension xsi:type="ct-kip:KeyInitializationDataType">
         <KeyInitializationMethod>
           http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
           ct-kip#transport</KeyInitializationMethod>
         <Payload xsi:type="xenc:EncryptedKeyType"
          Type="http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
          otps-wst#SecurID-AES">
           <xenc:EncryptionMethod
           Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
           <ds:KeyInfo>
             <ds:X509Data>
               <ds:X509Certificate>miib</ds:X509Certificate>
             </ds:X509Data>
           </ds:KeyInfo>
           <xenc:CipherData>
             <xenc:CipherValue>abcd</xenc:CipherValue>
           </xenc:CipherData>
           <xenc:CarriedKeyName>43212093</xenc:CarriedKeyName>
         </Payload>
       </Extension>
       <Extension xsi:type="ct-kip:OTPKeyConfigurationDataType">
         <OTPFormat>Decimal</OTPFormat>
         <OTPLength>6</OTPLength>
         <OTPMode><Time/></OTPMode>
       </Extension>
     </Extensions>
     <Mac
     MacAlgorithm="http://www.rsasecurity.com/rsalabs/otps/schemas
     /2005/11/ct-kip#ct-kip-prf-aes">miidfasde312asder394jw==
     </Mac>
   </ServerFinished>






Nystroem & Machani       Expires August 27, 2007               [Page 30]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


C.4.  Example of a <ServerFinished> message using the key wrap profile

   In this example, the server responds to the previous request using
   the key wrap profile.

   <?xml version="1.0" encoding="UTF-8"?>
   <ServerFinished
     xmlns:ct-kip=
     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
     Version="1.0" SessionID="4114" Status="Success">
     <TokenID>12345678</TokenID>
     <KeyID>43212093</KeyID>
     <KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
     <ServiceID>Example Enterprise Name</ServiceID>
     <UserID>exampleLoginName</UserID>
     <Extensions>
       <Extension xsi:type="ct-kip:KeyInitializationDataType">
         <KeyInitializationMethod>
           http://www.rsasecurity.com/rsalabs/otps/schemas
           /2006/05/ct-kip#wrap</KeyInitializationMethod>
         <Payload xsi:type="xenc:EncryptedKeyType"
          Type="http://www.rsasecurity.com/rsalabs/otps/schemas
          /2005/09/otps-wst#SecurID-AES">
           <xenc:EncryptionMethod
           Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
           <ds:KeyInfo>
             <ds:KeyName>Key-001</ds:KeyName>
           </ds:KeyInfo>
           <xenc:CipherData>
             <xenc:CipherValue>abcd</xenc:CipherValue>
           </xenc:CipherData>
           <xenc:CarriedKeyName>43212093</xenc:CarriedKeyName>
         </Payload>
       </Extension>
       <Extension xsi:type="ct-kip:OTPKeyConfigurationDataType">
         <OTPFormat>Decimal</OTPFormat>
         <OTPLength>6</OTPLength>
         <OTPMode><Time/></OTPMode>
       </Extension>
     </Extensions>
     <Mac MacAlgorithm="http://www.rsasecurity.com/rsalabs/otps/schemas
     /2005/12/ct-kip#ct-kip-prf-aes">miidfasde312asder394jw==
     </Mac>
   </ServerFinished>




Nystroem & Machani       Expires August 27, 2007               [Page 31]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


C.5.  Example of a <ServerFinished> message using the passphrase-based
      key wrap profile

   In this example, the server responds to the previous request using
   the passphrase-based key wrap profile.

   <?xml version="1.0" encoding="UTF-8"?>
   <ServerFinished
     xmlns:ct-kip=
     "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:xenc=http://www.w3.org/2001/04/xmlenc#
     xmlns:pkcs-5=
     "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
     Version="1.0" SessionID="4114" Status="Success">
     <TokenID>12345678</TokenID>
     <KeyID>43212093</KeyID>
     <KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
     <ServiceID>Example Enterprise Name</ServiceID>
     <UserID>exampleLoginName</UserID>
     <Extensions>
       <Extension xsi:type="ct-kip-two-pass:KeyInitializationDataType">
         <KeyInitializationMethod>
           http://www.rsasecurity.com/rsalabs/otps/schemas/2006/03
           /ct-kip#passphrase-wrap</KeyInitializationMethod>
         <Payload xsi:type="xenc:EncryptedKeyType"
          Type="http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
          otps-wst#SecurID-AES">
           <xenc:EncryptionMethod
            Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas
            /pkcs-5#pbes2">
             <pkcs-5:PBES2-params>
               <KeyDerivationFunc Algorithm="http://www.rsasecurity.com
               /rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
                 <pkcs-5:PBKDF2-params>
                   <Salt>
                     <Specified>32113435</Specified>
                   </Salt>
                   <IterationCount>1024</IterationCount>
                   <KeyLength>128</KeyLength>
                   <PRF/>
                 </pkcs-5:PBKDF2-params>
               </KeyDerivationFunc>
                <EncryptionScheme Algorithm="http://www.w3.org/2001/04
                /xmlenc#kw-aes128-cbc">
             </EncryptionScheme>
         </pkcs-5:PBES2-params>



Nystroem & Machani       Expires August 27, 2007               [Page 32]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


           </xenc:EncryptionMethod>
           <ds:KeyInfo>
         <ds:KeyName>Passphrase1</ds:KeyName>
           </ds:KeyInfo>
           <xenc:CipherData>
           <xenc:CipherValue>
               ZWcLvpFoXNHAG+lx3+Rww/Sic+o
             </xenc:CipherValue>
           </xenc:CipherData>
           <xenc:CarriedKeyName>43212093</xenc:CarriedKeyName>
         </Payload>
       </Extension>
       <Extension xsi:type="ct-kip:OTPKeyConfigurationDataType">
         <OTPFormat>Decimal</OTPFormat>
         <OTPLength>6</OTPLength>
         <OTPMode><Time/></OTPMode>
       </Extension>
     </Extensions>
     <Mac MacAlgorithm="http://www.rsasecurity.com/rsalabs/otps/schemas
       /2005/12/ct-kip#ct-kip-prf-aes">miidfasde312asder394jw==
     </Mac>
   </ServerFinished>





























Nystroem & Machani       Expires August 27, 2007               [Page 33]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Appendix D.  Integration with PKCS #11

D.1.  The 2-pass variant

   A suggested procedure to perform 2-pass CT-KIP with a cryptographic
   token through the PKCS #11 interface using the mechanisms defined in
   [7] is as follows (see also [1]):

   a.  On the client side,

       1.  The client selects a suitable slot and token (e.g. through
           use of the <TokenID> or the <PlatformInfo> element of the CT-
           KIP trigger message).

       2.  A nonce R is generated, e.g. by calling C_SeedRandom and
           C_GenerateRandom.

       3.  The client sends its first message to the server, including
           the nonce R.

   b.  On the server side,

       1.  A generic key K = K_TOKEN | K _MAC (where '|' denotes
           concatenation) is generated, e.g. by calling C_GenerateKey
           (using key type CKK_GENERIC_SECRET).  The template for K
           shall allow it to be exported (but only in wrapped form, i.e.
           CKA_SENSITIVE shall be set to CK_TRUE and CKA_EXTRACTABLE
           shall also be set to CK_TRUE), and also to be used for
           further key derivation.  From K, a token key K_TOKEN of
           suitable type is derived by calling C_DeriveKey using the
           PKCS #11 mechanism CKM_EXTRACT_KEY_FROM_KEY and setting the
           CK_EXTRACT_PARAMS to the first bit of the generic secret key
           (i.e. set to 0).  Likewise, a MAC key K_MAC is derived from K
           by calling C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY
           mechanism, this time setting CK_EXTRACT_PARAMS to the length
           of K (in bits) divided by two.

       2.  The server wraps K with either the token's public key
           K_CLIENT, the shared secret key K_SHARED, or the derived
           shared secret key K_DERIVED by using C_WrapKey.  If use of
           the CT-KIP key wrap algorithm has been negotiated then the
           CKM_KIP_WRAP mechanism shall be used to wrap K. When calling
           C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure
           shall be set to NULL_PTR.  The pSeed parameter in the
           CK_KIP_PARAMS structure shall point to the nonce R provided
           by the CT-KIP client, and the ulSeedLen parameter shall
           indicate the length of R. The hWrappingKey parameter in the
           call to C_WrapKey shall be set to refer to the wrapping key.



Nystroem & Machani       Expires August 27, 2007               [Page 34]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


       3.  Next, the server needs to calculate a MAC using K_MAC.  If
           use of the CT-KIP MAC algorithm has been negotiated, then the
           MAC is calculated by calling C_SignInit with the CKM_KIP_MAC
           mechanism followed by a call to C_Sign.  In the call to
           C_SignInit, K_MAC shall be the signature key, the hKey
           parameter in the CK_KIP_PARAMS structure shall be set to
           NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure
           shall be set to NULL_PTR, and the ulSeedLen parameter shall
           be set to zero.  In the call to C_Sign, the pData parameter
           shall be set to the concatenation of the string ID_S and the
           nonce R, and the ulDataLen parameter shall be set to the
           length of the concatenated string.  The desired length of the
           MAC shall be specified through the pulSignatureLen parameter
           and shall be set to the length of R.

       4.  If the server also needs to authenticate its message (due to
           an existing K_TOKEN being replaced), the server shall
           calculate a second MAC.  Again, if use of the CT-KIP MAC
           algorithm has been negotiated, then the MAC is calculated by
           calling C_SignInit with the CKM_KIP_MAC mechanism followed by
           a call to C_Sign.  In this call to C_SignInit, the K_MAC
           existing before this CT-KIP protocol run shall be the
           signature key, the hKey parameter in the CK_KIP_PARAMS
           structure shall be set to NULL, the pSeed parameter of the
           CT_KIP_PARAMS structure shall be set to NULL_PTR, and the
           ulSeeidLen parameter shall be set to zero.  In the call to
           C_Sign, the pData parameter shall be set to the concatenation
           of the string ID_S and the nonce R, and the ulDataLen
           parameter shall be set to the length of concatenated string.
           The desired length of the MAC shall be specified through the
           pulSignatureLen parameter and shall be set to the length of
           R.

       5.  The server sends its message to the client, including the
           wrapped key K, the MAC and possibly also the authenticating
           MAC.

   c.  On the client side,

       1.  The client calls C_UnwrapKey to receive a handle to K. After
           this, the client calls C_DeriveKey twice: Once to derive
           K_TOKEN and once to derive K_MAC.  The client shall use the
           same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same
           mechanism parameters as used by the server above.  When
           calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter
           shall be used to set additional key attributes in accordance
           with local policy and as negotiated and expressed in the
           protocol.  In particular, the value of the <KeyID> element in



Nystroem & Machani       Expires August 27, 2007               [Page 35]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


           the server's response message may be used as CKA_ID for
           K_TOKEN.  The key K shall be destroyed after deriving K_TOKEN
           and K_MAC.

       2.  The MAC is verified in a reciprocal fashion as it was
           generated by the server.  If use of the CKM_KIP_MAC mechanism
           has been negotiated, then in the call to C_VerifyInit, the
           hKey parameter in the CK_KIP_PARAMS structure shall be set to
           NULL_PTR, the pSeed parameter shall be set to NULL_PTR, and
           ulSeedLen shall be set to 0.  The hKey parameter of
           C_VerifyInit shall refer to K_MAC.  In the call to C_Verify,
           pData shall be set to the concatenation of the string ID_S
           and the nonce R, and the ulDataLen parameter shall be set to
           the length of the concatenated string, pSignature to the MAC
           value received from the server, and ulSignatureLen to the
           length of the MAC.  If the MAC does not verify the protocol
           session ends with a failure.  The token shall be constructed
           to not "commit" to the new K_TOKEN or the new K_MAC unless
           the MAC verifies.

       3.  If an authenticating MAC was received (required if the new
           K_TOKEN will replace an existing key on the token), then it
           is verified in a similar vein but using the K_MAC associated
           with this server and existing before the protocol run.
           Again, if the MAC does not verify the protocol session ends
           with a failure, and the token must be constructed no to
           "commit" to the new K_TOKEN or the new K_MAC unless the MAC
           verifies.

D.2.  The 1-pass variant

   A suggested procedure to perform 1-pass CT-KIP with a cryptographic
   token through the PKCS #11 interface using the mechanisms defined in
   [7] is as follows (see also [1]):

   a.  On the server side,

       1.  A generic key K = K_TOKEN | K _MAC (where '|' denotes
           concatenation) is generated, e.g. by calling C_GenerateKey
           (using key type CKK_GENERIC_SECRET).  The template for K
           shall allow it to be exported (but only in wrapped form, i.e.
           CKA_SENSITIVE shall be set to CK_TRUE and CKA_EXTRACTABLE
           shall also be set to CK_TRUE), and also to be used for
           further key derivation.  From K, a token key K_TOKEN of
           suitable type is derived by calling C_DeriveKey using the
           PKCS #11 mechanism CKM_EXTRACT_KEY_FROM_KEY and setting the
           CK_EXTRACT_PARAMS to the first bit of the generic secret key
           (i.e. set to 0).  Likewise, a MAC key K_MAC is derived from K



Nystroem & Machani       Expires August 27, 2007               [Page 36]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


           by calling C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY
           mechanism, this time setting CK_EXTRACT_PARAMS to the length
           of K (in bits) divided by two.

       2.  The server wraps K with either the token's public key,
           K_CLIENT, the shared secret key, K_SHARED, or the derived
           shared secret key, K_DERIVED by using C_WrapKey.  If use of
           the CT-KIP key wrap algorithm has been negotiated, then the
           CKM_KIP_WRAP mechanism shall be used to wrap K. When calling
           C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure
           shall be set to NULL_PTR.  The pSeed parameter in the
           CK_KIP_PARAMS structure shall point to the octet-string
           representation of an integer I whose value shall be
           incremented before each protocol run, and the ulSeedLen
           parameter shall indicate the length of the octet-string
           representation of I. The hWrappingKey parameter in the call
           to C_WrapKey shall be set to refer to the wrapping key.

           Note: The integer-to-octet string conversion shall be made
           using the I2OSP primitive from [8].  There shall be no
           leading zeros.

       3.  For the server's message to the client, if use of the CT-KIP
           MAC algorithm has been negotiated, then the MAC is calculated
           by calling C_SignInit with the CKM_KIP_MAC mechanism followed
           by a call to C_Sign.  In the call to C_SignInit, K_MAC shall
           be the signature key, the hKey parameter in the CK_KIP_PARAMS
           structure shall be set to NULL_PTR, the pSeed parameter of
           the CT_KIP_PARAMS structure shall be set to NULL_PTR, and the
           ulSeedLen parameter shall be set to zero.  In the call to
           C_Sign, the pData parameter shall be set to the concatenation
           of the string ID_S and the octet-string representation of the
           integer I, and the ulDataLen parameter shall be set to the
           length of concatenated string.  The desired length of the MAC
           shall be specified through the pulSignatureLen parameter as
           usual, and shall be equal to, or greater than, sixteen (16).

       4.  If the server also needs to authenticate its message (due to
           an existing K_TOKEN being replaced), the server calculates a
           second MAC.  If the CT-KIP MAC mechanism is used, the server
           does this by calling C_SignInit with the CKM_KIP_MAC
           mechanism followed by a call to C_Sign.  In the call to
           C_SignInit, the K_MAC existing on the token before this
           protocol run shall be the signature key, the hKey parameter
           in the CK_KIP_PARAMS structure shall be set to NULL_PTR, the
           pSeed parameter of the CT_KIP_PARAMS structure shall be set
           to NULL_PTR, and the ulSeedLen parameter shall be set to
           zero.  In the call to C_Sign, the pData parameter shall be



Nystroem & Machani       Expires August 27, 2007               [Page 37]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


           set to the concatenation of the string ID_S and the octet-
           string representation of the integer I+1 (i.e.  I shall be
           incremented before each use), and the ulDataLen parameter
           shall be set to the length of the concatenated string.  The
           desired length of the MAC shall be specified through the
           pulSignatureLen parameter as usual, and shall be equal to, or
           greater than, sixteen (16).

       5.  The server sends its message to the client, including the MAC
           and possibly also the authenticating MAC.

   b.  On the client side,

       1.  The client calls C_UnwrapKey to receive a handle to K. After
           this, the client calls C_DeriveKey twice: Once to derive
           K_TOKEN and once to derive K_MAC.  The client shall use the
           same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same
           mechanism parameters as used by the server above.  When
           calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter
           shall be used to set additional key attributes in accordance
           with local policy and as negotiated and expressed in the
           protocol.  In particular, the value of the <KeyID> element in
           the server's response message may be used as CKA_ID for
           K_TOKEN.  The key K shall be destroyed after deriving K_TOKEN
           and K_MAC.

       2.  The MAC is verified in a reciprocal fashion as it was
           generated by the server.  If use of the CKM_KIP_MAC mechanism
           has been negotiated, then in the call to C_VerifyInit, the
           hKey parameter in the CK_KIP_PARAMS structure shall be set to
           NULL_PTR, the pSeed parameter shall be set to NULL_PTR, and
           ulSeedLen shall be set to 0.  The hKey parameter of
           C_VerifyInit shall refer to K_MAC.  In the call to C_Verify,
           pData shall be set to the concatenation of the string ID_S
           and the octet-string representation of the provided value for
           I, and the ulDataLen parameter shall be set to the length of
           the concatenated string, pSignature to the MAC value received
           from the server, and ulSignatureLen to the length of the MAC.
           If the MAC does not verify or if the provided value of I is
           not larger than any stored value I' for the identified server
           ID_S the protocol session ends with a failure.  The token
           shall be constructed to not "commit" to the new K_TOKEN or
           the new K_MAC unless the MAC verifies.  If the verification
           succeeds, the token shall store the provided value of I as a
           new I' for ID_S.






Nystroem & Machani       Expires August 27, 2007               [Page 38]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


       3.  If an authenticating MAC was received (required if K_TOKEN
           will replace an existing key on the token), it is verified in
           a similar vein but using the K_MAC existing before the
           protocol run.  Again, if the MAC does not verify the protocol
           session ends with a failure, and the token must be
           constructed no to "commit" to the new K_TOKEN or the new
           K_MAC unless the MAC verifies.












































Nystroem & Machani       Expires August 27, 2007               [Page 39]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Appendix E.  About OTPS

   The One-Time Password Specifications are documents produced by RSA
   Laboratories in cooperation with secure systems developers for the
   purpose of simplifying integration and management of strong
   authentication technology into secure applications, and to enhance
   the user experience of this technology.

   Further development of the OTPS series will occur through mailing
   list discussions and occasional workshops, and suggestions for
   improvement are welcome.  As for our PKCS documents, results may also
   be submitted to standards forums.  For more information, contact:

   OTPS Editor
   RSA, The Security Division of EMC
   174 Middlesex Turnpike
   Bedford, MA  01730 USA
   otps-editor@rsasecurity.com
   http://www.rsasecurity.com/rsalabs/
































Nystroem & Machani       Expires August 27, 2007               [Page 40]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Authors' Addresses

   Magnus Nystroem
   RSA, The Security Division of EMC

   Email: magnus@rsasecurity.com


   Salah Machani
   Diversinet Corp.

   Email: smachani@diversinet.com







































Nystroem & Machani       Expires August 27, 2007               [Page 41]


Internet-Draft            1- and 2-pass CT-KIP             February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Nystroem & Machani       Expires August 27, 2007               [Page 42]