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