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

"Tobias Guggemos" <guggemos@nm.ifi.lmu.de> Wed, 20 March 2019 17:06 UTC

Return-Path: <guggemos@nm.ifi.lmu.de>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32FC12426A for <ipsec@ietfa.amsl.com>; Wed, 20 Mar 2019 10:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH8MKSgN0ZGN for <ipsec@ietfa.amsl.com>; Wed, 20 Mar 2019 10:06:47 -0700 (PDT)
Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6651311AA for <ipsec@ietf.org>; Wed, 20 Mar 2019 10:06:42 -0700 (PDT)
Received: from DESKTOP58DFL8T (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 9918C35D9DE; Wed, 20 Mar 2019 18:06:40 +0100 (CET)
From: Tobias Guggemos <guggemos@nm.ifi.lmu.de>
To: 'Valery Smyslov' <smyslov.ietf@gmail.com>, 'Tero Kivinen' <kivinen@iki.fi>, ipsec@ietf.org
References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com>
In-Reply-To: <06b701d4deed$706f1310$514d3930$@gmail.com>
Date: Wed, 20 Mar 2019 18:06:40 +0100
MIME-Version: 1.0
Message-ID: <014001d4df3f$492fcc70$db8f6550$@nm.ifi.lmu.de>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQIABBzyAgABckXCAASJaAIAATTlQ
Content-Language: de
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="=-=MA/gNHKf0qaDLZ=-="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/hV4hePcfKzUz6AZf1Lhz-EydHew>
Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 17:06:55 -0000

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

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

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

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

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

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

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

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

> 
> 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 <ipsec-bounces@ietf.org> Im Auftrag von Panos
> > > > > Kampanakis
> > > > > (pkampana)
> > > > > Gesendet: Donnerstag, 14. März 2019 20:07
> > > > > An: 'Tero Kivinen' <kivinen@iki.fi>; ipsec@ietf.org
> > > > > Betreff: Re: [IPsec] WG adoptation call for
> > > > draft-smyslov-ipsecme-ikev2-aux-
> > > > > 02
> > > > >
> > > > > +1 on adopting this draft.
> > > > >
> > > > > -----Original Message-----
> > > > > From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Valery Smyslov
> > > > > Sent: Thursday, March 14, 2019 4:38 AM
> > > > > To: 'Tero Kivinen' <kivinen@iki.fi>; ipsec@ietf.org
> > > > > 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.
> > > > > > --
> > > > > > kivinen@iki.fi
> > > > > >
> > > > > > _______________________________________________
> > > > > > IPsec mailing list
> > > > > > IPsec@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/ipsec
> > > > >
> > > > > _______________________________________________
> > > > > IPsec mailing list
> > > > > IPsec@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ipsec
> > > > >
> > > > > _______________________________________________
> > > > > IPsec mailing list
> > > > > IPsec@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ipsec
> > > >
> > > > _______________________________________________
> > > > IPsec mailing list
> > > > IPsec@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ipsec