Network Working Group M. Bhatia Internet-Draft Alcatel-Lucent Intended status: Experimental D. Zhang Expires: March 6, 2013 Huawei September 6, 2012 In-Band Authentication Extension for Protocol Independent Multicast (PIM) draft-bhatia-zhang-pim-auth-extension-02 Abstract Existing security mechanisms for the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol mandates to use IPsec to provide message authenticity and integrity. This draft proposes an embedded authentication mechanism to facilitate data origin authentication and integrity verification for PIM packets in the cases where IPsec is not applied. Requirements Language 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 March 6, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Bhatia & Zhang Expires March 6 2013 [Page 1] Internet-Draft Authentication Extension for PIM Sep. 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 3. PIM Security Association . . . . . . . . . . . . . . . . . . . 5 4. AEP Packet Processing . . . . . . . . . . . . . . . . . . . . 6 4.1. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 6 4.2. Outbounding Packet Processing . . . . . . . . . . . . . . 8 4.3. Inbounding Packet Processing . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Register Packet Processing . . . . . . . . . . . . . . . . 9 5.2. New Packet Type Versus Authentication Trailer . . . . . . 9 5.3. Inter-Session Replay Attack Issue . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Bhatia & Zhang Expires March 6 2012 [Page 2] Internet-Draft Authentication Extension for PIM Sep. 2012 1. Introduction [RFC5796] describes the methods of using the IP security (IPsec) Encapsulating Security Payload (ESP) [RFC4303] or the Authentication Header (AH) [RFC4302] (which is optional) to protect the authenticity and integrity of the link-local messages of Protocol Independent Multicast - Sparse Mode (PIM-SM)[RFC4601]. [RFC5796] mandates the application of manual key management mechanisms and provide optional support for an automated group key management mechanism. However, the procedures for implementing automated group key management are left undone yet. It has been clarified in [I-D.bhatia-karp-pim-gap-analysis] that without the support of automated group key management mechanisms, the PIM packets protected by IPsec will be vulnerable to both inter- session and inner-session replay attacks. In addition, the poor scalability of manual keying may cause deployment issues in many typical scenarios. This document proposes a new type of PIM packet, called the Authentication Extension PIM packet (AEP), which is able to facilitate data origin authentication and message integrity verification for PIM packets without the support of IPsec. An AEP actually contains all the essential information of a PIM packet being protected and provides cryptographic methods for the receiver to assess the authenticity and integrity of the packet. In this solution, it is assumed that manual keying is performed while the automatic key management mechanisms are not precluded. Within a packet proposed in this document, a monotonically increasing sequence number is adopted to address the replay attack issues. However, the work of addressing the scalability issues imposed by manual keying is out of scope of this draft. 2. Proposed Solution Figure 1 illustrates the format of an example packet header. Bhatia & Zhang Expires March 6 2013 [Page 3] Internet-Draft Authentication Extension for PIM Sep. 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ |PIM Ver| Type 1| Reserved 1 | Checksum | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |Original | Remainder part of the packet expected | packet ~ to be protected ~ | | | | | | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | | | V 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ |PIM Ver| Type | Reserved | Checksum | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Key ID | Auth Data Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Cryptographic Sequence Number (High Order 32 Bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header | Cryptographic Sequence Number (Low Order 32 Bits) | of AEP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Authentication Data (Variable) | | ~ ~ | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Type 1| Reserved 1 | | ^ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | |Protected | Remainder part of the packet expected | packet ~ to be protected ~ | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ Figure 1. The format of an example AEP In compliance with [RFC4601], the first four fields of the AEP header is identical to those of the original types of PIM packets. Particularly, the PIM Version number is set to 2. The type number of AEP is 9 in order to distinguish AEP from other types of PIM packets. The Reserved field is set to zero on transmission and ignored upon receipt. The checksum field of the AEP is set to zero, and the checksum calculation and verification are omitted. Bhatia & Zhang Expires March 6 2013 [Page 4] Internet-Draft Authentication Extension for PIM Sep. 2012 Other fields of in the AEP header are described as follows: Key ID: A 16-bit field that identifies the secret key and the algorithm used to create the authentication data. Cryptographic Sequence Number: A 64-bit strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every AEP packet sent by a PIM router. Upon reception, the sequence number MUST be greater than the sequence number in the last AEP packet accepted from the PIM router sending the packet. Otherwise, the AEP packet is considered a replayed packet and dropped. PIM routers implementing this specification SHOULD use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the PIM router (including cold restarts). Techniques such as sequence number space partitioning and non- volatile storage preservation can be used but are beyond the scope of this specification. Authentication Data: A field with a variable length. The field carries the digest for the protocol packet and other optional information. Type 1: This 4-bit field indicate the type of the encapsulated PIM packet. Reserved 1: This 8-bit field is identical to the Reserved field of the encapsulated PIM packet. Because the Version field and the Checksum field in the header of the encapsulated PIM packet are redundant, they are removed. 3. PIM Security Association An PIM Security Association (SA) consists of a set of parameters for PIM routers to correctly generate or verify AEP packets. In manual keying, it is the responsibility of network operators to generate and deploy PIM SAs amongst PIM routers appropriately to ensure the routers can exchange PIM signalling messages securely. The parameters associated with a PIM SA: o Key Identifier (Key ID) : A 16-bit unsigned integer which is used to uniquely identify an PIM SA within a PIM domain. o Authentication Algorithm: This parameter is used to indicate the authentication algorithm to be used with the PIM SA. The value of this parameter can be implementer specific. Currently, the Bhatia & Zhang Expires March 6 2013 [Page 5] Internet-Draft Authentication Extension for PIM Sep. 2012 following algorithms SHOULD be supported: HMAC-SHA-1, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. o Key: The value of this parameter denotes the cryptographic key associated with the key ID. The length of this key is determined by the algorithm specified in the PIM SA. o Key Start Accept: The time after which a PIM router will accept a packet if it is created with this PIM SA. o Key Start Generate: The time after which a PIM router will begin using this PIM SA for PIM packet generation. o Key Stop Generate: The time after which a PIM router will stop using this PIM SA for PIM packet generation. o Key Stop Accept: The time after which a PIM router will refuse to accept a packet if it is generated with this PIM SA. 4. AEP Packet Processing 4.1. Cryptographic Aspects In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used: H is the specific hashing algorithm (e.g. SHA-256). K is the Authentication Key for the PIM security association. Ko is the cryptographic key used with the hash algorithm. B is the block size of H, measured in octets rather than bits. Note that B is the internal block size, not the hash size. For SHA-1 and SHA-256: B == 64 For SHA-384 and SHA-512: B == 128 L is the length of the hash, measured in octets rather than bits. XOR is the exclusive-or operation. Opad is the hexadecimal value 0x5c repeated B times. Ipad is the hexadecimal value 0x36 repeated B times. Bhatia & Zhang Expires March 6 2013 [Page 6] Internet-Draft Authentication Extension for PIM Sep. 2012 Apad is a value which is the same length as the hash output or message digest. If the packet is transported upon IPv6, the first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. If the packet is transported upon IPv4, the first 4 octets contain the IPv4 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. 1. Preparation of the Key In this application, Ko is always L octets long. If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K) such that Ko is L octets long. 2. First Hash First, the AEP packet's Authentication Data field in the AEP header is filled with the value Apad. Then, a First-Hash, also known as the inner hash, is computed as follows: If the original packet is a Register packet First-Hash = H(Ko XOR Ipad || (AEP Packet-Data Part)) else First-Hash = H(Ko XOR Ipad || (AEP Packet)) The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; for SHA-384, 48 octets; and for SHA-512, 64 octets. 3. Second Hash Then a second hash, also known as the outer hash, is computed as follows: Second-Hash = H(Ko XOR Opad || First-Hash) 4. Result Bhatia & Zhang Expires March 6 2013 [Page 7] Internet-Draft Authentication Extension for PIM Sep. 2012 The resulting Second-Hash becomes the authentication data that is sent in the AEP header. The length of the authentication data is always identical to the message digest size of the specific hash function H that is being used. 4.2. Outbounding Packet Processing First of all, a sender needs to find a proper PIM SA and generate a PIM header. The checksum field of the AEP header is set as zero. The length of the Authentication Data field is determined according the algorithm specified in the SA. The sequence number for this SA is increased, and the new value is inserted into the Sequence Number field. The Authentication Data field is set as Apad. After these, the sender appends the encapsulated PIM packet (without the redundant fields) at the end of the AEP header and generates the authentication data as illustrated in Section 4.1. After inserting the calculated authentication data into the Authentication Data field, the sender delivers the packet. 4.3. Inbounding Packet Processing A router identifies a received PIM packet is an AEP by examining the Type field in PIM packet header. If the cryptographic sequence number of the packet is less than or equal to the last sequence number received from the PIM router, the AEP packet MUST be dropped. If the Checksum fields in the AEP header and in the PIM header of the encapsulated PIM packet are not zero, the AEP packet MUST be dropped. According to the key ID in the packet header, the receiver tries to find the associated PIM SA. If no valid PIM SA exists for this packet or the key is not in its valid period, the receiver MUST discard the packet. If the appropriate PIM SA for the received packet is found, the receiver starts performing the authentication algorithm dependent processing, using the algorithm specified in the SA. In the first step, the receiver derives the cryptographic algorithm from the PIM SA and identify the length of the Authentication Data field. Then the receiver fills the Authentication Data field with Apad . After this, the receiver calculate the authentication data for the AEP as described in Section 4.1. The calculated data is compared with the received authentication data in AEP header. If the two do not match, the packet MUST be discarded. In such a case, an error event SHOULD be logged. Bhatia & Zhang Expires March 6 2013 [Page 8] Internet-Draft Authentication Extension for PIM Sep. 2012 5. Security Considerations 5.1. Register Packet Processing The solution proposed in this draft only intends to secure PIM signaling packets. The efforts of protecting data packets transported among PIM routers are out of scope. Therefore, for a register packet, only the Type field, the B field, and the N field are secured while the Multicast data packet part is not protected by the authentication data. 5.2. New Packet Type Versus Authentication Trailer Both PIM and OSPFv3 rely on IPsec to secure packet transmission, and they meet similar security issues, such as the vulnerability to the replay attacks and lack of support to priority packets. [I-D.ietf-ospf-auth-trailer-ospfv3] proposes an authentication trailer which is appended at the end of an OSPFv3 packet and provides IPsec independent authentication for the packet. This idea can also be adopted into PIM. However, compared with the OSPFv3 packet header, the PIM header lacks a field to point out the length the PIM packet. The length of the PIM packet is actually indicated by the length of the IP payload and can be variable. This raises a issue. If an authentication trailer is attached at the end of a PIM packet, it will be difficult to locate. This issue can be addressed by extending the PIM headers with an Length field. 5.3. Inter-Session Replay Attack Issue When a router is rebooted , the sequence number will be re- initialzed. This will cause a problem. When a PIM router received a hello message with a changed GenID and an re-inialized sequence number, it is difficult for the receiver to distinguish this message from a replay attack. The soltuion proposed in this document is subject to this problem. However, the experience in [I-D.ietf-ospf-security-extension-manual-keying] can be used to address this problem. In the solution proposed in [I-D.ietf-ospf-security-extension-manual-keying], there is a reboot counter maintained in non-violate memory which is increased by 1 after every reboot. The count value is set into the first 32 bits of the sequence number. Therefore, even after a restart, the sequence number will still be increased. 6. Acknowledgements We would like to thank Stig Venaas for his kindly review work and comments on this document. Bhatia & Zhang Expires March 6 2013 [Page 9] Internet-Draft Authentication Extension for PIM Sep. 2012 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.bhatia-karp-pim-gap-analysis] Bhatia, M., "Analysis of Protocol Independent Multicast Sparse Mode (PIM-SM) Security According to KARP Design Guide", draft-bhatia-karp-pim-gap-analysis-00 (work in progress), April 2011. [I-D.ietf-ospf-auth-trailer-ospfv3] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", draft-ietf-ospf-auth-trailer-ospfv3-11 (work in progress), November 2011. [I-D.ietf-ospf-security-extension-manual-keying] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 when using Manual Key Management", draft-ietf-ospf-security-extension-manual-keying-01 (work in progress), October 2011. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. Bhatia & Zhang Expires March 6 2013 [Page 10] Internet-Draft Authentication Extension for PIM March 2012 Authors' Addresses Manav Bhatia Alcatel-Lucent Email: manav.bhatia@alcatel-lucent.com Dacheng Zhang Huawei Email: zhangdacheng@huawei.com Bhatia & Zhang Expires March 6 2013 [Page 11]