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

["Valery Smyslov" <[e-mail]>]

[I snipped some text to make message more readable]

> > > 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.
> 
> You're right it doesn't, but it leaves the impression that it's designed for the use case.

It's a false impression :-)

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

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.

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

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.

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

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.

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

OK, how about:

The implementation MUST NOT negotiate support for 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.

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

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

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

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

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

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

Regards,
Valery.

> Regards
> Tobias