Editor's note: These minutes have not been edited. IETF 37, December 1996, San Jose IP Security WG (IPsec) Meeting Minutes Co-Chairs: Paul Lambert Ran Atkinson INTRODUCTION As is customary, Paul Lambert moderated the meeting. Paul first went over the agenda and charter. He displayed a list of the 20 current drafts and emphasized key management: ISAKMP, Oakley, and the IPsec DOI for ISAKMP. The ISAKMP/Oakley specifications are in WG Last Call that will end in very early January. Comments should be sent to the list. Jeff Schiller, IESG Security Area Director, pointed out that some of the IDs are already going to RFCs, and therefore not easily changed by the WG. STATUS OF DRAFTS AND RFCs (1) ARCHITECTURE DOCUMENT UPDATE (Presented by Steve Kent) He started with an introduction. The idea is to protect IP, whether in a host, outboard processor, or gateway. Router to router security, for example, can protect all of the traffic between two networks. IPsec Security associations (SAs) may be nested as well. A tunnel-mode SA can exist along with a transport-mode SA. The AH and ESP specs are now being revised. The AH sequence number for replay detection (optional to use) can be 4 or 8 bytes. The authentication data may be 16 or 20 bytes. The total AH size is 28, 32, or 36, which in IPv6 has to be 64 bit aligned (i.e., a multiple of 8 bytes). The notion of using SHA-1 with less than the standard 160 bits was not discussed here. In the proposed new unified ESP header (SPI, IV, sequence #, payload, pad, pad length, type, authentication data [optional and including padding]), particular feature combinations can be registered and used without writing a new document. IPSEC outbound processing can be complicated; the recommendation is that a processing selection function first look at source and destination addresses, next protocol, and ports (where applicable). The decision resulting from examining these items can be SA processing, bypass processing, or discard and audit. In the first case, an SA might need to be created. Packet selection parameters can include IP addresses, next protocol, ports, and sensitivity labels. The granularity can be a fully specified selector, * name selector, or ranges. Compliance specifications include protocol modes, mode combinations (e.g., nesting levels), administrative interfaces, and perhaps MIBs or some other administrative mechanisms. Nesting can accommodate both security gateway and end user security requirements. (2) HMAC SPECIFICATION STATUS (Presented by Hugo Krawczyk) The HMAC ID will become an informational RFC. Hugo had previously suggested using 128 bits of output from SHA-1. HMAC is also being used for key derivation. He recommends using a more substantial mechanism than the Oakley counter increment when this is applied repeatedly. He made another pitch for truncation of the SHA-1 HMAC output when used within AH. He also argued that the Novell patent is not an issue. Bellovin and Simpson supported truncation of the 160 bit MAC as well. Schiller will discuss this with Hugo and the WG chairs after the meeting. (The post-meeting conclusion was to truncate SHA-1 to 128-bits to avoid issues relating to 64-bit alignment; 64-bit alignment is mandated by IPv6 and IPsec is required to support/comply with IPv6). (2) COMPRESSION (Presented by Rodney Thayer and Bob Monsour) The talk covered (1) why compression, (2) two approaches, and (3) next steps. The presenters argued compression is important because compression must be at a higher protocol processing level than encryption if it is to be effective. They assert that compression might actually reduce CPU time when DES and MD5 are used and also assert that 2:1 compression is possible. The two approaches presented were (1) as an ESP feature and (2) as an orthogonal transform. The former causes compression to be tied into IPsec key management. They believe the sender could choose whether to compress each packet (e.g., based on packet size) on a packet-by-packet basis, one header byte indicates compression was done prior to encryption; for IP, it is memoryless. The one byte has a compress bit (used now) and history bit (unused for now). There was no clear explanation of where the "one byte" would come from and how this would be done such that existing conforming implementations would not be made non-conforming. The rationale for the the first approach is minimal overhead, minimal change, compression only needed when encryption is used. It is described in the two drafts: draft-sabin-esp-des3-lzs-md5-00.txt and draft-sabin-lzs-payload-00.txt. The second method, described by Rodney Thayer, added a new transform, allowed history, didn't change ESP, and could be planned to be deprecated later. The draft draft-thayer-seccomp-00.txt describes this. The header is 8 bytes: (next payload(1), type(1), options(2), identity(2), length(2)). Compressed data follows. The next steps would be to add compression parameters and algorithms to the ISAKMP DOI. During open discussion, Bellovin and Kent objected to adding the "one byte at the beginning". Some other comments were that much of the Internet is already compressed and that TCP level compression makes using history sensible. But this, it was said, does not help UDP. A straw pole indicated there is no current consensus on how to proceed. Further discussion was deferred to the IPsec list. KEY MANAGEMENT (1) ISAKMP Base Specification (Presented by Doug Maughan) The ISAKMP architecture now has ISAKMP relying on a separate (security-protocol-specific) DOI specification and a separate key exchange definitions (e.g. the Oakley resolution document). All the IPSEC specific information is in the DOI document. Another DOI could be written for TLS, SSH, or another security protocol. Also, this document approach permits the substitution of another key exchange for Oakley if that were ever desirable for some reason. The main changes in the ISAKMP base specification were described as: 1. ISAKMP header: version was expanded from 4 to 8 bits (major and minor); pre -06 it is (0,1), draft-06 is (1,0); exchange type field was expanded (4 to 8 bits), flags shortened a byte (no collate bit, added commit bit for key exchange synchronization); added a 32 bit message ID field to keep multiple phase 2 negotiations straight. 2. SA identification: the two phases are now clearly delineated and the process of filling in the fields and defining the keyid with the cookies or the SPI was clearly documented. 3. SA negotiation format: proposal and transform payloads were added; envelope payload and collate bit were removed. Proposal can negotiate entire protocol suites at once (logical AND) or multiple suites (logical OR). 4. Certificate and certificate request payloads: deleted CA information, shortened type to one byte, supports PKCS #7, wrapped X.509, PGP, DNS, X.509, and Kerberos tokens. CRLs and ARLs need to be discussed and resolved, as requested by Greg Carter. Certificate request payload can request specific certificate of CAs. 5. Exchanges: added nonce payload to base exchange and identity protect exchange; moved nonce payload in auth only; added aggressive exchange combining SA , KE, and auth. This consolidates unidirectional notify and delete in informational exchange. -06 had major editing in Sect 2; new 3.3, 3.10, 4.1, 4.1.1, 4.7, 5.4.1, 5.4.2, 5.8, and changes to appendices. (2) INLINE KEYING WITH ISAKMP (Presented by Bill Sommerfeld) The goals are to borrow technology from SKIP, assume 2-way communication, produce a lightweight child SA, keep the overhead to 100-200 extra bytes, avoid extra messages, and be compatible with ISAKMP-Oakley. Applications include per connection keying between hosts, per connection keying at tunnel endpoints, zero packet overhead for sporadic communications, and compatibility with RSVP (credited to Ran). The proposal starts with an existing SA; the initiator creates an inbound SA for the reply, and combines the SA creation notice with a request for the responder to do the same. It can use stock ISAKMP/Oakley or publish DH public values (as in SKIP). Consensus was to use ISAKMP/Oakley. The items required are: SPI, Nonce, IV, next payload, authenticator, sequence #, reply-creation goop, payload. A separate key is needed for protecting headers. There are two methods, one with 3 messages and one with 2 messages using Quick Mode. Issues are exact encapsulation of fat packet (ESP vs. new IP-layer protocol as in SKIP), short lifetime SAs, and MTU discovery. Bill solicited additional ideas and feedback; the proposal is still sketchy. A more detailed proposal will be published before the Spring 1997 IETF meeting. (3) GKMP AND MULTICAST KEY MANAGEMENT (Presented by Hugh Harney) The goal is to make ISAKMP work well with IP Multicasting by adoption of GKMP-derived extensions into ISAKMP. Requirements include support for: ATM and IP style multicast groups, mutual suspicion, re-keying, group compromise recovery, non-compromising "leaves," and late joins. ISAKMP defines only pairwise SAs. With groups, the other endpoints are not clearly identified. Keys are usually "handed out." Algorithms and group permissions also have to be defined. See the two GKMP Internet-Drafts. The standalone GKMP specification is pending as an Informational RFC. The ISAKMP/GKMP work is intended for the standards-track and will be undertaken within the IPsec WG. IPSEC-RELATED APIs (1) SIMPLE IPSEC API (Presented by Dan McDonald) He described the contents of his Internet-Draft (draft-mcdonald-simple-ipsec-00.txt), which specifies IPsec extensions to the BSD Sockets API. Most of this work was done at NRL and is available in every public snapshot of the NRL IPv6+IPsec code (http://web.mit.edu/network/isakmp/) These extensions apply to both IPv4 and IPv6. The API implements the notion of a "Security Level" and the notion of a "Security Category". A Security Level value is associated with each Security Category in an array. The system administrator can configure a system-wide minimum security level value for each security category. An IPsec-aware application can also request a particular security level value on its socket(s). If the system security level and the per-socket security level are different, the more paranoid setting is used for traffic to/from that socket. The API uses Socket-options to set the levels. Possible Security Level values implemented in the NRL code include: None Use IPsec if it is available, Must use IPsec on outbound traffic, Require IPsec both inbound and outbound Require IPsec both inbound and outbound, and require that the IPsec SA be session-oriented rather than host-oriented Possible security categories are: AH (transport-mode), ESP (transport-mode), and ESP (network-mode) A revised version is expected to be published before the Spring 1997 IETF in Memphis. Dan solicited other comments to be sent to him via email. (2) PF_KEYv2 KEY MANAGEMENT API PF_KEY is a BSD Sockets API used for key management services. It is not limited to IPsec, but can be used for any sort of key management (e.g. RIPv2 MD5, OSPFv2 MD5, RSVP MD5). The general notion is that the key management protocol is implemented as an application-layer daemon outside of the kernel. This daemon communicates with the kernel via the PF_KEY API. The kernel can send up requests for new SAs and the daemon can send new SAs down into the kernel after they are established. PF_KEYv1 is implemented in the NRL IPv6+IPsec software distribution and is supported by the cisco ISAKMP+Oakley daemon, for example. Parts of SKIP could also be built using PF_KEY. This was not a formal presentation. Someone in the audience asked about status of this document. Dan McDonald, one of the PF_KEYv2 authors, responded. Dan reported that there are some unresolved comments that need to be resolved before this can be published as an Internet-Draft. He hopes to have this out before the Spring 1997 IETF in Memphis. INTEROPERABILITY The IPsec Implementation Survey is being recirculated and should be sent out to the list again thereafter. The AIAG plans to sponsor multi-vendor IPsec interoperability testing during the Spring of 1997. OPEN ISSUES IPSEC MIBs (controversial because of missing SNMP security), How to deal with compression, MAC truncation (raised by Hugo), ISAKMP CRL and ARL distribution (supported by Kent and Wiener) ----------------------------------------------------------------------