[IPsec] IPsecME rechartering

Hi everyone, The following 7 messages request your input regarding the activities that were proposed for the next phase of the IPsecME WG. This is an open process, and we specifically request that you reply to the mailing list, rather than privately, whether you are committing to review/author

[IPsec] Proposed work item: EAP-only authentication in IKEv2

This draft proposes an IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for one of the peers to present a certificate. This applies to a small number of key-generating EAP methods that allow mutual authentication.   Proposed starting point: http://tools.ie

[IPsec] Proposed work item: Childless IKE SA

This draft proposes an IKEv2 extension to allow the setup of an IKE SA with no Child SA, a situation which is currently disallowed by the protocol. Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt.   Please reply to the list:   - If this proposal is accepted a

[IPsec] Proposed work item: IKEv2 password authentication (SPSK)

This draft proposes a particular method for mutual authentication of IKEv2 peers using a short, low quality shared secret (a.k.a. "password"). The proposal is to embed this method in the IKE exchange, rather than use EAP. Proposed starting point: http://tools.ietf.org/id/draft-harkins-ipsecme-s

[IPsec] Proposed work item: Failure detection in IKEv2

This work item proposes an IKEv2 extension to allow an IKE peer to quickly and securely detect that its opposite peer has lost state. This is claimed to be quicker than the current method, which is based on time outs. Proposed starting point: http://tools.ietf.org/id/draft-nir-ike-qcd-05.txt or

[IPsec] Proposed work item: Labelled IPsec

This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec to be used in environments that require Mandatory Access Control. It is envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS). Propose

[IPsec] Proposed work item: WESP extensibility

This draft proposes an extensibility framework for WESP, as well as several specific extensions. Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committi

[IPsec] Proposed work item: IKE/IPsec high availability and load sharing

This work item will define the problem statement and requirements for a solution that allows interoperable HA/LS device groups. Mixed-vendor clusters are specifically out of scope; but single-vendor clusters should be fully interoperable with other vendors' devices or clusters. The main challeng

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

For someone, who spent quite a lot of time working in this area, it is not difficult fo figure out what is really important and what is not. But, I think, a newcomer could be confused by a long list of all possible numbers. This answer is inconsistent, and that's the crux of the issue I have w

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

At 12:19 AM +0300 11/30/09, Valery Smyslov wrote: >>>For someone, who spent quite a lot of time working in this area, it is not >>>difficult fo figure out what is really important and what is not. But, I >>>think, >>>a newcomer could be confused by a long list of all possible numbers. >> >>This an

Re: [IPsec] WESP - Roadmap Ahead

Jack, Thanks for describing the additional selection criteria that must be employed to avoid the problem I cited. Given this more complete description of the selection criteria, I am not convinced that that is a significant benefit for using WESP in this context. - Whether using WESP or j

Re: [IPsec] Proposed work item: Labelled IPsec

I think that there has been insufficient discussion of whether those who wish to make use of IPsec to enforce mandatory access controls require the facilities described by the folks who have proposed this. At the WG meeting 2 weeks ago I made two observations: - possible use of CIPSO for c

Re: [IPsec] Proposed work item: WESP extensibility

I am opposed to pursing this work at this time. The ongoing discussion on the list suggests that the arguments put forth for WESP use in the OSPFv3 context, the first concrete proposal outside of the middlebox inspection context that motivated WESP, have not been validated. The presentation