CURRENT_MEETING_REPORT_ Reported by Randall Atkinson/Naval Research Laboratory Minutes of the Internet Protocol Security Protocol Working Group (IPSEC) Paul Lambert and Randall Atkinson jointly chaired the meeting of the IPSEC Working Group in Danvers, MA. Randall Atkinson is now co-chair and will continue editing his three IP Security documents. Five documents are in working group last call through Monday, 4/10. Aside from defining the packet formats and overall architecture, the other tasks of the working group involve first specifying mandatory key management, which is public-key based and has flexible association management. After that, Security Association Management and Multicast Key Distribution are planned work items. IPSEC Document Status and Work Plan draft-ietf-ipsec-arch-00.txt draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-auth-00.txt draft-ietf-ipsec-esp-des-cbc-03 draft-ietf-ipsec-ah-md5-02.txt Several editorial clarifications have been requested on the above documents. Comments made during working group last call are being sorted out and any needed changes will be addressed. These five drafts are moving toward Proposed Standard very soon. They cannot progress to Draft Standard until after interoperable implementations exist. At least two independent implementations of the above are well underway. It is expected that at least one freely distributable implementation will exist, though this is not an IETF requirement. Internet Key Management Protocol, Background and Review There is long-standing consensus within the working group that Key Management will be application layer, independent of the IP layer, and based on public-key technology. Eventually, other technology approaches (e.g., Kerberos) might also be supported. Key management includes authentication of peers, generating session keys, and managing Security Associations. Near term goals are: Public-Key session key generation, attribute negotiation, and leaving hooks for growth. Deferred items include: multi-party key management, maintenance of existing Security Associations, Peer Discovery and Authentication, Error Recovery. IKMP Requirements There is working group consensus that the mandatory-to-implement Internet standard key management approach must provide the property of ``Perfect Forward Secrecy,'' and will use a ``Hybrid Diffie-Hellman'' technique (avoiding the well known `Man in the Middle' attack by using signed keys from the DNS). The working group base document for this mandatory-to-implement specification is Phil Karn's ``Photuris'' Internet-Draft. Karn is the official editor for this official working group draft on session key exchange. Other approaches that are not mandatory-to-implement might be considered later by the working group if there is working group consensus to have multiple standards-track specifications. There was clear consensus within the working group that the ``STS'' technology used by Photuris was a good approach to use. Photuris Overview Phil Karn (Qualcomm) presented a synopsis of the differences between his December 1994 draft of Photuris and the current specification. The Photuris protocol is designed for efficiency with respect to exponentiation and round-trip times. It uses cookies, hybrid Diffie-Hellman (DH), and digital signatures. Cookies are used to reduce risk from denial of service attacks. The Diffie-Hellman component uses a single 1024-bit prime. Hilarie Orman (U. Arizona) has suggested an alternative that uses elliptic curves. Photuris might also support a list of primes. The Security Parameters Index (SPI) should be random. DH computation can be done in parallel by the two sides. RSA digital signatures are used to sign the public values. Pre-signing vulnerabilities (see Diffie et al., 1992) have been addressed. The responder is passive, and timers are used. Slow responders may need to queue protected packets. A suggestion from Bellovin and Herzberg is that signatures might need to be encrypted. Five messages comprise the protocol. The session key is an MD5 of cookies, DH secret, and SPI. Keys are unidirectional; there is a different key for each direction. At present the algorithm can generate keys for at least IDEA, keyed MD5, and DES. Suggestions for ``Triple DES'' were offered. Signatures are done with RSA on the MD5 of two Diffie-Hellman public values and the Diffie-Hellman secret. This is an improved version of van Oorschot's Station-to-Station (STS) protocol. It is necessary to require signing something fresh. Photuris runs on a well-known UDP port. The Assigned Numbers are used for the security encapsulation protocols and ports. A new ICMP message is used to report problems: unknown SPI, authentication failed, encryption failed. This does allow certain denial of service attacks, since ICMP is not protected. The idea is to be able to re-key frequently. Re-keying can be optimized by remembering the DH result. Metzger suggested re-keying based on volume versus elapsed time. Bellovin pointed out that re-keying must not break existing TCP connections. IBM's Photuris Hybrid Hugo Krawczyk (IBM) presented his ideas on a protocol similar to but different from Photuris. He said that Photuris was a good basis, but forces a single execution path: Diffie-Hellman exchange and Public-Key signature. It might be desirable not to have to do both of these each time. Non-Public-Key models exist: manual, trusted third party, or pre-shared keys. These may lack Perfect Forward Secrecy, which he said Diffie-Hellman could add. He claimed that if secrecy was not needed, Perfect Forward Secrecy is not meaningful. The claimed performance improvement is 2X to 7X. Finally, he claimed a way to improve Photuris for fast re-keying based on a constrained set of SPI values, without Public-Key or Diffie-Hellman. His protocol allows non-Public-Key, skipping the Diffie-Hellman, or fast and light re-keying. It is really four different protocols in a single specification, where the default equals Photuris. Cookies are identical. Sharing is PK based with nonces and XOR. A-->B: E sub B(id sub A, K sub 1), nonce sub A B-->A: E sub A(K sub 2), nonce sub B, MD5 sub K sub 0 (nonce sub A, nonce sub B) A-->B: MD5 sub K sub 0 (nonce sub B, nonce sub A) K sub 0 == K sub 1 XOR K sub 2 Authenticated DH uses keyed MD5. Exchange g^x, g^y and use MD5 sub K sub 0 to authenticate. Not using Diffie-Hellman involves replacing Diffie-Hellman values with nonces (which use is apparently patented by IBM). It assumes a pre-shared key. The additional techniques can be added independently to Photuris. Technique selection can be combined with transform selection. Field lengths depend on mode. Symmetric key encryption is not required. Hugo stated that IBM claims intellectual property rights (patents) on some or all of the techniques described by Hugo. Jeff Schiller (IESG Area Director for Security) said that Karn's Photuris has nothing patented beyond DH and RSA and noted that the IETF generally avoids the use of patented techniques wherever possible. The STS technique by van Oorschot will not be patented. Lambert speaking as IPSEC co-Chair requested further clarification from IBM on their patent claims and proposed licensing. There was consensus in the working group that patented technology will be avoided if at all possible. NSA's ``Internet Security Association and Key Management Protocol (ISAKMP)'' Mark Schertler (US National Security Agency) presented an overview of the ISAKMP proposal that was recently made available as an Internet-Draft. He said that he is part of the ``Information Systems Security Organization'' within NSA (as are B. Patrick and D. Maughan, co-authors of the Internet-Draft). NSA is interested in working with the IETF standards process because NSA wants to provide current, commercial products to government customers. Their flexibility requirements are: attribute negotiation, mechanism interchangeability (key exchange, authentication, encryption algorithms), extensibility for future. Their components are anti-clogging tokens (Karn), authentication, association management, and key exchange. They defined scenarios and packet formats. Keying may be host-to-host or user-oriented. They believe that we need host and user certificates to name principals. Many Certification Authority structures already exist. Examples of existing Certification Authorities include but are not limited to the Domain Name System, Privacy-Enhanced Mail, RSA Data Security Inc., and the PGP web of trust. Also, there are different certificate formats in existence today. NSA has defined a data structure with an authentication authority (IANA-based), authentication type (e.g., certificate format), length of authentication data, and actual authentication data. Security Association Management Protocol (SAMP) functions needed include: attribute negotiation, commit, modify, and delete. Negotiation may be by attribute (see NetScape) or by sets of attributes (see PEM). Commit synchronizes; delete is informational. The Security Association Management payload includes an indicator, flags, and Security Parameters Index (SPI). Security Association Attributes have common syntax and are registered, somewhat like MIBs, with IANA. Supported key exchange systems include Diffie-Hellman, The Station-to-Station Diffie-Hellman technique of van Oorschot, ANSI X9.42, RSA, Photuris, KEA, and classified techniques. The Key Exchange Identifier (KEI) would also be also registered with IANA. Security Association Management scenarios may be defined according to security needs. For example, Establishment might be: 1. authenticated clear setup, 2. authenticated protected setup, 3. negotiated clear setup, 4. negotiated clear setup with anti-clogging, 5. anonymous, or 6. anonymous with anti-clogging. Some of the above six might be mandatory to implement. A general packet format is needed to define SPI, scenario, and payload (ISAKMP) type. The NSA approach strives to be modular, flexible, and extensible. NSA will be setting up a Web site later this Spring on the Internet, but the hostname was not yet known. Tsuo asked what the overhead would be if ISAKMP were used. Mark replied that the current negotiation is at most four exchanges. Sun's SKIP Key Management Approach Ashar Aziz (Sun) presented his SKIP key management protocol to the meeting. This uses certified Diffie-Hellman public values, which need to be computed once per pair. Users exchange ephemeral DH values and authenticate by applying the long-term, pair-wise DH value as key for a Message Authentication Code. He claims SKIP has Perfect Forward Secrecy, one real-time exponentiation per side, anonymity, strong authentication, and deniability. His claimed advantage over Photuris is efficiency. This assumes less than full size exponents. Elliptic curves can be used. The SKIP-like, zero-message key setup (certified public DH values) is also possible. Karn indicated this is closer to Photuris than to Hugo's proposal. Hugo indicated it is a subset of what he is doing. It was pointed out that none of the methods required RSA, since other signature schemes exist. Sun has filed for a patent. The SKIP implementation will be publicly available, even though it uses the BSAFE toolkit, rather than the no-cost RSAREF toolkit. An Issue With DES-CBC When Used Without Strong Integrity Steve Bellovin (AT&T Bell Labs) described a vulnerability present if ESP is used with a block-chaining encryption algorithm when a strong integrity mechanism, such as MD5, is not in use. Assume that host-oriented keying is being used between a pair of multiuser machines and that the attacker has an unprivileged login on both machines. Also assume that attacker can inject messages, for example via a PC on the LAN segment. If these assumptions hold, there is a cut-and-paste attack on UDP messages. This attack allows one to read traffic sent by another user between the two machines. Similarly, an active attack can paste data into another association. The danger comes from shared keys and no mandatory integrity check. Thus, encryption should not be used unless there is strong integrity present. Summary of IKMP Discussion, Review of Group Decisions and Requirements Bob Moscowitz asked which methods require packets too long for UDP. All proposers are to make this more clear in their next drafts, if any. Ran stressed the importance of making progress very soon not only with the packet formats but also in session key exchange. The discussion focused on additional points of consensus, e.g., for fast re-keying without DH or signatures without RSA. Bellovin asked about upgrading existing Security Associations. There was rough consensus that the working group will refine Photuris and then put out Photuris as the mandatory-to-implement session key exchange protocol. Karn is officially designated as the document editor for Photuris. The goal is to have Photuris out as a Proposed Standard by the end of the summer. It is not clear if the IPSEC Working Group will meet in Stockholm. It depends partly on whether enough working group members are able to attend. Ran Atkinson noted that it was unlikely that he could attend a Stockholm meeting.