Minutes of the Security Area Advisory Group (SAAG) Thursday, December 6, 1300-1500 SAAG Scribes: Donald Eastlake and Paul Hoffman Area Directors: Tim Polk, Sam Hartman Each working group and BOF that met during the week gave a brief report. For summaries of these meetings see the working group or BOF minutes. These minutes highlight discussions that happened during the WG reports to the SAAG. Eric Rescorla presented for TLS: Main work item is completion of TLS 1.2. The current draft is basically stable; most changes in this version were editorial. There is an outstanding question about whether ciphersuites with IDEA should be specified as SHOULD NOT or MUST NOT in TLS 1.2. The TLS extractor document had broad support in the room; if confirmed on the list, this will be adopted as a wg document. There were several other presentations proposing new work, but it has not determined whether to accept or reject these proposals. Steve Kent made the presentation for PKIX: The PKIX WG has reached significant milestones on several long standing projects. SCVP is in AUTH48; the three CMC specifications have been approved by the WG; and 3280bis has gone to WG Last Call. There was a presentation from a design team on specification of ECC keys that appears to resolve a potential conflict with another SDO. Sean Turner will submit an Internet Draft documenting the proposal for consideration by the WG. The WG meeting also included a presentation on Trust Anchor management (TAM), which is now under consideration as new work. The WG is also working on responses to queries from ITU on Distinguished Name uniqueness and on upper bounds on strings used in DN attributes. Hannes Tschofenig made the presentation for Keyprov. There are three active documents and they are moving more slowly than expected. The working group is moving aggressively to remove unnecessary functionality. The wg is also requesting additional review to help identify any open issues. Finally, an interim meeting is planned to help speed progress. Joe Saloway presented for EMU. RFC2716bis (EAP-TLS) is in IETF LC. EAP-GPSK has completed working group review and will go to the IESG shortly. Charter revisions are under discussion to add a work item for an EAP tunnel method base on TLS to support passwords and other authentication methods. That discussion will continue on the list. Shawn Emery presented for Kitten. Most of the discussion was on the domain based drafts. A number of updates and enhancements are included in the new drafts, but some open issues remain. The wg is looking for both editors and reviewers to help get its documents to completion. If no editor steps forward for the C# bindings, that will probably be removed from the charter. Stephen Farrell presented for DKIM. They had a presentation on an interoperability event for the dkim base spec. Twenty organizations participated with good results, which is very encouraging. There was a presentation on the SSP specification which produced lively discussion. They hope to resolve the issues and close WG Last Call in January 2008. Several extensions to SSP were presented. The WG will consider these after the SSP document progresses. Tobias Gondrom presented for LTANS. The WG is looking to complete its work and wrap up a number of documents. SCVP's progression clears a roadblock for the ERS over SCVP document. DSSC has had only minor changes; XML-ERS has had more extensive revisions to align with the ASN.1 version of ERS. The Validate and LTAP documents are also near completion; the wg decide to specify an intended status of Experimental for LTAP since little implementation activity has been seen. Sean Turner for S/MIME 3 RFCs have been published since Chicago. 1 document (RSA-KEM) has completed WG Last Call, but IPR issues need to be resolved. CMC's completion in PKIX should result in publication of wg documents that are currently stuck in the RFC Editor's Queue. There are 4 active drafts in the WG; significant issues include whether ECDSA can be specified as a SHOULD in light of IPR issues. Steve Hanna for NEA. The NEA WG is nearing completion of its Requirements specification. Once the requirements are complete, NEA can commence work on the protocol specification. There was a presentation on MNEA - mutual network endpoint assessment; the wg agreed it was interesting but out of scope for the wg. The remaining time in the session was spent on updated milestones in anticipation of beginning protocol work. SASL, Tom Yu, Kurt Zeilenga Sam Hartman's AD review of GS2 identified some issues involving detecting channel bindings failures. Kurt Zeilenga's YAP document will proceed as an independent submission. The WG is looking at incorporating new concepts into SCRAM and supporting implementation as a GSS-API mechanism. WG Last Call has been issued for moving DIGEST-MD5 to Historic. Remaining milestones are being pushed out four months. MSEC, Ran Canetti, Lakshminath Dondeti There was progress on four work items, including crypto suites for GDOI, and extensions to GDOI for hash agility, GDOI for SRTP, and TESLA extensions. There are also several current work items that are not making progress and may need to be dropped. Some new work has been proposed to support keying for transport and routing protocols, but this work will not go forward unless it is clear that the appropriate WGs in transport and routing have consensus. If clear direction is provided, msec will consider a charter update for new work. Otherwise, msec will stay on course to complete its active documents and shut down. Sam Hartman: Important to confirms with OSPF, RSVP, that any work for them will actually be used by them and actually implemented. Lars Eggert (Transport AD): There is interest in having an informational document that describes the different keying mechanisms you could use for RSVP, but it is not clear that requires any immediate action from msec. Tim Polk: Presentation in TSVWG of a paper paired with one in MSEC is the kind of thing we would like to see in MSEC. We need that kind of coordinated work to ensure that we Dave Ward (Routing AD): No clear evidence that the OSPF WG is interested in the MSEC work. Sam Hartman: That is exactly the kind of feedback we need. Acee Lindem (OSPF WG Chair): Don't know if the proposed mechanism will help us but we do have a requirement to do automated keying. This does merit investigation. Hannes Tschofenig: Read through the MSEC document re RSVP. Something is needed but maybe not that. Charles Clancy provided a status update for the HOKEY working group. Hokey has five working group documents, with two sent to the AD for review. The EMSK keying hierarchy wording needs to be straightened out, then that document is ready for WG Last Call. The back end key management protocol document has issues with AAA proxies. The question is whether end-to-end security is required or if hop-by-hop security is sufficient. This completes the reports of working groups that have already met at this meeting. The following working groups will meet this evening or Friday morning. Love Hornqvist-Astrand presented a status update for BTNS. The Core and applicability documents have WG consensus. There are two more documents to go, and additional participation is invited! Jeff Hutzelman provided an update and meeting preview for the Kerberos working group. Kerberos has two documents in last call: hash agility for the GSS-API mechanism; and the problem statement for cross realm Kerberos. Last call has expired for the anonymity specification; comments will discussed during the meeting. There will also be a discussion of the pre-authentication framework and kerberos referrals work which is nearing completion. There will also be a discussion of plans for the next version of the kerberos specification Invited Presentations Sam Hartman: NDSS flyers are available at the front on the room after the meeting. We don't usually announce meetings but this one is sponsored by ISOC. A few meetings ago we had a presentation on why IPSEC isn't the right solution for routers, etc. People have been working on key management for BGP. But things are only important if they are deployed. We plan to have a BOF at the Philadelphia meeting next year that is focused on solving the automated key management problem. The specific targets are key management for the TCP security option and for BGP... but there are a lot of other applications that people want to address as well. Our goal is to lay the groundwork for successful BOF, and so we've arranged for presentations at this meeting to get people thinking about this stuff. Sandy Murphy, Brian Weis, and Joe Touch are going to make the presentations. Sandy is going to talk about the output of the design team. Brian and Joe will discuss some of the options for automated key management. Today's goal is not to determine whether they are right, but to ensure that people are thinking about this problem and determine what progress needs to happen before Philadelphia to have a successful BOF. Dave Ward (Routing AD): The routing area is strongly supportive of this effort, and will certainly participate in the BOF. The critical thing for the routing area is our deployment considerations. We will be producing a draft on the current state-of-the-state of how routing and signaling protocols are deployed and our current understanding of the (in)security of that deployment. The document actually hasn't been submitted officially yet, but should be available in time to be discussed at the BOF. The routing area is also unclear about the precise meaning of "automated key management" so presentations at the BOF that add clarity there would also be appreciated. TCP-AO Key Management, Sandy Murphy (See also slides in proceedings.) [This presentation describes the results of the design team. The design team has declared themselves done, and passed the torch to the TCPM WG.] TCP MD5 used an unsophisticated technique (suffix only), lacked algorithm agility, and re-keying, and did not cover the options. So the goal was to design a new mechanism that could coexist with TCP MD5. Limited options space was a particular challenge and limited some of the design team's options. One of the more energetic discussions was that a new key was required for every connection attempt. This could present operational problems in some scenarios, like connection attempts to an unstable neighbor. The alternative is vulnerable to SYN replay. The key management techniques were out of scope for the design team; that is what the BOF will be all about. The Key Manager, TCP Security Association Database (TSAD), and TCP itself have the primary roles in this system. Steve Kent: The option exclusion list seems qualitatively different from the other contents of the TSAD. Shouldn't this have been in a separate database? Joe Touch: Since there is only one index (the socket pair) it didn't seem useful to have two separate databases, even though there are differences in the types of data. The presentation resulted in very lively discussions. Many of the questions addressed fundamental assumptions of the design team. It was clear that a greater understanding of the operational requirements. Gregory Leibovitz volunteered to facilitate documentation of these requirements. Scoping also needs to be nailed down. Is the focus BGP and LDP or other protocols? Charlie Kaufman noted that TCP-MD5 fills a niche. It is very lightweight and easy to deploy with manual keying. At the other extreme is IPSEC with IKE. We have to be sure not to add too much complexity. Brian Weis presented "Simple Key Establishment Method for the TCP-AO". Availability is a key operational requirement; any solution must not decrease availability. There are simple key establishment methods with well known security properties that fall between IKE and TCP MD5. They should be explored and leveraged if they meet the requirements, rather than invent new mechanisms if possible. Two examples include Key Transport (encrypted key protected with a long-term KEK) and key derivation using a counter (derive a key from a master key and a counter). Joe Touch presented "TCP Authentication Option: Keying Management Provisions". There is another document that should be reviewed: draft-bellovin-tcpsec. This draft specifies requirements for a replacement mechanism for TCP-MD5. The design team decided to mandate a new key for a port pair to avoid adding replay protection. This helps keep the option small. By design, the entries should be added or deleted, but aren't ever changed. The design team believes two algorithms should be mandatory to implement (in case of a break) and at least one should be very efficient. Finally, the design team would like to see the TSAD support TCP-MD5 as well... whether the two mechanisms co-exist, and for how long, is still an open issue. Sam Hartman: What we need for a successful BOF is: A presentation with support form TCPM; requirements from the operator community that this fits; an understanding of the interface between key management and TCPM features. We will also need some proposed solution. Who will work on this? Lars Eggert (TSV AD): The WG process has taken over. The design team has been disbanded. Send mail to the TCPM list if you have comments. The plan is to leave this as a draft a bit longer, but they took a hum yesterday and there is a strong consensus in TCPM for the document. So, the current version is mature enough for review. EKR: Another fundamental question is whether key management should be supported in channel or through a separate channel. We need to review the requirements and determine whether there are operational considerations that restrict us to one solution or the other. Gregory Leibovitz noted that operational requirements fundamentally affect the rest of the design. Asking for solutions for the BOF may be premature. Tim Polk: Look at the TCPM document. If the BoF scope is too ambitious, it can be scaled back. Sam Hartman: Do people think it is desirable to have solutions going into the Philly BoF? There was a show of hands. About two thirds of those that expressed an opinion believed solutions would be desirable. Sam Hartman then asked: Should we postpone if we don't have solutions? The show of hands indicated most wanted to have the BOF regardless. Joe Touch asked if we should we be gathering requirements? Sam Hartman indicated that multiple presentations from different views would be better for the BOF than one presentation. Paul Hoffman: Another question that needs to be answered is "How many MAC bits do we need? 64? 128? 96?" This will change our set of possible solutions Stefan Santesson then presented "Enhancing Credential Selection in IETF Protocols". This was originally slated for PKIX, but was moved to SAAG since the the mechanism has applicability for other credential types. The problem is, most users have a set of credentials, so when a service requests credentials, the user may have several matching the criteria, but the user can only send one. How do they chose which credentials to use? Stefan's ID describes a scheme which in its most basic form looks for octet sequences in certificates treating the entire certificate as an opaque blob. There are extensions that could support more complex modes which parsed the data. The scheme could be used to select or prioritize credentials. In the discussion, it was noted that false positives are certainly possible. Since the scheme matches substrings without parsing the data, it is possible to match an ASN.1 OID in random text or data (e.g., a public key). It might be better to think of this as a heuristic or a scoring algorithm. There were significant questions about whether this is really a *good* mechanism... perhaps the more complex solution (parsing) is really worth the pain. There was some discussion that pursuing an X.509 only solution in PKIX might be better than pursuing a generic solution at this time. Adjourn.