Last Modified: 2005-01-18
| RFC | Status | Title |
|---|---|---|
| RFC3365 | BCP | Encryption and Security Requirements for IETF Standard Protocols |
|
Security Area Advisory Group (SAAG)
IETF 62, Minneapolis, MN Minutes compiled by Sean Turner and Russ Housley Introduction Russ Housley presented the agenda: WG Reports BoF Reports Invited Presentations - AVISPA - OATH HOTP - MD5 and SHA-1 Status Open Microphone Working Group and BoF Reports Each working group or BoF that had a meeting at IETF 62 gave a very brief summary of the session. Please see the minutes for each of these sessions. The highlights are not repeated here. Reports were given by: INCH Enroll ISMS Kitten KINK KRB-WG MOBIKE MSEC OpenPGP PKI4IPsec PKIX SASL SecSH BTNS BoF AVISPA (See Armando-AVISPA.ppt) Alessandro Armando, from AI-Lab, DIST - University of Genova, Italy, gave a presentation on Automated Validation of Internet Security Protocols and Applications (AVISPA). It is a project funded by the EU. He covered: - The development of security protocols is out-pacing human ability to analyze them. - Tools are needed to support the analysis of these protocols. - Some protocol analyzers exist, but they do not support large protocols and each one has a unique language and user interface. - Want to develop a rich specification language, advanced techniques, integrated developer tools, and standard AVISPA Library. - Want to assess the practicality using AVISPA Tool. - There are four "backends" to do checks on protocols. - The High Level Protocol Specification Language (HLPSL) is role based language. - Tool can be accessed at www.avispa-project.org/web-interface. - AVISPA Library tested against a set of security problems with protocols that have been recently standardized by the IETF, uncovering 112 problems in 33 protocols. - There are four universities working together on the development. Comments and Questions/Answers C: Support for LINT-like applications, but there is a problem. The HLPSL representation of the protocol may not represent all of the English language details. The mathematical form may not actually capture the full protocol, especially checks. C: Found tool useful to apply different modeling tool. Interesting to make sure others can understand it. Formal methods and IETF standard writers use different styles. Bouncing it across both is helpful to make language more understandable. Q: TLS is a list of protocols that were checked with the tool; did you find the CBC attack to the Million-Message attack? A: No. Currently crypto operators are assumed to be flawless. Q: Are implementations being analyzed? A: No. The tool works on the protocol description, not an implementation of the protocol. Q: Does tool confirm that it is a correct implementation of the protocol using the test vectors in the specification? A: No, but that is an interesting thought. The One Time Password algorithm from OATH (the initiative for Open AuTHentication) (See dmraihi-oath-hotp.ppt) David M'Raihi, from Verisign, gave a presentation on the OATH one-time password algorithm. He covered: - Why? One-time passwords (OTP) are more secure than static passwords. OTP is easy, like two-factor authentication. - Several algorithms exist, but they are proprietary, so information is not available for peer review. - An open algorithm makes it possible for anyone to analyze. There is a freely available description and a reference implementation. - Requirements: usable, secure, implementation flexible, and economic. - Algorithm uses HMAC and SHA-1, which are both open and public. - Algorithm description: HOTP (Counter, Key) = Truncate (HMAC-SHA-1 (Counter, Key)) - The recently announced SHA-1 attacks cause no concerns in this algorithm. - About ten companies have implemented the algorithm, including software tokens, hardware tokens, and SIM cards. - Next Step: an open standard. Comments and Questions/Answers Q: How does this compare to RFC 2289, which specifies S/KEY? S/KEY is IETF standard, where an attack on the server does not allow the attacker to masquerade as the user. A: The OATH OTP does not have this property. If an attacker gets the key stored on the client or the server, then it can masquerade. However, S/KEY was not selected because of usability concerns. The amount of data that the user must type in an hardware token implementation is unacceptable. C: S/KEY and this have different UI. MD5 and SHA-1 Status (See ekr-digest-status.pdf) Eric Rescorla, from Network Resonance, gave a presentation on MD5 and SHA-1 and the recent attacks against them. He covered: - Terminology: -- Collision: Find M, M' such that H(M) = H(M') -- 1st preimage: Given X, find M such that H(M) = X -- 2nd preimage: Given M, find M' such that H(M') = H(M) - MD5 collision (practical). - SHA-1 in 269 operations (theory); when it should be 280 operations. - Certificates - Lenstra et al. demonstrate a pair of certificates with different public keys but the same hash. - None of these attacks allow you to compute preimage. - The collisions are not totally controllable; where the changed bits will be located depends on current hash state. - DO NOT panic! - These attacks do not affect key derivation functions (PRF), peer authentication protocols with non-repudiation (SSL, IPsec, SSH), message authentication (HMAC), challenge-response. - These attacks do affect non-repudiation, certificate issuance (only in special instances), and timestamps (maybe). - Since the CA has control over some of the fields in the certificate there are ways to thwart attacks based on these hash collision attacks. - DO NOT Panic, but we do need to create a plan for the future: -- SHA-224, something new? -- New randomized hash algorithms; in ASN.1 protocols one needs a random value in the algorithm identifier parameter. -- As a stop gap measure, randomize certificate serial numbers (or dates in the validity period). Comments and Questions/Answers C: Primitives should work without special rules. Better to use new functions or randomize SHA-1. C: CRL size increases if you increase size of serial numbers. C: Can add randomness buy adding a GUID to the subject name. C: NIST wants people to move beyond 80-bit strength by 2010. Given these new attacks, that transition may need to move forward. Q: Why SHA-224 and not SHA-256. A: It's just the next one on the list. Any larger one could be used. Q: Do we have new problems where we use a key for both encryption and signatures? Should we move it to dual keys? A: These attacks do not make matters any worse. Open Microphone Q: Need algorithm independence in all protocols. A: Yes. However, need to ensure there is not any multi-layer negotiation. Q: Some are proposing to use hash function to produce long-lived IDs. HIP is one example. What are the implications? A: There might not be a problem with this usage because there is not a third party. |