The Dynamic Symmetric Key Provisioning Protocol (DSKPP)

1. The Dynamic Symmetric Key Provisioning Protocol (DSKPP) KEYPROV WG IETF-70 Vancouver December 3, 2007 Andrea Doherty

2. Current Status • draft-ietf-keyprov-dskpp-01 was submitted Oct 29 to address review comments received at IETF-69 and on the mailing list • Restructured document to make it more readable for implementers • Modified message names to reflect KEYPROV request/response style (e.g., KeyProvClientHello, KeyProvClientNonce) • Added message flows to protocol details to aid security analyses • Upgraded to a validated schema and examples • Replaced K_AUTH with K_MAC in 4-pass variant • Reduced number of user authentication options • There are still a number of open issues

3. Open Issues(refer to Issue Tracker - http://www.tschofenig.com:8080/keyprov/)

4. Issue #34 – Client Authentication • User Authentication • Use Case 1 - A prov. policy requires the DSKPP server to verify the user's identity • Use Case 2 - A prov. policy requires the DSKPP server to prove that a user was pre-authorized for the request • DSKPP can address both use cases by specifying that the user id must be provided with the AuthenticationData, e.g., in Scenario (2), a pseudo (or temp) id could be provided • DSKPP must allow a flexible format (e.g., TLV) for the authentication code • Device Authentication • Use Case - provisioning policy requires the server to only issue keys to trusted devices, e.g., those from a given manufacturer, which may or may not be owned by a user yet • Implicit device authentication is all that is required within the DSKPP. This is already supported in KeyProvClientHello, wherein DeviceID (e.g., X.509 certificate) is an optional parameter. • Explicit device authentication, e.g., by signing data using the device certificate, is out-of-scope for DSKPP • User and Device Authentication can be supported in the same protocol run

5. Issue #34 – Client Authentication (cont’d) • User Authentication • Change to DSKPP AuthenticationData Element <xs:complexType name="AuthenticationDataType"> <xs:sequence> <xs:element name="ClientID" type="dskpp:IdentifierType“ minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="AuthenticationCodeMac“ type="dskpp:AuthenticationCodeMacType"/> <!-- <xs:element name="DigitalSignature“ type="ds:SignatureType"/> --> </xs:choice> </xs:sequence> </xs:complexType> • AuthenticationCodeMac computed using • MAC = DSKPP-PRF-AES(K_AUTHCODE, AUTHCODE->Identifier || URL_S || [R_S], 16) • Device Authentication • <KeyProvClientHello>: [ID_Device], [ID_K], [R_S], Alg_List

6. Issue #36 – Apps Review of HTTP Binding • Expectation of Apps Area • HTTP bindings should address the concerns raised in BCP 56 (RFC 3205) • Findings: No significant deviations from draft-ietf-keyprov-dskpp-01 and BCP 56. The following recommendations were made: • Unless the primary client for DSKPP is a web browser, register a separate port to avoid damage and interoperability problems that can result from the inevitable presence of intrusive firewalls on port 80. • Define a new URI scheme (DSKPP relies on HTTP/HTTPS scheme) • It was not evident to the reviewers that WSDL would be useful • Thomas Roessler of W3C Security Activity said that he failed to see the benefit of allocating a separate port and/or URI scheme: • Protocol binding will be layered cleanly on HTTP, and won't confuse URI-based addressing • Binding can be implemented on top of a conventional Web server, which is consist with sticking to port 80 and http (or port 443 and https).

7. Issue #37 – Rationale for One-Pass Variant • SMS-based transport • SMS push with KeyProvServerFinished data • Does not necessarily have to be triggered by a KeyProvClientHello from a desktop computer. It could be sent to the phone as a result of a user registering with the provisioning service through the Web channel. • Has different data format considerations than for HTTP • SMS-based transport use case is not supported by DSKPP, as agreed during IETF-69. • It is not necessary with HTTP • One-pass is redundant with two-pass when used with HTTP • As a client-server protocol, the DSKPP client would always send a request, which could be done using KeyProvClientHello • Other?

8. Issue #32 – Conformance Matrix (Proposal)

9. Issue #33 – Why allow a non-secure transport layer? • Use Case: Non-Protected Transport Layer • Legacy devices (e.g., some mobile phones) are not able to establish a secure transport channel (e.g., SSL/TLS) for data confidentiality • DSKPP should be capable of ensuring data confidentiality over a non-secure transport layer. • Use Case: Non-Authenticated Transport Layer • Legacy devices (e.g., some mobile phones) are not able to establish a secure transport channel (e.g., SSL/TLS) for server authentication • DSKPP should be capable of server authentication and client authentication over a non-secure transport layer. • Adds some complexity to DSKPP, while providing implementers with more options • For example, an optional MAC value is specified as parameter to <KeyProvServerHello> and <KeyProvServerFinished> for server authentication. • The added complexity may be small relative to the benefits for implementers who will gain support for a wider range of devices

10. Issue #35 – Schema Refinement • Schema Versioning • Proposal is for three schemes: • Schema version attribute • Version number in root element • Target namespace as a pattern (e.g., urn:ietf:params:xml:ns:keyprov:<spec>:<version>) • Alternative proposal is to not have any version attributes • Avoids situation, e.g., one has “old” schema and receives “new” data, causing validation to conclude that the input document doesn’t conform to the schema • There are no (or few) schemas in use that have actually been updated and keep the old name-space (SAML1.x did this, but discontinued the practice in SAML2.0). • import namespace • Since the majority of XML processors in use today support the concept of pre-loaded schemas, no need to refer to non-normative local file-name nor live URL, as in • <import namespace="http://www.w3.org/2000/09/xmldsig#"/>

11. Issue #35 – Schema Refinement (cont’d) • elementFormDefault • Currently, PSKC schema uses “qualified” while DSKPP uses “unqualified” • Use of “qualified” exposes the namespace, reducing readability • elementFormDefault=qualified, however, makes processing of instance documents more efficient for applications. This is especially true when the namespace is required to determine how an element is to be processed. • Proposal is to change from “unqualified” to “qualified”. • schemaLocation • PSKC and DS don’t rely on schemaLocation, whereas DSKPP does • XML processors cannot find files specified in instance documents without being overridden • Proposal is to remove schemaLocation from the instance document • Should we use URL or URN for new algorithm URI? • URL is preferred. URL wasn’t chosen for namespace because many tools may automatically convert it to a resource locator to actually download schema file. • Algorithm URI doesn’t have this issue. Thus, URL syntax is better for it is easy to ensure to be unique, and is familiar.

12. Next Steps • Resolve outstanding issues using the mailing list • Revise and resubmit draft for WGLC In addition: • Decide whether to add SOAP binding document (e.g., draft-doherty-keyprov-ct-kip-ws-00) as a working group item.