Re: [secdir] Security review of draft-ietf-ippm-ipsec-08

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 09 April 2015 09:50 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08E1B2D51; Thu, 9 Apr 2015 02:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 qodO7cqIhI4r; Thu, 9 Apr 2015 02:50:52 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1ED1B2D4D; Thu, 9 Apr 2015 02:50:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 612FFBED1; Thu, 9 Apr 2015 10:50:50 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbVvo0dhR3lR; Thu, 9 Apr 2015 10:50:47 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92661BE57; Thu, 9 Apr 2015 10:50:45 +0100 (IST)
Message-ID: <55264B70.80401@cs.tcd.ie>
Date: Thu, 09 Apr 2015 10:50:40 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Kostas Pentikousis <k.pentikousis@eict.de>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org >> The IESG" <iesg@ietf.org>, "draft-ietf-ippm-ipsec@tools.ietf.org" <draft-ietf-ippm-ipsec@tools.ietf.org>
References: <54D85781.2080009@gmx.net> <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB748D98@SBS2008.eict.local> <5525E9A3.6010906@gmx.net>
In-Reply-To: <5525E9A3.6010906@gmx.net>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EiQEkK5JsO5UwxUSifmioe1piOlxrVhql"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/fgDsOiivlkSN3D2Au3dV-tenX_0>
Subject: Re: [secdir] Security review of draft-ietf-ippm-ipsec-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2015 09:50:55 -0000

Ah - that makes me wonder about another thing. I've
updated my discuss ballot with the text below. (If
this is already clear in the text, I'll clear as soon
as you show me where.)

Cheers,
Stephen.

The text added to my discuss ballot [1] is:

"(2) Is it clear what to do if a key needs to be derived for
O/TWAMP whilst re-keying is in progress for the IKE SA?
(Hannes' review made me wonder, and I don't recall if
the text on this is quite clear enough to not allow for a
case where the two sides end up with different values
derived from the DH share.)"

[1]
https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ballot/#stephen-farrell

On 09/04/15 03:53, Hannes Tschofenig wrote:
> Hi Kostas,
> 
> thanks for responding to my review.
> 
> A few remarks inline.
> 
> On 02/12/2015 01:29 PM, Kostas Pentikousis wrote:
>> Hi Hannes,
>>
>> <snip>
>>
>> | comments were written primarily for the benefit of the security
>> area | directors.  Document editors and WG chairs should treat these
>> comments just | like any other last call comments.
>>
>> Many thanks for the thorough review. Much appreciated.
>>
>> <snip>
>>
>>
>> | In the introduction you point out that IKEv2 is very commonly
>> deployed. | You even say that "In mobile telecommunication networks,
>> the deployment rate | of IPsec exceeds 95% with respect to the LTE
>> serving network." | | While the exact number is probably not that
>> important (and very likely hard to
>>
>> This text originates from the motivation that got this draft going.
>> In particular, the nearly 10-year old RFC 4656 argues in sec. 6.6
>> (https://tools.ietf.org/html/rfc4656#section-6.6), among other
>> things, that
>>
>> "The deployment paths of IPsec and OWAMP could be separate if OWAMP 
>> does not depend on IPsec.  After nine years of IPsec, only 0.05% of
>> traffic on an advanced backbone network, such as Abilene, uses IPsec
>> (for comparison purposes with encryption above layer 4, SSH use is at
>> 2-4% and HTTPS use is at 0.2-0.6%).  It is desirable to be able to
>> deploy OWAMP on as large a number of different platforms as
>> possible."
>>
>> I don't think we need to argue about the numbers for IPsec, HTTPS and
>> so on today (esp. as we look towards 2020), but I would make the case
>> that it's likely that IPsec is more widely deployed today than OWAMP
>> is. Perhaps I'm wrong, please correct me. Hence, during the early
>> phase of development of this draft we included this text to
>> illustrate eminent use cases for this draft (such as the LTE case).
>> If you think that "95%" should be replaced with "the vast majority
>> of" or something of that nature, please let us know. If you have
>> completely different numbers from operators, research studies or
>> vendors for this type of deployment (or other settings for that
>> matter), I'll be happy to hear them.
> 
> I just got a hung up on the numbers you mention since you do not provide
> any description of where these numbers came from. So, I would prefer to
> say something like widely deployed or so.
> 
> 
>>
>>
>> | verify) the statement does, however, raise some questions. You seem
>> to expect | that you can re-use already deployed IKEv2 for the
>> special version of IKEv2 | you are describing in this document and
>> that's unfortunately very unlikely to | be true.
>>
>> I don't agree this is the case when I read the text.
> 
> When you talk in the introduction about the widespread deployment of
> IPsec and IKEv2 in operator networks, then state that using IPsec /
> IKEv2 is a "viable alternative" for protecting O/TWAMP
> and then document the solution then it is easy to come up with the idea
> that
> this existing deployment can be re-used.
> 
> I believe that the reason for stating that IPsec/IKEv2 is already so
> widely deployed is to create the argument for going with the IPsec/IKEv2
> solution approach.
> 
> In all fairness for operators, who read this specification, they should
> not be under the impression that they can might necessarily be able to
> re-use their existing IPsec/IKEv2 stack since the described solution is
> a bit special IMHO.
> 
> 
>>
>> | The solution described in the document requires a very tight
>> integration | between an IKEv2 implementation (not IPsec) and the
>> O/TWAMP application and | the text in the document gives me the
>> impression that you are not entirely | aware that this will actually
>> need to happen. This may lead to unpleasant | surprises when you
>> implement it.
>>
>> I don't agree with the term "very tight integration". In fact, we had
>> the API discussion several times with folks in ipsecme over the last
>> 2 years and a bit.
> 
> What was the outcome of that discussion? Can you send me a pointer to it?
> 
>> I heard some of the background, and I agree that
>> perhaps an IPsec vendor with *no interest in TWAMP* may have to think
>> more if they want to invest the effort to support this spec.
> 
> Of course, an IPsec VPN vendor who provides a solution as described
> in the document will not encounter a problem. This, however, supports
> my impression that a random IPsec VPN solution (I call it
> "of-the-shelve" stack) might not work.
> 
>> But for
>> vendors with both implementations in house, I would leave it to their
>> respective implementation teams. This spec would facilitate
>> interoperability in this latter case.
> 
> It is great to describe aspects that concern interoperability
> but it is also important to point to potential
> implementation/operational issues.
> 
>>
>> As an aside, and given that this is an IPPM draft, I would like to
>> point out that TWAMP per se (RFC 5357, sec. 1.2:
>> https://tools.ietf.org/html/rfc5357#section-1.2) does leave certain
>> interactions "unspecified", which "may be proprietary protocols".
> 
> ... which is not good for interoperability.
> 
>>
>> | First, you will have to trigger the IKEv2 exchange from the
>> application. | Second, you definitely do not want the IKEv2 exchange
>> to create IPsec SAs
>>
>> <snip>
>>
>> | "IPPM" ). IMHO no off-the-shelf IKEv2 implementation will let
>> applications | access the SK_d directly nor will it have an API to
>> the IKEv2 SA either.
>>
>> Agreed, wrt "off-the-shelf" (in general), after all this is not an
>> RFC yet. But please see above.
>>
>>
>> | It might also want to think about potential interactions from the |
>> IKEv2-> to O/TWAMP side, such as rekeying. I am not sure whether
>> there | are issues to take into account but have you thought about
>> them?
>>
>> This is addressed in the last paragraph of sec. 5.1
>> (https://tools.ietf.org/html/draft-ietf-ippm-ipsec-09#section-5.1).
>> If you would like other text to be added or this to be edited, please
>> kindly send a proposal.
>>
>> <snip>
>>
> 
> Here is the current text:
> 
> "
> 
>    If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the
>    corresponding shared secret key generated from the SA can continue to
>    be used until the O/TWAMP session terminates.
> "
> 
> I would prefer to have this paragraph written in a normative way (i.e.,
> using RFC 2119 language). It seems that you leave it up to the
> implementation on how to react to re-keying / IKEv2 SA deletion.
> Wouldn't this create potential issues when one side decides to derive
> new keying material and the other side doesn't? What happens if one side
> has the policy to delete the O/TWAMP keying material in response to the
> IKEv2 SA being deleted?
> 
> Was there a reason why rekeying of an IKEv2 SA shouldn't lead to new
> keying material be derived mandatorily? Also, one would think when the
> underlying IKEv2 SA is deleted then the keying material for the O/TWAMP
> also be deleted.
> 
>>
>> | In Section 5.1 you describe a way to obtain for the O/TWAMP
>> implementation to | interact with the IKEv2 code as follows: | | " |
>> the IPSec layer can perform a lookup |    in the Security Association
>> Database (SAD) using the IP address of |    the server and thus match
>> the corresponding IKEv2 SA.  At the server |    side, the IPSec layer
>> can look up the corresponding IKEv2 SA by using |    the SPIs sent by
>> the client, and therefore extract the shared secret " | | I believe
>> that this approach will not work since your use of IKEv2 shouldn't |
>> actually require any interaction with IPsec at all.
>>
>> We use IPsec to refer to IKE+ESP/AH in this draft. If you would like
>> to propose alternative, better refined text, please let us know.
>>
>> <snip>
>>
>>
>> | I could imagine that a network management protocol could be used to
>> provision | the shared secrets to the appropriate nodes. While public
>> key cryptography | makes some aspects of the key distribution easier
>> it does raise other | questions, such as distribution of trust
>> anchors and the question about | authorization. Since you do not
>> discuss authorization in the document I am not | sure it is of
>> concern with the use of O/TWAMP.
>>
>> Indeed, a network management protocol _could_ be used, but this is
>> not standardized and, imo, orthogonal to the problem at hand. Perhaps
>> we should start a separate draft for OAM-based shared secret
>> distribution for TWAMP.
> 
> In the above paragraph I have been trying to express a question
> regarding authorization. In a shared secret environment the
> authorization procedure is often dealt-with implicitly but with public
> key cryptography you have to deal with authorization separate. How do
> you expect authorization to be handled here?
> 
>>
>>
>> | I am not sure why you include the text in Section 5.4 where you
>> describe | O/TWAMP over an IPsec tunnel since in the introduction you
>> argue that this is | not an approach that you favour since it
>> introduces delays into the | measurements.
>>
>> This was introduced as part of the consensus process in the WG. If
>> your comment is editorial in nature, then [editor hat on] I would let
>> it go [editor hat off]. If it's substantial, blocking, then I would
>> be happy to remove sec. 5.4. Mind you, several parts of the draft
>> have been repeatedly tuned to reach consensus over the last 2 years.
> 
> Since I have not participated in the working group I am not aware of
> these discussions. Just from reading the document it felt a bit strange
> to find the text in Section 5.4 while the introduction argues differently.
> 
>>
>>
>> | I am also wondering whether this solution offers crypto agility.
>> The text | describes that you use AES-CBC (for encryption) and
>> HMAC-SHA1 (for data origin | authentication and integrity
>> protection). IKEv2 could, of course, allow you to | negotiate other
>> algorithms and particularly the more modern AEAD ciphers.
>>
>> AES-CBC and HMAC-SHA1 are algorithms defined in the O/TWAMP RFCs.
>> Perhaps there is space for another draft in this direction as well,
>> i.e. to allow for more crypto agility in TWAMP beyond has been
>> standardized so far.
>>
> 
> It is up to the IESG to decide how to take crypto agility in IETF
> specifications into account.
> 
> I personally would make use of IKEv2 (and the algorithm negotiation
> capabilities) as well as take steps to support state-of-the-art algorithms.
> 
>>
>> | In a few parts of the document you say " |    The new Modes value
>> indicating support for this |    specification is IKEv2Derived and is
>> equal to 128 (i.e. bit set in |    position 7) [NOTE to IANA: remove
>> before allocation and final | publication]". | | I am not sure what
>> you are asking IANA to do. I believe what you are trying to | say is
>> that you have proposed a specific value for this extension and you
>> want | IANA to confirm that allocation.
>>
>> <snip>
>>
>> Done in -09
> 
> Thanks.
> 
> 
>>
>>
>> | I would also remove this paragraph in the Security Consideration
>> section: | | | " |    As a more general note, the IPPM community may
>> want to revisit the |    arguments listed in [RFC4656], Sec. 6.6.
>> Other widely-used Internet |    security mechanisms, such as TLS and
>> DTLS, may also be considered for |    future use over and above of
>> what is already specified in [RFC4656] |    [RFC5357]. | " | | While
>> it is true that DTLS/TLS could also used (and are probably a better |
>> choice) it feels like the wrong statement in this document. It makes
>> the | reader feel like that even the authors are not convinced that
>> this is the | right solution approach.
>>
>> We have removed this paragraph in -09, as per your request:
>> http://www.ietf.org/rfcdiff?url1=draft-ietf-ippm-ipsec-08&url2=draft-ietf-ippm-ipsec-09c-09.
>> However, this brings us back to motivation discussion at the
>> beginning of this email.
> 
> Thanks. Btw, I also agree with you that DTLS would have been a better
> choice ...
> 
> A last question: Has someone implemented this specification? I am
> curious about the challenges they ran into.
> 
> Ciao
> Hannes
> 
>>
>> Once again, many thanks.
>>
>> Best regards,
>>
>> Kostas
>>
> 
> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>