Hey all, we have implemented the draft and found a few issues. Overall, the separation of IKE_INTERMEDIATE and the draft-tjhai-ipsecme-hybrid-qske-ikev2-03 is not clear in some points.
I personally like the idea of having a document on how to add a "pre-auth" exchange to IKEv2, however weve found that the two documents depend quite strongly on each other, which we found a bit of an implementation issue: 1. The draft does not say anything about payloads to be carried in the IKE_INTERMEDIATE message (except SK payload), which means it could either transfer "any payload" or "no payload". >From a security perspective, I'd assume "no payload", which means the draft specifies how to send an empty SK payload between IKE_INIT and IKE_AUTH, where "empty" means encrypted padding. So basically, we have a (standard-track RFC) document describing a message which cannot (I'd almost say MUST NOT) be implemented without the requirement to implement an additional document describing the payload. 2. On the other hand, IKE_INTERMEDIATE describes how to use previously exchanged keys in order to secure (encrypt) the IKE_INTERMEDIATE traffic. If IKE_INTERMEDIATE is there to describe the messages and not the key exchange, I think the document should only say that the current key in the IKE SA should be used. I'm not 100% sure if especially point 1 is an actual issue for an IETF document and if so how to solve it. One idea would be to define a (maybe informational/experimental) document like "how to add an additional pre-auth exchange in IKEv2", which can then be used by e.g. draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the actual exchange. Another idea would be to define a list of allowed payloads (e.g. by IANA registry). If the WG thinks that this is not an issue or can be solved after adoption, we support adoption and we were about to show and discuss some details on that (and other PQKE related stuff) in a presentation in Prague. We just wanted to raise awareness and get a discussion on this (potential) issue before the adoption call ends. Regards Tobias > -----Ursprüngliche Nachricht----- > Von: IPsec <[email protected]> Im Auftrag von Panos Kampanakis > (pkampana) > Gesendet: Donnerstag, 14. März 2019 20:07 > An: 'Tero Kivinen' <[email protected]>; [email protected] > Betreff: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux- > 02 > > +1 on adopting this draft. > > -----Original Message----- > From: IPsec <[email protected]> On Behalf Of Valery Smyslov > Sent: Thursday, March 14, 2019 4:38 AM > To: 'Tero Kivinen' <[email protected]>; [email protected] > Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux- > 02 > > Hi, > > as author of the document I (obviously) support its adoption. > It's a building block for QSKE solution (at least how the WG sees it now) so I > think we should adopt it. > > Regards, > Valery. > > > This document has been stable for some time, and I think it is ready > > to go forward. Because of that I will start one week long WG > > adoptation call for this draft which will expire end of next week > > (2019-03-22). > > > > If you have any reasons why this should not be adopted as WG document, > > send email to the list as soon as possible. > > -- > > [email protected] > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
