idnits 2.17.1 draft-ietf-sipcore-sec-flows-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 8, 2010) is 4908 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: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 1132, but not defined ** Obsolete normative reference: RFC 2560 (ref. '2') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 4366 (ref. '7') (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5751 (ref. '8') (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 4474 (ref. '11') (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (ref. '13') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '18') (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 4 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: Informational K. Ono 5 Expires: May 12, 2011 Columbia University 6 R. Sparks 7 B. Hibbard, Ed. 8 Tekelec 9 November 8, 2010 11 Example call flows using Session Initiation Protocol (SIP) security 12 mechanisms 13 draft-ietf-sipcore-sec-flows-04 15 Abstract 17 This document shows example call flows demonstrating the use of 18 Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail 19 Extensions (S/MIME) in Session Initiation Protocol (SIP). It also 20 provides information that helps implementers build interoperable SIP 21 software. To help facilitate interoperability testing, it includes 22 certificates used in the example call flows and processes to create 23 certificates for testing. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 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 12, 2011. 48 Copyright Notice 49 Copyright (c) 2010 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 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 68 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 9 69 3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 11 70 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 11 71 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13 72 4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 14 73 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 14 74 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20 75 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22 76 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 27 77 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 81 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 83 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 84 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 85 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35 86 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36 87 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39 88 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42 89 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42 90 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49 91 B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 57 92 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 63 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 95 1. Introduction 97 This document is informational and is not normative on any aspect of 98 SIP. 100 SIP with TLS (RFC 5246 [13]) implementations are becoming very 101 common. Several implementations of the S/MIME (RFC 5751 [8]) portion 102 of SIP (RFC 3261 [3]) are also becoming available. After several 103 interoperability events, it is clear that it is difficult to write 104 these systems without any test vectors or examples of "known good" 105 messages to test against. Furthermore, testing at the events is 106 often hindered due to the lack of a commonly trusted certificate 107 authority to sign the certificates used in the events. This document 108 addresses both of these issues by providing messages that give 109 detailed examples that implementers can use for comparison and that 110 can also be used for testing. In addition, this document provides a 111 common certificate and private key that can be used to set up a mock 112 Certificate Authority (CA) that can be used during the SIP 113 interoperability events. Certificate requests from the users will be 114 signed by the private key of the mock CA. The document also provides 115 some hints and clarifications for implementers. 117 A simple SIP call flow using SIPS URIs and TLS is shown in Section 3. 118 The certificates for the hosts used are shown in Section 2.2, and the 119 CA certificates used to sign these are shown in Section 2.1. 121 The text from Section 4.1 through Section 4.3 shows some simple SIP 122 call flows using S/MIME to sign and encrypt the body of the message. 123 The user certificates used in these examples are shown in 124 Section 2.3. These host certificates are signed with the same mock 125 CA private key. 127 Section 5 presents a partial list of items that implementers should 128 consider in order to implement systems that will interoperate. 130 Scripts and instructions to make certificates that can be used for 131 interoperability testing are presented in Appendix A, along with 132 methods for converting these to various formats. The certificates 133 used while creating the examples and test messages in this document 134 are made available in Appendix B. 136 Binary copies of various messages in this document that can be used 137 for testing appear in Appendix C. 139 2. Certificates 140 2.1. CA Certificates 142 The certificate used by the CA to sign the other certificates is 143 shown below. This is a X509v3 certificate. Note that the X.509v3 144 Basic Constraints in the certificate allows it to be used as a CA, 145 certificate authority. This certificate is not used directly in the 146 TLS call flow; it is used only to verify user and host certificates. 148 Version: 3 (0x2) 149 Serial Number: 150 96:a3:84:17:4e:ef:8a:4c 151 Signature Algorithm: sha1WithRSAEncryption 152 Issuer: C=US, ST=California, L=San Jose, O=sipit, 153 OU=Sipit Test Certificate Authority 154 Validity 155 Not Before: May 10 20:54:48 2010 GMT 156 Not After : Apr 16 20:54:48 2110 GMT 157 Subject: C=US, ST=California, L=San Jose, O=sipit, 158 OU=Sipit Test Certificate Authority 159 Subject Public Key Info: 160 Public Key Algorithm: rsaEncryption 161 RSA Public Key: (1024 bit) 162 Modulus (1024 bit): 163 00:c6:4d:2b:8b:79:14:07:db:c7:61:88:98:4f:a2: 164 7c:e3:61:80:fb:27:05:18:ed:3c:c9:0d:e5:f1:dc: 165 92:4e:eb:ce:77:91:4b:e7:f3:68:60:b0:40:00:6f: 166 74:5b:4e:1d:c9:97:c8:70:4a:66:fc:13:46:aa:d2: 167 98:b0:3e:9a:86:de:3c:20:d1:0b:35:a2:2d:e6:92: 168 e6:03:49:b0:db:4c:62:2f:59:86:94:20:69:69:7a: 169 0a:16:5a:d5:01:a5:08:06:29:6e:85:a6:ae:a1:01: 170 0b:f6:1f:53:c5:95:b0:6e:b0:b4:8d:0e:f9:e9:cb: 171 5d:7a:44:21:14:ec:9a:a8:ad 172 Exponent: 65537 (0x10001) 173 X509v3 extensions: 174 X509v3 Subject Key Identifier: 175 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C 176 X509v3 Authority Key Identifier: 177 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C 178 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 179 OU=Sipit Test Certificate Authority 180 serial:96:A3:84:17:4E:EF:8A:4C 182 X509v3 Basic Constraints: 183 CA:TRUE 184 Signature Algorithm: sha1WithRSAEncryption 185 2f:08:4d:b4:01:9b:79:ff:af:c8:ce:e5:5d:30:3c:fa:99:3a: 186 48:ba:1b:28:f8:7c:ea:d6:4a:17:85:82:e6:49:81:1b:24:bf: 187 01:ff:fa:fc:55:12:2b:07:b8:c0:39:fa:10:73:88:59:56:b7: 188 7f:96:01:30:af:89:0f:0a:6d:4e:ae:d8:04:ae:94:d4:67:78: 189 2a:c4:36:86:4b:e1:4c:a6:6d:46:d9:2c:73:0f:da:fe:8f:ba: 190 02:10:09:b7:1b:c6:13:a9:90:a9:02:15:60:61:32:79:c5:e8: 191 2b:d8:e4:b1:ba:eb:c7:7f:19:0c:69:b1:c6:92:af:ee:1c:74: 192 55:d5 194 The ASN.1 parse of the CA certificate is shown below. 196 0:l= 822 cons: SEQUENCE 197 4:l= 671 cons: SEQUENCE 198 8:l= 3 cons: cont [ 0 ] 199 10:l= 1 prim: INTEGER :02 200 13:l= 9 prim: INTEGER :96A384174EEF8A4C 201 24:l= 13 cons: SEQUENCE 202 26:l= 9 prim: OBJECT :sha1WithRSAEncryption 203 37:l= 0 prim: NULL 204 39:l= 112 cons: SEQUENCE 205 41:l= 11 cons: SET 206 43:l= 9 cons: SEQUENCE 207 45:l= 3 prim: OBJECT :countryName 208 50:l= 2 prim: PRINTABLESTRING :US 209 54:l= 19 cons: SET 210 56:l= 17 cons: SEQUENCE 211 58:l= 3 prim: OBJECT :stateOrProvinceName 212 63:l= 10 prim: PRINTABLESTRING :California 213 75:l= 17 cons: SET 214 77:l= 15 cons: SEQUENCE 215 79:l= 3 prim: OBJECT :localityName 216 84:l= 8 prim: PRINTABLESTRING :San Jose 217 94:l= 14 cons: SET 218 96:l= 12 cons: SEQUENCE 219 98:l= 3 prim: OBJECT :organizationName 220 103:l= 5 prim: PRINTABLESTRING :sipit 221 110:l= 41 cons: SET 222 112:l= 39 cons: SEQUENCE 223 114:l= 3 prim: OBJECT :organizationalUnitName 224 119:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 225 153:l= 32 cons: SEQUENCE 226 155:l= 13 prim: UTCTIME :100510205448Z 227 170:l= 15 prim: GENERALIZEDTIME :21100416205448Z 228 187:l= 112 cons: SEQUENCE 229 189:l= 11 cons: SET 230 191:l= 9 cons: SEQUENCE 231 193:l= 3 prim: OBJECT :countryName 232 198:l= 2 prim: PRINTABLESTRING :US 233 202:l= 19 cons: SET 234 204:l= 17 cons: SEQUENCE 235 206:l= 3 prim: OBJECT :stateOrProvinceName 236 211:l= 10 prim: PRINTABLESTRING :California 237 223:l= 17 cons: SET 238 225:l= 15 cons: SEQUENCE 239 227:l= 3 prim: OBJECT :localityName 240 232:l= 8 prim: PRINTABLESTRING :San Jose 241 242:l= 14 cons: SET 242 244:l= 12 cons: SEQUENCE 243 246:l= 3 prim: OBJECT :organizationName 244 251:l= 5 prim: PRINTABLESTRING :sipit 245 258:l= 41 cons: SET 246 260:l= 39 cons: SEQUENCE 247 262:l= 3 prim: OBJECT :organizationalUnitName 248 267:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 249 301:l= 159 cons: SEQUENCE 250 304:l= 13 cons: SEQUENCE 251 306:l= 9 prim: OBJECT :rsaEncryption 252 317:l= 0 prim: NULL 253 319:l= 141 prim: BIT STRING 254 00 30 81 89 02 81 81 00-c6 4d 2b 8b 79 14 07 db .0.......M+.y... 255 c7 61 88 98 4f a2 7c e3-61 80 fb 27 05 18 ed 3c .a..O.|.a..'...< 256 c9 0d e5 f1 dc 92 4e eb-ce 77 91 4b e7 f3 68 60 ......N..w.K..h` 257 b0 40 00 6f 74 5b 4e 1d-c9 97 c8 70 4a 66 fc 13 .@.ot[N....pJf.. 258 46 aa d2 98 b0 3e 9a 86-de 3c 20 d1 0b 35 a2 2d F....>...< ..5.- 259 e6 92 e6 03 49 b0 db 4c-62 2f 59 86 94 20 69 69 ....I..Lb/Y.. ii 260 7a 0a 16 5a d5 01 a5 08-06 29 6e 85 a6 ae a1 01 z..Z.....)n..... 261 0b f6 1f 53 c5 95 b0 6e-b0 b4 8d 0e f9 e9 cb 5d ...S...n.......] 262 7a 44 21 14 ec 9a a8 ad-02 03 01 00 01 zD!.......... 263 463:l= 213 cons: cont [ 3 ] 264 466:l= 210 cons: SEQUENCE 265 469:l= 29 cons: SEQUENCE 266 471:l= 3 prim: OBJECT :X509v3 Subject Key Identifier 267 476:l= 22 prim: OCTET STRING 268 04 14 38 ad 80 84 e2 e0-16 6b 93 9f 89 f8 46 51 ..8......k....FQ 269 67 2c da 8d 80 9c g,.... 270 500:l= 162 cons: SEQUENCE 271 503:l= 3 prim: OBJECT :X509v3 Authority Key Identifier 272 508:l= 154 prim: OCTET STRING 273 30 81 97 80 14 38 ad 80-84 e2 e0 16 6b 93 9f 89 0....8......k... 274 f8 46 51 67 2c da 8d 80-9c a1 74 a4 72 30 70 31 .FQg,.....t.r0p1 275 0b 30 09 06 03 55 04 06-13 02 55 53 31 13 30 11 .0...U....US1.0. 276 06 03 55 04 08 13 0a 43-61 6c 69 66 6f 72 6e 69 ..U....Californi 277 61 31 11 30 0f 06 03 55-04 07 13 08 53 61 6e 20 a1.0...U....San 278 4a 6f 73 65 31 0e 30 0c-06 03 55 04 0a 13 05 73 Jose1.0...U....s 279 69 70 69 74 31 29 30 27-06 03 55 04 0b 13 20 53 ipit1)0'..U... S 280 69 70 69 74 20 54 65 73-74 20 43 65 72 74 69 66 ipit Test Certif 281 69 63 61 74 65 20 41 75-74 68 6f 72 69 74 79 82 icate Authority. 282 09 00 96 a3 84 17 4e ef-8a 4c ......N..L 283 665:l= 12 cons: SEQUENCE 284 667:l= 3 prim: OBJECT :X509v3 Basic Constraints 285 672:l= 5 prim: OCTET STRING 286 30 03 01 01 ff 0.... 287 679:l= 13 cons: SEQUENCE 288 681:l= 9 prim: OBJECT :sha1WithRSAEncryption 289 692:l= 0 prim: NULL 290 694:l= 129 prim: BIT STRING 291 00 2f 08 4d b4 01 9b 79-ff af c8 ce e5 5d 30 3c ./.M...y.....]0< 292 fa 99 3a 48 ba 1b 28 f8-7c ea d6 4a 17 85 82 e6 ..:H..(.|..J.... 293 49 81 1b 24 bf 01 ff fa-fc 55 12 2b 07 b8 c0 39 I..$.....U.+...9 294 fa 10 73 88 59 56 b7 7f-96 01 30 af 89 0f 0a 6d ..s.YV....0....m 295 4e ae d8 04 ae 94 d4 67-78 2a c4 36 86 4b e1 4c N......gx*.6.K.L 296 a6 6d 46 d9 2c 73 0f da-fe 8f ba 02 10 09 b7 1b .mF.,s.......... 297 c6 13 a9 90 a9 02 15 60-61 32 79 c5 e8 2b d8 e4 .......`a2y..+.. 298 b1 ba eb c7 7f 19 0c 69-b1 c6 92 af ee 1c 74 55 .......i......tU 299 d5 . 301 2.2. Host Certificates 303 The certificate for the host example.com is shown below. Note that 304 the Subject Alternative Name is set to example.com and is a DNS type. 305 The certificates for the other hosts are shown in Appendix B. 307 Version: 3 (0x2) 308 Serial Number: 309 49:02:11:01:84:01:5e 310 Signature Algorithm: sha1WithRSAEncryption 311 Issuer: C=US, ST=California, L=San Jose, O=sipit, 312 OU=Sipit Test Certificate Authority 313 Validity 314 Not Before: May 11 20:22:56 2010 GMT 315 Not After : Apr 17 20:22:56 2110 GMT 316 Subject: C=US, ST=California, L=San Jose, O=sipit, CN=example.com 317 Subject Public Key Info: 318 Public Key Algorithm: rsaEncryption 319 RSA Public Key: (2048 bit) 320 Modulus (2048 bit): 321 00:d1:da:2d:b3:77:42:5f:00:99:1e:f4:b6:6c:51: 322 51:bb:0b:20:b3:f9:c7:93:97:ff:02:ac:81:92:d5: 323 a1:1c:c9:24:16:46:59:d1:92:1d:0d:bf:66:3a:66: 324 c6:5c:aa:3b:07:21:bf:45:40:63:94:20:30:81:e3: 325 5f:aa:e6:c7:60:aa:6c:22:8f:47:64:94:9a:71:b1: 326 18:51:2e:81:e9:a3:32:64:b4:38:f4:35:eb:da:3f: 327 6f:82:f1:7a:4d:dc:e1:c5:e3:05:1b:c1:78:83:48: 328 d4:64:6e:98:4b:4e:ce:85:7f:0d:62:5d:1b:8a:72: 329 c1:9d:bd:85:dc:37:f0:a7:c1:cc:60:ad:b7:39:cb: 330 20:ff:89:9f:65:06:35:93:5b:61:d0:04:1b:a3:d4: 331 70:57:d9:d5:c0:52:f4:70:0d:ca:f6:0a:42:8b:52: 332 47:e2:a1:cb:0e:17:9d:d6:ea:41:e5:6a:5a:29:a8: 333 11:af:52:65:a4:79:8e:4f:ef:fc:ec:a7:3a:ca:56: 334 45:b7:87:dd:e9:c7:f9:b7:f7:e8:12:f8:b5:a2:08: 335 ce:9e:c4:cc:70:85:a6:e9:d3:cc:76:6d:11:67:b0: 336 00:14:a0:55:a6:63:36:fa:c2:e0:bd:45:3c:14:b0: 337 ed:88:f6:19:14:d6:c3:a2:79:ca:be:69:52:d0:78: 338 f1:fd 340 Exponent: 65537 (0x10001) 341 X509v3 extensions: 342 X509v3 Subject Alternative Name: 343 DNS:example.com, URI:sip:example.com 344 X509v3 Basic Constraints: 345 CA:FALSE 346 X509v3 Subject Key Identifier: 347 AC:96:21:E6:54:7D:E7:1E:A1:F1:58:86:D9:5F:AD:CB:DC:F1:66:92 348 X509v3 Authority Key Identifier: 349 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C 350 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 351 OU=Sipit Test Certificate Authority 352 serial:96:A3:84:17:4E:EF:8A:4C 354 X509v3 Key Usage: 355 Digital Signature, Non Repudiation, Key Encipherment 356 X509v3 Extended Key Usage: 357 TLS Web Server Authentication, 1.3.6.1.5.5.7.3.20 358 Signature Algorithm: sha1WithRSAEncryption 359 52:ae:66:df:55:1d:99:3c:9e:17:09:3d:4a:59:19:88:8f:df: 360 ee:2b:75:ca:c5:b3:36:ce:37:10:5f:6f:0e:f2:4f:2a:62:34: 361 19:5c:7a:3e:a3:cb:99:ae:a7:7c:a6:34:59:a7:43:a3:dc:ef: 362 e5:80:86:3f:21:21:95:5b:74:4c:23:e3:1e:1d:14:43:86:48: 363 b9:f5:c9:f0:a9:48:a3:1e:52:91:56:d5:ed:b2:56:52:8f:f4: 364 02:e8:4c:80:83:e6:0c:aa:e0:d6:b0:5c:75:d2:90:39:52:8b: 365 b5:48:dc:68:bc:e5:5c:5c:dd:43:34:af:14:3a:85:60:a3:46: 366 17:69 368 The example host certificate above, as well as all the others 369 presented in this document, are signed directly by a root CA. These 370 certificate chains have a length equal to two: the root CA and the 371 host certificate. Non-root CAs exist and may also sign certificates. 372 The certificate chains presented by hosts with certificates signed by 373 non-root CAs will have a length greater than two. For more details 374 on how certificate chains are validated, see section 6.1.4 of RFC 375 5280 [14]. 377 2.3. User Certificates 379 User certificates are used by many applications to establish user 380 identity. The user certificate for fluffy@example.com is shown 381 below. Note that the Subject Alternative Name has a list of names 382 with different URL types such as a sip, im, or pres URL. This is 383 necessary for interoperating with a CPIM gateway. In this example, 384 example.com is the domain for fluffy. The message could be coming 385 from any host in *.example.com, and the AOR in the user certificate 386 would still be the same. The others are shown in Appendix B.1. 388 These certificates make use of the EKU extension discussed in RFC 389 5924 [15]. Note that the X509v3 Extended Key Usage attribute refers 390 to the SIP OID introduced in RFC 5924 [15], which is 391 1.3.6.1.5.5.7.3.20 393 Version: 3 (0x2) 394 Serial Number: 395 49:02:11:01:84:01:5c 396 Signature Algorithm: sha1WithRSAEncryption 397 Issuer: C=US, ST=California, L=San Jose, O=sipit, 398 OU=Sipit Test Certificate Authority 399 Validity 400 Not Before: May 11 20:22:55 2010 GMT 401 Not After : Apr 17 20:22:55 2110 GMT 402 Subject: C=US, ST=California, L=San Jose, O=sipit, 403 CN=fluffy@example.com 404 Subject Public Key Info: 405 Public Key Algorithm: rsaEncryption 406 RSA Public Key: (2048 bit) 407 Modulus (2048 bit): 408 00:d5:9d:cf:3e:bd:83:4e:2d:df:c9:bf:86:57:cf: 409 0d:26:a9:e9:08:35:45:e7:5f:ae:a3:5d:60:d1:3c: 410 2f:6f:db:92:49:fd:05:12:68:6c:d9:ca:66:2d:02: 411 e2:20:8a:8a:10:0a:a1:db:ee:b3:6b:c5:39:e6:4a: 412 49:b1:41:00:f3:f8:91:07:17:83:40:a6:bc:68:99: 413 a6:32:08:4f:4f:34:64:ae:9f:b1:0f:9c:d5:14:96: 414 fb:40:62:84:85:b7:ba:38:29:cc:1d:ba:19:83:d9: 415 59:21:ba:1e:4b:04:53:f6:aa:a6:68:4d:9a:5f:36: 416 90:4d:ae:01:df:58:f2:89:ec:51:c9:a1:20:65:a9: 417 de:5c:c9:f3:57:7f:76:56:0d:23:fc:d6:26:e7:01: 418 25:75:2a:e4:26:3b:df:db:35:61:02:0c:0f:14:68: 419 18:70:13:d6:41:0a:a4:d1:5b:99:7b:32:60:78:7b: 420 a8:95:71:80:b5:df:63:fc:ca:f4:9e:f7:a5:a0:0c: 421 13:6d:55:ad:17:9d:34:f2:80:66:03:86:a0:a7:83: 422 52:0e:ea:b7:49:ea:75:e4:c9:d8:b7:72:37:dd:30: 423 b1:33:d4:56:26:e8:33:70:c5:97:db:ba:63:89:3f: 424 9c:65:45:51:18:a8:fb:96:14:09:f0:8e:55:01:f7: 425 ad:99 426 Exponent: 65537 (0x10001) 427 X509v3 extensions: 428 X509v3 Subject Alternative Name: 429 URI:sip:fluffy@example.com, URI:im:fluffy@example.com, 430 URI:pres:fluffy@example.com 431 X509v3 Basic Constraints: 432 CA:FALSE 433 X509v3 Subject Key Identifier: 434 DD:D5:75:00:3E:4C:15:7C:9C:49:C0:07:10:CB:CA:4E:07:A1:CE:4F 435 X509v3 Authority Key Identifier: 437 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C 438 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 439 OU=Sipit Test Certificate Authority 440 serial:96:A3:84:17:4E:EF:8A:4C 442 X509v3 Key Usage: 443 Digital Signature, Non Repudiation, Key Encipherment 444 X509v3 Extended Key Usage: 445 E-mail Protection, 1.3.6.1.5.5.7.3.20 446 Signature Algorithm: sha1WithRSAEncryption 447 9c:c5:bc:04:88:81:19:35:2b:ba:be:d4:02:8d:41:25:45:95: 448 8b:cf:f6:a4:95:bc:5b:d8:eb:87:6a:48:29:34:6c:ef:87:e0: 449 e3:73:ca:3a:dd:a3:d2:d6:74:5b:cc:00:7f:28:fc:e4:07:b6: 450 5c:e8:72:ea:ee:7d:40:99:58:26:b0:7d:5b:0d:36:e2:9e:b1: 451 40:8d:fc:af:f0:f2:60:d8:36:46:7e:a8:fa:2a:47:52:35:71: 452 11:ab:ec:fb:28:cf:fa:1d:a9:5d:8b:72:29:67:1d:be:fb:e3: 453 bd:5d:c9:57:6d:75:d5:40:b5:77:52:69:b6:c4:1f:ec:03:60: 454 1e:a1 456 Versions of these certificates that do not make use of EKU are also 457 included in Appendix B.2 459 3. Callflow with Message Over TLS 461 3.1. TLS with Server Authentication 463 The flow below shows the edited SSLDump output of the host 464 example.com forming a TLS RFC 5246 [13] connection to example.net. 465 In this example mutual authentication is not used. Note that the 466 client proposed three protocol suites including 467 TLS_RSA_WITH_AES_128_CBC_SHA defined in RFC 5246 [13]. The 468 certificate returned by the server contains a Subject Alternative 469 Name that is set to example.net. A detailed discussion of TLS can be 470 found in SSL and TLS [21]. For more details on the SSLDump tool, see 471 the SSLDump Manual [22]. 473 This example does not use the Server Extended Hello (see RFC 4366 474 [7]). 476 New TCP connection #1: example.com(50713) <-> example.net(5061) 477 1 1 0.0004 (0.0004) C>SV3.1(101) Handshake 478 ClientHello 479 Version 3.1 480 random[32]= 481 4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3 482 ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec 484 cipher suites 485 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 486 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 487 TLS_DHE_RSA_WITH_AES_256_SHA 488 TLS_RSA_WITH_AES_256_CBC_SHA 489 TLS_DSS_RSA_WITH_AES_256_SHA 490 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 491 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 492 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 493 TLS_RSA_WITH_AES_128_CBC_SHA 494 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 495 TLS_ECDHE_RSA_WITH_DES_192_CBC3_SHA 496 TLS_ECDH_RSA_WITH_DES_192_CBC3_SHA 497 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 498 TLS_RSA_WITH_3DES_EDE_CBC_SHA 499 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 500 TLS_ECDHE_RSA_WITH_RC4_128_SHA 501 TLS_ECDH_RSA_WITH_RC4_128_SHA 502 TLS_RSA_WITH_RC4_128_SHA 503 TLS_RSA_WITH_RC4_128_MD5 504 TLS_DHE_RSA_WITH_DES_CBC_SHA 505 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 506 TLS_RSA_WITH_DES_CBC_SHA 507 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 508 TLS_DHE_DSS_WITH_DES_CBC_SHA 509 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 510 TLS_RSA_EXPORT_WITH_RC4_40_MD5 511 compression methods 512 NULL 513 1 2 0.0012 (0.0007) S>CV3.1(48) Handshake 514 ServerHello 515 Version 3.1 516 random[32]= 517 4c 09 5b a7 30 87 74 c7 16 98 24 d5 af 35 17 a7 518 ef c3 78 0c 94 d4 94 d2 7b a6 3f 40 04 25 f6 e0 519 session_id[0]= 521 cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA 522 compressionMethod NULL 523 1 3 0.0012 (0.0000) S>CV3.1(1858) Handshake 524 Certificate 525 1 4 0.0012 (0.0000) S>CV3.1(14) Handshake 526 CertificateRequest 527 certificate_types rsa_sign 528 certificate_types dss_sign 529 certificate_types unknown value 530 ServerHelloDone 531 1 5 0.0043 (0.0031) C>SV3.1(7) Handshake 532 Certificate 533 1 6 0.0043 (0.0000) C>SV3.1(262) Handshake 534 ClientKeyExchange 535 1 7 0.0043 (0.0000) C>SV3.1(1) ChangeCipherSpec 536 1 8 0.0043 (0.0000) C>SV3.1(48) Handshake 537 1 9 0.0129 (0.0085) S>CV3.1(170) Handshake 538 1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec 539 1 11 0.0129 (0.0000) S>CV3.1(48) Handshake 540 1 12 0.0134 (0.0005) C>SV3.1(32) application_data 541 1 13 0.0134 (0.0000) C>SV3.1(496) application_data 542 1 14 0.2150 (0.2016) S>CV3.1(32) application_data 543 1 15 0.2150 (0.0000) S>CV3.1(336) application_data 544 1 16 12.2304 (12.0154) S>CV3.1(32) Alert 545 1 12.2310 (0.0005) S>C TCP FIN 546 1 17 12.2321 (0.0011) C>SV3.1(32) Alert 548 3.2. MESSAGE Transaction Over TLS 550 Once the TLS session is set up, the following MESSAGE request (as 551 defined in RFC 3428 [6] is sent from fluffy@example.com to 552 kumiko@example.net. Note that the URI has a SIPS URL and that the 553 VIA indicates that TLS was used. In order to format this document, 554 the convention from RFC 4475 [20] is used to break long 555 lines. The actual message does not contain the linebreaks contained 556 within those tags. 558 MESSAGE sips:kumiko@example.net:5061 SIP/2.0 559 560 Via: SIP/2.0/TLS 192.0.2.2:15001; 561 branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-; 562 rport=50713 563 564 Max-Forwards: 70 565 To: 566 From: ;tag=10f47d62 567 Call-ID: ODU5YTQzYTMyYjNkZDAyODcyOGJiMWNmOWZmZmY2MGU. 568 CSeq: 4308 MESSAGE 569 570 Accept: multipart/signed, text/plain, application/pkcs7-mime, 571 application/sdp, multipart/alternative 572 573 Content-Type: text/plain 574 Content-Length: 6 576 Hello! 578 When a UA goes to send a message to example.com, the UA can see if it 579 already has a TLS connection to example.com and if it does, it may 580 send the message over this connection. A UA should have some scheme 581 for reusing connections as opening a new TLS connection for every 582 message results in awful performance. Implementers are encouraged to 583 read RFC 5923 [17] and RFC 3263 [4]. 585 The response is sent from example.net to example.com over the same 586 TLS connection. It is shown below. 588 SIP/2.0 200 OK 589 590 Via: SIP/2.0/TLS 192.0.2.2:15001; 591 branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-; 592 rport=50713 593 594 To: ;tag=a0d41548 595 From: ;tag=10f47d62 596 Call-ID: ODU5YTQzYTMyYjNkZDAyODcyOGJiMWNmOWZmZmY2MGU. 597 CSeq: 4308 MESSAGE 598 Content-Length: 0 600 4. Callflow with S/MIME-secured Message 602 4.1. MESSAGE Request with Signed Body 604 Below is an example of a signed message. The values on the Content- 605 Type line (multipart/signed) and on the Content-Disposition line have 606 been broken across lines to fit on the page, but they are not broken 607 across lines in actual implementations. 609 MESSAGE sip:kumiko@example.net SIP/2.0 610 611 Via: SIP/2.0/TCP 192.0.2.2:15001; 612 branch=z9hG4bK-d8754z-c947ab3f4ea84000-1---d8754z-; 613 rport=50714 614 615 Max-Forwards: 70 616 To: 617 From: ;tag=20fad54c 618 Call-ID: NTMyZGNlOWRkODAyNGY1ZWM0MDI2ZGVmZDBhZTQwYWI. 619 CSeq: 8473 MESSAGE 620 621 Accept: multipart/signed, text/plain, application/pkcs7-mime, 622 application/sdp, multipart/alternative 623 624 625 Content-Type: multipart/signed;boundary=d0c5ff1dcdc8f431; 626 micalg=sha1;protocol="application/pkcs7-signature" 627 628 Content-Length: 772 630 --d0c5ff1dcdc8f431 631 Content-Type: text/plain 632 Content-Transfer-Encoding: binary 634 Hello! 635 --d0c5ff1dcdc8f431 636 Content-Type: application/pkcs7-signature;name=smime.p7s 637 638 Content-Disposition: attachment;handling=required; 639 filename=smime.p7s 640 641 Content-Transfer-Encoding: binary 643 ***************** 644 * BINARY BLOB 1 * 645 ***************** 646 --d0c5ff1dcdc8f431-- 648 It is important to note that the signature ("BINARY BLOB 1") is 649 computed over the MIME headers and body, but excludes the multipart 650 boundary lines. The value on the Message-body line ends with CRLF. 651 The CRLF is included in the boundary and is not part of the signature 652 computation. To be clear, the signature is computed over data 653 starting with the "C" in the "Content-Type" and ending with the "!" 654 in the "Hello!". 656 Content-Type: text/plain 657 Content-Transfer-Encoding: binary 659 Hello! 661 Following is the ASN.1 parsing of encrypted contents referred to 662 above as "BINARY BLOB 1". Note that at address 30, the hash for the 663 signature is specified as SHA-1. Also note that the sender's 664 certificate is not attached as it is optional in RFC 5652 [9]. 666 0 470: SEQUENCE { 667 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 668 15 455: [0] { 669 19 451: SEQUENCE { 670 23 1: INTEGER 1 671 26 11: SET { 672 28 9: SEQUENCE { 673 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 674 37 0: NULL 675 : } 676 : } 677 39 11: SEQUENCE { 678 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 679 : } 680 52 418: SET { 681 56 414: SEQUENCE { 682 60 1: INTEGER 1 683 63 123: SEQUENCE { 684 65 112: SEQUENCE { 685 67 11: SET { 686 69 9: SEQUENCE { 687 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 688 76 2: PrintableString 'US' 689 : } 690 : } 691 80 19: SET { 692 82 17: SEQUENCE { 693 84 3: OBJECT IDENTIFIER 694 : stateOrProvinceName (2 5 4 8) 695 89 10: PrintableString 'California' 696 : } 697 : } 698 101 17: SET { 699 103 15: SEQUENCE { 700 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 701 110 8: PrintableString 'San Jose' 702 : } 703 : } 705 120 14: SET { 706 122 12: SEQUENCE { 707 124 3: OBJECT IDENTIFIER 708 : organizationName (2 5 4 10) 709 129 5: PrintableString 'sipit' 710 : } 711 : } 712 136 41: SET { 713 138 39: SEQUENCE { 714 140 3: OBJECT IDENTIFIER 715 : organizationalUnitName (2 5 4 11) 716 145 32: PrintableString 'Sipit Test Certificate Aut 717 hority' 718 : } 719 : } 720 : } 721 179 7: INTEGER 49 02 11 01 84 01 5C 722 : } 723 188 9: SEQUENCE { 724 190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 725 197 0: NULL 726 : } 727 199 13: SEQUENCE { 728 201 9: OBJECT IDENTIFIER 729 : rsaEncryption (1 2 840 113549 1 1 1) 730 212 0: NULL 731 : } 732 214 256: OCTET STRING 733 : 06 AF 96 EE 1F 64 C9 B5 72 A6 07 F8 BF F7 95 4D 734 : D9 7C D7 F6 CB 00 30 46 D4 EF BA 85 11 8A EB B9 735 : 03 8E F8 34 12 99 0C A9 98 53 C7 17 DE E5 66 5D 736 : 5B A0 66 A0 93 89 53 1D 06 EC F5 10 1C DC 8B 48 737 : 5A 47 49 FB 02 9F 58 96 B5 2B 01 F2 F9 0A 26 7A 738 : 08 79 1D 31 78 C0 C9 71 CA 30 4A 5A C5 64 89 80 739 : 62 0A FB F5 C9 5F 15 7B 56 2D 7B 3E A1 66 A8 CC 740 : 5F 42 BD 4D 5A E1 E0 7B EB 2B E7 C5 48 53 62 4A 741 : D0 AA 28 95 A9 0D E3 3C A0 3E 51 41 1C B1 12 5E 742 : 47 AA A2 3A D0 7A 95 E8 6F A8 C6 0D 81 79 FE 03 743 : 21 50 91 1B 0A 97 DB 11 4C C8 E6 5F 2F C1 22 27 744 : CF 76 36 1C E0 63 37 95 65 EF BB 7F E7 56 47 5B 745 : C5 A7 1B 76 13 97 6A 13 BD 17 37 1D BC 2B 9A 48 746 : 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA 747 : E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41 748 : 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB 749 : } 750 : } 751 : } 752 : } 753 : } 755 SHA-1 parameters may be omitted entirely, instead of being set to 756 NULL, as mentioned in RFC 3370 [5]. The above dump of Blob 1 has 757 SHA-1 parameters set to NULL. Below are the same contents signed 758 with the same key, but omitting the NULL according to RFC 3370 [5]. 759 This is the preferred encoding. This is covered in greater detail in 760 Section 5. 762 0 466: SEQUENCE { 763 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 764 15 451: [0] { 765 19 447: SEQUENCE { 766 23 1: INTEGER 1 767 26 9: SET { 768 28 7: SEQUENCE { 769 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 770 : } 771 : } 772 37 11: SEQUENCE { 773 39 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 774 : } 775 50 416: SET { 776 54 412: SEQUENCE { 777 58 1: INTEGER 1 778 61 123: SEQUENCE { 779 63 112: SEQUENCE { 780 65 11: SET { 781 67 9: SEQUENCE { 782 69 3: OBJECT IDENTIFIER countryName (2 5 4 6) 783 74 2: PrintableString 'US' 784 : } 785 : } 786 78 19: SET { 787 80 17: SEQUENCE { 788 82 3: OBJECT IDENTIFIER 789 : stateOrProvinceName (2 5 4 8) 790 87 10: PrintableString 'California' 791 : } 792 : } 793 99 17: SET { 794 101 15: SEQUENCE { 795 103 3: OBJECT IDENTIFIER localityName (2 5 4 7) 796 108 8: PrintableString 'San Jose' 797 : } 798 : } 799 118 14: SET { 800 120 12: SEQUENCE { 801 122 3: OBJECT IDENTIFIER 802 : organizationName (2 5 4 10) 803 127 5: PrintableString 'sipit' 804 : } 805 : } 806 134 41: SET { 807 136 39: SEQUENCE { 808 138 3: OBJECT IDENTIFIER 809 : organizationalUnitName (2 5 4 11) 810 143 32: PrintableString 'Sipit Test Certificate Aut 811 hority' 812 : } 813 : } 814 : } 815 177 7: INTEGER 49 02 11 01 84 01 5C 816 : } 817 186 7: SEQUENCE { 818 188 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 819 : } 820 195 13: SEQUENCE { 821 197 9: OBJECT IDENTIFIER 822 : rsaEncryption (1 2 840 113549 1 1 1) 823 208 0: NULL 824 : } 825 210 256: OCTET STRING 826 : 06 AF 96 EE 1F 64 C9 B5 72 A6 07 F8 BF F7 95 4D 827 : D9 7C D7 F6 CB 00 30 46 D4 EF BA 85 11 8A EB B9 828 : 03 8E F8 34 12 99 0C A9 98 53 C7 17 DE E5 66 5D 829 : 5B A0 66 A0 93 89 53 1D 06 EC F5 10 1C DC 8B 48 830 : 5A 47 49 FB 02 9F 58 96 B5 2B 01 F2 F9 0A 26 7A 831 : 08 79 1D 31 78 C0 C9 71 CA 30 4A 5A C5 64 89 80 832 : 62 0A FB F5 C9 5F 15 7B 56 2D 7B 3E A1 66 A8 CC 833 : 5F 42 BD 4D 5A E1 E0 7B EB 2B E7 C5 48 53 62 4A 834 : D0 AA 28 95 A9 0D E3 3C A0 3E 51 41 1C B1 12 5E 835 : 47 AA A2 3A D0 7A 95 E8 6F A8 C6 0D 81 79 FE 03 836 : 21 50 91 1B 0A 97 DB 11 4C C8 E6 5F 2F C1 22 27 837 : CF 76 36 1C E0 63 37 95 65 EF BB 7F E7 56 47 5B 838 : C5 A7 1B 76 13 97 6A 13 BD 17 37 1D BC 2B 9A 48 839 : 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA 840 : E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41 841 : 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB 842 : } 843 : } 844 : } 845 : } 846 : } 848 4.2. MESSAGE Request with Encrypted Body 850 Below is an example of an encrypted text/plain message that says 851 "Hello!". The binary encrypted contents have been replaced with the 852 block "BINARY BLOB 2". 854 MESSAGE sip:kumiko@example.net SIP/2.0 855 856 Via: SIP/2.0/TCP 192.0.2.2:15001; 857 branch=z9hG4bK-d8754z-19883b67d813801b-1---d8754z-; 858 rport=50716 859 860 Max-Forwards: 70 861 To: 862 From: ;tag=47e96625 863 Call-ID: NDg3ZGJjMGVhM2Y4MjdjNjU4ZDYyODhlODZkNGVlOWU. 864 CSeq: 3260 MESSAGE 865 866 Accept: multipart/signed, text/plain, application/pkcs7-mime, 867 application/sdp, multipart/alternative 868 869 870 Content-Disposition: attachment;handling=required; 871 filename=smime.p7 872 873 Content-Transfer-Encoding: binary 874 875 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 876 name=smime.p7m 877 878 Content-Length: 563 880 ***************** 881 * BINARY BLOB 2 * 882 ***************** 884 Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at 885 address 452, the encryption is set to aes128-CBC. 887 0 559: SEQUENCE { 888 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 889 15 544: [0] { 890 19 540: SEQUENCE { 891 23 1: INTEGER 0 892 26 407: SET { 893 30 403: SEQUENCE { 894 34 1: INTEGER 0 895 37 123: SEQUENCE { 896 39 112: SEQUENCE { 897 41 11: SET { 898 43 9: SEQUENCE { 899 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 900 50 2: PrintableString 'US' 901 : } 902 : } 903 54 19: SET { 904 56 17: SEQUENCE { 905 58 3: OBJECT IDENTIFIER 906 : stateOrProvinceName (2 5 4 8) 907 63 10: PrintableString 'California' 908 : } 909 : } 910 75 17: SET { 911 77 15: SEQUENCE { 912 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 913 84 8: PrintableString 'San Jose' 914 : } 915 : } 916 94 14: SET { 917 96 12: SEQUENCE { 918 98 3: OBJECT IDENTIFIER 919 : organizationName (2 5 4 10) 920 103 5: PrintableString 'sipit' 921 : } 922 : } 923 110 41: SET { 924 112 39: SEQUENCE { 925 114 3: OBJECT IDENTIFIER 926 : organizationalUnitName (2 5 4 11) 927 119 32: PrintableString 'Sipit Test Certificate Aut 928 hority' 929 : } 930 : } 931 : } 932 153 7: INTEGER 49 02 11 01 84 01 5D 933 : } 934 162 13: SEQUENCE { 935 164 9: OBJECT IDENTIFIER 936 : rsaEncryption (1 2 840 113549 1 1 1) 937 175 0: NULL 938 : } 939 177 256: OCTET STRING 940 : 40 0B 31 3C 3D 16 C2 B3 C1 74 C8 A3 08 70 6F FB 941 : DC 1B 40 72 A3 BB 84 0A 54 CA AD A7 5E 93 39 36 942 : D5 0D 29 C8 D9 B0 67 3D 75 88 C7 5B 32 0A 9A 54 943 : 01 59 F1 F0 AF 07 65 6B 35 4C 24 B0 D0 2A 57 8D 944 : E0 99 1F 54 D2 45 7C 49 7B 59 C9 E2 26 FF 8D 79 945 : FC AD 06 67 C3 31 0E 2F FF A9 17 8C 24 AA 79 82 946 : B6 6E EC 87 25 B2 E7 04 88 A4 92 FB 85 AD 9C 26 947 : A2 D2 E8 3D F6 72 DB CD 20 EF C4 F2 0B 0F 0A 02 948 : 68 E9 52 B7 2E 69 3B E7 D0 EE 42 9C 9B 3E 0F B5 949 : DA 3B 7B 27 E0 1F D4 76 DE 0A 4B C1 4C 44 51 E8 950 : 05 05 FB D8 0D 69 A5 B8 1A 51 08 00 43 E2 45 EA 951 : 8D 98 A0 7E 73 53 41 4D CB D1 77 4C FB 81 AA 26 952 : F5 F4 82 6E C9 F4 8B 5E 5C 13 44 F4 D6 E2 57 89 953 : B6 11 DD 60 A4 8A C1 77 48 98 AA BF 82 FA 5C 0E 954 : 58 C7 A8 67 48 9E 09 97 51 2E B4 10 B3 9B 3F 62 955 : 77 D7 4F 61 C0 E4 AA 70 58 22 4E B4 24 6E 80 4C 956 : } 957 : } 958 437 124: SEQUENCE { 959 439 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 960 450 29: SEQUENCE { 961 452 9: OBJECT IDENTIFIER 962 : aes128-CBC (2 16 840 1 101 3 4 1 2) 963 463 16: OCTET STRING 964 : 22 B3 06 78 4E 7E CF 9B 99 C8 08 2F 93 85 6D 5C 965 : } 966 481 80: [0] 967 : CB F2 22 1B C0 F8 ED 86 6A CB 65 8C 08 7C BE 21 968 : 8A 53 3D C5 92 EE 23 E3 8A EA D6 DF B3 22 3A 00 969 : F9 96 4C 5F 8B 75 4F 7E 22 F7 D6 8A D3 13 56 EE 970 : BF B7 D9 24 32 6D F1 0B E8 CF 7C FC 14 90 BE DA 971 : F3 5E 04 38 CC D6 E5 9D 6F AF 44 BF A0 0A 3A 5C 972 : } 973 : } 974 : } 975 : } 977 4.3. MESSAGE Request with Encrypted and Signed Body 979 In the example below, some of the header values have been split 980 across mutliple lines. Where the lines have been broken, the 981 convention has been used. This was only done to make it 982 fit in the RFC format. Specifically, the application/pkcs7-mime 983 Content-Type line is one line with no whitespace between the "mime;" 984 and the "smime-type". The values are split across lines for 985 formatting, but are not split in the real message. The binary 986 encrypted content has been replaced with "BINARY BLOB 3", and the 987 binary signed content has been replaced with "BINARY BLOB 4". 989 MESSAGE sip:kumiko@example.net SIP/2.0 990 991 Via: SIP/2.0/TCP 192.0.2.2:15001; 992 branch=z9hG4bK-d8754z-540c0075b0e6350b-1---d8754z-; 993 rport=50717 994 995 Max-Forwards: 70 996 To: 997 From: ;tag=ead36604 998 Call-ID: MjhmOTlmMWVmY2ZhNzAxYmZlYzNmODE2YWNhMmU4Zjg. 999 CSeq: 5449 MESSAGE 1000 1001 Accept: multipart/signed, text/plain, application/pkcs7-mime, 1002 application/sdp, multipart/alternative 1003 1004 1005 Content-Type: multipart/signed;boundary=f913571e3a21963d; 1006 micalg=sha1;protocol="application/pkcs7-signature" 1007 1008 Content-Length: 1451 1010 --f913571e3a21963d 1011 1012 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 1013 name=smime.p7m 1014 1015 1016 Content-Disposition: attachment;handling=required; 1017 filename=smime.p7 1018 1019 Content-Transfer-Encoding: binary 1021 ***************** 1022 * BINARY BLOB 3 * 1023 ***************** 1024 --f913571e3a21963d 1025 Content-Type: application/pkcs7-signature;name=smime.p7s 1026 1027 Content-Disposition: attachment;handling=required; 1028 filename=smime.p7s 1029 1030 Content-Transfer-Encoding: binary 1032 ***************** 1033 * BINARY BLOB 4 * 1034 ***************** 1035 --f913571e3a21963d-- 1036 Below is the ASN.1 parsing of "BINARY BLOB 3". 1038 0 559: SEQUENCE { 1039 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 1040 15 544: [0] { 1041 19 540: SEQUENCE { 1042 23 1: INTEGER 0 1043 26 407: SET { 1044 30 403: SEQUENCE { 1045 34 1: INTEGER 0 1046 37 123: SEQUENCE { 1047 39 112: SEQUENCE { 1048 41 11: SET { 1049 43 9: SEQUENCE { 1050 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1051 50 2: PrintableString 'US' 1052 : } 1053 : } 1054 54 19: SET { 1055 56 17: SEQUENCE { 1056 58 3: OBJECT IDENTIFIER 1057 : stateOrProvinceName (2 5 4 8) 1058 63 10: PrintableString 'California' 1059 : } 1060 : } 1061 75 17: SET { 1062 77 15: SEQUENCE { 1063 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1064 84 8: PrintableString 'San Jose' 1065 : } 1066 : } 1067 94 14: SET { 1068 96 12: SEQUENCE { 1069 98 3: OBJECT IDENTIFIER 1070 : organizationName (2 5 4 10) 1071 103 5: PrintableString 'sipit' 1072 : } 1073 : } 1074 110 41: SET { 1075 112 39: SEQUENCE { 1076 114 3: OBJECT IDENTIFIER 1077 : organizationalUnitName (2 5 4 11) 1078 119 32: PrintableString 'Sipit Test Certificate Aut 1079 hority' 1080 : } 1081 : } 1082 : } 1083 153 7: INTEGER 49 02 11 01 84 01 5D 1084 : } 1085 162 13: SEQUENCE { 1086 164 9: OBJECT IDENTIFIER 1087 : rsaEncryption (1 2 840 113549 1 1 1) 1088 175 0: NULL 1089 : } 1090 177 256: OCTET STRING 1091 : 00 50 79 F3 84 E1 0A 63 9E E3 F2 FE 87 5F 81 43 1092 : 55 6E 5B C9 46 91 B0 FF 15 70 03 8C 07 EC 56 5D 1093 : 4F F9 8C 22 89 9C 0F EE 81 FB 5C 63 F0 5E 9E DA 1094 : AC CC D5 F2 55 CD 04 6F C3 9A 1F 56 C5 F4 FB 08 1095 : 70 4D 07 79 54 83 AF CA 08 75 4B 4A 2A 2F 56 70 1096 : A7 A0 B3 68 2F D0 CF 3F 77 C8 A8 DC B3 E7 81 3E 1097 : 72 2A 12 6B E6 D9 B7 23 8A B1 3F 27 D6 48 EF 2C 1098 : 14 35 8A D2 84 22 FB 41 B6 1F 23 39 DC 9A 42 60 1099 : CD F6 5F 1C 70 22 20 86 C3 EC 3E 91 D5 62 78 66 1100 : A1 01 3D D7 AE 1E 9A 00 38 AC 0E 21 49 C2 4A 9A 1101 : 9F BF 5D AC 50 F3 B0 39 A4 14 89 A6 F3 DA EC E0 1102 : 84 D0 B7 2B 00 C0 C0 2A B9 FA EE DE 7A B0 FE CC 1103 : D9 1F A3 1F B7 BC 69 D3 9D 84 6B 7A 37 15 4C DB 1104 : 08 6D 55 F8 F7 38 24 3F 87 F5 66 E2 7F 5F 0F 84 1105 : BD 1E 49 16 DD 31 BE BF 1F 7E 3E 07 AE AA 97 52 1106 : F2 EA 8B 34 5D 5A 07 72 DB 48 B8 FE D5 41 14 36 1107 : } 1108 : } 1109 437 124: SEQUENCE { 1110 439 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1111 450 29: SEQUENCE { 1112 452 9: OBJECT IDENTIFIER 1113 : aes128-CBC (2 16 840 1 101 3 4 1 2) 1114 463 16: OCTET STRING 1115 : 4F 3B 58 6A ED 07 FF BC 84 F4 03 CA 98 B2 1F 65 1116 : } 1117 481 80: [0] 1118 : 88 11 C3 C3 70 D0 5B E6 48 F5 50 27 C1 C2 F2 F5 1119 : 31 3D 47 B9 FB 3E E6 AA EB DE 5C 11 40 A7 2A 5A 1120 : 7C FF 6F 10 66 68 C1 D9 8E B0 36 94 9C 60 90 30 1121 : 6A 80 0A C6 20 50 F0 E2 03 B6 44 B3 B3 D9 AA 54 1122 : A7 EE 12 7D F9 4D 10 56 DC 92 CE 3C C8 9C C2 F0 1123 : } 1124 : } 1125 : } 1126 : } 1128 Below is the ASN.1 parsing of "BINARY BLOB 4". 1130 0 470: SEQUENCE { 1131 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 1132 15 455: [0] { 1133 19 451: SEQUENCE { 1134 23 1: INTEGER 1 1135 26 11: SET { 1136 28 9: SEQUENCE { 1137 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1138 37 0: NULL 1139 : } 1140 : } 1141 39 11: SEQUENCE { 1142 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1143 : } 1144 52 418: SET { 1145 56 414: SEQUENCE { 1146 60 1: INTEGER 1 1147 63 123: SEQUENCE { 1148 65 112: SEQUENCE { 1149 67 11: SET { 1150 69 9: SEQUENCE { 1151 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1152 76 2: PrintableString 'US' 1153 : } 1154 : } 1155 80 19: SET { 1156 82 17: SEQUENCE { 1157 84 3: OBJECT IDENTIFIER 1158 : stateOrProvinceName (2 5 4 8) 1159 89 10: PrintableString 'California' 1160 : } 1161 : } 1162 101 17: SET { 1163 103 15: SEQUENCE { 1164 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1165 110 8: PrintableString 'San Jose' 1166 : } 1167 : } 1168 120 14: SET { 1169 122 12: SEQUENCE { 1170 124 3: OBJECT IDENTIFIER 1171 : organizationName (2 5 4 10) 1172 129 5: PrintableString 'sipit' 1173 : } 1174 : } 1175 136 41: SET { 1176 138 39: SEQUENCE { 1177 140 3: OBJECT IDENTIFIER 1178 : organizationalUnitName (2 5 4 11) 1180 145 32: PrintableString 'Sipit Test Certificate Aut 1181 hority' 1182 : } 1183 : } 1184 : } 1185 179 7: INTEGER 49 02 11 01 84 01 5C 1186 : } 1187 188 9: SEQUENCE { 1188 190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1189 197 0: NULL 1190 : } 1191 199 13: SEQUENCE { 1192 201 9: OBJECT IDENTIFIER 1193 : rsaEncryption (1 2 840 113549 1 1 1) 1194 212 0: NULL 1195 : } 1196 214 256: OCTET STRING 1197 : 25 50 A2 07 12 FC 51 08 BB FD CF A5 58 CB 35 58 1198 : 46 79 DD D4 B7 E7 35 D7 F1 12 83 AC 94 9A C0 14 1199 : D1 B7 9A FA 98 78 52 BA 8E DB A6 14 75 CE 1B 84 1200 : 1A 02 DD F4 E6 7A F5 83 29 D5 A2 17 DC E9 53 76 1201 : EF 22 8E FE 76 CC 82 A9 B4 FB 5D 1B 61 90 5E 1E 1202 : 1B CF 25 DB 24 8E A8 E1 29 4A A9 E7 BC 1A 2F 03 1203 : 0B 3A 1C 9B 9B 93 9F E6 79 25 77 B6 54 EB 3D 8D 1204 : D4 03 69 D5 A0 52 21 1C 44 F6 73 3E 82 50 0A 00 1205 : 46 66 85 A1 C0 8A 8A C3 3E 10 02 F4 F9 8E 63 B6 1206 : 83 3D B2 C2 28 E5 D9 00 92 A5 13 B5 18 7C 01 D4 1207 : 81 5D 2C 1D DB B7 DB CF 10 5E 7B E7 FC 4B 64 E2 1208 : 00 94 B0 64 A6 9B 1D 9B BA E7 A2 D9 2D AF 22 C7 1209 : 5C 04 60 C8 4C C1 6C 9A E5 37 6C 16 C9 00 3A 45 1210 : 18 83 57 5F 32 17 2B 18 54 B3 3F 9F F0 E4 44 36 1211 : 30 CF 25 53 95 1F 33 CD 01 78 DF FC 8D E4 47 40 1212 : AC 9C 9B 5A 6B 97 04 E3 06 F7 3D CE 18 4C 54 6A 1213 : } 1214 : } 1215 : } 1216 : } 1217 : } 1219 5. Observed Interoperability Issues 1221 This section describes some common interoperability problems. These 1222 were observed by the authors at SIPit interoperability events. 1223 Implementers should be careful to verify that their systems do not 1224 introduce these common problems, and, when possible, make their 1225 clients forgiving in what they receive. Implementations should take 1226 extra care to produce reasonable error messages when interacting with 1227 software that has these problems. 1229 Some SIP clients incorrectly only do SSLv3 and do not support TLS. 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 checks that this name corresponds 1237 to the identity the server is trying to contact. Normative text 1238 describing path validation can be found in section 7 of RFC 5922 [16] 1239 and section 6 of RFC 5280 [14]. If a client is trying to set up a 1240 TLS connection to good.example.com and it gets a TLS connection set 1241 up with a server that presents a valid certificate but with the name 1242 evil.example.com, it will typically generate an error or warning of 1243 some type. Similarly with S/MIME, if a user is trying to communicate 1244 with sip:fluffy@example.com, one of the items in the Subject 1245 Alternate Name set in the certificate will need to match according to 1246 the certificate validation rules in section 23 of RFC 3261 [3] and 1247 section 6 of RFC 5280 [14]. 1249 Some implementations used binary MIME encodings while others used 1250 base64. It is advisable that implementations send only binary and 1251 are prepared to receive either. 1253 In several places in this document, the messages contain the encoding 1254 for the SHA-1 digest algorithm identifier. The preferred form for 1255 encoding as set out in Section 2 of RFC 3370 [5] is the form in which 1256 the optional AlgorithmIdentifier parameter field is omitted. 1257 However, RFC 3370 also says the recipients need to be able to receive 1258 the form in which the AlgorithmIdentifier parameter field is present 1259 and set to NULL. Examples of the form using NULL can be found in 1260 Section 4.2 of RFC 4134 [19]. Receivers really do need to be able to 1261 receive the form that includes the NULL because the NULL form, while 1262 not preferred, is what was observed as being generated by most 1263 implementations. Implementers should also note that if the algorithm 1264 is MD5 instead of SHA-1, then the form that omits the 1265 AlgorithmIdentifier parameters field is not allowed and the sender 1266 has to use the form where the NULL is included. 1268 The preferred encryption algorithm for S/MIME in SIP is AES as 1269 defined in RFC 3853 [10]. 1271 Observed S/MIME interoperability has been better when UAs did not 1272 attach the senders' certificates. Attaching the certificates 1273 significantly increases the size of the messages, which should be 1274 considered when sending over UDP. Furthermore, the receiver cannot 1275 rely on the sender to always send the certificate, so it does not 1276 turn out to be useful in most situations. 1278 6. Additional Test Scenarios 1280 This section provides a non-exhaustive list of tests that 1281 implementations should perform while developing systems that use 1282 S/MIME and TLS for SIP. 1284 Much of the required behavior for inspecting certificates when using 1285 S/MIME and TLS with SIP is currently underspecified. The non- 1286 normative recommendations in this document capture the current 1287 folklore around that required behavior, guided by both related 1288 normative works such as RFC 4474 [11] (particulary, section 13.4 1289 Domain Names and Subordination) and informative works such as RFC 1290 2818 [18] section 3.1. To summarize, test plans should: 1291 o For S/MIME secured bodies, assure that the peer's URI (address-of- 1292 record, as per RFC 3261 [3] section 23.3) appears in the 1293 subjectAltName of the peer's certifcate as a 1294 uniformResourceIdentifier field. 1295 o For TLS, assure that the peer's hostname appears as described in 1296 RFC 5922 [16]. Also: 1297 * assure an exact match in a dNSName entry in the subjectAltName 1298 if there are any dNSNames in the subjectAltName. Wildcard 1299 matching is not allowed against these dNSName entries. See 1300 section 7.1 of RFC 5922 [16]. 1301 * assure that the most specific CommonName in the Subject field 1302 matches if there are no dNSName entries in the subjectAltName 1303 at all (which is not the same as there being no matching 1304 dNSName entries). This match can be either exact, or against 1305 an entry that uses the wildcard matching character '*' 1306 The peer's hostname is discovered from the initial DNS query in 1307 the server location process RFC 3263 [4]. 1308 o IP addresses can appear in subjectAltName (RFC 5280 [14]) of the 1309 peer's certificate, e.g. "IP:192.168.0.1". Note that if IP 1310 addresses are used in subjectAltName, there are important 1311 ramifications regarding the use of Record-Route headers that also 1312 need to be considered. See section 7.5 of RFC 5922 [16]. Use of 1313 IP addresses instead of domain names is inadvisable. 1315 For each of these tests, an implementation will proceed past the 1316 verification point only if the certificate is "good". S/MIME 1317 protected requests presenting bad certificate data will be rejected. 1318 S/MIME protected responses presenting bad certificate information 1319 will be ignored. TLS connections involving bad certificate data will 1320 not be completed. 1322 1. S/MIME : Good peer certificate 1323 2. S/MIME : Bad peer certificate (peer URI does not appear in 1324 subjAltName) 1325 3. S/MIME : Bad peer certificate (valid authority chain does not 1326 end at a trusted CA) 1327 4. S/MIME : Bad peer certificate (incomplete authority chain) 1328 5. S/MIME : Bad peer certificate (the current time does not fall 1329 within the period of validity) 1330 6. S/MIME : Bad peer certificate (certificate or cert in authority 1331 chain has been revoked) 1332 7. S/MIME : Bad peer certificate ("Digital Signature" is not 1333 specified as an X509v3 Key Usage) 1334 8. TLS : Good peer certificate (hostname appears in dNSName in 1335 subjAltName) 1336 9. TLS : Good peer certificate (no dNSNames in subjAltName, 1337 hostname appears in CN of Subject) 1338 10. TLS : Good peer certificate (CN of Subject empty, and 1339 subjectAltName extension contains an iPAddress stored in the 1340 octet string in network byte order form as specified in RFC 791 1341 [1]) 1342 11. TLS : Bad peer certificate (no match in dNSNames or in the 1343 Subject CN) 1344 12. TLS : Bad peer certificate (valid authority chain does not end 1345 at a trusted CA) 1346 13. TLS : Bad peer certificate (incomplete authority chain) 1347 14. TLS : Bad peer certificate (the current time does not fall 1348 within the period of validity) 1349 15. TLS : Bad peer certificate (certificate or cert in authority 1350 chain has been revoked) 1351 16. TLS : Bad peer certificate ("TLS Web Server Authentication" is 1352 not specified as an X509v3 Key Usage) 1353 17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any 1354 Extended Key Usage" specified as an X509v3 Extended Key Usage, 1355 and X509v3 Extended Key Usage is present) 1357 7. IANA Considerations 1359 No IANA actions are required. 1361 8. Acknowledgments 1363 Many thanks to the developers of all the open source software used to 1364 create these call flows. This includes the underlying crypto and TLS 1365 software used from openssl.org, the SIP stack from 1366 www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. 1367 The TLS flow dumps were done with SSLDump from 1368 http://www.rtfm.com/ssldump. The book "SSL and TLS" [21] was a huge 1369 help in developing the code for these flows. It's sad there is no 1370 second edition. 1372 Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat 1373 Chan, and Lyndsay Campbell who all helped find and correct mistakes 1374 in this document. 1376 Vijay Gurbani and Alan Jeffrey contributed much of the additional 1377 test scenario content. 1379 9. Security Considerations 1381 Implementers must never use any of the certificates provided in this 1382 document in anything but a test environment. Installing the CA root 1383 certificates used in this document as a trusted root in operational 1384 software would completely destroy the security of the system while 1385 giving the user the impression that the system was operating 1386 securely. 1388 This document recommends some things that implementers might test or 1389 verify to improve the security of their implementations. It is 1390 impossible to make a comprehensive list of these, and this document 1391 only suggests some of the most common mistakes that have been seen at 1392 the SIPit interoperability events. Just because an implementation 1393 does everything this document recommends does not make it secure. 1395 This document does not show any messages to check certificate 1396 revocation status (see section 3.3 of RFC 5280 [14]) as that is not 1397 part of the SIP call flow. The expectation is that revocation status 1398 is checked regularly to protect against the possibility of 1399 certificate compromise or repudiation. For more information on how 1400 certificate revocation status can be checked, see RFC 2560 [2] 1401 (Online Certificate Status Protocol) and RFC 5055 [12] (Server-Based 1402 Certificate Validation Protocol). 1404 10. Changelog 1406 (RFC Editor: remove this section) 1408 -02 to -03 1409 * Re-worded "should" and "must" so that the document doesn't 1410 sound like it is making normative statements. Actual normative 1411 behavior is referred to in the respective RFCs. 1413 * Section 5: re-worded paragraphs 4 and 5 regarding 1414 subjectAltName, and added references. 1415 * Section 6: added references, clarified use of IP addresses, and 1416 clarified which From/To URI is used for comparison (from RFC 1417 3261 section 23.2). Added an EKU test case. 1418 * Section 9: added text about certificate revocation checking. 1419 * Appendix B.3: new section to present certificate chains longer 1420 than 2 (non-root CA). 1421 * Made examples consistently use convention. 1422 * CSeq looks more random. 1423 * Serial numbers in certs are non-zero. 1424 * All flows re-generated using new certs. IP addresses conform 1425 to RFC 5737. 1426 * Updated references. 1427 -01 to -02 1428 * Draft is now informational, not standards track. Normative- 1429 sounding language and references to RFC 2119 removed. 1430 * Add TODO: change "hello" to "Hello!" in example flows for 1431 consistency. 1432 * Add TODO: Fix subjectAltName DNS:com to DNS:example.com and 1433 DNS:net to DNS:example.net. 1434 * Add TODO: use allOneLine convention from RFC4475. 1435 * Section 3: updated open issue regarding contact headers in 1436 MESSAGE. 1437 * Section 3.2: added some text about RFC 3263 and connection 1438 reuse and closed open issue. 1439 * Section 5: clarified text about sender attaching certs, closed 1440 issue. 1441 * Section 5: clarified text about observed problems, closed 1442 issue. 1443 * Section 5: closed issue about clients vs. servers vs. proxies. 1444 * Section 6: updated section text and open issue where IP address 1445 is in subjectAltName. 1446 * Section 6: added normative references and closed "folklore" 1447 issue. 1448 * Section 6: added cases about cert usage and broken chains, 1449 updated OPEN ISSUE: we need a SIP EKU example. 1450 * References: updated references to drafts and re-categorized 1451 informative vs. normative. 1452 * Section 9: added some text about revocation status and closed 1453 issue. 1454 * Appendix B: open issue: do we need non-root-CA certs and host 1455 certs signed by them for help in testing cases in Section 6? 1456 * Miscellaneous minor editorial changes. 1458 -00 to -01 1459 * Addition of OPEN ISSUES. 1460 * Numerous minor edits from mailing list feedback. 1461 to -00 1462 * Changed RFC 3369 references to RFC 3852. 1463 * Changed draft-ietf-sip-identity references to RFC 4474. 1464 * Added an ASN.1 dump of CMS signed content where SHA-1 1465 parameters are omitted instead of being set to ASN.1 NULL. 1466 * Accept headers added to messages. 1467 * User and domain certificates are generated with EKU as 1468 specified in Draft SIP EKU. 1469 * Message content that is shown is computed using certificates 1470 generated with EKU. 1471 * Message dump archive returned. 1472 * Message archive contains messages formed with and without EKU 1473 certificates. 1474 prior to -00 1475 * Incorporated the Test cases from Vijay Gurbani's and Alan 1476 Jeffrey's Use of TLS in SIP draft 1477 * Began to capture the folklore around where identities are 1478 carried in certificates for use with SIP 1479 * Removed the message dump archive pending verification (will 1480 return in -02) 1482 11. References 1484 11.1. Normative References 1486 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, 1487 September 1981. 1489 [2] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, 1490 "X.509 Internet Public Key Infrastructure Online Certificate 1491 Status Protocol - OCSP", RFC 2560, June 1999. 1493 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1494 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1495 Session Initiation Protocol", RFC 3261, June 2002. 1497 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1498 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1500 [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 1501 RFC 3370, August 2002. 1503 [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1504 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1505 Instant Messaging", RFC 3428, December 2002. 1507 [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1508 T. Wright, "Transport Layer Security (TLS) Extensions", 1509 RFC 4366, April 2006. 1511 [8] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail 1512 Extensions (S/MIME) Version 3.2 Message Specification", 1513 RFC 5751, January 2010. 1515 [9] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1516 RFC 5652, September 2009. 1518 [10] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1519 Requirement for the Session Initiation Protocol (SIP)", 1520 RFC 3853, July 2004. 1522 [11] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1523 Identity Management in the Session Initiation Protocol (SIP)", 1524 RFC 4474, August 2006. 1526 [12] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, 1527 "Server-Based Certificate Validation Protocol (SCVP)", 1528 RFC 5055, December 2007. 1530 [13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1531 Protocol Version 1.2", RFC 5246, August 2008. 1533 [14] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 1534 R., and W. Polk, "Internet X.509 Public Key Infrastructure 1535 Certificate and Certificate Revocation List (CRL) Profile", 1536 RFC 5280, May 2008. 1538 [15] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for 1539 Session Initiation Protocol (SIP) X.509 Certificates", 1540 RFC 5924, June 2010. 1542 [16] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates 1543 in the Session Initiation Protocol (SIP)", RFC 5922, June 2010. 1545 [17] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the 1546 Session Initiation Protocol (SIP)", RFC 5923, June 2010. 1548 11.2. Informative References 1550 [18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1552 [19] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1553 July 2005. 1555 [20] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and 1556 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test 1557 Messages", RFC 4475, May 2006. 1559 [21] Rescorla, E., "SSL and TLS - Designing and Building Secure 1560 Systems", 2001. 1562 [22] Rescorla, E., "SSLDump manpage". 1564 Appendix A. Making Test Certificates 1566 These scripts allow you to make certificates for test purposes. The 1567 certificates will all share a common CA root so that everyone running 1568 these scripts can have interoperable certificates. WARNING - these 1569 certificates are totally insecure and are for test purposes only. 1570 All the CA created by this script share the same private key to 1571 facilitate interoperability testing, but this totally breaks the 1572 security since the private key of the CA is well known. 1574 The instructions assume a Unix-like environment with openssl 1575 installed, but openssl does work in Windows too. OpenSSL version 1576 0.9.8j was used to generate the certificates used in this document. 1577 Make sure you have openssl installed by trying to run "openssl". Run 1578 the makeCA script found in Appendix A.1; this creates a subdirectory 1579 called demoCA. If the makeCA script cannot find where your openssl 1580 is installed you will have to set an environment variable called 1581 OPENSSLDIR to whatever directory contains the file openssl.cnf. You 1582 can find this with a "locate openssl.cnf". You are now ready to make 1583 certificates. 1585 To create certs for use with TLS, run the makeCert script found in 1586 Appendix A.2 with the fully qualified domain name of the proxy you 1587 are making the certificate for. For example, "makeCert 1588 host.example.net". This will generate a private key and a 1589 certificate. The private key will be left in a file named 1590 domain_key_example.net.pem in pem format. The certificate will be in 1591 domain_cert_example.net.pem. Some programs expect both the 1592 certificate and private key combined together in a PKCS12 format 1593 file. This is created by the script and left in a file named 1594 example.net.p12. Some programs expect this file to have a .pfx 1595 extension instead of .p12 - just rename the file if needed. A file 1596 with a certificate signing request, called example.net.csr, is also 1597 created and can be used to get the certificate signed by another CA. 1599 A second argument indicating the number of days for which the 1600 certificate should be valid can be passed to the makeCert script. It 1601 is possible to make an expired certificate using the command 1602 "makeCert host.example.net 0". 1604 Anywhere that a password is used to protect a certificate, the 1605 password is set to the string "password". 1607 The root certificate for the CA is in the file 1608 root_cert_fluffyCA.pem. 1610 For things that need DER format certificates, a certificate can be 1611 converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM 1612 -out cert.der -outform DER". 1614 Some programs expect certificates in PKCS#7 format (with a file 1615 extension of .p7c). You can convert these from PEM format to PKCS#7 1616 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ 1617 cacert.pem -outform DER -out cert.p7c" 1619 IE (version 8), Outlook Express (version 6), and Firefox (version 1620 3.5) can import and export .p12 files and .p7c files. You can 1621 convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in 1622 cert.p7c -inform DER -outform PEM -out cert.pem". 1624 The private key can be converted to pkcs8 format with "openssl pkcs8 1625 -in a_key.pem -topk8 -outform DER -out a_key.p8c" 1627 In general, a TLS client will just need the root certificate of the 1628 CA. A TLS server will need its private key and its certificate. 1629 These could be in two PEM files, a single file with both certificate 1630 and private key PEM sections, or a single .p12 file. An S/MIME 1631 program will need its private key and certificate, the root 1632 certificate of the CA, and the certificate for every other user it 1633 communicates with. 1635 A.1. makeCA script 1637 #!/bin/sh 1638 set -x 1640 rm -rf demoCA 1642 mkdir demoCA 1643 mkdir demoCA/certs 1644 mkdir demoCA/crl 1645 mkdir demoCA/newcerts 1646 mkdir demoCA/private 1647 # This is done to generate the exact serial number used for the RFC 1648 echo "4902110184015C" > demoCA/serial 1649 touch demoCA/index.txt 1651 # You may need to modify this for where your default file is 1652 # you can find where yours in by typing "openssl ca" 1653 for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do 1654 CONF=${OPENSSLDIR:=$D}/openssl.cnf 1655 [ -f ${CONF} ] && break 1656 done 1658 CONF=${OPENSSLDIR}/openssl.cnf 1660 if [ ! -f $CONF ]; then 1661 echo "Can not find file $CONF - set your OPENSSLDIR variable" 1662 exit 1663 fi 1664 cp $CONF openssl.cnf 1666 cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem < demoCA/serial 1767 # openssl req -newkey rsa:1024 -passin pass:password \ 1768 # -passout pass:password \ 1769 # -sha1 -x509 -keyout demoCA/private/cakey.pem \ 1770 # -out demoCA/cacert.pem -days 36500 -config ${CONF} <