Network Working Group                                        M. Nystroem
Internet-Draft                                              RSA Security
Expires: November 20, 2006                                    S. Machani
                                                              Diversinet
                                                            May 19, 2006


  Extensions to CT-KIP to support one- and two-pass key initialization
                     draft-nystrom-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 November 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.






Nystroem & Machani      Expires November 20, 2006               [Page 1]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 . . . . . . . . 21
     B.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 21
     B.2.  Key transport profile  . . . . . . . . . . . . . . . . . . 21
       B.2.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 21
       B.2.2.  Identification . . . . . . . . . . . . . . . . . . . . 21
       B.2.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 21
     B.3.  Key wrap profile . . . . . . . . . . . . . . . . . . . . . 22
       B.3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 22
       B.3.2.  Identification . . . . . . . . . . . . . . . . . . . . 22
       B.3.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 22
     B.4.  Passphrase-based key wrap profile  . . . . . . . . . . . . 23
       B.4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 23



Nystroem & Machani      Expires November 20, 2006               [Page 2]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


       B.4.2.  Identification . . . . . . . . . . . . . . . . . . . . 24
       B.4.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 24
   Appendix C.  Example messages  . . . . . . . . . . . . . . . . . . 26
     C.1.  Note regarding the examples  . . . . . . . . . . . . . . . 26
     C.2.  Example of a <ClientHello> message indicating support
           for two-pass CT-KIP  . . . . . . . . . . . . . . . . . . . 26
     C.3.  Example of a <ServerFinished> message using the key
           transport profile  . . . . . . . . . . . . . . . . . . . . 28
     C.4.  Example of a <ServerFinished> message using the key
           wrap profile . . . . . . . . . . . . . . . . . . . . . . . 30
     C.5.  Example of a <ServerFinished> message using the
           passphrase-based key wrap profile  . . . . . . . . . . . . 31
   Appendix D.  Integration with PKCS #11 . . . . . . . . . . . . . . 33
     D.1.  The 2-pass variant . . . . . . . . . . . . . . . . . . . . 33
     D.2.  The 1-pass variant . . . . . . . . . . . . . . . . . . . . 35
   Appendix E.  About OTPS  . . . . . . . . . . . . . . . . . . . . . 38
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
   Intellectual Property and Copyright Statements . . . . . . . . . . 40

































Nystroem & Machani      Expires November 20, 2006               [Page 3]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 two profiles of CT-KIP.

   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 November 20, 2006               [Page 4]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 CT-KIP client (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 November 20, 2006               [Page 5]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 etc.  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, etc. 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 November 20, 2006               [Page 6]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   <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="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.

   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
   extension and the client indicated support for the selected key
   initialization method.  Servers must include this extension in a



Nystroem & Machani      Expires November 20, 2006               [Page 7]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   <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="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.

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 November 20, 2006               [Page 8]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   <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="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 2 computation", the server
   identifier ID_S, and a monotonically increasing, unsigned integer
   value I guaranteed not to be used again by this server (This could 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), using a MAC key
   K_MAC.  In contrast to [1], this key shall be provided together with
   K_TOKEN to the client, 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.

   If CT-KIP-PRF is used as the MAC algorithm, then the input parameter



Nystroem & Machani      Expires November 20, 2006               [Page 9]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   s shall consist of the concatenation of the (ASCII) string "MAC 2
   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 2 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 3 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). 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 3
   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 3 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 November 20, 2006              [Page 10]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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
   2 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 client, 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 2
   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 2 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 3 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 3
   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 3 computation" || ID_S || R, dsLen)








Nystroem & Machani      Expires November 20, 2006              [Page 11]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


4.  Security considerations

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

   This document extends [1], and the security considerations discussed
   in [1] therefore applies here as well, but with some 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 Client Hello 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 November 20, 2006              [Page 12]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 password-based encryption is generally limited
   in the security that it provides and despite the use of use of salt
   and iteration count in PBKDF2 to increase the complexity of attack;
   Implementations should 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.  (E.g. the use of a global passphrase for a
      batch of tokens should be avoided).  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 workstation.

   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 November 20, 2006              [Page 13]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


      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 taken and the security of the password-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 November 20, 2006              [Page 14]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


5.  IANA considerations

   This document does not contain any considerations for IANA.
















































Nystroem & Machani      Expires November 20, 2006              [Page 15]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


6.  Intellectual property considerations

   RSA Security intends to file an IETF IPR disclosure for IPR related
   to this document.  Until then, a disclosure can be found in [1].  RSA
   Security makes no representations regarding intellectual property
   claims by other parties.  Such determination is the responsibility of
   the user.

   RSA, RSA Security 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 & Machani      Expires November 20, 2006              [Page 16]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 November 20, 2006              [Page 17]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


8.  References

8.1.  Normative references

   [1]  RSA Laboratories, "Cryptographic Token Key Initialization
        Protocol", CT-KIP Version 1.0, December 2005,
        <http://www.rsasecurity.com/rsalabs/otps/>.

   [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 (DRAFT 2), May 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 November 20, 2006              [Page 18]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


Appendix A.  XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <!-- Copyright (c) RSA Security Inc. 2006. All rights reserved. -->
   <xs:schema
     targetNamespace=
     "http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
      ct-kip-two-pass#"
     xmlns:ct-kip-two-pass="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#"
     xmlns=
     "http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
     ct-kip-two-pass#">

   <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="ct-kip.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 -->
   <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>



Nystroem & Machani      Expires November 20, 2006              [Page 19]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


     <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="AbstractExtensionType">
         <xs:sequence>
           <xs:element name="Mac" type="ExtendedMacType"/>
         </xs:sequence>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>
   </xs:schema>





Nystroem & Machani      Expires November 20, 2006              [Page 20]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


Appendix B.  Key initialization profiles of CT-KIP

B.1.  Introduction

   This appendix introduces three profiles of CT-KIP for key
   initialization.  They may both be used for two- as well as one-pass
   initialization of cryptographic tokens.  Further profiles may be
   defined by external identities 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

   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) are allowed as values for the
   <xenc:EncryptionMethod> element.  Further, 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,
   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 key.  The type



Nystroem & Machani      Expires November 20, 2006              [Page 21]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   shall be one of the types supported by the CT-KIP client (as reported
   in the <SupportedKeyTypes> of the preceding <ClientHello> message).
   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).  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

B.3.3.  Payloads

   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.




Nystroem & Machani      Expires November 20, 2006              [Page 22]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   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)
   are allowed as values for the <xenc:EncryptionMethod> element.
   Further, 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 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).
   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).  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.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



Nystroem & Machani      Expires November 20, 2006              [Page 23]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   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

   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)
   are allowed as values for the <xenc:EncryptionMethod> element.
   Further, 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 <ServerFinished> message.  The Type attribute of the
   xenc:EncryptedKeyType shall be present and shall identify the type of
   the wrapped 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).  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 password-based key derivation function also defined
   in [3] (and identified as
   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 in



Nystroem & Machani      Expires November 20, 2006              [Page 24]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   [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).  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 November 20, 2006              [Page 25]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 November 20, 2006              [Page 26]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   <?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 November 20, 2006              [Page 27]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 November 20, 2006              [Page 28]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


   <?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 November 20, 2006              [Page 29]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 November 20, 2006              [Page 30]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 November 20, 2006              [Page 31]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


           </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 November 20, 2006              [Page 32]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


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 key K = K_TOKEN | K _MAC (where '|' denotes concatenation) is
         generated, e.g. by calling C_GenerateKey.  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.  Likewise, a MAC key K_MAC is
         derived from K by calling C_DeriveKey.  The mechanism to use
         shall be [TBD - probably can't use CKM_KIP_DERIVE].

      2. The server wraps K with either the client's public key or the
         shared secret key by calling 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.

      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



Nystroem & Machani      Expires November 20, 2006              [Page 33]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


         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.  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



Nystroem & Machani      Expires November 20, 2006              [Page 34]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


         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 key K = K_TOKEN | K _MAC (where '|' denotes concatenation) is
         generated, e.g. by calling C_GenerateKey.  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.  Likewise, a MAC key K_MAC is
         derived from K by calling C_DeriveKey.  The mechanism to use
         shall be [TBD - probably can't use CKM_KIP_DERIVE].

      2. The server wraps K with either the client's public key or the
         shared secret key by calling 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.




Nystroem & Machani      Expires November 20, 2006              [Page 35]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


         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 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.  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,



Nystroem & Machani      Expires November 20, 2006              [Page 36]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


         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.

      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 November 20, 2006              [Page 37]

Internet-Draft            1- and 2-pass CT-KIP                  May 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 four 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/































Nystroem & Machani      Expires November 20, 2006              [Page 38]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


Authors' Addresses

   Magnus Nystroem
   RSA Security

   Email: magnus@rsasecurity.com


   Salah Machani
   Diversinet

   Email: smachani@diversinet.com







































Nystroem & Machani      Expires November 20, 2006              [Page 39]

Internet-Draft            1- and 2-pass CT-KIP                  May 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Nystroem & Machani      Expires November 20, 2006              [Page 40]