The Dynamic Symmetric Key Provisioning Protocol (DSKPP)

1. The Dynamic Symmetric Key Provisioning Protocol (DSKPP) KEYPROV WG IETF-71 Philadelphia March 11, 2008 Andrea Doherty

2. Current Status • Interim face-to-face meeting held in Bedford Feb 6-7, 2008 • Liaison report from IEEE P1619.3 chair Matt Ball • Discussed/resolved all open: • DSKPP issues • PSKC issues • SKPC (ASN.1) issues • DSKPP/PSKC alignment issues • PSKC/SKPC alignment issues • Draft-ietf-keyprov-dskpp-03 was submitted Feb 25, 2008 • Document cleanup • Addresses comments received on mailing list and at IETF-70, as well as resolutions from interim meeting

3. Draft -03 Document Updates • Editorial Changes • Introduction • Terminology • Use Cases • User Authentication • Security Considerations • Object Model • Aligned entities with PSKC and SKPC (e.g., Key Container -> Key Package) • Message Flows • Made corrections • Imitated message flows in IKEV2 (RFC4306)

4. Draft -03 Document Updates (cont’d) • Protocol Variants • Removed one-pass variant • Provided rationale for four-pass • HTTP Binding • Incorporated comments from Thomas Roessler of W3C • Conformance Section • Updated based on input from Interim meeting • Schema Changes • ElementDefault now equals “qualified” instead of “unqualified” • Removed references to schemaLocation • Rely on URL rather than URN for algorithm URI

5. Open Issues(refer to Issue Tracker - http://www.shingou.info:8080/keyprov/index)

6. Issue A – Authentication Code Format • Draft -03 does not specify a format • For interoperability purposes, a format should be defined as mandatory-to-implement • Proposed Approach • Authentication code MUST contain a client identifier and one-time use password • Authentication code MAY contain a checksum (CRC16 of ISO3309) • Rely on TLV format with a length set to 1 byte

7. Issue B – Scope of MAC • MAC does not cover all messages/payloads (Pasi Eronen) • This limits future extensibility • Typically, in key exchange protocols, the first message does not have a MAC, but once a key is agreed on, it is used to MAC all subsequent messages (e.g., Finished messages in TLS and AUTH payloads in IKEV2) • Originally the MAC was only intended for key confirmation (Magnus Nystrom) • The most critical elements are currently included in the MAC • The MAC fulfills the need for key confirmation • Would be better if final MAC included all components sent and received by the server. This way one could get integrity protection of other protocol elements even ouside of a tunnel, e.g., in EAP-POTP.

8. Issue C – Open Questions from Review • Review comments (Roessler) that still have to be addressed: • Identify early on in the document which namespace prefixes are used in the XML schema and what they mean. • Be clearer about what parts of ds:KeyInfoType are being used for payloads and public keys (see Section 11.2.3 and 11.3.3). • It would contribute to the clarity of the Security Considerations if there was a clear discussion of the assumptions beforehand, and a consistent use of attacker models later on. • Possible weakening of keys if both device and server support multiple key types with mutually interchangeable key material. Consider using the negotiated algorithm value as input into the MAC derivation mechanism. • DSKPP currently only protects the key material • To address this, the MAC can be expanded as per Issue B

9. Issues D and E • Issue D - IANA Considerations are incomplete (Tschofenig) • KEYPROV co-chair (Hannes Tschofenig) to ask IANA whether it would be possible for them to post KEYPROV URIs on their Web Site • Section will be completed for next update • Issue E – Examples Depend on PSKC • Examples may have to be updated when PSKC changes

10. Next Steps • Close remaining issues • Effort required is relatively simple • Revise and resubmit draft for WGLC In addition: • Add SOAP binding document (e.g., draft-doherty-keyprov-ct-kip-ws-00) as a working group item?