Hi Sara, comments below > > > I think that we are at a crucial point where we can make a > change that will > turn our work to more focused and efficient, and hopefully fruitful. I > suggest we use a "divide and conquer" strategic. > We should first of all separate IPsec transforms traffic > handling (i.e. ESP > and AH) and key management work to different WGs (if I > understand right, > this was raised by JI in the SAAG meeting). > This process is already happening as we speak - MSEC and KINK > are working on > key management protocols that create IPsec SAs, with different > requirements. ESP and AH will still be used for traffic handling. > If we will do the separation, we will soon be able to tell > the industry that > the work on the IPsec transforms is done, which I think will > be a great > advantage. > > I think we should also allow for several key management protocols, > preferably with one framework. > This is the only way we will be able to cater for the > requirements of "DSL > geeks" as well as "billion mobile users" (quoting Jari's words). Michael: I also believe that it will not be possible to define a less complex KMP that meets all the requirements of the IPsec community (IKE is so complex because it tries to do so). It seems to be reasonable to develop more focused protocols in different WGs. But, I'm also convinced that a 'default' (mandatory ?) KMP (IKE v2?) for IPsec is necessary in order to guarantee secure operation and interoperability (IPsec is useless without KMP and the security relies upon the security of the KMP). This protocol should be designed to meet only a limited basic set of requirements with security as the most important one (it should be formaly analysed). For me it is not important if this protocol is developed in the IPsec WG or in a different one. It is important that there is a default KMP for IPsec that is secure, that is suitabe for many scenarios and that is implemented by most of the IPsec products. I think that the proposed new charter is a good starting point: we will have to ! ! use IKE for a longer period of time and it makes sense to improve it; OTOH we should start the development of a less complex and more secure protocol. The first and most important step is a clear definition of the requirements. If application scenarios arise with new requirements new protocols can be developed by suitable WGs. > > There are several actions that we need to take for this to happen: > 1) Allow working groups other than IPsec to work on key management > protocols, this way we could shut down the IPsec WG and keep > on working on > new key management protocols. As I said this is already happening. > 2) Limit IPsec wg to only on the following IKE modifications : NAT > traversal, SCTP support and re-keying. The new IKE version > should be a minor > version including only minor fixes (as outlined in the new suggested > charter). Michael: I do not mind if the IPsec WG only adds minor changes to the current IKE or if the WG also should develop the new KMP for IPsec (see above). > 3) Re-assure ourselves that the interface between transforms and key > management is clearly defined, and general enough to allow > for the addition > of new key management protocols, without having to change the > transforms. Michael: I agree. > 4) Have a framework protocol for key management - I think it > should be based > on ISAKMP. There is no need to re-invent transforms and > proposals syntax for > each new key management protocol. Michael: I'm not sure if this really makes sense. > 5) Have different requirements for different key management > protocols. With > one common requirement - they should all create IPsec SAs. Michael: I would like to add the requirement that they should all undergo careful security analysis (formal analysis ?). I don't want to sell IPsec products that will be broken because one of the implemented KMPs was poorly designed. > This way we could > have one requirements document include Identity protection, > and allow for a > larger number of messages, and another that has no Identity Protection > requirement, and requires a small number of message. We can > also have one or > several WGs in charge of the key management protocols. > > Sara. Michael
Unrecognized Data: application/ms-tnef