idnits 2.17.1 draft-ietf-sipcore-sec-flows-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 23, 2009) is 5262 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '0' is mentioned on line 1127, but not defined ** Obsolete normative reference: RFC 5246 (ref. '5') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 3546 (ref. '6') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 3268 (ref. '7') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3851 (ref. '8') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3852 (ref. '9') (Obsoleted by RFC 5652) ** Downref: Normative reference to an Informational RFC: RFC 4475 (ref. '12') == Outdated reference: A later version (-08) exists of draft-ietf-sip-eku-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-sip-eku (ref. '13') -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '16') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '17') (Obsoleted by RFC 9110) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track K. Ono 5 Expires: May 27, 2010 Columbia University 6 R. Sparks 7 B. Hibbard, Ed. 8 Tekelec 9 November 23, 2009 11 Example call flows using Session Initiation Protocol (SIP) security 12 mechanisms 13 draft-ietf-sipcore-sec-flows-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on May 27, 2010. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document shows example call flows demonstrating the use of 61 Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail 62 Extensions (S/MIME) in Session Initiation Protocol (SIP). It also 63 provides information that helps implementers build interoperable SIP 64 software. To help facilitate interoperability testing, it includes 65 certificates used in the example call flows and processes to create 66 certificates for testing. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 74 3.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 9 75 3.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 76 4. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 77 4.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 78 4.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 14 79 5. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 80 5.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 15 81 5.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 20 82 5.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 23 83 6. Observed Interoperability Issues . . . . . . . . . . . . . . . 28 84 7. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 30 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 88 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 92 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35 93 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36 94 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39 95 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42 96 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42 97 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49 98 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 58 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 101 1. Introduction 103 This document is informational and is not normative on any aspect of 104 SIP. 106 SIP with TLS (RFC 5246 [5]) implementations are becoming very common. 107 Several implementations of the S/MIME (RFC 3851 [8]) portion of SIP 108 (RFC 3261 [2]) are also becoming available. After several 109 interoperability events, it is clear that it is difficult to write 110 these systems without any test vectors or examples of "known good" 111 messages to test against. Furthermore, testing at the events is 112 often hampered by trying to get certificates signed by some common 113 test root into the appropriate format for various clients. This 114 document addresses both of these issues by providing messages that 115 give detailed examples that implementers can use for comparison and 116 that can also be used for testing. In addition, this document 117 provides a common certificate and private key that can be used for a 118 Certificate Authority (CA) to reduce the time it takes to set up a 119 test at an interoperability event. The document also provides some 120 hints and clarifications for implementers. 122 A simple SIP call flow using SIPS URIs and TLS is shown in Section 4. 123 The certificates for the hosts used are shown in Section 3.2, and the 124 CA certificates used to sign these are shown in Section 3.1. 126 The text from Section 5.1 through Section 5.3 shows some simple SIP 127 call flows using S/MIME to sign and encrypt the body of the message. 128 The user certificates used in these examples are shown in 129 Section 3.3. These host certificates are signed with the same CA 130 certificate. 132 Section 6 presents a partial list of things implementers should 133 consider in order to implement systems that will interoperate. 135 A way to make certificates that can be used for interoperability 136 testing is presented in Appendix A, along with methods for converting 137 these to various formats. The certificates used while creating the 138 examples and test messages in this document are made available in 139 Appendix B. 141 Binary copies of various messages in this draft that can be used for 142 testing appear in Appendix C. 144 2. Conventions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [1]. 150 OPEN ISSUE: If there's no intent to have normative language, this 151 section and reference to RFC 2119 should be removed. 153 3. Certificates 155 3.1. CA Certificates 157 The certificate used by the CA to sign the other certificates is 158 shown below. This is a X509v3 certificate. Note that the X.509v3 159 Basic Constraints in the certificate allows it to be used as a CA, 160 certificate authority. This certificate is not used directly in the 161 TLS call flow; it is used only to verify user and host certificates. 163 Version: 3 (0x2) 164 Serial Number: 0 (0x0) 165 Signature Algorithm: sha1WithRSAEncryption 166 Issuer: C=US, ST=California, L=San Jose, O=sipit, 167 OU=Sipit Test Certificate Authority 168 Validity 169 Not Before: Jul 18 12:21:52 2003 GMT 170 Not After : Jul 15 12:21:52 2013 GMT 171 Subject: C=US, ST=California, L=San Jose, O=sipit, 172 OU=Sipit Test Certificate Authority 173 Subject Public Key Info: 174 Public Key Algorithm: rsaEncryption 175 RSA Public Key: (1024 bit) 176 Modulus (1024 bit): 177 00:c3:22:1e:83:91:c5:03:2c:3c:8a:f4:11:14:c6: 178 4b:9d:fa:72:78:c6:b0:95:18:a7:e0:8c:79:ba:5d: 179 a4:ae:1e:21:2d:9d:f1:0b:1c:cf:bd:5b:29:b3:90: 180 13:73:66:92:6e:df:4c:b3:b3:1c:1f:2a:82:0a:ba: 181 07:4d:52:b0:f8:37:7b:e2:0a:27:30:70:dd:f9:2e: 182 03:ff:2a:76:cd:df:87:1a:bd:71:eb:e1:99:6a:c4: 183 7f:8e:74:a0:77:85:04:e9:41:ad:fc:03:b6:17:75: 184 aa:33:ea:0a:16:d9:fb:79:32:2e:f8:cf:4d:c6:34: 185 a3:ff:1b:d0:68:28:e1:9d:e5 186 Exponent: 65537 (0x10001) 187 X509v3 extensions: 188 X509v3 Subject Key Identifier: 189 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 190 X509v3 Authority Key Identifier: 191 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 192 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 193 OU=Sipit Test Certificate Authority 194 serial:00 196 X509v3 Basic Constraints: 197 CA:TRUE 198 Signature Algorithm: sha1WithRSAEncryption 199 96:6d:1b:ef:d5:91:93:45:7c:5b:1f:cf:c4:aa:47:52:0b:34: 200 a8:50:fa:ec:fa:b4:2a:47:4c:5d:41:a7:3d:c0:d6:3f:9e:56: 201 5b:91:1d:ce:a8:07:b3:1b:a4:9f:9a:49:6f:7f:e0:ce:83:94: 202 71:42:af:fe:63:a2:34:dc:b4:5e:a5:ce:ca:79:50:e9:6a:99: 203 4c:14:69:e9:7c:ab:22:6c:44:cc:8a:9c:33:6b:23:50:42:05: 204 1f:e1:c2:81:88:5f:ba:e5:47:bb:85:9b:83:25:ad:84:32:ff: 205 2a:5b:8b:70:12:11:83:61:c9:69:15:4f:58:a3:3c:92:d4:e8: 206 6f:52 208 The ASN.1 parse of the CA certificate is shown below. 210 0:l= 804 cons: SEQUENCE 211 4:l= 653 cons: SEQUENCE 212 8:l= 3 cons: cont [ 0 ] 213 10:l= 1 prim: INTEGER :02 214 13:l= 1 prim: INTEGER :00 215 16:l= 13 cons: SEQUENCE 216 18:l= 9 prim: OBJECT :sha1WithRSAEncryption 217 29:l= 0 prim: NULL 218 31:l= 112 cons: SEQUENCE 219 33:l= 11 cons: SET 220 35:l= 9 cons: SEQUENCE 221 37:l= 3 prim: OBJECT :countryName 222 42:l= 2 prim: PRINTABLESTRING :US 223 46:l= 19 cons: SET 224 48:l= 17 cons: SEQUENCE 225 50:l= 3 prim: OBJECT :stateOrProvinceName 226 55:l= 10 prim: PRINTABLESTRING :California 227 67:l= 17 cons: SET 228 69:l= 15 cons: SEQUENCE 229 71:l= 3 prim: OBJECT :localityName 230 76:l= 8 prim: PRINTABLESTRING :San Jose 231 86:l= 14 cons: SET 232 88:l= 12 cons: SEQUENCE 233 90:l= 3 prim: OBJECT :organizationName 234 95:l= 5 prim: PRINTABLESTRING :sipit 235 102:l= 41 cons: SET 236 104:l= 39 cons: SEQUENCE 237 106:l= 3 prim: OBJECT :organizationalUnitName 238 111:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 239 145:l= 30 cons: SEQUENCE 240 147:l= 13 prim: UTCTIME :030718122152Z 241 162:l= 13 prim: UTCTIME :130715122152Z 242 177:l= 112 cons: SEQUENCE 243 179:l= 11 cons: SET 244 181:l= 9 cons: SEQUENCE 245 183:l= 3 prim: OBJECT :countryName 246 188:l= 2 prim: PRINTABLESTRING :US 247 192:l= 19 cons: SET 248 194:l= 17 cons: SEQUENCE 249 196:l= 3 prim: OBJECT :stateOrProvinceName 250 201:l= 10 prim: PRINTABLESTRING :California 251 213:l= 17 cons: SET 252 215:l= 15 cons: SEQUENCE 253 217:l= 3 prim: OBJECT :localityName 254 222:l= 8 prim: PRINTABLESTRING :San Jose 255 232:l= 14 cons: SET 256 234:l= 12 cons: SEQUENCE 257 236:l= 3 prim: OBJECT :organizationName 258 241:l= 5 prim: PRINTABLESTRING :sipit 259 248:l= 41 cons: SET 260 250:l= 39 cons: SEQUENCE 261 252:l= 3 prim: OBJECT :organizationalUnitName 262 257:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 263 291:l= 159 cons: SEQUENCE 264 294:l= 13 cons: SEQUENCE 265 296:l= 9 prim: OBJECT :rsaEncryption 266 307:l= 0 prim: NULL 267 309:l= 141 prim: BIT STRING 268 00 30 81 89 02 81 81 00-c3 22 1e 83 91 c5 03 2c .0......."....., 269 3c 8a f4 11 14 c6 4b 9d-fa 72 78 c6 b0 95 18 a7 <.....K..rx..... 270 e0 8c 79 ba 5d a4 ae 1e-21 2d 9d f1 0b 1c cf bd ..y.]...!-...... 271 5b 29 b3 90 13 73 66 92-6e df 4c b3 b3 1c 1f 2a [)...sf.n.L....* 272 82 0a ba 07 4d 52 b0 f8-37 7b e2 0a 27 30 70 dd ....MR..7{..'0p. 273 f9 2e 03 ff 2a 76 cd df-87 1a bd 71 eb e1 99 6a ....*v.....q...j 274 c4 7f 8e 74 a0 77 85 04-e9 41 ad fc 03 b6 17 75 ...t.w...A.....u 275 aa 33 ea 0a 16 d9 fb 79-32 2e f8 cf 4d c6 34 a3 .3.....y2...M.4. 276 ff 1b d0 68 28 e1 9d e5-02 03 01 00 01 ...h(........ 277 453:l= 205 cons: cont [ 3 ] 278 456:l= 202 cons: SEQUENCE 279 459:l= 29 cons: SEQUENCE 280 461:l= 3 prim: OBJECT :X509v3 Subject Key Identifier 281 466:l= 22 prim: OCTET STRING 282 04 14 6b 46 17 14 ea 94-76 25 80 54 6e 13 54 da ..kF....v%.Tn.T. 283 a1 e3 54 14 a1 b6 ..T... 284 490:l= 154 cons: SEQUENCE 285 493:l= 3 prim: OBJECT :X509v3 Authority Key Identifier 286 498:l= 146 prim: OCTET STRING 287 30 81 8f 80 14 6b 46 17-14 ea 94 76 25 80 54 6e 0....kF....v%.Tn 288 13 54 da a1 e3 54 14 a1-b6 a1 74 a4 72 30 70 31 .T...T....t.r0p1 289 0b 30 09 06 03 55 04 06-13 02 55 53 31 13 30 11 .0...U....US1.0. 290 06 03 55 04 08 13 0a 43-61 6c 69 66 6f 72 6e 69 ..U....Californi 291 61 31 11 30 0f 06 03 55-04 07 13 08 53 61 6e 20 a1.0...U....San 292 4a 6f 73 65 31 0e 30 0c-06 03 55 04 0a 13 05 73 Jose1.0...U....s 293 69 70 69 74 31 29 30 27-06 03 55 04 0b 13 20 53 ipit1)0'..U... S 294 69 70 69 74 20 54 65 73-74 20 43 65 72 74 69 66 ipit Test Certif 295 69 63 61 74 65 20 41 75-74 68 6f 72 69 74 79 82 icate Authority. 296 01 . 297 0092 - 298 647:l= 12 cons: SEQUENCE 299 649:l= 3 prim: OBJECT :X509v3 Basic Constraints 300 654:l= 5 prim: OCTET STRING 301 30 03 01 01 ff 0.... 302 661:l= 13 cons: SEQUENCE 303 663:l= 9 prim: OBJECT :sha1WithRSAEncryption 304 674:l= 0 prim: NULL 305 676:l= 129 prim: BIT STRING 306 00 96 6d 1b ef d5 91 93-45 7c 5b 1f cf c4 aa 47 ..m.....E|[....G 307 52 0b 34 a8 50 fa ec fa-b4 2a 47 4c 5d 41 a7 3d R.4.P....*GL]A.= 308 c0 d6 3f 9e 56 5b 91 1d-ce a8 07 b3 1b a4 9f 9a ..?.V[.......... 309 49 6f 7f e0 ce 83 94 71-42 af fe 63 a2 34 dc b4 Io.....qB..c.4.. 310 5e a5 ce ca 79 50 e9 6a-99 4c 14 69 e9 7c ab 22 ^...yP.j.L.i.|." 311 6c 44 cc 8a 9c 33 6b 23-50 42 05 1f e1 c2 81 88 lD...3k#PB...... 312 5f ba e5 47 bb 85 9b 83-25 ad 84 32 ff 2a 5b 8b _..G....%..2.*[. 313 70 12 11 83 61 c9 69 15-4f 58 a3 3c 92 d4 e8 6f p...a.i.OX.<...o 314 52 R 316 3.2. Host Certificates 318 The certificate for the host example.com is shown below. Note that 319 the Subject Alternative Name is set to example.com and is a DNS type. 320 The certificates for the other hosts are shown in Appendix B. 322 Version: 3 (0x2) 323 Serial Number: 324 01:52:01:54:01:90:00:43 325 Signature Algorithm: sha1WithRSAEncryption 326 Issuer: C=US, ST=California, L=San Jose, O=sipit, 327 OU=Sipit Test Certificate Authority 328 Validity 329 Not Before: Apr 28 22:12:00 2009 GMT 330 Not After : Apr 27 22:12:00 2012 GMT 331 Subject: C=US, ST=California, L=San Jose, O=sipit, CN=example.com 332 Subject Public Key Info: 333 Public Key Algorithm: rsaEncryption 334 RSA Public Key: (2048 bit) 335 Modulus (2048 bit): 336 00:c7:60:09:2c:e2:0b:a6:8d:2c:8f:86:eb:47:72: 337 4d:dc:20:a5:48:69:9c:c6:79:73:3a:65:e4:74:b6: 338 80:99:4f:6e:a4:1b:1b:6f:5c:91:29:7c:11:a1:bd: 339 ad:25:c6:42:a3:96:bb:d8:c8:11:d8:2a:bc:39:5f: 340 e3:5f:9a:54:f5:0c:77:44:c6:f0:ee:a7:73:85:d0: 341 d1:d7:34:96:d8:24:83:fe:1d:a7:5e:94:6a:a6:79: 342 e6:8b:d6:96:06:31:8d:da:4d:f1:72:c0:a2:9c:48: 343 c9:d2:1f:80:27:60:52:b8:12:cc:43:7c:e7:66:ac: 344 b7:6e:07:bc:e7:d5:0f:fa:41:b3:37:4f:16:33:71: 345 fc:6d:73:17:b5:65:8b:65:03:34:83:8e:98:7d:8b: 346 a3:36:f1:a7:37:94:65:af:dd:13:29:f8:1b:c2:8b: 347 fa:05:03:6b:4b:26:ae:a9:93:ab:5d:0c:f3:08:84: 348 9e:16:c0:13:fa:da:8f:1c:b6:69:95:04:6d:c8:cf: 349 c0:12:8f:fd:27:2a:cb:16:16:fd:c2:fa:94:fe:e8: 350 78:40:e4:5a:ac:a7:ef:d7:17:7d:e8:f8:86:8c:16: 351 35:ff:3e:32:fd:43:1c:c1:20:08:2c:aa:56:a6:17: 352 4f:bc:74:b0:5d:57:ba:a5:19:b4:20:46:dd:36:3d: 354 15:b3 355 Exponent: 65537 (0x10001) 356 X509v3 extensions: 357 X509v3 Subject Alternative Name: 358 DNS:com, URI:sip:example.com 359 X509v3 Basic Constraints: 360 CA:FALSE 361 X509v3 Subject Key Identifier: 362 28:CC:9B:2B:4F:7C:43:5C:9D:AD:96:8B:73:A2:4F:58:5D:30:D4:04 363 X509v3 Authority Key Identifier: 364 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 365 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 366 OU=Sipit Test Certificate Authority 367 serial:00 369 X509v3 Key Usage: 370 Digital Signature, Non Repudiation, Key Encipherment 371 X509v3 Extended Key Usage: 372 TLS Web Server Authentication, 1.3.6.1.5.5.7.3.20 373 Signature Algorithm: sha1WithRSAEncryption 374 1f:b7:c2:84:43:90:d2:06:81:47:48:e7:14:39:5a:ad:a0:53: 375 36:fb:6f:d7:e1:bf:b1:65:98:fd:a6:c5:e0:5a:b7:5f:90:08: 376 ab:d4:85:2a:d1:57:f2:0e:c1:26:43:de:e1:26:1e:ef:90:95: 377 94:6e:74:45:36:01:41:ce:43:c2:91:54:dd:35:a8:6e:57:3b: 378 b2:34:71:aa:d4:ea:34:aa:8c:8e:dd:e1:a4:2c:05:45:fb:b8: 379 38:0c:7b:1f:4f:d7:3c:d7:68:7c:57:57:6d:13:c6:3f:44:dd: 380 fd:6b:fb:65:96:9b:87:92:95:10:af:e7:47:cd:72:6c:6e:d7: 381 60:f5 383 The example host certificate above, as well as all the others 384 presented in this document, are signed directly by a root CA. These 385 certificate chains have a length equal to two: the root CA and the 386 host certificate. Non-root CAs exist and may also sign certificates. 387 The certificate chains presented by hosts with certificates signed by 388 non-root CAs will have a length greater than two. For more details 389 on how certificate chains are validated, see section 6.1.4 of RFC 390 5280 [4]. 392 3.3. User Certificates 394 User certificates are used by many applications to establish user 395 identity. The user certificate for fluffy@example.com is shown 396 below. Note that the Subject Alternative Name has a list of names 397 with different URL types such as a sip, im, or pres URL. This is 398 necessary for interoperating with a CPIM gateway. In this example, 399 example.com is the domain for fluffy. The message could be coming 400 from a host called atlanta.example.com, and the AOR in the user 401 certificate would still be the same. The others are shown in 402 Appendix B.1. These certificates make use of the EKU extension 403 discussed in Draft SIP EKU [13]. Note that the X509v3 Extended Key 404 Usage attribute refers to the SIP OID introduced in Draft SIP EKU 405 [13] is 1.3.6.1.5.5.7.3.20 407 Version: 3 (0x2) 408 Serial Number: 409 01:52:01:54:01:90:00:47 410 Signature Algorithm: sha1WithRSAEncryption 411 Issuer: C=US, ST=California, L=San Jose, O=sipit, 412 OU=Sipit Test Certificate Authority 413 Validity 414 Not Before: Apr 29 17:10:46 2009 GMT 415 Not After : Apr 28 17:10:46 2012 GMT 416 Subject: C=US, ST=California, L=San Jose, O=sipit, 417 CN=fluffy@example.com 418 Subject Public Key Info: 419 Public Key Algorithm: rsaEncryption 420 RSA Public Key: (2048 bit) 421 Modulus (2048 bit): 422 00:f4:0f:e8:18:2d:b1:9b:93:ef:64:6b:19:d7:83: 423 ac:f7:af:12:37:30:48:df:6e:55:0a:ce:f7:2a:19: 424 17:66:bc:42:af:7a:af:78:6c:96:c6:c1:de:5e:38: 425 67:93:8d:f2:40:13:b5:6f:07:79:de:32:2c:23:e7: 426 ba:e4:a8:36:32:83:8a:75:79:86:85:a2:50:d1:bb: 427 b5:81:36:7e:6b:f2:64:9b:b6:54:d3:8b:c4:4d:4d: 428 26:94:ae:7c:50:e4:b2:e6:5f:ac:34:e0:97:51:cd: 429 ff:66:b9:92:98:c5:cc:22:e7:0c:30:a4:4c:a6:37: 430 ba:21:31:b2:81:93:0d:24:ee:a7:27:c9:b3:ec:46: 431 e3:f9:7a:d2:42:0a:59:ab:e7:a3:8b:30:66:3d:31: 432 88:6f:ee:c4:8d:24:ca:99:f1:c8:4c:50:0d:4b:6b: 433 73:80:ac:74:6f:45:b1:29:29:a1:89:40:94:02:57: 434 23:8b:6d:60:5c:38:d3:1f:c3:bb:74:3d:15:87:af: 435 2d:29:16:6c:30:01:4e:e3:39:13:17:6b:ea:58:97: 436 75:9f:60:38:84:2c:31:95:6e:d8:6d:69:81:bb:2e: 437 fa:59:a2:fb:08:53:59:df:1e:94:17:e5:10:f8:72: 438 5a:fb:4e:4f:2f:cd:3b:3d:30:c5:b6:c8:3b:e0:e7: 439 32:ed 440 Exponent: 65537 (0x10001) 441 X509v3 extensions: 442 X509v3 Subject Alternative Name: 443 URI:sip:fluffy@example.com, URI:im:fluffy@example.com, 444 URI:pres:fluffy@example.com 445 X509v3 Basic Constraints: 446 CA:FALSE 447 X509v3 Subject Key Identifier: 448 D2:A2:22:FB:4D:A1:37:B9:15:0B:1E:FC:27:BC:FA:00:A7:1C:F2:29 450 X509v3 Authority Key Identifier: 451 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 452 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 453 OU=Sipit Test Certificate Authority 454 serial:00 456 X509v3 Key Usage: 457 Digital Signature, Non Repudiation, Key Encipherment 458 X509v3 Extended Key Usage: 459 E-mail Protection, 1.3.6.1.5.5.7.3.20 460 Signature Algorithm: sha1WithRSAEncryption 461 80:a0:db:45:dd:7d:b6:50:b6:93:27:36:cd:cd:28:3c:39:23: 462 aa:e4:6e:9c:f7:d9:8c:96:4d:b7:36:f6:ac:c1:8f:86:d8:6a: 463 91:3a:4f:5a:68:32:37:df:0f:dd:40:b7:34:68:91:ce:0f:f0: 464 16:02:ee:be:b6:1d:e1:92:87:c9:5e:a9:42:78:26:45:bb:17: 465 08:ee:83:ea:e9:d8:30:84:66:90:69:b8:78:ff:c4:09:5c:ea: 466 e2:8a:10:e6:f9:64:eb:db:47:0e:10:29:4d:0e:bb:53:65:70: 467 e1:71:82:c8:d0:14:f4:24:30:49:a6:fc:80:a8:b1:84:bc:e9: 468 73:75 470 Versions of these certificates that do not make use of EKU are also 471 included in Appendix B.2 473 4. Callflow with Message Over TLS 475 4.1. TLS with Server Authentication 477 The flow below shows the edited SSLDump output of the host 478 example.com forming a TLSRFC 5246 [5] connection to example.net. In 479 this example mutual authentication is not used. Note that the client 480 proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA 481 defined in RFC 3268 [7]. The certificate returned by the server 482 contains a Subject Alternative Name that is set to example.net. A 483 detailed discussion of TLS can be found in SSL and TLS [18]. For 484 more details on the SSLDump tool, see the SSLDump Manual [19]. 486 This example does not use the Server Extended Hello (see RFC 3546 487 [6]). 489 New TCP connection #1: www.example.com(57592) <-> www.example.com(5061) 490 1 1 0.0015 (0.0015) C>SV3.1(101) Handshake 491 ClientHello 492 Version 3.1 493 random[32]= 494 49 f7 83 8d 1f 21 c7 73 0c 9f 61 ab 13 2d 6b 26 495 1e 79 0c 68 b3 b6 f8 24 54 6b 41 0d 9b 3a 03 31 497 cipher suites 498 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 499 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 500 TLS_DHE_RSA_WITH_AES_256_SHA 501 TLS_RSA_WITH_AES_256_CBC_SHA 502 TLS_DSS_RSA_WITH_AES_256_SHA 503 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 504 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 505 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 506 TLS_RSA_WITH_AES_128_CBC_SHA 507 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 508 TLS_ECDHE_RSA_WITH_DES_192_CBC3_SHA 509 TLS_ECDH_RSA_WITH_DES_192_CBC3_SHA 510 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 511 TLS_RSA_WITH_3DES_EDE_CBC_SHA 512 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 513 TLS_ECDHE_RSA_WITH_RC4_128_SHA 514 TLS_ECDH_RSA_WITH_RC4_128_SHA 515 TLS_RSA_WITH_RC4_128_SHA 516 TLS_RSA_WITH_RC4_128_MD5 517 TLS_DHE_RSA_WITH_DES_CBC_SHA 518 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 519 TLS_RSA_WITH_DES_CBC_SHA 520 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 521 TLS_DHE_DSS_WITH_DES_CBC_SHA 522 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 523 TLS_RSA_EXPORT_WITH_RC4_40_MD5 524 compression methods 525 NULL 526 1 2 0.0040 (0.0024) S>CV3.1(48) Handshake 527 ServerHello 528 Version 3.1 529 random[32]= 530 49 f7 83 8d a0 f8 f0 3f ff 2d d4 13 9c 29 2b 2b 531 fc 1c 92 b9 a8 2a d2 10 0c 54 8e fd af d6 42 22 532 session_id[0]= 534 cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA 535 compressionMethod NULL 536 1 3 0.0040 (0.0000) S>CV3.1(1823) Handshake 537 Certificate 538 1 4 0.0040 (0.0000) S>CV3.1(14) Handshake 539 CertificateRequest 540 certificate_types rsa_sign 541 certificate_types dss_sign 542 certificate_types unknown value 543 ServerHelloDone 544 1 5 0.0360 (0.0320) C>SV3.1(7) Handshake 545 Certificate 546 1 6 0.0360 (0.0000) C>SV3.1(262) Handshake 547 ClientKeyExchange 548 1 7 0.0360 (0.0000) C>SV3.1(1) ChangeCipherSpec 549 1 8 0.0360 (0.0000) C>SV3.1(48) Handshake 550 1 9 0.0770 (0.0410) S>CV3.1(170) Handshake 551 1 10 0.0770 (0.0000) S>CV3.1(1) ChangeCipherSpec 552 1 11 0.0770 (0.0000) S>CV3.1(48) Handshake 553 1 12 0.0780 (0.0010) C>SV3.1(32) application_data 554 1 13 0.0780 (0.0000) C>SV3.1(448) application_data 555 1 14 0.2804 (0.2023) S>CV3.1(32) application_data 556 1 15 0.2804 (0.0000) S>CV3.1(416) application_data 557 1 16 12.3288 (12.0483) S>CV3.1(32) Alert 558 1 12.3293 (0.0004) S>C TCP FIN 559 1 17 12.3310 (0.0017) C>SV3.1(32) Alert 561 4.2. MESSAGE Message Over TLS 563 Once the TLS session is set up, the following MESSAGE message (as 564 defined in RFC 3428 [15] is sent from fluffy@example.com to 565 kumiko@example.net. Note that the URI has a SIPS URL and that the 566 VIA indicates that TLS was used. In order to format this document, 567 the convention from RFC 4475 [12] is used to break long 568 lines. The actual message does not contain the linebreaks contained 569 within those tags. 571 MESSAGE sips:kumiko@example.net:5061 SIP/2.0 572 Via: SIP/2.0/TLS 208.77.188.166:15001;\ 573 branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\ 574 rport=54499 575 Max-Forwards: 70 576 Contact: 577 To: 578 From: ;tag=2eff6a6f 579 Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY. 580 CSeq: 1 MESSAGE 581 Accept: multipart/signed, text/plain, application/pkcs7-mime,\ 582 application/sdp, multipart/alternative 583 Content-Type: text/plain 584 Content-Length: 6 586 Hello! 588 The response is sent from example.net to example.com over the same 589 TLS connection. It is shown below. 591 SIP/2.0 200 OK 592 Via: SIP/2.0/TLS 208.77.188.166:15001;\ 593 branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\ 594 rport=54499 595 Contact: 596 To: ;tag=00e62966 597 From: ;tag=2eff6a6f 598 Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY. 599 CSeq: 1 MESSAGE 600 Content-Length: 0 602 OPEN ISSUE: Ben Campbell pointed out: Contact: "RFC3428 forbids 603 Contact header fields in MESSAGE requests or 2XX responses to 604 MESSAGE. This brings up the question as to whether MESSAGE is a good 605 example, as you may wish to illustrate SIPS rules concerning Contact. 606 (This reoccurs in all MESSAGE and 200 OK examples)." We need 607 consensus on this. 609 OPEN ISSUE: There should be some more information about how this 610 MESSAGE is associated with the handshake example. The dump in 5.1 is 611 slightly confusing in that example.com and example.net both resolved 612 to the same address, so reverse lookup shows both domains as 613 example.com. 615 OPEN ISSUE: Add a few lines about RFC 3263. Add a few lines about 616 how the UA decides to create a new TLS session or use an existing one 617 (but not "connection-reuse" draft level of reuse complexity). Any 618 volunteers? 620 5. Callflow with S/MIME-secured Message 622 5.1. MESSAGE Message with Signed Body 624 Below is an example of a signed message. The values on the Content- 625 Type line (multipart/signed) and on the Content-Disposition line have 626 been broken across lines to fit on the page, but they should not be 627 broken across lines in actual implementations. 629 MESSAGE sip:kumiko@example.net SIP/2.0 630 Via: SIP/2.0/TCP 208.77.188.166:15001;\ 631 branch=z9hG4bK-d8754z-36f515466f3a7f5c-1---d8754z-;\ 632 rport=54500 633 Max-Forwards: 70 634 Contact: 635 To: 636 From: ;tag=e8cc1b5c 637 Call-ID: NjVjYjNjNzQzNTZlYzdjMWUwM2VjYjcwOTVjM2RkZDM. 638 CSeq: 1 MESSAGE 639 Accept: multipart/signed, text/plain, application/pkcs7-mime,\ 640 application/sdp, multipart/alternative 641 Content-Type: multipart/signed;boundary=ac31fa52a112030f;\ 642 micalg=sha1;protocol="application/pkcs7-signature" 643 Content-Length: 772 645 --ac31fa52a112030f 646 Content-Type: text/plain 647 Content-Transfer-Encoding: binary 649 hello 650 --ac31fa52a112030f 651 Content-Type: application/pkcs7-signature;name=smime.p7s 652 Content-Disposition: attachment;handling=required;\ 653 filename=smime.p7s 654 Content-Transfer-Encoding: binary 656 ***************** 657 * BINARY BLOB 1 * 658 ***************** 659 --ac31fa52a112030f-- 661 It is important to note that the signature ("BINARY BLOB 1") is 662 computed over the MIME headers and body, but excludes the multipart 663 boundary lines. The value on the Message-body line ends with CRLF. 664 The CRLF is included in the boundary and should not be part of the 665 signature computation. To be clear, the signature is computed over 666 data starting with the C in the Content-Type and ending with the o in 667 the hello. 669 Content-Type: text/plain 670 Content-Transfer-Encoding: binary 672 hello 674 Following is the ASN.1 parsing of encrypted contents referred to 675 above as "BINARY BLOB 1". Note that at address 30, the hash for the 676 signature is specified as SHA-1. Also note that the sender's 677 certificate is not attached as it is optional in RFC 3852 [9]. 679 0 471: SEQUENCE { 680 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 681 15 456: [0] { 682 19 452: SEQUENCE { 683 23 1: INTEGER 1 684 26 11: SET { 685 28 9: SEQUENCE { 686 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 687 37 0: NULL 688 : } 689 : } 690 39 11: SEQUENCE { 691 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 692 : } 693 52 419: SET { 694 56 415: SEQUENCE { 695 60 1: INTEGER 1 696 63 124: SEQUENCE { 697 65 112: SEQUENCE { 698 67 11: SET { 699 69 9: SEQUENCE { 700 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 701 76 2: PrintableString 'US' 702 : } 703 : } 704 80 19: SET { 705 82 17: SEQUENCE { 706 84 3: OBJECT IDENTIFIER 707 : stateOrProvinceName (2 5 4 8) 708 89 10: PrintableString 'California' 709 : } 710 : } 711 101 17: SET { 712 103 15: SEQUENCE { 713 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 714 110 8: PrintableString 'San Jose' 715 : } 716 : } 717 120 14: SET { 718 122 12: SEQUENCE { 719 124 3: OBJECT IDENTIFIER 720 : organizationName (2 5 4 10) 721 129 5: PrintableString 'sipit' 722 : } 723 : } 724 136 41: SET { 725 138 39: SEQUENCE { 726 140 3: OBJECT IDENTIFIER 727 : organizationalUnitName (2 5 4 11) 728 145 32: PrintableString 'Sipit Test Certificate Aut 729 hority' 730 : } 731 : } 732 : } 733 179 8: INTEGER 01 52 01 54 01 90 00 47 734 : } 735 189 9: SEQUENCE { 736 191 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 737 198 0: NULL 738 : } 739 200 13: SEQUENCE { 740 202 9: OBJECT IDENTIFIER 741 : rsaEncryption (1 2 840 113549 1 1 1) 742 213 0: NULL 743 : } 744 215 256: OCTET STRING 745 : B1 08 00 AA 15 AC 59 6D 1A 66 66 61 40 A7 BB B1 746 : D6 7C 32 D8 CE 59 98 E3 8F 69 94 09 A5 F2 C4 34 747 : 6F 49 4D 56 64 FE EB A9 EA 71 5D 44 B4 0C 77 C1 748 : 0E BF FD 42 17 E3 84 A2 7E 5E 13 6C A6 F8 2B A9 749 : 24 3F BE AE 14 51 0E 0D 3E 9A 93 9A 16 52 25 AB 750 : 28 AA C5 8D 15 EB 96 29 C0 9B D9 52 3E 38 D8 07 751 : 86 2D 22 28 9F 66 0F 74 DF B1 63 0B 26 0D 51 11 752 : EF AD 54 01 6D A4 C9 65 C6 3E 78 E3 CE 1C 78 5A 753 : 41 85 B5 20 22 9F 0B 70 5A 0B 62 1F EF 92 56 75 754 : 22 25 41 90 2B F5 12 08 60 07 09 F7 73 5A 89 B9 755 : 0D F1 48 54 FF 1C FA C3 A8 10 58 6D 58 98 18 A5 756 : 0B B3 24 24 D5 CE DB 33 FC 31 75 E9 AC 15 1F 02 757 : F2 A8 E0 3A 3F 1E D2 22 B8 4D EA 11 0A 08 76 A7 758 : 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A 759 : 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA 760 : 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01 761 : } 762 : } 763 : } 764 : } 765 : } 767 SHA-1 parameters may be omitted entirely, instead of being set to 768 NULL, as mentioned in RFC 3370 [11]. The above dump of Blob 1 has 769 SHA-1 parameters set to NULL. Below are the same contents signed 770 with the same key, but omitting the NULL according to RFC 3370 [11]. 771 This is the preferred encoding. This is covered in greater detail in 772 Section 6. 774 0 467: SEQUENCE { 775 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 776 15 452: [0] { 777 19 448: SEQUENCE { 778 23 1: INTEGER 1 779 26 9: SET { 780 28 7: SEQUENCE { 781 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 782 : } 783 : } 784 37 11: SEQUENCE { 785 39 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 786 : } 787 50 417: SET { 788 54 413: SEQUENCE { 789 58 1: INTEGER 1 790 61 124: SEQUENCE { 791 63 112: SEQUENCE { 792 65 11: SET { 793 67 9: SEQUENCE { 794 69 3: OBJECT IDENTIFIER countryName (2 5 4 6) 795 74 2: PrintableString 'US' 796 : } 797 : } 798 78 19: SET { 799 80 17: SEQUENCE { 800 82 3: OBJECT IDENTIFIER 801 : stateOrProvinceName (2 5 4 8) 802 87 10: PrintableString 'California' 803 : } 804 : } 805 99 17: SET { 806 101 15: SEQUENCE { 807 103 3: OBJECT IDENTIFIER localityName (2 5 4 7) 808 108 8: PrintableString 'San Jose' 809 : } 810 : } 811 118 14: SET { 812 120 12: SEQUENCE { 813 122 3: OBJECT IDENTIFIER 814 : organizationName (2 5 4 10) 815 127 5: PrintableString 'sipit' 816 : } 817 : } 818 134 41: SET { 819 136 39: SEQUENCE { 820 138 3: OBJECT IDENTIFIER 821 : organizationalUnitName (2 5 4 11) 822 143 32: PrintableString 'Sipit Test Certificate Aut 823 hority' 824 : } 825 : } 826 : } 827 177 8: INTEGER 01 52 01 54 01 90 00 47 828 : } 829 187 7: SEQUENCE { 830 189 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 831 : } 832 196 13: SEQUENCE { 833 198 9: OBJECT IDENTIFIER 834 : rsaEncryption (1 2 840 113549 1 1 1) 835 209 0: NULL 836 : } 837 211 256: OCTET STRING 838 : B1 08 00 AA 15 AC 59 6D 1A 66 66 61 40 A7 BB B1 839 : D6 7C 32 D8 CE 59 98 E3 8F 69 94 09 A5 F2 C4 34 840 : 6F 49 4D 56 64 FE EB A9 EA 71 5D 44 B4 0C 77 C1 841 : 0E BF FD 42 17 E3 84 A2 7E 5E 13 6C A6 F8 2B A9 842 : 24 3F BE AE 14 51 0E 0D 3E 9A 93 9A 16 52 25 AB 843 : 28 AA C5 8D 15 EB 96 29 C0 9B D9 52 3E 38 D8 07 844 : 86 2D 22 28 9F 66 0F 74 DF B1 63 0B 26 0D 51 11 845 : EF AD 54 01 6D A4 C9 65 C6 3E 78 E3 CE 1C 78 5A 846 : 41 85 B5 20 22 9F 0B 70 5A 0B 62 1F EF 92 56 75 847 : 22 25 41 90 2B F5 12 08 60 07 09 F7 73 5A 89 B9 848 : 0D F1 48 54 FF 1C FA C3 A8 10 58 6D 58 98 18 A5 849 : 0B B3 24 24 D5 CE DB 33 FC 31 75 E9 AC 15 1F 02 850 : F2 A8 E0 3A 3F 1E D2 22 B8 4D EA 11 0A 08 76 A7 851 : 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A 852 : 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA 853 : 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01 854 : } 855 : } 856 : } 857 : } 858 : } 860 5.2. MESSAGE Message with Encrypted Body 862 Below is an example of an encrypted text/plain message that says 863 "hello". The binary encrypted contents have been replaced with the 864 block "BINARY BLOB 2". 866 MESSAGE sip:kumiko@example.net SIP/2.0 867 Via: SIP/2.0/TCP 208.77.188.166:15001;\ 868 branch=z9hG4bK-d8754z-1c7dd40a5fff4463-1---d8754z-;\ 869 rport=54502 870 Max-Forwards: 70 871 Contact: 872 To: 873 From: ;tag=5a10502e 874 Call-ID: YTk3ODIwN2FiYTUwMGZmYTM1MDJiMzY2ODcyYzE4MGM. 875 CSeq: 1 MESSAGE 876 Accept: multipart/signed, text/plain, application/pkcs7-mime,\ 877 application/sdp, multipart/alternative 878 Content-Disposition: attachment;handling=required;\ 879 filename=smime.p7 880 Content-Transfer-Encoding: binary 881 Content-Type: application/pkcs7-mime;smime-type=enveloped-data;\ 882 name=smime.p7m 883 Content-Length: 564 885 ***************** 886 * BINARY BLOB 2 * 887 ***************** 889 Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at 890 address 453, the encryption is set to aes128-CBC. 892 0 560: SEQUENCE { 893 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 894 15 545: [0] { 895 19 541: SEQUENCE { 896 23 1: INTEGER 0 897 26 408: SET { 898 30 404: SEQUENCE { 899 34 1: INTEGER 0 900 37 124: SEQUENCE { 901 39 112: SEQUENCE { 902 41 11: SET { 903 43 9: SEQUENCE { 904 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 905 50 2: PrintableString 'US' 906 : } 907 : } 908 54 19: SET { 909 56 17: SEQUENCE { 910 58 3: OBJECT IDENTIFIER 911 : stateOrProvinceName (2 5 4 8) 912 63 10: PrintableString 'California' 913 : } 914 : } 915 75 17: SET { 916 77 15: SEQUENCE { 917 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 918 84 8: PrintableString 'San Jose' 919 : } 920 : } 921 94 14: SET { 922 96 12: SEQUENCE { 923 98 3: OBJECT IDENTIFIER 924 : organizationName (2 5 4 10) 925 103 5: PrintableString 'sipit' 926 : } 927 : } 928 110 41: SET { 929 112 39: SEQUENCE { 930 114 3: OBJECT IDENTIFIER 931 : organizationalUnitName (2 5 4 11) 932 119 32: PrintableString 'Sipit Test Certificate Aut 933 hority' 934 : } 935 : } 936 : } 937 153 8: INTEGER 01 52 01 54 01 90 00 48 938 : } 939 163 13: SEQUENCE { 940 165 9: OBJECT IDENTIFIER 941 : rsaEncryption (1 2 840 113549 1 1 1) 942 176 0: NULL 943 : } 944 178 256: OCTET STRING 945 : 6E 48 A2 78 07 3A 47 09 C0 57 6F CB 01 AA 0E E7 946 : 3E 2C 1B 78 8F 6B 0B C2 D4 F2 BD 41 8E 3E CB 95 947 : CD 35 9C 2E 59 8B E8 E5 35 59 6F 0E FC 3B BB A4 948 : 2E 66 0D 68 6E 45 04 CA 4B E5 29 BE 65 F1 51 A1 949 : E3 40 83 95 7C 8F B0 A9 56 CF 34 D4 DE C4 63 BE 950 : 26 55 1D 57 51 E2 86 8C 2A 7D B1 37 13 B5 F8 8D 951 : B8 3C F1 84 31 0C 57 B2 24 E3 D2 F6 94 5D A2 80 952 : 2E 45 B7 36 96 6C EF A3 90 23 8E 9D B3 50 0A 6F 953 : DB E7 47 54 EA 2D 5E 38 75 77 CB 05 EE 45 71 B6 954 : BB 95 93 AF 59 31 BC B3 10 F7 FE 72 B9 85 22 51 955 : 80 A6 7E F6 E5 9E 46 32 2C 8A BB ED 60 C8 F6 7B 956 : 2D 9E CF 5F 9E D9 21 68 08 BE 00 51 27 A7 1B 54 957 : 53 CF 45 2A 58 61 63 3C 19 75 86 67 04 C3 05 77 958 : 6D 77 19 3B A4 16 32 38 1C 79 05 7B 71 11 7B 56 959 : 24 75 24 6B F7 75 D1 8A DA AE B8 3A 86 4D 31 0A 960 : 1B D2 80 88 64 52 13 DA FE 93 DD AA C9 E0 D2 CB 961 : } 962 : } 963 438 124: SEQUENCE { 964 440 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 965 451 29: SEQUENCE { 966 453 9: OBJECT IDENTIFIER 967 : aes128-CBC (2 16 840 1 101 3 4 1 2) 968 464 16: OCTET STRING 969 : E8 E4 34 63 AE 68 F7 C1 62 C5 9E 7B 6F 25 22 AF 970 : } 971 482 80: [0] 972 : 41 4C FE FA A4 B4 70 1A 62 86 BC C1 DE 90 94 69 973 : 7D 0A D2 0F F3 4E 7D 6F 72 2F 7A A7 4B B4 4A 59 974 : C9 C0 CB F3 AD 92 D6 31 66 94 0E B3 49 01 63 D5 975 : BA 5A AE 29 ED C9 8A 87 EA 00 FC 4B 97 62 54 56 976 : 91 DB 78 50 B6 AD B7 B8 5D F6 11 41 3C C0 20 DD 977 : } 978 : } 979 : } 980 : } 982 5.3. MESSAGE Message with Encrypted and Signed Body 984 In the example below, some of the header values have been split 985 across mutliple lines. Where the lines have been broken, a "\" has 986 been inserted. This was only done to make it fit in the RFC format. 987 Specifically, the application/pkcs7-mime Content-Type line should be 988 one line with no whitespace between the "mime;" and the "smime-type". 989 The values are split across lines for formatting, but are not split 990 in the real message. The binary encrypted content has been replaced 991 with "BINARY BLOB 3", and the binary signed content has been replaced 992 with "BINARY BLOB 4". 994 MESSAGE sip:kumiko@example.net SIP/2.0 995 Via: SIP/2.0/TCP 208.77.188.166:15001;\ 996 branch=z9hG4bK-d8754z-c2d73f665e157842-1---d8754z-;\ 997 rport=54503 998 Max-Forwards: 70 999 Contact: 1000 To: 1001 From: ;tag=5e4dd355 1002 Call-ID: MDQ2ZGVkZWQ4YzJhZTZhZDRjNzE0MDJkNzk1NGIxNTQ. 1003 CSeq: 1 MESSAGE 1004 Accept: multipart/signed, text/plain, application/pkcs7-mime,\ 1005 application/sdp, multipart/alternative 1006 Content-Type: multipart/signed;boundary=e0c6b73cedc44967;\ 1007 micalg=sha1;protocol="application/pkcs7-signature" 1008 Content-Length: 1453 1010 --e0c6b73cedc44967 1011 Content-Type: application/pkcs7-mime;smime-type=enveloped-data;\ 1012 name=smime.p7m 1013 Content-Disposition: attachment;handling=required;\ 1014 filename=smime.p7 1015 Content-Transfer-Encoding: binary 1017 ***************** 1018 * BINARY BLOB 3 * 1019 ***************** 1020 --e0c6b73cedc44967 1021 Content-Type: application/pkcs7-signature;name=smime.p7s 1022 Content-Disposition: attachment;handling=required;\ 1023 filename=smime.p7s 1024 Content-Transfer-Encoding: binary 1026 ***************** 1027 * BINARY BLOB 4 * 1028 ***************** 1029 --e0c6b73cedc44967-- 1031 Below is the ASN.1 parsing of "BINARY BLOB 3". 1033 0 560: SEQUENCE { 1034 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 1035 15 545: [0] { 1036 19 541: SEQUENCE { 1037 23 1: INTEGER 0 1038 26 408: SET { 1039 30 404: SEQUENCE { 1040 34 1: INTEGER 0 1041 37 124: SEQUENCE { 1042 39 112: SEQUENCE { 1043 41 11: SET { 1044 43 9: SEQUENCE { 1045 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1046 50 2: PrintableString 'US' 1047 : } 1048 : } 1049 54 19: SET { 1050 56 17: SEQUENCE { 1051 58 3: OBJECT IDENTIFIER 1052 : stateOrProvinceName (2 5 4 8) 1053 63 10: PrintableString 'California' 1054 : } 1055 : } 1056 75 17: SET { 1057 77 15: SEQUENCE { 1058 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1059 84 8: PrintableString 'San Jose' 1060 : } 1061 : } 1062 94 14: SET { 1063 96 12: SEQUENCE { 1064 98 3: OBJECT IDENTIFIER 1065 : organizationName (2 5 4 10) 1066 103 5: PrintableString 'sipit' 1067 : } 1068 : } 1069 110 41: SET { 1070 112 39: SEQUENCE { 1071 114 3: OBJECT IDENTIFIER 1072 : organizationalUnitName (2 5 4 11) 1073 119 32: PrintableString 'Sipit Test Certificate Aut 1074 hority' 1075 : } 1076 : } 1077 : } 1078 153 8: INTEGER 01 52 01 54 01 90 00 48 1079 : } 1080 163 13: SEQUENCE { 1081 165 9: OBJECT IDENTIFIER 1082 : rsaEncryption (1 2 840 113549 1 1 1) 1083 176 0: NULL 1084 : } 1085 178 256: OCTET STRING 1086 : 8A C2 F2 23 B0 D4 11 0E EB 38 60 3A 47 99 14 33 1087 : 78 01 1A F9 12 9E 97 93 D5 68 B2 B8 4E CF 76 15 1088 : EF CD 36 0E A5 B8 36 5F E1 05 78 45 F7 05 12 6D 1089 : 55 0A A1 50 4C A9 F7 E3 B1 69 65 F8 38 A8 F7 2F 1090 : A1 74 0F 15 6F 29 B6 5C 74 21 49 21 77 07 E4 0A 1091 : 4D A9 02 30 15 45 2F 8F AE 08 2E 49 D9 B2 77 73 1092 : E8 41 08 4E 2D B0 B0 EE 2F 49 B7 75 D7 70 E0 60 1093 : FC A3 C9 49 38 C8 B3 79 71 46 98 C3 17 20 A9 13 1094 : E7 EE E3 99 AA E2 1F C3 C3 7A B3 70 40 DA F3 40 1095 : 0B 69 99 DC EB 5C 10 A9 FF A8 66 D1 56 BB B9 B9 1096 : 84 CB 6D 03 3F 96 CC 6D 5A 92 8B 00 23 CB 8B FE 1097 : FB BF 19 26 7F C9 69 CC 93 98 5A E4 DE D3 B0 DE 1098 : 6E 0E 29 9C E8 05 D7 4F 3D A0 F7 C2 B2 8E 0E FF 1099 : 06 DA 46 0B ED 3B 84 BF 88 17 9C 40 DA 52 65 62 1100 : A9 BB F5 7A E7 D1 78 69 9D 61 D5 48 53 56 0A BB 1101 : DD F3 35 C3 04 0D C0 BD 26 41 C1 E4 9E 19 A2 4B 1102 : } 1103 : } 1104 438 124: SEQUENCE { 1105 440 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1106 451 29: SEQUENCE { 1107 453 9: OBJECT IDENTIFIER 1108 : aes128-CBC (2 16 840 1 101 3 4 1 2) 1109 464 16: OCTET STRING 1110 : 9E C3 11 33 C1 F5 42 09 C8 8B D2 C9 54 32 78 46 1111 : } 1112 482 80: [0] 1113 : 89 5B E2 84 60 E5 45 2B 74 CC 61 4F A2 E4 03 37 1114 : D3 C6 83 52 A3 CF C9 E8 C7 8D AF F3 36 39 56 BF 1115 : 8F 7D E3 F8 65 43 6E 61 65 85 5B 62 AC BF 3A DD 1116 : 99 C7 8B B7 BA A7 3F 97 61 3C B1 E2 E0 45 BC 17 1117 : 43 51 03 F4 41 8C 55 E7 02 5F CC AE F5 02 6B D8 1118 : } 1119 : } 1120 : } 1121 : } 1123 Below is the ASN.1 parsing of "BINARY BLOB 4". 1125 0 471: SEQUENCE { 1126 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 1127 15 456: [0] { 1128 19 452: SEQUENCE { 1129 23 1: INTEGER 1 1130 26 11: SET { 1131 28 9: SEQUENCE { 1132 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1133 37 0: NULL 1134 : } 1135 : } 1136 39 11: SEQUENCE { 1137 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1138 : } 1139 52 419: SET { 1140 56 415: SEQUENCE { 1141 60 1: INTEGER 1 1142 63 124: SEQUENCE { 1143 65 112: SEQUENCE { 1144 67 11: SET { 1145 69 9: SEQUENCE { 1146 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1147 76 2: PrintableString 'US' 1148 : } 1149 : } 1150 80 19: SET { 1151 82 17: SEQUENCE { 1152 84 3: OBJECT IDENTIFIER 1153 : stateOrProvinceName (2 5 4 8) 1154 89 10: PrintableString 'California' 1155 : } 1156 : } 1157 101 17: SET { 1158 103 15: SEQUENCE { 1159 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1160 110 8: PrintableString 'San Jose' 1161 : } 1162 : } 1163 120 14: SET { 1164 122 12: SEQUENCE { 1165 124 3: OBJECT IDENTIFIER 1166 : organizationName (2 5 4 10) 1167 129 5: PrintableString 'sipit' 1168 : } 1169 : } 1170 136 41: SET { 1171 138 39: SEQUENCE { 1172 140 3: OBJECT IDENTIFIER 1173 : organizationalUnitName (2 5 4 11) 1174 145 32: PrintableString 'Sipit Test Certificate Aut 1175 hority' 1176 : } 1177 : } 1178 : } 1179 179 8: INTEGER 01 52 01 54 01 90 00 47 1180 : } 1181 189 9: SEQUENCE { 1182 191 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1183 198 0: NULL 1184 : } 1186 200 13: SEQUENCE { 1187 202 9: OBJECT IDENTIFIER 1188 : rsaEncryption (1 2 840 113549 1 1 1) 1189 213 0: NULL 1190 : } 1191 215 256: OCTET STRING 1192 : 29 C3 93 9D 71 C5 93 52 80 4B 0F C5 66 C7 CD 18 1193 : 2F 4D A0 07 E1 29 CE F9 2E CE 92 16 CD 7D B1 45 1194 : 5A 6D C2 5A 90 51 C3 20 66 FC 76 F0 DF D3 AE C5 1195 : CE 4D DF C8 0D D7 87 B3 69 ED 81 BA 71 EA B4 C0 1196 : E3 F5 A3 A4 CA 2E 36 A3 29 37 86 37 C3 B6 90 A7 1197 : EA 6A 27 52 C6 9C AB B1 2C 7B 60 10 26 E9 33 43 1198 : 83 BA 06 B0 68 05 26 88 A2 68 1A 4E E5 82 16 5B 1199 : E4 00 7D 18 09 4A 13 09 2D B5 F1 A6 C0 39 60 29 1200 : 02 32 24 29 D6 37 55 4C 42 DA 7D E9 98 F8 C6 FE 1201 : E8 01 1C 56 8B AD DB D2 B2 C4 20 A0 CC 92 BD 9B 1202 : 9F 0E C9 9E 5C BF 4E DA 1D D9 E4 02 DC DA 57 A6 1203 : 59 EC 89 CD AD 66 D3 A3 7A 88 F9 A2 DA D5 9E FB 1204 : 4F AD 7D D9 69 68 35 B1 98 10 64 42 1D 3D 24 57 1205 : C5 BF 48 C3 B0 E6 3C 91 3C 27 52 28 D2 BE 2C AC 1206 : 79 79 32 2E C4 9D 7C 8A 73 73 68 EC 60 E0 22 0D 1207 : 50 7F 72 33 96 89 F8 9F 7B ED D1 4A 75 7B D5 14 1208 : } 1209 : } 1210 : } 1211 : } 1212 : } 1214 6. Observed Interoperability Issues 1216 OPEN ISSUE: Who observed them? Is this experience from SIPits, etc? 1217 I think it would strengthen the idea that these are real-world, 1218 observed-in-the-wild issues to give sources. 1220 This section describes some common interoperability problems. 1221 Implementers should verify that their clients do the correct things 1222 and when possible make their clients forgiving in what they receive. 1223 Implementations should take extra care to produce reasonable error 1224 messages when interacting with software that has these problems. 1226 Some SIP clients incorrectly only do SSLv3 and do not support TLS. 1228 OPEN ISSUE: Do mean client class devices, or user agents in general? 1229 Does this exclude proxies? (same question throughout section.) 1231 Many SIP clients were found to accept expired certificates with no 1232 warning or error. 1234 When used with SIP, TLS and S/MIME provide the identity of the peer 1235 that a client is communicating with in the Subject Alternative Name 1236 in the certificate. The software must check that this name 1237 corresponds to the identity the server is trying to contact. If a 1238 client is trying to set up a TLS connection to good.example.com and 1239 it gets a TLS connection set up with a server that presents a valid 1240 certificate but with the name evil.example.com, it must generate an 1241 error or warning of some type. Similarly with S/MIME, if a user is 1242 trying to communicate with sip:fluffy@example.com, one of the items 1243 in the Subject Alternate Name set in the certificate must match. 1245 Some implementations used binary MIME encodings while others used 1246 base64. Implementations should send only binary but must be prepared 1247 to receive either. 1249 OPEN ISSUE: Is "...should send...must be prepared..." intended to be 1250 a normative statement? There is a larger issue as to whether this 1251 document is intended to be normative or informative. Should it be 1252 standards track? 1254 In several places in this draft, the messages contain the encoding 1255 for the SHA-1 digest algorithm identifier. The preferred form for 1256 encoding as set out in Section 2 of RFC 3370 [11] is the form in 1257 which the optional AlgorithmIdentifier parameter field is omitted. 1258 However, RFC 3370 also says the recipients need to be able to receive 1259 the form in which the AlgorithmIdentifier parameter field is present 1260 and set to NULL. Examples of the form using NULL can be found in 1261 Section 4.2 of RFC 4134 [14]. Receivers really do need to be able to 1262 receive the form that includes the NULL because the NULL form, while 1263 not preferred, is what was observed as being generated by most 1264 implementations. Implementers should also note that if the algorithm 1265 is MD5 instead of SHA-1, then the form that omits the 1266 AlgorithmIdentifier parameters field is not allowed and the sender 1267 has to use the form where the NULL is included. 1269 The preferred encryption algorithm for S/MIME in SIP is AES as 1270 defined in RFC 3853 [10]. 1272 Observed S/MIME interoperability has been better when UAs did not 1273 attach the senders' certificates. Attaching the certificates 1274 significantly increases the size of the messages, and since it can 1275 not be relied on, it does not turn out to be useful in most 1276 situations. 1278 OPEN ISSUE: There's some implicit stuff here that should be explicit. 1279 Do you mean to recommend never attaching certs? It's probably worth 1280 mentioning the message size limit issue. What do we mean by "it 1281 cannot be relied upon"--that we can't rely on the peer sending it, or 1282 it is unreliable when the peer does send it? 1284 7. Additional Test Scenarios 1286 This section provides a non-exhaustive list of tests that 1287 implementations should perform while developing systems that use 1288 S/MIME and TLS for SIP. 1290 Much of the required behavior for inspecting certificates when using 1291 S/MIME and TLS with SIP is currently underspecified. The non- 1292 normative recommendations in this document capture the current 1293 folklore around that required behavior, guided by both related 1294 normative works such as RFC 4474 [16] (particulary, section 13.4 1295 Domain Names and Subordination) and informative works such as RFC 1296 2818 [17] section 3.1. To summarize that non-normative lore: 1297 o For S/MIME the peer's URI must appear in the subjectAltName of the 1298 peer's certifcate as a uniformResourceIdentifier field. 1299 o For TLS the peer's hostname (from the initial DNS query in the 1300 server location process RFC 3263 [3]) must appear as 1301 * an exact match in a dNSName entry in the subjectAltName if 1302 there are any dNSNames in the subjectAltName. (Wildcard 1303 matching is not allowed against these dNSName entries) 1304 * the most specific CommonName in the Subject field if there are 1305 no dNSName entries in the subjectAltName at all (which is not 1306 the same as there being no matching dNSName entries). This 1307 match can be either exact, or against an entry that uses the 1308 wildcard matching character '*' 1310 OPEN ISSUE: Are we sure all of this is truly folklore and none of it 1311 is from bona fide normative language somewhere? The true folklore 1312 portions may indicate future normative work we need to do. 1314 OPEN ISSUE: From first bullet, "peer's URI"...What URI? An AoR for 1315 the user? From or To values? Contacts? Request-URIs? For request 1316 URIs, do we need to discuss the effects of retargeting? Do we need 1317 to consider some of the current History-Info discussions? 1319 OPEN ISSUE: From second bullet: What if all you've got is an IP 1320 address? Do we disallow IPAddress entries in SubjectAltName? 1322 OPEN ISSUE: First sub-bullet (Wildcard matching is not allowed 1323 against these dNSName entries): Is there something that can be 1324 referenced here? In particular, RFC2818 explicitly allows wildcards 1325 in dNSName entries. It is not obvious to me whether the proscription 1326 against wildcards in RFC4474 should apply to general use of TLS, or 1327 just to identity. 1329 For each of these tests, an implementation will proceed past the 1330 verification point only if the certificate is "good". S/MIME 1331 protected requests presenting bad certificate data will be rejected. 1332 S/MIME protected responses presenting bad certificate information 1333 will be ignored. TLS connections involving bad certificate data will 1334 not be completed. 1336 1. S/MIME : Good peer certificate 1337 2. S/MIME : Bad peer certificate (peer URI does not appear in 1338 subjAltName) 1339 3. S/MIME : Bad peer certificate (valid authority chain does not 1340 end at a trusted CA) 1341 4. S/MIME : Bad peer certificate (the current time does not fall 1342 within the period of validity) 1343 5. S/MIME : Bad peer certificate (certificate or cert in authority 1344 chain has been revoked) 1345 6. TLS : Good peer certificate (hostname appears in dNSName in 1346 subjAltName) 1347 7. TLS : Good peer certificate (no dNSNames in subjAltName, 1348 hostname appears in CN of Subject) 1349 8. TLS : Bad peer certificate (no match in dNSNames or in the 1350 Subject CN) 1351 9. TLS : Bad peer certificate (valid authority chain does not end 1352 at a trusted CA) 1353 10. TLS : Bad peer certificate (the current time does not fall 1354 within the period of validity) 1355 11. TLS : Bad peer certificate (certificate or cert in authority 1356 chain has been revoked) 1358 OPEN ISSUE: What about cases where the basic constraints or allowed 1359 uses are not appropriate? Is it worth putting in cases around self- 1360 signed certs? (i.e. self-signed cert, explicitly trusted, not 1361 trusted, etc.) How about cases where one or more certs in the chain 1362 to the root were not provided and not available through other means? 1363 Those seem like sensible cases to either include or explain why they 1364 aren't included. The self-signed cert is definitely a popular case 1365 among developers. 1367 8. IANA Considerations 1369 No IANA actions are required. 1371 9. Acknowledgments 1373 Many thanks to the developers of all the open source software used to 1374 create these call flows. This includes the underlying crypto and TLS 1375 software used from openssl.org, the SIP stack from 1376 www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. 1377 The TLS flow dumps were done with SSLDump from 1378 http://www.rtfm.com/ssldump. The book "SSL and TLS" [18] was a huge 1379 help in developing the code for these flows. It's sad there is no 1380 second edition. 1382 Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat 1383 Chan, and Lyndsay Campbell who all helped find and correct mistakes 1384 in this document. 1386 Vijay Gurbani and Alan Jeffrey contributed much of the additional 1387 test scenario content. 1389 10. Security Considerations 1391 Implementers must never use any of the certificates provided in this 1392 document in anything but a test environment. Installing the CA root 1393 certificates used in this document as a trusted root in operational 1394 software would completely destroy the security of the system while 1395 giving the user the impression that the system was operating 1396 securely. 1398 This document recommends some things that implementers might test or 1399 verify to improve the security of their implementations. It is 1400 impossible to make a comprehensive list of these, and this document 1401 only suggests some of the most common mistakes that have been seen at 1402 the SIPit interoperability events. Just because an implementation 1403 does everything this document recommends does not make it secure. 1405 This document does not show the messages needed to check Certificate 1406 Revocation Lists (see RFC 5280 [4]) as that is not part of the SIP 1407 call flow. 1409 OPEN ISSUE: We should probably say something about CRLs. We need to 1410 get consensus on whether we want to recommend a method for retrieving 1411 CRLs. We could explicitly state that these are assumed to be 1412 retrieved out-of-band. Should they be retrieved by HTTP by some 1413 maintenance procedure? Via OCSP? 1415 11. Changelog 1417 (RFC Editor: remove this section) 1419 -00 to -01 1420 * Addition of OPEN ISSUES. 1421 * Numerous minor edits from mailing list feedback. 1422 to -00 1423 * Changed RFC 3369 references to RFC 3852. 1424 * Changed draft-ietf-sip-identity references to RFC 4474. 1425 * Added an ASN.1 dump of CMS signed content where SHA-1 1426 parameters are omitted instead of being set to ASN.1 NULL. 1427 * Accept headers added to messages. 1428 * User and domain certificates are generated with EKU as 1429 specified in Draft SIP EKU [13]. 1430 * Message content that is shown is computed using certificates 1431 generated with EKU. 1432 * Message dump archive returned. 1433 * Message archive contains messages formed with and without EKU 1434 certificates. 1435 prior to -00 1436 * Incorporated the Test cases from Vijay Gurbani's and Alan 1437 Jeffrey's Use of TLS in SIP draft 1438 * Began to capture the folklore around where identities are 1439 carried in certificates for use with SIP 1440 * Removed the message dump archive pending verification (will 1441 return in -02) 1443 12. References 1445 12.1. Normative References 1447 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1448 Levels", BCP 14, RFC 2119, March 1997. 1450 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1451 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1452 Session Initiation Protocol", RFC 3261, June 2002. 1454 [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1455 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1457 [4] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 1458 R., and W. Polk, "Internet X.509 Public Key Infrastructure 1459 Certificate and Certificate Revocation List (CRL) Profile", 1460 RFC 5280, May 2008. 1462 [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1463 Protocol Version 1.2", RFC 5246, August 2008. 1465 [6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1466 T. Wright, "Transport Layer Security (TLS) Extensions", 1467 RFC 3546, June 2003. 1469 [7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1470 Transport Layer Security (TLS)", RFC 3268, June 2002. 1472 [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1473 (S/MIME) Version 3.1 Message Specification", RFC 3851, 1474 July 2004. 1476 [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 1477 July 2004. 1479 [10] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1480 Requirement for the Session Initiation Protocol (SIP)", 1481 RFC 3853, July 2004. 1483 [11] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 1484 RFC 3370, August 2002. 1486 [12] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and 1487 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test 1488 Messages", RFC 4475, May 2006. 1490 [13] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) 1491 for Session Initiation Protocol (SIP) X.509 Certificates", 1492 draft-ietf-sip-eku-04 (work in progress), April 2009. 1494 12.2. Informative References 1496 [14] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1497 July 2005. 1499 [15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1500 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1501 Instant Messaging", RFC 3428, December 2002. 1503 [16] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1504 Identity Management in the Session Initiation Protocol (SIP)", 1505 RFC 4474, August 2006. 1507 [17] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1509 [18] Rescorla, E., "SSL and TLS - Designing and Building Secure 1510 Systems", 2001. 1512 [19] Rescorla, E., "SSLDump manpage". 1514 Appendix A. Making Test Certificates 1516 These scripts allow you to make certificates for test purposes. The 1517 certificates will all share a common CA root so that everyone running 1518 these scripts can have interoperable certificates. WARNING - these 1519 certificates are totally insecure and are for test purposes only. 1520 All the CA created by this script share the same private key to 1521 facilitate interoperability testing, but this totally breaks the 1522 security since the private key of the CA is well known. 1524 The instructions assume a Unix-like environment with openssl 1525 installed, but openssl does work in Windows too. OpenSSL version 1526 0.9.8j was used to generate the certificates used in this document. 1527 Make sure you have openssl installed by trying to run "openssl". Run 1528 the makeCA script found in Appendix A.1; this creates a subdirectory 1529 called demoCA. If the makeCA script cannot find where your openssl 1530 is installed you will have to set an environment variable called 1531 OPENSSLDIR to whatever directory contains the file openssl.cnf. You 1532 can find this with a "locate openssl.cnf". You are now ready to make 1533 certificates. 1535 To create certs for use with TLS, run the makeCert script found in 1536 Appendix A.2 with the fully qualified domain name of the proxy you 1537 are making the certificate for. For example, "makeCert 1538 host.example.net". This will generate a private key and a 1539 certificate. The private key will be left in a file named 1540 domain_key_example.net.pem in pem format. The certificate will be in 1541 domain_cert_example.net.pem. Some programs expect both the 1542 certificate and private key combined together in a PKCS12 format 1543 file. This is created by the script and left in a file named 1544 example.net.p12. Some programs expect this file to have a .pfx 1545 extension instead of .p12 - just rename the file if needed. A file 1546 with a certificate signing request, called example.net.csr, is also 1547 created and can be used to get the certificate signed by another CA. 1549 A second argument indicating the number of days for which the 1550 certificate should be valid can be passed to the makeCert script. It 1551 is possible to make an expired certificate using the command 1552 "makeCert host.example.net 0". 1554 Anywhere that a password is used to protect a certificate, the 1555 password is set to the string "password". 1557 The root certificate for the CA is in the file 1558 root_cert_fluffyCA.pem. 1560 For things that need DER format certificates, a certificate can be 1561 converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM 1562 -out cert.der -outform DER". 1564 Some programs expect certificates in PKCS#7 format (with a file 1565 extension of .p7c). You can convert these from PEM format to PKCS#7 1566 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ 1567 cacert.pem -outform DER -out cert.p7c" 1569 IE (version 8), Outlook Express (version 6), and Firefox (version 1570 3.5) can import and export .p12 files and .p7c files. You can 1571 convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in 1572 cert.p7c -inform DER -outform PEM -out cert.pem". 1574 The private key can be converted to pkcs8 format with "openssl pkcs8 1575 -in a_key.pem -topk8 -outform DER -out a_key.p8c" 1577 OPEN ISSUE: The information in this section needs to be verified with 1578 the latest software versions. How to do conversions between 1579 supported types needs to be updated accordingly. 1581 In general, a TLS client will just need the root certificate of the 1582 CA. A TLS server will need its private key and its certificate. 1583 These could be in two PEM files, a single file with both certificate 1584 and private key PEM sections, or a single .p12 file. An S/MIME 1585 program will need its private key and certificate, the root 1586 certificate of the CA, and the certificate for every other user it 1587 communicates with. 1589 A.1. makeCA script 1591 #!/bin/sh 1592 set -x 1594 rm -rf demoCA 1596 mkdir demoCA 1597 mkdir demoCA/certs 1598 mkdir demoCA/crl 1599 mkdir demoCA/newcerts 1600 mkdir demoCA/private 1601 echo "01" > demoCA/serial 1602 hexdump -n 4 -e '4/1 "%04u"' /dev/random > demoCA/serial 1603 touch demoCA/index.txt 1604 # You may need to modify this for where your default file is 1605 # you can find where yours in by typing "openssl ca" 1606 for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do 1607 CONF=${OPENSSLDIR:=$D}/openssl.cnf 1608 [ -f ${CONF} ] && break 1609 done 1611 CONF=${OPENSSLDIR}/openssl.cnf 1613 if [ ! -f $CONF ]; then 1614 echo "Can not find file $CONF - set your OPENSSLDIR variable" 1615 exit 1616 fi 1617 cp $CONF openssl.cnf 1619 cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem <