1 / 9

Extending TLS to Meet Protocol Developers’ Requirements

Extending TLS to Meet Protocol Developers’ Requirements. July 23, 2007 Tim Polk. Why Am I Up Here?. Protocol developers are increasingly drawn to TLS to provision security services As they should, it is a great protocol Strong KDF that incorporates TLS context into derived key material

lerin
Télécharger la présentation

Extending TLS to Meet Protocol Developers’ Requirements

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. Extending TLS to Meet Protocol Developers’ Requirements July 23, 2007 Tim Polk

  2. Why Am I Up Here? • Protocol developers are increasingly drawn to TLS to provision security services • As they should, it is a great protocol • Strong KDF that incorporates TLS context into derived key material • We want to encourage this, because inventing new mechanisms is always risky • Review is time consuming • Fixing errors is even more time consuming!

  3. Why Am I Up Here? • TLS provisioned security services focus on the TLS endpoints, not on the calling protocols • Applications do not have an opportunity to contribute context to the TLS KDF • Applications needing additional key material need to run another KDF

  4. Building on Channel Bindings • Channel bindings are an important step in the right direction • Incorporating the TLS finished messages into the authentication process binds the TLS key material to the authenticated identity at the application level • But we really want a mechanism that allows the application or protocol to contribute to the KDF, strongly binding the upper level context to the key material

  5. Opaque Objects • draft-rescorla-tls-opaque-prf-input-00.txt • “it is desirable to have some material with the following properties”: • It is contributed both by client and server. • It is arbitrary-length. • It is mixed into the eventual keying material. • It is structured and decodable by the receiving party.

  6. What Does That Get You? • Client and server can each assert their view of the application context • Client and server can verify application context is consistent at the endpoints • Key material that protects this application is strongly bound to that context, in addition to the context of the TLS session. • (If the client is authenticated,) the identities of both parties are bound to the key material.

  7. TLS Extractors Draft • Endpoints request creation of additional key material for use by the application • http://tools.ietf.org/html/draft-rescorla-tls-extractor-00 • This is a very powerful tool, but we can augment this and make it stronger • Cryptographers’ rule of thumb: applications should contribute something to the derivation of their own keys… • So opaque objects and extractors in concert would provide a much stronger solution

  8. Providing a tool • From the context of TLS, this mechanism does not have any negative impacts • From the context of the application, this mechanism can • Bind the app context to the session key material • Amplify channel bindings • Bind the app context to any additional TLS-derived application layer key material • We can and should provide these tools to application developers • Lets avoid those tricky protocol design problems!

  9. Proposal • TLS should adopt opaque objects as a wg document • TLS should adopt the extractors draft as a wg document

More Related