Hello Tero, Regarding charter item 4 (mitigating privacy concerns), I have submitted the following draft:
https://tools.ietf.org/html/draft-dschinazi-ipsecme-sa-init-privacy-addition <https://tools.ietf.org/html/draft-dschinazi-ipsecme-sa-init-privacy-addition> I'd like to discuss the problem statement and potential solution in London. I would personally recommend not deciding on its addition to the charter until this has been discussed. Thanks, David Schinazi > On Mar 4, 2018, at 12:18, Tero Kivinen <[email protected]> wrote: > > There was very little discussion about the "ready" parts of the > charter (one comment from Wouters, but no new text or explination why > "mesh" is different than host-to-host. > > Additional items: > > > Item 1 responder MOBIKE > > We had some discussion already on the list, and several people > commented (Paul Wouters, Hu Jun) that they do want to have > more discussion about the goal before going to the the > solutions. I also think that the item is not well enough > explained in the charter that we can work on it, so perhaps we > leave this out for now and continue discussion in the list and > in the next meeting about what we really want. > > Item 2 Address Failure Errors > > We got some support (Michael Richardson), and Paul Wouters > wanted to have more discussion about this. I myself think this > is clear enough and we can add it to the charter. > > Item 3 Labeled IPsec > > We had concerns (Yoav Nir, Valery Smyslov) that this should > not affect implementations which do not implement this, so I > think the charter item should be modified to explictly say so. > I.e., add text which says there will not be any need to change > old implementations. > > Item 4 Mitigating privacy concerns > > We had very little support for this and some concerns about > this getting in the arms race with goverments etc. I myself do > not think this item is ready yet to be taken as charter item, > we need research on this before we can actually start working > on the protocol changes. > > ---------------------------------------------------------------------- > > This means the final proposed chater would be: > > ---------------------------------------------------------------------- > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec > security architecture (RFC 4301). IPsec is widely deployed in VPN > gateways, VPN remote access clients, and as a substrate for > host-to-host, host-to-network, and network-to-network security. > > The IPsec Maintenance and Extensions Working Group continues the work > of the earlier IPsec Working Group which was concluded in 2005. Its > purpose is to maintain the IPsec standard and to facilitate discussion > of clarifications, improvements, and extensions to IPsec, mostly to > ESP and IKEv2. The working group also serves as a focus point for > other IETF Working Groups who use IPsec in their own protocols. > > The current work items include: > > IKEv1 using shared secret authentication was partially resistant to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will add a mode to IKEv2 or otherwise > modify IKEv2 to have similar quantum resistant properties than IKEv1 > had. > > Split-DNS is a common configuration for VPN deployments, in which only > one or a few private DNS domains are accessible and resolvable via the > tunnel. Adding new configuration attributes to IKEv2 for configuring > Split-DNS would allow more deployments to adopt IKEv2. This > configuration should also allow verification of the domains using > DNSSEC. Working group will specify needed configuration attributes for > IKEv2. > > Currently, widely used counter mode based ciphers send both the ESP > sequence number and IV in form of counter, as they are very commonly > the same. There has been interest to work on a document that will > compress the packet and derive IV from the sequence number instead of > sending it in separate field. The working group will specify how this > compression can be negotiated in the IKEv2, and specify how the > encryption algorithm and ESP format is used in this case. > > The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based > protocol for negotiating group keys for both multicast and unicast > uses. The Working Group will develop an IKEv2-based alternative that > will include cryptographic updates. A possible starting point is > draft-yeung-g-ikev2 > > Postquantum Cryptography brings new key exchange methods. Most of > these methods that are known to date have much larger public keys then > conventional Diffie-Hellman public keys. Direct using these methods in > IKEv2 might lead to a number of problems due to the increased size of > initial IKEv2 messages. The working group will analyze the possible > problems and develop a solution, that will make adding Postquantum key > exchange methods more easy. The solution will allow post quantum key > exchange to be performed in parallel with (or instead of) the existing > Diffie-Hellman key exchange. > > A growing number of use cases for constraint network - but not limited > to - have shown interest in reducing ESP (resp. IKEv2) overhead by > compressing ESP (resp IKEv2) fields. The WG will define extensions of > ESP and IKEv2 to enable ESP header compression. > > draft-mglt-ipsecme-diet-esp and > draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good > starting points for ESP compression. > draft-smyslov-ipsecme-ikev2-compression and > draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 > compression. > > RFC7427 allows peers to indicate hash algorithms they support, thus > eliminating ambiguity in selecting a hash function for digital > signature authentication. However, recent advances in cryptography > lead to a situation when some signature algorithms have several > signature formats. A prominent example is RSASSA-PKCS#1 and > RSASSA-PSS, however it is envisioned that the same situation may > repeat in future with other signature algorithms. Currently IKE peers > have no explicit way to indicate each other which signature format(s) > the support, that leads to ineroperability problems. The WG will > investigate the situation and come up with a solution that allows > peers to deal with the problem in an interoperable way. > > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address family > is not assigned, nor whether it should try using another address > family. The Working Group will specify a set of more specific > notification codes that will provide sufficient information to the > IKEv2 initiator about the encountered failure. > draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting > point for this item. > > Some systems support security labels (aka security context) as one of > the selectors of the SPD. This label needs to be part of the IKE > negotiation for the IPsec SA. non-standard implementations exist for > IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now > using private space IPSEC Security Association Attribute 32001). The > work is to standarize this for IKEv2, in a way that will be backwards > compatible with old implementations, meaning it must not require any > changes to implementations not supporting this. > > This charter will expire in December 2019. If the charter is not > updated before that time, the WG will be closed and any remaining > documents revert back to individual Internet-Drafts. > -- > [email protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
