Hi Tobias, > Hey all, > we have implemented the draft and found a few issues.
Glad to know. We can do an interoperability testing, I guess :-) > 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: The idea is that hybrid-qske document depends on ikev2-aux document and not vice versa. If this failed in your opinion, that must be fixed. > 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". True. > >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. You are right that the draft doesn't imply any requirements on the content of SK payloads, so sending empty SK payload is allowed. This is OK, since, e.g. the response to some payload in request message can be empty (just to complete exchange). > 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. Yes. And the draft explicitly says: The content of the INTERMEDIATE exchange messages depends on the data being transferred and will be defined by specifications utilizing this exchange. Should I add some normative language here to make this even more explicit? For example: The content of the INTERMEDIATE exchange messages depends on the data being transferred and MUST be defined by specifications utilizing this exchange. Note, that it's a common case with any framework documents - the draft describes only very basic things that must not depend on the content of the SK payload - how to negotiate INTERMEDIATE exchanges, how to authenticate them, how to handle errors etc. You can implement this draft alone, but it's useless per its own. > 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. Sorry, but in my reading the draft currently says exactly this: The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the INTERMEDIATE exchanges are computed in a standard fashion, as defined in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE exchange uses the most recently calculated keys before this exchange is started. The first INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] keys that were computed as result the IKE_SA_INIT exchange. If this INTERMEDIATE exchange performs additional key exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are used for encryption and authentication of next INTERMEDIATE exchange, otherwise the current keys are used, and so on. In my reading this text says exactly what you want it to say. It doesn't give any hints how the keys are calculated - it says: "use most recently calculated keys". So, if keys are not recalculated after each INTERMEDIATE exchange, then SK_* from IKE_SA_INIT are always used, otherwise the result of recalculation is used. How do you think the text can be improved to make this more clear? > 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. Standards Track RFC generally cannot have Normative reference to lower grade RFCs, like Informational or Experimental (there are exceptions, but it's a generic rule). So I think that INTERMEDIATE document must be Standards Track. > Another idea would be to define a list of allowed payloads (e.g. by IANA > registry). I'd rather to avoid this, as new payloads may appear in future. > 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. Thank you, Valery. > > 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
