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