IETF KeyProv work group:Provisioning of Symmetric Keys

2

Agenda Introductions Charter of IETF KEYPROV working group

Working group items (deliverables) PSKC

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

3

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/keyprov-charter.html

4

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

5

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

6

PSKC Data ModelKeyContainer

DeviceUser

Service Key

DeviceID

UserID

KeyID

Issuer

Usage

KeyAlgorithm

PINPolicy

StartDate

ExpiryDate

KeyData

FriendlyName

1

1..*

1..*

11..*

*1..*

PSKC Data Model

7

PSKC Features XML based Design goals

Keep it simple and lightweight for portable devices Support broad symmetric key types

Not limited to OTP keys Storage encryption key, encryption key, PIN etc.

Refer key algorithm by URI Registered a new URI for HOTP algorithm

Leverage standard XMLEnc elements for protecting the key but not as encryption of whole document Support different key protection methods

Password-generated encryption Pre-shared symmetric key PKI using a client’s public key

8

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

9

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>

10

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 Registered PIN

algorithm URI Referred by a 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>

11

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>

12

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>

13

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

14

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)

15

Comparison of Key policyElement 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)

NumberOfTransactions

N Y

Times N Y List of Start and end times during a 24 hour period that the key can be used

16

Symmetric Key Package Content(SKPC)

SKPC is an ASN.1-based format specification http://tools.ietf.org/html/draft-ietf-keyprov-symmetrickeyformat-0

4 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

17

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-the-air) 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

18

DSKPP Protocol Model

DSKPP Provisioning serverDSKPP client

Client Hello (2, 4-pass)

Server Finished (2, 4-pass)

Smart Device

Client Nonce (4-pass)

Server Hello (4-pass)

4-Pass: Mutually authenticated key agreement2-Pass: Distribution of server pre-generated symmetric keys

Trigger (Optional)

19

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

20

DSKPP Protocol Features XML based client-server message protocol Two Variants

2-pass or 4-pass Algorithm agility via protocol negotiation

Supported variants – 2- or 4-pass Supported key types – HOTP, SecurID etc. Supported key container types – PSKC, SKPC, etc. Supported encryption and MAC algorithms

PSKC as the default key container Key material encryption

Pass-phrase derived key, pre-shared key, and client public key

21

Feature Cont. Extensible

Allow client provide additional information Allow service provider return vendor specific attributes

Client authentication User authentication code

Server authentication and key confirmation MAC in <KeyProvServerFinished>

Support HTTP binding Transport security

Recommend to run DSKPP over a transport providing privacy and integrity such as HTTP over TLS

22

Message Flow Four-Pass

Consist of two pairs of message exchanges1. Negotiate Cryptographic algorithms and exchange

nonces Pass 1 = <KeyProvClientHello>, Pass 2 =

<KeyProvServerHello>2. Establishes a symmetric key

Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished>

Two-Pass Consist of one exchange

Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerFinished >

Optional <KeyProvTrigger> in both variants A DSKPP server may send it to initiate the

DSKPP protocol

23

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

24

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)

25

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

26

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>

27

Message KeyProvClientHello Contains client

supported Protocol versions Protocl variations

(four-pass or two-pass)

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>

28

Message KeyProvServerHello Contains response

for Protocol versions Protocl variations

(four-pass or two-pass)

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>

29

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>

30

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>

31

Current Status: DSKPP Revision -07 submitted in 01/2009 Work in progress for the final cleanup

Reduce number of supported variations Test vectors

32

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