idnits 2.17.1 draft-petithuguenin-vipr-sip-antispam-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 11, 2012) is 4488 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) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-02 ** Downref: Normative reference to an Informational draft: draft-jennings-vipr-overview (ref. 'VIPR-OVERVIEW') == Outdated reference: A later version (-02) exists of draft-jennings-vipr-vap-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VIPR M. Petit-Huguenin 3 Internet-Draft Stonyfish 4 Intended status: Standards Track J. Rosenberg 5 Expires: July 14, 2012 jdrosen.net 6 C. Jennings 7 Cisco 8 January 11, 2012 10 Session Initiation Protocol (SIP) Extensions for Blocking VoIP Spam 11 Using PSTN Validation 12 draft-petithuguenin-vipr-sip-antispam-03 14 Abstract 16 Verification Involving PSTN Reachability (ViPR) is a new technique 17 for inter-domain federation of SIP calls. ViPR makes use of the PSTN 18 as an introduction mechanism to verify the correctness of mappings 19 from phone numbers to domains. The PSTN introduction mechanism can 20 also be used as a technique for blocking spam - a SIP caller is only 21 authorized when its calling domain has previously called that same 22 number over the PSTN. This document describes an extension to SIP 23 which enables authorization of SIP calls based on a prior PSTN 24 introduction. 26 Legal 28 This documents and the information contained therein are provided on 29 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 30 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 31 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 32 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 33 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 34 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 35 FOR A PARTICULAR PURPOSE. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 14, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Terminating Side Procedures . . . . . . . . . . . . . . . . . . 5 74 4. Originating Side Procedures . . . . . . . . . . . . . . . . . . 6 75 5. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 78 7.1. IANA Registration of ViPR-Ticket Header Field . . . . . . . 7 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 83 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 9 84 A.1. Modifications between vipr-03 and vipr-02 . . . . . . . . . 9 85 A.2. Modifications between vipr-02 and vipr-01 . . . . . . . . . 9 86 A.3. Modifications between vipr-01 and vipr-00 . . . . . . . . . 9 87 A.4. Modifications between vipr-00 and dispatch-03 . . . . . . . 9 88 A.5. Modifications between dispatch-03 and dispatch-02 . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 The anti-spam tickets described in this specification are the key 94 security mechanism in ViPR for mitigation of SPAM. The domain 95 originating a call inserts a ticket in the SIP INVITE sent to the 96 other domain. The Border Element in the domain receiving the call 97 (see Figure 1) can check the ticket to ensure that this originating 98 domain has been authorized by the terminating domain. This document 99 relies heavily on the concepts and terminology defined in 100 [VIPR-OVERVIEW] and will not make sense if you have not read that 101 document first. 103 +-+ +-+ 104 | | | | +------+ 105 | | +-----| |---|Enroll| 106 | | | | | +------+ 107 |I| | |I| 108 |n| +-----+ |n| 109 VAP |t| | ViPR| |t| 110 +----------|r|---|Srvr |--|e|----------------- 111 | |a| | | |r| P2P-Validation 112 | |n| +-----+ |n| 113 | |e| |e| 114 | |t| |t| 115 +-----+ SIP | | +-----+ | | 116 | CA |-------|F|---| |--|F| --------------- 117 +-----+ |i| | | |i| SIP/TLS 118 . |r| | . | |r| 119 SIP/ . |e| | | |e| 120 MGCP/ . |w| | BE | |w| 121 TDM . |a| | | |a| 122 . |l| | | |l| 123 +-----+ |l| | | |l| 124 | UA |-------| |---| |--| |----------------- 125 +-----+ | | +-----+ | | SRTP 126 | | | | 127 +-+ +-+ 128 | | 129 +--------------------+-----------------+ 130 | 131 Single administrative domain 133 Figure 1: Architecture 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Terminating Side Procedures 143 The Border Element will receive the TLS ClientHello which begins the 144 TLS handshake. The Border Element will present its own configured 145 cert. Once TLS handshaking is complete, the Border Element notes the 146 domain from the SubjectAltName on the other side of the TLS 147 connection, and associates it with that connection. 149 Next, the Border Element will receive an INVITE. This INVITE will 150 contain a ticket in the ViPR-Ticket header field value. The Border 151 Element extracts this header field. This call flow assumes it is 152 present. The Border Element parses it, and obtains the epoch value 153 encoded in the ticket. This is matched against the current epoch 154 value for the configured password. If they match, processing 155 continues. The Border Element verifies the signature is correct. 156 Next, it examines the start and stop time of the validity. If the 157 current time is between the start and stop times, the check is 158 passed. Next, the Border Element checks the granted-to domain in the 159 ticket. It compares that domain against the domain name in the 160 SubjectAltName of the peer on the other side of the TLS connection, 161 as noted above. Next, it takes the Request-URI of the SIP INVITE. 162 That will be of the form sip:+number@domain. If it is not in that 163 form, and if the number does not begin with a plus, the request is 164 dropped. The value, including the plus, is then compared to the 165 number in the ticket. If it is equal, the check has passed. The 166 Border Element leaves the header field in the request, but forwards 167 to the Call Agent. 169 In addition, the Border Element will typically be configured to apply 170 its SIP message validation logic, and enforce restrictions on the 171 sizes of various SIP header fields. This provides an additional 172 layer of security in case malicious SIP messages are sent. 174 The Border Element will also apply port forwarding in the case of 175 NAT, so that the incoming request is forwarded to the appropriate 176 Call Agent node. 178 The Call Agent will receive incoming SIP INVITEs. The Request-URI of 179 the INVITE will contain an E.164 number as indicated by a leading 180 plus. If the Request-URI is not an E.164, the request must be 181 rejected with a 403. Only E.164 numbers can be accepted on a ViPR 182 trunk. 184 4. Originating Side Procedures 186 The routes stored to other domains in the Call Agent will each store 187 a ticket to utilize with calls to that route. The Call Agent learns 188 about these routes and the information needed to construct the ticket 189 from the VAP protocol [VIPR-VAP]. When sending a SIP request to one 190 of these domains, the Call Agent MUST include the ticket in any 191 dialog forming request or request that is not in an existing dialog. 193 5. Tickets 195 This ticket is a sequence of characters. These MUST be placed into a 196 ViPR-Ticket SIP header field value. Consequently the format for this 197 header field is: 198 Ticket = "ViPR-Ticket" HCOLON ticket-val 199 ticket-val = 1*(alphanum / "-" / "_" / ".") 201 This header field MUST be utilized in all dialog forming requests and 202 all out-of-dialog requests. It is not utilized in responses. The 203 ticket-value is a modified base64 encoded version of an object that 204 is composed of a series of TLVs. Each TLV is a 16 bit type, a 16 bit 205 length, and a variable length value. The length field refers to the 206 length of the value portion of the TLV, measured in bytes. The 207 following TLV types are defined: 209 1. Ticket Unique ID: This TLV has a type of 0x0001. It contains a 210 128 bit ID that has a unique identifier for this ticket. The 211 value MUST contain a 128 bit UUID defined by [RFC4122]. This TLV 212 MUST be present. However at this time it is used for diagnostic 213 purposes only. 214 2. Salt: This TLV has a type of 0x0002. It contains a value which 215 MUST be at least 32 bits, and contains a random number. Its 216 presence ensures that each ticket contains sufficient randomness. 217 This TLV MUST be present. 218 3. Validity: This TLV has a type of 0x0003. It contains two 64 bit 219 NTP times. The first is the start of the validity of the ticket, 220 the next is the end time for the validity of the ticket. This 221 TLV MUST be present. 222 4. Number: This TLV has a type of 0x0004. It contains a string 223 which has an E.164 number, included the "+", which may be called 224 using this ticket. The TLV has variable length. This TLV MUST 225 be present. 227 5. Granting Node: This TLV has a type of 0x0005. It contains a 128 228 bit value which is the Node-ID of the node which granted the 229 ticket. This TLV MUST be present. 230 6. Granting Domain: This TLV has a type of 0x0006. The domain 231 which granted the ticket. A string, up to 256 characters, each 232 of which must be a valid domain name character. The TLV has 233 variable length. This TLV MUST be present. 234 7. Granted-To Domain: This TLV has a type of 0x0007. The domain to 235 which the ticket is granted. A string, up to 256 characters, 236 each of which must be a valid domain name character. The TLV has 237 a variable length. This TLV MUST be present. 238 8. Epoch: This TLV has a type of 0x0008. It contains a 32 bit 239 epoch value. It is used to select a key. This TLV MUST be 240 present. 241 9. Integrity: This TLV has a type of 0x0009. It contains a 160 bit 242 integrity value, computed using HMAC-SHA1. This TLV MUST be 243 present and MUST be the last TLV in the object. 245 The base64 encoding uses the base64url encoding from RFC4648 246 [RFC4648], with the exception of the pad character, which is a "." 247 instead of an "=". This ensures that the output is a valid SIP 248 token. 250 To compute the MAC, the following is done. First, the key is 251 obtained. The key is actually a 128 bit key, configured into the 252 system. The key, P, is then used to compute Km: 254 Km = HMAC-SHA1(P, S | Epoch) 256 Based on PBKDF2 from PKCS #5 [RFC2898] with HMAC-SHA1 as PRF and 257 iteration count of 1. Where S is the 32 bit salt and Epoch is the 32 258 bit Epoch, from the ticket. This produces a 160 bit Km. The MAC is 259 then computed as another HMAC-SHA1, over the entire ticket up to but 260 not including the Integrity itself, using Km as the key. This 261 produces the 160 bit MAC. 263 6. Security Considerations 265 TBD 267 7. IANA Considerations 269 7.1. IANA Registration of ViPR-Ticket Header Field 271 This document defines a new SIP header field: ViPR-Ticket. Its 272 syntax is defined in Section 5. This header field must be registered 273 by IANA in the SIP Parameters registry under the Header Fields 274 subregistry with the following information: 276 Header Name: ViPR-Ticket 277 Compact Form: none 279 8. Acknowledgements 281 Thanks to Patrice Bruno for his comments, suggestions and questions 282 that helped to improve this document. 284 9. References 286 9.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 292 Specification Version 2.0", RFC 2898, September 2000. 294 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 295 Unique IDentifier (UUID) URN Namespace", RFC 4122, 296 July 2005. 298 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 299 Encodings", RFC 4648, October 2006. 301 [VIPR-OVERVIEW] 302 Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 303 Huguenin, "Verification Involving PSTN Reachability: 304 Requirements and Architecture Overview", 305 draft-jennings-vipr-overview-02 (work in progress), 306 September 2011. 308 9.2. Informative References 310 [VIPR-VAP] 311 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 312 "Verification Involving PSTN Reachability: The ViPR Access 313 Protocol (VAP)", draft-jennings-vipr-vap-01 (work in 314 progress), July 2011. 316 Appendix A. Release notes 318 This section must be removed before publication as an RFC. 320 A.1. Modifications between vipr-03 and vipr-02 322 o Keep the document alive. 324 A.2. Modifications between vipr-02 and vipr-01 326 o Renamed Ticket to ViPR-Ticket to synchronize with -overview. 328 A.3. Modifications between vipr-01 and vipr-00 330 o Renamed X-Cisco-ViPR-Ticket to Ticket and filled the IANA section. 332 A.4. Modifications between vipr-00 and dispatch-03 334 o Moved to new Working Group. 336 A.5. Modifications between dispatch-03 and dispatch-02 338 o Added terminology section. 339 o Nits 340 o Shorter I-Ds references. 341 o Changed issued-to to granted-to. 342 o Fixed the ABNF. 343 o The tickets is used in all dialog forming requests, not only 344 INVITE. 345 o The Number TLV has a variable length. 346 o The Integrity TLV MUST be the last in the object. 347 o Fixed a discrepancy in the epoch length. 349 Authors' Addresses 351 Marc Petit-Huguenin 352 Stonyfish 354 Email: petithug@acm.org 355 Jonathan Rosenberg 356 jdrosen.net 357 Monmouth, NJ 358 US 360 Email: jdrosen@jdrosen.net 361 URI: http://www.jdrosen.net 363 Cullen Jennings 364 Cisco 365 170 West Tasman Drive 366 MS: SJC-21/2 367 San Jose, CA 95134 368 USA 370 Phone: +1 408 421-9990 371 Email: fluffy@cisco.com