idnits 2.17.1 draft-ietf-ipsec-sctp-05.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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 379 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2401], [RFC2960], [RFC2409]), 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 95: '...tiated peer addresses, MUST return the...' RFC 2119 keyword, line 104: '...irst case, the outer addresses MUST be...' RFC 2119 keyword, line 109: '...ination address, and MUST use the same...' RFC 2119 keyword, line 112: '... tunnel, and MUST use the the same d...' RFC 2119 keyword, line 125: '... SCTP association, it MUST be possible...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2401' on line 303 looks like a reference -- Missing reference section? 'RFC2409' on line 319 looks like a reference -- Missing reference section? 'RFC2960' on line 322 looks like a reference -- Missing reference section? 'RFC2402' on line 306 looks like a reference -- Missing reference section? 'RFC2406' on line 309 looks like a reference -- Missing reference section? 'RFC-2119' on line 59 looks like a reference -- Missing reference section? 'RFC2407' on line 312 looks like a reference -- Missing reference section? 'TBD' on line 191 looks like a reference -- Missing reference section? 'Bel96' on line 299 looks like a reference -- Missing reference section? 'RFC2408' on line 315 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. M. Bellovin 2 Internet Draft J. Ioannidis 3 draft-ietf-ipsec-sctp-05.txt AT&T Labs - Research 4 A. D. Keromytis 5 Columbia University 6 R. R. Stewart 7 Cisco 9 On the Use of SCTP with IPsec 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes functional requirements for IPsec [RFC2401] 31 and IKE [RFC2409] to facilitate their use in securing SCTP 32 [RFC2960] traffic. 34 1. Introduction 36 The Stream Control Transmission Protocol (SCTP) is a reliable 37 transport protocol operating on top of a connection-less packet 38 network such as IP. SCTP is designed to transport PSTN signaling 39 messages over IP networks, but is capable of broader applications. 41 When SCTP is used over IP networks, it may utilize the IP security 42 protocol suite [RFC2402][RFC2406] for integrity and 43 confidentiality. To dynamically establish IPsec Security 44 Associations (SAs), a key negotiation protocol such as IKE 45 [RFC2409] may be used. 47 This document describes functional requirements for IPsec and IKE 48 to facilitate their use in securing SCTP traffic. In particular, we 49 discuss additional support in the form of a new ID type in IKE 50 [RFC2409] and implementation choices in the IPsec processing to 51 accommodate for the multiplicity of source and destination addresses 52 associated with a single SCTP association. 54 1.1. Terminology 56 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 57 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 58 described in [RFC-2119]. 60 2. SCTP over IPsec 62 When utilizing the Authentication Header [RFC2402] or Encapsulating 63 Security Payload [RFC2406] protocols to provide security services 64 for SCTP frames, the SCTP frame is treated as just another transport 65 layer protocol on top of IP (same as TCP, UDP, etc.) 67 IPsec implementations should already be able to use the SCTP 68 transport protocol number as assigned by IANA as a selector in 69 their Security Policy Database (SPD). It should be straightforward 70 extend existing implementations to use the SCTP source and 71 destination port numbers as selectors in the SPD. Since the 72 concept of a port, and its location in the transport header is 73 protocol-specific, the IPsec code responsible for identifying the 74 transport protocol ports has to be suitable modified. This, 75 however is not enough to fully support the use of SCTP in 76 conjunction with IPsec. 78 Since SCTP can negotiate sets of source and destination addresses 79 (not necessarily in the same subnet or address range) that may be 80 used in the context of a single association, the SPD should be able 81 to accommodate this. The straightforward, and expensive, way is to 82 create one SPD entry for each pair of source/destination addresses 83 negotiated. A better approach is to associate sets of addresses 84 with the source and destination selectors in each SPD entry (in the 85 case of non-SCTP traffic, these sets would contain only one 86 element). While this is an implementation decision, implementors 87 are encouraged to follow this or a similar approach when designing or 88 modifying the SPD to accommodate SCTP-specific selectors. 90 Similarly, SAs may have multiple associated source and destination 91 addresses. Thus an SA is identified by the extended triplet ({set 92 of destination addresses}, SPI, Security Protocol). A lookup in 93 the Security Association Database (SADB) using the triplet 94 (Destination Address, SPI, Security Protocol), where Destination 95 Address is any of the negotiated peer addresses, MUST return the 96 same SA. 98 When operating in tunnel mode, the question of what to use as the 99 tunnel destination address (for the `outer' header) arises. We 100 distinguish three cases: where the end hosts are also the tunnel 101 endpoints; where neither host is a tunnel endpoint (the tunnel 102 endpoints are security gateways); and where only one of the hosts is 103 a tunnel endpoint (the usual case for the `road warrior' talking to 104 a security gateway). In the first case, the outer addresses MUST be 105 the same as the inner addresses of the tunnel. In the second case 106 (security gateways) there is no special processing; address 107 selection proceeds as it would for two distinct sets of end hosts. 108 In the third case, the `road warrior' uses the security gateway's 109 address as the tunnel destination address, and MUST use the same 110 source address as that of the inner packet. Symmetrically, the 111 security gateway uses its own address as the source address of the 112 tunnel, and MUST use the the same destination address in the outer 113 header as that of the inner packet. An implementation will probably 114 structure the code so that if, during SA setup, the inner and outer 115 address of either side is the same, rather than explicitly store the 116 corresponding address of the tunnel, it sets a flag that marks the SA 117 to use the same address in the tunnel header as in the inner header. 119 3. SCTP and IKE 121 There are two issues relevant to the use of IKE when negotiating 122 protection for SCTP traffic: 124 a) Since SCTP allows for multiple source and destination network 125 addresses associated with an SCTP association, it MUST be possible 126 for IKE to efficiently negotiate these in the Phase 2 (Quick Mode) 127 exchange. The straightforward approach is to negotiate one pair of 128 IPsec SAs for each combination of source and destination addresses. 129 This can result in an unnecessarily large number of SAs, thus 130 wasting time (in negotiating these) and memory. All current 131 implementations of IKE support this functionality. However, a 132 method for specifying multiple selectors in Phase 2 is desirable 133 for efficiency purposes. Compliance with this document requires 134 that implementations adhere to the guidelines in the rest of this 135 section. 137 Define a new type of ID, ID_LIST, that allows for recursive 138 inclusion of IDs. Thus, the IKE Phase 2 Initiator ID for an SCTP 139 association MAY be of type ID_LIST, which would in turn contain as 140 many ID_IPV4_ADDR IDs as necessary to describe Initiator addresses; 141 likewise for Responder IDs. Note that other selector types MAY be 142 used when establishing SAs for use with SCTP, if there is no need 143 to use negotiate multiple addresses for each SCTP endpoint (i.e., 144 if only one address is used by each peer of an SCTP flow). 145 Implementations MUST support this new ID type. 147 ID_LIST IDs cannot appear inside ID_LIST ID payloads. Any of the 148 ID types defined in [RFC2407] can be included inside an ID_LIST ID. 149 Each of the IDs contained in the ID_LIST ID must include a complete 150 Identification Payload header. 152 The following diagram illustrates the content of an ID_LIST ID 153 payload that contains two ID_FQDN payloads. 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 ! Next Payload ! RESERVED ! Payload Length ! 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 ! ID Type ! Protocol ID ! Port ! 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 ! Next Payload ! RESERVED ! Payload Length ! 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 ! ID Type ! Protocol ID ! Port ! 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 ~ FQDN 1 Identification Data ~ 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 ! Next Payload ! RESERVED ! Payload Length ! 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 ! ID Type ! Protocol ID ! Port ! 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 ~ FQDN 2 Identification Data ~ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 The Next Payload field in any of the included IDs (for FQDN 1 and 175 FQDN 2) MUST be ignored by the Responder. The Payload Length, ID 176 Type, Protocol ID, and Port fields of the included Payloads should 177 be set to the appropriate values. The Protocol ID and Port fields 178 of the ID_LIST Payload should be set to zero by the Initiator and 179 ignored by the Responder. 181 Different types of IDs (e.g., an ID_FQDN and an ID_IPV4_ADDR) can 182 be included inside the same ID_LIST ID. If an ID type included in 183 an ID_LIST ID payload is invalid in the context the ID_LIST ID is 184 used, the whole ID_LIST should be considered to be at fault, e.g., 185 if an ID_LIST ID payload that contains an ID_FQDN and an 186 ID_IPV4_ADDR is received during an IKE Quick Mode exchange, the 187 Responder should signal a fault to the Initiator and stop 188 processing of the message (the same behavior it would exhibit if 189 simply an ID_FQDN was received instead). 191 The IANA-assigned number for the ID_LIST ID is [TBD]. 193 b) For IKE to be able to validate the Phase 2 selectors, it must be 194 possible to exchange sufficient information during Phase 1. 195 Currently, IKE can directly accommodate the simple case of two 196 machines talking to each other, by using Phase 1 IDs corresponding 197 to their IP addresses, and encoding those same addresses in the 198 SubjAltName of the certificates used to authenticate the Phase 1 199 exchange. For more complicated scenarios, external policy (or some 200 other mechanism) needs to be consulted, to validate the Phase 2 201 selectors and SA parameters. All addresses presented in Phase 2 202 selectors MUST be validated. That is, enough evidence must be 203 presented to the Responder that the Initiator is authorized to 204 receive traffic for all addresses that appear in the Phase 2 205 selectors. This evidence can be derived from the certificates 206 exchanged during Phase 1 (if possible); otherwise it must be 207 acquired through out-of-band means (e.g., policy mechanism, 208 configured by the administrator, etc.). 210 In order to accommodate the same simple scenario in the context of 211 multiple source/destination addresses in an SCTP association, it 212 MUST be possible to: 214 1) Specify multiple Phase 1 IDs, which are used to validate 215 Phase 2 parameters (in particular, the Phase 2 selectors). 216 Following the discussion on an ID_LIST ID type, it is 217 possible to use the same method for specifying multiple Phase 218 1 IDs. 220 2) Authenticate the various Phase 1 IDs. Using pre-shared key 221 authentication, this is possible by associating the same 222 shared key with all acceptable peer Phase 1 IDs. In the case 223 of certificates, we have two alternatives: 225 a) The same certificate can contain multiple IDs encoded 226 in the SubjAltName field, as an ASN.1 sequence. Since 227 this is already possible, it is the preferred solution and 228 any compliant implementations MUST support this. 230 b) Multiple certificates MAY be passed during the Phase 1 231 exchange, in multiple CERT payloads. This feature is also 232 supported by the current specification. Since only one 233 signature may be issued per IKE Phase 1 exchange, it is 234 necessary for all certificates to contain the same key as 235 their Subject. However, this approach does not offer any 236 significant advantage over (a), thus implementations MAY 237 support it. 239 In either case, an IKE implementation needs to verify the 240 validity of a peer's claimed Phase 1 ID, for all such IDs 241 received over an exchange. 243 Although SCTP does not currently support modification of the 244 addresses associated with an SCTP association (while the latter is 245 in use), it is a feature that may be supported in the future. 246 Unless the set of addresses changes extremely often, it is 247 sufficient to do a full Phase 1 and Phase 2 exchange to establish 248 the appropriate selectors and SAs. 250 The last issue with respect to SCTP and IKE pertains to the initial 251 offer of Phase 2 selectors (IDs) by the Initiator. Per the current 252 IKE specification, the Responder must send in the second message of 253 the Quick Mode the IDs received in the first message. Thus, it is 254 assumed that the Initiator already knows all the Selectors relevant 255 to this SCTP association. In most cases however, the Responder has 256 more accurate knowledge of its various addresses. Thus, the IPsec 257 Selectors established can be potentially insufficient or 258 inaccurate. 260 If the proposed set of Selectors is not accurate from the 261 Responder's point of view, the latter can start a new Quick Mode 262 exchange. In this new Quick Mode exchange, the roles of Initiator 263 and Responder have been reversed; the new Initiator MUST copy the 264 SA and Selectors from the old Quick Mode message, and modify its 265 set of Selectors to match reality. All SCTP-supporting IKE 266 implementations MUST be able to do this. 268 4. Security Considerations 270 This documents discusses the use of a security protocol (IPsec) in 271 the context of a new transport protocol (SCTP). SCTP, with its 272 provision for mobility, opens up the possibility for 273 traffic-redirection attacks whereby an attacker X claims that his 274 address should be added to an SCTP session between peers A and B, 275 and be used for further communications. In this manner, traffic 276 between A and B can be seen by X. If X is not in the communication 277 path between A and B, SCTP offers him new attack capabilities. 278 Thus, all such address updates of SCTP sessions should be 279 authenticated. Since IKE negotiates IPsec SAs for use by these 280 sessions, IKE MUST validate all addresses attached to an SCTP 281 endpoint either through validating the certificates presented to it 282 during the Phase 1 exchange, or through some out-of-band method. 284 The Responder in a Phase 2 exchange MUST verify the Initiator's 285 authority to receive traffic for all addresses that appear in the 286 Initiator's Phase 2 selectors. Not doing so would allow for any 287 valid peer of the Responder (i.e., anyone who can successfully 288 establish a Phase 1 SA with the Responder) to see any other valid 289 peer's traffic by claiming their address. 291 5. IANA Considerations 293 IANA must assign a number for ID_LIST (defined in Section 3) in the 294 "IPSEC Identification Type" registry from the Internet Security 295 Association and Key Management Protocol (ISAKMP) Identifiers table. 297 References: 299 [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security 300 Protocols", Proceedings of the Sixth Usenix Unix Security 301 Symposium, July, 1996. 303 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 304 Internet Protocol", RFC 2401, November 1998. 306 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 307 2402, November 1998. 309 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 310 Payload (ESP)", RFC 2406, November 1998. 312 [RFC2407] D. Piper, "The Internet IP Security Domain of 313 Interpretation for ISAKMPD", RFC 2407, November 1998. 315 [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, 316 "Internet Security Association and Key Management 317 Protocol", RFC 2408, November 1998. 319 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 320 (IKE)", RFC 2409, November 1998. 322 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 323 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 324 Zhang, L. and V. Paxson, "Stream Control Transmission 325 Protocol", RFC 2960, October 2000. 327 Authors' addresses: 329 Steven M. Bellovin 330 AT&T Labs - Research 331 180 Park Avenue 332 Florham Park, New Jersey 07932-0971 334 Email: smb@research.att.com 336 John Ioannidis 337 AT&T Labs - Research 338 180 Park Avenue 339 Florham Park, New Jersey 07932-0971 341 Email: ji@research.att.com 343 Angelos D. Keromytis 344 Columbia University, CS Department 345 515 CS Building 346 1214 Amsterdam Avenue, Mailstop 0401 347 New York, New York 10027-7003 349 Phone: +1 212 939 7095 350 Email: angelos@cs.columbia.edu 352 Randall R. Stewart 353 24 Burning Bush Trail. 354 Crystal Lake, IL 60012 356 Phone: +1-815-477-2127 357 Email: rrs@cisco.com 359 Expiration and File Name 361 This draft expires in October 2003 363 Its file name is draft-ietf-ipsec-sctp-05.txt