1 / 16

TLS 1.2 and NIST SP 800-56A

TLS 1.2 and NIST SP 800-56A. Tim Polk November 10, 2006. Acknowledgements. The bulk of the analysis was performed by Ray Perlner at NIST Reviewed -01 draft. Background. NIST publishes cryptographic standards and specifications

pekelo
Télécharger la présentation

TLS 1.2 and NIST SP 800-56A

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. TLS 1.2 and NIST SP 800-56A Tim Polk November 10, 2006

  2. Acknowledgements • The bulk of the analysis was performed by Ray Perlner at NIST • Reviewed -01 draft

  3. Background • NIST publishes cryptographic standards and specifications • Agencies protecting unclassified data with cryptography need to use Approved algorithms • Based on FIPS 140, FISMA, etc.. • Exception: where no Approved algorithms exist, agencies can select any algorithm • CMVP may impose additional constraints

  4. FIPS 140 Implementation Guidance, 12/2005 • “The following protocols are acceptable for use in the FIPS mode to establish keys to be used for encryption and decryption:” • SSL v3.1 • TLS and EAP-TLS • IPSEC • SSH v2

  5. NIST 800-56A, Key Establishment • Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography • Published March, 2006 • Specifies key derivation function(s) • Basically, one kdf with two input formatting variants (ASN.1 and concatenated values)

  6. 800-56A KDF Overview.. • Generate keying material with a hash function from the shared secret and… • Cryptographic algorithm(s) identifier • Identifiers for communicating parties • Nonces (required if keys are static) • Optional information from both parties • The derived key material is bound to the complete communications context

  7. Silence Was Golden • Now that we specify a kdf… the FIPS 140 IG will be changing • Current proposal: • Accept protocols with 800-56A KDF • No such protocols exist • Review protocols that use non-conforming KDFs, accept with time limits • TLS is proposed for acceptance through the end of 2010

  8. Now That We’re Here… • This is clearly a bad situation • The WG chair reviewed the 800-56A KDF and determined it isn’t a good fit for TLS • The AD requested that NIST reconsider the problem • Could NIST accept the TLS kdf without an expiration date?

  9. Analysis • NIST could accept TLS 1.2 without an expiration date, with a few minor fixes • Finished message binds the context to the communications channel effectively • Niche cases exist where these bindings might not be established

  10. Certificate Hash • Certificate hash needs to be mandatory • If the hash is not included with the client certificate URL, the finished message will not factor in the name associated with the key. • Hash needs agility • The protocol mandates SHA-1, which is fine as a default, but there is no mechanism to specify a stronger algorithm.

  11. Upgrade Security Guidance to Requirements • TLS recommends mechanisms to protect against • Timing attacks (6.2.3.2, 7.4.9.1) • Bliechenbacher attack (7.4.9.1) • Can TLS 1.2 upgrade these to MUST? • Consider extending guidance for blinding to non-RSA key exchange algorithms?

  12. Clarifications in Error Handling • Need to clarify when alerts MUST be sent versus MAY be sent • Responses on list have been helpful; would like to see this information in the spec

  13. Incremental Changes • IVs • MUST use one of the specified IV generation techniques • Certificate Handling, HMAC truncation • Should require explicit agreement • DH • Recommend maintaining leading zeroes

  14. Anonymous Diffie-Hellman • Frankly, it makes us nervous. • List traffic does not support expunging Anonymous DH • Need to ensure that Anonymous DH is only used with user agreement • Bodo Moeller has suggested text: • http://www1.ietf.org/mail-archive/web/tls/current/msg00900.html

  15. Further Information • NIST 800-56A (see 5.8) • http://csrc.nist.gov/publications/nistpubs/800-56A/sp800-56A_May-3-06.pdf • Personal draft with KDFs • http://www.ietf.org/internet-drafts/draft-dang-nistkdf-01.txt

  16. Questions?

More Related