IPsecME WG meeting 2014-03-05 (1300-1500) Peter Yee, minute-taker Charter Revision – Paul Hoffman The IKEv2 fragmentation draft has recently gone into IETF LC. The crypto requirements (MTI ciphers) for AH and ESP draft has gone into WG LC. And the IKEv2 signature authentication draft will hit IETF LC shortly, once Paul gets it moving again. Tero Kivinen notes that he has to fix some examples in the appendix, so there are already comments to be submitted during the LC. There was not enough WG interest in doing a single AD VPN proposal. This topic will be considered dead within the WG by the end of the week, although individual submissions might resurrect it. Tero Kivinen stated that the multiple drafts on the topic each had multiple authors to the point that all interested parties were tied up with one proposal or another. That left a dearth of active reviewers. Kivinen doesn’t think a bunch of under-reviewed individual submissions is a better situation. Rather, he would prefer fewer co-authors on documents so that there is a larger pool of independent (or at least not outwardly aligned) reviewers who could look over the set of drafts. Mike Boyle apologized for not submitting comments, but admitted that they remain interested. Paul said he felt uncomfortable extending the request time for document input, but that shouldn’t stop individual submissions to which comments could be supplied. That doesn’t mean that opinions on the existing drafts shouldn’t be submitted to the WG mailing list. Sean Turner said that the WG should not waste time if the disparate parties cannot agree on a way forward. Lou Berger asked if there was consensus on not working on this problem? Hoffman indicated that was not the case; there’s at least one vendor shipping such a product. He clarified that there was interest in the problem, but no apparent interest in working together to produce a unified solution. Kivinen stated that two of the three proposals had roughly split the WG between them in terms of support. Those two have different approaches and could probably co-exist if it came to that, regardless of their standardization status within the IETF. Frederic Detienne (a co-author of one of the proposals) said that he thinks the requirements are too bloated and that only vendors with existing implementations would meet the requirements (which were derived from their feature list). A reduction of the requirements would likely be helpful. Detienne will submit his ideas for this reduction to the mailing list, although he does feel that discussing the topic within a meeting can also be helpful despite how much time has been wasted in open session on the topic. Perhaps a design team meeting rather than a full WG meeting would be the way discuss the topic. Yoav Nir (a member of the “other” group) agreed with Detienne that you can make different assumptions about the environment for which the solution applies and then end up with quite different proposals. A single set of requirements that was smaller would help. Hoffman asked Nir to bring his list of requirements to the list. Detienne’s and Nir’s lists might turn out to be similar. Lou Berger followed up Nir and Kivinen’s comments. There was a bifurcation in the votes. Berger said that Nir was correct, there were two separate sets of requirements based off of two very different operating environments. Perhaps, as Kivinen said, there was the possibility of having one solution build off of the other. This path has not explored. A layered solution could match layered requirements. Hoffman feels there is more interest in this approach. There will definitely be a design team meeting or two before the Toronto IETF meeting. Berger would like those meetings to be open to the whole WG, while Hoffman feels that a meeting of the authors would probably be more productive. If the design team can arrive at consensus, then the WG would consider pursuing the topic again. Kathleen Moriarty (incoming Security AD) asked if one of the proposals was strictly a subset of the other or whether there was a common core between them. IPsec in Constrained Environments – Tero Kivinen Constrained environments are those with small devices (power, CPU, and/or memory) and could be sensors, actuators, smart objects, or smart devices. The LWIG terminology gives three class of devices based on data and code size. Of the classes, only class 2 would likely be suitable for use on the Internet. Security is required for these devices given that some of them are used in life critical situations. Most current devices use proprietary security schemes of questionable strength. Some of the time, security is done only at the link layer (e.g., IEEE 802.15.4 although there is no key management). Vendor proprietary solutions may use shared keys or vendor proprietary keys. A few devices use TLS/DTLS, but IPsec doesn’t appear to be widely used. IEEE 802.15.9 is adding key management to IEEE 802.15.4 using existing key management protocols. IKEv2 is one of the key management protocols that will be carried over IEEE 802.15.9, which seems to make, in combination with AES-CCM link encryption, the possibility of doing IPsec for end-to-end security. Smart Energy/Grid do or can use IPsec for their security as well. IPsec is actually a pretty small protocol when stripped of optional features. It can protect anything running over IP and can be used in nodes that sleep most of the time. On small devices, implementation is fairly simple and doesn’t require concerns about a kernel and application split. Sean Turner asked how revocation/status checking works in small devices. Kivinen says that he small implementation doesn’t do that; frequently in small device deployments, raw keys are used and revocation is done by manually removing the device from an access list. Frederic Detienne said that customers aren’t interested in using PKI because they think they have to deal with the full revocation scenario. He believes that a non-revocation-using PKI implementation is still better than just using pre-shared or vendor built-in keys. Brian Weis asked where sensors were being used in an end-to-end scenario. Kivinen said that sensors using CoAP might be talking to a server several hops down the line, not just on the local network segment. Daniel Migault says that his company is interested in this model of operation. Diet-ESP: A flexible and compressed format for IPsec/ESP – Daniel Migault The idea is to use ESP with the “extraneous” bytes removed. IPsec using ESP has an 18 byte overhead per packet. The Diet-ESP scheme has no per-packet overhead. This is done by removing the SPI, sequence number, padding, pad length, and next header. By making assumptions about the environment and negotiating some values at the beginning of an association, these removed values can be handled implicitly and not transmitted in every packet. For example, if the network is only handling one application, the Next Header and UDP header are unneeded. If 8-bit alignment is coming out of the application, then there’s no need for padding and padding length. If there’s only on IP connection, the SPI is unneeded. If there isn’t a risk of replay, the sequence number can be deleted. Yoav Nir and Frederic Detienne believe that the sequence number should not be removed. Daniel Migault clarified that the WG is asking that the sequence number be kept mandatory. Steve Kent said he was in favor of shrinking things down, but he’s concerned that the removal of certain values will make it easier for application developers to make poor choices that end up compromising security even though IPsec is apparently in use. He notes that padding is there because IPv4 required 32-bit alignment. Hoffman said the WG will have to decide if it wants to take on this work. Yoav Nir said that there is already IPsec over ROCH, so why not this. Yaron Sheffer wondered about the number of skinny ESP proposals we have before the WG. Minimal ESP – Tobias Guggemos This proposal looks at how to simplify ESP implementation. It discusses the specifics of how the Diet-ESP proposal would be implemented along with choices in things like encryption algorithms to reduce the need for padding and IVs. Paul Wouters clarified that these devices still used IKE and then ESP. He wondered why they didn’t just propose an IKEv2 payload. Tero Kivinen said that the slides show how to implement ESP in small devices. Minimal IKE wouldn’t allow the use of IKE payloads. He feels that minimal ESP is easier to use than minimal IKE in this context. Steve Kent feels that if fields weren’t eliminated and choices were just made on things like algorithms, then using the same ESP protocol number would be fine. But if mandatory to implement fields are dropped, a new protocol number would be appropriate although difficult to obtain. Frederic Detienne asked if the authors had considered connection latching. This also eliminates the need for a next header and is defined in an existing RFC. This work is taking place in the LWIG WG. Tero feels that this might be interesting work for the IPsecME WG. ChaCha20+Poly1305 for IPsec – Yoav Nir ChaCha20 can be used with ESP, while Poly1305 can be used as the MAC for AH and ESP. The two algorithms can be used together as an AEAD algorithm in ESP. Nir wants to know if the WG is interested in adopting this work. Tero Kivinen thinks it would be fine to take on this work, although he’s only interested in the combined ChaCha20/Poly1305 mode. He’s not particularly interested in the separate MAC and stream cipher algorithms by themselves. Brian Weis asked why there was a lot of use of little-endianess in these algorithms instead of network byte order. Hoffman noted that this issue arises from DJB’s designs and it has been discussed in the CFRG. The names may have to be changed if usage is aligned with big-endian Internet. Hoffman sees a fair amount of interest in this work, here and in the CFRG. It will probably be taken up by the WG. Kevin Igoe pointed out that urgency in using ChaCha owes much to the untimely death of RC4. Yaron Sheffer points out that ChaCha was submitted to the eStream competition. [ Later corrected to "...Salsa was submitted to... ] The AutoVPN Architecture – Yoav Nir This draft is a proposal for how to do opportunistic IKE/IPsec between two gateways, even when not explicitly requested. This would protect devices (that don’t do encryption for themselves) behind the gateways. It uses ICMP to discover peer IPsec entities. Self-signed certificates are used, although offline authentication can be done as an option. Use of the AutoVPN is transparent to the end points; the gateways handle the setup by themselves if they see end points trying to communicate across the gateways. WG feedback is desired. IPsec “Opportunistic Encryption” – Paul Wouters This is a different approach to doing IPsec opportunistic encryption. It is based off of public keys published into DNS and protected with DNSSEC. DNS A/AAAA lookups also trigger a lookup for an IPSECKEY RR. An IPsec tunnel is setup prior to returning the A/AAAA record to the application that did the DNS lookup. Thus, when the application starts communicating with the remote party, IPsec is now in place. A prototype implementation based on libreswan exists. There are some open issues, however. Multiple A/AAAA records is problematic as it would imply multiple tunnels being set up. Unlike the AutoVPN proposal, this proposal does not support gateway-to-gateway protection. It involves IPsec between the nodes that actually wish to communicate. Steve Kent asked that since this was based on using DNS to get keying material, was there a possibility of using DANE? Wouters said this was in essence DANE or very close to it. IKEv2/IPsec Context Definition – Daniel Palomares This is work that Orange Labs is doing around clustered systems in which they would like IPsec to be available even with when fail-over is used to provide high availability. RFC 6311 and 6027 deal with this scenario. Palomares draft deals with how to list the IKEv2/IPsec parameters and their associated level. It does not deal with the format of the parameters.