Re: [IPsec] Proposed work item: Failure detection in IKEv2 - YES
Hello all, I myself do not like the current method for detecting that a peer has lost state (generally this means waiting for a number of retransmits, whom each of which has a time out). In my opinion this would be a good item for the WG to work on and would enhance IKEv2. I would like to review the draft. If time permits, I would be interested to contribute text, but I cannot say that for sure right now. Regards, Matt 2009/12/2 Raj Singh > Hi Team, > > According to me, we need to support this draft as WG item as it appears to > enhance the failure detection time. > Currently, there are many scenarios, in which we detect and delete stale SA > only by max. re-transmits. > I would like to review this draft. > > Regards, > Raj > > 2009/11/29 Yaron Sheffer > >> 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 >> http://tools.ietf.org/html/draft-detienne-ikev2-recovery-03. >> >> Please reply to the list: >> >> - If this proposal is accepted as a WG work item, are you committing to >> review multiple versions of the draft? >> - Are you willing to contribute text to the draft? >> - Would you like to co-author it? >> >> Please also reply to the list if: >> >> - You believe this is NOT a reasonable activity for the WG to spend time >> on. >> >> If this is the case, please explain your position. Do not explore the fine >> technical details (which will change anyway, once the WG gets hold of the >> draft); instead explain why this is uninteresting for the WG or for the >> industry at large. Also, please mark the title clearly (e.g. "DES40-export >> in IPsec - NO!"). >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Failure detection in IKEv2 - YES
Hi Team, According to me, we need to support this draft as WG item as it appears to enhance the failure detection time. Currently, there are many scenarios, in which we detect and delete stale SA only by max. re-transmits. I would like to review this draft. Regards, Raj 2009/11/29 Yaron Sheffer > 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.txtor > http://tools.ietf.org/html/draft-detienne-ikev2-recovery-03. > > Please reply to the list: > > - If this proposal is accepted as a WG work item, are you committing to > review multiple versions of the draft? > - Are you willing to contribute text to the draft? > - Would you like to co-author it? > > Please also reply to the list if: > > - You believe this is NOT a reasonable activity for the WG to spend time > on. > > If this is the case, please explain your position. Do not explore the fine > technical details (which will change anyway, once the WG gets hold of the > draft); instead explain why this is uninteresting for the WG or for the > industry at large. Also, please mark the title clearly (e.g. "DES40-export > in IPsec - NO!"). > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKE/IPsec high availability and load sharing - YES
Hi Team, According to me, High Availability needs protocol level support from IKEv2 due to windowing and sequence numbers in IPsec. This will enhance performance and avoid proprietary versions of different vendors. Here we can discuss various problem and solution of IPsec and HA, which surely needs some attention. Also, Kalyani presented a solution syncing-up of IKE message id in internal meeting. That can be a good starting point. I would like to review and co-author this draft. Regards, Raj On Sun, Nov 29, 2009 at 10:49 PM, Yaron Sheffer wrote: > 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 > challenge is to overcome the strict use of sequence numbers in both IPsec > and IKE, in HA and LS scenarios. Following the Hiroshima discussion, the WI > is initially focused on defining the problem, rather than a particular > solution. > > > > Proposed starting point: > http://tools.ietf.org/id/draft-nir-ipsecme-ipsecha-00.txt. > > > > Please reply to the list: > > > > - If this proposal is accepted as a WG work item, are you committing to > review multiple versions of the draft? > > - Are you willing to contribute text to the draft? > > - Would you like to co-author it? > > > > Please also reply to the list if: > > > > - You believe this is NOT a reasonable activity for the WG to spend time > on. > > > > If this is the case, please explain your position. Do not explore the fine > technical details (which will change anyway, once the WG gets hold of the > draft); instead explain why this is uninteresting for the WG or for the > industry at large. Also, please mark the title clearly (e.g. "DES40-export > in IPsec - NO!"). > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
Hi Martin, If you (or anybody else) support EAP-only auth (or any of the other 6 drafts), please commit to review it assuming it becomes a WG document. *This* was the main point of this discussion thread: we cannot make progress without committed editors and reviewers. Thanks, and apologies for picking on you :-) Yaron > -Original Message- > From: Martin Willi [mailto:mar...@strongswan.org] > Sent: Tuesday, December 01, 2009 11:27 > To: Dan Harkins > Cc: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 > > Hi Dan, > > > And in that case EAP encapsulation of the underlying key exchange would > > be completely pointless and extraneous, would double the number of > > messages required to complete the exchange, and would increase the > amount > > of security-critical code. > > EAP authentication was not primarily included in IKEv2 to implement some > kind of password authentication on top if IKEv2, but to reuse existing > EAP methods and infrastructure. > > The most demanding user of IKEv2 currently is the mobile/telco industry; > There are several specs in 3GPP and 3GPP2 using it. Many of them have > chosen IKEv2 because they can use their existing EAP-AKA/SIM > infrastructure for authentication. > > > It seems to me that EAP-only authentication in IKEv2: > > 1. does not solve a general problem; > > It does. It allows to omit public key authentication in cases where > mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2 > spec that already uses EAP-AKA/TLS only authentication, but does not > follow this draft. I really see a need for this WG item. > > > 2. solves the specific problem it is aimed at poorly-- doubling of > > the number of messages, requiring writing and testing of new > > state EAP state machines that are, otherwise, unnecessary > > If you're just talking about password authentication, yes. But this > allows IKEv2 to work in existing infrastructures (EAP over > RADIUS/DIAMETER). We currently see a strong demand for such solutions. > > > To provide the benefits of EAP-only authentication [...] it would be > > much better to support the inclusion of "Secure PSK authentication" as > > a work item. > > Implementing password authentication on top of EAP may be one reason for > this draft, but there are several others. And the separated EAP layer > allows you to forward authentication to an existing AAA server. > Further, many vendors already have generic EAP support. Implementing PSK > authentication on top of it is probably simpler and more flexible than > integrating it in IKEv2 directly. > > Best regards > Martin > > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Hi Dan, I will not argue about the implementation complexity. Such arguments are useless in general, and I certainly cannot argue with your first-hand experience. But EAP does solve, perfectly, the client-to-server use case. The password can be offloaded to AAA or not, depending on security and performance considerations. And multiple choices are available for the authentication method, depending on various criteria like performance, IPR, security strength and others. To repeat what I'd already said, the "lying NAS" problem can be easily solved with channel bindings, and will (eventually) be solved. Adding a few protected fields to any particular EAP method is not a big deal. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, December 01, 2009 22:04 > To: Yaron Sheffer > Cc: Tero Kivinen; ipsec@ietf.org; Matthew Cini Sarreo > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO > > > Hi Yaron, > > EAP is a client/server protocol. If either side can initiate the > exchange (necessary for site-to-site and transport) then each side > will be required to implement BOTH the EAP client and EAP server > state machines. "[P]eople who already have client-side EAP" will > need to add server-side EAP to their IPsec client implementation > and people who have server-side EAP today will need to add client- > side EAP to their gateway implementation. You say it's "not adding a > lot"; I disagree. Having written an EAP implementation (as well as > 802.1x and several EAP methods) I can tell you it's a good sized > chunk of code that needs testing and debugging. > > Doing what you propose means: > > 1. no AAA server for off-load is possible since both sides need > to possess the shared secret and there is no AAA server in > the world that can _initiate_ EAP. > 2. the EAP encapsulation serves no purpose since the conversation > is just between the two peers. > 3. it takes twice as many messages. > 4. it involves a pointless exchange of identities which brings up > further complexity in the case when the identity in the EAP > exchange differs from the one in the IKE exchange. You'll need > to check, what do you do and why? > > All this added complexity to a security product for what gain? Nothing. > For the other use case-- true client/server-- the EAP-only proposal > also has a security issue since the server can claim any identity it > chooses and the AAA server terminating EAP will "authenticate" it. > > So for 2 uses cases it's pointless complexity and for the other use > case it's got a security problem. Why is this a good idea? Because > "this is not adding a lot"? That's like saying that dirt doesn't taste > that bad without explaining why someone would want to eat dirt in the > first place. > > Dan. > > On Tue, December 1, 2009 5:17 am, Yaron Sheffer wrote: > > Hi Tero, > > > > I think you are too quick to dismiss the option of using EAP-only for > > site-to-site and transport deployments, where the EAP state machine is > > embedded into the IKE endpoint. For people who already have client-side > > EAP, this is not adding a lot. It's not as efficient as tailor-made > > password authentication in IKE, but OTOH it is much more generic. > > > > Thanks, > > Yaron > > > >> -Original Message- > >> From: Tero Kivinen [mailto:kivi...@iki.fi] > >> Sent: Tuesday, December 01, 2009 15:04 > >> To: Yaron Sheffer > >> Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org > >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > >> (SPSK) - NO > >> > >> Yaron Sheffer writes: > >> > I'm sorry, but you are misstating the difference between the > >> > proposals. One is adding a notification and eliminating one existing > >> > (certificate) check; the other is adding an IKE mode, and changing > >> > the protocol state machine in the process. > >> > >> Not true. > >> > >> Both are adding new IKEv2 authentication mode. > >> > >> In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also > >> makes it so that server DOES NOT need to have certificate and public > >> key, meaning it does not send it s first AUTH payload in message 4. > >> > >> The main benefit from this is that the server DOES NOT need to have > >> private key. > >> > >> (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) > >> > >> We currently already have 4 authentication modes. > >> > >> ClientServer > >> 1) Shared keyShared key > >> 2) Public keyShared key > >> 3) Shared keyPublic key > >> 4) EAP Public key > >> > >> EAP only will add one more: > >> > >> 5) mutual-EAPmutual-EAP > >> > >> and SPSK will add one more: > >> > >> 6) Password
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman wrote: > - Add [IKEV2IANA] to the Normative References; it will point to the > URL of the IANA registry. I don't like the idea of splitting the normative content of RFC 4306 to two different places. An informative reference would be very useful (and probably some of the tables may contain stuff that could be just removed). But if I'm writing code to send an IDi payload of type ID_FQDN, the numbers for "IDi" and "ID_FQDN" should be in this RFC (either somewhere near the text that describes IDi and ID_FQDN, or in a table -- that doesn't matter very much). Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Hi Yaron, EAP is a client/server protocol. If either side can initiate the exchange (necessary for site-to-site and transport) then each side will be required to implement BOTH the EAP client and EAP server state machines. "[P]eople who already have client-side EAP" will need to add server-side EAP to their IPsec client implementation and people who have server-side EAP today will need to add client- side EAP to their gateway implementation. You say it's "not adding a lot"; I disagree. Having written an EAP implementation (as well as 802.1x and several EAP methods) I can tell you it's a good sized chunk of code that needs testing and debugging. Doing what you propose means: 1. no AAA server for off-load is possible since both sides need to possess the shared secret and there is no AAA server in the world that can _initiate_ EAP. 2. the EAP encapsulation serves no purpose since the conversation is just between the two peers. 3. it takes twice as many messages. 4. it involves a pointless exchange of identities which brings up further complexity in the case when the identity in the EAP exchange differs from the one in the IKE exchange. You'll need to check, what do you do and why? All this added complexity to a security product for what gain? Nothing. For the other use case-- true client/server-- the EAP-only proposal also has a security issue since the server can claim any identity it chooses and the AAA server terminating EAP will "authenticate" it. So for 2 uses cases it's pointless complexity and for the other use case it's got a security problem. Why is this a good idea? Because "this is not adding a lot"? That's like saying that dirt doesn't taste that bad without explaining why someone would want to eat dirt in the first place. Dan. On Tue, December 1, 2009 5:17 am, Yaron Sheffer wrote: > Hi Tero, > > I think you are too quick to dismiss the option of using EAP-only for > site-to-site and transport deployments, where the EAP state machine is > embedded into the IKE endpoint. For people who already have client-side > EAP, this is not adding a lot. It's not as efficient as tailor-made > password authentication in IKE, but OTOH it is much more generic. > > Thanks, > Yaron > >> -Original Message- >> From: Tero Kivinen [mailto:kivi...@iki.fi] >> Sent: Tuesday, December 01, 2009 15:04 >> To: Yaron Sheffer >> Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication >> (SPSK) - NO >> >> Yaron Sheffer writes: >> > I'm sorry, but you are misstating the difference between the >> > proposals. One is adding a notification and eliminating one existing >> > (certificate) check; the other is adding an IKE mode, and changing >> > the protocol state machine in the process. >> >> Not true. >> >> Both are adding new IKEv2 authentication mode. >> >> In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also >> makes it so that server DOES NOT need to have certificate and public >> key, meaning it does not send it s first AUTH payload in message 4. >> >> The main benefit from this is that the server DOES NOT need to have >> private key. >> >> (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) >> >> We currently already have 4 authentication modes. >> >> Client Server >> 1) Shared key Shared key >> 2) Public key Shared key >> 3) Shared key Public key >> 4) EAP Public key >> >> EAP only will add one more: >> >> 5) mutual-EAP mutual-EAP >> >> and SPSK will add one more: >> >> 6) PasswordPassword >> >> > Regardless of all the other pros and cons, the proposals are clearly >> > not comparable as far as changing the protocol. >> >> The changes required for EAP only might be smaller, but testing effort >> for both of them is same, except EAP only really requires you to test >> with all supported mutual key generating EAP methods (and also test >> with others and make sure they are not accepted). >> >> One thing I think most of you are missing is that their usage >> scenarios are COMPLETELY different. >> >> EAP-only can be used when there is clear client-server setup, existing >> EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there >> is no certificates or shared keys in use at all. This setup is >> asymmetric, one party (the user) always initiates the connection. SPSK >> cannot be used in such setup, as there is no password it can find. >> >> SPSK can be used when there is requirement for host to host (or site >> to site) connection, where either end can initiate traffic and >> exchanges and where entities still want to use passwords instead of >> public keys to authenticate. Shared keys could be used there, but in >> mo
Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...)
At 12:03 PM +0200 12/1/09, Tero Kivinen wrote: >Dan Harkins writes: >> Groups 1 and 2 were defined in RFC 2409 and repeating them in a >> subsequent RFC does not change that. > >RFC2409 has been obsoleted, so I do not want to refer to that, as >people will then go to the RFC2409 and notice that it has been >obsoleted by RFC4306, and will go to there and find the groups from >RFC4306 appendix B.1 and B.2. Fully agree. It does not matter where something was defined first. >I am NOT going to touch ipsec-registry. That is IKEv1 stuff that is >already obsoleted, and there is no point of doing anything for that >(and no need, as it does nto have range allocations). > >I am talking about IKEv2 registry >(http://www.iana.org/assignments/ikev2-parameters) and there the >references were already for RFC4306, not to RFC2409 (and it does not >have groups 3 and 4 at all, those are not defined for IKEv2). There may be a good reason for someone to touch the IKEv1 registry, but that should be done as a separate work item. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New issue: INTERNAL_ADDRESS_FAILURE error and how to continue.
On Tue, Dec 01, 2009 at 03:24:18PM +0200, Tero Kivinen wrote: > The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the > IKE SA stays up, but the child SA is not created. It does not say > anything what should happen on the initiator if it actually did > require address by policy. Interactions like these show the hazards in integrating address configuration into a key exchange protocol. But since we've already thrown in with this since the days of MODE-CFG in IKEv1... > Perhaps adding following paragraph to the end of 3.15.4 would help: > -- > If the initiator does not receive the IP address(es) required by its > policy, it MAY keep the IKE SA up and retry the configuration > payload (as separate INFORMATIONAL exchange) after suitable timeout, > or it MAY also tear down the IKE SA (by sending DELETE payload > inside separate INFORMATIONAL exchange) and retry IKE SA from the > beginning after some longer timeout. The timeout should not be too > short (especially if the IKE SA is started from the beginning), as > these error situations will only be fixed when more entries are > returned to the address pool of the responder, thus it will not be > fixed in seconds, but more likely it takes several minutes. This is definitely the right idea. And the responder should already be able to react to either initiator choice (try with existing IKE SA, or deal with new IKE SA). Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Yaron Sheffer writes: > I'm sorry, but you are misstating the difference between the > proposals. One is adding a notification and eliminating one existing > (certificate) check; the other is adding an IKE mode, and changing > the protocol state machine in the process. Not true. Both are adding new IKEv2 authentication mode. In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also makes it so that server DOES NOT need to have certificate and public key, meaning it does not send it s first AUTH payload in message 4. The main benefit from this is that the server DOES NOT need to have private key. (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) We currently already have 4 authentication modes. Client Server 1) Shared key Shared key 2) Public key Shared key 3) Shared key Public key 4) EAPPublic key EAP only will add one more: 5) mutual-EAP mutual-EAP and SPSK will add one more: 6) Password Password > Regardless of all the other pros and cons, the proposals are clearly > not comparable as far as changing the protocol. The changes required for EAP only might be smaller, but testing effort for both of them is same, except EAP only really requires you to test with all supported mutual key generating EAP methods (and also test with others and make sure they are not accepted). One thing I think most of you are missing is that their usage scenarios are COMPLETELY different. EAP-only can be used when there is clear client-server setup, existing EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there is no certificates or shared keys in use at all. This setup is asymmetric, one party (the user) always initiates the connection. SPSK cannot be used in such setup, as there is no password it can find. SPSK can be used when there is requirement for host to host (or site to site) connection, where either end can initiate traffic and exchanges and where entities still want to use passwords instead of public keys to authenticate. Shared keys could be used there, but in most setups the shared keys used in those scenarios are not strong enough to be resistant against dictionary attacks. EAP-only cannot be used there as this is not client-server setup. In these setup the authentication needs to be symmetric. For this reason I do not think we need to decide to take on or the other, we can take both as I do see use for both of them. If I would need to select one, I would select SPSK, as that is something which cannot be done by IKEv2 now. EAP-only is an optimization (both in protocol level, and especially in adminstrative level) for the existing EAP-Public key authentication. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Closing #25
Paul Hoffman writes: > At 9:46 AM +0200 10/21/09, Yoav Nir wrote: > > A few lines above this section it already says "If the responder's > > policy allows it to accept the first selector of TSi and TSr, then > > the responder MUST narrow the traffic selectors to a subset that > > includes the initiator's first choices." > > > > So there is a MUST requirement to select the initiator's first > > choice (if possible), so I don't think the SHOULD and MAY are > > appropriate here. The way I read this section, it only clarifies > > what to do if the initiator traffic selector (first or not) is too > > broad. In that case, we shouldn't mention the initiator's choices. > > > >On Oct 20, 2009, at 6:19 PM, Paul Hoffman wrote: > > > >>Issue #25, Choice of the right TS when narrowing > > > >>Proposed change: > >> When narrowing is done, there may be several subsets that are > >> acceptable but their union is not. In this case, the responder > >> SHOULD select the initiator's first choice (to be interoperable > >> with RFC 4306), but MAY arbitrarily select any of them, > >> and MAY include an > >> ADDITIONAL_TS_POSSIBLE notification in the response. > > God call. I have closed #25 without making any change. There is one problem with the current text for this traffic selector negotiation. If the initiator has policy that says (I only use one end of traffic selectors as that is enough for this example): 192.0.2.0 - 192.0.2.255 PROTECT and responder has policy that says: 192.0.2.128 - 192.0.2.255 PROTECT Now when initiator gets packet form the network that has address of 192.0.2.5, it will match its policy and it will start creating new IKE SA and Child SA. It sends traffic selectors having content of: TS(TCP:80-80, 192.0.2.5 - 192.0.2.5) TS(0:0-65535, 192.0.2.0 - 192.0.2.255) The responder will see those and starts following the rules in the section 2.9. -- The responder performs the narrowing as follows: o If the responder's policy does not allow it to accept any part of the proposed traffic selectors, it responds with TS_UNACCEPTABLE. o If the responder's policy allows the entire set of traffic covered by TSi and TSr, no narrowing is necessary, and the responder can return the same TSi and TSr values. o If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices. In this example above, the responder might respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. o If the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. -- 1) The responder's policy do allow some part of the traffic selectors, so it does not send TS_UNACCEPTABLE. 2) Responder's policy does not allow entire set of traffic, so it cannot return full set. 3) Responder's policy does not allow first traffic selector, so it cannot narrow it down to that. 4) So it gets to this last rule and narrows traffic selectors down to acceptable subset of initiators set, i.e resulting traffic selector will be: TS(0:0-65535, 192.0.2.128 - 192.0.2.255) Now when initiator gets this it installs the Child SA as normally. The created SA is useless for triggering packet, so it cannot send the packet over that SA, and most likely it will throw that packet away. When the next packet coming having same address comes in, it most likely triggers new child SA exchange with same results. After a few hundred packets the initiator and responder have 100 overlapping Child SAs which all are completely useless for any traffic. Responder cannot do anything, as it is completely valid to create multiple overlapping Child SAs, as this is required for the QoS. Initiator might try to do something smart and for example disable the trigger rule for next n minutes when it started creating Child SA, so it will not trigger again, but at some point it do want to enable the trigger again, just in case the other end has fixed its configuration. All of this is caused because of the final rule saying: o If the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. If that would not be there, then the responder would return TS_UNACCEPTABLE to the initiators Child SA create exchange, which would prevent creating extra Child SAs. This final rule is NOT in the RFC4306 in triggering packet case, it was only there in case there was no triggering packet (of course there is no text explaining how do you know if the first traffic selector is triggering packet or not). I suggest that we add text explainin
[IPsec] New issue: inconsistency in the section 2.9
The section 2.9 has text which says: -- 2.9. Traffic Selector Negotiation ... Since the two endpoints may be configured by different people, the incompatibility may persist for an extended period even in the absence of errors. It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses and depends on the other end to have the up-to-date list. ... ... This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a tunnel wider than the responder will accept. Such misconfigurations should be recorded in error logs. -- So the first part says that traffic selectors may be different on initiator's and responder's policy and that such a configuration may be intentional. Then the second part calls such configuration misconfigurations and require such events to be logged. This is bit inconsistent, and I think the second part should be modified so that the last sentence is removed, or rephrased. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Childless IKE SA
During the last 3GPP SA3 meeting, such requirement about HNB has also been approved as well. thanks -Hui 2009/12/1 Yoav Nir : > There were several motivations listed for childless IKE SAs. > - remote access, where you create an IKE SA when the user wants to connect, > and only create child SAs in response to traffic > - authentication only over a physically secure network (not necessarily EAP, > but I think this is the use case you referred to) > - Location awareness (as in the SecureBeacon draft) > - Some "weird" uses such as liveness checks without IPsec, NAT detection, > etc. > > > On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: > >> One of the (or main?) motivations of this proposal is to turn IKEv2 into >> "EAP-based network access authentication protocol". RFC 5191 is designed >> for that purpose, and I'm not sure if we need to twist a protocol for the >> same purpose. >> >> >> >>> -Original Message- >>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >>> Of Yaron Sheffer >>> Sent: Sunday, November 29, 2009 7:21 PM >>> To: ipsec@ietf.org >>> Subject: [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 as a WG work item, are you committing to >>> review multiple versions of the draft? >>> - Are you willing to contribute text to the draft? >>> - Would you like to co-author it? >>> >>> Please also reply to the list if: >>> >>> - You believe this is NOT a reasonable activity for the WG to spend >>> time on. >>> >>> If this is the case, please explain your position. Do not explore the >>> fine technical details (which will change anyway, once the WG gets hold >>> of the draft); instead explain why this is uninteresting for the WG or >>> for the industry at large. Also, please mark the title clearly (e.g. >>> "DES40-export in IPsec - NO!"). >>> ___ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] New issue: INTERNAL_ADDRESS_FAILURE error and how to continue.
The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the IKE SA stays up, but the child SA is not created. It does not say anything what should happen on the initiator if it actually did require address by policy. I think we have two options: 1) Tear down the IKE SA (by sending DELETE payload inside INFORMATIONAL exchange) and try again after suitable timeout. 2) Keep the existing IKE SA up, but retry the configuration payload exchange again after suitable timeout by starting new INFORMATIONAL exchange and putting same configuration payloads in it. I think we might want mention something about this in the section 1.2, or section 3.15.4 Address Assignment Failures. Most likely the section 3.15.4 is better, but we might want to add forward reference from section 1.2 to there. Section 3.15.4 do explain how the responder can behave in different situations, but it does not cover what initiator should do. Perhaps adding following paragraph to the end of 3.15.4 would help: -- If the initiator does not receive the IP address(es) required by its policy, it MAY keep the IKE SA up and retry the configuration payload (as separate INFORMATIONAL exchange) after suitable timeout, or it MAY also tear down the IKE SA (by sending DELETE payload inside separate INFORMATIONAL exchange) and retry IKE SA from the beginning after some longer timeout. The timeout should not be too short (especially if the IKE SA is started from the beginning), as these error situations will only be fixed when more entries are returned to the address pool of the responder, thus it will not be fixed in seconds, but more likely it takes several minutes. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Childless IKE SA
There were several motivations listed for childless IKE SAs. - remote access, where you create an IKE SA when the user wants to connect, and only create child SAs in response to traffic - authentication only over a physically secure network (not necessarily EAP, but I think this is the use case you referred to) - Location awareness (as in the SecureBeacon draft) - Some "weird" uses such as liveness checks without IPsec, NAT detection, etc. On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: > One of the (or main?) motivations of this proposal is to turn IKEv2 into > "EAP-based network access authentication protocol". RFC 5191 is designed > for that purpose, and I'm not sure if we need to twist a protocol for the > same purpose. > > > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Yaron Sheffer >> Sent: Sunday, November 29, 2009 7:21 PM >> To: ipsec@ietf.org >> Subject: [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 as a WG work item, are you committing to >> review multiple versions of the draft? >> - Are you willing to contribute text to the draft? >> - Would you like to co-author it? >> >> Please also reply to the list if: >> >> - You believe this is NOT a reasonable activity for the WG to spend >> time on. >> >> If this is the case, please explain your position. Do not explore the >> fine technical details (which will change anyway, once the WG gets hold >> of the draft); instead explain why this is uninteresting for the WG or >> for the industry at large. Also, please mark the title clearly (e.g. >> "DES40-export in IPsec - NO!"). >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Hi Tero, I think you are too quick to dismiss the option of using EAP-only for site-to-site and transport deployments, where the EAP state machine is embedded into the IKE endpoint. For people who already have client-side EAP, this is not adding a lot. It's not as efficient as tailor-made password authentication in IKE, but OTOH it is much more generic. Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Tuesday, December 01, 2009 15:04 > To: Yaron Sheffer > Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO > > Yaron Sheffer writes: > > I'm sorry, but you are misstating the difference between the > > proposals. One is adding a notification and eliminating one existing > > (certificate) check; the other is adding an IKE mode, and changing > > the protocol state machine in the process. > > Not true. > > Both are adding new IKEv2 authentication mode. > > In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also > makes it so that server DOES NOT need to have certificate and public > key, meaning it does not send it s first AUTH payload in message 4. > > The main benefit from this is that the server DOES NOT need to have > private key. > > (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) > > We currently already have 4 authentication modes. > > Client Server > 1) Shared key Shared key > 2) Public key Shared key > 3) Shared key Public key > 4) EAP Public key > > EAP only will add one more: > > 5) mutual-EAP mutual-EAP > > and SPSK will add one more: > > 6) Password Password > > > Regardless of all the other pros and cons, the proposals are clearly > > not comparable as far as changing the protocol. > > The changes required for EAP only might be smaller, but testing effort > for both of them is same, except EAP only really requires you to test > with all supported mutual key generating EAP methods (and also test > with others and make sure they are not accepted). > > One thing I think most of you are missing is that their usage > scenarios are COMPLETELY different. > > EAP-only can be used when there is clear client-server setup, existing > EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there > is no certificates or shared keys in use at all. This setup is > asymmetric, one party (the user) always initiates the connection. SPSK > cannot be used in such setup, as there is no password it can find. > > SPSK can be used when there is requirement for host to host (or site > to site) connection, where either end can initiate traffic and > exchanges and where entities still want to use passwords instead of > public keys to authenticate. Shared keys could be used there, but in > most setups the shared keys used in those scenarios are not strong > enough to be resistant against dictionary attacks. EAP-only cannot be > used there as this is not client-server setup. In these setup the > authentication needs to be symmetric. > > For this reason I do not think we need to decide to take on or the > other, we can take both as I do see use for both of them. > > If I would need to select one, I would select SPSK, as that is > something which cannot be done by IKEv2 now. > > EAP-only is an optimization (both in protocol level, and especially in > adminstrative level) for the existing EAP-Public key authentication. > -- > kivi...@iki.fi > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Matthew Cini Sarreo writes: > From a developer point of view, I share the same opinion as Yaron about this > issue. Instead of creating new solutions, I personally think that it would > be better to offer guidlines on how to implement current solutions (i.e EAP) > and provide documents targeting implementers. This would create less > confusion and keep IKEv2 a clean, easy to understand and use protocol. I think it would be much more complicated to try to turn EAP from client / server protocol to symmetric protocol, than to add new exchange to IKEv2. Note, that I do not comment anything about how the current SPKS draft is done, as I have not really read it, but I think we should add secure password protocol to the IKEv2 and not use EAP for that when using symmetric site to site, or host to host scenarios. If we had that clean secure password protocol, then we could leave out EAP in some environments, which would make protocol implementation much easier. Looking at the state machine of IKE_AUTH in our own implementation, EAP causes most of the complexity (mostly because EAP is open ended). On the other hand if we add multiple authentication support to the state machine pictures, then that is even more complex than EAP... Good thing with SPSK is that it is alternative for all other authentication modes, i.e. adds one to the shared key-shared key, shared key-public key, public key-shared key, and EAP-public key list. I.e. it does not multiply the test cases but just adds one to the list of current authentication modes, raising it from 4 to 5. EAP only authentication mode raises it by one more. Multiple authentication support raises it to power of n (depending how many different authentication rounds you support)... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Childless IKE SA
One of the (or main?) motivations of this proposal is to turn IKEv2 into "EAP-based network access authentication protocol". RFC 5191 is designed for that purpose, and I'm not sure if we need to twist a protocol for the same purpose. > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Yaron Sheffer > Sent: Sunday, November 29, 2009 7:21 PM > To: ipsec@ietf.org > Subject: [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 as a WG work item, are you committing to > review multiple versions of the draft? > - Are you willing to contribute text to the draft? > - Would you like to co-author it? > > Please also reply to the list if: > > - You believe this is NOT a reasonable activity for the WG to spend > time on. > > If this is the case, please explain your position. Do not explore the > fine technical details (which will change anyway, once the WG gets hold > of the draft); instead explain why this is uninteresting for the WG or > for the industry at large. Also, please mark the title clearly (e.g. > "DES40-export in IPsec - NO!"). > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Yaron Sheffer writes: > EAP was added to IKEv2 to provide "legacy" (a.k.a. password) > authentication. In the past it did not do it very well, but this is > changing. We should improve the use of EAP in IKEv2, rather than > replacing it by a homebrew solution. EAP can really only be used in the client / server situation. Using EAP to protect site to site, or host to host traffic is very hard, because of the assymetric properties of the EAP. Because if this I do think there is use for having secure password protocol in the IKEv2 without using EAP. As an additional note, I also think there is use for EAP methods you list below, as those can be used when there is clear client / server distinction just like in the remote access case. Btw, this same applies to the EAP only authentication, i.e. it has uses when there is clear client / server distinction, i.e. it is not competing with this one, but it provides similar properties for those cases where we really have client and server, and where we do have existing infrastructure (for example using EAP-SIM or EAP-AKA in the GSM or 3GPP environments). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Hi Dan, I'm sorry, but you are misstating the difference between the proposals. One is adding a notification and eliminating one existing (certificate) check; the other is adding an IKE mode, and changing the protocol state machine in the process. Regardless of all the other pros and cons, the proposals are clearly not comparable as far as changing the protocol. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, December 01, 2009 11:01 > To: Matthew Cini Sarreo > Cc: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO > > > Hi Matthew, > > Please take a look at both proposals. There is no proposal to simply > offer guidelines. Both of them are "new solutions" and modify the IKE > exchange. One uses NOTIFY messages to indicate the new exchange and the > other uses the critical bit to indicate the new exchange. I would be > interested in your opinion as a developer which is better-- NOTIFY or > critical bit-- and why. > > As a developer, I do not believe it is better to double the number > of messages needed to do a key exchange, and do not believe it is better > to require pointless encapsulations of a key exchange. If you disagree I > would also be interested in knowing why. > > Dan. > > On Mon, November 30, 2009 11:10 pm, Matthew Cini Sarreo wrote: > > From a developer point of view, I share the same opinion as Yaron about > > this > > issue. Instead of creating new solutions, I personally think that it > would > > be better to offer guidlines on how to implement current solutions (i.e > > EAP) > > and provide documents targeting implementers. This would create less > > confusion and keep IKEv2 a clean, easy to understand and use protocol. > > > > Regards, > > Matthew > > > > 2009/12/1 Yaron Sheffer > > > >> Hi everyone, > >> > >> [WG co-chair hat off] > >> > >> I believe this effort is misguided, and would be a waste of the WG > time. > >> > >> EAP was added to IKEv2 to provide "legacy" (a.k.a. password) > >> authentication. In the past it did not do it very well, but this is > >> changing. We should improve the use of EAP in IKEv2, rather than > >> replacing > >> it by a homebrew solution. > >> > >> Specifically, the following EAP methods can be used today (or in the > >> near > >> future) for mutual password-based auth: > >> > >> - Dan's own EAP-PWD, > >> http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-12 > >> - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03 > >> - The long expired EAP-SRP, > >> http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 > >> - A rumored EAP method based on the PAK protocol ( > >> http://tools.ietf.org/html/draft-brusilovsky-pak-10) > >> > >> Embedding one of these methods as the single way to do mutual auth in > >> IKE > >> simply doesn't make sense. > >> > >> In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto > >> protocol. It has had by far the least crypto review than the other > three > >> protocols. IMHO, this working group should NOT be developing new > >> cryptographic protocols. This is not where our expertise lies. > >> > >> Lastly, one of the major criticisms with IKEv1 was the number of > >> protocol > >> modes. And here we are, with a proposal to add another mode to IKEv2. > >> Doesn't seem like a good idea to me. > >> > >> Thanks, > >>Yaron > >> > >> > >> > -Original Message- > >> > From: Dan Harkins [mailto:dhark...@lounge.org] > >> > Sent: Tuesday, December 01, 2009 1:35 > >> > To: Yaron Sheffer > >> > Cc: ipsec@ietf.org > >> > Subject: Re: [IPsec] Proposed work item: IKEv2 password > authentication > >> > (SPSK) > >> > > >> > > >> > Hello, > >> > > >> > As can be inferred by my previous posting on EAP-only > >> authentication, > >> > I favor this particular method for mutual authentication. > >> > > >> > I believe this is a general purpose exchange, useful for more than > >> the > >> > narrow focus of EAP-only, does not require extraneous encapsulations > >> or > >> > unnecessary code (ala EAP-only), and is secure regardless of its use > >> > (unlike EAP-only). > >> > > >> > I am committed to working on this as a WG work item. I agree to > >> continue > >> > contributing to the text and (co-)authoring the text. I solicit help, > >> and > >> > support, from those who are interested in this task. > >> > > >> > regards, > >> > > >> > Dan. > >> > > >> > On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: > >> > > 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-spsk-auth-00.txt. > >> > > > >> > > Please reply to the list: >
Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
Hi Martin, On Tue, December 1, 2009 1:27 am, Martin Willi wrote: > Hi Dan, > >> And in that case EAP encapsulation of the underlying key exchange would >> be completely pointless and extraneous, would double the number of >> messages required to complete the exchange, and would increase the >> amount >> of security-critical code. > > EAP authentication was not primarily included in IKEv2 to implement some > kind of password authentication on top if IKEv2, but to reuse existing > EAP methods and infrastructure. I understand. I'm not talking about EAP authentication in IKEv2 today. Please, don't misunderstand me. I'm not proposing to do away with EAP authentication in IKEv2, I'm proposing a more efficient, more secure, and simpler way of doing password-only authentication in IKEv2. > The most demanding user of IKEv2 currently is the mobile/telco industry; > There are several specs in 3GPP and 3GPP2 using it. Many of them have > chosen IKEv2 because they can use their existing EAP-AKA/SIM > infrastructure for authentication. > >> It seems to me that EAP-only authentication in IKEv2: >> 1. does not solve a general problem; > > It does. It allows to omit public key authentication in cases where > mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2 > spec that already uses EAP-AKA/TLS only authentication, but does not > follow this draft. I really see a need for this WG item. I guess I was just saying that certificate-less, password-based authentication is not general. It's specific to the problem of authenticating with only a password and no certificate. If 3GPP2 has a need for authentication with only a password and no certificate please take a look at EAP-pwd! That will, apparently, solve your problem. If it doesn't then the singular use of EAP-only IKEv2 authentication will not either. Furthermore, doing pointless encapsulations and doubling of messages does not really seem to solve _any_ problem. Keep in mind that IKE/IPsec is, fundamentally, a peer-to-peer protocol. While your client-server application is a very valid use case, it is not the only one and it is important to solve problems generally, with utility to all use cases, if possible. >> 2. solves the specific problem it is aimed at poorly-- doubling of >> the number of messages, requiring writing and testing of new >> state EAP state machines that are, otherwise, unnecessary > > If you're just talking about password authentication, yes. But this > allows IKEv2 to work in existing infrastructures (EAP over > RADIUS/DIAMETER). We currently see a strong demand for such solutions. IKEv2 already works in such infrastructure. Yes, I'm talking about password authentication. That's the only use for EAP-only authentication in IKEv2. Any other EAP authentication can already be handled in IKEv2 today. I'm glad you have a strong desire for using existing EAP authentication of IKEv2. But please understand that that is not what the topic under discussion is. >> To provide the benefits of EAP-only authentication [...] it would be >> much better to support the inclusion of "Secure PSK authentication" as >> a work item. > > Implementing password authentication on top of EAP may be one reason for > this draft, but there are several others. And the separated EAP layer > allows you to forward authentication to an existing AAA server. > Further, many vendors already have generic EAP support. Implementing PSK > authentication on top of it is probably simpler and more flexible than > integrating it in IKEv2 directly. Please tell me what other reasons there are for this draft. This draft solves one problem only-- using only a password to authenticate, with both sides requiring plaintext access to the password-- and that problem can be solved more simply and more securely than EAP-only, and in a way that is applicable to all use cases of IKE. Note that the EAP methods being used to justify EAP-only authentication in IKEv2 (the ones mentioned by the Yaron) DO NOT allow for forwarding of authentication to a AAA server. Other EAP methods might but, as I stated earlier, those are already handled today in IKEv2. The benefit you want to apply to this proposal is not valid and what you seem to be requiring is already provided for. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...)
Dan Harkins writes: > Groups 1 and 2 were defined in RFC 2409 and repeating them in a > subsequent RFC does not change that. RFC2409 has been obsoleted, so I do not want to refer to that, as people will then go to the RFC2409 and notice that it has been obsoleted by RFC4306, and will go to there and find the groups from RFC4306 appendix B.1 and B.2. The groups are same, so it does not really matter which document is referenced. > I suggest leaving the reference to RFC 2409 for groups 1 and 2 (and > 3 and 4 for that matter) that currently exists today at > http://www.iana.org/assignments/ipsec-registry, as of 2315 GMT on 30 > November 2009, aka "right now". I am NOT going to touch ipsec-registry. That is IKEv1 stuff that is already obsoleted, and there is no point of doing anything for that (and no need, as it does nto have range allocations). I am talking about IKEv2 registry (http://www.iana.org/assignments/ikev2-parameters) and there the references were already for RFC4306, not to RFC2409 (and it does not have groups 3 and 4 at all, those are not defined for IKEv2). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
Hi Dan, > And in that case EAP encapsulation of the underlying key exchange would > be completely pointless and extraneous, would double the number of > messages required to complete the exchange, and would increase the amount > of security-critical code. EAP authentication was not primarily included in IKEv2 to implement some kind of password authentication on top if IKEv2, but to reuse existing EAP methods and infrastructure. The most demanding user of IKEv2 currently is the mobile/telco industry; There are several specs in 3GPP and 3GPP2 using it. Many of them have chosen IKEv2 because they can use their existing EAP-AKA/SIM infrastructure for authentication. > It seems to me that EAP-only authentication in IKEv2: > 1. does not solve a general problem; It does. It allows to omit public key authentication in cases where mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2 spec that already uses EAP-AKA/TLS only authentication, but does not follow this draft. I really see a need for this WG item. > 2. solves the specific problem it is aimed at poorly-- doubling of > the number of messages, requiring writing and testing of new > state EAP state machines that are, otherwise, unnecessary If you're just talking about password authentication, yes. But this allows IKEv2 to work in existing infrastructures (EAP over RADIUS/DIAMETER). We currently see a strong demand for such solutions. > To provide the benefits of EAP-only authentication [...] it would be > much better to support the inclusion of "Secure PSK authentication" as > a work item. Implementing password authentication on top of EAP may be one reason for this draft, but there are several others. And the separated EAP layer allows you to forward authentication to an existing AAA server. Further, many vendors already have generic EAP support. Implementing PSK authentication on top of it is probably simpler and more flexible than integrating it in IKEv2 directly. Best regards Martin ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Hi Matthew, Please take a look at both proposals. There is no proposal to simply offer guidelines. Both of them are "new solutions" and modify the IKE exchange. One uses NOTIFY messages to indicate the new exchange and the other uses the critical bit to indicate the new exchange. I would be interested in your opinion as a developer which is better-- NOTIFY or critical bit-- and why. As a developer, I do not believe it is better to double the number of messages needed to do a key exchange, and do not believe it is better to require pointless encapsulations of a key exchange. If you disagree I would also be interested in knowing why. Dan. On Mon, November 30, 2009 11:10 pm, Matthew Cini Sarreo wrote: > From a developer point of view, I share the same opinion as Yaron about > this > issue. Instead of creating new solutions, I personally think that it would > be better to offer guidlines on how to implement current solutions (i.e > EAP) > and provide documents targeting implementers. This would create less > confusion and keep IKEv2 a clean, easy to understand and use protocol. > > Regards, > Matthew > > 2009/12/1 Yaron Sheffer > >> Hi everyone, >> >> [WG co-chair hat off] >> >> I believe this effort is misguided, and would be a waste of the WG time. >> >> EAP was added to IKEv2 to provide "legacy" (a.k.a. password) >> authentication. In the past it did not do it very well, but this is >> changing. We should improve the use of EAP in IKEv2, rather than >> replacing >> it by a homebrew solution. >> >> Specifically, the following EAP methods can be used today (or in the >> near >> future) for mutual password-based auth: >> >> - Dan's own EAP-PWD, >> http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-12 >> - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03 >> - The long expired EAP-SRP, >> http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 >> - A rumored EAP method based on the PAK protocol ( >> http://tools.ietf.org/html/draft-brusilovsky-pak-10) >> >> Embedding one of these methods as the single way to do mutual auth in >> IKE >> simply doesn't make sense. >> >> In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto >> protocol. It has had by far the least crypto review than the other three >> protocols. IMHO, this working group should NOT be developing new >> cryptographic protocols. This is not where our expertise lies. >> >> Lastly, one of the major criticisms with IKEv1 was the number of >> protocol >> modes. And here we are, with a proposal to add another mode to IKEv2. >> Doesn't seem like a good idea to me. >> >> Thanks, >>Yaron >> >> >> > -Original Message- >> > From: Dan Harkins [mailto:dhark...@lounge.org] >> > Sent: Tuesday, December 01, 2009 1:35 >> > To: Yaron Sheffer >> > Cc: ipsec@ietf.org >> > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication >> > (SPSK) >> > >> > >> > Hello, >> > >> > As can be inferred by my previous posting on EAP-only >> authentication, >> > I favor this particular method for mutual authentication. >> > >> > I believe this is a general purpose exchange, useful for more than >> the >> > narrow focus of EAP-only, does not require extraneous encapsulations >> or >> > unnecessary code (ala EAP-only), and is secure regardless of its use >> > (unlike EAP-only). >> > >> > I am committed to working on this as a WG work item. I agree to >> continue >> > contributing to the text and (co-)authoring the text. I solicit help, >> and >> > support, from those who are interested in this task. >> > >> > regards, >> > >> > Dan. >> > >> > On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: >> > > 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-spsk-auth-00.txt. >> > > >> > > Please reply to the list: >> > > >> > > - If this proposal is accepted as a WG work item, are you committing >> to >> > > review multiple versions of the draft? >> > > - Are you willing to contribute text to the draft? >> > > - Would you like to co-author it? >> > > >> > > Please also reply to the list if: >> > > >> > > - You believe this is NOT a reasonable activity for the WG to spend >> time >> > > on. >> > > >> > > If this is the case, please explain your position. Do not explore >> the >> > fine >> > > technical details (which will change anyway, once the WG gets hold >> of >> > the >> > > draft); instead explain why this is uninteresting for the WG or for >> the >> > > industry at large. Also, please mark the title clearly (e.g. "DES40- >> > export >> > > in IPsec - NO!"). >> > > ___ >> > > IPsec mailing list >> > > IPsec@ietf.org >> > > https://www.ietf.org/mailman/listinfo/ip
Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
Hi Yaron, On Mon, November 30, 2009 10:47 pm, Yaron Sheffer wrote: > Hello Dan, > > [WG co-chair hat off] > > EAP-only authentication is a small IKE extension that does not change the > existing IKE architecture; neither does it change many of the extant > implementations. Given the right EAP methods, it would provide us exactly > what EAP was supposed to provide from day one: mutual non-PKI > authentication. I don't know where you came up with the idea that EAP was supposed to provide us with mutual non-PKI authentication from day one. It was designed for PPP and the trust model for which it was designed is DRAMATICALLY DIFFERENT than the trust model used for IKE. > And the solution is generic: any suitable EAP method can be deployed, so > implementors can make their own security/interoperability/IPR/simplicity > tradeoffs, instead of having one specific authentication method mandated. Please do not overstate your proposal. The only type of EAP method that is suitable is one in which a password, and only a password, is the authentication credential, and each side possesses that credential. Any other EAP method can quite happily be handled in IKEv2 today, no need for new EAP-only authentication proposals. > To address your specific concerns: > > - The case of client-to-gateway authentication happens to be one of the > top use cases of IKE/IPsec. Certainly not a "small use case". I'm not > saying that EAP-only auth is limited to this use case, but it certainly > solves it well. I don't want to get in a case of dueling marketing departments but let's just say we disagree. Site-to-site IKE/IPsec is large, transport-only IKE/IPsec is less so, and the that became the UMA market put a serious dent in client-to-gateway IKEv2. But I will agree with you that client-to-gateway IKE/IPsec using IKEv1 and insecure proprietary hacks is also quite large today. And hopefully you will agree that it would be good to provide a _secure_ solution to that market. I will take issue with your statement about limited use of EAP-only auth. It really is limited. What you are proposing is for one, and only one, use case of IKEv2. And what you are proposing is more complicated than just solving it directly in IKE. You have failed to justify the increased complexity and decreased utility. > - It would depend very much on the specific product/scenario whether "both > client and server state machines" need to be implemented. Specifically > this is incorrect for client-to-gateway. > > - EAP as you well know is a 3-party protocol, it is not necessarily > terminated on the IKE peer. So it is incorrect to say that "both sides > MUST possess the shared secret" - exactly the right parties will need to: > the client and the authentication server. Actually EAP is a 2-party protocol that, for optimization reasons, has become viewed as a 3-party protocol. And therein lies the problem. Both sides will need to possess the shared secret for this proposal to be applicable to all use cases of IKEv2. Note that a simpler proposal that solves the exact problem you're trying to solve is applicable to all use cases of IKEv2. You have to decide whether your proposal has limited applicability or whether it requires unnecessary implementation of EAP state machines, you can't have both. I'm sure you will agree that encapsulating messages in EAP buys nothing and doubling the number of messages also buys nothing. But they both cost something. Again, we have cost with no gain with your proposal but less cost and more gain with mine. And now the security problem: an IKEv2 gateway can claim ANY identity during EAP-only authentication. That has serious implications with the security claims of IKE. If password-based authentication is provided as part of IKE this security problem goes away. > - EAP-only auth can also be applied to scenarios where no Auth Server is > deployed. However in these cases both peers would indeed need a full EAP > implementation. > > - The EAP community is (very slowly) coming to terms with EAP channel > bindings. While this is not provided by your EAP-PWD (and I hope this is > fixed before publication), EAP-EKE has been extended to add this > capability. Very slowly being the operative words. And this disclaimer also nullifies your previous statement of this being a "generic solution". It really only applies to EAP methods that are password-only and have some extra capability above-and-beyond EAP. On the other hand, we could have all this with less complexity by going with draft-harkins-ipsecme-spsk-auth. It's a choice of more complexity, less utility, and less security OR less complexity, more utility and more security. I don't understand why you want to go with the former. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Yaron, It is important for you to state what problem you're trying to solve. That problem is, simply, password-only authentication. To bring up the motivation for adding EAP to IKEv2 is quite irrelevant since EAP in IKEv2 today involves server-side authentication using a certificate. You want to do password authentication in IKE. Period. Full stop. And to do that you want to add a pointless encapsulation. And you want to do it with twice as many messages. And you want to require each side to implement both the client- and server-side state machines for this "solution" to be useful in the use cases defined in IKEv2. It seems to me that you need to justify why such EXTRA work is necessary when a simpler way of solving your problem is available. Don't just say "it doesn't make sense", justify why you are proposing more, extraneous work. Furthermore, I would be very interested in why you feel that a WG in the Security Area of the IETF is not the place to define cryptographic protocols and that it would be more appropriate for a WG in the Security Area to just use a protocol from the Network Area with protocols defined as individual submissions. Dan. On Mon, November 30, 2009 10:46 pm, Yaron Sheffer wrote: > Hi everyone, > > [WG co-chair hat off] > > I believe this effort is misguided, and would be a waste of the WG time. > > EAP was added to IKEv2 to provide "legacy" (a.k.a. password) > authentication. In the past it did not do it very well, but this is > changing. We should improve the use of EAP in IKEv2, rather than replacing > it by a homebrew solution. > > Specifically, the following EAP methods can be used today (or in the near > future) for mutual password-based auth: > > - Dan's own EAP-PWD, > http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-12 > - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03 > - The long expired EAP-SRP, > http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 > - A rumored EAP method based on the PAK protocol > (http://tools.ietf.org/html/draft-brusilovsky-pak-10) > > Embedding one of these methods as the single way to do mutual auth in IKE > simply doesn't make sense. > > In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto > protocol. It has had by far the least crypto review than the other three > protocols. IMHO, this working group should NOT be developing new > cryptographic protocols. This is not where our expertise lies. > > Lastly, one of the major criticisms with IKEv1 was the number of protocol > modes. And here we are, with a proposal to add another mode to IKEv2. > Doesn't seem like a good idea to me. > > Thanks, > Yaron > > >> -Original Message- >> From: Dan Harkins [mailto:dhark...@lounge.org] >> Sent: Tuesday, December 01, 2009 1:35 >> To: Yaron Sheffer >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication >> (SPSK) >> >> >> Hello, >> >> As can be inferred by my previous posting on EAP-only authentication, >> I favor this particular method for mutual authentication. >> >> I believe this is a general purpose exchange, useful for more than the >> narrow focus of EAP-only, does not require extraneous encapsulations or >> unnecessary code (ala EAP-only), and is secure regardless of its use >> (unlike EAP-only). >> >> I am committed to working on this as a WG work item. I agree to >> continue >> contributing to the text and (co-)authoring the text. I solicit help, >> and >> support, from those who are interested in this task. >> >> regards, >> >> Dan. >> >> On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: >> > 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-spsk-auth-00.txt. >> > >> > Please reply to the list: >> > >> > - If this proposal is accepted as a WG work item, are you committing >> to >> > review multiple versions of the draft? >> > - Are you willing to contribute text to the draft? >> > - Would you like to co-author it? >> > >> > Please also reply to the list if: >> > >> > - You believe this is NOT a reasonable activity for the WG to spend >> time >> > on. >> > >> > If this is the case, please explain your position. Do not explore the >> fine >> > technical details (which will change anyway, once the WG gets hold of >> the >> > draft); instead explain why this is uninteresting for the WG or for >> the >> > industry at large. Also, please mark the title clearly (e.g. "DES40- >> export >> > in IPsec - NO!"). >> > ___ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> >> >> >> Scanned by Check Point Total Security Gateway. >
