Internet DRAFT - draft-hallambaker-oathxkms
draft-hallambaker-oathxkms
Internet Draft P. Hallam-Baker
Document: draft-hallambaker-oathxkms-00.txt VeriSign Inc.
Expires: August 2006 Jeff Bohren
BMC Software
February 2006
XKMS Provisioning of OATH Shared Secret Keys
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.
Abstract
A means of provisioning OATH shared secret OTP parameters based on
the XKMS protocol is described. The techniques used may be extended
to support XKMS registration of symmetric keys for other
cryptographic protocols. It is hoped that publication of this note
will allow others to make use of the same architectural approach as a
starting point for future proposals.
This work is a joint effort by the members of OATH (Initiative for
Open AuTHentication) to specify an algorithm that can be freely
distributed to the technical community. The authors believe that a
common and shared specification will facilitate adoption of two-
factor authentication on the Internet by enabling interoperability
commercial and open-source implementations.
Hallam-Baker Expires August 2006 Page 1
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
Contents
XKMS Provisioning of OATH Shared Secret Keys........................1
Status of this Memo...............................................1
Abstract..........................................................1
Contents............................................................2
1. Conventions used in this document................................2
2. Requirements.....................................................2
2.1 Use Cases.....................................................2
2.2 Constraints...................................................5
3. The XKMS Key Registration Service Specification..................6
3.1 Extension to Shared Secret Keys...............................7
3.2 Secret Key Identifier.........................................7
3.3 Key Generation................................................7
4. XKRSS Profile....................................................9
4.1 Identifiers...................................................9
4.2 SOAP Binding..................................................9
4.3 Authentication Binding.......................................10
4.4 Request......................................................10
4.5 Response.....................................................11
5. Example Messages (Non-normative)................................12
5.1 Server Generated Key.........................................12
5.2 Mutual Generated Key.........................................14
6. References......................................................18
1.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RRC 2119].
2.
Requirements
We consider three specific use cases that are believed to be
indicative of the situations in which the provisioning protocol might
be employed. These use cases are intended to be illustrative rather
than exhaustive. For example a token issuer that purchases a large
number of tokens intending to re-initialize them before issue is
likely to find that their particular situation is closer to the
manufacturing use case than initialization before issue.
2.1
Use Cases
The provisioning protocol is designed to meet the needs of three
principal use cases corresponding to initialization at three
different stages in the token life cycle.
Hallam-Baker Expires August 2006 Page 2
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
Direct Static Provisioning (Bulk initialization)
In most cases an OATH token will be initialized during manufacture.
This is likely to be the case even if the purchaser of the token is
likely to re-initialize the token on receipt. The Device
Initialization Tool obtains one or more credentials from a Credential
Issuer. These are then installed in the OTP devices by the
manufacturing equipment (Figure 1).
Device Credential
Initialization <----Standard Protocol ---> Issuer
Tool
|
|
/ Possible
| Interruption
|
Manufacturing
Equipment
|
|
Devices
Figure 1: Bulk initialization Use Case
The requirement for interoperability and thus the scope of the
standards proposal in this particular use case is limited to
communications between the Device Initialization Tool and the
Credential Issuer. Credential issuers require the ability to service
devices produced by multiple manufacturers. Manufacturers require the
ability to obtain credentials from multiple issuers at different
times. Both parties want to minimize partner specific configuration.
In a manufacturing environment reliability and throughput are
critical. A provisioning protocol that requires the manufacturing
machinery to perform complex or lengthy calculation is unacceptable.
Manufacturing environments are frequently hostile to network
communications and the ability to continue production during brief
network outages is generally considered essential.
Requirement: Standards based protocol for communication between
Device Initialization Tool and the Credential Issuer.
Requirement: Bulk initialization of multiple tokens
Hallam-Baker Expires August 2006 Page 3
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
Requirement: Protocol must not require the manufacturing
equipment to perform complex or lengthy calculation
Inferred Requirement: Server generated keys
Issuance to OTA Provisioning Service:
The Credential Issuer supplies OATH authentication credentials to an
Over-the-Air (OTA) Provisioning Service operated by a external entity
(e.g., application service provider, mobile operator, or enterprise
customer), for subsequent delivery of individual credentials to end
user mobile devices. The provisioning service receives stores
credentials securely for future wireless download to the user device.
Requirement: Supports bulk (pre-ordered range of tokens) and on-
demand (real-time request/response) issuance.
Requirement: Allows token IDs to be assigned by either the
credential issuer or the provisioning service.
Administrator initialization before issue
While bulk initialization under controlled conditions during
manufacture is likely to meet the security needs of most applications
reliance on a pre-disclosed secret is unacceptable to some
circumstances, in particular tokens issued for classified government
use.
In such cases the token issuer requires the ability to remove all the
secret information installed on the token during manufacture and
replace it with secret keys established under conditions controlled
by the issuer.
It is however in most cases impractical for the administrator to
apply a physical marking to the token itself such as a serial number.
It is therefore necessary for the enrolment process to communicate
the token serial number to the provisioning service. Another
situation in which initialization before use is required is the case
where the OTP functionality is installed on a previously manufactured
device as software (Figure 2).
Hallam-Baker Expires August 2006 Page 4
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
Administrator Credential
Initialization <----Standard Protocol ---> Issuer
Tool
|
|
|
Device
Figure 2: Initialization before issue Use Case
Requirement: Administrator Initialization Tool to communicate a
token serial number or other physical indicata to credential
issuer.
Requirement: Administrator Initialization Tool to agree new
shared secret information with the credential issuer.
Requirement: Administrator to be able to demonstrate that the
shared secret information in the token has been generated in
compliance with security practices.
Requirement: Credential Issuer to be able to demonstrate that
the shared secret information in the token has been generated
in compliance with security practices.
Architectural Approaches
The manufacturing use case clearly points to the use of a
provisioning protocol where the secret key material is generated by
the provisioning service. This corresponds to ‘server generated keys’
in terms of XKMS.
While this approach may be appropriate in some after-issue situations
it does not meet all the requirements identified in the after-issue
use cases. These use cases suggest the need for the client to
participate in the generation of the secret key material. This
corresponds to a new mode of key generation that is at present only
applicable to symmetric key protocols in which both the client and
server make a verifiable contribution to the randomness of the shared
secret.
2.2
Constraints
Existing open standards
Design, development and review of cryptographic security protocols is
an expensive and time consuming business requiring access to limited
Hallam-Baker Expires August 2006 Page 5
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
resources. Use of existing open standards is preferred whenever
possible and appropriate.
Constraint: The protocols chosen should be based on existing
open standards wherever possible
Web Services compliant
Web Services are increasingly the platform of choice for network
application protocols. In the case of a device
Constraint: The protocols chosen should be based on the Web
Services architecture
Support low speed devices
Most of the devices used to enroll in the protocol are highly
constrained offering minimal computation capability and communication
bandwidth. The overhead involved in XML processing in particular is
greater than these devices are typically capable of supporting.
Constraint: It should be possible for a low speed device to
participate in the protocol even if it is not capable of
supporting an XML processing stack.
PKI provisioning support
Combination tokens offer both OTP and PKI authentication. It is
clearly desirable to allow provisioning of the PKI secret key and the
OTP shared secret to be supported by a common infrastructure.
Constraint: The protocols chosen for provisioning the OTP shared
secret should be capable of provisioning PKI secret keys.
3.
The XKMS Key Registration Service Specification
The use cases and constraints are best met by an extension to the
XKMS Key Registration Service Specification (XKRSS) [XKMS]
XKRSS is an open standard agreed by the World Wide Web Consortium.
The XKMS protocol is a Web Service designed to support provisioning
of secret keys for PKI in both end user and bulk manufacture
applications.
Hallam-Baker Expires August 2006 Page 6
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
3.1
Extension to Shared Secret Keys
From an architectural point of view the problem of provisioning a
shared secret is very similar to the problem of provisioning a secret
key for use with an asymmetric algorithm.
* The secret key material must be transported in a form which
protects against disclosure to any third party.
* At the end of the protocol the secret material must be
established at the client.
* The security of protocols in which the secret key is employed
will depend on the secret being generated in an appropriately
secure manner, in particular the use of a sufficiently random
and un-guessable seed.
There are also important differences:
* When provisioning a shared-secret there is no ‘public key’
attribute to be considered.
* At the end of the protocol the secret key material must be
established at the provisioning service
3.2
Secret Key Identifier
The purpose of a PKI provisioning protocol is generally described in
terms of binding a collection of attributes such as a certificate
holder’s name to the public key.
In a shared-secret architecture there is no public key to bind the
attributes to. There is however a surrogate that serves the same
function. When an authentication service receives a request to
perform an authentication against a shared-secret an identifier must
be provided to inform the registry which shared secret is to be used.
A shared-secret identifier is a name: the choice of name is arbitrary
and semantics of the identifier are defined exclusively by the
registry. A public key is not a name: the choice is not arbitrary as
it must be the mathematical compliment of the private key itself
3.3
Key Generation
The requirement to establish the shared-secret at the provisioning
service has important consequences for the choice of key generation
Hallam-Baker Expires August 2006 Page 7
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
mechanism. In a PKI provisioning infrastructure the disclosure of the
private key to the provisioning service is a design choice that is
appropriate in some cases (e.g. escrow of encryption keys) and
inappropriate in others (e.g. signature or authentication keys).
In a shared secret provisioning infrastructure the shared secret must
be disclosed to the provisioning infrastructure by definition,
otherwise it has not been ‘shared’.
XKMS supports two modes of key generation, at the client and at the
server. Server side key generation is primarily intended for bulk
issue and applications where the key is to be escrowed. If the
private key is not to be escrowed by the service it is generally
preferable to generate it at the client and avoid the need to
transport it over the network at all.
Server Side Key Generation
Bulk issue of shared-secret keys is no different in principle to bulk
issue of PKI keys. The ability to use a single protocol to support
both types of provisioning is clearly a benefit to manufacturers and
issuers requiring bulk re-initialization. The only additional
requirement needed to support provisioning of OATH shared secrets is
to define an appropriate shared secret container.
Client Side Key Generation: Not applicable
The client side key generation protocol defined in XKMS does not meet
the needs of shared-secret generation described in the use cases and
does not appear to offer any benefit over server generated keys when
a symmetric key algorithm is involved.
Mutual Key Generation
In a mutual key generation the client and service both contribute
random material to the generated key. This allows both parties to
ensure that the generated key is sufficiently random and un-
guessable.
The key generation mechanism defined employs a Diffie-Hellman key
exchange.
* The client generates a random private key c and calculates the
corresponding public key e^c.
* The client public key e^c is communicated to the service.
Hallam-Baker Expires August 2006 Page 8
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
* The service generates a random private key s and calculates the
corresponding public key e^s.
* The service calculates the shared secret H(e^cs)
* The service public key e^s is communicated to the client.
* The client calculates the shared secret H(e^cs)
The established shared secret contains random information contributed
by both the client and the service. The shared secret will be
sufficiently random provided that one of the parties generated a
sufficiently random private key.
Although the Diffie-Hellman key exchange is considered to be a secure
public key exchange algorithm the security of the protocol against a
disclosure attack requires both parties to choose a sufficiently
random private key. The use of a secure transport protocol is
therefore required.
4.
XKRSS Profile
4.1
Identifiers
The following identifiers defined by external sources are used in
this document:
http://www.w3.org/2002/03/xkms#
XKMS Schema
http://www.w3.org/2000/09/xmldsig#
XML Signature Schema
http://www.w3.org/2001/04/xmlenc#DHKeyValue
Diffie-Hellman key agreement
The following identifiers are defined and used in this document:
urn:ietf:rfc:4226
The OATH OTP specification
The following identifiers are defined and used in the Internet draft
Portable Shared Secret Container [Container]
http://www.openauthentication.org/2006/02/PSKC
Schema used to encode the HOTP shared secret parameter values
before encryption.
4.2
SOAP Binding
Hallam-Baker Expires August 2006 Page 9
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
Any of the bindings described in the document XML Key Management
Specification (XKMS 2.0) Bindings may be employed by a compliant
implementation.
The use of the following specific bindings is RECOMMENDED:
SOAP Binding: SOAP 1.2, SOAP over HTTP binding
Confidentiality Binding: SSL/TLS or WS-Security
Authentication Binding: Payload authentication (if required)
The XKMS specification does not define a WS-Security binding as the
design predates it. The use of WS-Security is preferred over TLS as
it provides support for firewall infrastructure.
4.3
Authentication Binding
The choice of payload authentication or a limited use shared secret
for authentication is determined by the application:
. Payload authentication using a pre-established public key is
preferred for bulk issue and administrative issue. Payload
authentication allows multiple registration requests to be
authenticated using a single signature.
. End-users cannot be expected to have an authentication mechanism
until after the registration process has been completed. In
these cases the KeyBindingAuthentication mechanism is
RECOMMENDED.
4.4
Request
Prototype Key Binding
The prototype key binding contains information that the client
requests be present in the keybinding resulting from the request.
A <KeyUsage> element MUST specify authentication (signature) as an
authorized use: http://www.w3.org/2002/03/xkms#Signature
A <RespondWith> element MUST request that a Diffie-Hellman
http://www.w3.org/2001/04/xmlenc#DHKeyValue
A <UseKeyWith> element of the prototype key binding MUST specify the
use of the OATH OTP protocol: urn:ietf:rfc:4226.
The <ds:KeyInfo> element SHOULD contain a <ds:KeyName> element
contains an identifier for the token to be registered. This
identifier need not be a physical identifier present on the token but
Hallam-Baker Expires August 2006 Page 10
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
will be the identifier used by the authentication service to identify
the token in an authentication request.
Administrators may make use of the <ValidityInterval> and
<RevocationCodeIdentifier> elements to provide additional control
over use of the token.
Additional Key Elements MAY be specified by including a portable key
container as defined by [Container] within the <ds:KeyInfo> element
A revocation code identifier is a self authenticating information
code that tells the provisioning service to revoke the corresponding
key binding. Use of the revocation code does not require either
authentication or a confidential channel to the provisioning service.
This allows a multi-function device to provide a means of securely,
reliably and verifiably terminating the validity of the key binding.
The shared secret MUST NOT be used as the revocation code. A one way
hash of the revocation code MAY be used.
Server Key Generation
A <RespondWith> value MUST specify that a private key value is
requested using the identifier
http://www.w3.org/2002/03/xkms#PrivateKey
Mutual Key Generation
A <RespondWith> value MUST specify that a request for a mutually
agreed key using the identifier: urn:ietf:rfc:4226
The <ds:KeyInfo> element of the <PrototypeKeyBinding> MUST include a
<ds:KeyValue> element that specifies the Diffie-Hellman public key
parameters of the client.
The requestor SHOULD specify a random value for the <Data> element.
The same value is returned in the encrypted Private key parameters in
the response allowing the requestor to verify that the value of the
key agreement generated at the server matches.
4.5
Response
Key Binding
The KeyBinding returned by the provisioning service must meet the
same constraints as the PrototypeKeyBinding specified in the request.
Hallam-Baker Expires August 2006 Page 11
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
Server Key Generation
If the request is successful the <PrivateKey> element MUST be present
and MUST contain the encrypted OTP parameters encoded under the
schema described in [Container]
Mutual Key Generation
If the request is successful the <ds:KeyInfo> element of the returned
<KeyBinding> MUST include a <ds:KeyValue> element that specifies the
Diffie-Hellman public key parameters newly generated by the service.
The shared secret is derived by applying the Diffie-Hellman key
agreement algorithm as specified in XML Encryption. The initial
counter value is 0.
The <PrivateKey> element MAY be present and MAY contain the encrypted
OTP parameters encoded under the schema described in [Container]. The
result of the Diffie-Hellman key agreement replaces the value
specified for the <Data> element if specified.
Appendix A: Example Messages (Non normative)
This section provides non-normative examples of using the
registration protocol. For clarity the XKMS transport and message
level security bindings are omitted.
A.1 Server Generated Key
This example meets the requirements set out in the ‘bulk
initialization’ use case. A client at the manufacturing site makes a
request for one or more private keys to be created and bound to a
specified token identifier.
For efficiency authentication and encryption are performed in this
particular instance using a pre-shared key. The pre-shared key might
be established through out of band configuration or by means of a
standard key agreement protocol. Alternatively public key protocols
might be used for authentication and encryption.
The pre-shared key used for MAC generation and encryption is:
3n9cjk4jks04jfw0934jsr09jwik4
Request
The request message is:
Hallam-Baker Expires August 2006 Page 12
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
<?xml version="1.0" encoding="utf-8"?>
<RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="I652c3870fcdc9d8259c554ace9175846"
Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<RespondWith>http://www.w3.org/2002/03/xkms#PrivateKey</RespondWith>
<PrototypeKeyBinding Id="I7d5d848c7a01682d22412b9e3ae74de7">
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:4226"
Identifier="ALNG000DE8FA/001" />
</PrototypeKeyBinding>
<Authentication>
<KeyBindingAuthentication>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
<ds:Reference URI="#I7d5d848c7a01682d22412b9e3ae74de7">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>/D4ocLWp/6RxP6XkH9qn5BvqGz0=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>0l9rxrH1dSd6B5E5RYKs5yVc+FM=
</ds:SignatureValue>
</ds:Signature>
</KeyBindingAuthentication>
</Authentication>
</RegisterRequest>
Response
The response contains a private key encrypted under the specified
private key.
The response message is:
<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="Id9daf1016925c55dac5030797eb8d244"
Service="http://test.xmltrustcenter.org/XKMS"
Hallam-Baker Expires August 2006 Page 13
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="I652c3870fcdc9d8259c554ace9175846"
xmlns="http://www.w3.org/2002/03/xkms#">
<KeyBinding Id="Ice130d2ae662b7644eb3f3654d929db1">
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:4226"
Identifier="ALNG000DE8FA/001" />
<Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
<ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidRe
ason>
<ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidRe
ason>
</Status>
</KeyBinding>
<PrivateKey>
<xenc:EncryptedData>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<xenc:CipherData>
<xenc:CipherValue>Hnp23IfB9Vpt5f4A6392Lqk3+h+Y999rJhpiexi+
xXEWokE1ntr0Z4q4u36hRy0PxAnUEovMpccfDwyJhKqooPrvOyfzX0QyGr
9Tlk2hax/siY3vOiRWl3fLYtuJgiI/wtu/6lvWZfv6Q8x4wBfQyrTFNyUR
eMmtBu7A/Hskk5mAGcvp4kZC/MTYJXfmvJpOiBiTm1nhoreoLDib5VKihJ
qDFuOcju/ONMN0kWM2rBqdmSq5k+xmZhf/qMx3b7ttygSyNuoKj2GVTmyL
ueGmiFqmQ/3Ek5oduYXo1GYPiibOz6HIyKVZRfyrtgm2lWB92bSYPS8GsR
jloIbs+nG4GmfTcD2knbCByVV0NIwI9Qxam1EZSAGtxowtnuYheWDYRj15
4O6LuqRNxTqr4oiQyU1Yl7x/mKTz</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</PrivateKey>
</RegisterResult>
A.2 Mutual Generated Key
This example meets the requirements set out in the use cases
describing registration after manufacture.
The shared secret is generated by means of the mutual key
establishment mechanism. The initial request is authenticated in this
particular case by means of a one time use pre-shared secret.
The pre-shared secret used to authenticate the request is 024837
Request
Hallam-Baker Expires August 2006 Page 14
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
The client makes use of a pre-generated Diffie-Hellman parameter set.
A new private key is generated randomly. In big-endian hexadecimal
format this key is:
A Private =
b483aec8 dc6978e6 7157c363 33e6babc a62c6082 e0d31eeb
698432b9 f3b72d13 b544e309 223728f2 82df47d9 9885a073
02f03990 21bf40fc 313d52ce 65d686b0 258a59f9 f847db5f
d7d03796 f9021d7f 1fcb66c6 280aaed2 eb07cc5e 6f89e9ae
2d4df737 69a18d59 b4dda0ff 5694d3de 7a27141c b4e6e83e
0df5b110 bf36b274
The request message is:
<?xml version="1.0" encoding="utf-8"?>
<RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="Ib9b0386caf44d6c6df3e4eec9f895c30"
Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<RespondWith>http://www.w3.org/2001/04/xmlenc#DHKeyValue</RespondWith
>
<PrototypeKeyBinding Id="I62f4453d6d4ed6bc9dd856e52d5eaa20">
<ds:KeyInfo>
<ds:KeyValue>
<xenc:DHKeyValue>
<xenc:P>4RG/7j64smZYmNL6Y4YdiMfZhJ8CCGqJOy1Qe3b9l/XO8ATv
fXdQJ+xdR+UQ0q5BTxZWgSWL/fFzQhH3V0GmeJZ4gpIC6OTqBJBnkSm/
ix85NUV8JLIatjjFTeAS6iCe06yTgSg1pmAC1TGLeU3MuPrAMOruzojq
7BLhBtlV59c=</xenc:P>
<xenc:Q>togFf3+94+GC+L+fbLWXqQC6yMAghpSnb7Zskn9T4n4n+qGS
GOwJoLE44Gx2iQaSTDfbGxONNZnwxh1Zd+ZBwQ==</xenc:Q>
<xenc:Generator>Rsp0nalaVmr5ggzfPMnkEbb5sdV2RDHCwKNL92tt
24eBOT9OfjvV/5z5TFQa+QM9FyNYM+GeNfQImW37PkzNv1kjDB9IuAw1Z
eIvEDKIyg86P2A/xOhrZ/26cwR0LMsRRSGDZlaOZsXgnMIUR7Zokjialv
Lz4xKB7Dis5gGMYW8=
</xenc:Generator>
<xenc:Public>YGAcOiFj6QN15JRohMVuP3Zh0xREgoWCT7mbFToW1dO
SNygQRnbdZzdOKvTBT1caEs8Cm/sPmjiNMiz/S3o+hdU1yDHuoVHS58W
FI7Ns6XC7pNMQHW08L7vlhJ+K8HyABKnWFPx7Uckwj7tfmfW5i9xDEgb
GoHM8U4mx7Hcw8tk=
</xenc:Public>
</xenc:DHKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
Hallam-Baker Expires August 2006 Page 15
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
<UseKeyWith Application="urn:ietf:rfc:4226"
Identifier="ALNG000DE8FA/001" />
</PrototypeKeyBinding>
<Authentication>
<KeyBindingAuthentication>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
<ds:Reference URI="#I62f4453d6d4ed6bc9dd856e52d5eaa20">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>vZrZ/snvEhb8OcyNKJ5577cCigQ=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>K7K6OA8j8ub3HV/fQmoHGhurLtE=
</ds:SignatureValue>
</ds:Signature>
</KeyBindingAuthentication>
</Authentication>
</RegisterRequest>
Response
The server private key is:
B Private =
b483aec8 dc6978e6 7157c363 33e6babc a62c6082 e0d31eeb
698432b9 f3b72d13 b544e309 223728f2 82df47d9 9885a073
02f03990 21bf40fc 313d52ce 65d686b0 258a59f9 f847db5f
d7d03796 f9021d7f 1fcb66c6 280aaed2 eb07cc5e 6f89e9ae
2d4df737 69a18d59 b4dda0ff 5694d3de 7a27141c b4e6e83e
0df5b110 bf36b274
The response message is:
<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="I9da626389715f998e75cbe1456514c89"
Service="http://test.xmltrustcenter.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="Ib9b0386caf44d6c6df3e4eec9f895c30"
xmlns="http://www.w3.org/2002/03/xkms#">
Hallam-Baker Expires August 2006 Page 16
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
<KeyBinding Id="I40aa6a1795ecb38e14f2db58f3f5874d">
<ds:KeyInfo>
<ds:KeyValue>
<xenc:DHKeyValue>
<xenc:Public>YGAcOiFj6QN15JRohMVuP3Zh0xREgoWCT7mbFToW1d
OSNygQRnbdZzdOKvTBT1caEs8Cm/sPmjiNMiz/S3o+hdU1yDHuoVHS5
8WFI7Ns6XC7pNMQHW08L7vlhJ+K8HyABKnWFPx7Uckwj7tfmfW5i9xD
EgbGoHM8U4mx7Hcw8tk=</xenc:Public>
</xenc:DHKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:4226"
Identifier="ALNG000DE8FA/001" />
<Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
<ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidRe
ason>
<ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidRe
ason>
</Status>
</KeyBinding>
</RegisterResult>
Key Generation
The mutually agreed key is:
Shared Key =
295b12b1 ea56c534 a6d52b53 9d147c14 b438d161 9a2cc6c3
7e46f99d b450b93b c44778ce 64cd99ee a4b68a74 23289571
1ffaaadd f6483c60 d31bb8f5 80184540 7d95b171 4f485a08
92d9f58a 7a0885c6 c811c392 d42d6d73 a3e5b023 e2928b15
76f3bfe9 c9fc7bfc 8d8d3a2f 96e24582 59b9f273 ee40f3c4
e2a0ba6c 835fbab8
The algorithm specified in [XML-ENC] is then used to derive the value
for the token secret:
Keying Material = KM(1) | KM(2) | ...
KM(counter) = DigestAlg ( Shared Key | counter | EncryptionAlg |
KeySize )
The value KA-Nonce is not used.
The string (counter | EncryptionAlg | KeySize) is:
Hallam-Baker Expires August 2006 Page 17
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
http://www.w3.org/2000/09/xmldsig#sha101urn:ietf:rfc:4226160
The value of the token secret is:
b20d1e4ffb796685d95340b33fdd6dde695ba6a0
Notices
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.
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."
References
[Container] Portable Shared Secret Container, Internet Draft, To be
published
[OATH] OATH Reference Architecture Version 1.0, Initiative for
Open Authentication. 2005.
[XKMS] Phillip Hallam-Baker, Shivaram H. Mysore, XML Key
Management Specification (XKMS 2.0) Version 2.0, W3C
Recommendation 28 June 2005, http://www.w3.org/TR/2005/REC-
xkms2-20050628/
[XKMS-B] Phillip Hallam-Baker, Shivaram H. Mysore, XML Key
Management Specification (XKMS 2.0) (Bindings) Version 2.0, W3C
Recommendation 28 June 2005, http://www.w3.org/TR/2005/REC-
xkms2-bindings-20050628/
[XML-SIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox
, E. Simon. XML-Signature Syntax and Processing, W3C
Recommendation, 12 February 2002. http://www.w3.org/TR/xmldsig-
core/.
[XML-ENC] D. Eastlake, J. Reagle, T. Imamura, B. Dillaway, E.
Simon, XML Encryption Syntax and Processing, W3C Recommendation,
10 December 2002, http://www.w3.org/TR/xmlenc-core/.
Hallam-Baker Expires August 2006 Page 18
XKMS Provisioning of OATH Shared Secret Keys Feb. 2006
[WS-Security] A. Nadalin et al., Web Services Security: SOAP Message
Security 1.1 (WS-Security 2004), OASIS Standard,
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
message-security-1.1.pdf.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
Acknowledgments
The authors would like to thank members of OATH (Initiative for Open
AuTHentication) for their help during the conception and development
of this document.
The authors of this document would like to emphasize the role of
persons who have made a key contribution to this document:
- Siddharth Bajaj, is the Director of Advanced Products and Research
at Verisign, Inc. He is also the chair of the Technology Focus Group
at OATH.
- Stu Vaeth, is the Chief Security Officer at Diversinet, Inc. He is
also the co-chair of the Technology Focus Group at OATH
Without their advice and valuable inputs, this document would not be
the same.
Authors’ Addresses
Phillip Hallam-Baker
VeriSign Inc.
pbaker@verisign.com
Jeff Bohren
BMC Software.
6526 Thoroughbred Loop, Odessa, FL
Jeff_Bohren@bmc.com
Hallam-Baker Expires August 2006 Page 19
