| |
| |
| |
| |
| |
| |
| Network Working Group S. Bellovin |
| Request for Comments: 3554 J. Ioannidis |
| Category: Standards Track AT&T Labs - Research |
| A. Keromytis |
| Columbia University |
| R. Stewart |
| Cisco |
| July 2003 |
| |
| |
| On the Use of Stream Control Transmission Protocol (SCTP) with IPsec |
| |
| Status of this Memo |
| |
| This document specifies an Internet standards track protocol for the |
| Internet community, and requests discussion and suggestions for |
| improvements. Please refer to the current edition of the "Internet |
| Official Protocol Standards" (STD 1) for the standardization state |
| and status of this protocol. Distribution of this memo is unlimited. |
| |
| Copyright Notice |
| |
| Copyright (C) The Internet Society (2003). All Rights Reserved. |
| |
| Abstract |
| |
| This document describes functional requirements for IPsec (RFC 2401) |
| and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in |
| securing SCTP (RFC 2960) traffic. |
| |
| 1. Introduction |
| |
| The Stream Control Transmission Protocol (SCTP) is a reliable |
| transport protocol operating on top of a connection-less packet |
| network such as IP. SCTP is designed to transport PSTN signaling |
| messages over IP networks, but is capable of broader applications. |
| |
| When SCTP is used over IP networks, it may utilize the IP security |
| protocol suite [RFC2402][RFC2406] for integrity and confidentiality. |
| To dynamically establish IPsec Security Associations (SAs), a key |
| negotiation protocol such as IKE [RFC2409] may be used. |
| |
| This document describes functional requirements for IPsec and IKE to |
| facilitate their use in securing SCTP traffic. In particular, we |
| discuss additional support in the form of a new ID type in IKE |
| [RFC2409] and implementation choices in the IPsec processing to |
| accommodate for the multiplicity of source and destination addresses |
| associated with a single SCTP association. |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 1] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| 1.1. Terminology |
| |
| In this document, the key words "MAY", "MUST, "MUST NOT", "optional", |
| "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as |
| described in [RFC-2119]. |
| |
| 2. SCTP over IPsec |
| |
| When utilizing the Authentication Header [RFC2402] or Encapsulating |
| Security Payload [RFC2406] protocols to provide security services for |
| SCTP frames, the SCTP frame is treated as just another transport |
| layer protocol on top of IP (same as TCP, UDP, etc.) |
| |
| IPsec implementations should already be able to use the SCTP |
| transport protocol number as assigned by IANA as a selector in their |
| Security Policy Database (SPD). It should be straightforward to |
| extend existing implementations to use the SCTP source and |
| destination port numbers as selectors in the SPD. Since the concept |
| of a port, and its location in the transport header is |
| protocol-specific, the IPsec code responsible for identifying the |
| transport protocol ports has to be suitably modified. This, however |
| is not enough to fully support the use of SCTP in conjunction with |
| IPsec. |
| |
| Since SCTP can negotiate sets of source and destination addresses |
| (not necessarily in the same subnet or address range) that may be |
| used in the context of a single association, the SPD should be able |
| to accommodate this. The straightforward, and expensive, way is to |
| create one SPD entry for each pair of source/destination addresses |
| negotiated. A better approach is to associate sets of addresses with |
| the source and destination selectors in each SPD entry (in the case |
| of non-SCTP traffic, these sets would contain only one element). |
| While this is an implementation decision, implementors are encouraged |
| to follow this or a similar approach when designing or modifying the |
| SPD to accommodate SCTP-specific selectors. |
| |
| Similarly, SAs may have multiple associated source and destination |
| addresses. Thus an SA is identified by the extended triplet ({set of |
| destination addresses}, SPI, Security Protocol). A lookup in the |
| Security Association Database (SADB) using the triplet (Destination |
| Address, SPI, Security Protocol), where Destination Address is any of |
| the negotiated peer addresses, MUST return the same SA. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 2] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| 3. SCTP and IKE |
| |
| There are two issues relevant to the use of IKE when negotiating |
| protection for SCTP traffic: |
| |
| a) Since SCTP allows for multiple source and destination network |
| addresses associated with an SCTP association, it MUST be possible |
| for IKE to efficiently negotiate these in the Phase 2 (Quick Mode) |
| exchange. The straightforward approach is to negotiate one pair of |
| IPsec SAs for each combination of source and destination addresses. |
| This can result in an unnecessarily large number of SAs, thus wasting |
| time (in negotiating these) and memory. All current implementations |
| of IKE support this functionality. However, a method for specifying |
| multiple selectors in Phase 2 is desirable for efficiency purposes. |
| Conformance with this document requires that implementations adhere |
| to the guidelines in the rest of this section. |
| |
| Define a new type of ID, ID_LIST, that allows for recursive inclusion |
| of IDs. Thus, the IKE Phase 2 Initiator ID for an SCTP association |
| MAY be of type ID_LIST, which would in turn contain as many |
| ID_IPV4_ADDR IDs as necessary to describe Initiator addresses; |
| likewise for Responder IDs. Note that other selector types MAY be |
| used when establishing SAs for use with SCTP, if there is no need to |
| use negotiate multiple addresses for each SCTP endpoint (i.e., if |
| only one address is used by each peer of an SCTP flow). |
| Implementations MUST support this new ID type. |
| |
| ID_LIST IDs cannot appear inside ID_LIST ID payloads. Any of the ID |
| types defined in [RFC2407] can be included inside an ID_LIST ID. |
| Each of the IDs contained in the ID_LIST ID must include a complete |
| Identification Payload header. |
| |
| The following diagram illustrates the content of an ID_LIST ID |
| payload that contains two ID_FQDN payloads. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 3] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ! Next Payload ! RESERVED ! Payload Length ! |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ! ID Type ! Protocol ID ! Port ! |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ! Next Payload ! RESERVED ! Payload Length ! |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ! ID Type ! Protocol ID ! Port ! |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ FQDN 1 Identification Data ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ! Next Payload ! RESERVED ! Payload Length ! |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ! ID Type ! Protocol ID ! Port ! |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ FQDN 2 Identification Data ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| The Next Payload field in any of the included IDs (for FQDN 1 and |
| FQDN 2) MUST be ignored by the Responder. The Payload Length, ID |
| Type, Protocol ID, and Port fields of the included Payloads should be |
| set to the appropriate values. The Protocol ID and Port fields of |
| the ID_LIST Payload should be set to zero by the Initiator and MUST |
| be ignored by the Responder. |
| |
| Different types of IDs (e.g., an ID_FQDN and an ID_IPV4_ADDR) can be |
| included inside the same ID_LIST ID. If an ID type included in an |
| ID_LIST ID payload is invalid in the context the ID_LIST ID is used, |
| the whole ID_LIST should be considered to be at fault, e.g., if an |
| ID_LIST ID payload that contains an ID_FQDN and an ID_IPV4_ADDR is |
| received during an IKE Quick Mode exchange, the Responder should |
| signal a fault to the Initiator and stop processing of the message |
| (the same behavior it would exhibit if simply an ID_FQDN was received |
| instead). |
| |
| The IANA-assigned number for the ID_LIST ID is 12. |
| |
| b) For IKE to be able to validate the Phase 2 selectors, it must be |
| possible to exchange sufficient information during Phase 1. |
| Currently, IKE can directly accommodate the simple case of two peers |
| talking to each other, by using Phase 1 IDs corresponding to their IP |
| addresses, and encoding those same addresses in the SubjAltName of |
| the certificates used to authenticate the Phase 1 exchange. For more |
| complicated scenarios, external policy (or some other mechanism) |
| needs to be consulted, to validate the Phase 2 selectors and SA |
| parameters. All addresses presented in Phase 2 selectors MUST be |
| validated. That is, enough evidence must be presented to the |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 4] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| Responder that the Initiator is authorized to receive traffic for all |
| addresses that appear in the Phase 2 selectors. This evidence can be |
| derived from the certificates exchanged during Phase 1 (if possible); |
| otherwise it must be acquired through out-of-band means (e.g., policy |
| mechanism, configured by the administrator, etc.). |
| |
| In order to accommodate the same simple scenario in the context of |
| multiple source/destination addresses in an SCTP association, it MUST |
| be possible to: |
| |
| 1) Specify multiple Phase 1 IDs, which are used to validate Phase |
| 2 parameters (in particular, the Phase 2 selectors). Following |
| the discussion on an ID_LIST ID type, it is possible to use the |
| same method for specifying multiple Phase 1 IDs. |
| |
| 2) Authenticate the various Phase 1 IDs. Using pre-shared key |
| authentication, this is possible by associating the same shared |
| key with all acceptable peer Phase 1 IDs. In the case of |
| certificates, we have two alternatives: |
| |
| a) The same certificate can contain multiple IDs encoded in |
| the SubjAltName field, as an ASN.1 sequence. Since this is |
| already possible, it is the preferred solution and any |
| conformant implementations MUST support this. |
| |
| b) Multiple certificates MAY be passed during the Phase 1 |
| exchange, in multiple CERT payloads. This feature is also |
| supported by the current specification. Since only one |
| signature may be issued per IKE Phase 1 exchange, it is |
| necessary for all certificates to contain the same key as |
| their Subject. However, this approach does not offer any |
| significant advantage over (a), thus implementations MAY |
| support it. |
| |
| In either case, an IKE implementation needs to verify the |
| validity of a peer's claimed Phase 1 ID, for all such IDs |
| received over an exchange. |
| |
| Although SCTP does not currently support modification of the |
| addresses associated with an SCTP association (while the latter is in |
| use), it is a feature that may be supported in the future. Unless |
| the set of addresses changes extremely often, it is sufficient to do |
| a full Phase 1 and Phase 2 exchange to establish the appropriate |
| selectors and SAs. |
| |
| |
| |
| |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 5] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| The last issue with respect to SCTP and IKE pertains to the initial |
| offer of Phase 2 selectors (IDs) by the Initiator. Per the current |
| IKE specification, the Responder must send in the second message of |
| the Quick Mode the IDs received in the first message. Thus, it is |
| assumed that the Initiator already knows all the Selectors relevant |
| to this SCTP association. In most cases however, the Responder has |
| more accurate knowledge of its various addresses. Thus, the IPsec |
| Selectors established can be potentially insufficient or inaccurate. |
| |
| If the proposed set of Selectors is not accurate from the Responder's |
| point of view, the latter can start a new Quick Mode exchange. In |
| this new Quick Mode exchange, the roles of Initiator and Responder |
| have been reversed; the new Initiator MUST copy the SA and Selectors |
| from the old Quick Mode message, and modify its set of Selectors to |
| match reality. All SCTP-supporting IKE implementations MUST be able |
| to do this. |
| |
| 4. Security Considerations |
| |
| This documents discusses the use of a security protocol (IPsec) in |
| the context of a new transport protocol (SCTP). SCTP, with its |
| provision for mobility, opens up the possibility for |
| traffic-redirection attacks whereby an attacker X claims that his |
| address should be added to an SCTP session between peers A and B, and |
| be used for further communications. In this manner, traffic between |
| A and B can be seen by X. If X is not in the communication path |
| between A and B, SCTP offers him new attack capabilities. Thus, all |
| such address updates of SCTP sessions should be authenticated. Since |
| IKE negotiates IPsec SAs for use by these sessions, IKE MUST validate |
| all addresses attached to an SCTP endpoint either through validating |
| the certificates presented to it during the Phase 1 exchange, or |
| through some out-of-band method. |
| |
| The Responder in a Phase 2 exchange MUST verify the Initiator's |
| authority to receive traffic for all addresses that appear in the |
| Initiator's Phase 2 selectors. Not doing so would allow for any |
| valid peer of the Responder (i.e., anyone who can successfully |
| establish a Phase 1 SA with the Responder) to see any other valid |
| peer's traffic by claiming their address. |
| |
| 5. IANA Considerations |
| |
| IANA has assigned number 12 for ID_LIST (defined in Section 3) in the |
| "IPSEC Identification Type" registry from the Internet Security |
| Association and Key Management Protocol (ISAKMP) Identifiers table. |
| |
| |
| |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 6] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| 6. Intellectual Property Rights Notice |
| |
| The IETF takes no position regarding the validity or scope of any |
| intellectual property or other rights that might be claimed to |
| pertain to the implementation or use of the technology described in |
| this document or the extent to which any license under such rights |
| might or might not be available; neither does it represent that it |
| has made any effort to identify any such rights. Information on the |
| IETF's procedures with respect to rights in standards-track and |
| standards-related documentation can be found in BCP-11. Copies of |
| claims of rights made available for publication and any assurances of |
| licenses to be made available, or the result of an attempt made to |
| obtain a general license or permission for the use of such |
| proprietary rights by implementors or users of this specification can |
| be obtained from the IETF Secretariat. |
| |
| The IETF invites any interested party to bring to its attention any |
| copyrights, patents or patent applications, or other proprietary |
| rights which may cover technology that may be required to practice |
| this standard. Please address the information to the IETF Executive |
| Director. |
| |
| Normative References |
| |
| [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the |
| Internet Protocol", RFC 2401, November 1998. |
| |
| [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC |
| 2402, November 1998. |
| |
| [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security |
| Payload (ESP)", RFC 2406, November 1998. |
| |
| [RFC2407] Piper, D., "The Internet IP Security Domain of |
| Interpretation for ISAKMPD", RFC 2407, November 1998. |
| |
| [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, |
| "Internet Security Association and Key Management |
| Protocol", RFC 2408, November 1998. |
| |
| [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange |
| (IKE)", RFC 2409, November 1998. |
| |
| [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., |
| Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., |
| Zhang, L. and V. Paxson, "Stream Control Transmission |
| Protocol", RFC 2960, October 2000. |
| |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 7] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| Authors' Addresses |
| |
| Steven M. Bellovin |
| AT&T Labs - Research |
| 180 Park Avenue |
| Florham Park, New Jersey 07932-0971 |
| |
| Phone: +1 973 360 8656 |
| EMail: smb@research.att.com |
| |
| |
| John Ioannidis |
| AT&T Labs - Research |
| 180 Park Avenue |
| Florham Park, New Jersey 07932-0971 |
| |
| EMail: ji@research.att.com |
| |
| |
| Angelos D. Keromytis |
| Columbia University, CS Department |
| 515 CS Building |
| 1214 Amsterdam Avenue, Mailstop 0401 |
| New York, New York 10027-7003 |
| |
| Phone: +1 212 939 7095 |
| EMail: angelos@cs.columbia.edu |
| |
| |
| Randall R. Stewart |
| 24 Burning Bush Trail. |
| Crystal Lake, IL 60012 |
| |
| Phone: +1-815-477-2127 |
| EMail: rrs@cisco.com |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 8] |
| |
| RFC 3554 SCTP with IPsec July 2003 |
| |
| |
| Full Copyright Statement |
| |
| Copyright (C) The Internet Society (2003). All Rights Reserved. |
| |
| This document and translations of it may be copied and furnished to |
| others, and derivative works that comment on or otherwise explain it |
| or assist in its implementation may be prepared, copied, published |
| and distributed, in whole or in part, without restriction of any |
| kind, provided that the above copyright notice and this paragraph are |
| included on all such copies and derivative works. However, this |
| document itself may not be modified in any way, such as by removing |
| the copyright notice or references to the Internet Society or other |
| Internet organizations, except as needed for the purpose of |
| developing Internet standards in which case the procedures for |
| copyrights defined in the Internet Standards process must be |
| followed, or as required to translate it into languages other than |
| English. |
| |
| The limited permissions granted above are perpetual and will not be |
| revoked by the Internet Society or its successors or assignees. |
| |
| This document and the information contained herein is provided on an |
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| |
| Acknowledgement |
| |
| Funding for the RFC Editor function is currently provided by the |
| Internet Society. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Bellovin, et. al. Standards Track [Page 9] |
| |