Network Working Group Tissa Senevirathne Internet Draft (Force10) Document: draft-tsenevir-mpls-lauth-00.txt Category: Informational April 2001 MPLS Label Stack Authentication methods and algorithms Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document provide methods to protect MPLS Label stack from security related attacks such as, label spoofing. Two HMAC based label stack authentication methods are provided. A solution based on stream cipher is provided for speed oriented deployments. Applicable deployment scenarios are presented where appropriate. Methods presented in this document are intended for hop-by-hop label stack authentication - as opposed to end-to-end label authentication. Senevirathne Informational - September 2001 1 draft-tsenevir-mpls-lauth-00.txt April 2001 1.0 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2.0 Introduction Multiprotocol Label Switching (MPLS) is getting popular as a wide area networking protocol. In the same time MPLS is becoming popular amongst service providers who wish to provision services to customer networks. When connecting un-trusted MPLS domains, label stack authentication is required to prevent any Denial of Service attack by label spoofing or connection hijacking by malicious label insertion. The label stack used in MPLS packets can be from a single label to several labels. In other words, from 32-bits to 100's of bits. The label stack authentication methods must be able to cover either part or the entire stack. The selected authentication algorithm should not generate arbitrarily large signatures. Ideally the signature length should be in multiple of 32-bits. In the first part of this document we present use of HMAC for label stack authentication. HMAC-SHA-1-96 and HMAC-MD5-96 are presented as possible HMAC algorithms that could be used for the authentication purpose. HMAC algorithms take the data stream and a secret key and generate a message digest. The cryptographic strength of HMAC based algorithms depends on the computational difficulty of regeneration of the digest without possessing the secret key. Both SHA-1 and MD5 takes the data stream as a block input of 512-bits and generate a message digest of either 160-bits (SHA-1) or 128-bits (MD5). The goal of MPLS label stack authentication is to provide a fast and secure authentication method. Commercially available hardware solutions are capable of performing SHA-1 and MD5 algorithms at high speeds. In the second part of this document we present algorithms that could encrypt the label stack. A solution based on novel stream cipher technique and a DES based solution are presented. The solution based on stream cipher generators, take the label stack and generate a bit stream based on some established stream cipher algorithm, such as A5. Stream cipher algorithms are secure for time varying bit streams. It is possible that label stack may remain static over a period of time. Thus giving an opportunity for an attacker to decipher the message. [3] describes a procedure to break stream cipher text that use static text. We have proposed to randomize the label stack using a predictable function that can only be meaningfully applied by the sender and receiver. Section 4.0 below explains the use of stream cipher to protect the label stack. Senevirathne Informational - September 2001 2 draft-tsenevir-mpls-lauth-00.txt April 2001 DES (Data Encryption Standard) is widely used to encrypt data. The security of the DES algorithm does not depend on the time uniqueness of data stream. The security of the DES algorithm depends on the computational difficulty of the algorithm it-self. [3] Provide an excellent coverage on DES and other encryption algorithms. MPLS label stack authentication is enabled per interface basis. At configuration time, the cipher algorithm and related parameters are defined. It is possible that the authentication algorithm may be negotiated during the adjacency formation. However, the exact implementation depends on the label distribution protocol used. Hence, the negotiation of label stack authentication is considered out of scope of this document. 3.0 Use of HMAC for Label stack authentication In this section label stack authentication based on Hash Message Authentication (HMAC) is presented. HMAC is presented in RFC 2104 [4]. HMAC generates a message digest based on a secret key and the message. HMAC propose to use hash functions to generate the required message digest. Presently MD5 and SHA-1 are the most popular hash functions used within HMAC. Hardware based implementations of SHA-1 and MD5 are commonly available. In the native form MD5 generates a 128 bit message digest and SHA-1 generates a message digest of 160 bits as the message digest. RFC 2104 [4] has identified that only sending a subset of the message digest is sufficient to maintain the required cryptographic strength. RFC 2403 [5] specifies HMAC-MD5-96 algorithm as applicable to IPsec. RFC 2404 [6] specifies HMAC-SHA-1-96 algorithm as applicable to IPsec. In this section we propose to extend the work presented in [5] and [6] to authenticate MPLS label stack over each hop. Both SHA-1 and MD5 require payload in multiple of 512 bits. In general label stack contain few labels thus making average label stack significantly smaller than 512 bits. Hence, padding of the label stack to 512-bit boundary is required. A casual browser may deduce this as significant over head and thus may impact the performance. However, careful analysis proves this does not impact the performance. The padding pattern is relatively static and thus can be considered as part of the initialization vector. Hardware solutions that could perform HMAC authentication at 1Gps rates are widely available in the market. Several vendors have announced product plans to develop such features for 10Gps rates. 3.0.1 Configuration of Authentication Algorithm Hop by hop label stack authentication is configured per interface basis. At present we propose to manually configure the authentication algorithms and enable the label stack authentication per interface basis. However, authentication related parameters may Senevirathne Informational - September 2001 3 draft-tsenevir-mpls-lauth-00.txt April 2001 be negotiated during LDP adjacency formation or via dedicated IKE channel. Such automatic discovery of label stack authentication algorithm is beyond the scope of this document. Only supported label stack authentication algorithms at the time of writing is HMAC-SHA-1-96 and HMAC-MD5-96. 3.0.2 Use of HAMC to authenticate the Label Stack Let the Label Stack with n labels (32*n bits) is L(n) Let the secret key is k Let the HMAC operation is H Note: See [4], [5] and [6] for details. Let the message digest is (truncated to 96 bits) is ICV Let the Required Padding is P ICV = H((L(n) | P) , k) 3.0.3 Label stack validation The message digest is transmitted with the packet. At the destination the ICV is calculated over the label stack using the same procedure. The re-generated ICV is compared against the ICV that was embedded in the message. If the ICV are equal message may be accepted as authenticated. If the ICV are not equal message MUST be discarded. 3.0.4 Encoding of ICV In hierarchical MPLS tunnels one may wish to authenticate some parts of the label stack. Hence, it is important to identify the start and the end of the authenticated portion of the label stack. For this purpose we propose to use reserved label from the range 0-15. We have arbitrarily selected value 7 (seven) for the purpose. 1. General Encoding format ----------------------------------------------------------------- | M-H | Lbl(clear)| Lbl(Rsv)| ICV | Lbl(auth)| Lbl(Rsv)|Lbl(clear)| ----------------------------------------------------------------- 2. Simple Encoding format ------------------------------------------- | M-H | Lbl(Rsv)| ICV | Lbl(auth)|Payload | ------------------------------------------- Senevirathne Informational - September 2001 4 draft-tsenevir-mpls-lauth-00.txt April 2001 M-H Media dependant header for the MPLS packet Lbl(Clear) Labels that are not authenticated Lbl(Rsv) Reserved Label that identifies the start and end of Authenticated label stack. If the Label(auth) contain the bottom of stack label then Label(Rsv) MUST not be inserted after Lbl(auth). ICV Integrity check value generated according to one of the authentication algorithms. Always 96-bits in length. 3.0.5 Deployment scenario 1. General deployment -o-o-o-o-o-o-o- ---- | Public MPLS network ---- | |1 1o----------------o2 2| | |LSR |-----------------------------------------|LSR | ---- o----------------o ---- | (A) | -o-o-o-o-o-o-o- 1, 1 Authenticated Interfaces 2,2 Authenticated Interfaces (A) Public MPLS network, may not have authentication NOTE: at 1 labels required to forward via (A) is pushed. at 2 labels used to forward in (A) is popped thus trimming the outer tunnel. 2. Simple deployment | ------ ----- |---------| LSR | | LSR |1 | 1| | | |------------| ------ ----- | Network 1,1 Authenticated Interface Senevirathne Informational - September 2001 5 draft-tsenevir-mpls-lauth-00.txt April 2001 4.0 Use of Stream cipher techniques to encrypt the Label Stack The work presented in this document in essence encrypts the label stack. The encrypted label stack may only decrypted by the party that holds the correct parameters for the algorithm. It is possible that an attacker generate packets with undefined label stacks. This in essence would lead to erroneous forwarding. In order to avoid such attacks we propose that a known signature is included in the encrypted label stack. The unique signature that is only known to the parties may either be configured statically or may be obtained via some Public Key Infrastructure (PKI). The exact method of deriving the signature is out of the scope of this document. Let the Label stack with n labels (32*n bits) is L(n) Let the signature is S Let the random pattern is crc32 Let the randomize Label stack is L(n)" ; L(i)" = L(i) xor crc32 Let the Stream cipher function is StE() Let the Strem decipher function is StD() Let the Encrypted Label Stack is LE(m) Let the Decrypted Label Stack is LD(M) LE(m) = StE( crc32 | L(n)" | S ) LD(M) = StD(LE(m)) ; LD(M) <- crc32' | L'(n) | S' If S' = S then The label stack is valid and use normal forwarding ; L(n) <- L'(n) xor crc32 else discard packet crc32 is inserted at the beginning of the data stream. The receiver extracts the crc32 from the stream after deciphering. The derived crc32 is used to extract the original label stack. 4.1 Stream Cipher algorithms There are large number of published stream cipher algorithms. [3] Provide an excellent coverage on various available stream cipher Senevirathne Informational - September 2001 6 draft-tsenevir-mpls-lauth-00.txt April 2001 algorithms. We present three stream cipher algorithms that we believe would serve the purpose of Label stack authentication 4.1.1 A5 A5 is used in mobile telecommunication to encrypt voice data, [7], though written in Chinese (English translation available), provide a good coverage of the algorithm. [3] Includes the source code for the algorithm. 4.1.2 Fish and Pike Fish and Pike provide another good stream generator. Fish and Pike are both based on additive generators. Both of these algorithms may be used by deployments that do not require stringent security standards. 4.1.3 Gifford Gifford algorithm is presented in [8], and ideally suited for the application that is presented in this document. However the algorithm was known to have been broken. Again, this algorithm may be deployed in environments that does not require higher security requirements. 5.0 Use of DES to encrypt Label Stack Let the Label stack with n labels (32*n bits) is L(n) Let the signature is S Let D64 is the 64 bit aligned L(n)| S | PD Where PD is one or more bit padding Let DES encryption DES-E Let Encrypted output LE(m) Let DES decipher is DES-D Let de-encrypted output LD(m) LE(m) = DES-E(D64) LD(M) = DES-D(LE(m)) LD(M) -> L'(n)| S' | PD If S' = S then (L' == L) The label stack is valid and use normal forwarding Senevirathne Informational - September 2001 7 draft-tsenevir-mpls-lauth-00.txt April 2001 else discard packet 6.0 Payload encapsulation The encrypted label stack MUST be encapsulated in the following format to avoid any ambiguities. 6.0.1 Encoding of Encrypted Label Stack 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Number of Labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Encrypted Label Stack +-+-+-+-+-+-~ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length - Length of the encrypted label stack in bits Number of Labels - Number of Labels that are in the stack Note: This also can be part of Encrypted stack Encrypted Label Stack - Encrypted Label stack derived from one of the above methods Padding - one or more zero bit to aligned the encoding to 32-bit boundary. 6.0.2 Encapsulation of MPLS packet with encrypted Labels --------------------------------------------------------- | M-H | E-Labels | Payload | --------------------------------------------------------- M-H Media depended header for the MPLS packet E-Labels encrypted Labels stack in the format of 6.0.1 Payload payload of the MPLS packet 7.0 Identification of Authenticated MPLS packets Not all MPLS packets on an interface are authenticated. Users may require authenticating only packets belonging to high security LSP. Senevirathne Informational - September 2001 8 draft-tsenevir-mpls-lauth-00.txt April 2001 In such a scenario the receiving devices MUST be able to distinguish between packets that contain authenticated Label stack and packets that does not contain authenticated Label stacks. It is suggested to use a new Ethertype for the purpose to identify Secure MPLS packets that require security processing. New Ethertype for this purpose is being requested from IANA. 8.0 Security Considerations The work presented in this document affect the security of the MPLS data plane. Security analysis of the methods provided here has not yet been performed 9.0 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Schneier, B., Applied Cryptography, John Wiley and Sons, 1996. 4 Krawczyk, H., and et.al., HMAC: Keyed-Hashing for Message Authentication, RFC 2104, February 1997. 5 Madson, C., and Glenn, R., The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, November 1998. 6 Madson, C., and Glenn, R., The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, November 1998. 7 Xu, S.B, and et.al., An Implementation of the GSM General Data Encryption Algorithm A5, CHINACRYPT'94, 1994. 8 Gifford, D.K., and et.al., The Application of Digital Broadcast Communication to Large Scale Information Systems, IEEE Journal on Selected Areas in Communications, v.3., May 1985. 10.0 Author's Addresses Tissa Senevirathne Force10 Networks 1445 McCarthy Blvd Milpitas, CA Phone: 408-965-5103 Email: tissa@force10networks.com Senevirathne Informational - September 2001 9 draft-tsenevir-mpls-lauth-00.txt April 2001 Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne Informational - September 2001 10