Network Working Group M. Bhatia Internet-Draft Alcatel-Lucent Intended status: Experimental D. Zhang Expires: September 29, 2013 Huawei B. Joshi Infosys Ltd. March 28, 2013 In-Band Authentication Extension for Protocol Independent Multicast draft-bhatia-zhang-pim-auth-extension-03 Abstract Existing security mechanisms for the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol mandates the use of 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 cannot be 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 September 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Bhatia, et al. Expires September 29, 2013 [Page 1] Internet-Draft Authentication Extension for PIM March 2013 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. PIM Packet Processing . . . . . . . . . . . . . . . . . . . . 6 4.1. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 6 4.2. Outbounding Packet Processing . . . . . . . . . . . . . . 7 4.3. Inbounding Packet Processing . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Register packet processing . . . . . . . . . . . . . . . . 9 5.2. Inter-Session Replay Attack Issue . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Bhatia, et al. Expires September 29, 2013 [Page 2] Internet-Draft Authentication Extension for PIM March 2013 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 not specified. 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 few changes in the PIM header which helps in carrying authentication data along with the usual PIM packet. The PIM packet contains all the essential inforamtion for data origin authentication and message integrity verification without the support of IPsec. In this solution, it is assumed that manual keying is performed while the automatic key management mechanisms are not precluded. A strictly 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 This document adds some more fields in PIM packet to carry the authentication information. Figure 1 illustrates the format of a PIM packet that carries authentication information. Bhatia, et al. Expires September 29, 2013 [Page 3] Internet-Draft Authentication Extension for PIM March 2013 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 |A| Reserved | PIM Message Length | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Key ID | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth | Cryptographic Sequence Number (High Order 32 Bits) | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic Sequence Number (Low Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | | ~ PIM Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ Figure 1. Format of a PIM packet carrying authentication information PIM Ver: PIM Version number is 2. Type: Types for specific PIM messages. PIM types are defined in [RFC4601]. Auth bit: If 'Auth' bit is 1, it means the PIM packet is carrying authentication information. If 'Auth' bit is 0, it means the PIM packet is not carrying authentication information and such a packet should be handled as specified in [RFC4601]. Reserved: Set to zero on transmission. Ignored upon receipt. PIM Message Length: A 16-bit field that contains the length of the PIM message. This length does not include the length of the PIM header, PIM auth header and authentication data. Key ID: A 16-bit field that identifies the secret key and the algorithm used to create the authentication data. Auth Data Len: A 16-bit field that identifies the length of the trailing authentication data field. 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 PIM packet carrying authentication. Upon reception, the sequence number MUST Bhatia, et al. Expires September 29, 2013 [Page 4] Internet-Draft Authentication Extension for PIM March 2013 be greater than the sequence number in the last PIM packet accepted from the PIM router sending the packet. Otherwise, the PIM 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. PIM Message: PIM message as specified in [RFC4601]. Authentication Data: Variable length authentication data. This field carries the digest for the protocol packet. A PIM packet carrying authentication information does not need checksum for integrity check. So 'checksum' field has been replaced with 'PIM Message Length' in a PIM packet carrying authentication information. 3. PIM Security Association A PIM Security Association (SA) consists of a set of parameters for PIM routers to correctly generate or verify PIM packets carrying authentication information. 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 messages. The parameters associated with a PIM SA: o Key Identifier (Key ID) : A 16-bit unsigned integer which is used to uniquely identify a PIM SA within a PIM domain. o Authentication Algorithm: This parameter is used to indicate authentication algorithm to be used with the PIM SA. The value of this parameter can be implementation specific. The 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. Bhatia, et al. Expires September 29, 2013 [Page 5] Internet-Draft Authentication Extension for PIM March 2013 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. PIM 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. 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 Bhatia, et al. Expires September 29, 2013 [Page 6] Internet-Draft Authentication Extension for PIM March 2013 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 PIM packet's Authentication Data field is filled with the value Apad. Then, a First-Hash, also known as the inner hash, is computed as follows: If the PIM packet is a Register packet First-Hash = H(Ko XOR Ipad || (PIM Packet - Data Part)) else First-Hash = H(Ko XOR Ipad || (PIM 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 The resulting Second-Hash becomes the authentication data that is added in the PIM packet. 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 If embedded authentication is enabled, sender first finds an appropriate PIM security association (SA) to be used for this packet. Following processing is done: Bhatia, et al. Expires September 29, 2013 [Page 7] Internet-Draft Authentication Extension for PIM March 2013 o It first prepares the PIM header and PIM auth header as follows: * PIM version is set to 2 * Type field is set to the PIM message type that is being sent. * Auth bit is set to 1. * Reserved field is set to 0. * Key ID is set to the key-id from PIM SA * Auth Data Len is set to the length of the Authentication Data field which is determined based on the algorithm specified in the selected SA. * The sequence number for the selected SA is increased and the new value is inserted into the Sequence Number field. o It then populates the PIM message that is to be sent out. As length of the PIM message is now known, it is updated in the PIM header. o The Authentication Data field is set to Apad and then sender generates the authentication data as described in Section 4.1 for the PIM packet. Calculate authentication data is inserted in the Authentication data field. After this PIM packet is sent out on the idenfitied interface. 4.3. Inbounding Packet Processing A router identifies a received PIM packet is carrying authentication data by examining the 'Auth' bit in the PIM header. If the 'Auth' bit is 1, it means the PIM packet is carrying embedded authentication information. Following processing is done: o Find the PIM SA for the Key ID available in PIM auth header in the PIM packet. If no valid PIM SA is found for this packet or the PIM SA is not in its valid period, receiver MUST discard the packet and SHOULD log an error event. o If the cryptographic sequence number of the packet is less than or equal to the last sequence number received from the same PIM router, receiver MUST discard the packet and SHOULD log an error event. Bhatia, et al. Expires September 29, 2013 [Page 8] Internet-Draft Authentication Extension for PIM March 2013 o Find the Auth data len expected from the PIM SA and compare it against the Auth Data Len in the packet. If the two do not match, receiver MUST discard the packet and SHOULD log an error event. o Calculate the PIM message length using total packet length from IP header and Auth Data Len from PIM Auth Header. Compare it with the PIM message length in PIM header. If the two do not match, receiver MUST discard the packet and SHOULD log an error event. o Receiver stores the Authentication Data from packet locally. It then fills the Authentication Data field with Apad. Then the receiver calculates the authentication data for the PIM packet as described in Section 4.1. The calculated authentication data is then compared with the received authentication data in PIM packet. If the two do not match, reciever MUST discard the packet and SHOULD log an error event. If the two matches, PIM message is passed for further processing. 5. Security Considerations 5.1. Register packet processing The solution proposed in this draft only intends to secure PIM singaling packets. The efforts for protecting data packets transported among PIM routers is out of scope. Therefore, for a register packet, only PIM header, PIM Auth Header, the B field and the N field are secured while the Multicast data packet part is not protected. 5.2. 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 receive 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-volatile memory which is increased by 1 after every reboot. The reboot 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. Bhatia, et al. Expires September 29, 2013 [Page 9] Internet-Draft Authentication Extension for PIM March 2013 6. Acknowledgements We would like to thank Stig Venaas for his kind review and comments on this document. 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-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-04 (work in progress), February 2013. [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, et al. Expires September 29, 2013 [Page 10] Internet-Draft Authentication Extension for PIM March 2013 Authors' Addresses Manav Bhatia Alcatel-Lucent Email: manav.bhatia@alcatel-lucent.com Dacheng Zhang Huawei Email: zhangdacheng@huawei.com Bharat Joshi Infosys Ltd. Email: bharat_joshi@infosys.com Bhatia, et al. Expires September 29, 2013 [Page 11]