idnits 2.17.1 draft-uusitalo-sipping-delegation-00.txt: ** The Abstract section seems to be numbered 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 == It seems as if not all pages are separated by form feeds - found 1 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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.) ** There are 89 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 106: '...eq 1. A SIP node MUST be able to send ...' RFC 2119 keyword, line 115: '... >> Req 2: It SHOULD be possible to...' RFC 2119 keyword, line 123: '...nsport mechanism MUST protect transfer...' RFC 2119 keyword, line 132: '...nsport mechanism MUST not depend on th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: >> Req 4. The key transport mechanism MUST not depend on the security of any underlying layers. -- 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 (February 2002) is 8077 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) -- Missing reference section? '5' on line 145 looks like a reference -- Missing reference section? '2' on line 142 looks like a reference -- Missing reference section? '6' on line 175 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 INTERNET-DRAFT V. Torvinen 4 draft-uusitalo-sipping-delegation-00.txt I. Uusitalo 5 Expires: August 2002 Ericsson 6 February 2002 8 Requirements for Delegation of Message Protection for SIP 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 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/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 1. Abstract 34 The Session Initiation Protocol (SIP) is an application-layer 35 control (signaling) protocol for creating, modifying and terminating 36 sessions with one or more participants. These sessions include 37 Internet telephone calls, multimedia distribution and multimedia 38 conferences. SIP has a number of security mechanisms used for hop- 39 by-hop or end-to-end message protection. The SIP node handling 40 authentication and initial message protection may decide, for 41 efficiency reasons, to delegate subsequent message protection to 42 another SIP node. In this document we discuss requirements 43 concerning the delegation of message protection for SIP. 45 SIP DELEGATION REQUIREMENTS February 2002 47 2. Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in 51 this document are to be interpreted as described in RFC 2119. 53 3. Table of contents 55 1. Abstract........................................................1 56 2. Conventions used in this document...............................2 57 3. Table of contents...............................................2 58 4. Introduction and Motivation.....................................2 59 5. Requirements....................................................2 60 6. Discussion......................................................3 61 7. Acknowledgments.................................................4 62 8. References......................................................4 63 9. Author's Address................................................5 65 4. Introduction and Motivation 67 A SIP node that shares a security context with a user may decide to 68 delegate, according to a policy, further message protection after 69 the initial authentication to another SIP node. This might be 70 necessary due to e.g. re-allocation of clients for capacity reasons, 71 or in order to avoid additional authentication in a multi-hop 72 situation (e.g. via TLS and PKI for the first hop). 74 An essential part of delegating message protection is the 75 transportation of keys used for message protection. Since the 76 security of a system relies on the secrecy of the keys, care has to 77 be taken to ensure that the keys are transported in a secure manner. 78 For example, it is not recommended to specify a key transport 79 mechanism that relies on underlying security because the application 80 using the keys might not be aware of the security. It is also not 81 recommended to make bundled key transport features into 82 authentication mechanisms without confidentiality protection. 84 It may also be possible to use Kerberos [5] in SIP in the future. 85 Even though Kerberos tickets are safe as such, the same delegation 86 and key transport features as proposed in this document may be 87 needed. This document assumes that keying material and tickets 88 require the same mechanisms from SIP. 90 This document is an effort to define requirements applicable for 91 delegation of message protection with SIP protocol. Most of these 92 requirements are listed also in "3GPP Requirements on SIP" [2], but 93 we consider them to be beneficial also to infrastructures other than 94 3GPP. Therefore they've been separated into this new draft that's 95 easier to deal with. 97 5. Requirements 99 SIP DELEGATION REQUIREMENTS February 2002 101 A SIP node may decide, according to a policy, to delegate further 102 message protection after the initial authentication to another SIP 103 node. For example, the SIP node delegating further message 104 protection might be a registrar. 106 >> Req 1. A SIP node MUST be able to send keying material (or 107 tickets) to another SIP node. 109 Performing authentication on all SIP signaling messages would likely 110 create bottlenecks in the authentication infrastructure. Therefore, 111 a distributed implementation of security functions responsible for 112 authentication may be required in some SIP implementations (e.g. 113 3GPP). 115 >> Req 2: It SHOULD be possible to perform an initial authentication 116 based on long-term authentication credentials, followed by 117 subsequent protected signaling that uses short-term authentication 118 credentials. 120 Secret keys and tickets are of importance to a security of a system 121 and compromising them would be harmful. 123 >> Req 3. The key transport mechanism MUST protect transferred keys 124 (or tickets) in a secure manner. 126 SIP can be transported over different underlying protocols, some of 127 which offer security while some don't. The application using the 128 keys is not necessarily aware of lower layer security deployment. 129 Therefore it is not recommended to specify a key transport mechanism 130 that relies on the security of the underlying layers. 132 >> Req 4. The key transport mechanism MUST not depend on the 133 security of any underlying layers. 135 6. Discussion 137 Currently, SIP does not have secure way to transport keying material 138 or tickets between the SIP nodes. SIP does not include a mechanism 139 for delegation of security tasks either. SIP body (e.g. SDP) can be 140 used to carry keying material to protect subsequent multimedia 141 sessions. It has also been proposed that SIP could be used to carry 142 keys to protect SIP [2]. Similar requirements may be found if other 143 similar security credentials, such as tickets or tokens, are 144 utilized in SIP in the future. For example, the transport of 145 Kerberos tickets [5] between SIP nodes may be required. Even though 146 tickets may be secured by some other means, the same transport and 147 delegation features as proposed in this document may be needed. 149 The key transport should be specified as an individual function, 150 with its specific headers or bodies used for transporting the keys 151 in SIP. 153 SIP DELEGATION REQUIREMENTS February 2002 155 The reliance to lower-layer security schemes in the transport of the 156 keys is also problematic. Due to the importance of the session keys 157 for the security of the system, the applications should be aware of 158 where they are receiving keys. While some SIP implementations may be 159 able to trust on the underlying network security, a standardized key 160 transport mechanism is likely to find other users as well, and needs 161 to prepare for different network cases. For example, a separate 162 gateway solution is unlikely to provide application layer 163 information about the source of the keys - it can at most guarantee 164 that the keys came from one of the sources trusted by the gateway. 165 In a multi-hop situation, even information provided from an 166 underlying security mechanism may not be very helpful. Therefore, 167 the recommendation is that an application layer mechanism is used to 168 protect key transport. One such mechanism is S/MIME, though also 169 other possibilities such as XML Digital Signatures exist. 171 Delegation of security tasks should be somehow integrated as a part 172 of key transport. In practice, there should be some way to 173 communicate the purpose for which the transported keys are used. 175 HTTP authentication framework [6] includes functionality similar to 176 the delegation requirement. HTTP server may be responsible for 177 authenticating data that is situated in another server. This basic 178 delegation mechanism is achieved by using the "opaque" parameter 179 together with sequential 401 unauthorized and 301/302 redirection 180 error messages. The servers do not exchange key material, however 181 the delegating server is able to send delegation-related data to the 182 delegated server in the "opaque" parameter. 184 7. Acknowledgments 186 We would like to thank Allison Mankin, Dean Willis, Rohan Mahy, 187 Bernard Aboba, Miguel Garcia, as well as numerous people at 3GPP SA3 188 and Ericsson for interesting discussions in this problem space. 190 8. References 192 1. Rosenberg, J., et al., "SIP:Session Initiation Protocol", 193 draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in 194 progress. 196 2. Garcia, M., et al., "3GPP requirements on SIP", draft-garcia- 197 sipping-3gpp-regs-02.txt, November 2001, work in progress. 199 3. 3GPP TS 23.228: "IP Multimedia (IM) Subsystem (Stage 2) - 200 Release 5". Version 5.3.0 is available at 201 ftp://ftp.3gpp.org/Specs/2001-12/Rel-5/23_series/23228-530.zip 203 4. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call 204 control based on SIP and SDP". Version 1.9.0 is available at 205 ftp://ftp.3gpp.org/Specs/Latest-drafts/24288-190.zip 207 SIP DELEGATION REQUIREMENTS February 2002 209 5. Kohl, J., Neuman, C., " The Kerberos Network Authentication 210 Service (V5)", RCF 1510, September 1993. 212 6. Franks, J., et al., "HTTP Authentication: Basic and Digest 213 Access Authentication", RFC 2617, June 1999. 215 9. Authors' Addresses 217 Jari Arkko 218 Oy LM Ericsson Ab 219 02420 Jorvas 220 Finland 222 Phone: +358 40 5079256 223 EMail: jari.arkko@ericsson.com 225 Vesa Torvinen 226 Oy LM Ericsson Ab 227 Joukahaisenkatu 1 228 20520 Turku 229 Finland 231 Phone: +358 40 7230822 232 EMail: vesa.torvinen@ericsson.fi 234 Ilkka Uusitalo 235 Oy LM Ericsson Ab 236 Tutkijantie 2C 237 90570 Oulu 238 Finland 240 Phone: +358 40 7245404 241 EMail: ilkka.uusitalo@ericsson.fi 243 Full Copyright Statement 245 Copyright (C) The Internet Society (2002). All Rights Reserved. 247 This document and translations of it may be copied and furnished to 248 others, and derivative works that comment on or otherwise explain it 249 or assist in its implementation may be prepared, copied, published 250 and distributed, in whole or in part, without restriction of any 251 kind, provided that the above copyright notice and this paragraph 252 are 253 included on all such copies and derivative works. However, this 254 document itself may not be modified in any way, such as by removing 256 SIP DELEGATION REQUIREMENTS February 2002 258 the copyright notice or references to the Internet Society or other 259 Internet organizations, except as needed for the purpose of 260 developing Internet standards in which case the procedures for 261 copyrights defined in the Internet Standards process must be 262 followed, or as required to translate it into languages other than 263 English. 265 The limited permissions granted above are perpetual and will not be 266 revoked by the Internet Society or its successors or assigns. 268 This document and the information contained herein is provided on an 269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 275 SIP DELEGATION REQUIREMENTS February 2002