1 / 7

CT-KIP

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:

vlora
Download Presentation

CT-KIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. Principles of Operation

  4. Recent Modifications – CT-KIP: 4th 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 <KeyID> element in the client's initial message • For use when token already is initialized • Replaced the <Nonce> element in the server's initial message with a <Payload> element, which in turn is a <choice> • 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.

  5. Recent Modifications – CT-KIP 5th draft • Clarified that the length of nonces RC and RS 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 <TokenID> 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 <TokenID> element allowing the server to assign an identifier also for the token and not just the generated key • Added a "Security Considerations" section

  6. Recent Modifications – CT-KIP’s PKCS #11 Interface 4th and 5th draft • Clarified that the <KeyID> element from CT-KIP may be used as CKA_ID • In Appendix B, modified the proposed/suggested procedure to let KTOKEN 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

  7. 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

More Related