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