IETF KeyProv work group:
Provisioning of Symmetric Keys
Agenda


Introductions
Charter of IETF KEYPROV working group


PSKC








Working group items (deliverables)
Overview
Data model
Features
Schema
Status
Comparison with SKSML
SKPC
DSKPP





Overview
Protocol model (2-pass, 4 pass)
Description (features, message flow, user authentication, HTTP
binding)
Status
Comparison
2
Charter


Develop the necessary protocols and data
formats for provisioning of symmetric
cryptographic keys and associated attributes. In
particular the ability to provision symmetric keys
and associated attributes dynamically to already
issued devices such as cell phones and USB
drives.
Use cases:


Use of Shared Symmetric Key Tokens
Other use cases for future extensibility


P1619.3 and Kerberos
WG Charter Page
http://www.ietf.org/html.charters/keyprovcharter.html
3
Working Group Items

Dynamic Symmetric Key Provisioning Protocol (DSKPP)


XML based real-time online provisioning protocol
Key Container Specification

Portable Symmetric Key Container (PSKC)



XML based format
May also be used for offline bulk key import / migration
Symmetric Key Package Content Type (SKPC)

ASN.1 based format
4
PSKC Overview

Purpose


A symmetric key format for transport and provisioning of
symmetric keys (for example One Time Password (OTP)
shared secrets or symmetric cryptographic keys) to
different types of crypto modules such as a strong
authentication device.
Use cases


Online
 Real-time key provisioning: Internet or OTA
 User key upload
 Server to server provisioning
Offline
 End user key migration
 Bulk import or key migration
 User key upload
5
PSKC Data Model
PSKC Data Model
KeyContainer
1
1..*
DeviceID
1
User
1..*
Device
UserID
KeyID
Issuer
1..*
KeyAlgorithm
*
Service
1..*
Key
PINPolicy
Usage
KeyData
StartDate
ExpiryDate
FriendlyName
6
PSKC Features





XML based
Design goals

Keep it simple and lightweight for portable devices


Not limited to OTP keys
Storage encryption key, encryption key, PIN etc.

Registered a new URI for HOTP algorithm

Support different key protection methods
Support broad symmetric key types
Refer key algorithm by URI
Leverage standard XMLEnc elements for
protecting the key but not as encryption of whole
document



Password-generated encryption
Pre-shared symmetric key
PKI using a client’s public key
7
Features cont.
One KeyContainer may contain multiple
<Device>, which in turn may contain one
or more <Key>
 The same encryption key is used for all
Key elements in the same container
 A Key contains a key issuer, usage policy,
and data attributes. A few OTP related
data attribute types are defined.
 Extensible. Extensions are allowed at all
levels with consistent extension
mechanism

8
XML Schema: Top element





KeyContainer is
the top element
One or many
Devices
Common
encryption and
MAC algorithm for
all Devices
Optional common
key configuration
data
Optional
Signature for data
integrity
<xs:complexType
name="KeyContainerType">
<xs:sequence>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType"
minOccurs="0"/>
<xs:element name="MACAlgorithm"
type="pskc:KeyAlgorithmType"
minOccurs="0"/>
<xs:element name="Device"
type="pskc:DeviceType"
maxOccurs="unbounded"/>
<xs:element name="Signature"
type="ds:SignatureType"
minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version"
type="xs:unsignedInt"
use="required"/>
<xs:attribute name="id"
type="xs:ID" use="optional"/>
</xs:complexType>
9
XML Schema: DeviceType




A Device may
contain multiple
keys
A Device may be
associated to a
user
Device
information by
“DeviceInfoType”
PIN is transferred
as a special key


<xs:complexType name="DeviceType">
<xs:sequence>
<xs:element name="DeviceInfo"
type="pskc:DeviceInfoType"
minOccurs="0"/>
<xs:element name="Key"
type="pskc:KeyType"
maxOccurs="unbounded"/>
<xs:element name="User"
type="xs:string" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Registered PIN
algorithm URI
Referred by a key
10
XML Schema: KeyType



Each key has a
unique ID
(KeyId attribute)
Key data is
defined via
“DataType” –
XMLEnc
encrypted value
Additional key
attributes by
DataType
<xs:complexType name="KeyType">
<xs:sequence>
<xs:element name="Issuer" type="xs:string"
minOccurs="0"/>
<xs:element name="Usage" type="pskc:UsageType"/>
<xs:element name="KeyProfileId" type="xs:string"
minOccurs="0"/>
<xs:element name="MasterKeyId" type="xs:string"
minOccurs="0"/>
<xs:element name="FriendlyName" type="xs:string"
minOccurs="0"/>
<xs:element name="Data" type="pskc:KeyDataType"
minOccurs="0"/>
<xs:element name="UserId" type="xs:string"
minOccurs="0"/>
<xs:element name="Policy" type="pskc:PolicyType"
minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="KeyId" type="xs:string"
use="required"/>
<xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" use="optional"/>
</xs:complexType>
11
Sample Key Container
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1“ xmlns="urn:ietf:params:xml:ns:keyprov:pskc“
xmlns:ds=http://www.w3.org/2000/09/xmldsig# xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>Example-Key1</ds:KeyName>
</EncryptionKey>
<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1</MACAlgorithm>
<Device>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm="hotp" KeyId="987654321">
<Issuer>Example-Issuer</Issuer>
<Usage><ResponseFormat Length="8" Encoding="DECIMAL"/></Usage>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>JikjCho/uy8u+qRYCQ0TkZx+0o2Fjh7Ccr1CET+qrMhqbjGiE6AQ6B8jngucfvcC
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>50a26+2nfhGMPPDxmgEjFm70WrM=</ValueMAC>
</Secret>
<Counter><PlainValue>0</PlainValue></Counter>
</Data>
</Key>
</Device>
</KeyContainer>
12
Current Status: PSKC

Revision -01 (after name change and 6 revisions)
submitted in 1/2009

Work in progress for the final cleanup
 Mandatory encryption algorithm choice
 Separate MAC key from encryption key allowed
 Test vectors
13
Comparison with SKSML

PSKC







Allows protection using any kind of algorithm including
symmetirc keys and password base encryption
Allows transmission of binding information to devices and
users
allows transmission of PIN values to protect keys
Allows transmission of encrypted or unencrypted key meta
data
Allows offline provisioning
Uses separate IANA registry to define algorithm URIs and
separate information standard to define algorithm profiles
(defining what metadata is present for specific algorithms)
SKSML




allows protection using asymmetric cryptography
allows the naming of a KeyPolicy this is where SKSML
transmits AlgorithmsType and permissions.
allows the transmission of a status of a key
Allows more extensive key policy description (next slide)
14
Comparison of Key policy
Element
PSKC - KeyPolicy
SKSML - Permissions
Notes
StartDate
Y
PermittedDays
SKSML allows a list of permitted dates each have start and
end
ExpiryDate
Y
PermittedDays
PINPolicy
Y
N
KeyUsage
Y
PermittedUses
PSKC defines values whereas SKSML does not but allows
‘any’
Applications
N
Y
A list of applications that are permitted to use this key. The
interpretation of the application
element is user application-defined. It may consist of a name,
version number, a message digest, etc.
Days
N
Y
A list of days of the week that the symmetric key may be
used. Its meaning is application-specific
Duration
Can be modelled with
ExpiryDate as it
models UTC up
to milliseconds
Y
The number of seconds a symmetric key may be used for,
once the client application starts using the key.
Levels
N
Y
A list of classification levels within which an application is
permitted to use the key. Its interpretation is
application-specific.
Location
N
Y
contains sub elements of:
<locationName>
And list of Coordinates (Latitude Longitude)
NumberOfTransacti
ons
N
Y
Times
N
Y
List of Start and end times during a 24 hour period that the 15
key
can be used
Symmetric Key Package Content(SKPC)

SKPC is an ASN.1-based format specification

http://tools.ietf.org/html/draft-ietf-keyprov-symmetrickeyformat04

Co-authored by Sean Turner and Russ Housley
Used to transfer one or more plaintext symmetric keys
from one party to another
A symmetric key package can be encapsulated in one or
more CMS (RFC3852) protecting content types
Updated about alignment with PSKC




Added use cases
16
DSKPP Overview

DSKPP is a client-server protocol for
initialization (and configuration) of symmetric
keys to cryptographic modules



Intended for use within computer and communications
systems employing symmetric cryptographic modules
that are locally (over-the-wire) or remotely (over-theair) accessible.
Can be run with or without private-key capabilities in
the cryptographic modules, and with or without an
established public key infrastructure
Key encryption options for end-to-end key protection:



Pre-shared symmetric key (e.g., smart card
manufacturer’s key)
Password-generated symmetric key (e.g., mobile phone
provisioning)
PKI using on client public key
17
DSKPP Protocol Model
4-Pass: Mutually authenticated key agreement
2-Pass: Distribution of server pre-generated symmetric keys
DSKPP client
Smart
Device
DSKPP Provisioning server
Trigger (Optional)
Client Hello (2, 4-pass)
Server Hello (4-pass)
Client Nonce (4-pass)
Server Finished (2, 4-pass)
18
2-pass vs. 4-pass

Use 4-pass under the following conditions




Policy requires that both parties engaged in the protocol
jointly contribute entropy to the key
A cryptographic module does not have private-key
capabilities
The cryptographic module is hosted by a device that
doesn’t have a pre-shared authentication key and a key
pad for password input
Use 2-pass under the following conditions



Pre-existing keys must be provisioned via transport to
the cryptographic module
A cryptographic module has private-key capabilities
The cryptographic module is hosted by a device that has
a pre-shared authentication key (e.g. Smart Card or SIM
card) or a key pad for password input
19
DSKPP Protocol Features



XML based client-server message protocol
Two Variants

2-pass or 4-pass

Supported
Supported
Supported
Supported
Algorithm agility via protocol negotiation





variants – 2- or 4-pass
key types – HOTP, SecurID etc.
key container types – PSKC, SKPC, etc.
encryption and MAC algorithms
PSKC as the default key container
Key material encryption

Pass-phrase derived key, pre-shared key, and client
public key
20
Feature Cont.

Extensible

Allow client provide additional information
Allow service provider return vendor specific attributes

User authentication code

MAC in <KeyProvServerFinished>

Recommend to run DSKPP over a transport providing
privacy and integrity such as HTTP over TLS





Client authentication
Server authentication and key confirmation
Support HTTP binding
Transport security
21
Message Flow

Four-Pass
 Consist of two pairs of message exchanges
1.
Negotiate Cryptographic algorithms and exchange
nonces

2.
Establishes a symmetric key


Pass 3 = <KeyProvClientNonce>, Pass 4 =
<KeyProvServerFinished>
Two-Pass
 Consist of one exchange


Pass 1 = <KeyProvClientHello>, Pass 2 =
<KeyProvServerHello>
Pass 1 = <KeyProvClientHello>, Pass 2 =
<KeyProvServerFinished >
Optional <KeyProvTrigger> in both variants
 A DSKPP server may send it to initiate the
DSKPP protocol
22
Mutual Key Derivation in 4-pass



K_PROV = DSKPP-PRF (R_C, "Key generation" || K || R_S,
dsLen)
 DSKPP-PRF is a DSKPP defined pseudorandom function
 R_C is a secret random value chosen by the client
 R_S is a server nonce randomly chosen by the server
 K is the encryption key for the R_C
 dsLen is the desired length of K_PROV (combined length
of K_TOKEN and K_MAC)
K_PROV = K_MAC || K_TOKEN
 K_MAC is used to compute MAC values
 K_TOKEN is the target provisioned key
Both the client and the server can derive the K_PROV
without the need to transfer K_PROV over network
23
User Authentication



An authentication code (AC) can be used for user
authentication and authorization to get a key
AC isn’t sent in clear in Authentication Data
Authentication Data consists of a MAC value
derived from



AC, client nonce and optionally server nonce
MAC = DSKPP-PRF(K_AC,
AC->Identifier||URL_S||R_C||[R_S], 16)
K_AC = PBKDF2(AC->password, R_C || [K], iter_count,
16)
24
HTTP Binding

The MIME-type for all DSKPP messages MUST be




application/vnd.ietf.keyprov.dskpp+xml
DSKPP requests are mapped to HTTP requests
with the POST method.
DSKPP responses are mapped to HTTP responses.
No HTTP authentication is assumed
25
Message KeyProvTrigger

A DSKPP server
uses it to initiate
the DSKPP protocol


E.g. respond to a
user requesting a
key in a browsing
session
May contain




TriggerNonce – a
nonce to couple
with a
KeyProvClientHello
Device information
Key ID
Server URL
<xs:complexType
name="InitializationTriggerType">
<xs:sequence>
<xs:element minOccurs="0"
name="DeviceIdentifierData”
type="DeviceIdentifierDataType"/>
<xs:element minOccurs="0"
name="KeyID"
type="xs:base64Binary"/>
<xs:element minOccurs="0"
name="TokenPlatformInfo”
type="TokenPlatformInfoType"/>
<xs:element
name="TriggerNonce"
type="NonceType"/>
<xs:element minOccurs="0"
name="ServerUrl"
type="xs:anyURI"/>
<xs:any minOccurs="0"
namespace="##other”
processContents="strict"/>
</xs:sequence>
</xs:complexType>
26
Message KeyProvClientHello

Contains client
supported







Protocol versions
Protocl variations
(four-pass or twopass)
Key types
Key package format
Encryption and MAC
algorithms
Client
authentication
data
Optionally



DeviceID
KeyID
R_TRIGGER
<xs:complexType name="KeyProvClientHelloPDU">
<xs:complexContent mixed="false">
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element minOccurs="0" name="DeviceIdentifierData"
type="DeviceIdentifierDataType" />
<xs:element minOccurs="0" name="KeyID”
type="xs:base64Binary" />
<xs:element minOccurs="0" name="ClientNonce"
type="NonceType" />
<xs:element minOccurs="0" name="TriggerNonce”
type="NonceType" />
<xs:element name="SupportedKeyTypes”
type="AlgorithmsType"/>
<xs:element name="SupportedEncryptionAlgorithms"
type="AlgorithmsType" />
<xs:element name="SupportedMacAlgorithms”
type="AlgorithmsType"/>
<xs:element minOccurs="0"
name="SupportedProtocolVariants"
type="ProtocolVariantsType" />
<xs:element minOccurs="0"
name="SupportedKeyPackages"
type="KeyPackagesFormatType" />
<xs:element minOccurs="0" name="AuthenticationData"
type="AuthenticationDataType" />
<xs:element minOccurs="0" name="Extensions”
type="ExtensionsType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
27
Message KeyProvServerHello

Contains response
for







Protocol versions
Protocl variations
(four-pass or twopass)
Key types
Key package format
Encryption and MAC
algorithms
Server nonce R_S
Key information for
client nonce
encryption
<xs:complexType name="KeyProvServerHelloPDU">
<xs:complexContent mixed="false">
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType"
type="AlgorithmType" />
<xs:element name="EncryptionAlgorithm"
type="AlgorithmType" />
<xs:element name="MacAlgorithm"
type="AlgorithmType" />
<xs:element name="EncryptionKey"
type="ds:KeyInfoType" />
<xs:element name="KeyPackageFormat"
type="KeyPackageFormatType" />
<xs:element name="Payload"
type="PayloadType" />
<xs:element minOccurs="0" name="Extensions"
type="ExtensionsType" />
<xs:element minOccurs="0" name="Mac"
type="MacType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
28
Message KeyProvClientNonce

Contain a
protected random
nonce R_C to
DSKPP server


R_C contributes to
mutual key
generation
Authentication
data
<xs:complexType
name="KeyProvClientNoncePDU">
<xs:complexContent mixed="false">
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce"
type="xs:base64Binary" />
<xs:element minOccurs="0"
name="AuthenticationData"
type="AuthenticationDataType" />
<xs:element minOccurs="0"
name="Extensions"
type="ExtensionsType" />
</xs:sequence>
<xs:attribute name="SessionID"
type="IdentifierType"
use="required" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
29
Message KeyProvServerFinished


The last response
message
Contains




a key package that
holds configuration
data, and
protected keying
material (2-pass
case)
Key confirmation
MAC
Extensions for other
data
<xs:complexType
name="KeyProvServerFinishedPDU">
<xs:complexContent mixed="false">
<xs:extension
base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyPackage"
type="KeyPackageType" />
<xs:element minOccurs="0"
name="Extensions"
type="ExtensionsType" />
<xs:element name="Mac"
type="MacType" />
<xs:element minOccurs="0"
name="AuthenticationData"
type="AuthenticationDataType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
30
Current Status: DSKPP

Revision -07 submitted in 01/2009

Work in progress for the final cleanup
 Reduce number of supported variations
 Test vectors
31
Comparison with SKSML

DSKPP






Clearly separates protocol from payload
Allows multiple payload formats (PSKC, SKPC, other)
Allows establishment of keys without transmitting key
value
Allows protection of payload with symmetic, asymmetric
and password based crypto
protocol binding independent (not restricted to SOAP)
SKSML




Protects payload with asymmetric cryptography only
Supports SOAP binding
Supports more extensive key policies
Supports KeyCache policies
32