CT-KIP and DSKPP Convergence

1
CT-KIP and DSKPP Convergence

• KEYPROV WG
• IETF-68 Prague
• March 2007
• Andrea Doherty
• Mingliang Pei
• Salah Machani

2
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).

3
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

4
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

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

6
Merge Options (1)

• Payload format options
• Explicitly declare the payload format in the
  request and response parameters
• Extend algorithms and capabilities negotiation to
  include payload format
• Rely on existing protocol extension, e.g.,
• Use payload element in ltServerFinishedgt
  KeyInitializationDataType extension
• Add payload element to ltServerFinishedgt
  OTPKeyConfigurationDataType extension

7
Merge Options (2)

• User authentication options
• Explicitly declare AuthenticationDataType in the
  ltClientHellogt and ltClientNoncegt
• Ensure authentication data can accommodate
  ActivationCodeDataType like the one in DSKPP
• Rely on existing protocol extension, e.g.,
• Use ltMACgt element in ltServerFinishedgt
  AuthenticationDataType extension
• Apply extension to ltClientHellogt and ltClientNoncegt

8
Merge Options (3)

• Explicit device authentication options
• Explicitly declare AuthenticationDataType in the
  ltClientHellogt and ltClientNoncegt
• Ensure authentication data can accommodate a
  value of CERTIFICATE as in DSKPP
• Rely on existing protocol extension, e.g.,
• Use ltMACgt element in ltServerFinishedgt
  AuthenticationDataType extension
• Apply extension to ltClientNoncegt message

9
Bindings

• SOAP Binding
• Identify and close issues with draft-doherty-keypr
  ov-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

10
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

11
Next Steps

• Resolve open issues
• Submit a single KEYPROV specification