Tobias races good points to address, but that can be discussed after adoption too.
I’m in favour of adoption and I would like all ambiguity to be resolved so that this document can be implemented independently from any other future documents. Paul Sent from mobile device > On Mar 18, 2019, at 18:02, Tobias Guggemos <[email protected]> wrote: > > 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 we’ve 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
