[IPsec] wesp discussion
Hi, Regarding the need to have non encrypted text in the esp packet, we had a use case a few years ago for tunnels such as Geneve. NSH may also be something that would need such a property. At that time I proposed something very similar to ESP. I think that is a useful feature to have to enable securing what is currently not secured at all. https://www.ietf.org/archive/id/draft-mglt-nvo3-geneve-security-architecture-00.txt https://www.ietf.org/archive/id/draft-mglt-nvo3-geneve-authentication-option-00.txt https://www.ietf.org/archive/id/draft-mglt-nvo3-geneve-encryption-option-00.txt Yours, Daniel -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] FW: Discussion about an idea to extend IKEv2
Dear all, Is it the write place to send an email to discuss about an idea I would like to propose to extend IKEv2 ? Best Regards, Houda ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Starting discussion of failure detection proposals
Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: - A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf, and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is sure that the INVALID_SPI responses are not a DoS attack; this could be several minutes - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use rekey to mean rekey or, if appropriate, resume. The proposed extension does not include the actual rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (http://tools.ietf.org/html/draft-nir-ike-qcd), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say this SPI is gone. Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. In SIR (http://tools.ietf.org/html/draft-ditienne-ikev2-recovery), Alice sends a new Check_SPI query with a stateless cookie, essentially asking do you really not know about this SPI?; Bob responds by saying I'm sure I don't know that SPI. Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Yes, you can sort-of negotiate DH groups, but you don't have the New Group Mode that we had in section 5.6 or RFC 2409. So with RFC 4306, you're stuck with only those groups that appear in the IANA registry, rather than your own pet DH groups. On Mar 2, 2010, at 10:49 PM, Yaron Sheffer wrote: By the way, IKEv2 does allow for negotiation of the DH group using the ugly INVALID_KE_PAYLOAD hack. RFC 2409 supported negotiation of various parameters, like the group used for the Diffie-Hellman key exchange. That was removed in RFC 4306. All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- criteria do some sort of discrete logarithm cryptography and therefore it would be useful to list whether the candidate algorithm can use any of the groups either negotiated or asserted by IKE(v2). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Yoav Nir writes: Yes, you can sort-of negotiate DH groups, but you don't have the New Group Mode that we had in section 5.6 or RFC 2409. Yes, that was left out but as it was seen that nobody will accept new group proposed from unknown party without checking it first, and checking that the modulus is prime and otherwise secure is quite hard task... So with RFC 4306, you're stuck with only those groups that appear in the IANA registry, rather than your own pet DH groups. That is not completely true. RFC4306 has a SHOULD requirement which says: -- ... In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman (DH) parameters (the generator, modulus, and exponent lengths and values) for new DH groups. Implementations SHOULD provide a management interface via which these parameters and the associated transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. -- I.e. as it was seen that implementations will not want to accept group they have not verified, and that verification is computationally costly operation, it will not be done online. So if you want to use your own private groups you use off-line communication and communicate the group parameters to the other side and both ends store that group parameters along with the group number allocated from private number space, and then you can use the privete group. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Hello, There are other criteria that should be evaluated in making a decision, such as how well does the solution fits into IKE(v2) and does it support crypto agility. RFC 2409 supported negotiation of various parameters, like the group used for the Diffie-Hellman key exchange. That was removed in RFC 4306. All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- criteria do some sort of discrete logarithm cryptography and therefore it would be useful to list whether the candidate algorithm can use any of the groups either negotiated or asserted by IKE(v2). For instance, I do not believe EKE is suitable for any of the groups currently in the IANA registry of groups that can be used with IKE(v2). The MODP groups have a generator that is a quadratic residue which enables a passive attacker to eliminate passwords from the dictionary if they do not decrypt to a value that is, itself, a quadratic residue and ECP groups are unsuitable because a passive attacker can eliminate passwords from the group if they do not decrypt to a valid point on the curve. In either case, after seeing a trivial number of exchanges a passive attacker is able to determine the password with high probability. So EKE requires a hard-coded special group to be used for its discrete logarithm operations and since negotiation has been removed in RFC 4306 it means that the ability to change the group to suit the policy or whim of the user (what is popularly termed crypto agility) goes away. EKE also requires specification of the mode of encryption used which may or may not be the same as the one negotiated or asserted in IKE(v2). It could be hard-coded into the specification, like the group, but this too further limits crypto agility. The other candidates, I believe, can use the same group, whether MODP or ECP, that the IKE(v2) exchange is using. I think it would be good to add these criteria to the draft. Also, the table in section 5 should include IEEE 802.11s under the standards column for SPSK. And the phrase may or may not infringe on existing patents applies to all candidates, and frankly, to almost everything in the IETF. It is a meaningless phrase and it would be better to just remove it from the IPR column. regards, Dan. On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: Greetings again. This message is cross-posted to both the IPsecME WG and the CFRG because it pertains to both groups. The recently-revised IPsecME charter has a new work item in it: == - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for strong shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for weak shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on weak (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. == As the last paragraph says, there are multiple algorithms to choose from. Different algorithms have different properties. Before the WG decides on which algorithm to focus on, it needs to at least roughly decide which properties are important for the new protocol. I have included the CFRG on this message because they are a good source of expertise on cryptographic properties. Yaron Sheffer has created a short and admittedly biased draft listing some desired properties and possible
Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
At 12:12 PM -0800 3/2/10, Dan Harkins wrote: There are other criteria that should be evaluated in making a decision, such as how well does the solution fits into IKE(v2) and does it support crypto agility. ...and what we mean by agility. To some, that means in-protocol negotiation of parameters, but to others it means have enough variants of the algorithm with different parameters to meet some security threshold. RFC 2409 supported negotiation of various parameters, like the group used for the Diffie-Hellman key exchange. That was removed in RFC 4306. All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- criteria do some sort of discrete logarithm cryptography and therefore it would be useful to list whether the candidate algorithm can use any of the groups either negotiated or asserted by IKE(v2). OK, but... For instance, I do not believe EKE is suitable for any of the groups currently in the IANA registry of groups that can be used with IKE(v2). The MODP groups have a generator that is a quadratic residue which enables a passive attacker to eliminate passwords from the dictionary if they do not decrypt to a value that is, itself, a quadratic residue and ECP groups are unsuitable because a passive attacker can eliminate passwords from the group if they do not decrypt to a valid point on the curve. In either case, after seeing a trivial number of exchanges a passive attacker is able to determine the password with high probability. Those two paragraphs don't line up. Why would you want to use the groups negotiated or demanded in the IKEv2 exchange if they allow for easier attacks? Wouldn't it be better to allow the PAKE to negotiate or demand its own, presumably better, groups? So EKE requires a hard-coded special group to be used for its discrete logarithm operations and since negotiation has been removed in RFC 4306 it means that the ability to change the group to suit the policy or whim of the user (what is popularly termed crypto agility) goes away. EKE also requires specification of the mode of encryption used which may or may not be the same as the one negotiated or asserted in IKE(v2). It could be hard-coded into the specification, like the group, but this too further limits crypto agility. Yaron disagreed with this assessment. I would like to hear from others with EKE experience. The other candidates, I believe, can use the same group, whether MODP or ECP, that the IKE(v2) exchange is using. I think it would be good to add these criteria to the draft. See above. I think the requirement should be crypto agility, which means X Y Z unless that agility itself opens up a security hole, such as a downgrade attack. Also, the table in section 5 should include IEEE 802.11s under the standards column for SPSK. And the phrase may or may not infringe on existing patents applies to all candidates, and frankly, to almost everything in the IETF. It is a meaningless phrase and it would be better to just remove it from the IPR column. +1 --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Hi Yaron, The discussion is on the secure password-only authentication work item in which a password authenticated key exchange is being added directly to IKE(v2). It doesn't matter what EAP-EKE does or does not do because EAP is not being used for this work item. Now we can add some sort of negotiation or assertion of the special group required by EKE (analagous to what EAP-EKE does) but that doesn't fit well with IKEv2 today. Whether the ability to use the existing IANA group registry or whether hard-coding special groups into the exchange is less or more important is a matter of opinion and when we get to that stage we can argue about it. But right now all I'm saying is that this should be included in the criteria that we are using to evaluate candidates. Do we need a shoe horn or a jack hammer to put the exchange into IKE(v2)? Once in does it constrain us in any way? These are valid topics to discuss. Don't you agree? regards, Dan. On Tue, March 2, 2010 12:49 pm, Yaron Sheffer wrote: Hi Dan, EAP-EKE supports negotiation of various algorithms, a.k.a. crypto-agility. One of the negotiated algorithms is in fact the group being used. EAP-EKE does require MODP groups that fulfill certain conditions, and as a result, the document defines one such group (additional ones can be easily added). I believe that crypto-agility is an important criterion. As to reuse of IKEv2 groups, this is probably much less important. It is a bit early to speculate about IKE+EKE, since to the best of my knowledge, it has not been written yet. By the way, IKEv2 does allow for negotiation of the DH group using the ugly INVALID_KE_PAYLOAD hack. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan Harkins Sent: Tuesday, March 02, 2010 22:12 To: Paul Hoffman Cc: IPsecme WG; c...@irtf.org Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Hello, There are other criteria that should be evaluated in making a decision, such as how well does the solution fits into IKE(v2) and does it support crypto agility. RFC 2409 supported negotiation of various parameters, like the group used for the Diffie-Hellman key exchange. That was removed in RFC 4306. All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- criteria do some sort of discrete logarithm cryptography and therefore it would be useful to list whether the candidate algorithm can use any of the groups either negotiated or asserted by IKE(v2). For instance, I do not believe EKE is suitable for any of the groups currently in the IANA registry of groups that can be used with IKE(v2). The MODP groups have a generator that is a quadratic residue which enables a passive attacker to eliminate passwords from the dictionary if they do not decrypt to a value that is, itself, a quadratic residue and ECP groups are unsuitable because a passive attacker can eliminate passwords from the group if they do not decrypt to a valid point on the curve. In either case, after seeing a trivial number of exchanges a passive attacker is able to determine the password with high probability. So EKE requires a hard-coded special group to be used for its discrete logarithm operations and since negotiation has been removed in RFC 4306 it means that the ability to change the group to suit the policy or whim of the user (what is popularly termed crypto agility) goes away. EKE also requires specification of the mode of encryption used which may or may not be the same as the one negotiated or asserted in IKE(v2). It could be hard-coded into the specification, like the group, but this too further limits crypto agility. The other candidates, I believe, can use the same group, whether MODP or ECP, that the IKE(v2) exchange is using. I think it would be good to add these criteria to the draft. Also, the table in section 5 should include IEEE 802.11s under the standards column for SPSK. And the phrase may or may not infringe on existing patents applies to all candidates, and frankly, to almost everything in the IETF. It is a meaningless phrase and it would be better to just remove it from the IPR column. regards, Dan. On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: Greetings again. This message is cross-posted to both the IPsecME WG and the CFRG because it pertains to both groups. The recently-revised IPsecME charter has a new work item in it: == - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for strong shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access
Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Dan, For instance, I do not believe EKE is suitable for any of the groups currently in the IANA registry of groups that can be used with IKE(v2). There was an analogous experience with SRP for iSCSI - completely different groups were used up to 2048 bits and beyond there, the modulus primes from the larger IKEv2 groups were combined with different generators (i.e., not 2) - see Appendix A of RFC 3723. [... snip ...] OTOH, I think you've oversimplified here ... The candidate exchanges all rely on the hard problem of doing a discrete logarithm in one of the defined groups. It's the same hard problem that makes the Diffie-Hellman portion of IKE secure. If the group negotiated or demanded in IKE allows for an easier attack then it shouldn't be used in the IKE exchange to do the Diffie-Hellman. If I follow your logic, I think you're arguing that because the existing groups allow easier attacks on password authentication (e.g., based on checks on what a guessed password decrypts to) then they allow easier attacks on IKE with existing authentication, *hence* those groups are unacceptable to use with IKE. I think the *hence* is off the mark due to the much larger candidate search space when other techniques (e.g., certificate-based) are used to authenticate. And if the group is good enough to use for the Diffie-Hellman key exchange then, by definition, it is good enough for password authentication. No argument here, but I don't think that statement implies its converse. [... snip ..] I think there is value in being able to use the same group (a lesson learned from IKEv1 is that not everything needs to be negotiated and the increase in complexity just isn't worth it). Some may find value in negotiating groups separately. Whatever. But I think this should be included in the criteria for selection so we can discuss the pros and cons. I would agree with that - the ability to use the existing groups should be a plus for evaluation. I'd also suggest that if new groups are defined for password authentication, those groups ought to be usable for IKE as well *provided that* the resulting negotiation complexity doesn't get out of hand. I don't think we can retire/replace the existing groups, and I don't think you're suggesting that. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_da...@emc.com Mobile: +1 (978) 394-7754 -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan Harkins Sent: Tuesday, March 02, 2010 5:55 PM To: Paul Hoffman Cc: IPsecme WG; c...@irtf.org; Dan Harkins Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Hi Paul, On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote: [snip] RFC 2409 supported negotiation of various parameters, like the group used for the Diffie-Hellman key exchange. That was removed in RFC 4306. All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- criteria do some sort of discrete logarithm cryptography and therefore it would be useful to list whether the candidate algorithm can use any of the groups either negotiated or asserted by IKE(v2). OK, but... For instance, I do not believe EKE is suitable for any of the groups currently in the IANA registry of groups that can be used with IKE(v2). The MODP groups have a generator that is a quadratic residue which enables a passive attacker to eliminate passwords from the dictionary if they do not decrypt to a value that is, itself, a quadratic residue and ECP groups are unsuitable because a passive attacker can eliminate passwords from the group if they do not decrypt to a valid point on the curve. In either case, after seeing a trivial number of exchanges a passive attacker is able to determine the password with high probability. Those two paragraphs don't line up. Why would you want to use the groups negotiated or demanded in the IKEv2 exchange if they allow for easier attacks? Wouldn't it be better to allow the PAKE to negotiate or demand its own, presumably better, groups? The candidate exchanges all rely on the hard problem of doing a discrete logarithm in one of the defined groups. It's the same hard problem that makes the Diffie-Hellman portion of IKE secure. If the group negotiated or demanded in IKE allows for an easier attack then it shouldn't be used in the IKE exchange to do the Diffie-Hellman. And if the group is good enough to use for the Diffie-Hellman key exchange then, by definition, it is good enough for password authentication. If someone wants to use a 521-bit ECP group for the Diffie-Hellman key exchange then requiring him to use a 2048-bit MODP group
[IPsec] Beginning discussion on secure password-only authentication for IKEv2
Greetings again. This message is cross-posted to both the IPsecME WG and the CFRG because it pertains to both groups. The recently-revised IPsecME charter has a new work item in it: == - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for strong shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for weak shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on weak (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. == As the last paragraph says, there are multiple algorithms to choose from. Different algorithms have different properties. Before the WG decides on which algorithm to focus on, it needs to at least roughly decide which properties are important for the new protocol. I have included the CFRG on this message because they are a good source of expertise on cryptographic properties. Yaron Sheffer has created a short and admittedly biased draft listing some desired properties and possible candidate algorithms: http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-pake-criteria-00.txt. Other people (and even Yaron) might have different views on which properties are important, how the properties should be ranked, the importance of the crypto properties of the listed algorithms, and so on. This message is therefore meant to kick off the discussion. It is OK for messages to focus on one or more of the proposed algorithms, but getting a clearer view of which crypto and non-crypto properties are important is probably more important first. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] this discussion
Folks, The flurry of messages that have been exchanged today and yesterday have often struck me as incorporating rather vague arguments. I find myself having to do a lot of work to fill in the blanks for not well-articulated comments, construct detailed analyses, and postulate rationales for the arguments made by others. I think everyone ought to spend more time composing messages that are clear and persuasive, so as to not unduly consume the time of others. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Rechartering discussion in Hiroshima
Greetings again. As Yaron and I have mentioned on the mailing list in the past few weeks, one of the next big tasks for the WG is to decide if we want to ask the IESG if we can add new items to the WG charter. To that end, we asked for proposals for which there were already Internet Drafts, or for which there would be Internet Drafts soon. As you can see at http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/RecharterNov2009, we got seven such proposals. Our next task is to start discussing whether or not the WG as a whole would want to include these in our charter. We will have the first discussion of that at the IETF meeting in Hiroshima. The tenor of the discussion will be whether or not the WG wants to take on the work, not the technical specifics of the drafts listed. It is important to remember a few things about rechartering a WG: - If we want to amend our charter, we do so in a request to the IESG and the IAB. As RFC 2418 explains: Rechartering (other than revising milestones) a working group follows the same procedures that the initial chartering does (see section 2). The revised charter must be submitted to the IESG and IAB for approval. As with the initial chartering, the IESG may approve new charter as-is, it may request that changes be made in the new charter (including having the Working Group continue to use the old charter), or it may decline to approve the rechartered working group. In the latter case, the working group is disbanded. - A request to recharter contains a text description of the intended work, not just the name of an Internet Draft that the WG wants to use as the basis for work. - Our current charter (http://www.ietf.org/dyn/wg/charter/ipsecme-charter.html) says: The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. We have indeed progressed many documents to IESG evaluation, and a few beyond. Yaron and I intend to keep the total of WG items to six, as in our current charter. - There needs to be sufficient interest in a proposed item before we put it in the charter. We thought we had such interest for the original set of work items, but Yaron and I have had to do a bit of public grovelling to get sufficient reviews for some of them. We will attempt to avoid that for any new charter items, meaning that we will be strict about promises for review. Given this, please start to take a look at the items at http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/RecharterNov2009. We will have presentations on them in Hiroshima, and more discussion on the list after that. We will then poll about the items, and Yaron and I will propose a way forwards based on the results of the poll. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
