idnits 2.17.1 draft-stein-pwe3-pwsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 13, 2006) is 6404 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'GCM' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'PW-sec-req' is defined on line 321, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-01) exists of draft-stein-pwe3-sec-req-00 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y(J) Stein 3 Internet-Draft RAD Data Communications 4 Expires: April 16, 2007 Oct 13, 2006 6 Pseudowire Security (PWsec) 7 draft-stein-pwe3-pwsec-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 16, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document proposes an extension to the MPLS pseudowire format to 41 enhance pseudowire user-plane security. The extension, called PWsec, 42 provides confidentiality, data integrity, and source authentication. 43 The extension is based on the National Institute of Standards and 44 Technology (NIST) Advanced Encryption Standard (AES) using the 45 Galois/Counter Mode (GCM). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. AES/GCM . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. PWsec encapsulation . . . . . . . . . . . . . . . . . . . . . 6 52 4. PWsec signaling . . . . . . . . . . . . . . . . . . . . . . . 7 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 57 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 59 Intellectual Property and Copyright Statements . . . . . . . . 10 61 1. Introduction 63 The PWE3 architecture [RFC3985] defines a pseudowire (PW) connecting 64 customer networks over a provider network. The customer networks run 65 a native service, which may be Ethernet, ATM, frame relay, TDM, etc. 66 On both sides of the PW a customer edge (CE) connects to a provider 67 edge (PE) via an attachment circuit (AC). The PW itself is a tunnel 68 that transports the native service data across the provider network, 69 here assumed to be based on MPLS. PW tunnels may be set up using the 70 PWE control protocol [RFC4447]. 72 Security threats specific to pseudowires were discussed in [PW-sec- 73 req], where the following nonexhaustive list of user plane threats 74 were considered: 76 accidental connection to untrusted network compromising user 77 traffic 79 maliciously setting up a PW to gain access to a customer network 81 forking of a PW to snoop PW packets 83 malicious rerouting of a PW to snoop or modify PW packets 85 unauthorized tearing down of a PW 87 unauthorized snooping of PW packets 89 traffic analysis of PW connectivity 91 unauthorized deletion of PW packets 93 unauthorized modification of PW packets 95 unauthorized insertion of PW packets 97 replay of PW packets 99 denial of service or significantly impacting PW service quality. 101 In order to counter these threats, several security measures are 102 needed. State-of-the-art encryption algorithms provide data 103 confidentiality in order to frustrate snooping and prevent unintended 104 data leakage. Mechanisms to ensure data integrity thwart packet 105 insertion and modification. Source authentication may prevent 106 malicious access to resources and denial of service attacks. 108 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 109 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 110 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 112 2. AES/GCM 114 From 1976 to 2000 the Data Encryption Standard (DES) was the standard 115 block cipher. In 2000, after an open competition for the selction of 116 a successor to DES, the National Institute of Standards and 117 Technology (NIST) announced that Rijndael had been selected as the 118 basis for a new standard, and in 2001 the Advanced Encryption 119 Standard (AES) was published [AES]. Agencies of the US government 120 have certified that AES is sufficient to protect SECRET and even TOP 121 SECRET classified information. 123 AES has a fixed block size of 128 bits and allows key sizes of 128, 124 192 or 256 bits. Like other block ciphers, in order to encrypt 125 larger amounts of data, various 'modes of operation' may be used. 126 The simplest mode is Electronic CodeBook (ECB), wherein the message 127 is segmented into blocks each of which is separately encrypted. This 128 mode is not recommended due to inherent weaknesses. Other modes, 129 such as Cipher Block Chaining (CBC) and Output FeedBack (OFB) provide 130 confidentiality but do not ensure overall message integrity, nor do 131 they authenticate the claimed source. Newer modes, such as Offset 132 CodeBook (OCB) and Counter (CTR) are designed to address these 133 limitations. 135 The Galois/Counter Mode (GCM) has numerous advantages over other 136 proposed modes of operation. Its most important characteristics: 138 encryption is provided by AES with a counter-type mode of 139 operation 141 an Integrity Check Value (ICV) verifies the payload integrity 143 data that is not part of the packet payload (for example source 144 identifiers) can be authenticated 146 encryption, integrity, and source authentication are performed by 147 a single algorithm 149 authentication can be performed without encrypting data 151 the Initialization Vector (IV) nonce can be of arbitrary length 153 the algorithm can be efficiently implemented in software 154 the computation can be pipelined and parallelized, enabling high 155 speed hardware implementations 157 GCM mode is unencumbered by IPR claims. 159 For these reasons, AES/GCM has been adopted by the IEEE as the 160 default cipher suite for 802.1ae (MACsec), and has been specified for 161 IPsec ESP [RFC4106] and AH [RFC4543]. It is also being considered by 162 other bodies for applications where high-speed authenticated 163 encryption is required. When used to provide security for MPLS PWs, 164 we shall call it PWsec. 166 When encrypting, AES/GCM takes the following as input: 168 the plaintext to be encrypted (up to 2^36 - 32 bytes in length) 170 the encryption key (128 or 256 bits in length) 172 a per-packet randomly generated IV (12 bytes is recommended for 173 efficiency) 175 additional data to be authenticated but not encrypted (between 0 176 and 2^61 bytes) 178 and returns the following as output 180 the ciphertext, whose length is precisely that of the plaintext 182 the ICV (which we shall take to be 16 bytes in length). 184 For a given encryption key IV values SHOULD NOT be repeated. In 185 MACsec, the IV consists of a 4-byte Packet Number (PN) and a 8-byte 186 Secure Channel Identifier (SCI). The PN is increased from frame to 187 frame, and a new encryption key must be supplied before the PN 188 recycles. An alternative way of conforming to the requirement is 189 selecting random IV values such that repetition is highly unlikely. 191 When decrypting, AES/GCM takes the following as input: 193 the ciphertext to be decrypted 195 the encryption key 197 the IV nonce that was used when encrypting 199 the ICV generated during encryption 201 and returns the following as output 202 a boolean value specifying whether the integrity test passed or 203 failed 205 if the integrity test passed, the plaintext. 207 3. PWsec encapsulation 209 PWsec may be employed whether or not the control word [RFC4385] is 210 used. If the control word is used, it is not encrypted. If an RTP 211 header is used [RFC3985], it is encrypted. The format of a PWsec 212 encrypted packet is given in Figure 1. Note that unlike MACsec, 213 PWsec does not use the sequence number as part of the IV. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Tunnel Label | EXP |S| TTL | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | PW label | EXP |1| TTL | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |0 0 0 0| flags |FRG| Length | Sequence Number | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 225 | Initialization Vector (IV) | 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 | Encrypted Payload | 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 | Integrity Check Value (ICV) | 234 | | 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 1. PWsec Packet Format 240 PWsec performs source authentication by using an identifier that 241 uniquely identifies the source as additional data to be authenticated 242 but not encrypted. If the control word is used and the sequence 243 number is nonzero, the sequence number is authenticated in this way 244 as well. 246 If the PW is set up using the PWE control protocol [RFC4447] using 247 FEC 128, then the source identifier can be taken to be the source PE 248 identifier plus the 4-byte Group ID plus the 4-byte PW ID. If the PW 249 is set up using the PWE control protocol using FEC 129, then the 250 source identifier can be taken to be the source PE identifier plus 251 the Attachment Identifier (AI); where the latter will usually consist 252 of the Attachment Group Identifier (AGI) plus the Source Attachment 253 Individual Identifier (SAII). For both cases, the entire contents of 254 the FEC element MAY be authenticated. If the PW is statically 255 provisioned, then a unique source identifier MUST be provisioned. 257 4. PWsec signaling 259 When setting up a PW to use PWsec using the PWE3 control protocol, a 260 new TLV, called the PWsec TLV MUST be used in the LDP label mapping 261 message. This TLV specifies the parameters of the encryption and 262 authentication, including a code indicating the use of AES/GCM, the 263 encryption key length (128 or 256 bits), the length of the IV (here a 264 constant 12 bytes), the length of the ICV (here a constant 16 bytes), 265 and the additional data to be authenticated. The format of this TLV 266 will be specified in the next revision of this document. 268 The key used to encrypt and decrypt PW packets should be regularly 269 changed. Methods for key distribution are beyond the scope of this 270 document, but mechanisms such as the Internet Key Exchange (IKE) 271 [RFC4306] are appropriate for this task. 273 5. Security Considerations 275 This document proposes a security mechanism for the MPLS PW user 276 plane based on symmetric key cryptography. The mechanism is based on 277 AES in GCM mode, which has been adopted by the IEEE as the default 278 cipher suite for MACsec and has been specified for IPsec ESP 279 [RFC4106] and AH [RFC4543]. Mechanisms for key distribution will be 280 required, but were not specified. 282 Our discussion has focused on the PW user plane. To complement the 283 proposed mechanism, security solutions for the PWE3 control protocol 284 and for the management plane will be required. 286 6. IANA Considerations 288 In order to signal the use of PWsec, a new TLV to be used in the LDP 289 label mapping message of the PWE3 control protocol [RFC4447] will be 290 required. 292 7. References 294 7.1 Normative References 296 [AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, 297 November 2001. 299 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 300 Operation (GCM)", January 2004. 301 Downloadable from http://csrc.nist.gov/CryptoToolkit/ 302 modes/proposedmodes/gcm/gcm-spec.pdf 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 308 (GCM) in IPsec Encapsulating Security Payload (ESP)", 309 RFC 4106, June 2005. 311 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 312 Heron, "Pseudowire Setup and Maintenance Using the Label 313 Distribution Protocol (LDP)", RFC 4447, April 2006. 315 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 316 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 317 May 2006. 319 7.2 Informative References 321 [PW-sec-req] 322 Stein, Y(J)., "Requirements for PW Security", 323 draft-stein-pwe3-sec-req-00.txt (work in progress), 324 February 2006. 326 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 327 Edge (PWE3) Architecture", RFC 3985, March 2005. 329 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 330 RFC 4306, December 2005. 332 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 333 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 334 Use over an MPLS PSN", RFC 4385, February 2006. 336 Author's Address 338 Yaakov (J) Stein 339 RAD Data Communications 340 24 Raoul Wallenberg St., Bldg C 341 Tel Aviv 69719 342 ISRAEL 344 Phone: +972 3 645-5389 345 Email: yaakov_s@rad.com 347 Intellectual Property Statement 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be 356 found in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use of 361 such proprietary rights by implementers or users of this 362 specification can be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at 369 ietf-ipr@ietf.org. 371 Disclaimer of Validity 373 This document and the information contained herein are provided on an 374 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 375 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 376 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 377 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 378 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 381 Copyright Statement 383 Copyright (C) The Internet Society (2006). This document is subject 384 to the rights, licenses and restrictions contained in BCP 78, and 385 except as set forth therein, the authors retain all their rights. 387 Acknowledgment 389 Funding for the RFC Editor function is currently provided by the 390 Internet Society.