CURRENT_MEETING_REPORT_ Reported by Antonio Fernandez/Bellcore and Mark Schertler/NSA Minutes of the IP Security Protocol Working Group (IPSEC) The IPSEC Working Group met during the 33rd IETF on Wednesday, 19 July. Paul Lambert chaired the meeting which was broadcast on the MBone. The meeting covered the status of the IP ESP and AH documents, a presentation and discussion about the Internet Key Management Protocol (IKMP) and a presentation of DNS Security Extensions (DNSSEC) to provide long-term keys on the Internet. Martin Patterson announced a SKIP BOF. Several implementations of SKIP have been developed and alignment of SKIP with ESP and AH is being discussed. The main purpose of the BOF is to get the people implementing versions of SKIP together. IPSEC Document Status The following IPSEC Specifications have been advanced to Proposed Standard: o Security Architecture for the Internet Protocol o IP Authentication Header o IP Encapsulating Security Payload (ESP) o IP Authentication using Keyed MD5 o The ESP DES-CBC Transform The IP Authentication using Keyed MD5 specification before it is forwarded to the RFC Editor will be edited to reflect Hugo Krawczyk's comments concerning having the prepended key padded with a one (1) and some number of zeros (0) to a length of 512 bits. Jeff Schiller, Security Area Director, will provide the official response to the comments received during the Last Call period. Several implementations of ESP and AH are being developed and an implementor's mailing list has been started. Contact Perry Metzger (perry@imsi.com) if you are an implementor and would like to be on the mailing list. Internet Key Management Protocol (IKMP) Currently IPSEC is considering two Internet Key Management Protocol (IKMP) Proposals: o Photuris o Internet Security Association Key Management Protocol (ISAKMP) Paul Lambert reviewed the IKMP goals and requirements. The IKMP mechanism must support the selection of security transforms and creation of session keys for ESP and AH. Algorithm, mechanism, and key exchange independence to provide migration for the future is also a requirement. IKMP should be general enough to be used by protocols developed in other working groups. Photuris The Photuris editors, Phil Karn and Bill Simpson, were unable to attend the IETF meeting. In their absence an open discussion of Photuris was held. Issues raised concerning the Photuris specification included the need to clarify the relationship between the security association definitions in Photuris and in the Security Architecture for IP specification. Another clarification required is how the SIGN exchange should be encrypted. The question of how Photuris would be used by a router acting on behalf of an end system was also raised. Internet Security Association and Key Management Protocol (ISAKMP) Mark Schertler, NSA Information Systems Security Organization (ISSO), presented the Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP is a flexible key management architecture that provides a common mechanism for security attribute negotiation, strong authentication, and session key establishment. ISAKMP is key exchange, authentication mechanism, and cryptographic algorithm independent. ISAKMP by providing a common security association (SA) establishment mechanism can be used by other protocols developed by the IETF that require SAs. This architecture follows the Security Architecture for IP, ESP and AH specifications lead. As was done in the IP Authentication using Keyed MD5 ESP DES-CBC specifications, a base KMP transform including a session key generation algorithm, authentication mechanism, and encryption algorithm must be specified. The Photuris session key generation algorithm is a good candidate for the base KMP transform. This is a possible way to utilize both proposals---ISAKMP as the Internet Key Management Protocol and Photuris as the base IKMP transform. The features of ISAKMP include: o A fixed field header that contains no security attributes making header parsing consistent and migration to new security attributes easier o Replay prevention using a time variant cookie o Initialization exchange to indicate base KMP transform or select other KMP transforms to protect SA and session key establishment o Strong authentication mechanism required o Support for multiple certificate authorities o Transport protocol independence Following its header, ISAKMP separates security information into discrete payloads based on the security information's function. The key exchange payload has a Key Exchange Identifier (KEI) which indicates the key exchange algorithm used. KEIs must be specified in a separate RFC and/or registered with IANA. The RFC would define the keying information and payload format to be exchanged with the protocol. The authentication payload identifies the Certificate Authority that issued the certificate. This is also an IANA issued identifier. The Authentication Type field indicates the type of authentication data (e.g., Certificate format). Finally the payload contains the authentication data that is used to authenticate the peer entity. The Security Association (SA) payload contains the security attributes being offered (request) or accepted (response) for the security association. Security attributes can be bundled together into a set (e.g., encryption - DES, hash - MD5, signature - RSA, etc.) or each attribute can be followed by a list of the acceptable options (e.g., encryption - DES, IDEA, 3DES). Either format has a field which indicates which security service the security attributes support (e.g., ESP, AH, or OSPF authentication). The SA payload supports the SA parameters defined in the Security Architecture for IP and allows for migration to SA parameters defined for future security services and mechanisms. ISAKMP defines protocol exchanges to establish Security Associations (SAs) and create session keys, modify SAs, delete SAs and transmit notifications (error messages and front-end synchronization). A concern was raised that the ISAKMP proposal has too much flexibility, too many combinations will make it impossible to understand all the security implications. Therefore, only a minimum of flexibility is required. Responses from the floor stated that we can not have only one solution (key exchange algorithm). Another statement was that we must choose one key exchange everyone implements for interoperability, but we must allow an open migration path and not tie ourselves down to a specific algorithm. The ISAKMP editors stated that ISAKMP is a protocol that supports many key management architectures, the Photuris key exchange is an example of a key exchange that fits into the ISAKMP protocol and can be defined as the must implement for Internet interoperability. Development of an ISAKMP prototype has begun and the developers are open to all suggestions. Initially the prototype will negotiate and place two types of security associations. The first an Internet SA utilizes either RSA with PGP certificates or RSA with RSA certificates for its authentication mechanism, the Diffie-Van Oorschot-Wiener STS (Photuris) for session key creation, DES-CBC for encryption, and MD5 for hashing. The second SA utilize algorithms form the Fortezza Card which are DSA with Fortezza certificates for authentication, Key Exchange Algorithm (KEA) for session key creation, Skipjack for encryption and Secure Hash Algorithm (SHA) for hashing. The developers welcome anyone who would like to develop additional security associations to contact them. The prototype is on SunOS 4.1.3, using gcc 2.6.x and running on UDP for the transport protocol. The schedule is to complete the prototype by 17 November and post the source code on the NSA Web Site (http://www.nsa.gov:8080/). The developer's future plans are to prototype an Internet security solution using ISAKMP, ESP, and AH. A model of ISAKMP has been developed using the Foresight modeling tool. This model will be used to perform vulnerability testing prior to prototype completion. DNS Security Extensions (DNSSEC) Donald Eastlake presented work being done on DNS Security Extensions (DNSSEC) and its relationship to IPSEC work. IKMP will create session (short-term) keys, but there is also a requirement for long-term keys. There are several sources for long-term keys, and one is the DNSSEC. DNSSEC includes provisions for associating long-term keys with users and hosts and also explicit provisions for indicating the protocols associated with the long-term keys. The public (long-term) keys can be signed (e.g., certified) and stored in the DNS. Thus the long-term keys are available on-line. DNSSEC supports a variety of key types requests. DNS is widely deployed in the Internet and having the entities being named linked to the domain names is a natural in the global Internet. Public alpha code will be made available soon (in the next few days) by Trusted Information Systems (TIS). The Internet-Draft which incorporates implementation experience thus far is available at: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-04.txt Future Work Items Paul Lambert concluded the meeting by presenting a list of possible future work items that the IPSEC Working Group should consider. o Management of security (ESP, AH, etc.) o Access control o Additional Security Transforms o Additional Security Exchanges o Multicast Key Management o 3rd part security (router like) o Naming o Cryptographic issues o MD5 security issues o True anonymity o Application issues