Dynamic Symmetric Key Provisioning Protocol (DSKPP)

Andrea DohertyMingliang PeiSalah Machani

Magnus Nyström

IETF 74San Francisco, USA

24 March 2009

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)

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

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

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)

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)

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

Next Steps

• Submit -08 draft– Update DSKPP based on comments received– Finalize terminology alignment with PSKC