Transcript The Dynamic Symmetric Key Provisioning Protocol (DSKPP) KEYPROV WG IETF-69 Chicago

The Dynamic Symmetric Key
Provisioning Protocol (DSKPP)
KEYPROV WG
IETF-69 Chicago
July 2007
Andrea Doherty
Current Status
• 2nd draft of DSKPP protocol specification (draftdoherty-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
2
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-keycontainer-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
3
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-thewire) 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
4
DSKPP Object Model
User
User ID
…
Device
*
owns
*
Device ID
…
1
contains
Cryptographic Module
*
Cryptographic Module ID
Encryption Algorithms
1
MAC Algorithms
…
contains
Key Container
Key ID
Key Type
…
*
5
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
6
DSKPP 1, 2, 4-pass Comparison
DSKPP server
DSKPP client
Smart
Device
Client Hello (2, 4-pass)
Server Hello (4-pass)
Client Nonce (4-pass)
Server Finished (1, 2, 4-pass)
7
DSKPP 1- and 2-pass Key
Initialization Profiles
Profile
Key transport and derivation
Usage
Key
Transport
Using a public key, K_CLIENT,
whose private key part resides
in the cryptographic module
Ideal for PKIcapable devices
Key Wrap
Using a symmetric keywrapping key, K_SHARED,
known in advance by both the
DSKPP client and server
Ideal for pre-keyed
devices, e.g., SIM
cards
Passphrase- Using a passphrase-derived
based Key
key-wrapping key,
Wrap
K_DERIVED, known in
advance by both the DSKPP
client and server
Ideal for constrained
devices with keypads, e.g., mobile
phones
8
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
9
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-01
• SOAP Binding
– WSDL defined in draft-doherty-keyprov-ct-kip-ws-00
10
Open Items in Issue Tracker
(http://www.tschofenig.com:8080/keyprov/)
#
Description
1
Should PDU names reflect KEYPROV in WS request/response style?
4
Should Key Identifiers be represented as strings or base64Binary?
6
Map dskpp:AlgorithmType and pskc:EncryptionAlgorithmType?
7
Add explicit support for SMS-based key delivery method?
8
How to refer to OTP (e.g., HOTP and SecurID) algorithms?
9
What is relationship between dskpp:KeyInitializationMethod and
pskc:EncryptionMethod?
11 Is special KEYPROV HTTP header definition required?
12 DSKPP schema sometimes relies on “any” type for flexibility. Should it
instead strongly type request and response parameters?
11
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?
12
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 issuer’s 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.,
<KeyID>http://example.com|0123456789</KeyID>)
• 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-todeploy hierarchical names of X.500
• e.g., <KeyID issuer="http://example.com/policy#3">0123456789</KeyID>
13
Issue #4 (2)
•
IEEE P1619.3, which is actively defining requirements for a key
identifier and namespace specification, is considering various
proposals, e.g.,:
1. 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.
2. Define the namespace as a URI set to kms://realm/object/path
3. Encode a key id and attributes in a PKCS#7 formatted message
4. 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
5. 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”
14
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
15
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
16
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 user’s 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 1pass, 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.
17
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.dskpp+xml
– Defines restrictions on HTTP headers
• Is there an IETF Best Practices guide for defining HTTP
bindings?
18
Issue #12
• For extensibility, the schema defined in draft-dohertykeyprov-dskpp-01.txt relies on the use of the any type
– However, the specification uses any with
processContents=“strict”, 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
processContents=“strict”
19
Next steps
• Decide on whether draft-doherty-keyprov-dskpp01.txt 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-dohertykeyprov-dskpp-01.txt
– Or, other?
• Resolve open issues using the mailing list
• Revise and resubmit draft
20