Subject: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Mar 2019 05:30:30 +0200

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-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Mar 2019 11:38:01 +0300

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.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 14 Mar 2019 19:06:53 +0000

+1 on adopting this draft. 

-----Original Message-----
From: IPsec <[email-masked]> On Behalf Of Valery Smyslov
Sent: Thursday, March 14, 2019 4:38 AM
To: 'Tero Kivinen' <[email-masked]>; [email-masked]
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.

---

From: "Tobias Guggemos" <[email-masked]>
Date: Mon, 18 Mar 2019 18:02:12 +0100

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-masked]> Im Auftrag von Panos Kampanakis
> (pkampana)
> Gesendet: Donnerstag, 14. März 2019 20:07
> An: 'Tero Kivinen' <[email-masked]>; [email-masked]
> Betreff: Re: [IPsec] WG adoptation call for
draft-smyslov-ipsecme-ikev2-aux-
> 02
> Subject: Re: [IPsec] WG adoptation call for
draft-smyslov-ipsecme-ikev2-aux-
> 02
so I
> think we should adopt it.
> 
> Regards,
> Valery.
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Mar 2019 18:08:20 +0100

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-masked]> wrote:
> 
> Hey all,

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 19 Mar 2019 11:30:15 +0300

Hi Tobias,

> we have implemented the draft and found a few issues.

Glad to know. We can do an interoperability testing, I guess :-)

> 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.

> transfer "any payload" or "no payload".

True.

> 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). 

> 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.

> exchange, I think the document should only say that the current key in the

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?

> be used by e.g. draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the

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

I'd rather to avoid this, as new payloads may appear in future.

> issue before the adoption call ends.

Thank you,
Valery.

---

From: "Tobias Guggemos" <[email-masked]>
Date: Tue, 19 Mar 2019 18:28:40 +0100

> Glad to know. We can do an interoperability testing, I guess :-)

Would be great :-)

> > 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:
> 

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.
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!

> > IKE_INTERMEDIATE message (except SK payload), which means it could
> > either transfer "any payload" or "no payload".
> 
> True.
> 
> > 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.
> 
> 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?
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 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.
However, I'm happy to learn if (and why) this is not security thread at all =)

> > exchange, I think the document should only say that the current key in
> > the IKE SA should be used.
> 
> "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.
> 

I'd completely remove the second part and only write:

    is started.  

> > 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.

> 
> > Another idea would be to define a list of allowed payloads (e.g. by
> > IANA registry).
> 

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 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.

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
> >
> > > > 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
> > > > If you have any reasons why this should not be adopted as WG
> > > > document, send email to the list as soon as possible.
> > > > --
> > > > [email-masked]
> > > >

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 20 Mar 2019 10:20:46 +0300

Hi Tobias,

> 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.

> 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.

>     exchange uses the most recently calculated keys before this exchange

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 don't like this idea too much, but it would at least be clean that any message is defined completely by any

The drawback is that every document would need to redefine a negotiation,
protection, authentication, error handling, interaction with other extensions etc.

> 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.

---

From: Andreas Steffen <[email-masked]>
Date: Wed, 20 Mar 2019 11:11:32 +0100

Kind regards

Andreas

> adoptation call for this draft which will expire end of next week
======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==

---

From: "Tobias Guggemos" <[email-masked]>
Date: Wed, 20 Mar 2019 18:06:40 +0100

Hey
> > 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.

That's now really a discussion of details, but do we really need this as about 1/3 of the introduction?
I just don't like that the draft goes back to this use case during the description of the used keys.
However, my feelings about this are not so strong, that I see it as a show-stopper.

> 
> > 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
> And in my opinion the draft makes no hint that QSKE is the only application,
> quite the opposite.

You're right it doesn't, but it leaves the impression that it's designed for the use case.

> > > > message which cannot (I'd almost say MUST NOT) be implemented
> > > > without the requirement to implement an additional document
> > > > describing the
> > > payload.
> > >
> > > 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?
> 

Ok, I'm basically only speculating now:
1) What about an attacker who just sends empty messages to an responder supporting IKE_INTERMEDIATE? 
The state machine will never leave the state of waiting for an IKE_AUTH. 
2) What about a quantum attacker who breaks the IKE_INIT (in real-time) and just floods the responder with empty IKE_INTERMEDIATE.

This might not be a very realistic attack, but my question is, can you make sure that it is not an issue? 

The important thing I'd like to mention:
I think, if we can avoid an issue by design - by excluding an option we don't necessarily need - we should do that and not the other way around.

> > 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
> 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?

At least, it makes it clearer!
I personally would like to make it explicitly impossible to support IKE_INTERMEDIATE with an empty payload. (unless there is an application using an empty payload as some kind of a response)

The current wording says: The implementation MAY support IKE_INTERMEDIATE but MUST NOT use it without an application.
My preferred approach would be: The implementation MUST NOT support IKE_INTERMEDIATE without an application. 

My thinking is, you'd like to negotiate an application  (e.g. PQKE) which needs IKE_INTERMEDIATE, so it's all about the application anyway.
So if the application needs IKE_INTERMEDIATE, it wouldn't work if IKE_INTERMEDIATE is not supported anyways.

> > 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
> I don't think it's a good idea. Instead of decoupling INTERMEDIATE from its
> applications, it would make them more interdependent.
> 
> > > "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.
> > >
> 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.

It's a valid concern, but a concern which should be addressed by the document describing the key update.
On the other hand, what if the additional Key Exchange would say that you should not do that for any reason, which would be the ruling document?
That would be even more confusing (although I admit the chances for this case are quite low).

> > > > I'm not 100% sure if especially point 1 is an actual issue for an
> > > > IETF document and if so how to solve it.
> > > > document like "how to add an additional pre-auth exchange in
> > > > IKEv2", which can then be used by e.g.
> > > 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.
> 
True!

> > > > Another idea would be to define a list of allowed payloads (e.g.
> > > > by IANA registry).
> > >
> > 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.
> 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.
> 

The difference with INFORMATIONAL is, that you have a secured channel. 
At the time of INTERMEDIATE, you still build this channel and, thus, I think a more conservative approach of white-listing is better. 

That doesn't mean that an IANA registry is the right way to go, it's just one. 
I'd just like to prevent any miss-use of INTERMEDIATE, as I beliebe it's a highly security critical step.
There are definitely multiple ways of doing that, but I think that should be the goal.

> > 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.

Maybe we could replace "used" with "supported"?
Regards
Tobias

> > > > 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.
> > > > > It's a building block for QSKE solution (at least how the WG
> > > > > sees it
> > > > > now)
> > > > so I
> > > > > > 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).
> > > > > >

---

From: Tobias Heider <[email-masked]>
Date: Wed, 20 Mar 2019 21:48:31 +0100

Hi Valery,

>> If there is a chance that this is a potential thread (and I fear
>> it'll be impossible to proof the opposite), my
> 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,
I was wondering about what happens when multiple documents utilize the
IKE_INTERMEDIATE exchange
at the same time.
Can two different documents utilize a single exchange of
IKE_INTERMEDIATE messages,
or must every document add an additional exchange of IKE_INTERMEDIATE
messages?

Currently the only "user" is the Hybrid PQKE draft which adds up to
seven INTERMEDIATE exchanges before the IKE_AUTH,
could i just define a draft that includes an additional payload in the
first INTERMEDIATE exchange (not knowing whether Hybrid KE is used or not)
or would i have to add an eighth INTERMEDIATE exchange?

I couldn't find any info on this in the current draft and i feel like
this is quite relevant for future users of the exchange.

Regards,
(another) Tobias

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Mar 2019 10:48:22 +0300

[I snipped some text to make message more readable]

> You're right it doesn't, but it leaves the impression that it's designed for the use case.

It's a false impression :-)

> This might not be a very realistic attack, but my question is, can you make sure that it is not an issue?

In my view it's not how INTERMEDIATE should be dealt with. 
Firstly, sole exchange of INTERMEDIATE_EXCHANGE_SUPPORTED
notifications is not enough condition for INTERMEDIATE exchange to happen. 
There must be some other conditions, that must be defined
in the documents utilizing this exchange. Moreover, both peers
must have common view on how many such exchanges should be done
and in what order. Secondly, I cannot see any relevance to empty
SK payload in the examples you provided. The same attacks can
happen regardless on whether the content of SK is empty or not.
For example, in hybrid-qske the initiator could initiate more
INTERMEDIATE exchanges than the number of negotiated PQ methods,
so that the responder would receive the unexpected request.
And thirdly, the similar situation could also take place even with
core IKEv2, if the initiator sends, say INFORMATIONAL
instead of IKE_AUTH.

So, in your examples above, the responder would treat unexpected 
INTERMEDIATE as inappropriate exchange (as it would treat there 
any exchange except for IKE_AUTH). Since ICV is verified, there is
a clear protocol error and responder would silently delete half-created
SA. However, if your implementation is smart enough and you are concerned
about Quantum Computers breaking initial DH (your example 2),
then you can just ignore unexpected exchange and continue to wait
some (short period of) time for a proper one. If it wouldn't come - 
delete SA.

> that and not the other way around.

I don't see it's an issue. More precisely, I can see it as a generic issue,
not particularly concerned with empty INTERMEDIATE messages.

> At least, it makes it clearer!

OK.

> I personally would like to make it explicitly impossible to support IKE_INTERMEDIATE with an empty payload.
> (unless there is an application using an empty payload as some kind of a response)

See above.

> My preferred approach would be: The implementation MUST NOT support IKE_INTERMEDIATE without an

OK, how about:

The implementation MUST NOT negotiate support for INTERMEDIATE without an application.

> So if the application needs IKE_INTERMEDIATE, it wouldn't work if IKE_INTERMEDIATE is not supported

It depends. I can imagine extensions that can run w/o INTERMEDIATE, but can benefit
if it is supported...

> That would be even more confusing (although I admit the chances for this case are quite low).

I think it's enough to add some text to this draft that warns implementers that 
the IKE SA keys may change as a result of INTERMEDIATE exchanges.

> There are definitely multiple ways of doing that, but I think that should be the goal.

In my opinion it's enough if dependent document define the content.

> Maybe we could replace "used" with "supported"?

is "negotiated" or "advertised support for" OK here?

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Mar 2019 11:02:04 +0300

Hi Tobias,

> or must every document add an additional exchange of IKE_INTERMEDIATE

It's a good question. My idea is that each application document
must define this, as well as the order of INTERMEDIATE exchanges,
if it matters. So, I assume that by default each application
will utilize its own INTERMEDIATE , but some applications could
benefit from piggybacking. But this must be clearly described
in corresponding document.

> or would i have to add an eighth INTERMEDIATE exchange?

I think that corresponding application document must define this.
QSKE exchanges would most probably take place before any other 
INTERMEDIATE exchange, since they update the keys and increase
IKE SA protection, but again, it must be defined in the application
documents.

> this is quite relevant for future users of the exchange.

I don't think it must be defined in this draft. Instead, it must be
defined in the documents utilizing this exchange. Note, that 
these documents will appear one by one, so every next published 
document must have a section describing how this application
of INTERMEDIATE should deal with the already defined
applications (whether it is OK to combine payloads or not,
what is the relative order etc.)

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Mar 2019 05:12:03 -0400 (EDT)

> in corresponding document.

I would think it quite differently. Each protocol extension just puts
payloads in the IKE_SA_INIT and once that one becomes too big, the
IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE.
This document defines what goes into IKE_SA_INIT, so the rest (eg new
stuff) ca ngo into IKE_INTERMEDIATE.

> I think that corresponding application document must define this.

I don't see why they would need to do that? For example, imagine I
add a large notify payload that would cause IKE_SA_INIT fragmentation,
the IKE daemon looks what payloads to put in IKE_SA_INIT and the
non-listed Notify payload would be put into one or more
IKE_INTERMEDIATE exchanges.

Paul

---

From: Tobias Heider <[email-masked]>
Date: Thu, 21 Mar 2019 10:16:00 +0100

>>>> 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? >> I was wondering about what
happens when multiple documents utilize >> the IKE_INTERMEDIATE exchange
at the same time. Can two different >> documents utilize a single
exchange of IKE_INTERMEDIATE messages, >> or must every document add an
additional exchange of >> IKE_INTERMEDIATE messages? > > It's a good
question. My idea is that each application document must > define this,
as well as the order of INTERMEDIATE exchanges, if it > matters. So, I
assume that by default each application will utilize > its own
INTERMEDIATE , but some applications could benefit from > piggybacking.
But this must be clearly described in corresponding > document
In that case, wouldn't it be better to not have a single
IKE_INTERMEDIATE exchange type
ID but one for each document and use-case.
That way an implementation could easily check the exchange type, check
if the SA is in
a state to accept this specific type of exchange, and then check if the
exchange type and
contained payloads match. IMO this would allow packet handling and parsing
implementations a lot more robust and allow to filter corrupt/unexpected
packets early.

>> Currently the only "user" is the Hybrid PQKE draft which adds up >> to seven INTERMEDIATE exchanges before the IKE_AUTH, could i just >>
define a draft that includes an additional payload in the first >>
INTERMEDIATE exchange (not knowing whether Hybrid KE is used or >> not)
or would i have to add an eighth INTERMEDIATE exchange? > > I think that
corresponding application document must define this. > QSKE exchanges
would most probably take place before any other > INTERMEDIATE exchange,
since they update the keys and increase IKE SA > protection, but again,
it must be defined in the application > documents. >> I couldn't find
any info on this in the current draft and i feel >> like this is quite
relevant for future users of the exchange. > > I don't think it must be
defined in this draft. Instead, it must be > defined in the documents
utilizing this exchange. Note, that these > documents will appear one by
one, so every next published document > must have a section describing
how this application of INTERMEDIATE > should deal with the already
defined applications (whether it is OK > to combine payloads or not,
what is the relative order etc.) Then we must be incredibly cautious
that every document using IKE_INTERMEDIATE
specifies explicitly what happens if other known users are used in
conjunction, as well as
what happens for every possible combination of other known users.
If one document for example would specify to always be the first
INTERMEDIATE
exchange, it would block any following document from doing the same
without losing compatibility, as there clearly can't be two first
INTERMEDIATE exchanges.

In that case, isn't the effort of having to explicitly specify every
single case actually the
same as if every of these documents would simply specify it's own
exchange that
takes place between IKE_SA_INIT and IKE_AUTH?
What is the advantage of using INTERMEDIATE then, instead of just
rolling your own
solution?

Regards,
Tobias

---

From: Tobias Heider <[email-masked]>
Date: Thu, 21 Mar 2019 10:25:55 +0100

> stuff) ca ngo into IKE_INTERMEDIATE.
I like that idea actually. It would be nice though to have some fixed
order for
additional payloads, as we always had a fixed order for expected payloads.
> IKE_INTERMEDIATE exchanges.
Indeed.
I think the main advantage of IKE_INTERMEDIATE could be that specific
"users" would not have to take care of this in their documents because it is
solved once in a generic way.

Regards,
Tobias

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Mar 2019 14:37:01 +0300

Hi Paul,

>From implementer's point of view it's better if the possible content
of each message be clearly defined. It simplifies parsing message and 
state machine...

> IKE_INTERMEDIATE exchanges.

I don't see any problem here. You can write an application document
saying that once INTERMEDIATE is negotiated (and some other 
thing happened, indicating mutual support for the following),
the peers may offload there whatever they want (and makes sense) 
from IKE_SA_INIT. I just don't want such things take place sporadically,
by sole fact that INTERMEDIATE is supported. Otherwise Tobias G.'s
concerns are applied.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Mar 2019 14:44:36 +0300

In that case, isn't the effort of having to explicitly specify every single case actually the 
same as if every of these documents would simply specify it's own exchange that
takes place between IKE_SA_INIT and IKE_AUTH?
What is the advantage of using INTERMEDIATE then, instead of just rolling your own
solution?

          The advantage is that some common things (like authentication
          of the intermediate exchange, its protection, error handling etc.)
          remain the same. So you don’t need to specify this again
          and you can have a single piece of code for this.

          Note, that we don’t have separate exchanges for e.g. deleting SAs,
          reporting errors, liveness checking, - it’s a single INFORMATIONAL
          that is used for all these (and many other) purposes.

          Regards,
          Valery

Regards,
Tobias

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Mar 2019 14:47:04 +0300

> additional payloads, as we always had a fixed order for expected payloads.

IKEv2 has no restrictions on payloads order.

> solved once in a generic way.

True. Besides specification, there is an advantage that a single piece of code will 
take care of some INTERMEDIATE core functions (like its authentication etc.)

Regards,
Valery.

---

From: Tobias Heider <[email-masked]>
Date: Thu, 21 Mar 2019 13:23:33 +0100

> IKEv2 has no restrictions on payloads order.
Right. It would have to have some if it was working the way Paul said
though,
because you would have to make sure at least SA, KEx, and Nx stay in the
IKE_SA_INIT
message or otherwise you can't use SK in the IKE_INTERMEDIATE.

---

From: "Tobias Guggemos" <[email-masked]>
Date: Thu, 21 Mar 2019 16:19:42 +0100

> [I snipped some text to make message more readable]
Same here :-)

> > I think, if we can avoid an issue by design - by excluding an option
> > we don't necessarily need - we should do that and not the other way
> around.
> 
> I don't see it's an issue. More precisely, I can see it as a generic issue, not
> particularly concerned with empty INTERMEDIATE messages.
> 

I see your point and I think making explicitly sure that support/negotitation of IKE_INTERMEDIATE without an application addresses the comment anyway!

> > The current wording says: The implementation MAY support
> > IKE_INTERMEDIATE but MUST NOT use it without an application.

That sounds good for me. 
The question remains if it is than necessary to negotiate INTERMEDIATE explicitly, but that this is something I really don't care too much! :-)

> > My thinking is, you'd like to negotiate an application  (e.g. PQKE)
> > which needs IKE_INTERMEDIATE, so it's all about the application anyway.
> > So if the application needs IKE_INTERMEDIATE, it wouldn't work if
> > IKE_INTERMEDIATE is not supported anyways.
> 
> It depends. I can imagine extensions that can run w/o INTERMEDIATE, but
> can benefit if it is supported...
> 

Good point!

> > > > 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
> > > 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.
> >

I think I like negotiated!

---

From: "Tobias Guggemos" <[email-masked]>
Date: Fri, 22 Mar 2019 09:49:23 +0100

Hey Paul and Valery,
> Hi Paul,
> 
> > > It's a good question. My idea is that each application document must
> > > define this, as well as the order of INTERMEDIATE exchanges, if it
> > > matters. So, I assume that by default each application will utilize
> > > its own INTERMEDIATE , but some applications could benefit from
> > > piggybacking. But this must be clearly described in corresponding
> > > document.
> >
> > payloads in the IKE_SA_INIT and once that one becomes too big, the IKE
> > daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE.
> of each message be clearly defined. It simplifies parsing message and state
> machine...
> 

I think I go with Valery here. 
Otherwise it feels like fragmenting IKE_SA_INIT, which was (as far as I remember) not what the WG wanted and the main reason for the original IKE_AUX draft.

On the other hand, I'd also prefer if not every application uses a new INTERMEDIATE message, but putting all  information which can be transported within one INTERMEDIATE in one single message.
I think IKE_INTERMEDIATE should be to define the message and the application should define the INTERMDIATE's payload. 
If any application needs several consecutive IKE_INTERMEDIATE's, it needs to be defined there, but the default case should be *one* INTERMEDIATE.
But that might be a discussion for the application's drafts and not for IKE_INTERMEDIATE.

> > I don't see why they would need to do that? For example, imagine I add
> > a large notify payload that would cause IKE_SA_INIT fragmentation, the
> > IKE daemon looks what payloads to put in IKE_SA_INIT and the
> I don't see any problem here. You can write an application document saying
> that once INTERMEDIATE is negotiated (and some other thing happened,
> indicating mutual support for the following), the peers may offload there
> whatever they want (and makes sense) from IKE_SA_INIT. I just don't want
> such things take place sporadically, by sole fact that INTERMEDIATE is
> supported. Otherwise Tobias G.'s concerns are applied.
> 
> Regards,
> Valery.
> 
> > Paul
> >