idnits 2.17.1 draft-ietf-pim-v2-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 266 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 12 instances of lines with control characters in the document. ** The abstract seems to contain references ([KA98]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '...cation mechanism MUST support HMAC-MD5...' RFC 2119 keyword, line 195: '...in the AH header MUST be filled in wit...' RFC 2119 keyword, line 196: '...number, the receivers SHOULD check the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 66 has weird spacing: '...routing state...' -- 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 (July 14, 2000) is 8687 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'KA98' ** Downref: Normative reference to an Informational RFC: RFC 1321 -- Possible downref: Non-RFC (?) normative reference: ref. 'MG98' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group PIM Working Group 2 INTERNET DRAFT Editor, 3 Expire in six months Liming Wei 4 Redback Networks Inc. 5 July 14, 2000 7 Authenticating PIM version 2 messages 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "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 Abstract 34 This draft specifies the use of IPSEC authentication header [KA98] to 35 provide protocol message integrity protection and groupwise message 36 origin authentication. 38 The text in this draft will be either incorporated into or referenced 39 by the PIM version 2 protocol specifications. 41 1. Factors in authenticating PIM messages 43 Using authentication for PIM messages can protect routers from 44 unwanted behaviors due to unauthorized or altered PIM messages. The 45 extent of possible damage depends on the type of counterfeit messages 46 accepted. When there is a breach in security, those messages that travel 47 only one hop may affect a small number of routers or multicast groups, 48 while other multi-hop messages, such as the bootstrap messages, may 49 affect a larger number of routers. For this reason, sometimes, fine 50 grained controls uncommon in unicast protocols may be desired for 51 different PIM message types. The following explains the impact by 52 these multi-hop messages in more detail. 54 There are three main cases where a PIM router interacts with other 55 routers on different subnets. The PIM messages involved are not 56 changed or processed by routers in between the message originator and 57 receiver: 59 1) The bootstrap router sends authoritative group-to-RP mappings 60 to all other routers in the same PIM domain. If PIM routers accept 61 bootstrap messages from non-authorized candidate BSRs, it can 62 potentially disrupt multicast routing for the entire PIM domain. 64 2) Candidate RPs sending candidate RP advertisement messages to 65 the BSR. The BSR needs to avoid advertising bogus group-to-RP 66 mappings, which can lead to unpredictable routing state. 68 3) DRs sending Register messages to the RPs. The RPs need to ignore 69 register messages from unauthorized PIM sources. 71 In some networks, it is sufficient to trust all routers equally, and 72 let them all share the same secret for authentication. While other 73 networks may be more sensitive to to the potential impact of a 74 security breach in the first two cases above, and would want different 75 mechanisms to restrict the set of routers capable of being a BSR 76 or RP. 78 There is a fair number of security machineries from the IETF security 79 working groups, and we try to adhere to the most stable and widely 80 used solution. It is expected that the mechanism described in this 81 note will be able to accommodate newer algorithms and solutions 82 without redesigning the packet format. 84 2. Authentication Methods 86 When security is enabled, all PIM version 2 messages will carry an 87 IPSEC authentication header (AH) [KA98]. This section specifies two 88 message authentication methods based on manual key distributions. 89 More general key management issues are outside of the scope of this 90 specification. The authentication mechanism MUST support HMAC-MD5-96 91 [MG98][RFC1321] and HMAC-SHA-1-96 [SHA] security transformations. In 92 the subsequent text, a key is assumed to be associated with the two 93 standard transformations, unless explicitly declared otherwise. 95 2.1 "Equal Opportunity" Method 97 All routers within the domain use the same key for all PIM 98 messages. As its name suggests, once a router gained the shared 99 secret, it gains the ability to conduct any PIM actions. This key is 100 called the "equal opportunity" key. 102 This method is simple and effective in preventing unauthorized routers 103 from participating in protocol actions. 105 2.2 "Differentiated Capabilities" Method 107 The most likely PIM routers requiring additional securities are the 108 candidate bootstrap routers, and the candidate RPs. Such requirements 109 may be due to administrative needs, e.g. by network design that covers 110 pseudo-autonomous subdomains, or one that takes advantage of the 111 security features to manage the evolution. 113 As in the previous method, all PIM routers in the same domain still 114 share a single secret (the "equal opportunity" key) that is used to 115 compute digests for PIM messages. Except, the candidate BSRs and RPs 116 use two more keys to protect bootstrap and the candidate RP 117 advertisement messages: 119 o All BSRs own an identical RSA [PKCS1] key pair, and uses the 120 private key to sign an entire bootstrap message. The other 121 routers only have the public key to verify the signature, and be 122 assured that the bootstrap message was indeed originated from one 123 of the candidate BSRs, and intact. These keys are called the "BSR 124 private key" and "BSR public key" respectively. 126 o All RPs and BSRs share another symmetric key. No other routers 127 have this key. This key is called "the RP key". For candidate RP 128 advertisement the digest is only calculated with the RP key, 129 instead of the equal opportunity key. 131 Clearly, this method is more flexible than the previous one, with 132 the following advantages: 134 o Only authorized candidate BSRs can become a bootstrap router; 136 o Only the authorized candidate RPs can advertise their candidacy to 137 the BSR; 139 This makes it easier to support very large PIM domains where some PIM 140 routers may be managed by multiple operators. 142 3.2 PIM message formats 144 When security is enabled, all PIM message headers are appended an 145 authentication header that is identical to the IPSEC Authentication 146 Header (AH) defined in [KA98]. The IP header contains 51 in its Protocol 147 field. 149 The following illustrates how the AH is inserted in a PIM packet: 151 +-------------+------------+------------+-------------+ 152 | IP Header | AH | PIM header | PIM payload | 153 +-------------+------------+------------+-------------+ 155 The following AH format is extracted from [KA98]. When generating a 156 packet, for the purpose of calculating a digest or RSA signature, the 157 authentication data field is zeroed. When verifying a received packet, 158 the value in the authentication data field is saved before zeroing. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Next Header | Payload Len | RESERVED | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Security Parameters Index (SPI) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Sequence Number Field | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | 170 + Authentication Data (variable) | 171 | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Next Header: 103, the value for PIM protocol. 176 Payload len: 4, when HMAC-MD5-96 or HMAC-SHA-1-96 177 is used (AH total length is 6 32-bit 178 words). 179 Variable, depending on the RSA key length for 180 bootstrap messages. 182 RESERVED: 0 when sent, ignored when received. 184 SPI: Security parameter index. 185 When the differentiated capability method is 186 in use, separate SPIs are needed for the 187 different security associations. 189 Sequence Number: Initialized to zero, incremented by one on 190 each subsequent PIM message from the same 191 originator. 193 Authentication Data: message digest 195 The sequence number field in the AH header MUST be filled in with 196 a non-decreasing 32-bit number, the receivers SHOULD check the 197 sequence number and reject duplicate or old messages. 199 When the sequence number wraps around, newer messages may be rejected 200 because the sequence numbers are smaller. Although it takes extremely 201 long time to wrap around the sequence number (e.g. if on average 1 PIM 202 message is sent in every second, it will take 136 years for the 203 sequence number to wrap around.), to guard against sequence number 204 wrap-around in abnormal conditions, each staticly configured SPI 205 SHOULD have one or more rollover SPIs, to be used upon sequence number 206 wrap around. 208 4. Security Considerations 210 The strength of message integrity protection and groupwise message 211 origin authentication depends on the strength of the underlying 212 security transformations used. According to [MG98][SHA][PKCS1], to 213 date, there are no known attacks against these algorithms. 215 5. Acknowledgements 217 The ideas in this draft were contributed or instigated by Dino 218 Farinacci, David Meyer, Dan Harkins, Tony Speakman, Cheryl Madson, 219 Brian Weis, Achutha Rao and Tom Pusateri. Other members of the PIM 220 working group also contributed to the discussions and ideas in this 221 draft. 223 6. References 225 [KA98] Kent Stephen, Randall Atkinson, "IP Authentication Header", 226 "draft-ietf-ipsec-auth-header-07.txt", July 1998 228 [RFC1321] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992 230 [MG98] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", 231 "draft-ietf-ipsec-auth-hmac-md5-96-03.txt", Feb 1998 233 [PKCS1] RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5, 234 No. 1993 236 [SHA] C. Madson, R Glenn "The Use of HMAC-SHA-1-96 within ESP and AH", 237 "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt", Feb, 1998 239 6. Editor's address 241 Liming Wei 242 Redback Networks, Inc. 243 350 Holger Way, 244 San Jose, CA 95134 245 lwei@redback.com