IPsec WG Minutes Monday, March 19, 2000 Taken by Barbara Fraser Agenda Bashing IPSEC MIB documents: These documents will be going to wg last call in two weeks. They've been posted for awhile and there has been little or no discussion on them. Ted Ts'o urged those who did have comments to send them in asap. John Iannodis: pointed out that there is a 3GPP draft out that folks might be interested in IPSEC and IPV6 1. Jari Arkko presented the draft on Effects on ICMPv6 on IKE and IPsec Policies. This draft covers a problem with circular icmp traffic. 2. Jari Arkko also presented the draft on Manual SA Configuration for IPv6 Link Local Messages. Analyzed of icmpv6 security implications. Table presented that showed control functions against weak and strong attackers at low and high levels. DoS for weak attackers under higher layer security; man in the middle, spying, and impersonation for all attackers under no higher layer security; identity selection in all situations, if stateful... He presented possible ways to reduce the configuration effort which was about twice the SAs as the number of nodes. Comments: Dan McDonald draft on link shared secret, presented in Adelaide to the v6 group and it could be dragged back up to help with the manual configuration. Steve Kent suggested that we need a more complete story in order to motivate people. We'll need more discussion on the mailing list to see how to proceed with both of these. 3. Tissa Senevirathne presented draft-tsenevir-smpls-doi-00.txt draft-tsenevir-smpls-doi-00.txt draft-tsevevir-smpls-oo.txt MPLS is considered as secure as atm and frame relay but there is no evidence that these aren't being attacked. Currently have multiple encapsulation: foo/IP/IPsec/MPLS/... Payload encapsulation formats differ in that the next header field is not being used. For the SA, they're using IKE over RSVP (no additional control channel needed and a new RSVP object defined) and separate IKE channel (allows scaling, simpler implementation, but may not provide PFS) Comment that MPLS security is not an IP protocol and hence it doesn't belong at the IETF. Tissa replied that this is the sub-IP layer that the IETF is forming. Tissa also said there wasn't much security expertise present in the MPLS wg. Ted said that a similar issue has come up with IPv6 addressing which will be discussed in SAAG. Tissa: is it ok to run IKE over RSVP? Suggested that he raise this question at the SAAG meeting. A. D. Keromytis, On the Use of SCTP with IPsec draft: SCTP is a Transport protocol that supports multiple addresses for source and destination. Covered the issues related to IPsec. SAs will need to be specified by a set of addresses SPD: processing for the entries will have to support sets of addresses IKE Phase 2 IDs: a couple of problems with several solutions which the working group will need to agree on. IKE phase I IDs and certificates: if using certs, it's possible for two hosts to verify each other's addresses with the info in the certificates. Certs will support multiple addresses but they'll need to be handled. The draft makes suggestions about changes to the architecture as well as to IKE. Only a handful of people said they had enough understanding in order to get consensus at this point. Ted asked that A.D. post a clear list of issues to the list for discussion. IPSEC and NAT William Dixon presented draft-stenberg-ipsec-nat-traversal-02 and draft-huttunen-ipsec-esp-in-udp-01. The two groups have been working together to arrive at a consensus proposal. Of course the first question is if people think NAT will even be needed with IPv6. Question: Is the internal IP address being exposed a legitimate security concern? The current draft it can be actively queried by active negotiation, can be discovered by man in the middle; and using discover payload of IP address hash makes IP discoverable passively. UDP encapsulation done during phase 2; encapsulation attribute expanded to allow for new UDP encap option but would like a better answer in son of IKE attribute negotiation; send original real IP address in IKE notify Described what the encapsulation would look like. See draft. What about AH? It gets very messy and the authors would rather have agreement that having IP address info in the header is ok. Keepalives: for the purpose of keeping the NAT mapping alive, it's not the same as the IKE keepalives discussion. The intellectual property issues are resolved so the drafts are moving forward. Question: what about the patent posted in Europe? SSH has one patent and has a new one coming that is about determining if a NAT is present. Request that the patent application be posted to the list. Answer: it's on the IETF web page. Is the reason we have the cookie mechanism to have 1 rather than 2 ports? Answer was yes. New draft with new name will come out in the next couple of weeks. Son of Ike discussion Ted introduced the discussion with the following ground rules: This is to fix bugs in IKE, not an invitation to add arbitrary features. While we may be talking about bumping major versions numbers, there is a lot of installed base so people will be supporting old IKE and new IKE. Changes will need to be implementation preserving. About twice as many folks felt we did need implementation preservation than not. Dan Harkins presented his ideas for Son of IKE Combine the three into a new draft and deprecate the other three. Why? A lot of folks just don't like IKE, unnecessarily long and hard to read. Duplicate verbage in the docs would be eliminated. IKE has received some crypto analysis and no flaws (unlike WEP and PPTP) and there is wide industry acceptance. It does work. Even though it's very flexible, it hasn't been used so the question is are all these layers necessary. To combine them, we lose the layer violations, less ambiguous and more internally consistent, no repeated text. We also lose the general framework. New group mode? aggressive mode? ISakmp exchange... Advancements in the state of the art (out with DES and in with AES); suggestions for protocol improvement can be considered. Discussion: more interoperabiity among deployed systems is a main objective. smb: It will probably simplify the document even though it may not reduce the code base. There is a risk in characterizing the issues. At the last bakeoff there were still a number of IKE issues. Clarity, extensibility. Taro sent the issues to the list after the last bakeoff. The problem is complexity. Refocus by focusing on the state machine and the bulk of the problems will go away. Rewriting will not solve some of the problems so why don't we leave IKE as it is now with a strict set of problems and start over with a new protocol.??? didn't understand this. Concern that if Dan takes out everything that is problematic, there will be problems. Instead, keep it in but add text that says why it's there and what the issues are. AD: even if we did nothing else than clarify the docs we would have done well. Starting over may not be a good idea and we don't have enough people in the room who are developers to be able to determine this today. Reduce some of the choices that nobody uses; discuss the core set of options that folks are really using. There are areas that are underspecified, e.g., negotiating lifetimes. We could document the types of things that are giving us headaches. Keepalives and XAUTH were sort of shoehorned in, but we might be able to solve these problems with better solutions. Ted: There are have been various strawman proposals for heartbeats, birth certificates, death certificates... For some of these narrow areas it might make sense to use multiple IDs to flesh out the ideas and approaches. Once baked it can be incorporated into the new IKE draft. Someone to keep track of all the places where we've made a change from the original IKE. Could be an ID, or an internal working group document. Ted went through the items that were posted to the list in the past couple of days. Comment that SCTP be addressed as a mod to current IKE so that it doesn't get stalled behind the son of IKE work. Suggestion to advance the elliptic curve draft and the config mode draft to solve the IANA number issue? Ted: no wg consensus. Comment suggesting that we look forward when making changes.