CT-KIP Magnus Nyström, RSA Security OTPS Workshop, October 2005

Overview A client-server protocol for initialization (and configuration) of cryptographic tokens —Intended for general use within computer and communications systems employing connected cryptographic tokens Objectives: —To provide a secure and interoperable method of initializing cryptographic tokens with secret keys —To avoid, as much as possible, any impact on existing cryptographic token manufacturing processes —To provide a solution that is easy to administer and scales well —To provide a solution which does not require private-key capabilities in tokens, nor the existence of a public-key infrastructure

Principles of Operation

Recent Modifications – CT-KIP: 4 th draft XML related —Switched to UpperCamelCase for XML names, as per discussion at the May workshop —Switched to explicit XML namespace usage, as per discussion at the May workshop —PDU (message) names changed to more descriptive names Introduced an optional element in the client's initial message —For use when token already is initialized Replaced the element in the server's initial message with a element, which in turn is a —For future use Suggested MIME type is now application/vnd.otps.ct-kip, since application/ct-kip would (normally) have required an RFC and approval by the IESG.

Recent Modifications – CT-KIP 5 th draft Clarified that the length of nonces R C and R S may depend on selected key types Expanded discussion in Section 3.3 on ways for the server to couple an initial user authentication to a CT-KIP session (and hence a particular key) Expanded text on comparison of XML string values Introduced a CT-KIP "trigger" or initialization message In the ClientHello message, clarified that the element must be present only if provided by the CT-KIP server in a trigger or if there is a key shared between the token and the CT-KIP server —Clients cannot assign a Token Identifier In the ServerHello and ServerFinished message, clarified that the parameters to the MAC are the same regardless of the MAC algorithm In the ServerFinished message, added a element allowing the server to assign an identifier also for the token and not just the generated key Added a "Security Considerations" section

Recent Modifications – CT-KIP’s PKCS #11 Interface 4 th and 5 th draft Clarified that the element from CT-KIP may be used as CKA_ID In Appendix B, modified the proposed/suggested procedure to let K TOKEN be generated after receipt of the ServerFinished message. This simplifies providing a complete template to C_DeriveKey Editorial corrections and clarifications thanks to Laszlo Elteto, Safenet Still missing here is actual assignment of mechanism identifiers

For Discussion Security Considerations section needs review Agreement and stabilization of document content —Need to verify completeness wrt OTP-PKCS #11, EAP-POTP, etc. Applies to all OTPS documents Assignment of PKCS #11 mechanism identifiers Possible future contribution of document, to (new) OASIS TC or elsewhere? Proposed schedule —Produce final draft versions within a month from this workshop —Publish Version 1.0 about two weeks after that