home *** CD-ROM | disk | FTP | other *** search
/ ftp.rsa.com / 2014.05.ftp.rsa.com.tar / ftp.rsa.com / pub / otps / ct-kip / ct-kip-v1-0a1d4.txt < prev    next >
Text File  |  2014-05-02  |  76KB  |  2,297 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                        M. Nystroem
  5. Internet-Draft                         RSA, The Security Division of EMC
  6. Expires: April 17, 2007                                       S. Machani
  7.                                                         Diversinet Corp.
  8.                                                         October 14, 2006
  9.  
  10.  
  11.   Extensions to CT-KIP to support one- and two-pass key initialization
  12.                     draft-nystrom-ct-kip-two-pass-01
  13.  
  14. Status of this Memo
  15.  
  16.    By submitting this Internet-Draft, each author represents that any
  17.    applicable patent or other IPR claims of which he or she is aware
  18.    have been or will be disclosed, and any of which he or she becomes
  19.    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20.  
  21.    Internet-Drafts are working documents of the Internet Engineering
  22.    Task Force (IETF), its areas, and its working groups.  Note that
  23.    other groups may also distribute working documents as Internet-
  24.    Drafts.
  25.  
  26.    Internet-Drafts are draft documents valid for a maximum of six months
  27.    and may be updated, replaced, or obsoleted by other documents at any
  28.    time.  It is inappropriate to use Internet-Drafts as reference
  29.    material or to cite them other than as "work in progress."
  30.  
  31.    The list of current Internet-Drafts can be accessed at
  32.    http://www.ietf.org/ietf/1id-abstracts.txt.
  33.  
  34.    The list of Internet-Draft Shadow Directories can be accessed at
  35.    http://www.ietf.org/shadow.html.
  36.  
  37.    This Internet-Draft will expire on April 17, 2007.
  38.  
  39. Copyright Notice
  40.  
  41.    Copyright (C) The Internet Society (2006).
  42.  
  43. Abstract
  44.  
  45.    This document describes extensions to the Cryptographic Token Key
  46.    Initialization Protocol (CT-KIP) to support one-pass (i.e. one
  47.    message) and two-pass (i.e. one round-trip) cryptographic token key
  48.    initialization.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Nystroem & Machani       Expires April 17, 2007                 [Page 1]
  56.  
  57. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  58.  
  59.  
  60. Table of Contents
  61.  
  62.    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  63.      1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  64.      1.2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
  65.      1.3.  Document organization  . . . . . . . . . . . . . . . . . .  4
  66.    2.  Acronyms and notation  . . . . . . . . . . . . . . . . . . . .  5
  67.      2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  5
  68.      2.2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  5
  69.    3.  One- and two-pass CT-KIP . . . . . . . . . . . . . . . . . . .  6
  70.      3.1.  Protocol flow  . . . . . . . . . . . . . . . . . . . . . .  6
  71.        3.1.1.  One-pass CT-KIP  . . . . . . . . . . . . . . . . . . .  6
  72.        3.1.2.  Two-pass CT-KIP  . . . . . . . . . . . . . . . . . . .  6
  73.      3.2.  Extensions to the <ClientHello> message  . . . . . . . . .  6
  74.      3.3.  Extensions to the <ServerFinished> message . . . . . . . .  7
  75.        3.3.1.  The KeyInitializationDataType extension  . . . . . . .  7
  76.        3.3.2.  The AuthenticationDataType extension . . . . . . . . .  8
  77.      3.4.  MAC calculations . . . . . . . . . . . . . . . . . . . . .  9
  78.        3.4.1.  One-pass CT-KIP  . . . . . . . . . . . . . . . . . . .  9
  79.        3.4.2.  Two-pass CT-KIP  . . . . . . . . . . . . . . . . . . . 11
  80.    4.  Security considerations  . . . . . . . . . . . . . . . . . . . 12
  81.      4.1.  Applicability of 4-pass CT-KIP security considerations . . 12
  82.      4.2.  Security considerations specific to 1- and 2-pass
  83.            CT-KIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  84.        4.2.1.  Client contributions to K_TOKEN entropy  . . . . . . . 12
  85.        4.2.2.  Replay protection  . . . . . . . . . . . . . . . . . . 12
  86.        4.2.3.  Key confirmation . . . . . . . . . . . . . . . . . . . 13
  87.        4.2.4.  Server authentication  . . . . . . . . . . . . . . . . 13
  88.        4.2.5.  Key protection in the passphrase profile . . . . . . . 13
  89.    5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 15
  90.    6.  Intellectual property considerations . . . . . . . . . . . . . 16
  91.    7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
  92.    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
  93.      8.1.  Normative references . . . . . . . . . . . . . . . . . . . 18
  94.      8.2.  Informative references . . . . . . . . . . . . . . . . . . 18
  95.    Appendix A.  XML Schema  . . . . . . . . . . . . . . . . . . . . . 19
  96.    Appendix B.  Key initialization profiles of CT-KIP . . . . . . . . 22
  97.      B.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 22
  98.      B.2.  Key transport profile  . . . . . . . . . . . . . . . . . . 22
  99.        B.2.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 22
  100.        B.2.2.  Identification . . . . . . . . . . . . . . . . . . . . 22
  101.        B.2.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 22
  102.      B.3.  Key wrap profile . . . . . . . . . . . . . . . . . . . . . 23
  103.        B.3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 23
  104.        B.3.2.  Identification . . . . . . . . . . . . . . . . . . . . 23
  105.        B.3.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 23
  106.      B.4.  Passphrase-based key wrap profile  . . . . . . . . . . . . 25
  107.        B.4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . 25
  108.  
  109.  
  110.  
  111. Nystroem & Machani       Expires April 17, 2007                 [Page 2]
  112.  
  113. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  114.  
  115.  
  116.        B.4.2.  Identification . . . . . . . . . . . . . . . . . . . . 25
  117.        B.4.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . 25
  118.    Appendix C.  Example messages  . . . . . . . . . . . . . . . . . . 27
  119.      C.1.  Note regarding the examples  . . . . . . . . . . . . . . . 27
  120.      C.2.  Example of a <ClientHello> message indicating support
  121.            for two-pass CT-KIP  . . . . . . . . . . . . . . . . . . . 27
  122.      C.3.  Example of a <ServerFinished> message using the key
  123.            transport profile  . . . . . . . . . . . . . . . . . . . . 29
  124.      C.4.  Example of a <ServerFinished> message using the key
  125.            wrap profile . . . . . . . . . . . . . . . . . . . . . . . 31
  126.      C.5.  Example of a <ServerFinished> message using the
  127.            passphrase-based key wrap profile  . . . . . . . . . . . . 32
  128.    Appendix D.  Integration with PKCS #11 . . . . . . . . . . . . . . 34
  129.      D.1.  The 2-pass variant . . . . . . . . . . . . . . . . . . . . 34
  130.      D.2.  The 1-pass variant . . . . . . . . . . . . . . . . . . . . 36
  131.    Appendix E.  About OTPS  . . . . . . . . . . . . . . . . . . . . . 39
  132.    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
  133.    Intellectual Property and Copyright Statements . . . . . . . . . . 41
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167. Nystroem & Machani       Expires April 17, 2007                 [Page 3]
  168.  
  169. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  170.  
  171.  
  172. 1.  Introduction
  173.  
  174. 1.1.  Scope
  175.  
  176.    This document describes extensions to the Cryptographic Token Key
  177.    Initialization Protocol (CT-KIP) [1] to support one-pass (i.e. one
  178.    message) and two-pass (i.e. one round-trip) cryptographic token key
  179.    initialization.
  180.  
  181. 1.2.  Background
  182.  
  183.    There are several deployment scenarios where it would be beneficial
  184.    to have one- or two-pass versions of CT-KIP.  These include
  185.    situations where a direct communication between the OTP token and the
  186.    CT-KIP server is not possible, where work-flow constraints otherwise
  187.    would limit real-time communications (e.g. needs for administrators
  188.    to authorize processes), or where network latency or other design
  189.    constraints (such as when initialization of tokens using existing
  190.    seeds from legacy systems is required) makes a four-pass version less
  191.    suitable.
  192.  
  193.    This document tries to meet the needs of these scenarios by
  194.    describing extensions to CT-KIP for the initialization of
  195.    cryptographic tokens in one round-trip or less.
  196.  
  197. 1.3.  Document organization
  198.  
  199.    The organization of this document is as follows:
  200.  
  201.    o  Section 1 is an introduction.
  202.  
  203.    o  Section 2 defines acronyms and notation used in this document.
  204.  
  205.    o  Section 3 defines extensions to CT-KIP.
  206.  
  207.    o  Section 4 discusses security considerations.
  208.  
  209.    o  Appendix A presents the XML schema. considerations.
  210.  
  211.    o  Appendix B contains key initialization profiles for the 1- and
  212.       2-pass versions of CT-KIP defined herein.
  213.  
  214.    o  Appendix C provides example messages.
  215.  
  216.    o  Appendix D discusses integration with PKCS #11 [2].
  217.  
  218.    o  Appendix E provides general information about the One-Time
  219.       Password Specifications.
  220.  
  221.  
  222.  
  223. Nystroem & Machani       Expires April 17, 2007                 [Page 4]
  224.  
  225. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  226.  
  227.  
  228. 2.  Acronyms and notation
  229.  
  230. 2.1.  Acronyms
  231.  
  232.    MAC       Cryptographic Token Key Initialization Protocol
  233.  
  234. 2.2.  Notation
  235.  
  236.    ||        String concatenation
  237.  
  238.    ID_C      Identifier for CT-KIP client
  239.  
  240.    ID_S      Identifier for CT-KIP server
  241.  
  242.    K_AUTH    Secret key used for authentication purposes in 4-pass CT-
  243.              KIP
  244.  
  245.    K_MAC     Secret key used for key confirmation and authentication
  246.              purposes, generated in CT-KIP
  247.  
  248.    K_TOKEN   Secret key used for token computations, generated in CT-KIP
  249.  
  250.    K_CLIENT  Public key of the cryptographic token
  251.  
  252.    K_SHARED  Secret key shared between the cryptographic token and the
  253.              CT-KIP server
  254.  
  255.    K_DERIVED Secret key derived from a passphrase that is known to both
  256.              the cryptographic token or user and the CT-KIP server
  257.  
  258.    R         Pseudorandom value chosen by the cryptographic token and
  259.              used for MAC computations
  260.  
  261.    The following typographical convention is used in the body of the
  262.    text: <XML Element>.
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279. Nystroem & Machani       Expires April 17, 2007                 [Page 5]
  280.  
  281. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  282.  
  283.  
  284. 3.  One- and two-pass CT-KIP
  285.  
  286. 3.1.  Protocol flow
  287.  
  288. 3.1.1.  One-pass CT-KIP
  289.  
  290.    In one-pass CT-KIP, the server simply sends a <ServerFinished>
  291.    message to the CT-KIP client.  In this case, there is no exchange of
  292.    the <ClientHello>, <ServerHello>, and <ClientNonce> CT-KIP messages,
  293.    and hence there is no way for the client to express supported
  294.    algorithms or key types.  Before attempting one-pass CT-KIP, the
  295.    server must therefore have prior knowledge not only that the client
  296.    is able and willing to accept this variant of CT-KIP, but also of
  297.    algorithms and key types supported by the client.
  298.  
  299.    Outside the specific cases where one-pass CT-KIP is desired, clients
  300.    should be constructed and configured to only accept CT-KIP server
  301.    messages in response to client-initiated transactions.
  302.  
  303. 3.1.2.  Two-pass CT-KIP
  304.  
  305.    In two-pass CT-KIP, the client's initial <ClientHello> message is
  306.    directly followed by a <ServerFinished> message.  There is no
  307.    exchange of the <ServerHello> message or the <ClientNonce> message.
  308.    Essentially, two-pass CT-KIP is a transport of key material from the
  309.    CT-KIP server to the CT-KIP client.  However, as the two-pass variant
  310.    of CT-KIP consists of one round trip to the server, the client is
  311.    still able to specify algorithm preferences and supported key types
  312.    in the <ClientHello> message.  Note that the CT-KIP "trigger" message
  313.    defined in [1] may be used to trigger the client's sending of the
  314.    <ClientHello> message.
  315.  
  316. 3.2.  Extensions to the <ClientHello> message
  317.  
  318.    A new extension is defined for this message.  The extension signals
  319.    client support for the two-pass version of CT-KIP, informs the server
  320.    of supported two-pass variants, and provides optional payload data to
  321.    the CT-KIP server.  The payload is sent in an opportunistic fashion,
  322.    and may be discarded by the CT-KIP server if the server does not
  323.    support the two-pass variant the payload is associated with.
  324.    Depending on the client's policy, this extension may or may not have
  325.    the Critical attribute set to true.  If Critical is not set to "true"
  326.    then a CT-KIP server may ignore the extension and proceed with
  327.    ordinary 4-pass CT-KIP.  Otherwise, the server must find a suitable
  328.    two-pass variant or else the protocol run will fail.
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335. Nystroem & Machani       Expires April 17, 2007                 [Page 6]
  336.  
  337. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  338.  
  339.  
  340.    <xs:complexType name="TwoPassSupportType">
  341.      <xs:annotation>
  342.        <xs:documentation xml:lang="en">
  343.          This extension is only valid in ClientHello PDUs. It informs
  344.          the server of the client's support for the two-pass version of
  345.          CT-KIP, and carries optional payload data associated with each
  346.          supported two-pass key initialization method
  347.        </xs:documentation>
  348.      </xs:annotation>
  349.      <xs:complexContent>
  350.        <xs:extension base="ct-kip:AbstractExtensionType">
  351.          <xs:sequence maxOccurs="unbounded">
  352.            <xs:element name="SupportedKeyInitializationMethod"
  353.            type="xs:anyURI"/>
  354.            <xs:element name="Payload" minOccurs="0"/>
  355.          </xs:sequence>
  356.        </xs:extension>
  357.      </xs:complexContent>
  358.    </xs:complexType>
  359.  
  360.    The elements of this type have the following meaning:
  361.  
  362.    o  <SupportedKeyInitializationMethod>: A two-pass key initialization
  363.       method supported by the CT-KIP client.  Multiple supported methods
  364.       may be present, in which case they shall be listed in order of
  365.       precedence.
  366.  
  367.    o  <Payload>: An optional payload associated with each supported key
  368.       initialization method.  Since the syntax is a shorthand for <xs:
  369.       element name="Payload" type="xs:anyType" minOccurs="0"/>, any
  370.       well-formed payloads can be carried in this element.
  371.  
  372.    A CT-KIP client that indicates support for two-pass CT-KIP must also
  373.    include the nonce R in its <ClientHello> message (this will enable
  374.    the client to verify that the CT-KIP server it is communicating with
  375.    is alive).
  376.  
  377. 3.3.  Extensions to the <ServerFinished> message
  378.  
  379. 3.3.1.  The KeyInitializationDataType extension
  380.  
  381.    This extension carries an identifier for the selected key
  382.    initialization method as well as key initialization method-dependent
  383.    payload data.
  384.  
  385.    Servers may include this extension in a <ServerFinished> message that
  386.    is being sent in response to a received <ClientHello> message if and
  387.    only if that <ClientHello> message contained a TwoPassSupportType
  388.  
  389.  
  390.  
  391. Nystroem & Machani       Expires April 17, 2007                 [Page 7]
  392.  
  393. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  394.  
  395.  
  396.    extension and the client indicated support for the selected key
  397.    initialization method.  Servers must include this extension in a
  398.    <ServerFinished> message that is sent as a 1-pass CT-KIP.
  399.  
  400.    <xs:complexType name="KeyInitializationDataType">
  401.      <xs:annotation>
  402.        <xs:documentation xml:lang="en">
  403.          This extension is only valid in ServerFinished PDUs. It
  404.          contains key initialization data and its presence results in a
  405.          two-pass (or one-pass, if no ClientHello was sent) CT-KIP
  406.          exchange.
  407.        </xs:documentation>
  408.      </xs:annotation>
  409.      <xs:complexContent>
  410.        <xs:extension base="ct-kip:AbstractExtensionType">
  411.          <xs:sequence>
  412.            <xs:element name="KeyInitializationMethod" type="xs:anyURI"/>
  413.            <xs:element name="Payload"/>
  414.          </xs:sequence>
  415.        </xs:extension>
  416.      </xs:complexContent>
  417.    </xs:complexType>
  418.  
  419.    The elements of this type have the following meaning:
  420.  
  421.    o  <KeyInitializationMethod>: A two-pass key initialization method
  422.       supported by the CT-KIP client.
  423.  
  424.    o  <Payload>: An payload associated with the key initialization
  425.       method.  Since the syntax is a shorthand for <xs:element
  426.       name="Payload" type="xs:anyType"/>, any well-formed payloads can
  427.       be carried in this element.
  428.  
  429. 3.3.2.  The AuthenticationDataType extension
  430.  
  431.    This extension must be included by the CT-KIP server when a
  432.    successful 1- or 2-pass protocol run will result in an existing key
  433.    being replaced.  The extension contains a MAC proving to the token
  434.    that the server knows the value of the key it is about to replace.
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447. Nystroem & Machani       Expires April 17, 2007                 [Page 8]
  448.  
  449. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  450.  
  451.  
  452.    <xs:complexType name="AuthenticationDataType">
  453.      <xs:annotation>
  454.        <xs:documentation xml:lang="en">
  455.          This extension is only valid in ServerFinished PDUs. It
  456.          contains a MAC authenticating the CT-KIP server to the token.
  457.        </xs:documentation>
  458.      </xs:annotation>
  459.      <xs:complexContent>
  460.        <xs:extension base="ct-kip:AbstractExtensionType">
  461.          <xs:sequence>
  462.            <xs:element name="Mac" type="ExtendedMacType"/>
  463.          </xs:sequence>
  464.        </xs:extension>
  465.      </xs:complexContent>
  466.    </xs:complexType>
  467.  
  468.    The element of this type has the following meaning:
  469.  
  470.    o  <Mac>: The authenticating MAC and optional additional information
  471.       (e.g.  MAC algorithm).  See further Section 3.4.
  472.  
  473. 3.4.  MAC calculations
  474.  
  475. 3.4.1.  One-pass CT-KIP
  476.  
  477. 3.4.1.1.  Key confirmation
  478.  
  479.    In one-pass CT-KIP, the server is required to include an identifier,
  480.    ID_S, for itself (in the <ServerID> element) in the <ServerFinished>
  481.    message.  The MAC value in the <ServerFinished> message shall be
  482.    computed on the (ASCII) string "MAC 1 computation", the server
  483.    identifier ID_S, and an usigned integer value I, using a MAC key
  484.    K_MAC.  The value I must be monotonically increasing and guaranteed
  485.    not to be used again by this server towards this token.  It could for
  486.    example be the number of seconds since some point in time with
  487.    sufficient granularity, a counter value, or a combination of the two
  488.    where the counter value is reset for each new time value.  In
  489.    contrast to [1], the MAC key K_MAC shall be provided together with
  490.    K_TOKEN to the token, and hence there is no need for a K_AUTH for key
  491.    confirmation purposes.
  492.  
  493.    Note 1: The integer I does not necessarily need to be maintained per
  494.    token by the CT-KIP server (it is enough if the server can guarantee
  495.    that the same value is never being sent twice to the same token).
  496.  
  497.    Note 2: An extension is planned to [1] to allow for generation of a
  498.    K_MAC in addition to K_TOKEN in 4-pass CT-KIP.
  499.  
  500.  
  501.  
  502.  
  503. Nystroem & Machani       Expires April 17, 2007                 [Page 9]
  504.  
  505. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  506.  
  507.  
  508.    If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
  509.    s shall consist of the concatenation of the (ASCII) string "MAC 1
  510.    computation", ID_S, and I. The parameter dsLen shall be set to at
  511.    least 16 (i.e. the length of the MAC shall be at least 16 octets):
  512.  
  513.    dsLen >= 16
  514.  
  515.    MAC = CT-KIP-PRF (K_MAC, "MAC 1 computation" || ID_S || I, dsLen)
  516.  
  517.    The server shall provide I to the client in the Nonce attribute of
  518.    the <Mac> element of the <ServerFinished> message using the following
  519.    extension of the CT-KIP MacType:
  520.  
  521.    <xs:complexType name="ExtendedMacType">
  522.      <xs:simpleContent>
  523.        <xs:extension base="ct-kip:MacType">
  524.          <xs:attribute name="Nonce" type="xs:nonNegativeInteger"
  525.          use="required"/>
  526.        </xs:extension>
  527.      </xs:simpleContent>
  528.    </xs:complexType>
  529.  
  530. 3.4.1.2.  Server authentication
  531.  
  532.    As discussed in Section 3.3.2, servers need to authenticate
  533.    themselves when attempting to replace an existing K_TOKEN.  In 1-pass
  534.    CT-KIP, servers authenticate themselves by including a second MAC
  535.    value in the AuthenticationDataType extension.  The MAC value in the
  536.    AuthenticationDataType extension shall be computed on the (ASCII)
  537.    string "MAC 1 computation", the server identifier ID_S, and a new
  538.    value I', I' > I, using the existing MAC key K_MAC' (the MAC key that
  539.    existed before this protocol run).  The MAC algorithm shall be the
  540.    same as the algorithm used for key confirmation purposes.
  541.  
  542.    If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
  543.    s shall consist of the concatenation of the (ASCII) string "MAC 1
  544.    computation" ID_S, and I'.  The parameter dsLen shall be set to at
  545.    least 16 (i.e. the length of the MAC shall be at least 16 octets):
  546.  
  547.    dsLen >= 16
  548.  
  549.    MAC = CT-KIP-PRF (K_MAC', "MAC 1 computation" || ID_S || I', dsLen)
  550.  
  551.    The server shall provide I' to the client in the Nonce attribute of
  552.    the <Mac> element of the AuthenticationDataType extension.  If the
  553.    protocol run is successful, the client stores I' as the new value of
  554.    I for this server.
  555.  
  556.  
  557.  
  558.  
  559. Nystroem & Machani       Expires April 17, 2007                [Page 10]
  560.  
  561. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  562.  
  563.  
  564. 3.4.2.  Two-pass CT-KIP
  565.  
  566. 3.4.2.1.  Key confirmation
  567.  
  568.    In two-pass CT-KIP, the client is required to include a nonce R in
  569.    the <ClientHello> message.  Further, the server is required to
  570.    include an identifier, ID_S, for itself (in the <ServerID> element)
  571.    in the <ServerFinished> message.  The MAC value in the
  572.    <ServerFinished> message shall be computed on the (ASCII) string "MAC
  573.    1 computation", the server identifier ID_S, and R using a MAC key
  574.    K_MAC.  Again, in contrast with [1], this key shall be provided
  575.    together with K_TOKEN to the token, and hence there is no need for a
  576.    K_AUTH for key confirmation purposes.
  577.  
  578.    If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
  579.    s shall consist of the concatenation of the (ASCII) string "MAC 1
  580.    computation" and R, and the parameter dsLen shall be set to the
  581.    length of R:
  582.  
  583.    dsLen = len(R)
  584.  
  585.    MAC = CT-KIP-PRF (K_MAC, "MAC 1 computation" || ID_S || R, dsLen)
  586.  
  587. 3.4.2.2.  Server authentication
  588.  
  589.    As discussed in Section 3.3.2, servers need to authenticate
  590.    themselves when attempting to replace an existing K_TOKEN.  In 2-pass
  591.    CT-KIP, servers authenticate themselves by including a second MAC
  592.    value in the AuthenticationDataType extension.  The MAC value in the
  593.    AuthenticationDataType extension shall be computed on the (ASCII)
  594.    string "MAC 1 computation", the server identifier ID_S, and R, using
  595.    the existing MAC key K_MAC' (the MAC key that existed before this
  596.    protocol run).  The MAC algorithm shall be the same as the algorithm
  597.    used for key confirmation purposes.
  598.  
  599.    If CT-KIP-PRF is used as the MAC algorithm, then the input parameter
  600.    s shall consist of the concatenation of the (ASCII) string "MAC 1
  601.    computation" ID_S, and R. The parameter dsLen shall be set to at
  602.    least 16 (i.e. the length of the MAC shall be at least 16 octets):
  603.  
  604.    dsLen >= 16
  605.  
  606.    MAC = CT-KIP-PRF (K_MAC', "MAC 1 computation" || ID_S || R, dsLen)
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615. Nystroem & Machani       Expires April 17, 2007                [Page 11]
  616.  
  617. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  618.  
  619.  
  620. 4.  Security considerations
  621.  
  622. 4.1.  Applicability of 4-pass CT-KIP security considerations
  623.  
  624.    This document extends [1], and therefore, the security considerations
  625.    discussed in [1] apply here as well, with the following exceptions:
  626.  
  627.    o  Message re-ordering attacks cannot occur since in the CT-KIP
  628.       variants described in this document each party sends at most one
  629.       message each.
  630.  
  631.    o  The attack described in Section 5.5 of [1] where the attacker
  632.       replaces a client-provided R_C with his own R'C does not apply as
  633.       the client does not provide any entropy to K_TOKEN in the 1- and
  634.       2-pass variants discussed here.  The attack as such (and its
  635.       countermeasures) still applies, however, as it essentially is a
  636.       man-in-the-middle attack.
  637.  
  638.    In addition, the 1- and 2-pass CT-KIP variants described in this
  639.    document warrant some further security considerations that are
  640.    discussed in the following.
  641.  
  642. 4.2.  Security considerations specific to 1- and 2-pass CT-KIP
  643.  
  644. 4.2.1.  Client contributions to K_TOKEN entropy
  645.  
  646.    In 4-pass CT-KIP, both the client and the server provide randomizing
  647.    material to K_TOKEN , in a manner that allows both parties to verify
  648.    that they did contribute to the resulting key.  In the 1- and 2-pass
  649.    CT-KIP versions defined herein, only the server contributes to the
  650.    entropy of K_TOKEN.  This means that a broken or compromised
  651.    (pseudo-)random number generator in the server may cause more damage
  652.    than it would in the 4-pass variant.  Server implementations should
  653.    therefore take extreme care to ensure that this situation does not
  654.    occur.
  655.  
  656. 4.2.2.  Replay protection
  657.  
  658.    A 4-pass CT-KIP client knows that a server it is communicating with
  659.    is "live" since the server must create a MAC on information sent by
  660.    the client.  The same is true for 2-pass CT-KIP thanks to the
  661.    requirement that the client sends R in the <ClientHello> message and
  662.    that the server includes R in the MAC computation.  In 1-pass CT-KIP
  663.    clients (tokens) that record the latest I used by a particular server
  664.    (as identified by ID_S) will be able to detect replays.
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671. Nystroem & Machani       Expires April 17, 2007                [Page 12]
  672.  
  673. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  674.  
  675.  
  676. 4.2.3.  Key confirmation
  677.  
  678.    4-pass CT-KIP servers provide key confirmation through the MAC on R_C
  679.    in the <ServerFinished> message.  In the 1- and 2-pass CT-KIP
  680.    variants described herein, key confirmation is provided by the MAC
  681.    including I (in the 1-pass case) or R (2-pass case), using K_MAC.
  682.  
  683. 4.2.4.  Server authentication
  684.  
  685.    CT-KIP servers must authenticate themselves whenever a successful CT-
  686.    KIP 1- or 2-pass protocol run would result in an existing K_TOKEN
  687.    being replaced by a K_TOKEN', or else a denial-of-service attack
  688.    where an unauthorized CT-KIP server replaces a K_TOKEN with another
  689.    key would be possible.  In 1- and 2-pass CT-KIP servers authenticate
  690.    by including the AuthenticationDataType extension containing a MAC as
  691.    described in Section 3.4 above.
  692.  
  693. 4.2.5.  Key protection in the passphrase profile
  694.  
  695.    The passphrase-based key wrap profile uses the PBKDF2 function from
  696.    [3] to generate an encryption key from a passphrase and salt string.
  697.    The derived key, K_DERIVED is used by the server to encrypt K_TOKEN
  698.    and by the token to decrypt the newly delivered K_TOKEN.  It is
  699.    important to note that passphrase-based encryption is generally
  700.    limited in the security that it provides despite the use of salt and
  701.    iteration count in PBKDF2 to increase the complexity of attack.
  702.    Implementations should therefore take additional measures to
  703.    strengthen the security of the passphrase-based key wrap profile.
  704.    The following measures should be considered where applicable:
  705.  
  706.    o  The passphrase should be selected well, and usage guidelines such
  707.       as the ones in [9] should be taken into account.
  708.  
  709.    o  A different passphrase should be used for every key initialization
  710.       wherever possible (the use of a global passphrase for a batch of
  711.       tokens should be avoided, for example).  One way to achieve this
  712.       is to use randomly-generated passphrases.
  713.  
  714.    o  The passphrase should be protected well if stored on the server
  715.       and/or on the token and should be delivered to the token's user
  716.       using secure methods.
  717.  
  718.    o  User pre-authentication should be implemented to ensure that
  719.       K_TOKEN is not delivered to a rogue recipient.
  720.  
  721.    o  The iteration count in PBKDF2 should be high to impose more work
  722.       for an attacker using brute-force methods (see [3] for
  723.       recommendations).  However, it must be noted that the higher the
  724.  
  725.  
  726.  
  727. Nystroem & Machani       Expires April 17, 2007                [Page 13]
  728.  
  729. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  730.  
  731.  
  732.       count, the more work is required on the legitimate token to
  733.       decrypt the newly delivered K_TOKEN.  Servers may use relatively
  734.       low iteration counts to accommodate tokens with limited processing
  735.       power such as some PDA and cell phones when other security
  736.       measures are implemented and the security of the passphrase-based
  737.       key wrap method is not weakened.
  738.  
  739.    o  Transport level security (e.g.  TLS) should be used where possible
  740.       to protect a 2-pass or 1-pass protocol run.  Transport level
  741.       security provides a second layer of protection for the newly
  742.       generated K_TOKEN.
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783. Nystroem & Machani       Expires April 17, 2007                [Page 14]
  784.  
  785. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  786.  
  787.  
  788. 5.  IANA considerations
  789.  
  790.    This document does not contain any considerations for IANA.
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839. Nystroem & Machani       Expires April 17, 2007                [Page 15]
  840.  
  841. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  842.  
  843.  
  844. 6.  Intellectual property considerations
  845.  
  846.    RSA SecurID is a registered trademark of RSA, The Security Division
  847.    of EMC, in the United States and/or other countries.  The names of
  848.    other products and services mentioned may be the trademarks of their
  849.    respective owners.
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895. Nystroem & Machani       Expires April 17, 2007                [Page 16]
  896.  
  897. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  898.  
  899.  
  900. 7.  Acknowledgements
  901.  
  902.    Thanks to all the participants at the OTPS workshops where this
  903.    document has been discussed and on the OTPS mailing list for their
  904.    review and comments related to this document.
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951. Nystroem & Machani       Expires April 17, 2007                [Page 17]
  952.  
  953. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  954.  
  955.  
  956. 8.  References
  957.  
  958. 8.1.  Normative references
  959.  
  960.    [1]  RSA Laboratories, "Cryptographic Token Key Initialization
  961.         Protocol", CT-KIP Version 1.0 Revision 1, September 2006,
  962.         <http://www.rsasecurity.com/rsalabs/otps/>.
  963.  
  964.    [2]  RSA Laboratories, "Cryptographic Token Interface Standard",
  965.         PKCS #11 Version 2.20, June 2004,
  966.         <http://www.rsasecurity.com/rsalabs/pkcs/>.
  967.  
  968.    [3]  RSA Laboratories, "Password-Based Cryptography Standard",
  969.         PKCS #5 Version 2.0, March 1999,
  970.         <http://www.rsasecurity.com/rsalabs/pkcs/>.
  971.  
  972.    [4]  W3C, "XML Signature Syntax and Processing", W3C Recommendation,
  973.         February 2002,
  974.         <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
  975.  
  976.    [5]  W3C, "XML Encryption Syntax and Processing", W3C Recommendation,
  977.         December 2002,
  978.         <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
  979.  
  980.    [6]  RSA Laboratories, "XML Schema for PKCS #5 Version 2.0", PKCS #5
  981.         Version 2.0 Amd.1 (FINAL DRAFT), October 2006,
  982.         <http://www.rsasecurity.com/rsalabs/pkcs/>.
  983.  
  984.    [7]  RSA Laboratories, "PKCS #11 Mechanisms for the Cryptographic
  985.         Token Key Initialization Protocol", PKCS #11 Version 2.20 Amd.2,
  986.         December 2005, <http://www.rsasecurity.com/rsalabs/pkcs/>.
  987.  
  988.    [8]  RSA Laboratories, "RSA Cryptography Standard", PKCS #1 Version
  989.         2.1, June 2002, <http://www.rsasecurity.com/rsalabs/pkcs/>.
  990.  
  991. 8.2.  Informative references
  992.  
  993.    [9]  National Institute of Standards and Technology, "Password
  994.         Usage", FIPS 112, May 1985,
  995.         <http://www.itl.nist.gov/fipspubs/fip112.htm>.
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007. Nystroem & Machani       Expires April 17, 2007                [Page 18]
  1008.  
  1009. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1010.  
  1011.  
  1012. Appendix A.  XML Schema
  1013.  
  1014.    <?xml version="1.0" encoding="UTF-8"?>
  1015.    !-- $Revision: 1.6 $ $Date: 2006/10/13 09:28:54 $ -->
  1016.  
  1017.    <!-- Copyright (c) RSA, The Security Division of EMC, 2006. -->
  1018.    <!-- All rights reserved. -->
  1019.    <!-- License to copy and use this schema file is granted provided
  1020.         that it is identified as "RSA One-Time Password
  1021.         Specifications (OTPS) Cryptographic Token Key Initialization
  1022.         Protocol Version 1.0 Amd.1" in all material mentioning or
  1023.         referencing it.
  1024.  
  1025.         RSA makes no representations concerning either the
  1026.         merchantability of this schema or the suitability of this schema
  1027.         for any particular purpose. It is provided "as is" without
  1028.         express or implied warranty of any kind.
  1029.    -->
  1030.    <xs:schema
  1031.      targetNamespace="http://www.rsasecurity.com/rsalabs/otps/schemas
  1032.        /2006/05/ct-kip-two-pass#"
  1033.      xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas
  1034.        /2006/05/ct-kip-two-pass#"
  1035.      xmlns:ct-kip="http://www.rsasecurity.com/rsalabs/otps/schemas
  1036.        /2005/12/ct-kip#"
  1037.      xmlns:xs="http://www.w3.org/2001/XMLSchema"
  1038.      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  1039.  
  1040.     <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
  1041.      schemaLocation="http://www.w3.org/TR/2002/
  1042.        REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
  1043.  
  1044.     <xs:import namespace="http://www.rsasecurity.com/rsalabs/otps/
  1045.        schemas/2005/12/ct-kip#"
  1046.      schemaLocation="ftp://ftp.rsasecurity.com/pub/otps/ct-kip/
  1047.        ct-kip-v1-0.xsd"/>
  1048.  
  1049.    <!-- Extended core types -->
  1050.    <xs:complexType name="ExtendedMacType">
  1051.      <xs:simpleContent>
  1052.        <xs:extension base="ct-kip:MacType">
  1053.          <xs:attribute name="Nonce" type="xs:nonNegativeInteger"
  1054.          use="required"/>
  1055.        </xs:extension>
  1056.      </xs:simpleContent>
  1057.    </xs:complexType>
  1058.  
  1059.    <!-- 1- and 2-pass extensions -->
  1060.  
  1061.  
  1062.  
  1063. Nystroem & Machani       Expires April 17, 2007                [Page 19]
  1064.  
  1065. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1066.  
  1067.  
  1068.    <xs:complexType name="TwoPassSupportType">
  1069.      <xs:annotation>
  1070.        <xs:documentation xml:lang="en">
  1071.          This extension is only valid in ClientHello PDUs. It informs
  1072.          the server of the client's support for the two-pass version of
  1073.          CT-KIP, and carries optional payload data associated with each
  1074.          supported two-pass key initialization method.
  1075.        </xs:documentation>
  1076.      </xs:annotation>
  1077.      <xs:complexContent>
  1078.        <xs:extension base="ct-kip:AbstractExtensionType">
  1079.          <xs:sequence maxOccurs="unbounded">
  1080.            <xs:element name="SupportedKeyInitializationMethod"
  1081.            type="xs:anyURI"/>
  1082.            <xs:element name="Payload" minOccurs="0"/>
  1083.          </xs:sequence>
  1084.        </xs:extension>
  1085.      </xs:complexContent>
  1086.    </xs:complexType>
  1087.  
  1088.    <xs:complexType name="KeyInitializationDataType">
  1089.      <xs:annotation>
  1090.        <xs:documentation xml:lang="en">
  1091.          This extension is only valid in ServerFinished PDUs. It
  1092.          contains key initialization data and its presence results in a
  1093.          two-pass (or one-pass, if no ClientHello was sent) CT-KIP
  1094.          exchange.
  1095.        </xs:documentation>
  1096.      </xs:annotation>
  1097.      <xs:complexContent>
  1098.        <xs:extension base="ct-kip:AbstractExtensionType">
  1099.          <xs:sequence>
  1100.            <xs:element name="KeyInitializationMethod" type="xs:anyURI"/>
  1101.            <xs:element name="Payload"/>
  1102.          </xs:sequence>
  1103.        </xs:extension>
  1104.      </xs:complexContent>
  1105.    </xs:complexType>
  1106.  
  1107.    <xs:complexType name="AuthenticationDataType">
  1108.      <xs:annotation>
  1109.        <xs:documentation xml:lang="en">
  1110.          This extension is only valid in ServerFinished PDUs. It
  1111.          contains a MAC authenticating the CT-KIP server to the token.
  1112.        </xs:documentation>
  1113.      </xs:annotation>
  1114.      <xs:complexContent>
  1115.        <xs:extension base="ct-kip:AbstractExtensionType">
  1116.  
  1117.  
  1118.  
  1119. Nystroem & Machani       Expires April 17, 2007                [Page 20]
  1120.  
  1121. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1122.  
  1123.  
  1124.          <xs:sequence>
  1125.            <xs:element name="Mac" type="ExtendedMacType"/>
  1126.          </xs:sequence>
  1127.        </xs:extension>
  1128.      </xs:complexContent>
  1129.    </xs:complexType>
  1130.  
  1131.    </xs:schema>
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175. Nystroem & Machani       Expires April 17, 2007                [Page 21]
  1176.  
  1177. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1178.  
  1179.  
  1180. Appendix B.  Key initialization profiles of CT-KIP
  1181.  
  1182. B.1.  Introduction
  1183.  
  1184.    This appendix introduces three profiles of CT-KIP for key
  1185.    initialization.  They may all be used for two- as well as one-pass
  1186.    initialization of cryptographic tokens.  Further profiles may be
  1187.    defined by external entities or through the OTPS process.
  1188.  
  1189. B.2.  Key transport profile
  1190.  
  1191. B.2.1.  Introduction
  1192.  
  1193.    This profile initializes the cryptographic token with a symmetric
  1194.    key, K_TOKEN, through key transport and key derivation.  The key
  1195.    transport is carried out using a public key, K_CLIENT, whose private
  1196.    key part resides in the token as the transport key.  A key K from
  1197.    which two keys, K_TOKEN and K_MAC are derived shall be transported.
  1198.  
  1199. B.2.2.  Identification
  1200.  
  1201.    This profile shall be identified with the following URI:
  1202.  
  1203.    http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
  1204.    ct-kip#transport
  1205.  
  1206. B.2.3.  Payloads
  1207.  
  1208.    In the two-pass version of CT-KIP, the client shall send a payload
  1209.    associated with this key initialization method.  The payload shall be
  1210.    of type ds:KeyInfoType ([4]), and only those choices of the ds:
  1211.    KeyInfoType that identify a public key are allowed.  The ds:
  1212.    X509Certificate option of the ds:X509Data alternative is recommended
  1213.    when the public key corresponding to the private key on the
  1214.    cryptographic token has been certified.
  1215.  
  1216.    The server payload associated with this key initialization method
  1217.    shall be of type xenc:EncryptedKeyType ([5]), and only those
  1218.    encryption methods utilizing a public key that are supported by the
  1219.    CT-KIP client (as indicated in the <SupportedEncryptionAlgorithms>
  1220.    element of the <ClientHello> message in the case of 2-pass CT-KIP, or
  1221.    as otherwise known in the case of 1-pass CT-KIP) are allowed as
  1222.    values for the <xenc:EncryptionMethod> element.  Further, in the case
  1223.    of 2-pass CT-KIP, the <ds:KeyInfo> element shall contain the same
  1224.    value (i.e. identify the same public key) as the <Payload> of the
  1225.    corresponding supported key initialization method in the
  1226.    <ClientHello> message that triggered the response.  The
  1227.    <CarriedKeyName> element may be present, but shall, when present,
  1228.  
  1229.  
  1230.  
  1231. Nystroem & Machani       Expires April 17, 2007                [Page 22]
  1232.  
  1233. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1234.  
  1235.  
  1236.    contain the same value as the <KeyID> element of the <ServerFinished>
  1237.    message.  The Type attribute of the xenc:EncryptedKeyType shall be
  1238.    present and shall identify the type of the wrapped token key.  The
  1239.    type shall be one of the types supported by the CT-KIP client (as
  1240.    reported in the <SupportedKeyTypes> of the preceding <ClientHello>
  1241.    message in the case of 2-pass CT-KIP, or as otherwise known in the
  1242.    case of 1-pass CT-KIP).  The transported key shall consist of two
  1243.    parts of equal length.  The first half constitutes K_MAC and the
  1244.    second half constitutes K_TOKEN.  The length of K_TOKEN (and hence
  1245.    also the length of K_MAC) is determined by the type of K_TOKEN.
  1246.  
  1247.    CT-KIP servers and tokens supporting this profile must support the
  1248.    http://www.w3.org/2001/04/xmlenc#rsa-1_5 key-wrapping mechanism
  1249.    defined in [5].
  1250.  
  1251.    When this profile is used, the MacAlgorithm attribute of the <Mac>
  1252.    element of the <ServerFinished> message must be present and must
  1253.    identify the selected MAC algorithm.  The selected MAC algorithm must
  1254.    be one of the MAC algorithms supported by the CT-KIP client (as
  1255.    indicated in the <SupportedMACAlgorithms> element of the
  1256.    <ClientHello> message in the case of 2-pass CT-KIP, or as otherwise
  1257.    known in the case of 1-pass CT-KIP).  The MAC shall be calculated as
  1258.    described in Section 3.4
  1259.  
  1260.    In addition, CT-KIP servers must include the AuthenticationDataType
  1261.    extension (see further Section 3.4) in their <ServerFinished>
  1262.    messages whenever a successful protocol run will result in an
  1263.    existing K_TOKEN being replaced.
  1264.  
  1265. B.3.  Key wrap profile
  1266.  
  1267. B.3.1.  Introduction
  1268.  
  1269.    This profile initializes the cryptographic token with a symmetric
  1270.    key, K_TOKEN, through key wrap and key derivation.  The key wrap
  1271.    shall be carried out using a (symmetric) key-wrapping key, K_SHARED,
  1272.    known in advance by both the token and the CT-KIP server.  A key K
  1273.    from which two keys, K_TOKEN and K_MAC are derived shall be wrapped.
  1274.  
  1275. B.3.2.  Identification
  1276.  
  1277.    This profile shall be identified with the following URI:
  1278.  
  1279.    http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/ct-kip#wrap
  1280.  
  1281. B.3.3.  Payloads
  1282.  
  1283.    In the 2-pass version of CT-KIP, the client shall send a payload
  1284.  
  1285.  
  1286.  
  1287. Nystroem & Machani       Expires April 17, 2007                [Page 23]
  1288.  
  1289. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1290.  
  1291.  
  1292.    associated with this key initialization method.  The payload shall be
  1293.    of type ds:KeyInfoType ([4]), and only those choices of the ds:
  1294.    KeyInfoType that identify a symmetric key are allowed.  The ds:
  1295.    KeyName alternative is recommended.
  1296.  
  1297.    The server payload associated with this key initialization method
  1298.    shall be of type xenc:EncryptedKeyType ([5]), and only those
  1299.    encryption methods utilizing a symmetric key that are supported by
  1300.    the CT-KIP client (as indicated in the
  1301.    <SupportedEncryptionAlgorithms> element of the <ClientHello> message
  1302.    in the case of 2-pass CT-KIP, or as otherwise known in the case of
  1303.    1-pass CT-KIP) are allowed as values for the <xenc:EncryptionMethod>
  1304.    element.  Further, in the case of 2-pass CT-KIP, the <ds:KeyInfo>
  1305.    element shall contain the same value (i.e. identify the same
  1306.    symmetric key) as the <Payload> of the corresponding supported key
  1307.    initialization method in the <ClientHello> message that triggered the
  1308.    response.  The <CarriedKeyName> element may be present, and shall,
  1309.    when present, contain the same value as the <KeyID> element of the
  1310.    <ServerFinished> message.  The Type attribute of the xenc:
  1311.    EncryptedKeyType shall be present and shall identify the type of the
  1312.    wrapped token key.  The type shall be one of the types supported by
  1313.    the CT-KIP client (as reported in the <SupportedKeyTypes> of the
  1314.    preceding <ClientHello> message in the case of 2-pass CT-KIP, or as
  1315.    otherwise known in the case of 1-pass CT-KIP).  The wrapped key shall
  1316.    consist of two parts of equal length.  The first half constitutes
  1317.    K_MAC and the second half constitutes K_TOKEN.  The length of K_TOKEN
  1318.    (and hence also the length of K_MAC) is determined by the type of
  1319.    K_TOKEN.
  1320.  
  1321.    CT-KIP servers and tokens supporting this profile must support the
  1322.    http://www.w3.org/2001/04/xmlenc#kw-aes128 key-wrapping mechanism
  1323.    defined in [5].
  1324.  
  1325.    When this profile is used, the MacAlgorithm attribute of the <Mac>
  1326.    element of the <ServerFinished> message must be present and must
  1327.    identify the selected MAC algorithm.  The selected MAC algorithm must
  1328.    be one of the MAC algorithms supported by the CT-KIP client (as
  1329.    indicated in the <SupportedMACAlgorithms> element of the
  1330.    <ClientHello> message in the case of 2-pass CT-KIP, or as otherwise
  1331.    known in the case of 1-pass CT-KIP).  The MAC shall be calculated as
  1332.    described in Section 3.4
  1333.  
  1334.    In addition, CT-KIP servers must include the AuthenticationDataType
  1335.    extension (see further Section 3.4) in their <ServerFinished>
  1336.    messages whenever a successful protocol run will result in an
  1337.    existing K_TOKEN being replaced.
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343. Nystroem & Machani       Expires April 17, 2007                [Page 24]
  1344.  
  1345. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1346.  
  1347.  
  1348. B.4.  Passphrase-based key wrap profile
  1349.  
  1350. B.4.1.  Introduction
  1351.  
  1352.    This profile is a variation of the key wrap profile.  It initializes
  1353.    the cryptographic token with a symmetric key, K_TOKEN, through key
  1354.    wrap and key derivation, using a passphrase-derived key-wrapping key,
  1355.    K_DERIVED.  The passphrase is known in advance by both the token user
  1356.    and the CT-KIP server.  To preserve the property of not exposing
  1357.    K_TOKEN to any other entity than the CT_KIP server and the token
  1358.    itself, the method should be employed only when the token contains
  1359.    facilities (e.g. a keypad) for direct entry of the passphrase.  A key
  1360.    K from which two keys, K_TOKEN and K_MAC are derived shall be
  1361.    wrapped.
  1362.  
  1363. B.4.2.  Identification
  1364.  
  1365.    This profile shall be identified with the following URI:
  1366.  
  1367.    http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
  1368.    ct-kip#passphrase-wrap
  1369.  
  1370. B.4.3.  Payloads
  1371.  
  1372.    In the 2-pass version of CT-KIP, the client shall send a payload
  1373.    associated with this key initialization method.  The payload shall be
  1374.    of type ds:KeyInfoType ([4]).  The ds:KeyName option shall be used
  1375.    and the key name shall identify the passphrase that will be used by
  1376.    the server to generate the key-wrapping key.  As an example, the
  1377.    identifier could be a user identifier or a registration identifier
  1378.    issued by the server to the user during a session preceding the CT-
  1379.    KIP protocol run.
  1380.  
  1381.    The server payload associated with this key initialization method
  1382.    shall be of type xenc:EncryptedKeyType ([5]), and only those
  1383.    encryption methods utilizing a passphrase to derive the key-wrapping
  1384.    key that are supported by the CT-KIP client (as indicated in the
  1385.    <SupportedEncryptionAlgorithms> element of the <ClientHello> message
  1386.    in the case of 2-pass CT-KIP, or as otherwise known in the case of
  1387.    1-pass CT-KIP) are allowed as values for the <xenc:EncryptionMethod>
  1388.    element.  Further, in the case of 2-pass CT-KIP, the <ds:KeyInfo>
  1389.    element shall contain the same value (i.e. identify the same
  1390.    passphrase) as the <Payload> of the corresponding supported key
  1391.    initialization method in the <ClientHello> message that triggered the
  1392.    response.  The <CarriedKeyName> element may be present, and shall,
  1393.    when present, contain the same value as the <KeyID> element of the
  1394.    <ServerFinished> message.  The Type attribute of the xenc:
  1395.    EncryptedKeyType shall be present and shall identify the type of the
  1396.  
  1397.  
  1398.  
  1399. Nystroem & Machani       Expires April 17, 2007                [Page 25]
  1400.  
  1401. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1402.  
  1403.  
  1404.    wrapped token key.  The type shall be one of the types supported by
  1405.    the CT-KIP client (as reported in the <SupportedKeyTypes> of the
  1406.    preceding <ClientHello> message in the case of 2-pass CT-KIP, or as
  1407.    otherwise known in the case of 1-pass CT-KIP).  The wrapped key shall
  1408.    consist of two parts of equal length.  The first half constitutes
  1409.    K_MAC and the second half constitutes K_TOKEN.  The length of K_TOKEN
  1410.    (and hence also the length of K_MAC) is determined by the type of
  1411.    K_TOKEN.
  1412.  
  1413.    CT-KIP servers and tokens supporting this profile must support the
  1414.    PBES2 password based encryption scheme defined in [3] (and identified
  1415.    as http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in
  1416.    [6]), the PBKDF2 passphrase-based key derivation function also
  1417.    defined in [3] (and identified as
  1418.    http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 in
  1419.    [6]), and the http://www.w3.org/2001/04/xmlenc#kw-aes128 key-wrapping
  1420.    mechanism defined in [5].
  1421.  
  1422.    When this profile is used, the MacAlgorithm attribute of the <Mac>
  1423.    element of the <ServerFinished> message must be present and must
  1424.    identify the selected MAC algorithm.  The selected MAC algorithm must
  1425.    be one of the MAC algorithms supported by the CT-KIP client (as
  1426.    indicated in the <SupportedMACAlgorithms> element of the
  1427.    <ClientHello> message in the case of 2-pass CT-KIP, or as otherwise
  1428.    known in the case of 1-pass CT-KIP).  The MAC shall be calculated as
  1429.    described in Section 3.4
  1430.  
  1431.    In addition, CT-KIP servers must include the AuthenticationDataType
  1432.    extension (see further Section 3.4) in their <ServerFinished>
  1433.    messages whenever a successful protocol run will result in an
  1434.    existing K_TOKEN being replaced.
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455. Nystroem & Machani       Expires April 17, 2007                [Page 26]
  1456.  
  1457. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1458.  
  1459.  
  1460. Appendix C.  Example messages
  1461.  
  1462. C.1.  Note regarding the examples
  1463.  
  1464.    All examples are syntactically correct.  MAC and cipher values are
  1465.    fictitious however.  The examples illustrate a complete two-pass CT-
  1466.    KIP exchange.  The server messages may also constitute the only
  1467.    messages in a one-pass CT-KIP exchange.
  1468.  
  1469. C.2.  Example of a <ClientHello> message indicating support for two-pass
  1470.       CT-KIP
  1471.  
  1472.    The client indicates support both for the two-pass key transport
  1473.    variant as well as the two-pass key wrap variant.
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511. Nystroem & Machani       Expires April 17, 2007                [Page 27]
  1512.  
  1513. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1514.  
  1515.  
  1516.    <?xml version="1.0" encoding="UTF-8"?>
  1517.    <ClientHello
  1518.      xmlns:ct-kip=
  1519.      "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
  1520.      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  1521.      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  1522.      Version="1.0">
  1523.      <TokenID>12345678</TokenID>
  1524.      <TriggerNonce>112dsdfwf312asder394jw==</TriggerNonce>
  1525.      <SupportedKeyTypes>
  1526.        <Algorithm>
  1527.          http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
  1528.          otps-wst#SecurID-AES
  1529.        </Algorithm>
  1530.      </SupportedKeyTypes>
  1531.      <SupportedEncryptionAlgorithms>
  1532.        <Algorithm>http://www.w3.org/2001/04/xmlenc#rsa-1_5</Algorithm>
  1533.        <Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128</Algorithm>
  1534.        <Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas
  1535.        /2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
  1536.      </SupportedEncryptionAlgorithms>
  1537.      <SupportedMACAlgorithms>
  1538.        <Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas
  1539.        /2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
  1540.      </SupportedMACAlgorithms>
  1541.      <Extensions>
  1542.        <Extension xsi:type="ct-kip:TwoPassSupportType">
  1543.          <SupportedKeyInitializationMethod>
  1544.          http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
  1545.          ct-kip#wrap
  1546.          </SupportedKeyInitializationMethod>
  1547.          <Payload xsi:type="ds:KeyInfoType">
  1548.            <ds:KeyName>Key-001</ds:KeyName>
  1549.          </Payload>
  1550.         <SupportedKeyInitializationMethod>
  1551.         http://www.rsasecurity.com/rsalabs/otps/schemas
  1552.         /2005/12/ct-kip#transport
  1553.         </SupportedKeyInitializationMethod>
  1554.          <Payload xsi:type="ds:KeyInfoType">
  1555.            <ds:X509Data>
  1556.              <ds:X509Certificate>miib</ds:X509Certificate>
  1557.            </ds:X509Data>
  1558.          </Payload>
  1559.        </Extension>
  1560.      </Extensions>
  1561.    </ClientHello>
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567. Nystroem & Machani       Expires April 17, 2007                [Page 28]
  1568.  
  1569. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1570.  
  1571.  
  1572. C.3.  Example of a <ServerFinished> message using the key transport
  1573.       profile
  1574.  
  1575.    In this example, the server responds to the previous request using
  1576.    the key transport profile.
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594.  
  1595.  
  1596.  
  1597.  
  1598.  
  1599.  
  1600.  
  1601.  
  1602.  
  1603.  
  1604.  
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623. Nystroem & Machani       Expires April 17, 2007                [Page 29]
  1624.  
  1625. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1626.  
  1627.  
  1628.    <?xml version="1.0" encoding="UTF-8"?>
  1629.    <ServerFinished
  1630.      xmlns:ct-kip=
  1631.      "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
  1632.      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  1633.      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  1634.      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
  1635.      Version="1.0" SessionID="4114" Status="Success">
  1636.      <TokenID>12345678</TokenID>
  1637.      <KeyID>43212093</KeyID>
  1638.      <KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
  1639.      <ServiceID>Example Enterprise Name</ServiceID>
  1640.      <UserID>exampleLoginName</UserID>
  1641.      <Extensions>
  1642.        <Extension xsi:type="ct-kip:KeyInitializationDataType">
  1643.          <KeyInitializationMethod>
  1644.            http://www.rsasecurity.com/rsalabs/otps/schemas/2006/05/
  1645.            ct-kip#transport</KeyInitializationMethod>
  1646.          <Payload xsi:type="xenc:EncryptedKeyType"
  1647.           Type="http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
  1648.           otps-wst#SecurID-AES">
  1649.            <xenc:EncryptionMethod
  1650.            Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
  1651.            <ds:KeyInfo>
  1652.              <ds:X509Data>
  1653.                <ds:X509Certificate>miib</ds:X509Certificate>
  1654.              </ds:X509Data>
  1655.            </ds:KeyInfo>
  1656.            <xenc:CipherData>
  1657.              <xenc:CipherValue>abcd</xenc:CipherValue>
  1658.            </xenc:CipherData>
  1659.            <xenc:CarriedKeyName>43212093</xenc:CarriedKeyName>
  1660.          </Payload>
  1661.        </Extension>
  1662.        <Extension xsi:type="ct-kip:OTPKeyConfigurationDataType">
  1663.          <OTPFormat>Decimal</OTPFormat>
  1664.          <OTPLength>6</OTPLength>
  1665.          <OTPMode><Time/></OTPMode>
  1666.        </Extension>
  1667.      </Extensions>
  1668.      <Mac
  1669.      MacAlgorithm="http://www.rsasecurity.com/rsalabs/otps/schemas
  1670.      /2005/11/ct-kip#ct-kip-prf-aes">miidfasde312asder394jw==
  1671.      </Mac>
  1672.    </ServerFinished>
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679. Nystroem & Machani       Expires April 17, 2007                [Page 30]
  1680.  
  1681. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1682.  
  1683.  
  1684. C.4.  Example of a <ServerFinished> message using the key wrap profile
  1685.  
  1686.    In this example, the server responds to the previous request using
  1687.    the key wrap profile.
  1688.  
  1689.    <?xml version="1.0" encoding="UTF-8"?>
  1690.    <ServerFinished
  1691.      xmlns:ct-kip=
  1692.      "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
  1693.      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  1694.      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  1695.      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
  1696.      Version="1.0" SessionID="4114" Status="Success">
  1697.      <TokenID>12345678</TokenID>
  1698.      <KeyID>43212093</KeyID>
  1699.      <KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
  1700.      <ServiceID>Example Enterprise Name</ServiceID>
  1701.      <UserID>exampleLoginName</UserID>
  1702.      <Extensions>
  1703.        <Extension xsi:type="ct-kip:KeyInitializationDataType">
  1704.          <KeyInitializationMethod>
  1705.            http://www.rsasecurity.com/rsalabs/otps/schemas
  1706.            /2006/05/ct-kip#wrap</KeyInitializationMethod>
  1707.          <Payload xsi:type="xenc:EncryptedKeyType"
  1708.           Type="http://www.rsasecurity.com/rsalabs/otps/schemas
  1709.           /2005/09/otps-wst#SecurID-AES">
  1710.            <xenc:EncryptionMethod
  1711.            Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
  1712.            <ds:KeyInfo>
  1713.              <ds:KeyName>Key-001</ds:KeyName>
  1714.            </ds:KeyInfo>
  1715.            <xenc:CipherData>
  1716.              <xenc:CipherValue>abcd</xenc:CipherValue>
  1717.            </xenc:CipherData>
  1718.            <xenc:CarriedKeyName>43212093</xenc:CarriedKeyName>
  1719.          </Payload>
  1720.        </Extension>
  1721.        <Extension xsi:type="ct-kip:OTPKeyConfigurationDataType">
  1722.          <OTPFormat>Decimal</OTPFormat>
  1723.          <OTPLength>6</OTPLength>
  1724.          <OTPMode><Time/></OTPMode>
  1725.        </Extension>
  1726.      </Extensions>
  1727.      <Mac MacAlgorithm="http://www.rsasecurity.com/rsalabs/otps/schemas
  1728.      /2005/12/ct-kip#ct-kip-prf-aes">miidfasde312asder394jw==
  1729.      </Mac>
  1730.    </ServerFinished>
  1731.  
  1732.  
  1733.  
  1734.  
  1735. Nystroem & Machani       Expires April 17, 2007                [Page 31]
  1736.  
  1737. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1738.  
  1739.  
  1740. C.5.  Example of a <ServerFinished> message using the passphrase-based
  1741.       key wrap profile
  1742.  
  1743.    In this example, the server responds to the previous request using
  1744.    the passphrase-based key wrap profile.
  1745.  
  1746.    <?xml version="1.0" encoding="UTF-8"?>
  1747.    <ServerFinished
  1748.      xmlns:ct-kip=
  1749.      "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
  1750.      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  1751.      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  1752.      xmlns:xenc=http://www.w3.org/2001/04/xmlenc#
  1753.      xmlns:pkcs-5=
  1754.      "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
  1755.      Version="1.0" SessionID="4114" Status="Success">
  1756.      <TokenID>12345678</TokenID>
  1757.      <KeyID>43212093</KeyID>
  1758.      <KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
  1759.      <ServiceID>Example Enterprise Name</ServiceID>
  1760.      <UserID>exampleLoginName</UserID>
  1761.      <Extensions>
  1762.        <Extension xsi:type="ct-kip-two-pass:KeyInitializationDataType">
  1763.          <KeyInitializationMethod>
  1764.            http://www.rsasecurity.com/rsalabs/otps/schemas/2006/03
  1765.            /ct-kip#passphrase-wrap</KeyInitializationMethod>
  1766.          <Payload xsi:type="xenc:EncryptedKeyType"
  1767.           Type="http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
  1768.           otps-wst#SecurID-AES">
  1769.            <xenc:EncryptionMethod
  1770.             Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas
  1771.             /pkcs-5#pbes2">
  1772.              <pkcs-5:PBES2-params>
  1773.                <KeyDerivationFunc Algorithm="http://www.rsasecurity.com
  1774.                /rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
  1775.                  <pkcs-5:PBKDF2-params>
  1776.                    <Salt>
  1777.                      <Specified>32113435</Specified>
  1778.                    </Salt>
  1779.                    <IterationCount>1024</IterationCount>
  1780.                    <KeyLength>128</KeyLength>
  1781.                    <PRF/>
  1782.                  </pkcs-5:PBKDF2-params>
  1783.                </KeyDerivationFunc>
  1784.                 <EncryptionScheme Algorithm="http://www.w3.org/2001/04
  1785.                 /xmlenc#kw-aes128-cbc">
  1786.              </EncryptionScheme>
  1787.          </pkcs-5:PBES2-params>
  1788.  
  1789.  
  1790.  
  1791. Nystroem & Machani       Expires April 17, 2007                [Page 32]
  1792.  
  1793. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1794.  
  1795.  
  1796.            </xenc:EncryptionMethod>
  1797.            <ds:KeyInfo>
  1798.          <ds:KeyName>Passphrase1</ds:KeyName>
  1799.            </ds:KeyInfo>
  1800.            <xenc:CipherData>
  1801.            <xenc:CipherValue>
  1802.                ZWcLvpFoXNHAG+lx3+Rww/Sic+o
  1803.              </xenc:CipherValue>
  1804.            </xenc:CipherData>
  1805.            <xenc:CarriedKeyName>43212093</xenc:CarriedKeyName>
  1806.          </Payload>
  1807.        </Extension>
  1808.        <Extension xsi:type="ct-kip:OTPKeyConfigurationDataType">
  1809.          <OTPFormat>Decimal</OTPFormat>
  1810.          <OTPLength>6</OTPLength>
  1811.          <OTPMode><Time/></OTPMode>
  1812.        </Extension>
  1813.      </Extensions>
  1814.      <Mac MacAlgorithm="http://www.rsasecurity.com/rsalabs/otps/schemas
  1815.        /2005/12/ct-kip#ct-kip-prf-aes">miidfasde312asder394jw==
  1816.      </Mac>
  1817.    </ServerFinished>
  1818.  
  1819.  
  1820.  
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847. Nystroem & Machani       Expires April 17, 2007                [Page 33]
  1848.  
  1849. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1850.  
  1851.  
  1852. Appendix D.  Integration with PKCS #11
  1853.  
  1854. D.1.  The 2-pass variant
  1855.  
  1856.    A suggested procedure to perform 2-pass CT-KIP with a cryptographic
  1857.    token through the PKCS #11 interface using the mechanisms defined in
  1858.    [7] is as follows (see also [1]):
  1859.  
  1860.    a. On the client side,
  1861.  
  1862.       1. The client selects a suitable slot and token (e.g. through use
  1863.          of the <TokenID> or the <PlatformInfo> element of the CT-KIP
  1864.          trigger message).
  1865.  
  1866.       2. A nonce R is generated, e.g. by calling C_SeedRandom and
  1867.          C_GenerateRandom.
  1868.  
  1869.       3. The client sends its first message to the server, including the
  1870.          nonce R.
  1871.  
  1872.    b. On the server side,
  1873.  
  1874.       1. A generic key K = K_TOKEN | K _MAC (where '|' denotes
  1875.          concatenation) is generated, e.g. by calling C_GenerateKey
  1876.          (using key type CKK_GENERIC_SECRET).  The template for K shall
  1877.          allow it to be exported (but only in wrapped form, i.e.
  1878.          CKA_SENSITIVE shall be set to CK_TRUE and CKA_EXTRACTABLE shall
  1879.          also be set to CK_TRUE), and also to be used for further key
  1880.          derivation.  From K, a token key K_TOKEN of suitable type is
  1881.          derived by calling C_DeriveKey using the PKCS #11 mechanism
  1882.          CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to
  1883.          the first bit of the generic secret key (i.e. set to 0).
  1884.          Likewise, a MAC key K_MAC is derived from K by calling
  1885.          C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism, this
  1886.          time setting CK_EXTRACT_PARAMS to the length of K (in bits)
  1887.          divided by two.
  1888.  
  1889.       2. The server wraps K with either the token's public key K_CLIENT,
  1890.          the shared secret key K_SHARED, or the derived shared secret
  1891.          key K_DERIVED by using C_WrapKey.  If use of the CT-KIP key
  1892.          wrap algorithm has been negotiated then the CKM_KIP_WRAP
  1893.          mechanism shall be used to wrap K. When calling C_WrapKey, the
  1894.          hKey handle in the CK_KIP_PARAMS structure shall be set to
  1895.          NULL_PTR.  The pSeed parameter in the CK_KIP_PARAMS structure
  1896.          shall point to the nonce R provided by the CT-KIP client, and
  1897.          the ulSeedLen parameter shall indicate the length of R. The
  1898.          hWrappingKey parameter in the call to C_WrapKey shall be set to
  1899.          refer to the wrapping key.
  1900.  
  1901.  
  1902.  
  1903. Nystroem & Machani       Expires April 17, 2007                [Page 34]
  1904.  
  1905. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1906.  
  1907.  
  1908.       3. Next, the server needs to calculate a MAC using K_MAC.  If use
  1909.          of the CT-KIP MAC algorithm has been negotiated, then the MAC
  1910.          is calculated by calling C_SignInit with the CKM_KIP_MAC
  1911.          mechanism followed by a call to C_Sign.  In the call to
  1912.          C_SignInit, K_MAC shall be the signature key, the hKey
  1913.          parameter in the CK_KIP_PARAMS structure shall be set to
  1914.          NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure
  1915.          shall be set to NULL_PTR, and the ulSeedLen parameter shall be
  1916.          set to zero.  In the call to C_Sign, the pData parameter shall
  1917.          be set to the concatenation of the string ID_S and the nonce R,
  1918.          and the ulDataLen parameter shall be set to the length of the
  1919.          concatenated string.  The desired length of the MAC shall be
  1920.          specified through the pulSignatureLen parameter and shall be
  1921.          set to the length of R.
  1922.  
  1923.       4. If the server also needs to authenticate its message (due to an
  1924.          existing K_TOKEN being replaced), the server shall calculate a
  1925.          second MAC.  Again, if use of the CT-KIP MAC algorithm has been
  1926.          negotiated, then the MAC is calculated by calling C_SignInit
  1927.          with the CKM_KIP_MAC mechanism followed by a call to C_Sign.
  1928.          In this call to C_SignInit, the K_MAC existing before this CT-
  1929.          KIP protocol run shall be the signature key, the hKey parameter
  1930.          in the CK_KIP_PARAMS structure shall be set to NULL, the pSeed
  1931.          parameter of the CT_KIP_PARAMS structure shall be set to
  1932.          NULL_PTR, and the ulSeeidLen parameter shall be set to zero.
  1933.          In the call to C_Sign, the pData parameter shall be set to the
  1934.          concatenation of the string ID_S and the nonce R, and the
  1935.          ulDataLen parameter shall be set to the length of concatenated
  1936.          string.  The desired length of the MAC shall be specified
  1937.          through the pulSignatureLen parameter and shall be set to the
  1938.          length of R.
  1939.  
  1940.       5. The server sends its message to the client, including the
  1941.          wrapped key K, the MAC and possibly also the authenticating
  1942.          MAC.
  1943.  
  1944.    c. On the client side,
  1945.  
  1946.       1. The client calls C_UnwrapKey to receive a handle to K. After
  1947.          this, the client calls C_DeriveKey twice: Once to derive
  1948.          K_TOKEN and once to derive K_MAC.  The client shall use the
  1949.          same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same
  1950.          mechanism parameters as used by the server above.  When calling
  1951.          C_UnwrapKey and C_DeriveKey, the pTemplate parameter shall be
  1952.          used to set additional key attributes in accordance with local
  1953.          policy and as negotiated and expressed in the protocol.  In
  1954.          particular, the value of the <KeyID> element in the server's
  1955.          response message may be used as CKA_ID for K_TOKEN.  The key K
  1956.  
  1957.  
  1958.  
  1959. Nystroem & Machani       Expires April 17, 2007                [Page 35]
  1960.  
  1961. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  1962.  
  1963.  
  1964.          shall be destroyed after deriving K_TOKEN and K_MAC.
  1965.  
  1966.       2. The MAC is verified in a reciprocal fashion as it was generated
  1967.          by the server.  If use of the CKM_KIP_MAC mechanism has been
  1968.          negotiated, then in the call to C_VerifyInit, the hKey
  1969.          parameter in the CK_KIP_PARAMS structure shall be set to
  1970.          NULL_PTR, the pSeed parameter shall be set to NULL_PTR, and
  1971.          ulSeedLen shall be set to 0.  The hKey parameter of
  1972.          C_VerifyInit shall refer to K_MAC.  In the call to C_Verify,
  1973.          pData shall be set to the concatenation of the string ID_S and
  1974.          the nonce R, and the ulDataLen parameter shall be set to the
  1975.          length of the concatenated string, pSignature to the MAC value
  1976.          received from the server, and ulSignatureLen to the length of
  1977.          the MAC.  If the MAC does not verify the protocol session ends
  1978.          with a failure.  The token shall be constructed to not "commit"
  1979.          to the new K_TOKEN or the new K_MAC unless the MAC verifies.
  1980.  
  1981.       3. If an authenticating MAC was received (required if the new
  1982.          K_TOKEN will replace an existing key on the token), then it is
  1983.          verified in a similar vein but using the K_MAC associated with
  1984.          this server and existing before the protocol run.  Again, if
  1985.          the MAC does not verify the protocol session ends with a
  1986.          failure, and the token must be constructed no to "commit" to
  1987.          the new K_TOKEN or the new K_MAC unless the MAC verifies.
  1988.  
  1989. D.2.  The 1-pass variant
  1990.  
  1991.    A suggested procedure to perform 1-pass CT-KIP with a cryptographic
  1992.    token through the PKCS #11 interface using the mechanisms defined in
  1993.    [7] is as follows (see also [1]):
  1994.  
  1995.    a. On the server side,
  1996.  
  1997.       1. A generic key K = K_TOKEN | K _MAC (where '|' denotes
  1998.          concatenation) is generated, e.g. by calling C_GenerateKey
  1999.          (using key type CKK_GENERIC_SECRET).  The template for K shall
  2000.          allow it to be exported (but only in wrapped form, i.e.
  2001.          CKA_SENSITIVE shall be set to CK_TRUE and CKA_EXTRACTABLE shall
  2002.          also be set to CK_TRUE), and also to be used for further key
  2003.          derivation.  From K, a token key K_TOKEN of suitable type is
  2004.          derived by calling C_DeriveKey using the PKCS #11 mechanism
  2005.          CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to
  2006.          the first bit of the generic secret key (i.e. set to 0).
  2007.          Likewise, a MAC key K_MAC is derived from K by calling
  2008.          C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism, this
  2009.          time setting CK_EXTRACT_PARAMS to the length of K (in bits)
  2010.          divided by two.
  2011.  
  2012.  
  2013.  
  2014.  
  2015. Nystroem & Machani       Expires April 17, 2007                [Page 36]
  2016.  
  2017. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  2018.  
  2019.  
  2020.       2. The server wraps K with either the token's public key,
  2021.          K_CLIENT, the shared secret key, K_SHARED, or the derived
  2022.          shared secret key, K_DERIVED by using C_WrapKey.  If use of the
  2023.          CT-KIP key wrap algorithm has been negotiated, then the
  2024.          CKM_KIP_WRAP mechanism shall be used to wrap K. When calling
  2025.          C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure shall
  2026.          be set to NULL_PTR.  The pSeed parameter in the CK_KIP_PARAMS
  2027.          structure shall point to the octet-string representation of an
  2028.          integer I whose value shall be incremented before each protocol
  2029.          run, and the ulSeedLen parameter shall indicate the length of
  2030.          the octet-string representation of I. The hWrappingKey
  2031.          parameter in the call to C_WrapKey shall be set to refer to the
  2032.          wrapping key.
  2033.  
  2034.          Note: The integer-to-octet string conversion shall be made
  2035.          using the I2OSP primitive from [8].  There shall be no leading
  2036.          zeros.
  2037.  
  2038.       3. For the server's message to the client, if use of the CT-KIP
  2039.          MAC algorithm has been negotiated, then the MAC is calculated
  2040.          by calling C_SignInit with the CKM_KIP_MAC mechanism followed
  2041.          by a call to C_Sign.  In the call to C_SignInit, K_MAC shall be
  2042.          the signature key, the hKey parameter in the CK_KIP_PARAMS
  2043.          structure shall be set to NULL_PTR, the pSeed parameter of the
  2044.          CT_KIP_PARAMS structure shall be set to NULL_PTR, and the
  2045.          ulSeedLen parameter shall be set to zero.  In the call to
  2046.          C_Sign, the pData parameter shall be set to the concatenation
  2047.          of the string ID_S and the octet-string representation of the
  2048.          integer I, and the ulDataLen parameter shall be set to the
  2049.          length of concatenated string.  The desired length of the MAC
  2050.          shall be specified through the pulSignatureLen parameter as
  2051.          usual, and shall be equal to, or greater than, sixteen (16).
  2052.  
  2053.       4. If the server also needs to authenticate its message (due to an
  2054.          existing K_TOKEN being replaced), the server calculates a
  2055.          second MAC.  If the CT-KIP MAC mechanism is used, the server
  2056.          does this by calling C_SignInit with the CKM_KIP_MAC mechanism
  2057.          followed by a call to C_Sign.  In the call to C_SignInit, the
  2058.          K_MAC existing on the token before this protocol run shall be
  2059.          the signature key, the hKey parameter in the CK_KIP_PARAMS
  2060.          structure shall be set to NULL_PTR, the pSeed parameter of the
  2061.          CT_KIP_PARAMS structure shall be set to NULL_PTR, and the
  2062.          ulSeedLen parameter shall be set to zero.  In the call to
  2063.          C_Sign, the pData parameter shall be set to the concatenation
  2064.          of the string ID_S and the octet-string representation of the
  2065.          integer I+1 (i.e.  I shall be incremented before each use), and
  2066.          the ulDataLen parameter shall be set to the length of the
  2067.          concatenated string.  The desired length of the MAC shall be
  2068.  
  2069.  
  2070.  
  2071. Nystroem & Machani       Expires April 17, 2007                [Page 37]
  2072.  
  2073. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  2074.  
  2075.  
  2076.          specified through the pulSignatureLen parameter as usual, and
  2077.          shall be equal to, or greater than, sixteen (16).
  2078.  
  2079.       5. The server sends its message to the client, including the MAC
  2080.          and possibly also the authenticating MAC.
  2081.  
  2082.    b. On the client side,
  2083.  
  2084.       1. The client calls C_UnwrapKey to receive a handle to K. After
  2085.          this, the client calls C_DeriveKey twice: Once to derive
  2086.          K_TOKEN and once to derive K_MAC.  The client shall use the
  2087.          same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same
  2088.          mechanism parameters as used by the server above.  When calling
  2089.          C_UnwrapKey and C_DeriveKey, the pTemplate parameter shall be
  2090.          used to set additional key attributes in accordance with local
  2091.          policy and as negotiated and expressed in the protocol.  In
  2092.          particular, the value of the <KeyID> element in the server's
  2093.          response message may be used as CKA_ID for K_TOKEN.  The key K
  2094.          shall be destroyed after deriving K_TOKEN and K_MAC.
  2095.  
  2096.       2. The MAC is verified in a reciprocal fashion as it was generated
  2097.          by the server.  If use of the CKM_KIP_MAC mechanism has been
  2098.          negotiated, then in the call to C_VerifyInit, the hKey
  2099.          parameter in the CK_KIP_PARAMS structure shall be set to
  2100.          NULL_PTR, the pSeed parameter shall be set to NULL_PTR, and
  2101.          ulSeedLen shall be set to 0.  The hKey parameter of
  2102.          C_VerifyInit shall refer to K_MAC.  In the call to C_Verify,
  2103.          pData shall be set to the concatenation of the string ID_S and
  2104.          the octet-string representation of the provided value for I,
  2105.          and the ulDataLen parameter shall be set to the length of the
  2106.          concatenated string, pSignature to the MAC value received from
  2107.          the server, and ulSignatureLen to the length of the MAC.  If
  2108.          the MAC does not verify or if the provided value of I is not
  2109.          larger than any stored value I' for the identified server ID_S
  2110.          the protocol session ends with a failure.  The token shall be
  2111.          constructed to not "commit" to the new K_TOKEN or the new K_MAC
  2112.          unless the MAC verifies.  If the verification succeeds, the
  2113.          token shall store the provided value of I as a new I' for ID_S.
  2114.  
  2115.       3. If an authenticating MAC was received (required if K_TOKEN will
  2116.          replace an existing key on the token), it is verified in a
  2117.          similar vein but using the K_MAC existing before the protocol
  2118.          run.  Again, if the MAC does not verify the protocol session
  2119.          ends with a failure, and the token must be constructed no to
  2120.          "commit" to the new K_TOKEN or the new K_MAC unless the MAC
  2121.          verifies.
  2122.  
  2123.  
  2124.  
  2125.  
  2126.  
  2127. Nystroem & Machani       Expires April 17, 2007                [Page 38]
  2128.  
  2129. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  2130.  
  2131.  
  2132. Appendix E.  About OTPS
  2133.  
  2134.    The One-Time Password Specifications are documents produced by RSA
  2135.    Laboratories in cooperation with secure systems developers for the
  2136.    purpose of simplifying integration and management of strong
  2137.    authentication technology into secure applications, and to enhance
  2138.    the user experience of this technology.
  2139.  
  2140.    Further development of the OTPS series will occur through mailing
  2141.    list discussions and occasional workshops, and suggestions for
  2142.    improvement are welcome.  As for our PKCS documents, results may also
  2143.    be submitted to standards forums.  For more information, contact:
  2144.  
  2145.    OTPS Editor
  2146.    RSA, The Security Division of EMC
  2147.    174 Middlesex Turnpike
  2148.    Bedford, MA  01730 USA
  2149.    otps-editor@rsasecurity.com
  2150.    http://www.rsasecurity.com/rsalabs/
  2151.  
  2152.  
  2153.  
  2154.  
  2155.  
  2156.  
  2157.  
  2158.  
  2159.  
  2160.  
  2161.  
  2162.  
  2163.  
  2164.  
  2165.  
  2166.  
  2167.  
  2168.  
  2169.  
  2170.  
  2171.  
  2172.  
  2173.  
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.  
  2183. Nystroem & Machani       Expires April 17, 2007                [Page 39]
  2184.  
  2185. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  2186.  
  2187.  
  2188. Authors' Addresses
  2189.  
  2190.    Magnus Nystroem
  2191.    RSA, The Security Division of EMC
  2192.  
  2193.    Email: magnus@rsasecurity.com
  2194.  
  2195.  
  2196.    Salah Machani
  2197.    Diversinet Corp.
  2198.  
  2199.    Email: smachani@diversinet.com
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.  
  2211.  
  2212.  
  2213.  
  2214.  
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.  
  2239. Nystroem & Machani       Expires April 17, 2007                [Page 40]
  2240.  
  2241. Internet-Draft            1- and 2-pass CT-KIP              October 2006
  2242.  
  2243.  
  2244. Intellectual Property Statement
  2245.  
  2246.    The IETF takes no position regarding the validity or scope of any
  2247.    Intellectual Property Rights or other rights that might be claimed to
  2248.    pertain to the implementation or use of the technology described in
  2249.    this document or the extent to which any license under such rights
  2250.    might or might not be available; nor does it represent that it has
  2251.    made any independent effort to identify any such rights.  Information
  2252.    on the procedures with respect to rights in RFC documents can be
  2253.    found in BCP 78 and BCP 79.
  2254.  
  2255.    Copies of IPR disclosures made to the IETF Secretariat and any
  2256.    assurances of licenses to be made available, or the result of an
  2257.    attempt made to obtain a general license or permission for the use of
  2258.    such proprietary rights by implementers or users of this
  2259.    specification can be obtained from the IETF on-line IPR repository at
  2260.    http://www.ietf.org/ipr.
  2261.  
  2262.    The IETF invites any interested party to bring to its attention any
  2263.    copyrights, patents or patent applications, or other proprietary
  2264.    rights that may cover technology that may be required to implement
  2265.    this standard.  Please address the information to the IETF at
  2266.    ietf-ipr@ietf.org.
  2267.  
  2268.  
  2269. Disclaimer of Validity
  2270.  
  2271.    This document and the information contained herein are provided on an
  2272.    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  2273.    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  2274.    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  2275.    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  2276.    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  2277.    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  2278.  
  2279.  
  2280. Copyright Statement
  2281.  
  2282.    Copyright (C) The Internet Society (2006).  This document is subject
  2283.    to the rights, licenses and restrictions contained in BCP 78, and
  2284.    except as set forth therein, the authors retain all their rights.
  2285.  
  2286.  
  2287. Acknowledgment
  2288.  
  2289.    Funding for the RFC Editor function is currently provided by the
  2290.    Internet Society.
  2291.  
  2292.  
  2293.  
  2294.  
  2295. Nystroem & Machani       Expires April 17, 2007                [Page 41]
  2296.  
  2297.