Network Working Group Y(J) Stein Internet-Draft RAD Data Communications Expires: April 16, 2007 Oct 13, 2006 Pseudowire Security (PWsec) draft-stein-pwe3-pwsec-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document proposes an extension to the MPLS pseudowire format to enhance pseudowire user-plane security. The extension, called PWsec, provides confidentiality, data integrity, and source authentication. The extension is based on the National Institute of Standards and Technology (NIST) Advanced Encryption Standard (AES) using the Galois/Counter Mode (GCM). Stein Expires April 16, 2007 [Page 1] Internet-Draft pwe3-pwsec Oct 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. AES/GCM . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PWsec encapsulation . . . . . . . . . . . . . . . . . . . . . 6 4. PWsec signaling . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Stein Expires April 16, 2007 [Page 2] Internet-Draft pwe3-pwsec Oct 2006 1. Introduction The PWE3 architecture [RFC3985] defines a pseudowire (PW) connecting customer networks over a provider network. The customer networks run a native service, which may be Ethernet, ATM, frame relay, TDM, etc. On both sides of the PW a customer edge (CE) connects to a provider edge (PE) via an attachment circuit (AC). The PW itself is a tunnel that transports the native service data across the provider network, here assumed to be based on MPLS. PW tunnels may be set up using the PWE control protocol [RFC4447]. Security threats specific to pseudowires were discussed in [PW-sec- req], where the following nonexhaustive list of user plane threats were considered: accidental connection to untrusted network compromising user traffic maliciously setting up a PW to gain access to a customer network forking of a PW to snoop PW packets malicious rerouting of a PW to snoop or modify PW packets unauthorized tearing down of a PW unauthorized snooping of PW packets traffic analysis of PW connectivity unauthorized deletion of PW packets unauthorized modification of PW packets unauthorized insertion of PW packets replay of PW packets denial of service or significantly impacting PW service quality. In order to counter these threats, several security measures are needed. State-of-the-art encryption algorithms provide data confidentiality in order to frustrate snooping and prevent unintended data leakage. Mechanisms to ensure data integrity thwart packet insertion and modification. Source authentication may prevent malicious access to resources and denial of service attacks. Stein Expires April 16, 2007 [Page 3] Internet-Draft pwe3-pwsec Oct 2006 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 2. AES/GCM From 1976 to 2000 the Data Encryption Standard (DES) was the standard block cipher. In 2000, after an open competition for the selction of a successor to DES, the National Institute of Standards and Technology (NIST) announced that Rijndael had been selected as the basis for a new standard, and in 2001 the Advanced Encryption Standard (AES) was published [AES]. Agencies of the US government have certified that AES is sufficient to protect SECRET and even TOP SECRET classified information. AES has a fixed block size of 128 bits and allows key sizes of 128, 192 or 256 bits. Like other block ciphers, in order to encrypt larger amounts of data, various 'modes of operation' may be used. The simplest mode is Electronic CodeBook (ECB), wherein the message is segmented into blocks each of which is separately encrypted. This mode is not recommended due to inherent weaknesses. Other modes, such as Cipher Block Chaining (CBC) and Output FeedBack (OFB) provide confidentiality but do not ensure overall message integrity, nor do they authenticate the claimed source. Newer modes, such as Offset CodeBook (OCB) and Counter (CTR) are designed to address these limitations. The Galois/Counter Mode (GCM) has numerous advantages over other proposed modes of operation. Its most important characteristics: encryption is provided by AES with a counter-type mode of operation an Integrity Check Value (ICV) verifies the payload integrity data that is not part of the packet payload (for example source identifiers) can be authenticated encryption, integrity, and source authentication are performed by a single algorithm authentication can be performed without encrypting data the Initialization Vector (IV) nonce can be of arbitrary length the algorithm can be efficiently implemented in software Stein Expires April 16, 2007 [Page 4] Internet-Draft pwe3-pwsec Oct 2006 the computation can be pipelined and parallelized, enabling high speed hardware implementations GCM mode is unencumbered by IPR claims. For these reasons, AES/GCM has been adopted by the IEEE as the default cipher suite for 802.1ae (MACsec), and has been specified for IPsec ESP [RFC4106] and AH [RFC4543]. It is also being considered by other bodies for applications where high-speed authenticated encryption is required. When used to provide security for MPLS PWs, we shall call it PWsec. When encrypting, AES/GCM takes the following as input: the plaintext to be encrypted (up to 2^36 - 32 bytes in length) the encryption key (128 or 256 bits in length) a per-packet randomly generated IV (12 bytes is recommended for efficiency) additional data to be authenticated but not encrypted (between 0 and 2^61 bytes) and returns the following as output the ciphertext, whose length is precisely that of the plaintext the ICV (which we shall take to be 16 bytes in length). For a given encryption key IV values SHOULD NOT be repeated. In MACsec, the IV consists of a 4-byte Packet Number (PN) and a 8-byte Secure Channel Identifier (SCI). The PN is increased from frame to frame, and a new encryption key must be supplied before the PN recycles. An alternative way of conforming to the requirement is selecting random IV values such that repetition is highly unlikely. When decrypting, AES/GCM takes the following as input: the ciphertext to be decrypted the encryption key the IV nonce that was used when encrypting the ICV generated during encryption and returns the following as output Stein Expires April 16, 2007 [Page 5] Internet-Draft pwe3-pwsec Oct 2006 a boolean value specifying whether the integrity test passed or failed if the integrity test passed, the plaintext. 3. PWsec encapsulation PWsec may be employed whether or not the control word [RFC4385] is used. If the control word is used, it is not encrypted. If an RTP header is used [RFC3985], it is encrypted. The format of a PWsec encrypted packet is given in Figure 1. Note that unlike MACsec, PWsec does not use the sequence number as part of the IV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initialization Vector (IV) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Integrity Check Value (ICV) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. PWsec Packet Format PWsec performs source authentication by using an identifier that uniquely identifies the source as additional data to be authenticated but not encrypted. If the control word is used and the sequence number is nonzero, the sequence number is authenticated in this way as well. If the PW is set up using the PWE control protocol [RFC4447] using FEC 128, then the source identifier can be taken to be the source PE identifier plus the 4-byte Group ID plus the 4-byte PW ID. If the PW Stein Expires April 16, 2007 [Page 6] Internet-Draft pwe3-pwsec Oct 2006 is set up using the PWE control protocol using FEC 129, then the source identifier can be taken to be the source PE identifier plus the Attachment Identifier (AI); where the latter will usually consist of the Attachment Group Identifier (AGI) plus the Source Attachment Individual Identifier (SAII). For both cases, the entire contents of the FEC element MAY be authenticated. If the PW is statically provisioned, then a unique source identifier MUST be provisioned. 4. PWsec signaling When setting up a PW to use PWsec using the PWE3 control protocol, a new TLV, called the PWsec TLV MUST be used in the LDP label mapping message. This TLV specifies the parameters of the encryption and authentication, including a code indicating the use of AES/GCM, the encryption key length (128 or 256 bits), the length of the IV (here a constant 12 bytes), the length of the ICV (here a constant 16 bytes), and the additional data to be authenticated. The format of this TLV will be specified in the next revision of this document. The key used to encrypt and decrypt PW packets should be regularly changed. Methods for key distribution are beyond the scope of this document, but mechanisms such as the Internet Key Exchange (IKE) [RFC4306] are appropriate for this task. 5. Security Considerations This document proposes a security mechanism for the MPLS PW user plane based on symmetric key cryptography. The mechanism is based on AES in GCM mode, which has been adopted by the IEEE as the default cipher suite for MACsec and has been specified for IPsec ESP [RFC4106] and AH [RFC4543]. Mechanisms for key distribution will be required, but were not specified. Our discussion has focused on the PW user plane. To complement the proposed mechanism, security solutions for the PWE3 control protocol and for the management plane will be required. 6. IANA Considerations In order to signal the use of PWsec, a new TLV to be used in the LDP label mapping message of the PWE3 control protocol [RFC4447] will be required. Stein Expires April 16, 2007 [Page 7] Internet-Draft pwe3-pwsec Oct 2006 7. References 7.1 Normative References [AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001. [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", January 2004. Downloadable from http://csrc.nist.gov/CryptoToolkit/ modes/proposedmodes/gcm/gcm-spec.pdf [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006. 7.2 Informative References [PW-sec-req] Stein, Y(J)., "Requirements for PW Security", draft-stein-pwe3-sec-req-00.txt (work in progress), February 2006. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. Stein Expires April 16, 2007 [Page 8] Internet-Draft pwe3-pwsec Oct 2006 Author's Address Yaakov (J) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL Phone: +972 3 645-5389 Email: yaakov_s@rad.com Stein Expires April 16, 2007 [Page 9] Internet-Draft pwe3-pwsec Oct 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stein Expires April 16, 2007 [Page 10]