1. IETF KeyProv work group: Provisioning of Symmetric Keys

2. 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. 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. 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. 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. 6 PSKC Data Model KeyContainer Device User Service Key DeviceID UserID KeyID Issuer Usage KeyAlgorithm PINPolicy StartDate ExpiryDate KeyData FriendlyName 1 1..* 1 * PSKC Data Model

7. 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. 8 Features cont.  One KeyContainer may contain multiple, which in turn may contain one or more  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. 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

10. 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

11. 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

12. 12 Sample Key Container <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#">http://www.w3.org/2000/09/xmldsig# Example-Key1 http://www.w3.org/2000/09/xmldsig#hmac-sha1 TokenVendorAcme 987654321 Example-Issuer JikjCho/uy8u+qRYCQ0TkZx+0o2Fjh7Ccr1CET+qrMhqbjGiE6AQ6B8jngucfvcC 50a26+2nfhGMPPDxmgEjFm70WrM= 0

13. 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. 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. 15 Comparison of Key policy ElementPSKC - KeyPolicySKSML - PermissionsNotes StartDate YPermittedDaysSKSML allows a list of permitted dates each have start and end ExpiryDate YPermittedDays PINPolicy YN KeyUsage YPermittedUsesPSKC defines values whereas SKSML does not but allows ‘any’ Applications NY 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 NYA 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 YThe number of seconds a symmetric key may be used for, once the client application starts using the key. Levels NYA list of classification levels within which an application is permitted to use the key. Its interpretation is application-specific. Location NYcontains sub elements of: And list of Coordinates (Latitude Longitude) NumberOfTransacti ons NY Times NYList of Start and end times during a 24 hour period that the key can be used

16. 16 Symmetric Key Package Content(SKPC)  SKPC is an ASN.1-based format specification http://tools.ietf.org/html/draft-ietf-keyprov-symmetrickeyformat- 04 http://tools.ietf.org/html/draft-ietf-keyprov-symmetrickeyformat- 04 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. 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. 18 DSKPP Protocol Model DSKPP Provisioning server DSKPP 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 agreement 2-Pass: Distribution of server pre-generated symmetric keys Trigger (Optional)

19. 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. 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. 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  Support HTTP binding  Transport security Recommend to run DSKPP over a transport providing privacy and integrity such as HTTP over TLS

22. 22 Message Flow  Four-Pass Consist of two pairs of message exchanges 1. Negotiate Cryptographic algorithms and exchange nonces  Pass 1 =, Pass 2 = 2. Establishes a symmetric key  Pass 3 =, Pass 4 =  Two-Pass Consist of one exchange  Pass 1 =, Pass 2 =  Optional in both variants A DSKPP server may send it to initiate the DSKPP protocol

23. 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. 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. 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. 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

27. 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:element minOccurs="0" name="DeviceIdentifierData" type="DeviceIdentifierDataType" /> <xs:element name="SupportedEncryptionAlgorithms" 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" />

28. 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:element name="EncryptionAlgorithm" type="AlgorithmType" /> <xs:element name="KeyPackageFormat" type="KeyPackageFormatType" /> <xs:element minOccurs="0" name="Extensions" type="ExtensionsType" />

29. 29 Message KeyProvClientNonce  Contain a protected random nonce R_C to DSKPP server R_C contributes to mutual key generation  Authentication data <xs:element minOccurs="0" name="AuthenticationData" type="AuthenticationDataType" /> <xs:element minOccurs="0" name="Extensions" type="ExtensionsType" /> <xs:attribute name="SessionID" type="IdentifierType" use="required" />

30. 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:element name="KeyPackage" type="KeyPackageType" /> <xs:element minOccurs="0" name="Extensions" type="ExtensionsType" /> <xs:element minOccurs="0" name="AuthenticationData" type="AuthenticationDataType" />

31. 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. 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