Hi Tobias, > > 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. > > My opinion is, that IKE_INTERMEDIATE should not mention PQKE at all, if it is > meant to be a framework > document which is "just" there to define the message.
It doesn't. There's no reference to QSKE draft and Quantum Safe Key Exchange is only mentioned as a possible application for the draft in the Introduction section. > I know that the main motivation for IKE_INTERMEDIATE is PQKE, but I don't > feel that we're at a point where > we can actually say for sure that this is the one and only way for PQKE and, > thus, I'd prefer > IKE_INTERMEDIATE to be completely independent of any Key Exchange related > stuff! That's my intention too, we are in concert here. And in my opinion the draft makes no hint that QSKE is the only application, quite the opposite. > > > 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. > > I'm not an expert in this kind of (framework) documents at all. My question > is, is an empty IKE_INTERMEDIATE > a potential security issue? Which security issue? Can you please elaborate? > If there is a chance that this is a potential thread (and I fear it'll be > impossible to proof the opposite), my > feeling is that the document should say that IKE_INTERMEDIATE MUST NOT be > supported without the > support of at least one document defining the payload. That is implied. I can make this more explicit, by adding something like that: Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED notification only confirms that both parties support INTERMEDIATE exchange. It is not enough condition to start doing INTERMEDIATE exchange. A separate documents that utilize this exchange MUST define the conditions in which peers would do INTERMEDIATE exchanges, the conditions for ending the sequence of these exchanges and start IKE_AUTH, and the payloads these exchanges should carry. Is it OK for you? > That would actually remove the necessity to NOTIFY the support of > IKE_INTERMEDIATE, as any exchange > utilizing IKE_INTERMEDIATE (e.g. PQKE) would directly infer the necessity to > implement IKE_INTERMEDIATE > with a detailed description of the allowed payload. I don't think it's a good idea. Instead of decoupling INTERMEDIATE from its applications, it would make them more interdependent. > However, I'm happy to learn if (and why) this is not security thread at all =) I'm not sure I understand the security thread you are talking about. If your concern is that someone would use an empty INTERMEDIATE exchange, than the text above would address it. > > 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'd completely remove the second part and only write: > > 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. I'm generally OK with this, however I'm a bit concerned here that implementers might get a wrong impression that the keys calculated in IKE_SA_INIT never changes. The text that you snipped has the only purpose to warn implementers that this might not be the case. Don't you think it's a valid concern? > > > 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. > > The idea about using not standard track would be, that any document using > the IKE_INTERMEDIATE needs to > define the actual message. > I don't like this idea too much, but it would at least be clean that any > message is defined completely by any > future document. The drawback is that every document would need to redefine a negotiation, protection, authentication, error handling, interaction with other extensions etc. > > > 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 we had an IANA registry for every payload allowed in IKE_INTERMEDIATE, > that could easily be updated by > future documents by registering a new value. I don't think IANA registry is needed for that. In my opinion it's enough that every dependent document describes the content of INTERMEDIATE exchange. Look for example at INFORMATIONAL exchange. It's the same "Swiss army knife", and is used for a lot of purposes depending on the notifications it contains. Somehow we managed to deal with that without IANA registry that would list the notifications that could appear in INFORMATIONAL exchange. I don't see a big difference with INTERMEDIATE here, except that instead of notifications the dependent documents will define payload types for this exchange. > I don't say this is the only way to go, but I feel it's cleaner than just > saying it could be anything. I'd actually > prefer what I mentioned above, not allowing IKE_INTERMEDIATE to be > implemented without another > document defining the actual payload. Exactly, except that I'd s/implemented/used. You can implement a pure framework (just for the future), but you cannot use it without implementing another document utilizing it. Regards, Valery. > In any case, if we can discuss/change that after adoption, I'm completely > fine and support adoption. > > > > > > 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
