[secdir] Security review of draft-ietf-ippm-ipsec-08
Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 09 February 2015 06:45 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 CCF791A006D; Sun, 8 Feb 2015 22:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 QrZIVTUHEkQX; Sun, 8 Feb 2015 22:45:45 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7831A0067; Sun, 8 Feb 2015 22:45:44 -0800 (PST)
Received: from [192.168.10.149] ([193.83.169.152]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwF9u-1XXqqg3LFW-0186YG; Mon, 09 Feb 2015 07:45:25 +0100
Message-ID: <54D85781.2080009@gmx.net>
Date: Mon, 09 Feb 2015 07:45:21 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: secdir@ietf.org, "iesg@ietf.org >> The IESG" <iesg@ietf.org>, draft-ietf-ippm-ipsec@tools.ietf.org
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="n4AuaxKIGd4uW5Ix6O2bsLMV3Ldnl5eUS"
X-Provags-ID: V03:K0:kXxp17qCN3hNqDq0kkRWkny5DP9503qY1I+EFFXMkxyadEnCtjl Z/4xB144To4OSJ95QbOxNqDvlBoPzxBFlYMmg9IxYj0Xh3zlgGM9YpC6rdUMsw+RG41UjkK IT7xRnYNhxrV3rJtLWSEvdCqQoGE1CjkKpUT5Yu9izhE3ihE4HH3XTH40YObzm5yvhqn3Ge 7mk0g3E7cysjb5teKKlRg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Day-KG0bF8KzOOLNornBc3fow10>
Subject: [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: Mon, 09 Feb 2015 06:45:48 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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. Summary: The specification proposes to derive keying material from an IKEv2 exchange to secure the One-way Active Measurement Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) protocols. Introduction: 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 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. 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. 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 since you only want the outcome of the exchange to produce the keying material as input to the O/TWAMP protocol via the already standardized pre-shared authentication exchange. Third, when the IKEv2 exchange is finished it needs to notify the application that the keying material is ready. The new key derivation function described in Section 5.1 is obviously not available in any IKEv2 implementation and, as you correctly stated, you don't want to make export the SK_d directly to the application but rather only the output of the derivation, namely prf( SK_d, "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. 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? It might be wortwhile to talk to people who used IKEv2 in a way similar to what you are proposing (namely for not establishing IPsec SAs). While there may not be that many of such standardization development I remember that there was some work in the routing area. 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. A small note on the use of shared secrets. It seems that you have the impression that the shared secrets used in the O/TWAMP protocol have to be manually configured. This may not necessarily be true if you want to use them in cellular networks, as you describe. 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. 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. 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. 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. If IANA cannot give you that value they should correct the text in the draft and put the appropriate value there. If that's the case then the correct way to write this is as follows: " The new Modes value indicating support for this specification is IKEv2Derived and is TBD." In the IANA consideration section you then note that all TBDs have to be replaced with the value allocated by IANA. 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. Ciao Hannes
- Re: [secdir] Security review of draft-ietf-ippm-i… Hannes Tschofenig
- Re: [secdir] Security review of draft-ietf-ippm-i… Stephen Farrell
- [secdir] Security review of draft-ietf-ippm-ipsec… Hannes Tschofenig
- Re: [secdir] Security review of draft-ietf-ippm-i… Kostas Pentikousis