Security Area Open Meeting (SAAG) Minutes Meeting : IETF 73, Thursday 20 November 2008, 17:40-19:30 Location: Minneapolis Hilton, Salon G Chairs : Pasi Eronen and Tim Polk Minutes : David Cooper and Paul Hoffman (edited by Tim and Pasi) Version : 2 (2008-12-05) ---------------------------------------------------------------------- 1. Overview - ADs The ADs opened the meeting with a review of the agenda. 2. WG Reports - WG Chairs Reports of the Security Area Working Groups were submitted to the SAAG list (see http://www.ietf.org/mail-archive/web/saag/ for details). Inspired by Pete Resnick's plenary comments, wg reports were not read but there was an opportunity for questions and discussion about each of the groups. Alan DeKok, co-chair of EMU, noted that questions about internationalization have come up in multiple groups and suggested that people come to him to discuss these issues. Sam Hartman proposed forming a group to address the internationalization issue. Tim Polk asked whether EMU might be interested in taking the lead. Alan noted that EMU was one possibility, but RADEXT, and DIME are also possibilities. It was also noted that SASLprep already dealt with these issues in the past, and might be a good source for intitial work. 3. BOF Report - OAUTH Sam Hartman indicated that there was consensus during the BOF to work on delegated authentication, but some impediments to progressing the work remain. The problem definition is straightforward, but the charter discussions were inconclusive. The major blocking issue is the degree of backward compatibility with current protocol. Extensibility of the current model may also be a sticking point. There is now an IETF mail list, oauth@ietf.org. 4. Invited Presentations: There were two invited presentations. 4.1 The Need for Cryptographically Insecure Hash Functions (Eric Rescorla) Eric noted that cryptographic hash functions are used in many places where the cryptographic properties are unnecessary. He proposed the standardization of an insecure hash that is fast relative to cryptographic hashes, the use of which would signal to protocol reviewers that the use of the hash function is not in intended to provide any security properties. While some people agreed that it would be useful to allow non-cryptographic hash functions where performance is an issue, there were strong opinions on both sides on the question of whether to use a non-cryptographic hash function solely for the purpose of indicating that to protocol reviewers that the cryptographic security properties are not necessary. Some of the opinions that were expressed at the mike following this presentation included: * David Black and Lakshminath Dondeti had questions about how many current protocols that might be helped by an insecure hash function. David was concerned that even if pre-image resistance is not needed, collision resistance may still be important. * Wes Hardaker noted that we would need detailed applicability statements that described when cryptographically insecure hash functions would be appropriate * Charlie Kaufman noted that a CRC would not be a good choice - Performance in software is worse than expected, and judging polynomials is very tricky. UMAC or Uhash might be a good starting point. * Sam Hartman expressed reservations, thinking security area reviews might be superficial when presented with protocols that use such hash functions * Dan Harkins suggested creating an MD5 clone with a different name and calling the problem solved. * Derek Atkins expressed support for the idea of standardizing cryptographically insecure hash functions, since this would allow the security area to frontload the security analysis. * Vidya Narayanan asked whether Eric's requirements for speed was really appropriate. David Black responded that strong interest in GCM in storage space is evidence that hardware speed and efficiency do matter to at least one community. * Joe Salowey noted that it can be easier and safer to just tell protocol designers to use a secure hash function. Tim Polk noted that this is clearly easier for security reviewers, but may be unfair to move that burden to designers in other areas. * Stephen Farrell noted that applying cryptographically insecure hash functions assumes that protocol designers will do the security analysis first: this is often a bad assumption. He also noted that content types change over time, and the need for cryptographically insecure hash functions could change to the need for secure hash functions. 4.2 (Re)Introducing Strong Password Protocols (Radia Perlman) Radia provided a history of protocols for performing password-based authentication in a manner that that is not vulnerable to off-line guessing attacks based on the information that is transmitted across the network between the entity performing the authentication and the authenticator. The presentation covered EKE, SPEKE, PDM, and augmented variants. She described how these protocols can be leveraged to bootstrap a PKI (for credential download), or to construct site-specific passwords. She also noted that there are two reasons these protocols are not widely used today: the IPR situation is very confusing; and using TLS to tunnel weak password protocols is good enough for most applications. Eric Rescorla noted that many web site designers do not like using protocols such as these since they wish to control the user interface, and that public key cryptography is a competing and arguably better solution. Charles Clancy noted that problems also arise if you are authenticating to a third-party server. Barry Lieba noted that one could make a plug-in to do these; Eric responded that this can lead to phishing. Stephen Farrell expressed support for initiaiting work, but only if the work was leveraging EKE explicitly, since EKE is the only algorithm whose IPR is clear. 5. Open Microphone There were no questions. ----------------------------------------------------------------------