Dynamic Symmetric Key Provisioning Protocol (DSKPP)

1. Dynamic Symmetric Key Provisioning Protocol (DSKPP) Andrea Doherty Mingliang Pei Salah Machani Magnus Nyström IETF 73 Minneapolis, USA 19 November 2008

2. Document Status • Version -06 submitted November 3rd • Addressed Philip Hallam-Baker’s comments • Addressed most (but not yet all) of Sean Turner’s comments • Addressed Magnus’ concern about AuthData calculation • Addressed Ming’s request for AuthCode extensibility • Version -06 since November 3rd • Received proposal for support of key confirmation at the crypto module from Ming • Received major comments from Pasi Eronen

3. Resolved Issues (i) • Authentication Code Format • As of version -05 authentication code format is TLV-based • Client ID and password length are left up to the implementers • As of version -06 <AuthenticationDataType> is extensible: <xs:choice> <xs:element name="AuthenticationCodeMac“ type="dskpp:AuthenticationMacType" <xs:any namespace="##other" processContents="strict" /> </xs:choice>

4. Resolved Issues (ii) • Authentication Data calculation • Magnus raised concern about vulnerability to MITM caused by K being optional in the four-pass • K_AC = PBKDF2(AC->password, R_C || [K], iter_count, 16) • K is OPTIONAL only in four-pass where no K_SHARED is used.  • Resolution: • K_AC = PBKDF2(AC->password, R_C || K, iter-count, 16) • In four-pass one of the following values for K MUST be used: • The public key of the DSKPP server (K_SERVER); or (in the pre-shared key variant) • The pre-shared key between the client and the server (K_SHARED)

5. Pasi pointed out that the document doesn’t explain how protocol entities interact with the outside world Since DSKPP is an application-layer protocol it interacts with a wider set of entities outside the protocol in more complex ways than, e.g., lower layer protocols like the transport layer (which just “send opaque data bytes”) Addressing this is critical for implementations and interoperability Consider a protocol model in RFC 4101 sense: Explain how "protocol black box" interacts with the rest ofthe world Provide a high-level view of the protocol internals (but omit the details that could be changed without the world external to DSKPP noticing) Open Issues - #1

6. Open Issues - #2 • Pasi pointed out that the document describes a framework more than a protocol • Too much flexibility makes the document hard (if not impossible) to understand, much less implement • There are too many options to make implementations interoperable

7. Open Issues - #2 (cont’d, ii) • Example given was the six ways a DSKPP client can be authenticated: • Authentication Code (one-time secret value, delivered to the user out-of-band before DSKPP starts) • Passphrase-Based Key Wrap (another one-time secret value, delivered to user out-of-band before DSKPP starts) • Web-based authentication (authenticate user using any web mechanism, then use TriggerNonce as one-time secret value) • Client certificate/key pair, used with TLS client authentication (CTLS) • Client certificate/key pair, used inside DSKPP in the Key Transport Profile. • Pre-existing symmetric key • This many options means that there are at least 25 different combinations one can use to implement client-side authentication!

8. Open Issues - #2 (cont-d, iii) • Pasi asked for the first document to support only a couple of the most important combinations • Defer the rest to separate document(s) later • Consider reducing/combining options, for example: • Eliminate “Client certificate/key pair, used with TLS client authentication”; this would reduce number of combinations from 25 to 8. There is consensus from the authors that this would be acceptable for two-pass since, e.g., most implementations find CTLS too costly/complex to deploy. Should consider it also for four-pass. • Combine authentication code and PBKW since both use a one-time secret value • Could remove trigger nonce from <KeyProvTrigger>, and rely on manually entered Authentication Code instead, or <KeyProvTrigger>message could deliver an Authentication Code (instead of TriggerNonce) and from there on the protocol would continue the same as with manually entered authentication code

9. Open Issues - #3 • Key Confirmation to the Crypto Module in two-pass protocol • SIM and TPM chip vendors have expressed interest in implementing DSKPP, but since these can have pre-embedded trust points, expectation is for key confirmation at crypto module, i.e., not to limit key confirmation at DSKPP client • Creates another option that must be considered for inclusion in the protocol as we work to narrow the scope • If assume trust anchor resides in the crypto module, this changes the original protocol assumption and could create significant change to the protocol • PKIX members on TAM work should be consulted • Must consider whether DSKPP is appropriate for this environment, or an extension to an existing PKI protocol

10. Open Issues - #3 (cont’d) • In the 4-pass, DSKPP uses the server public K_SERVER for R_C encryption, implying the use of trust anchors in the crypto module as per this note: • "If K is equivalent to K_SERVER, then the cryptographic module SHOULD verify the server's certificate before using it to encrypt R_C in accordance with [RFC5280]." • How this is done is not defined. • Salah and Ming suggested that we could do the same for 2-pass and encrypt the R_C in the ClientHello using K_SERVER.  • In this case, e.g., <KeyProvTrigger> may be used to pass the K_SERVER, the server 's cert or the server's public key ID/certificate ID to the client, then to the crypto module.   • MITM attack can be defeated in this process only if the server public key/certificate is pre-loaded in the CryptoModule and verified. 

11. Next Steps • Request support with open issues • Request teleconferences to: • Address better abstraction of the protocol model in terms of interacts with outside world • Narrow options down to a core set; decide which should/could be deferred to later document(s) • Submit another draft before the end of the calendar year that addresses: • The remainder of Sean Turner’s comments • Open issues