SAAG Minutes IETF 71 Prepared by Tim Polk from George Jones' meeting notes ADs: Tim Polk, Pasi Eronen Called to order about 1:04 The meeting began with a show of appreciation for the outgoing Security Area Director, Sam Hartman. Sam highlighted some of the Security Area's accomplishments during his three year tenure, and thanked the folks that had made it all happen. He also noted that he looked forward to continued collaboration with the security community in future IETF activities. Pasi Eronen was introduced as the incoming Security Area Director. He said he had lots of new things to learn and an amazing amount of email to read, but was excited by the new challenges and was looking forward to working with the IETF Security Community to help progress their work. WG Reports were presented by all security wgs that had scheduled meetings at IETF 71. Summaries of meeting reports and any discussions follow: >>> Steve Kent reported for PKIX. PKIX met once for 2.5 hours on Monday with about 60 attendees. Four PKIX documents have received IESG approval since the last IETF meeting: 3280bis and the CMC trio. There were five presentations on WG items, and five on related items. Highlights included discussions on trust anchor management and wild cards in DNS names as described below. The trust anchor management effort was the topic of two presentations. The first reviewed the current version of the problem statement I-D, and noted the plan to abandon this document and transition much of the text into a requirements statement I-D. The second presentation described a directory-based approach to TA management, and compared it to the request/response protocol approach that has been put forth so far. Both approaches can benefit from a common data structure model, but each approach offers somewhat different functionality. A discussion of the use of wildcards in DNS names in certs concluded with an agreement that this topic is adequately addressed in 3280bis; processing semantics beyond what 3280bis describes are best handled in the WGs responsible for the secruity protocols that allow use of this convention. The complete meeting summary may be found at http://mailman.mit.edu/pipermail/saag/2008q1/002176.html >>> Eric Rescorla presenting for TLS TLS met Monday at 1520-1420 for an hour. Don Eastlake presented RFC 4366-bis, which is the separate draft for TLS extensions. This is mostly editorial but there are two technical issues about certificate URL hashing. The general consensus was (1) to mandate the hash and (2) deal with hash agility by defining a new code point if we need to. Pasi Eronen presented the DES/IDEA cipher suite document, which breaks those cipher suites out of the main TLS draft. There was discussion about what kind of disclaimer to use and general consensus that in future we need to put clear applicability statements on cipher suites. Pascal Urien presented ECDHE_PSK, a new WG item. This hasn't had enough review to advance yet. We commissioned two reviews. Eric Rescorla presented plans for DTLS 1.1. The intention is simply to rev the version to align with TLS 1.2 and fix ambiguities in the original spec. There was substantial support for adopting this as a WG item--needs to be confirmed on list. Kato Akihiro presented Camellia cipher suites with SHA-256. Camellia is already in TLS, but with SHA-1. >>> Stephen Farrell reported for dkim. DKIM met on Wed morning, ~43 people signed the blue sheets. The base specification is in the RFC editor's queue. WGLC for the SSP requirements document runs until the end of next week; several issues were discussed and one is going to the list for a strawpoll. The wg has selected draft-allman-ssp as the basis for developing the ssp document (with a number of changes that were discussed at the meeting). Early April is the target for draft-ietf-dkim-ssp-00. The chairs hope to get active involvement from some DNS people in this work. The authors have proposed splitting the Overview document into three parts (from the authors). While there were a couple of concerns with that, the meeting was ok with going with the authors' suggestion since they were concerned with getting out text that'll help with deploying the base specification sooner rather than later. See http://mailman.mit.edu/pipermail/saag/2008q1/002167.html for additional information. >>> Steve Hanna reported for the nea working group. The Network Endpoint Assessment (NEA) WG met at IETF 71 on Tuesday, March 11, 2008 from 9 AM to 11:30 AM EDT. The meeting began by reviewing changes in the nea-requirements draft in response to IESG COMMENTs and DISCUSSes. The bulk of the meeting was spent reviewing the PB-TNC, PA-TNC, and PA-TNC Security proposals. These were the only responses to the request for protocol proposals that meet the NEA requirements. After a good discussion of the proposals, a consensus check showed a clear consensus in the room to accept PB-TNC and PA-TNC as WG drafts. For PA-TNC Security, there was no wg consensus that PA-TNC security was needed, given that security is provisioned at the lower layer. After work progresses on the other two protocols, it could be Deferred for further discussion. More details may be found at http://mailman.mit.edu/pipermail/saag/2008q1/002172.html >>> Phil Hallam-Baker reported for Keyprov. The working group is making steady progress. Most of the problems the wg faces at this point are in "XML land" rather than "security land". The ADs suggested noting the XML issues when documents are forwarded for IETF Last Call. The AD can arrange for a review by the XML Directorate in parallel with IETF Last Call and avoid unnecessary delays. Phil noted that he was not that concerned about the design decisions themselves, but very concerned about documenting the rationale behind them. >>> Tom Yu reported for SASL. The SASL meeting focused on rechartering, and the related issue of work on the DIGEST-MD5 successor. The wg had two candidate drafts; SCRAM and Simon Josefsson's ID. After some discussion, Simon Josefsson, Chris Newman, and Alexey Melnikov agreed to merge Simon's doc with the SCRAM draft. They will also produce a comparison of Simon's doc and SCRAM. The wg discussed whether to block GS2 behind SCRAM, but postponed the decision until IETF72 (Dublin). Kurt Zeilenga will coordinate interop testing in Dublin. A more comprehensive session summary is available at http://mailman.mit.edu/pipermail/saag/2008q1/002177.html >>> Jeff Hutzelman reported for krb-wg. The meeting of the kerberos working group meeting generated five action items: * Nicolas Williams - send an updated version of set-change password * Chairs - finish review and writeup of cross-realm problem statement * Larry Zhu - prepare an example for naming of how unintended access could be granted if authentication succeedes with an unsupported well-known name. * Chairs - ask folks commenting that the data model might be incomplete to come up with specific examples of things that are missing. * Larry Zhu, Shawn Emery, others - examine the data model with respect to their specific implementations. Two tentative decision were made at the meeting, and will need to be validated on the mailing list: * The data model document should not cover operations. * OTP perhaps does not need a mandatory-to-implement mechanism A more comprehensive session summary is available at http://mailman.mit.edu/pipermail/saag/2008q1/002180.html >>> Sean Emery reported for kitten. The kitten-wg met Tuesday, 3/11/08, during the last afternoon session. The goals of the meeting were to go over the active working items and Milestones. Both domain-based drafts have cleared DISCUSS issues and are now in the RFC editor's queue. The IANA extension draft and the channel-bindings clarification draft are nearing wglc. A new editor has volunteered to take over naming extensions ID, which needs the most work compared to the other drafts in the WG. We have decided to spread out the work load by submitting WGLC on the Java bindings draft, draft-ietf-kitten-rfc2853bis-03, after the IANA, channel bindings, and the naming extensions draft. WG milestones have been pushed out. Co-chairs will update with the new time lines shortly. A more comprehensive session summary is available at http://mailman.mit.edu/pipermail/saag/2008q1/002174.html >>> Charles Clancy reported for hokey Charles Clancy began by recapping the status of the five hokey documents: the HOKEY Re-authentication Problem Statement is in the RFC Editor's Queue. The EAP Reauthentication Extensions (ERX) draft is in IESG Evaluation, and the EMSK Keying Hierarchy is in IETF Last Call. The Pre-authentication Problem Statement is ready for wg last call, which leaves the HOKEY Key Management draft as the focus for hokey. HOKEY met Wednesday morning. Most of the discussion related to the HOKEY key management draft, which describes how to distribute EAP session keys to various network entities. Discussion resulted in consensus and a specific plan for how to move the document forward within the working group. Specifically, the proposal involves simplifying the protocol to a single RT between the key recipient and the home AAA server, and relying on AAA security rather than implementing our own. More details may be found at http://mailman.mit.edu/pipermail/saag/2008q1/002178.html >>> Donald Eastlake presenting for KMART The KMART BOF was anticipated to be very interesting, as in very controversial. In fact, the BOF was more successful than anticipated which led to it being less exciting perhaps. There were good presentations by Routing and Security Area Directors, discussions of link state routing, threats, and key management. There seems to be agreement that there are four problems and three are probably pretty easy. The fourth is a multicast problem, and is generally considered a research topic. Tim Polk thanked Don for taking the lead. He was very encouraged that many people thought there should have been a charter discussion. While Tim felt that was premature, and that we really needed that exchange of background ideas instead of charter work, but he considered it a very good sign for long range work. >>> Tim Polk reported for ltans The ltans working group had a very brief meeting. There are only a few documents left, and the chairs hope that everything will be in Last Call before Dublin. The group hopes to shutdown before the end of the calendar year. >>> Lakshminath Dondeti reported for msec The msec working group had a one hour session on Wednesday which was devoted to discussion of new work items. There are requirements related to a signaling protocol (RSVP) and routing protocols (e.g., OSPF, NLS) which point to the need for group key management protocols. There are indications that the work needs to happen in MSEC; although there is caution from the TSV ADs that the requirements do not imply that a particular protocol can be adopted as a MSEC work item. Extending GDOI to satisfy these requirements is one possible direction, but the there was no urgency for immediate wg action. The authors are advised to continue the work as individual work. Dan Wing presented his SRTP key transport work which works over DTLS. MSEC has a work item on group keying for SRTP, GDOI-SRTP. Sheela Rowles compared to the two approaches and after some discussion the conclusion was to pursue optimization of GDOI-SRTP for large groups and DTLS-SRTP-Key transport for small groups. As a side note, Dan was asked to study if there are indeed difficulties in using the TLS-based solution for large groups. A more complete meeting summary may be found at http://mailman.mit.edu/pipermail/saag/2008q1/002181.html >>> Joe Salowey reported for emu EAP Method Update (EMU) working group met Thursday morning. Discussion primarily focused on revising the charter to include tunnel method and the definition of EAP Channel Bindings. Next steps are finalizing the charter and requirements for the tunnel method. We also had a presentation on a secure password only method (draft-harkins-emu-eap-pwd-01). There was some interest in this type of method, but the working group was not ready to take this work on at this time. >>> Sean Turner reported for smime S/MIME will meet immediately after the SAAG session. S/MIME had one document get an RFC number The RSA KEM draft is in some IPR limbo. There were a number of IPR statements submitted to IEEE against P1393, but it isn't clear which apply to this draft. A meeting summary may be found at http://mailman.mit.edu/pipermail/saag/2008q2/002190.html More Working Group News Tim Polk announced that the Security Area needed new co-chairs for the tls, msec, and emu working groups. Please send nominations to Tim and Pasi. You can nominate others or nominate yourself! Experience as a wg co-chair in the past is not essential, and it is okay if you are not the world's leading expert in the technology. Management skills are also important, and Pasi and I will try to pair people with complementary skills in a wiorking group. That is one of the advantages of having co-chairs. INVITED TALKS There were two invited talks by David McGrew. The first presentation, "Interface and Algorithms for Authenticated Encryption", revisits the new RFC 5116. The second presentation focused on a new Internet Draft, draft-black-ipsec-ikev2-aead-modes, which he credited as mostly David Black's work. Please refer to the slides for the talk; highlights of the Q&A are supplied below. RFC 5116: Frequently, a protocol wants both encryption and authentication. This document provides a higher level abstraction, where a single algorithm provides both services. AEAD algorithms include AEAD modes (such as GCM or SIV) for standard block ciphers such as AES, as well as new algorithms that natively provide AEAD functionality. Yaron Sheffer asked what makes an algorithm eligible for AEAD? For example, why isn't the combination of a block cipher in CBC mode and an HMAC an AEAD algorithm? David indicated that it could be considered an AEAD algorithm and that he had submitted a draft defining such a combination. This is one of the advantages of raising the level of abstraction. There was a lot of discussion about nonces. David noted that the highest performance AEAD algorithms supported nonces, and nonceless algorithms were still supported by supplying a zero length nonce in the API. Dan Harkins noted that some AEAD algorithms (e.g., those based on the SIV mode) were still secure even if the nonce was reused. Paul Timmel asked why RFC 5116 had nonce generation above the API instead of hiding it below the API. David noted that the first drafts had hidden the API, but the academic community did not like it. The academic community has a specific definition for AEAD algorithms, and hiding nonce generation would violate that definition. draft-black-ipsec-ikev2-aead-modes David McGrew opened by crediting David Black as primary author. This draft defines how to use GCM, CCM, or any other AEAD algorithm with IKEv2. The draft defines a new encrypted payload format, and a associated data format to match up with the AEAD definition. The draft also describes how to generate a nonce in a way that is compatible with CCM and GCM. The draft is motivated by a desire to use AES-GCM and CCM with the ESP and IKEv2. Part of the motivation is implementation reuse - now that they have the circuits to go fast with ESP, they would like to do the same with IKEv2. While IKEv2 has relatively low bandwidth, the increased performance would allow you to terminate more IKEv2 connections in a single box. Imagine you have a box terminating 10k sessions, box reloads, all 10k try to get back in. It is a race to bring back up 10k sessions. Faster crypto algorithm increases the number that will be successfully restarted. Paul Hoffman noted that David Black said this was for iSCSI, and the number of sessions would be far less. Greg Lebovitz noted that *if* we were to use IKEv2 to secure routing protocols, BGP peers might have 1-2k edge routers. When a box bounces, that would be a lot of reconnects. David asked the saag attendees for feedback on the compatability and conformance decisions incorporated into the draft. Specifically, he asked if complete compatibility with ESP usage was Some of the options supported in ESP were omitted from this draft, including support for AES 192, 8 and 12 octet ICVs for GCM and 12 octet ICVs for CCM. Should these options be included for complete alignment. There were a variety of opinions on both sides of this issue. Considerations included consistency with ESP and minimizing the size of hardware implementers. OPEN MIKE Yaron Sheffer initiated a discussion about IPR issues and when they should or should not be an impediment to progression or acceptance in the IETF. He was concerned that the possibility of IPR infringement was sufficient to derail important work in discussions earlier that week, and felt an analysis of IPR issues was warranted. Pasi Eronen noted that there are very few lawyers in the IETF, and the IETF does not accept opinions on IPR for very good reasons. Tim Polk noted this has always been a struggle for IETF. IPR constraints have to be analyzed on a case-by-case basis, and you need to build consensus on the IPR issues just like anything else. There won't be official IETF patent reviews, but you can encourage people to do reviews. Russ Housley noted that the IPR requirements might be different if the work is progressed on a different publication track than standards.