Security Area Open Meeting (SAAG) Minutes Meeting : IETF 79, Thursday 11 November 2010, 13:00-15:00 Location: Valley Ballroom B Chairs : Tim Polk and Sean Turner Minutes : Jim Schaad (edited by Tim and Sean) Version : 1 (2011-01-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 that had already met at IETF 79 were submitted to the SAAG list, along with several wgs that were not meeting at IETF 79. (See http://www.ietf.org/mail-archive/web/saag/ for details.) There were also several brief reports at the mike from wgs that were scheduled to meet later Thursday or on Friday. 3. Invited Presentations 3.1 High Assurance Redirection (The HARD Problem) (no draft) Richard Barnes and Peter St. Andre presented a common problem, where clients need to authenticate outsourced services obtained via a redirect. Where the service provider, client, and target are from different domains, it is very difficult to verify that the service provider is in fact authorized to speak on behalf of the target (or the target domain). This affects many different applications (e.g., HTTP, SMTP/IMAP/POP3, SIP, and XMPP), and the redirect can take many forms (usually at the DNS-layer or application-layer). A generalized solution is needed to enhance security and provide more consistent behavior across applications. This presentation spawned a very active discussion. Paul Hoffman indicated that the http redirect case is more important today than the CNAM or MX use case. Wes Hardaker agreed that solving the problem is critical but noted that DNSSEC deployment solves some of these use cases, and that the momentum around DNSSEC deployment makes this a realistic solution. Trust anchors remain an issue given the islands of DNSSEC deployment, but workarounds exist (e.g., pre-configuration with lists of trust anchors). Barry Leiba noted a relationship with the Internet-Draft draft-carpenter-referral-ps, "Problem Statement for Referral". Steve Schultze noted that client support is the biggest challenge for any of these solutions. Stephen Farrell and Joe Hildebrand commented that the number of different solutions were confusing the issue. There may be a need to forge ahead, implement, and simply compare results to see if a real difference exists. Russ Mundy noted that a single consistent solution is less important than architecting solutions for the various applications that do not demand user intervention/decision making. While the number of different solutions makes an irtf effort seem reasonable, the need for a deployed solution seems to preclude that type of strategy. 3.2 OAUTH draft-ietf-oauth-v2 Hannes Tschoefenig presented an overview of the ongoing OAUTH 2.0 work. The specification is nearing finalization, and Hannes would like to see more security input (especially with regards to security considerations) before they publish the OAUTH 2.0 specification. Rechartering is also underway, and a number of additional extensions are being considered as work items. If security extensions are needed, this would be a good time to get them into the charter. Richard Barnes noted that OAUTH is very flexible, and there are a number of different deployment profiles. Without an abstraction to define the goals and scope, the security considerations will be very hard to document. Barry Leiba pointed out the importance of User Interface issues in any OAUTH based application. Tom Yu talked about the importance of roles and relationships amongst the OAUTH protocol participants and noted that OAUTH's unique terminology complicates development of any security guidance. 3.3 Multipath TCP Security Issues: A request for Assistance draft-ietf-mptcp-multiaddressed Alan Ford presented an overview of "TCP Extensions for Multipath Operation with Multiple Addresses". Multipath TCP (MPTCP) provides a mechanism to combine several TCP flows into a single TCP connection. There are a number of issues related to hijacking; some of the problems exist in TCP as well, so the basic goal is not to make things worse. Since this is somewhat subjective, the working group has adopted the following goal: "ensure the hosts communicating in the new subflow setup are the same as the hosts in the initial connection setup". This document is intended for publication as an Experimental RFC, but the MPTCP working group would like to address the security issues to the greatest extent possible, and would appreciate an early security review. Paul Hoffman recalled that earlier versions had an independent control plane. The presenter indicated this was dropped for complexity reasons. Stephen Farrell indicated that DOS attacks were a significant threat to this protocol. A number of solutions were discussed, along with the practical complexities (such as middleboxes that drop TCP options) and performance implications. 4. Open Microphone Sam Hartman brought the PCP session, where standardization of a protocol to open pinholes in NATS, to the group's attention. Both firewalls and NATS are in their charter. This topic has a lot of complexity, and it would be good to discuss security considerations earlier rather than later. Peter St Andre noted that plain text passwords over TLS are weak, and better solutions exist. He asked whether the community was interested in working on a document to provide better guidance. Sam Hartman indicated interest in working on this, but felt the document should state "Do better than plain text passwords over TLS." rather than "Plain text passwords over TLS are bad." It was noted that requiring SASL would improve security, but would not be practical for many applications. Sam agreed, noting this was the rationale against writing a spec clearly stating "Plain text passwords over TLS are bad." Sometimes the existing solutions don't fit. Sean Turner closed the meeting by encouraging the saag participants to read and comment on three drafts regarding hash functions: draft-turner-md5-seccon-update, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms"; draft-turner-md2-to-historic, "MD2 to Historic Status"; and draft-turner-md4-to-historic, "MD4 to Historic Status".