idnits 2.17.1 draft-bhatia-zhang-pim-auth-extension-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2013) is 4047 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FIPS-198' is mentioned on line 222, but not defined == Outdated reference: A later version (-01) exists of draft-bhatia-karp-pim-gap-analysis-00 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-04 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Experimental D. Zhang 5 Expires: September 29, 2013 Huawei 6 B. Joshi 7 Infosys Ltd. 8 March 28, 2013 10 In-Band Authentication Extension for Protocol Independent Multicast 11 draft-bhatia-zhang-pim-auth-extension-03 13 Abstract 15 Existing security mechanisms for the Protocol Independent Multicast - 16 Sparse Mode (PIM-SM) routing protocol mandates the use of IPsec to 17 provide message authenticity and integrity. This draft proposes an 18 embedded authentication mechanism to facilitate data origin 19 authentication and integrity verification for PIM packets in the 20 cases where IPsec cannot be applied. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 29, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 64 3. PIM Security Association . . . . . . . . . . . . . . . . . . . 5 65 4. PIM Packet Processing . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 6 67 4.2. Outbounding Packet Processing . . . . . . . . . . . . . . 7 68 4.3. Inbounding Packet Processing . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5.1. Register packet processing . . . . . . . . . . . . . . . . 9 71 5.2. Inter-Session Replay Attack Issue . . . . . . . . . . . . 9 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 [RFC5796] describes the methods of using the IP security (IPsec) 81 Encapsulating Security Payload (ESP) [RFC4303] or the Authentication 82 Header (AH) [RFC4302] (which is optional) to protect the authenticity 83 and integrity of the link-local messages of Protocol Independent 84 Multicast - Sparse Mode (PIM-SM)[RFC4601]. [RFC5796] mandates the 85 application of manual key management mechanisms and provide optional 86 support for an automated group key management mechanism. However, 87 the procedures for implementing automated group key management are 88 not specified. 90 It has been clarified in [I-D.bhatia-karp-pim-gap-analysis] that 91 without the support of automated group key management mechanisms, the 92 PIM packets protected by IPsec will be vulnerable to both inter- 93 session and inner-session replay attacks. In addition, the poor 94 scalability of manual keying may cause deployment issues in many 95 typical scenarios. This document proposes few changes in the PIM 96 header which helps in carrying authentication data along with the 97 usual PIM packet. The PIM packet contains all the essential 98 inforamtion for data origin authentication and message integrity 99 verification without the support of IPsec. 101 In this solution, it is assumed that manual keying is performed while 102 the automatic key management mechanisms are not precluded. A 103 strictly increasing sequence number is adopted to address the replay 104 attack issues. However, the work of addressing the scalability 105 issues imposed by manual keying is out of scope of this draft. 107 2. Proposed Solution 109 This document adds some more fields in PIM packet to carry the 110 authentication information. Figure 1 illustrates the format of a PIM 111 packet that carries authentication information. 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 116 |PIM Ver| Type |A| Reserved | PIM Message Length | Header 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 118 | Key ID | Auth Data Len | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth 120 | Cryptographic Sequence Number (High Order 32 Bits) | Header 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Cryptographic Sequence Number (Low Order 32 Bits) | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 124 | | 125 ~ PIM Message ~ 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 128 | | 129 ~ Authentication Data ~ 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 133 Figure 1. Format of a PIM packet carrying authentication information 135 PIM Ver: PIM Version number is 2. 137 Type: Types for specific PIM messages. PIM types are defined in 138 [RFC4601]. 140 Auth bit: If 'Auth' bit is 1, it means the PIM packet is carrying 141 authentication information. If 'Auth' bit is 0, it means the PIM 142 packet is not carrying authentication information and such a 143 packet should be handled as specified in [RFC4601]. 145 Reserved: Set to zero on transmission. Ignored upon receipt. 147 PIM Message Length: A 16-bit field that contains the length of the 148 PIM message. This length does not include the length of the PIM 149 header, PIM auth header and authentication data. 151 Key ID: A 16-bit field that identifies the secret key and the 152 algorithm used to create the authentication data. 154 Auth Data Len: A 16-bit field that identifies the length of the 155 trailing authentication data field. 157 Cryptographic Sequence Number: A 64-bit strictly increasing 158 sequence number that is used to guard against replay attacks. The 159 64-bit sequence number MUST be incremented for every PIM packet 160 carrying authentication. Upon reception, the sequence number MUST 161 be greater than the sequence number in the last PIM packet 162 accepted from the PIM router sending the packet. Otherwise, the 163 PIM packet is considered a replayed packet and dropped. PIM 164 routers implementing this specification SHOULD use available 165 mechanisms to preserve the sequence number's strictly increasing 166 property for the deployed life of the PIM router (including cold 167 restarts). Techniques such as sequence number space partitioning 168 and non-volatile storage preservation can be used but are beyond 169 the scope of this specification. 171 PIM Message: PIM message as specified in [RFC4601]. 173 Authentication Data: Variable length authentication data. This 174 field carries the digest for the protocol packet. 176 A PIM packet carrying authentication information does not need 177 checksum for integrity check. So 'checksum' field has been replaced 178 with 'PIM Message Length' in a PIM packet carrying authentication 179 information. 181 3. PIM Security Association 183 A PIM Security Association (SA) consists of a set of parameters for 184 PIM routers to correctly generate or verify PIM packets carrying 185 authentication information. In manual keying, it is the 186 responsibility of network operators to generate and deploy PIM SAs 187 amongst PIM routers appropriately to ensure the routers can exchange 188 PIM messages. 190 The parameters associated with a PIM SA: 192 o Key Identifier (Key ID) : A 16-bit unsigned integer which is used 193 to uniquely identify a PIM SA within a PIM domain. 195 o Authentication Algorithm: This parameter is used to indicate 196 authentication algorithm to be used with the PIM SA. The value of 197 this parameter can be implementation specific. The following 198 algorithms SHOULD be supported: HMAC-SHA-1, HMAC-SHA-256, HMAC- 199 SHA-384, and HMAC-SHA-512. 201 o Key: The value of this parameter denotes the cryptographic key 202 associated with the key ID. The length of this key is determined 203 by the algorithm specified in the PIM SA. 205 o Key Start Accept: The time after which a PIM router will accept a 206 packet if it is created with this PIM SA. 208 o Key Start Generate: The time after which a PIM router will begin 209 using this PIM SA for PIM packet generation. 211 o Key Stop Generate: The time after which a PIM router will stop 212 using this PIM SA for PIM packet generation. 214 o Key Stop Accept: The time after which a PIM router will refuse to 215 accept a packet if it is generated with this PIM SA. 217 4. PIM Packet Processing 219 4.1. Cryptographic Aspects 221 In the algorithm description below, the following nomenclature, which 222 is consistent with [FIPS-198], is used: 224 H is the specific hashing algorithm (e.g. SHA-256). 226 K is the Authentication Key for the PIM security association. 228 Ko is the cryptographic key used with the hash algorithm. 230 B is the block size of H, measured in octets rather than bits. 232 Note that B is the internal block size, not the hash size. 234 For SHA-1 and SHA-256: B == 64 236 For SHA-384 and SHA-512: B == 128 238 L is the length of the hash, measured in octets rather than bits. 240 XOR is the exclusive-or operation. 242 Opad is the hexadecimal value 0x5c repeated B times. 244 Ipad is the hexadecimal value 0x36 repeated B times. 246 Apad is a value which is the same length as the hash output or 247 message digest. If the packet is transported upon IPv6, the first 16 248 octets contain the IPv6 source address followed by the hexadecimal 249 value 0x878FE1F3 repeated (L-16)/4 times. If the packet is 250 transported upon IPv4, the first 4 octets contain the IPv4 source 251 address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 252 times. 254 1. Preparation of the Key 255 In this application, Ko is always L octets long. 257 If the Authentication Key (K) is L octets long, then Ko is equal 258 to K. If the Authentication Key (K) is more than L octets long, 259 then Ko is set to H(K). If the Authentication Key (K) is less 260 than L octets long, then Ko is set to the Authentication Key (K) 261 with zeros appended to the end of the Authentication Key (K) such 262 that Ko is L octets long. 264 2. First Hash 266 First, the PIM packet's Authentication Data field is filled with 267 the value Apad. 269 Then, a First-Hash, also known as the inner hash, is computed as 270 follows: 272 If the PIM packet is a Register packet 274 First-Hash = H(Ko XOR Ipad || (PIM Packet - Data Part)) 276 else 278 First-Hash = H(Ko XOR Ipad || (PIM Packet)) 280 The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; 281 for SHA-384, 48 octets; and for SHA-512, 64 octets. 283 3. Second Hash 285 Then a second hash, also known as the outer hash, is computed as 286 follows: 288 Second-Hash = H(Ko XOR Opad || First-Hash) 290 4. Result 292 The resulting Second-Hash becomes the authentication data that is 293 added in the PIM packet. The length of the authentication data is 294 always identical to the message digest size of the specific hash 295 function H that is being used. 297 4.2. Outbounding Packet Processing 299 If embedded authentication is enabled, sender first finds an 300 appropriate PIM security association (SA) to be used for this packet. 301 Following processing is done: 303 o It first prepares the PIM header and PIM auth header as follows: 305 * PIM version is set to 2 307 * Type field is set to the PIM message type that is being sent. 309 * Auth bit is set to 1. 311 * Reserved field is set to 0. 313 * Key ID is set to the key-id from PIM SA 315 * Auth Data Len is set to the length of the Authentication Data 316 field which is determined based on the algorithm specified in 317 the selected SA. 319 * The sequence number for the selected SA is increased and the 320 new value is inserted into the Sequence Number field. 322 o It then populates the PIM message that is to be sent out. As 323 length of the PIM message is now known, it is updated in the PIM 324 header. 326 o The Authentication Data field is set to Apad and then sender 327 generates the authentication data as described in Section 4.1 for 328 the PIM packet. Calculate authentication data is inserted in the 329 Authentication data field. 331 After this PIM packet is sent out on the idenfitied interface. 333 4.3. Inbounding Packet Processing 335 A router identifies a received PIM packet is carrying authentication 336 data by examining the 'Auth' bit in the PIM header. If the 'Auth' 337 bit is 1, it means the PIM packet is carrying embedded authentication 338 information. Following processing is done: 340 o Find the PIM SA for the Key ID available in PIM auth header in the 341 PIM packet. If no valid PIM SA is found for this packet or the 342 PIM SA is not in its valid period, receiver MUST discard the 343 packet and SHOULD log an error event. 345 o If the cryptographic sequence number of the packet is less than or 346 equal to the last sequence number received from the same PIM 347 router, receiver MUST discard the packet and SHOULD log an error 348 event. 350 o Find the Auth data len expected from the PIM SA and compare it 351 against the Auth Data Len in the packet. If the two do not match, 352 receiver MUST discard the packet and SHOULD log an error event. 354 o Calculate the PIM message length using total packet length from IP 355 header and Auth Data Len from PIM Auth Header. Compare it with 356 the PIM message length in PIM header. If the two do not match, 357 receiver MUST discard the packet and SHOULD log an error event. 359 o Receiver stores the Authentication Data from packet locally. It 360 then fills the Authentication Data field with Apad. Then the 361 receiver calculates the authentication data for the PIM packet as 362 described in Section 4.1. The calculated authentication data is 363 then compared with the received authentication data in PIM packet. 364 If the two do not match, reciever MUST discard the packet and 365 SHOULD log an error event. If the two matches, PIM message is 366 passed for further processing. 368 5. Security Considerations 370 5.1. Register packet processing 372 The solution proposed in this draft only intends to secure PIM 373 singaling packets. The efforts for protecting data packets 374 transported among PIM routers is out of scope. Therefore, for a 375 register packet, only PIM header, PIM Auth Header, the B field and 376 the N field are secured while the Multicast data packet part is not 377 protected. 379 5.2. Inter-Session Replay Attack Issue 381 When a router is rebooted, the sequence number will be re- 382 initialzed. This will cause a problem. When a PIM router receive a 383 hello message with a changed GenID and an re-inialized sequence 384 number, it is difficult for the receiver to distinguish this message 385 from a replay attack. The soltuion proposed in this document is 386 subject to this problem. However, the experience in 387 [I-D.ietf-ospf-security-extension-manual-keying] can be used to 388 address this problem. In the solution proposed in 389 [I-D.ietf-ospf-security-extension-manual-keying], there is a reboot 390 counter maintained in non-volatile memory which is increased by 1 391 after every reboot. The reboot count value is set into the first 32 392 bits of the sequence number. Therefore, even after a restart, the 393 sequence number will still be increased. 395 6. Acknowledgements 397 We would like to thank Stig Venaas for his kind review and comments 398 on this document. 400 7. References 402 7.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 7.2. Informative References 409 [I-D.bhatia-karp-pim-gap-analysis] 410 Bhatia, M., "Analysis of Protocol Independent Multicast 411 Sparse Mode (PIM-SM) Security According to KARP Design 412 Guide", draft-bhatia-karp-pim-gap-analysis-00 (work in 413 progress), April 2011. 415 [I-D.ietf-ospf-security-extension-manual-keying] 416 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 417 "Security Extension for OSPFv2 when using Manual Key 418 Management", 419 draft-ietf-ospf-security-extension-manual-keying-04 (work 420 in progress), February 2013. 422 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 423 December 2005. 425 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 426 RFC 4303, December 2005. 428 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 429 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 430 Protocol Specification (Revised)", RFC 4601, August 2006. 432 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 433 Confidentiality in Protocol Independent Multicast Sparse 434 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. 436 Authors' Addresses 438 Manav Bhatia 439 Alcatel-Lucent 441 Email: manav.bhatia@alcatel-lucent.com 443 Dacheng Zhang 444 Huawei 446 Email: zhangdacheng@huawei.com 448 Bharat Joshi 449 Infosys Ltd. 451 Email: bharat_joshi@infosys.com