The Dynamic Symmetric Key Provisioning Protocol DSKPP

1
The Dynamic Symmetric Key Provisioning Protocol
(DSKPP)

• KEYPROV WG
• IETF-69 Chicago
• July 2007
• Andrea Doherty

2
Current Status

• 2nd draft of DSKPP protocol specification
  (draft-doherty-keyprov-dskpp-01) implements the
  convergence plan that was proposed at IETF-68
  KEYPROV WG meeting in Prague
• Builds on information contained in RFC4758,
  adding specific enhancements in response to
  implementation experience and liaison requests.
  
• Also builds on
• draft-pei-keyprov-dskpp-00.txt
• draft-nyström-keyprov-ct-kip-two-pass-00.txt

3
Highlights of Convergence

• Like RFC4758, the merged protocol specification
  now
• Supports mutually generated secrets by both
  client and server (4-pass variant)
• Has ability to start with a blank device, i.e.,
  one with no private key nor transport key
• Supports full crypto suite negotiation (incl.
  MAC)
• Ensures negotiation can occur in first pass,
  minimizing unnecessary binding of resources in
  case of client-server non-interoperability
• Is capable of encapsulating XML or ASN.1
• In addition, the merged protocol specification
• Supports symmetric key transport from a server to
  a client (2- and 1-pass variants)
• Supports multiple key container formats
• PSKC is defined as the default (see
  draft-hoyer-keyprov-portable-symmetric-key-contain
  er-02.txt)
• Allows client authentication prior to
  provisioning within the core protocol
• Supports user authentication using activation
  code without requiring HTTPS
• Supports explicit device authentication using a
  device certificate

4
DSKPP Primer

• 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

5
DSKPP Object Model
Device
User
1
owns


Device ID
User ID
contains
Cryptographic Module

Cryptographic Module ID Encryption Algorithms MAC
Algorithms
1
contains
Key Container
Key ID Key Type

6
Protocol variants

• DSKPP variants support multiple usage scenarios
• Four-pass variant enables mutual key generation
  by the provisioning server and cryptographic
  module in near real-time provisioned keys are
  not transferred over-the-wire or over-the-air
• Two- and one-pass variants enable generation and
  transport of symmetric keys to a cryptographic
  module in environments where near real-time
  communication is not possible
• Two- and one-pass variants also enable transport
  of pre-generated (i.e., legacy) keys to a
  cryptographic module

7
DSKPP 1, 2, 4-pass Comparison
DSKPP server
DSKPP client
Smart Device
8
DSKPP 1- and 2-pass Key Initialization Profiles
9
Cryptographic properties

• Key confirmation
• In both variants via MAC on exchanged data (and
  counter in 1-pass)
• Replay protection
• In 4- and 2-pass through inclusion of
  client-provided data in MAC
• Suggested method for 1-pass based on counter
• Server authentication
• In all variants through MAC in ServerFinished
  message when replacing existing key
• Protection against MITM
• In both variants through use of shared keys,
  client certificates, or server public key usage
• User authentication
• Enabled in 4- and 2-pass variants using
  activation code
• Alternative methods rely on draft-doherty-keyprov-
  ct-kip-ws-00
• Device authentication
• In 4- and 2-pass variants if based on shared
  secret key or if device sends a client
  certificate
• Alternative methods rely on draft-doherty-keyprov-
  ct-kip-ws-00

10
Bindings

• Security Binding
• Transport level encryption (e.g., TLS) is not
  required for key transport
• TLS/SSL is required if other parameters/attributes
  must be protected in transit
• HTTP Binding
• Special content header recommended
• Examples provided in draft-doherty-keyprov-dskpp-0
  1
• SOAP Binding
• WSDL defined in draft-doherty-keyprov-ct-kip-ws-00
  

11
Open Items in Issue Tracker(http//www.tschofenig
.com8080/keyprov/)
12
Issue 1

• Original Comment
• The current PDU naming style (e.g. ClientHello,
  ServerFinished) is specific to certain SSL and
  key exchange protocol flavor. However, when
  KEYPROV is implemented as a WS using REST, SOAP,
  or even native HTTP, it is better to reflect the
  KEYPROV namespace in PDU names.
• For example, in a WS exchange, KeyProvRequest is
  more intuitive than ClientHello.
• Is it necessary to change the naming scheme?

13
Issue 4 (1)

• The Key Identifier is opaque in the protocol
• KeyID is currently defined in DSKPP as
  base64Binary
• The original reason for base64Binary was to allow
  for creating unique identifiers by, e.g., hashing
  together the issuers DNS name together with an
  issuer-unique serial number
• base64Binary encoding allows for full usage of
  all bits in a byte.
• PSKC defines KeyID as a user friendly string
• Provides a readable value
• String encoding does not allow for full usage of
  all bits in a byte a different scheme for
  guaranteeing Key ID uniqueness has to be defined
  (e.g., ltKeyIDgthttp//example.com0123456789lt/KeyID
  gt)
• In addition to uniqueness and user friendliness,
  other needs play a role when using a key
  identifier, e.g., cross-domain sharing of keys
• Some applications may associate metadata with the
  key identifier in an explicitly specified
  structure
• One possibility is a two-level URI ID scheme
• Compromise between binary blobs that cannot be
  filtered and the hard-to-deploy hierarchical
  names of X.500
• e.g., ltKeyID issuer"http//example.com/policy3"gt
  0123456789lt/KeyIDgt

14
Issue 4 (2)

• IEEE P1619.3, which is actively defining
  requirements for a key identifier and namespace
  specification, is considering various proposals,
  e.g.,
• Define the namespace (Key ID Space) to be a
  string that would typically identify a set of KMS
  servers. This string would be encoded into the
  Key ID. The structure of the namespace (e.g. URI,
  URL, GUID, FQDN, etc) is not specified.
• Define the namespace as a URI set to
  kms//realm/object/path
• Encode a key id and attributes in a PKCS7
  formatted message
• Use something from T10, wherein the namespace
  part is the Device Name Address Authority
  Identifier
• T10 is a Technical Committee of the INCITS that
  is focused on SCSI Storage Interfaces
• Keep namespace and Key ID separate, and never
  encode attributes of the key into either
  namespace would only be required when keys are
  shared between domains

15
Issue 4 (3)

• Recommendation Ensure that DSKPP, in
  combination with PSKC, makes available all of the
  key metadata (e.g., KeyID and IssuerID) required
  of an application
• Leave it up to the application to extract the key
  identifier, attributes, and namespace from the
  DSKPP key container, and to format the data in
  accordance with the relevant key identifier
  specification
• It is always possible to generate a key
  identifier specification and leave it to use
  cases or a later profile to address
• If the key metadata is maintained in the key
  container, then the original base64Binary
  encoding of the key identifier can be used

16
Issues 6, 8, and 9

• DSKPP relies on PSKC as default container format
  therefore, consistency between the two
  specifications is desired
• Currently, there is some overlap in algorithm
  type definitions in DSKPP and PSKC, e.g., OTP
  algorithms and EncryptionAlgorithm
• There is also potential overlap in how the key
  transport method is defined
• Two solutions have been proposed
• Publish a separate document that maps the
  relationships between data types common to DSKPP
  and PSKC
• Align algorithm and method types across DSKPP and
  PSKC

17
Issue 7

• Use case
• A user owns a mobile phone that is unable to
  communicate with a provisioning server
• The user initiates a key provisioning request
  using a cryptographic module resident on the
  users PC
• The server authenticates the user
• The server delivers the symmetric key to the
  mobile phone via SMS.
• Should explicit support for KeyDeliveryMethod
  (i.e., HTTP, HTTPS, SMS, etc.) be added to DSKPP
  to address this use case?
• What would the security characteristics of this
  be? It can only be 1-pass, as there is hardly
  any connection to other variants. If 1-pass,
  then what user does on browser/PC beforehand is
  outside the scope of DSKPP.
• Mobile phones that cannot connect to the Internet
  are becoming rare.
• Recommendation KEYPROV should not address this
  use case.

18
Issue 11

• In actuality, an HTTP header definition is not
  specified in draft-doherty-keyprov-dskpp-01.txt
• The specified HTTP binding
• Requires identification of all DSKPP messages via
  a MIME type set to application/vnd.ietf.keyprov.ds
  kppxml
• Defines restrictions on HTTP headers
• Is there an IETF Best Practices guide for
  defining HTTP bindings?

19
Issue 12

• For extensibility, the schema defined in
  draft-doherty-keyprov-dskpp-01.txt relies on the
  use of the any type
• However, the specification uses any with
  processContentsstrict, which still allows for
  extensibility
• Is it better to use strongly typed request and
  response parameters? For example, should complex
  types be explicitly declared for schema
  validation and code automation tools?
• If use of any type is not adopted, then new types
  that are extensions of old types will be needed
  whenever a new feature is added.
• There is plenty of precedence for using the any
  type, e.g., XMLenc and XMLDsig.
• Recommendation Continue to rely on the any type
  with processContentsstrict

20
Next steps

• Decide on whether draft-doherty-keyprov-dskpp-01.t
  xt document should become a KEYPROV working group
  item
• Decide on how SOAP binding should be addressed
  within KEYPROV
• Should draft-doherty-keyprov-ct-kip-ws-00.txt
  document become a KEYPROV working group item, or
• Should SOAP binding should be merged into
  draft-doherty-keyprov-dskpp-01.txt
• Or, other?
• Resolve open issues using the mailing list
• Revise and resubmit draft