Re: [IPsec] GDOI and G-IKEv2 payloads
Hi Toerless, first G-IKEv2 should be published as RFC. The draft is currently in WGLC (for a long time), but received very few reviews so far (and many thanks to all who reviewed it!). I'm planning to publish an updated version addressing Daniel's review soon. Once G-IKEv2 is standardized, there is no problem (IMHO) to do the equivalent of RFC8052 with it. Regards, Valery. > How would someone today do the equivalent of RFC8052 with G-IKEv2 ? > > On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote: > > Hi, > > > > I've got a question regarding the relation of G-IKEv2 and GDOI. > > > > I realized that G-IKEv2 will be the successor of GDOI and would have a question > regarding backward compatibility of payloads defined for GDOI. As the underlying > exchanges for the base key management changed from IKE to IKEv2 they will not > be backward compatible. Nevertheless, there have been enhancements of GDOI > for protocols used in the power system domain like GOOSE and Sampled Values, > which lead to the definition of new payloads for the ID, SA TEK and KD payloads to > accommodate the power system protocol parameters in RFC 8052. Likewise, using > the same approach new payloads of the same types have been defined to > distribute parameters for PTP (Precision Time Protocol) in IEC 62351-9. > > > > In general, I realized that there are similar payloads available in G-IKEv2 but I > was not quite sure, if it was a design criterion to have backward compatibility for > extensions/enhancements defined for GDOI to be usable also in G-IKEv2. Could > you please shed some light on this? > > > > Best regards > > Steffen > > > > -- > > Steffen Fries > > > > Siemens AG > > Technology > > Cybersecurity & Trust > > T CST > > Otto-Hahn-Ring 6 > > 81739 Munich, Germany > > Phone: +49 (89) 7805-22928 > > mailto:steffen.fr...@siemens.com > > www.siemens.com > > [Logo] > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann > Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive > Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; > Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin- > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > > ___ > 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] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods
On Mon, 5 Feb 2024, Panwei (William) wrote: Regarding how the responder handles the request containing the new Key Exchange methods (old name was DH Group) that it doesn’t understand, I’ve had a discussion with someone, but we failed to agree with each other due to different interpretations of RFC 7296. I’d like to hear more opinions from you experts. The handling I suggest is as follows: 1) if all KE methods proposed by the initiator are unknown to the responder, i.e., no KE method is acceptable, then the responder replies NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload. 2) if at least one acceptable KE method is included in the initiator’s proposals, the responder can select one acceptable KE method, ignore the unknown KE methods, and perform the next step of KE Payload processing. 2.1) if the KE method used in the KE payload happens to be the same as this selected KE method, then the responder normally replies with this selected KE method and the corresponding KE payload. 2.2) if the KE method used in the KE payload is different from this selected KE method, then the responder replies INVALID_KE_PAYLOAD with this selected KE method, regardless of whether the KE method used in the KE payload is known or unknown to the responder. that is correct. Note that the INVALID_KE_PAYLOAD can also contain the KE method(s) the responder is willing to use. This paragraph indicates that the responder should ignore the unknown KE methods in the SA payload because the new KE methods can be considered as new Transform Attributes. Yes, it should ignore unknown KEs. This allows newer software/versions to attempt newer KEs without breaking with older implementations that do not support the newer KEs. If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. I guess that SHOULD is a little odd. It really means "it should pick one from the responder list, that falls within its own local policy as valid to use, otherwise it must terminate the connection". This paragraph indicates that the initiator can suggest a KE method regardless of whether it is known to the responder. IKE assumes both peers do not know each others capabilities before the negotiation starts. The latter sentence indicates that the responder can continue the negotiation when the KE method in the KE payload is unknown and just needs to reply INVALID_KE_PAYLOAD with the correct KE method. No, it cannot "continue". INVALID_KE_PAYLOAD is an errror. If this is sent in the IKE_SA_INIT reply, the responder isn't even expected to keep any state. The initiator has to "start from scratch" using a different KE method. The responder responds "from scratch" to that message. However, others suggest that the responder should terminate the IKE exchange without reply, when the KE method used in the KE payload is unknown to the responder, even if there are other acceptable KE methods proposed in the SA payload. One must NEVER terminate without sending a reply. Doing so only causes the initiator to retransmit its packet, thinking the packet was dropped. It will only make things worse. Always reply. But in the case of INVALID_KE_PAYLOAD, the responder can get away with not keeping (or even creating) state. Because they feel the unknown KE method in the KE payload means that the whole packet is an invalid packet, and discarding this packet is the thing to do. That is wrong :) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods
Panwei \(William\) writes: > The handling I suggest is as follows: > > 1) if all KE methods proposed by the initiator are unknown to the > responder, i.e., no KE method is acceptable, then the responder replies > NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload. > > 2) if at least one acceptable KE method is included in the initiator’s > proposals, the responder can select one acceptable KE method, ignore the > unknown KE methods, and perform the next step of KE Payload processing. > >2.1) if the KE method used in the KE payload happens to be the same as > this selected KE method, then the responder normally replies with this > selected KE method and the corresponding KE payload. > >2.2) if the KE method used in the KE payload is different from this > selected KE method, then the responder replies INVALID_KE_PAYLOAD with this > selected KE method, regardless of whether the KE method used in the KE payload > is known or unknown to the responder. This is correct processing. Note, that any unknown KE method cannot be accaptable for the policy, thus they are not allowed by the policy, and if there are any KE methods which are acceptable to policy we use that, and if the KE payload is not using that you send INVALID_KE_PAYLOAD and indicate the KE method you want to use. This processing is same for the known and unknown KE methods, there is no difference there. Of course the initiator will include the exactly same SA payload listing all those unknown KE methods when it retries with the KE method listed in the INVALID_KE_PAYLOAD. > However, others suggest that the responder should terminate the IKE > exchange without reply, when the KE method used in the KE payload is > unknown to the responder, even if there are other acceptable KE > methods proposed in the SA payload. If there is anything in the RFC7296 that would suggest that kind of processing is valid, we need to fix that. The RFC7296 tries to be extendable, thus it tries to ignore unknown values, and process things without them. For example in implementation I was familiar with there were not unknown algorithms, all values for algorithms or methods were valid from IKEv2 point of view, and those values were then matched against policy, but of course policy only allowed values that implementation actually recognized... > Because they feel the unknown KE method in the KE payload means that > the whole packet is an invalid packet, and discarding this packet is > the thing to do. I have no idea where they think RFC7296 says anything like that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IANA registries and WESP
Just in case, this has not been reported earlier, I have the impression WESP should be indicated as an IPv6 Header Extension in [1]. If that is the case we should also add it there in the Header Extension registry in [2]. If we were to do some clean up [1] has a few missing keywords, and keywords from [1] should also be reported in [2] - or [2] completely removed. Yours, Daniel [1] https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml [2] https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml#ipv6-parameters-1 -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] GDOI and G-IKEv2 payloads
How would someone today do the equivalent of RFC8052 with G-IKEv2 ? On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote: > Hi, > > I've got a question regarding the relation of G-IKEv2 and GDOI. > > I realized that G-IKEv2 will be the successor of GDOI and would have a > question regarding backward compatibility of payloads defined for GDOI. As > the underlying exchanges for the base key management changed from IKE to > IKEv2 they will not be backward compatible. Nevertheless, there have been > enhancements of GDOI for protocols used in the power system domain like GOOSE > and Sampled Values, which lead to the definition of new payloads for the ID, > SA TEK and KD payloads to accommodate the power system protocol parameters in > RFC 8052. Likewise, using the same approach new payloads of the same types > have been defined to distribute parameters for PTP (Precision Time Protocol) > in IEC 62351-9. > > In general, I realized that there are similar payloads available in G-IKEv2 > but I was not quite sure, if it was a design criterion to have backward > compatibility for extensions/enhancements defined for GDOI to be usable also > in G-IKEv2. Could you please shed some light on this? > > Best regards > Steffen > > -- > Steffen Fries > > Siemens AG > Technology > Cybersecurity & Trust > T CST > Otto-Hahn-Ring 6 > 81739 Munich, Germany > Phone: +49 (89) 7805-22928 > mailto:steffen.fr...@siemens.com > www.siemens.com > [Logo] > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann > Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive > Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; > Registered offices: Berlin and Munich, Germany; Commercial registries: > Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods
Hi folks, Several new Key Exchange methods were defined after RFC 7296 was published. (See https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8) For example, RFC 8031 introduced two new KE methods, Curve25519 (KE Method ID = 31) and Curve448 (KE Method ID = 32). There may be more new KE methods defined in the future, e.g., the PQC KEM may be introduced into IKEv2. Regarding how the responder handles the request containing the new Key Exchange methods (old name was DH Group) that it doesn’t understand, I’ve had a discussion with someone, but we failed to agree with each other due to different interpretations of RFC 7296. I’d like to hear more opinions from you experts. The handling I suggest is as follows: 1) if all KE methods proposed by the initiator are unknown to the responder, i.e., no KE method is acceptable, then the responder replies NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload. 2) if at least one acceptable KE method is included in the initiator’s proposals, the responder can select one acceptable KE method, ignore the unknown KE methods, and perform the next step of KE Payload processing. 2.1) if the KE method used in the KE payload happens to be the same as this selected KE method, then the responder normally replies with this selected KE method and the corresponding KE payload. 2.2) if the KE method used in the KE payload is different from this selected KE method, then the responder replies INVALID_KE_PAYLOAD with this selected KE method, regardless of whether the KE method used in the KE payload is known or unknown to the responder. My logic is as follows: In section 3.3.6 Attribute Negotiation of RFC 7296, it says: Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and Transform Attributes to be defined in the future. This paragraph indicates that the responder should ignore the unknown KE methods in the SA payload because the new KE methods can be considered as new Transform Attributes. Also in section 3.3.6, it says: Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. This paragraph indicates that the initiator can suggest a KE method regardless of whether it is known to the responder. The latter sentence indicates that the responder can continue the negotiation when the KE method in the KE payload is unknown and just needs to reply INVALID_KE_PAYLOAD with the correct KE method. However, others suggest that the responder should terminate the IKE exchange without reply, when the KE method used in the KE payload is unknown to the responder, even if there are other acceptable KE methods proposed in the SA payload. Because they feel the unknown KE method in the KE payload means that the whole packet is an invalid packet, and discarding this packet is the thing to do. I’d like to hear more opinions from you experts. Regards & Thanks！ Wei PAN (潘伟) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] GDOI and G-IKEv2 payloads
Hi Valery, Thank you for the prompt answer. This is somehow what I have expected. Just wanted to double check. So there is at least the chance to proceed with the approach picked in RFC 8052. It still requires specification, but allows for taking the same approach. This would be important to have at least the same semantic of the payloads. That already answers my question. Best regards Steffen From: Valery Smyslov Sent: Monday, February 5, 2024 8:52 AM To: Fries, Steffen (T CST) ; ipsec@ietf.org Subject: RE: [IPsec] GDOI and G-IKEv2 payloads Hi, Steffen, in general, G-IKEv2 is not backward compatible with GDOI (likewise IKEv2 is not backward compatible with IKEv1). For this reason extensions defined for G-DOI should be redefined for G-IKEv2 (once it becomes an RFC). >From my reading of RFC 8052, it doesn't define new payloads for GDOI, instead >new ID type, Protocol ID etc. are specified. The same approach could be used for G-IKEv2 too. Regards, Valery. Hi, I've got a question regarding the relation of G-IKEv2 and GDOI. I realized that G-IKEv2 will be the successor of GDOI and would have a question regarding backward compatibility of payloads defined for GDOI. As the underlying exchanges for the base key management changed from IKE to IKEv2 they will not be backward compatible. Nevertheless, there have been enhancements of GDOI for protocols used in the power system domain like GOOSE and Sampled Values, which lead to the definition of new payloads for the ID, SA TEK and KD payloads to accommodate the power system protocol parameters in RFC 8052. Likewise, using the same approach new payloads of the same types have been defined to distribute parameters for PTP (Precision Time Protocol) in IEC 62351-9. In general, I realized that there are similar payloads available in G-IKEv2 but I was not quite sure, if it was a design criterion to have backward compatibility for extensions/enhancements defined for GDOI to be usable also in G-IKEv2. Could you please shed some light on this? Best regards Steffen -- Steffen Fries Siemens AG Technology Cybersecurity & Trust T CST Otto-Hahn-Ring 6 81739 Munich, Germany Phone: +49 (89) 7805-22928 mailto:steffen.fr...@siemens.com www.siemens.com [Logo] Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
