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

"Valery Smyslov" <smyslov.ietf@gmail.com> Tue, 19 March 2019 08:30 UTC

Return-Path: <smyslov.ietf@gmail.com>
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 6268C1274A1 for <ipsec@ietfa.amsl.com>; Tue, 19 Mar 2019 01:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iAR8wJqyjq1Z for <ipsec@ietfa.amsl.com>; Tue, 19 Mar 2019 01:30:22 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BA01311F6 for <ipsec@ietf.org>; Tue, 19 Mar 2019 01:30:21 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id y18so13767886lfe.1 for <ipsec@ietf.org>; Tue, 19 Mar 2019 01:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Bs5g+WmtCOA8xXRggF7qiYu/e7F5nFqPWCeMWqYxQOE=; b=Z10x1y94c13uydBBN3gniH9ZJfvUO4u9LvOPpGoLkbHKbcN32Og/J9mfFqfFgqjzeR sZ46uVs5nn1nBx3hLJdBUjaBdZ2QNV23ZMUvIJa380e9sGTcU++Rx7mGoxDzwePOOh0N 8wGEC8yG7s3SJfpIARimrnqqlLWkPVcMEBgV37MlQDLMLjQ4YwHO07Wfrioq43z9XaTz 0xolw7ofw5xrqi4B3owT7NoZCE6MCdMuXYVN1M/lWgvU69rhagfQjiCKbXrnZpFEt7fh Dsk5JkdWmYg0RUUke8wsgnVhxA6M9sUp9bhYrsFImG+ZqOJ6ur/qrcyxhVCSYusai5+Y ByMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Bs5g+WmtCOA8xXRggF7qiYu/e7F5nFqPWCeMWqYxQOE=; b=PZs0R8rcN69Fcm8RcL8OJgh4uXVN4OtbW8AirYhcsembE0Gw5tugxR7Zjasnc5HcY1 MiMFFdUX7fx7iPx4VQinmtHKV8vlt971VYLHxyzxXN0HvF13ciL+sJOxjpKakZ3si1aQ iiukeWqKFE8HfwSF41ITDnvFq0iV8NHu+CaxP3Ai41MIKQhwSiBlzz9ces1SAbKkZKf4 PDZ+bZzPjUkmadHvTx2GnK+vTEG+l8gYQcSwXV8/h9ObXK63kGH1mwrR8MoHciR0NuEJ xOXuNhumZvKL8ROuaispb5qYjlLHReCrSLMR3mEr7NVldHaquDtaZF7ti7+ZRP0s8l/I evXQ==
X-Gm-Message-State: APjAAAUVWhmtC+gn9ySOar54N6FDj4fBmWoyvXBpOrYYJ/YaxIardOlE wsKazEJAFB64E4JM3xhBP1U=
X-Google-Smtp-Source: APXvYqy27Tgx9TVC8Fyv8ho0FIm/d7qZMHb1Go13L5yVgk/w7lMMoHaiKOmlmyikpHc+EJj5MFPvxg==
X-Received: by 2002:a19:aacc:: with SMTP id t195mr12251424lfe.153.1552984219696; Tue, 19 Mar 2019 01:30:19 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f22sm2851154ljk.18.2019.03.19.01.30.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Mar 2019 01:30:18 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tobias Guggemos' <guggemos@nm.ifi.lmu.de>, '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>
In-Reply-To: <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de>
Date: Tue, 19 Mar 2019 11:30:15 +0300
Message-ID: <059301d4de2d$faa5a000$eff0e000$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUKWDmyEA
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Whgu7CL3cz2r-Q5M5LXdNT1F7G4>
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: Tue, 19 Mar 2019 08:30:24 -0000

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 we’ve 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 <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