ietf keyprov work group: provisioning of symmetric keys
Post on 04-Jan-2016
219 Views
Preview:
TRANSCRIPT
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
top related