Transcript CT-KIP and DSKPP Convergence KEYPROV WG IETF-68 Prague

CT-KIP and DSKPP
Convergence
KEYPROV WG
IETF-68 Prague
March 2007
Andrea Doherty
Mingliang Pei
Salah Machani
1
Rationale for Convergence
• One protocol is better than two
– Leverage an existing protocol
– Extend existing protocol to fully satisfy all
mandatory requirements
• Early agreement as to what protocol
KEYPROV will go forward with will make IEEE
more likely to pick up the results, including the
Portable Symmetric Key Container (PSKC).
2
Basis for Convergence
• Goal is to have one KEYPROV protocol
specification that combines:
– All CT-KIP variants (4-pass, 2-pass, 1-pass,
and WS)
– DSKPP
• KEYPROV specification can:
– Adopt majority of CT-KIP content
– Add some DSKPP features
3
Gap Analysis (1)
• Capabilities in CT-KIP not met in DSKPP
– Supports mutually generated secrets by both client
and server (4-pass variant)
– Ability to initialize token with no knowledge of device;
can start with blank device (no key or certificate)
• This might be of interest to IEEE P1619.3.
– Full crypto suite negotiation (i.e., MAC)
– Crypto algorithm negotiation occurs in first pass,
minimizing unnecessary binding of resources in case
of client-server non-interoperability
4
Gap Analysis (2)
• Capabilities in DSKPP not met in CT-KIP
– Support for multiple credential container formats
using PSKC payload format
– User authentication prior to provisioning
• CT-KIP partially handles user authentication through:
– A trigger message that ties an earlier, out-of-band, user
authentication to the session
– In the Web Service layer (draft-doherty-keyprov-ct-kip-ws-00)
– In the Transport Layer via HTTPS
• DSKPP (4-pass variant) supports activation code for authN
without requiring HTTPS
– Explicit device authentication using a device
certificate
• In CT-KIP, device authentication is implied. Explicit device
authentication can be achieved through protocol extension.
5
Merge Options (1)
Payload format options:
1. Explicitly declare the payload format in the
request and response parameters
2. Extend algorithms and capabilities
negotiation to include payload format
3. Rely on existing protocol extension, e.g.,:
1. Use payload element in <ServerFinished>
KeyInitializationDataType extension
2. Add payload element to <ServerFinished>
OTPKeyConfigurationDataType extension
6
Merge Options (2)
User authentication options:
1. Explicitly declare AuthenticationDataType in
the <ClientHello> and <ClientNonce>
– Ensure authentication data can accommodate
ActivationCodeDataType like the one in DSKPP
2. Rely on existing protocol extension, e.g.,:
– Use <MAC> element in <ServerFinished>
AuthenticationDataType extension
– Apply extension to <ClientHello> and
<ClientNonce>
7
Merge Options (3)
Explicit device authentication options:
1. Explicitly declare AuthenticationDataType in
the <ClientHello> and <ClientNonce>
– Ensure authentication data can accommodate a
value of “CERTIFICATE” as in DSKPP
2. Rely on existing protocol extension, e.g.,:
– Use <MAC> element in <ServerFinished>
AuthenticationDataType extension
– Apply extension to <ClientNonce> message
8
Bindings
• SOAP Binding
– Identify and close issues with draft-doherty-keyprov-ct-kip-ws-00
– Incorporate feedback into KEYPROV specification
– Should this binding be mandatory for compliance or left to the
implementation?
• HTTP Binding
– Is a header definition required?
• One is defined in CT-KIP, but not in DSKPP
– If so, should this binding be mandatory for compliance or left up
to the implementation?
• Security Binding
– CT-KIP and DSKPP equally satisfy requirements regarding
transport level encryption (e.g., TLS), i.e.,
• TLS is not required to keep the key secret
9
Open Issues
• Guiding principle for strongly typing request and
response parameters?
– For example, should complex types be explicitly declared
for schema validation and code automation tools?
• Keep the core protocol simple and flexible, allowing
organizations to define their own extensions:
– Agree on set (if any) of mandatory-to-support extensions
– Define parameters (if any) that belong in the “core” protocol
– Decide how to define different key types and configuration
• e.g., Storage Encryption Key (IEEE P1619.3), Kerberos key
• Guiding principle for HTTP and WS bindings
– Should HTTP and/or SOAP header definitions be
mandatory for the specification?
• Consider whether naming style of message set
10
Next Steps
• Resolve open issues
• Submit a single KEYPROV
specification
11