--- 1/draft-ietf-ippm-ipsec-03.txt 2014-07-22 09:14:31.329528128 -0700 +++ 2/draft-ietf-ippm-ipsec-04.txt 2014-07-22 09:14:31.357528811 -0700 @@ -1,20 +1,20 @@ IPPM WG K. Pentikousis, Ed. Internet-Draft EICT Intended status: Standards Track Y. Cui -Expires: December 7, 2014 E. Zhang +Expires: January 23, 2015 E. Zhang Huawei Technologies - June 5, 2014 + July 22, 2014 - Network Performance Measurement for IPsec - draft-ietf-ippm-ipsec-03 + IKEv2-based Shared Secret Key for O/TWAMP + draft-ietf-ippm-ipsec-04 Abstract The O/TWAMP security mechanism requires that both the client and server endpoints possess a shared secret. Since the currently- standardized O/TWAMP security mechanism only supports a pre-shared key mode, large scale deployment of O/TWAMP is hindered significantly. At the same time, recent trends point to wider IKEv2 deployment which, in turn, calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and @@ -34,42 +34,42 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 7, 2014. + This Internet-Draft will expire on January 23, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 4 3.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 4 3.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 5 3.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 6 4. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 6 4.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 6 4.2. Server Greeting Message Update . . . . . . . . . . . . . 7 4.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 9 4.4. O/TWAMP over an IPsec tunnel . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 @@ -115,20 +115,31 @@ cellular networks, such as UMTS and GSM, IPsec use penetration is lower, but still quite significant. If the shared key can be derived from the IKEv2 SA, O/TWAMP can support cert-based key exchange and make it more flexible in practice and more efficient. The use of IKEv2 also makes it easier to extend automatic key management. In general, O/TWAMP measurement packets can be transmitted inside the IPsec tunnel, as it occurs with typical user traffic, or transmitted outside the IPsec tunnel. This may depend on the operator's policy and is orthogonal to the mechanism described in this document. + We note that protecting unauthenticated O/TWAMP traffic using IPsec + security services is sufficient in many cases. That said, protecting + unauthenticated O/TWAMP control and/or test traffic via AH or ESP + cannot provide various security modes and cannot authenticate part of + a O/TWAMP packet as mentioned in [RFC4656]. In real-world + deployments this may hinder timestamp accuracy. This document + describes how to derive the shared secret key from the IKEv2 SA and + employ the security service at the O/TWAMP layer. This method SHOULD + be used when O/TWAMP traffic is bypassing IPsec protection and is + running over an external network exactly between two IKEv2 systems. + The remainder of this document is organized as follows. Section 3 summarizes O/TWAMP protocol operation with respect to security. Section 4 presents a method of binding O/TWAMP and IKEv2 for network measurements between the client and the server which both support IKEv2. Finally, Section 5 discusses the security considerations arising from the proposed mechanisms. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -255,28 +266,28 @@ 4. O/TWAMP for IPsec Networks This section presents a method of binding O/TWAMP and IKEv2 for network measurements between a client and a server which both support IPsec. In short, the shared key used for securing O/TWAMP traffic is derived using IKEv2 [RFC5996]. 4.1. Shared Key Derivation In the authenticated, encrypted and mixed modes, the shared secret - key can be derived from the IKEv2 Security Association (SA). Note + key MUST be derived from the IKEv2 Security Association (SA). Note that we explicitly opt to derive the shared secret key from the IKEv2 SA, rather than the child SA, since the use case whereby an IKEv2 SA can be created without generating any child SA is possible [RFC6023]. - If the shared secret key is derived from the IKEv2 SA, SKEYSEED must - be generated first. SKEYSEED and its derivatives MUST be computed as - per [RFC5996], where prf is a pseudorandom function: + When the shared secret key is derived from the IKEv2 SA, SKEYSEED + must be generated first. SKEYSEED and its derivatives MUST be + computed as per [RFC5996], where prf is a pseudorandom function: SKEYSEED = prf( Ni | Nr, g^ir ) Ni and Nr are, respectively, the initiator and responder nonces, which are negotiated during the initial exchange (see Section 1.2 of [RFC5996]). g^ir is the shared secret from the ephemeral Diffie- Hellman exchange and is represented as a string of octets. The shared secret key MUST be generated as follows: @@ -447,23 +458,24 @@ 6. IANA Considerations IANA will need to allocate additional values for the Modes options presented in this document. 7. Acknowledgments Emily Bi contributed to an earlier version of this document. - We thank Eric Chen, Yakov Stein, Brian Trammell, and John Mattsson - for their comments on this draft, and Al Morton for the discussion - and pointers to related earlier work in IPPM WG. + We thank Eric Chen, Yaakov Stein, Brian Trammell, John Mattsson, and + Steve Baillargeon for their comments and text suggestions, and Al + Morton for the good discussion and pointers to earlier related work + in IPPM WG. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.