1. Dynamic Symmetric Key Provisioning Protocol (DSKPP)
Andrea Doherty
Mingliang Pei
Salah Machani
Magnus Nyström
IETF 74
San Francisco, USA
24 March 2009

2. Document Status Version -07 submitted February 9th
Made the document more readable
Explained how protocol entities interact with the outside world
Reduced the number of options for client authentication
Modified conformance requirements to recommend all three key wrapping mechanisms (kw-aes128 w/ and w/out padding, aes-128-cbc)

3. Readability and Implement-ability
Described how the DSKPP model interacts with application
Described protocol entities in language geared for application developers:
When and why a message is used
Inputs – Processing - Outputs
Eliminated forward references, e.g.,
MAC Calculations
Key Protection Methods
Moved Usage Scenarios to an appendix
Simplified description of authentication code format

4. Interoperability
Previously, developers could implement client authentication using any of at least 25 combinations of the following options:
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 with a web mechanism, then use TriggerNonce as one-time secret)
Client certificate/key pair, used with TLS client authN
Client certificate/key pair, used for DSKPP Key Transport
Pre-existing symmetric key

5. Interoperability (cont’d)
Improved interoperability by reducing the number of allowable options for client authentication
Eliminated client authentication options that relied on client cert/key pair used with TLS client auth
For two-pass, Security Considerations still recommends running protocol over transport channel that can provide confidentiality
Combined authentication code and PBKW since both use a one-time secret value
Replaced trigger nonce in <KeyProvTrigger> with authentication data (which is derived from authentication code)

6. Key Wrap Protection Method
Do not limit developer to one algorithm. If algorithm is deprecated later, want developers to have alternative option(s) rather than waiting for the RFC to be revised
The following algorithms are recommended:
kw-aes128 without padding (xmlenc#kw-aes128)
kw-aes128 with padding (draft-housley-aes-key-wrap-with-pad-01)
AES-CBC-128 (FIPS197-AES)

7. New Comments Received
Add “Principal syntax is XML and it is layered on a transport mechanism such as HTTP” to Section 3.1.
Add text to Basic DSKPP Exchange describing beginning, middle, end of protocol exchange; as well as what an attacker can/cannot do
Remove <TokenPlatformInfoType> and <PlatformType>; these entities can be handled by <ClientInfoType>
Editorial (clean up Figure 3, remove “NOTES” and forward references, fix hanging indents)
Terminology alignment with PSKC

8. Next Steps Submit -08 draft Update DSKPP based on comments received
Finalize terminology alignment with PSKC