idnits 2.17.1 draft-ietf-sigtran-security-03.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 29, 2003) is 7601 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) == Unused Reference: '2' is defined on line 466, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 495, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 510, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 518, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '4') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '5') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. '6') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '7') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '8') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '9') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3057 (ref. '10') (Obsoleted by RFC 4233) -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. '11') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3309 (ref. '12') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3332 (ref. '14') (Obsoleted by RFC 4666) == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-m2pa-08 -- Unexpected draft version: The latest known version of draft-ietf-ipsec-sctp is -05, but you're referring to -06. Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Loughney 3 Internet-Draft Nokia Research Center 4 Expires: December 28, 2003 M. Tuexen, Ed. 5 Univ. of Applied Sciences Muenster 6 J. Pastor-Balbas 7 Ericsson 8 June 29, 2003 10 Security Considerations for SIGTRAN Protocols 11 draft-ietf-sigtran-security-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 28, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This documents discusses how TLS and IPsec can be used to secure the 42 communication for SIGTRAN protocols. The support of IPsec is 43 mandatory for all nodes running SIGTRAN protocols and the support of 44 TLS is optional. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Security in telephony networks . . . . . . . . . . . . . . . 4 53 4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 5 54 5. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Support of IPsec and TLS . . . . . . . . . . . . . . . . . . 9 57 8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 9 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 63 12.2 Informative References . . . . . . . . . . . . . . . . . . . 11 64 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 65 Intellectual Property and Copyright Statements . . . . . . . 14 67 1. Introduction 69 1.1 Overview 71 The SIGTRAN protocols are designed to carry signaling messages for 72 telephony services. These protocols will be used between 74 o customer premise and service provider equipment in case of IUA 76 o service provider equipment only. This is the case for M2UA, M2PA, 77 M3UA and SUA. The carriers may be different and may use other 78 transport network providers. 80 The security requirements for these situations may be different. 82 SIGTRAN protocols involve the security needs of several parties: the 83 end-users of the services; the service providers and the applications 84 involved. Additional security requirements may come from local 85 regulation. While having some overlapping security needs, any 86 security solution should fulfill all of the different parties' needs. 88 The SIGTRAN protocols assume that messages are secured by using 89 either IPsec or TLS. 91 1.2 Abbreviations 93 This document uses the following abbreviations: 95 ASP: Application Server Process. 97 CA: Certification Authority. 99 DOI: Domain Of Interpretation. 101 ESP: Encapsulating Security Payload. 103 FQDN: Full-Qualified Domain Names. 105 IPsec: IP Security Protocol. 107 IKE: Internet Key Exchange Protocol. 109 ISDN: Integrated Services Digital Network. 111 IUA: ISDN Q.921 User Adaptation Layer. 113 M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer. 115 M2UA: SS7 MTP2 User Adaptation Layer. 117 M3UA: SS7 MTP3 User Adaptation Layer. 119 PKI: Public Key Infrastructure. 121 SA: Security Association. 123 SCTP: Stream Control Transmission Protocol. 125 SS7: Signaling System No. 7. 127 SUA: SS7 SCCP User Adaptation Layer. 129 TLS: Transport Layer Security. 131 2. Convention 133 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 134 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 135 they appear in this document, are to be interpreted as described in 136 [1]. 138 3. Security in telephony networks 140 The security in telephony networks is mainly based on the closed 141 network principle. There are two main protocols used: Access 142 protocols (ISDN and others) are used for signaling in the access 143 network and the SS7 protocol stack in the core network. 145 As SS7 networks are often physically remote and/or inaccessible to 146 the user, it is assumed that they are protected from malicious users. 147 Often, equipment is under lock and key. At network boundaries 148 between SS7 networks, packet filtering is sometimes used. End-users 149 are not directly connected to SS7 networks. 151 The access protocols are used for end-user signaling. End-user 152 signaling protocols are translated to SS7 based protocols by 153 telephone switches run by network operators. 155 Often Regulatory Authorities require SS7 switches with connections to 156 different SS7 to be conformant to national and/or international test 157 specifications. 159 There are no standardized ways of using encryption technologies for 160 providing confidentiality or using technologies for authentication. 162 This description applies to telephony networks operated by a single 163 operator but also to multiple telephony networks being connected and 164 operated by different operators. 166 4. Threats and Goals 168 The Internet threats can be divided into one of two main types. The 169 first one is called "passive attacks". It happens whenever the 170 attacker reads packets off the network but does not write them. 171 Examples of such attacks include confidentiality violations, password 172 sniffing and offline cryptographic attacks amongst others. 174 The second kind of threads is called "active attacks". In this case 175 the attacker also writes data to the network. Examples for this 176 attack include replay attacks, message insertion, message deletion, 177 message modification or man-in-the-middle attacks amongst others. 179 In general, Internet protocols have the following security 180 objectives: 182 o Communication Security: 184 * Authentication of peers. 186 * Integrity of user data transport. 188 * Confidentiality of user data. 190 * Replay protection. 192 o Non-repudiation. 194 o System Security, avoidance of: 196 * Unauthorized use. 198 * Inappropiate use. 200 * Denial of Service. 202 Communication security is mandatory in some network scenarios to 203 prevent malicious attacks. The main goal of this document is to 204 recommend the minimum security means that a SIGTRAN node must 205 implement in order to achieve a secured communication. To get this 206 goal, we will explore the different security options that regarding 207 communication exist. 209 All SIGTRAN protocols use the Stream Control Transmission Protocol 210 (SCTP) being defined in [9] and [12] as its transport protocol. SCTP 211 provides certain transport related security features, such as 212 resistance against: 214 o Blind Denial of Service Attacks such as: 216 * Flooding. 218 * Masquerade. 220 * Improper Monopolization of Services. 222 There is no quick fix, one-size-fits-all solution for security. 224 When the network in which SIGTRAN protocols are used involves more 225 than one party, it may not be reasonable to expect that all parties 226 have implemented security in a sufficient manner. End-to-end security 227 should be the goal; therefore, it is recommended that IPsec or TLS is 228 used to ensure confidentiality of user payload. Consult [4] for more 229 information on configuring IPsec services. 231 5. IPsec Usage 233 This section is relevant only for SIGTRAN nodes using IPsec to secure 234 communication between SIGTRAN nodes. 236 All SIGTRAN nodes using IPsec MUST implement IPsec ESP [5] in 237 transport mode with non-null encryption and authentication algorithms 238 to provide per-packet authentication, integrity protection and 239 confidentiality, and MUST implement the replay protection mechanisms 240 of IPsec. In those scenarios where IP layer protection is needed, ESP 241 in tunnel mode SHOULD be used. Non-null encryption should be used 242 when using IPSec ESP. 244 All SIGTRAN nodes MUST support IKE for peer authentication, 245 negotiation of security associations, and key management, using the 246 IPsec DOI [6]. The IPsec implementations MUST support peer 247 authentication using a pre-shared key, and MAY support 248 certificate-based peer authentication using digital signatures. Peer 249 authentication using the public key encryption methods outlined in 250 IKE's sections 5.2 and 5.3 [7] SHOULD NOT be used. 252 Conformant implementations MUST support both IKE Main Mode and 253 Aggressive Mode. For transport mode, when pre-shared keys are used 254 for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main 255 Mode SHOULD NOT be used. When digital signatures are used for 256 authentication, either IKE Main Mode or IKE Aggressive Mode MAY be 257 used. When using ESP tunnel mode, IKE Main Mode MAY be used to create 258 ISAKMP association with identity protection during Phase 1. 260 When digital signatures are used to achieve authentication, an IKE 261 negotiator SHOULD use IKE Certificate Request Payload(s) to specify 262 the certification authority (or authorities) that are trusted in 263 accordance with its local policy. IKE negotiators SHOULD use 264 pertinent certificate revocation checks before accepting a PKI 265 certificate for use in IKE's authentication procedures. See [11] for 266 certificate revocation and [8] for online-checking. 268 The Phase 2 Quick Mode exchanges used to negotiate protection for 269 SIGTRAN sessions MUST explicitly carry the Identity Payload fields 270 (IDci and IDcr). The DOI provides for several types of identification 271 data. However, when used in conformant implementations, each ID 272 Payload MUST carry a single IP address and a single non-zero port 273 number, and MUST NOT use the IP Subnet or IP Address Range formats. 274 This allows the Phase 2 security association to correspond to 275 specific TCP and SCTP connections. 277 Since IPsec acceleration hardware may only be able to handle a 278 limited number of active IKE Phase 2 SAs, Phase 2 delete messages may 279 be sent for idle SAs, as a means of keeping the number of active 280 Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete 281 message SHOULD NOT be interpreted as a reason for tearing down a 282 SIGTRAN session. Rather, it is preferable to leave the connection up, 283 and if additional traffic is sent on it, to bring up another IKE 284 Phase 2 SA to protect it. This avoids the potential for continually 285 bringing connections up and down. 287 It should be noted that SCTP supports multi-homed hosts and this 288 results in the need for having multiple security associations for one 289 SCTP association. This disadvantage of IPsec has been addressed by 290 [17]. So IPsec implementations used by SIGTRAN nodes SHOULD support 291 the IPsec feature described in [17]. 293 6. TLS Usage 295 This section is relevant only for SIGTRAN nodes using TLS to secure 296 the communication between SIGTRAN nodes. 298 A SIGTRAN node that initiates a SCTP association to another SIGTRAN 299 node acts as a TLS client according to [3], and a SIGTRAN node that 300 accepts a connection acts as a TLS server. SIGTRAN peers implementing 301 TLS for security MUST mutually authenticate as part of TLS session 302 establishment. In order to ensure mutual authentication, the SIGTRAN 303 node acting as TLS server must request a certificate from the SIGTRAN 304 node acting as TLS client, and the SIGTRAN node acting as TLS client 305 MUST be prepared to supply a certificate on request. 307 [15] requires the support of the cipher suite 308 TLS_RSA_WITH_AES_128_CBC_SHA. SIGTRAN nodes MAY negotiate other TLS 309 cipher suites. 311 TLS MUST be used on all bi-directional streams and the other 312 uni-directional streams MUST NOT be used. 314 It should also be noted that a SCTP implementation used for TLS over 315 SCTP MUST support fragmentation of user data and might also need to 316 support the partial delivery API. This holds even if all SIGTRAN 317 messages are small. Furthermore, the 'unordered delivery' feature of 318 SCTP can not be used in conjunction with TLS. See [15] for more 319 details. 321 Because TLS only protects the payload the SCTP header and all control 322 chunks are not protected. This can be used for DoS attacks. This is a 323 general problem with security provided at the transport layer. 325 The SIGTRAN protocols use the same SCTP port number and payload 326 protocol identifier when run over TLS. A session upgrade procedure 327 has to be used to initiate the TLS based communication. 329 The session upgrade procedure should be as follows: 331 o If an ASP has been configured to use TLS it sends a STARTTLS 332 message on stream 0 and starts a timer T_TLS. This is the first 333 message send and the ASP sends no other adaptation layer messages 334 until the TLS based communication has been established. 336 o If the peer does not support TLS it sends back an ERROR message 337 indicating an unsupported message type. In this case the SCTP 338 association is terminated and it is reported to the management 339 layer that the peer does not support TLS. 341 o If the peer does support TLS it sends back an STARTTLS_ACK 342 message. The client then starts TLS based communication. 344 o If T_TLS expires without getting any of the above answers the 345 association is terminated and the failure is reported to the 346 management layer. 348 All SIGTRAN adaptation layers share a common message format. The 349 STARTTLS message consists of a common header only using the message 350 class 10 and message type 1. The STARTTLS_ACK message uses the same 351 message class 10 and the message type 2. Both messages do not contain 352 any parameters. 354 Using this procedure it is possible for a man-in-the-middle to do a 355 denial of service attack by indicating that the peer does not support 356 TLS. But this kind of attack is always possible for a 357 man-in-the-middle. 359 7. Support of IPsec and TLS 361 If content of SIGTRAN protocol messages is to be protected, either 362 IPsec ESP or TLS can be used. In both IPsec ESP Transport Mode and 363 TLS cases the IP header information is neither encrypted nor 364 protected. If IPsec ESP is chosen the SCTP control information is 365 encrypted and protected whereas if the TLS based solution the SCTP 366 control information is not encrypted and only protected by SCTP 367 procedures. 369 In general, both IPsec and TLS have enough mechanisms to secure the 370 SIGTRAN communications. 372 Therefore, in order to have a secured model working as soon as 373 possible, the following recommendation is made: A SIGTRAN node MUST 374 support IPsec and MAY support TLS. 376 8. Peer-to-Peer Considerations 378 M2PA, M3UA and SUA support the peer-to-peer model as a generalization 379 to the client-server model which is supported by IUA and M2UA. A 380 SIGTRAN node running M2PA, M3UA or SUA and operating in the 381 peer-to-peer mode is called a SIGTRAN peer. 383 As with any peer-to-peer protocol, proper configuration of the trust 384 model within a peer is essential to security. When certificates are 385 used, it is necessary to configure the trust anchors trusted by the 386 peer. These trust anchors are likely to be unique to SIGTRAN usage 387 and distinct from the trust anchors that might be trusted for other 388 purposes such as Web browsing. In general, it is expected that those 389 trust anchors will be configured so as to reflect the business 390 relationships between the organization hosting the peer and other 391 organizations. As a result, a peer will typically not be configured 392 to allow connectivity with any arbitrary peer. When certificate 393 authentication peers may not be known beforehand, and therefore peer 394 discovery may be required. 396 Note that IPsec is considerably less flexible than TLS when it comes 397 to configuring trust anchors. Since use of Port identifiers is 398 prohibited within IKE Phase 1, within IPsec it is not possible to 399 uniquely configure trusted trust anchors for each application 400 individually; the same policy must be used for all applications. This 401 implies, for example, that a trust anchor trusted for use with a 402 SIGTRAN protocol must also be trusted to protect other protocols (for 403 example SNMP). These restrictions can be awkward at best. 405 When pre-shared key authentication is used with IPsec to protect 406 SIGTRAN based communication, unique pre-shared keys are configured 407 with peers, who are identified by their IP address (Main Mode), or 408 possibly their FQDN (AggressivenMode). As a result, it is necessary 409 for the set of peers to be known beforehand. Therefore, peer 410 discovery is typically not necessary. 412 The following is intended to provide some guidance on the issue. 414 It is recommended that SIGTRAN peers use the same security mechanism 415 (IPsec or TLS) across all its sessions with other SIGTRAN peers. 416 Inconsistent use of security mechanisms can result in redundant 417 security mechanisms being used (e.g. TLS over IPsec) or worse, 418 potential security vulnerabilities. When IPsec is used with a SIGTRAN 419 protocol, a typical security policy for outbound traffic is "Initiate 420 IPsec, from me to any, destination port P"; for inbound traffic, the 421 policy would be "Require IPsec, from any to me, destination port P". 422 Here P denotes one of the registered port numbers for a SIGTRAN 423 protocol. 425 This policy causes IPsec to be used whenever a SIGTRAN peer initiates 426 a session to another SIGTRAN peer, and to be required whenever an 427 inbound SIGTRAN session occurs. This policy is attractive, since it 428 does not require policy to be set for each peer or dynamically 429 modified each time a new SIGTRAN session is created; an IPsec SA is 430 automatically created based on a simple static policy. Since IPsec 431 extensions are typically not available to the sockets API on most 432 platforms, and IPsec policy functionality is implementation 433 dependent, use of a simple static policy is the often the simplest 434 route to IPsec-enabling a SIGTRAN peer. 436 If IPsec is used to secure SIGTRAN peer-to-peer session, IPsec policy 437 SHOULD be set so as to require IPsec protection for inbound 438 connections, and to initiate IPsec protection for outbound 439 connections. This can be accomplished via use of inbound and outbound 440 filter policy. 442 9. Security Considerations 444 This documents discusses the usage of IPsec and TLS for securing 445 SIGTRAN traffic. 447 10. IANA Considerations 449 The message class 10 has to be reserved for STARTTLS messages for all 450 SIGTRAN adaptation layers. For this message class, message type 1 has 451 to be reserved for the STARTTLS message, message type 2 for the 452 STARTTLS_ACK message. 454 11. Acknowledgements 456 The authors would like to thank B. Aboba, K. Morneault and many 457 others for their invaluable comments and suggestions. 459 12. References 461 12.1 Normative References 463 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 464 Levels", BCP 14, RFC 2119, March 1997. 466 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 467 9, RFC 2026, October 1996. 469 12.2 Informative References 471 [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 472 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 473 1999. 475 [4] Kent, S. and R. Atkinson, "Security Architecture for the 476 Internet Protocol", RFC 2401, November 1998. 478 [5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 479 (ESP)", RFC 2406, November 1998. 481 [6] Piper, D., "The Internet IP Security Domain of Interpretation 482 for ISAKMP", RFC 2407, November 1998. 484 [7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 485 RFC 2409, November 1998. 487 [8] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, 488 "X.509 Internet Public Key Infrastructure Online Certificate 489 Status Protocol - OCSP", RFC 2560, June 1999. 491 [9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 492 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 493 "Stream Control Transmission Protocol", RFC 2960, October 2000. 495 [10] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, 496 "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001. 498 [11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 499 Public Key Infrastructure Certificate and Certificate 500 Revocation List (CRL) Profile", RFC 3280, April 2002. 502 [12] Stone, J., Stewart, R. and D. Otis, "Stream Control 503 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 504 September 2002. 506 [13] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. 507 Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) 508 - User Adaptation Layer", RFC 3331, September 2002. 510 [14] Sidebottom, G., Morneault, K. and J. Pastor-Balbas, "Signaling 511 System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation 512 Layer (M3UA)", RFC 3332, September 2002. 514 [15] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 515 Security over Stream Control Transmission Protocol", RFC 3436, 516 December 2002. 518 [16] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", 519 draft-ietf-sigtran-m2pa-08 (work in progress), April 2003. 521 [17] Bellovin, S., "On the Use of SCTP with IPsec", 522 draft-ietf-ipsec-sctp-06 (work in progress), April 2003. 524 13. Authors' Addresses 526 John Loughney 527 Nokia Research Center 528 PO Box 407 529 FIN-00045 Nokia Group 530 Finland 532 EMail: john.loughney@nokia.com 534 Michael Tuexen 535 Univ. of Applied Sciences Muenster 536 Stegerwaldstr. 39 537 48565 Steinfurt 538 Germany 540 EMail: tuexen@fh-muenster.de 541 Javier Pastor-Balbas 542 Ericsson 543 Via de los Poblados, 13 544 28033 Madrid 545 Spain 547 EMail: j.javier.pastor@ericsson.com 549 Intellectual Property Statement 551 The IETF takes no position regarding the validity or scope of any 552 intellectual property or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; neither does it represent that it 556 has made any effort to identify any such rights. Information on the 557 IETF's procedures with respect to rights in standards-track and 558 standards-related documentation can be found in BCP-11. Copies of 559 claims of rights made available for publication and any assurances of 560 licenses to be made available, or the result of an attempt made to 561 obtain a general license or permission for the use of such 562 proprietary rights by implementors or users of this specification can 563 be obtained from the IETF Secretariat. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights which may cover technology that may be required to practice 568 this standard. Please address the information to the IETF Executive 569 Director. 571 Full Copyright Statement 573 Copyright (C) The Internet Society (2003). All Rights Reserved. 575 This document and translations of it may be copied and furnished to 576 others, and derivative works that comment on or otherwise explain it 577 or assist in its implementation may be prepared, copied, published 578 and distributed, in whole or in part, without restriction of any 579 kind, provided that the above copyright notice and this paragraph are 580 included on all such copies and derivative works. However, this 581 document itself may not be modified in any way, such as by removing 582 the copyright notice or references to the Internet Society or other 583 Internet organizations, except as needed for the purpose of 584 developing Internet standards in which case the procedures for 585 copyrights defined in the Internet Standards process must be 586 followed, or as required to translate it into languages other than 587 English. 589 The limited permissions granted above are perpetual and will not be 590 revoked by the Internet Society or its successors or assignees. 592 This document and the information contained herein is provided on an 593 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 594 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 595 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 596 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 597 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 599 Acknowledgment 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.