idnits 2.17.1 draft-ietf-sip-sec-flows-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1875. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 16, 2006) is 6555 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 908, but not defined ** Obsolete normative reference: RFC 3280 (ref. '3') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (ref. '5') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 3268 (ref. '6') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3851 (ref. '7') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3369 (ref. '8') (Obsoleted by RFC 3852) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 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 Expires: November 17, 2006 K. Ono 5 NTT Corporation 6 R. Sparks, Ed. 7 Estacado Systems 8 May 16, 2006 10 Example call flows using Session Initiation Protocol (SIP) security 11 mechanisms 12 draft-ietf-sip-sec-flows-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 17, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document shows example call flows demonstrating the use of 46 Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail 47 Extensions (S/MIME) in Session Initiation Protocol (SIP). It also 48 provides information that helps implementers build interoperable SIP 49 software. To help facilitate interoperability testing, it includes 50 certificates used in the example call flows and processes to create 51 certificates for testing. 53 Table of Contents 55 1. Administrive Information . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 5. Known Problems . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 62 6.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 63 6.3. User Certificates . . . . . . . . . . . . . . . . . . . . 9 64 7. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 65 7.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 66 7.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 13 67 8. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 14 68 8.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 14 69 8.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 17 70 8.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 20 71 9. Test Consideration . . . . . . . . . . . . . . . . . . . . . . 25 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 76 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 77 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 27 78 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 29 79 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 31 80 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 33 81 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 36 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 83 Intellectual Property and Copyright Statements . . . . . . . . . . 45 85 1. Administrive Information 87 Please note that this version of the document 88 (draft-ietf-sip-sec-flows-00) is ONLY an administrative renaming from 89 draft-ietf-sipping-sec-flows. The outstanding additions to this 90 document discussed in those working groups have not yet been captured 91 here. 93 2. Introduction 95 Several different groups are starting to implement the S/MIME[7] 96 portion of SIP[2], and SIP with TLS[4], implementations are becoming 97 very common. At several interoperability events, it has become clear 98 that it is difficult to write these systems without any test vectors 99 or examples of "known good" messages to test against. Furthermore, 100 testing at the events is often hampered by trying to get certificates 101 signed by some common test root into the appropriate format for 102 various clients. This document addresses both of these issues by 103 providing messages that give detailed examples that implementers can 104 use for comparison and that can also be used for testing. In 105 addition, this document provides a common certificate that can be 106 used for a Certificate Authority (CA) to reduce the time it takes to 107 set up a test at an interoperability event. The document also 108 provides some hints and clarifications for implementers. 110 A simple SIP call flow using SIPS URIs and TLS is shown in Section 7. 111 The certificates for the hosts used are shown in Section 6.2, and the 112 CA certificates used to sign these are shown in Section 6.1. 114 The text from Section 8.1 through Section 8.3 shows some simple SIP 115 call flows using S/MIME to sign and encrypt the body of the message. 116 The user certificates used in these examples are shown in 117 Section 6.3. These host certificates are signed with the same CA 118 certificate. 120 Section 9 presents a partial list of things implementers should 121 consider in order to implement systems that will interoperate. 123 A way to make certificates that can be used for interoperability 124 testing is presented in Appendix A, along with methods for converting 125 these to various formats. 127 Binary copies of various messages in this draft that can be used for 128 testing appear in Appendix C. 130 3. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC-2119 [1]. 136 4. Security Considerations 138 Implementers must never use any of the certificates provided in this 139 document in anything but a test environment. Installing the CA root 140 certificates used in this document as a trusted root in operational 141 software would completely destroy the security of the system while 142 giving the user the impression that the system was operating 143 securely. 145 This document recommends some things that implementers might test or 146 verify to improve the security of their implementations. It is 147 impossible to make a comprehensive list of these, and this document 148 only suggests some of the most common mistakes that have been seen at 149 the SIPit interoperability events. Just because an implementation 150 does everything this document recommends does not make it secure. 152 This document does not show the messages to check Certificate 153 Revocation Lists (see [3]) as that is not part of the SIP call flow. 155 5. Known Problems 157 The binary dumps of the messages in Section 7.2 need to be updated to 158 match the text of the draft. 160 The messages are missing the accept headers. They should have the 161 following header: 163 Accept: multipart/signed 164 Accept: text/plain 165 Accept: application/pkcs7-mime 166 Accept: application/sdp 167 Accept: multipart/alternative 169 6. Certificates 171 6.1. CA Certificates 173 The certificate used by the CA to sign the other certificates is 174 shown below. This is a X509v3 certificate. Note that the basic 175 constraints allow it to be used as a CA. 177 Version: 3 (0x2) 178 Serial Number: 0 (0x0) 179 Signature Algorithm: sha1WithRSAEncryption 180 Issuer: C=US, ST=California, L=San Jose, O=sipit, 181 OU=Sipit Test Certificate Authority 182 Validity 183 Not Before: Jul 18 12:21:52 2003 GMT 184 Not After : Jul 15 12:21:52 2013 GMT 185 Subject: C=US, ST=California, L=San Jose, O=sipit, 186 OU=Sipit Test Certificate Authority 187 Subject Public Key Info: 188 Public Key Algorithm: rsaEncryption 189 RSA Public Key: (1024 bit) 190 Modulus (1024 bit): 191 00:c3:22:1e:83:91:c5:03:2c:3c:8a:f4:11:14:c6: 192 4b:9d:fa:72:78:c6:b0:95:18:a7:e0:8c:79:ba:5d: 193 a4:ae:1e:21:2d:9d:f1:0b:1c:cf:bd:5b:29:b3:90: 194 13:73:66:92:6e:df:4c:b3:b3:1c:1f:2a:82:0a:ba: 195 07:4d:52:b0:f8:37:7b:e2:0a:27:30:70:dd:f9:2e: 196 03:ff:2a:76:cd:df:87:1a:bd:71:eb:e1:99:6a:c4: 197 7f:8e:74:a0:77:85:04:e9:41:ad:fc:03:b6:17:75: 198 aa:33:ea:0a:16:d9:fb:79:32:2e:f8:cf:4d:c6:34: 199 a3:ff:1b:d0:68:28:e1:9d:e5 200 Exponent: 65537 (0x10001) 201 X509v3 extensions: 202 X509v3 Subject Key Identifier: 203 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 204 X509v3 Authority Key Identifier: 205 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 206 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 207 OU=Sipit Test Certificate Authority 208 serial:00 209 X509v3 Basic Constraints: 210 CA:TRUE 211 Signature Algorithm: sha1WithRSAEncryption 212 96:6d:1b:ef:d5:91:93:45:7c:5b:1f:cf:c4:aa:47:52:0b:34: 213 a8:50:fa:ec:fa:b4:2a:47:4c:5d:41:a7:3d:c0:d6:3f:9e:56: 214 5b:91:1d:ce:a8:07:b3:1b:a4:9f:9a:49:6f:7f:e0:ce:83:94: 215 71:42:af:fe:63:a2:34:dc:b4:5e:a5:ce:ca:79:50:e9:6a:99: 216 4c:14:69:e9:7c:ab:22:6c:44:cc:8a:9c:33:6b:23:50:42:05: 217 1f:e1:c2:81:88:5f:ba:e5:47:bb:85:9b:83:25:ad:84:32:ff: 218 2a:5b:8b:70:12:11:83:61:c9:69:15:4f:58:a3:3c:92:d4:e8: 219 6f:52 221 The ASN.1 parse of the CA certificate is shown below. 223 0:l= 804 cons: SEQUENCE 224 4:l= 653 cons: SEQUENCE 225 8:l= 3 cons: cont [ 0 ] 226 10:l= 1 prim: INTEGER :02 227 13:l= 1 prim: INTEGER :00 228 16:l= 13 cons: SEQUENCE 229 18:l= 9 prim: OBJECT :sha1WithRSAEncryption 230 29:l= 0 prim: NULL 231 31:l= 112 cons: SEQUENCE 232 33:l= 11 cons: SET 233 35:l= 9 cons: SEQUENCE 234 37:l= 3 prim: OBJECT :countryName 235 42:l= 2 prim: PRINTABLESTRING :US 236 46:l= 19 cons: SET 237 48:l= 17 cons: SEQUENCE 238 50:l= 3 prim: OBJECT :stateOrProvinceName 239 55:l= 10 prim: PRINTABLESTRING :California 240 67:l= 17 cons: SET 241 69:l= 15 cons: SEQUENCE 242 71:l= 3 prim: OBJECT :localityName 243 76:l= 8 prim: PRINTABLESTRING :San Jose 244 86:l= 14 cons: SET 245 88:l= 12 cons: SEQUENCE 246 90:l= 3 prim: OBJECT :organizationName 247 95:l= 5 prim: PRINTABLESTRING :sipit 248 102:l= 41 cons: SET 249 104:l= 39 cons: SEQUENCE 250 106:l= 3 prim: OBJECT :organizationalUnitName 251 111:l= 32 prim: PRINTABLESTRING : 252 Sipit Test Certificate Authority 253 145:l= 30 cons: SEQUENCE 254 147:l= 13 prim: UTCTIME :030718122152Z 255 162:l= 13 prim: UTCTIME :130715122152Z 256 177:l= 112 cons: SEQUENCE 257 179:l= 11 cons: SET 258 181:l= 9 cons: SEQUENCE 259 183:l= 3 prim: OBJECT :countryName 260 188:l= 2 prim: PRINTABLESTRING :US 261 192:l= 19 cons: SET 262 194:l= 17 cons: SEQUENCE 263 196:l= 3 prim: OBJECT :stateOrProvinceName 264 201:l= 10 prim: PRINTABLESTRING :California 265 213:l= 17 cons: SET 266 215:l= 15 cons: SEQUENCE 267 217:l= 3 prim: OBJECT :localityName 268 222:l= 8 prim: PRINTABLESTRING :San Jose 269 232:l= 14 cons: SET 270 234:l= 12 cons: SEQUENCE 271 236:l= 3 prim: OBJECT :organizationName 272 241:l= 5 prim: PRINTABLESTRING :sipit 273 248:l= 41 cons: SET 274 250:l= 39 cons: SEQUENCE 275 252:l= 3 prim: OBJECT :organizationalUnitName 276 257:l= 32 prim: PRINTABLESTRING : 277 Sipit Test Certificate Authority 278 291:l= 159 cons: SEQUENCE 279 294:l= 13 cons: SEQUENCE 280 296:l= 9 prim: OBJECT :rsaEncryption 281 307:l= 0 prim: NULL 282 309:l= 141 prim: BIT STRING 283 00 30 81 89 02 81 81 00-c3 22 1e 83 91 c5 03 2c .0......."....., 284 3c 8a f4 11 14 c6 4b 9d-fa 72 78 c6 b0 95 18 a7 <.....K..rx..... 285 e0 8c 79 ba 5d a4 ae 1e-21 2d 9d f1 0b 1c cf bd ..y.]...!-...... 286 5b 29 b3 90 13 73 66 92-6e df 4c b3 b3 1c 1f 2a [)...sf.n.L....* 287 82 0a ba 07 4d 52 b0 f8-37 7b e2 0a 27 30 70 dd ....MR..7{..'0p. 288 f9 2e 03 ff 2a 76 cd df-87 1a bd 71 eb e1 99 6a ....*v.....q...j 289 c4 7f 8e 74 a0 77 85 04-e9 41 ad fc 03 b6 17 75 ...t.w...A.....u 290 aa 33 ea 0a 16 d9 fb 79-32 2e f8 cf 4d c6 34 a3 .3.....y2...M.4. 291 ff 1b d0 68 28 e1 9d e5-02 03 01 00 01 ...h(........ 292 453:l= 205 cons: cont [ 3 ] 293 456:l= 202 cons: SEQUENCE 294 459:l= 29 cons: SEQUENCE 295 461:l= 3 prim: OBJECT :X509v3 Subject Key Identifier 296 466:l= 22 prim: OCTET STRING 297 04 14 6b 46 17 14 ea 94-76 25 80 54 6e 13 54 da ..kF....v%.Tn.T. 298 a1 e3 54 14 a1 b6 ..T... 299 490:l= 154 cons: SEQUENCE 300 493:l= 3 prim: OBJECT :X509v3 Authority Key Identifier 301 498:l= 146 prim: OCTET STRING 302 30 81 8f 80 14 6b 46 17-14 ea 94 76 25 80 54 6e 0....kF....v%.Tn 303 13 54 da a1 e3 54 14 a1-b6 a1 74 a4 72 30 70 31 .T...T....t.r0p1 304 0b 30 09 06 03 55 04 06-13 02 55 53 31 13 30 11 .0...U....US1.0. 305 06 03 55 04 08 13 0a 43-61 6c 69 66 6f 72 6e 69 ..U....Californi 306 61 31 11 30 0f 06 03 55-04 07 13 08 53 61 6e 20 a1.0...U....San 307 4a 6f 73 65 31 0e 30 0c-06 03 55 04 0a 13 05 73 Jose1.0...U....s 308 69 70 69 74 31 29 30 27-06 03 55 04 0b 13 20 53 ipit1)0'..U... S 309 69 70 69 74 20 54 65 73-74 20 43 65 72 74 69 66 ipit Test Certif 310 69 63 61 74 65 20 41 75-74 68 6f 72 69 74 79 82 icate Authority. 311 01 . 312 0092 - 313 647:l= 12 cons: SEQUENCE 314 649:l= 3 prim: OBJECT :X509v3 Basic Constraints 315 654:l= 5 prim: OCTET STRING 316 30 03 01 01 ff 0.... 317 661:l= 13 cons: SEQUENCE 318 663:l= 9 prim: OBJECT :sha1WithRSAEncryption 319 674:l= 0 prim: NULL 320 676:l= 129 prim: BIT STRING 321 00 96 6d 1b ef d5 91 93-45 7c 5b 1f cf c4 aa 47 ..m.....E|[....G 322 52 0b 34 a8 50 fa ec fa-b4 2a 47 4c 5d 41 a7 3d R.4.P....*GL]A.= 323 c0 d6 3f 9e 56 5b 91 1d-ce a8 07 b3 1b a4 9f 9a ..?.V[.......... 324 49 6f 7f e0 ce 83 94 71-42 af fe 63 a2 34 dc b4 Io.....qB..c.4.. 325 5e a5 ce ca 79 50 e9 6a-99 4c 14 69 e9 7c ab 22 ^...yP.j.L.i.|." 326 6c 44 cc 8a 9c 33 6b 23-50 42 05 1f e1 c2 81 88 lD...3k#PB...... 327 5f ba e5 47 bb 85 9b 83-25 ad 84 32 ff 2a 5b 8b _..G....%..2.*[. 328 70 12 11 83 61 c9 69 15-4f 58 a3 3c 92 d4 e8 6f p...a.i.OX.<...o 329 52 R 331 6.2. Host Certificates 333 The certificate for the host example.com is shown below. Note that 334 the Subject Alternative Name is set to example.com and is a DNS type. 335 The certificates for the other hosts are shown in Appendix B. 337 Data: 338 Version: 3 (0x2) 339 Serial Number: 340 01:95:00:71:02:33:00:55 341 Signature Algorithm: sha1WithRSAEncryption 342 Issuer: C=US, ST=California, L=San Jose, O=sipit, 343 OU=Sipit Test Certificate Authority 344 Validity 345 Not Before: Feb 3 18:49:08 2005 GMT 346 Not After : Feb 3 18:49:08 2008 GMT 347 Subject: C=US, ST=California, L=San Jose, O=sipit, 348 CN=example.com 349 Subject Public Key Info: 350 Public Key Algorithm: rsaEncryption 351 RSA Public Key: (1024 bit) 352 Modulus (1024 bit): 353 00:e6:31:76:b5:27:cc:8d:32:85:56:70:f7:c2:33: 354 33:32:26:42:5e:3c:68:71:7b:1f:79:50:d0:72:27: 355 3b:4a:af:f2:ce:d1:0c:bc:c0:5f:31:6a:43:e7:7c: 356 ad:64:bd:c7:e6:25:9f:aa:cd:2d:90:aa:68:84:62: 357 7b:05:be:43:a5:af:bb:ea:9d:a9:5b:a4:53:9d:22: 358 8b:da:96:2e:1f:3f:92:46:b8:cc:c8:24:3c:46:cd: 359 5d:2d:64:85:b1:a4:ca:01:f1:8e:c5:7e:0f:ff:00: 360 91:a3:ea:cb:3e:12:02:75:a4:bb:08:c8:d0:2a:ef: 361 b3:bb:72:7a:98:e5:ff:9f:81 362 Exponent: 65537 (0x10001) 363 X509v3 extensions: 364 X509v3 Subject Alternative Name: 365 DNS:example.com 366 X509v3 Basic Constraints: 367 CA:FALSE 368 X509v3 Subject Key Identifier: 369 22:EA:CB:38:66:1D:F1:96:0C:9A:47:B6:BB:1C:52: 370 44:B0:77:65:8D 371 Signature Algorithm: sha1WithRSAEncryption 372 ae:eb:49:ed:1e:f1:8d:26:a9:6d:03:82:92:d5:df:44:c4:1e: 373 1f:07:75:88:37:e4:76:97:35:12:59:98:79:78:16:6e:3b:b1: 374 c0:2b:db:85:02:6b:74:c9:5b:19:92:da:7e:f5:41:0b:bc:d2: 375 dd:45:aa:6f:be:24:dc:48:57:66:d9:2e:82:df:9e:8d:70:03: 376 73:75:ef:8f:7a:56:4c:cc:42:bd:31:45:b0:5e:ff:d1:3b:c4: 377 82:ee:fd:a7:c1:10:34:eb:81:49:1a:6b:86:7e:c7:61:1d:b3: 378 b9:0a:02:bd:84:f8:47:af:cf:f1:a8:73:a8:31:1d:20:7a:06: 379 7f:ac 381 6.3. User Certificates 383 The user certificate for fluffy@example.com is shown below. Note 384 that the Subject Alternative Name has a list of names with different 385 URL types such as a sip, im, or pres URL. This is necessary for 386 interoperating with CPIM gateway. In this example, example.com is 387 the domain for fluffy. The message could be coming from a host 388 called atlanta.example.com, and the AOR in the user certificate would 389 still be the same. The others are shown in Appendix B. 391 Data: 392 Version: 3 (0x2) 393 Serial Number: 394 01:95:00:71:02:33:00:58 395 Signature Algorithm: sha1WithRSAEncryption 396 Issuer: C=US, ST=California, L=San Jose, O=sipit, 397 OU=Sipit Test Certificate Authority 398 Validity 399 Not Before: Feb 3 18:49:34 2005 GMT 400 Not After : Feb 3 18:49:34 2008 GMT 401 Subject: C=US, ST=California, L=San Jose, O=sipit, 402 CN=fluffy@example.com 403 Subject Public Key Info: 404 Public Key Algorithm: rsaEncryption 405 RSA Public Key: (1024 bit) 406 Modulus (1024 bit): 407 00:ca:ab:9b:9b:4e:3c:d5:45:3c:ce:00:a6:36:a8: 408 b9:ec:d2:76:e2:b9:9b:e8:28:aa:ba:86:22:c5:cf: 409 33:3e:4f:6d:56:21:ae:bd:54:84:7c:14:14:f9:7d: 410 99:85:00:4e:93:d6:fd:6b:d4:d1:d4:55:8e:c9:89: 411 b1:af:2b:5f:23:99:4a:95:e5:68:65:64:1d:12:a7: 412 db:d3:d5:97:18:47:35:9c:e6:88:27:9d:a8:6c:ca: 413 2a:84:e6:62:d8:f1:e9:a2:1a:39:7e:0e:0f:90:a5: 414 a6:79:21:bc:2a:67:b4:dd:69:90:82:9a:ae:1f:02: 415 52:8a:58:d3:f5:d0:d4:66:67 416 Exponent: 65537 (0x10001) 417 X509v3 extensions: 418 X509v3 Subject Alternative Name: 419 URI:sip:fluffy@example.com, URI:im:fluffy@example.com, 420 URI:pres:fluffy@example.com 421 X509v3 Basic Constraints: 422 CA:FALSE 423 X509v3 Subject Key Identifier: 424 EC:DA:98:5E:E9:F7:F7:D7:EC:2B:29:4B:DA:25:EE:C7:C7: 425 7E:95:70 426 Signature Algorithm: sha1WithRSAEncryption 427 4c:46:49:6e:01:48:e2:d4:6e:d7:48:a1:f3:7b:c8:a5:98:37: 428 a5:44:46:58:9f:4a:37:7d:90:fb:5f:ff:36:bd:67:31:f0:29: 429 de:0a:e2:ea:b9:f0:5c:9f:ad:a0:de:e5:4e:42:8f:11:d8:41: 430 ea:68:be:db:c2:1e:fa:e5:8a:2d:7f:66:13:29:e9:da:8f:fb: 431 80:bf:7e:5e:b6:04:ad:08:5e:58:95:b7:c5:38:85:d5:65:31: 432 ad:80:cb:28:a7:4c:ad:11:fd:41:3b:37:77:5a:de:85:96:3d: 433 66:eb:5f:9a:f8:60:5f:8e:b1:fc:4a:43:53:b6:11:4d:2e:f4: 434 3d:ff 436 7. Callflow with Message Over TLS 438 7.1. TLS with Server Authentication 440 The flow below shows the edited SSLDump output of the host 441 example.com forming a TLS[4] connection to example.net. In this 442 example mutual authentication is not used. Note that the client 443 proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA 444 defined in [6]. The certificate returned by the server contains a 445 Subject Alternative Name that is set to example.net. A detailed 446 discussion of TLS can be found in [13]. 448 This example does not use the Server Extended Hello[5]. 450 New TCP connection #1: 127.0.0.1(55768) <-> 127.0.0.1(5061) 451 1 1 0.0060 (0.0060) C>SV3.1(49) Handshake 452 ClientHello 453 Version 3.1 454 random[32]= 455 42 16 8c c7 82 cd c5 87 42 ba f5 1c 91 04 fb 7d 456 4d 6c 56 f1 db 1d ce 8a b1 25 71 5a 68 01 a2 14 457 cipher suites 458 TLS_RSA_WITH_AES_256_CBC_SHA 459 TLS_RSA_WITH_AES_128_CBC_SHA 460 TLS_RSA_WITH_3DES_EDE_CBC_SHA 461 compression methods 462 NULL 463 1 2 0.0138 (0.0077) S>CV3.1(74) Handshake 464 ServerHello 465 Version 3.1 466 random[32]= 467 42 16 8c c7 c9 2c 43 42 bb 69 a5 ba f1 2d 69 75 468 c3 8d 3a 85 78 19 f2 e4 d9 2b 72 b4 cc dd e4 72 469 session_id[32]= 470 06 37 e9 22 56 29 e6 b4 3a 6e 53 fe 56 27 ed 1f 471 2a 75 34 65 f0 91 fc 79 cf 90 da ac f4 6f 64 b5 472 cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA 473 compressionMethod NULL 474 1 3 0.0138 (0.0000) S>CV3.1(1477) Handshake 475 Certificate 476 1 4 0.0138 (0.0000) S>CV3.1(4) Handshake 477 ServerHelloDone 478 1 5 0.0183 (0.0045) C>SV3.1(134) Handshake 479 ClientKeyExchange 480 EncryptedPreMasterSecret[128]= 481 a6 bd d9 4b 76 4b 9d 6f 7b 12 8a e4 52 75 9d 74 482 4f 06 e4 b0 bc 69 96 d7 42 ba 77 01 b6 9e 64 b0 483 ea c5 aa de 59 41 e4 f3 9e 1c 1c a9 48 f5 0a 3f 484 5e c3 50 23 15 d7 46 1d 69 79 76 ba 5e c8 ac 39 485 23 71 d0 0c 18 a6 a9 77 0f 7d 49 61 ef 6f 8d 32 486 54 f5 a4 1d 19 33 0a 64 ee 56 91 9b f4 f7 50 b1 487 11 4b 81 46 4c 36 df 70 98 04 dc 5c 8a 16 a9 2e 488 58 67 ae 5e 7a a9 44 2b 0b 7c 9c 2f 16 25 1a e9 489 1 6 0.0183 (0.0000) C>SV3.1(1) ChangeCipherSpec 490 1 7 0.0183 (0.0000) C>SV3.1(48) Handshake 491 1 8 0.0630 (0.0447) S>CV3.1(1) ChangeCipherSpec 492 1 9 0.0630 (0.0000) S>CV3.1(48) Handshake 493 1 10 0.3274 (0.2643) C>SV3.1(32) application_data 494 1 11 0.3274 (0.0000) C>SV3.1(720) application_data 495 1 12 0.3324 (0.0050) S>CV3.1(32) application_data 496 1 13 0.3324 (0.0000) S>CV3.1(384) application_data 497 1 9.2491 (8.9166) C>S TCP FIN 498 1 9.4023 (0.1531) S>C TCP FIN 500 7.2. MESSAGE Message Over TLS 502 Once the TLS session is set up, the following MESSAGE message (as 503 defined in [12] is sent from fluffy@example.com to 504 kumiko@example.net. Note that the URI has a SIPS URL and that the 505 VIA indicates that TLS was used. In order to format this document, 506 it was necessary to break up some of the lines across continuation 507 lines but the original messages have no continuation lines and no 508 breaks in the Identity header field value. 510 MESSAGE sips:kumiko@example.net SIP/2.0 511 To: 512 From: ;tag=03de46e1 513 Via: SIP/2.0/TLS 127.0.0.1:5071; 514 branch=z9hG4bK-d87543-58c826887160f95f-1--d87543-;rport 515 Call-ID: 0dc68373623af98a@Y2ouY2lzY28uc2lwaXQubmV0 516 CSeq: 1 MESSAGE 517 Contact: 518 Max-Forwards: 70 519 Content-Transfer-Encoding: binary 520 Content-Type: text/plain 521 Date: Sat, 19 Feb 2005 00:48:07 GMT 522 User-Agent: SIPimp.org/0.2.5 (curses) 523 Content-Length: 6 525 Hello! 527 The response is sent from example.net to example.com over the same 528 TLS connection. It is shown below. 530 SIP/2.0 200 OK 531 To: ;tag=4c53f1b8 532 From: ;tag=03de46e1 533 Via: SIP/2.0/TLS 127.0.0.1:5071; 534 branch=z9hG4bK-d87543-58c826887160f95f-1--d87543-; 535 rport=55768;received=127.0.0.1 536 Call-ID: 0dc68373623af98a@Y2ouY2lzY28uc2lwaXQubmV0 537 CSeq: 1 MESSAGE 538 Contact: 539 Content-Length: 0 541 8. Callflow with S/MIME-secured Message 543 8.1. MESSAGE Message with Signed Body 545 Example Signed Message. The value on the Content-Type line has been 546 broken across lines to fit on the page but it should not be broken 547 across lines in actual implementations. 549 MESSAGE sip:kumiko@example.net SIP/2.0 550 To: 551 From: ;tag=0c523b42 552 Via: SIP/2.0/UDP 68.122.119.3:5060; 553 branch=z9hG4bK-d87543-16a1192b7960f635-1--d87543-;rport 554 Call-ID: 27bb7608596d8914@Y2ouY2lzY28uc2lwaXQubmV0 555 CSeq: 1 MESSAGE 556 Contact: 557 Max-Forwards: 70 558 Content-Transfer-Encoding: binary 559 Content-Type: multipart/signed;boundary=151aa2144df0f6bd;\ 560 micalg=sha1;protocol="application/pkcs7-signature" 561 Date: Sat, 19 Nov 2005 23:34:50 GMT 562 User-Agent: SIPimp.org/0.2.5 (curses) 563 Content-Length: 639 565 --151aa2144df0f6bd 566 Content-Type: text/plain 567 Content-Transfer-Encoding: binary 569 hello 570 --151aa2144df0f6bd 571 Content-Type: application/pkcs7-mime;name=smime.p7s 572 Content-Disposition: attachment;handling=required;filename=smime.p7s 573 Content-Transfer-Encoding: binary 575 ******************* 576 * BINARY BLOB 1 * 577 ******************* 578 --151aa2144df0f6bd-- 580 It is important to note that the signature is computed across 581 includes the header and excludes the boundary. The value on the 582 Message-body line ends with CRLF. The CRLF is included in the 583 boundary and should not be part of the signature computation. In the 584 example below, the signature is computed over data starting with the 585 C in the Content-Type and ending with the o in the hello. 587 Content-Type: text/plain 588 Content-Transfer-Encoding: binary 590 hello 592 ASN.1 parse of binary Blob 1. Note that at address 30, the hash for 593 the signature is specified as SHA1. Also note that the sender's 594 certificate is not attached as it is optional in [8]. 596 0:SEQUENCE { 597 4: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 598 15: [0] { 599 19: SEQUENCE { 600 23: INTEGER 1 601 26: SET { 602 28: SEQUENCE { 603 30: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 604 : } 605 : } 606 37: SEQUENCE { 607 39: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 608 : } 609 50: SET { 610 54: SEQUENCE { 611 58: INTEGER 1 612 61: SEQUENCE { 613 63: SEQUENCE { 614 65: SET { 615 67: SEQUENCE { 616 69: OBJECT IDENTIFIER countryName (2 5 4 6) 617 74: PrintableString 'US' 618 : } 619 : } 620 78: SET { 621 80: SEQUENCE { 622 82: OBJECT IDENTIFIER stateOrProvinceName(2 5 4 8) 623 87: PrintableString 'California' 624 : } 625 : } 626 99: SET { 627 101: SEQUENCE { 628 103: OBJECT IDENTIFIER localityName (2 5 4 7) 629 108: PrintableString 'San Jose' 630 : } 631 : } 632 118: SET { 633 120: SEQUENCE { 634 122: OBJECT IDENTIFIER organizationName (2 5 4 10) 635 127: PrintableString 'sipit' 636 : } 637 : } 638 134: SET { 639 136: SEQUENCE { 640 138: OBJECT IDENTIFIER 641 : organizationalUnitName (2 5 4 11) 642 143: PrintableString 643 'Sipit Test Certificate Authority' 644 : } 645 : } 646 : } 647 177: INTEGER 01 95 00 71 02 33 00 58 648 : } 649 187: SEQUENCE { 650 189: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 651 : } 652 196: SEQUENCE { 653 198: OBJECT IDENTIFIER rsaEncryption 654 (1 2 840 113549 1 1 1) 655 209: NULL 656 : } 657 211: OCTET STRING 658 : C4 0E 40 A5 7F 88 5B 06 90 E7 B2 40 39 DF 33 E3 659 : 18 39 C2 9E EC 51 5E 06 E2 D5 DA F0 F6 87 77 1E 660 : F7 F9 C1 26 04 20 F8 30 B8 C0 37 92 F6 5C 64 DD 661 : 87 41 43 F8 2D E5 28 20 35 7D 84 72 2B 5E 5F CF 662 : 2E 73 93 03 4B DB 35 4C CA 44 CD F8 91 58 A2 4C 663 : 65 A1 A6 EA DC E6 1B 1E DD DA BD BE 1A EA 9F 62 664 : 12 7A D1 1A E7 27 B5 96 88 B9 E6 EF 79 C0 E5 40 665 : A0 5F 9F 93 09 4C 65 55 DA A8 FE CD 02 10 A9 67 666 : } 667 : } 668 : } 669 : } 670 : } 672 8.2. MESSAGE Message with Encrypted Body 674 Example encrypted text/plain message that says "hello": 676 MESSAGE sip:kumiko@example.net SIP/2.0 677 To: 678 From: ;tag=6d2a39e4 679 Via: SIP/2.0/UDP 68.122.119.3:5060; 680 branch=z9hG4bK-d87543-44ddc0a217a51788-1--d87543-;rport 681 Call-ID: 031be67669ea9799@Y2ouY2lzY28uc2lwaXQubmV0 682 CSeq: 1 MESSAGE 683 Contact: 684 Max-Forwards: 70 685 Content-Disposition: attachment;handling=required;filename=smime.p7 686 Content-Transfer-Encoding: binary 687 Content-Type: application/pkcs7-mime;\ 688 smime-type=enveloped-data;name=smime.p7m 689 Date: Sat, 19 Nov 2005 23:33:18 GMT 690 User-Agent: SIPimp.org/0.2.5 (curses) 691 Content-Length: 435 693 ***************** 694 * BINARY BLOB 2 * 695 ***************** 697 ASN.1 parse of binary Blob 2. Note that at address 324, the 698 encryption is set to aes128-CBC. 700 0:SEQUENCE { 701 4: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 702 15: [0] { 703 19: SEQUENCE { 704 23: INTEGER 0 705 26: SET { 706 30: SEQUENCE { 707 34: INTEGER 0 708 37: SEQUENCE { 709 39: SEQUENCE { 710 41: SET { 711 43: SEQUENCE { 712 45: OBJECT IDENTIFIER countryName (2 5 4 6) 713 50: PrintableString 'US' 714 : } 715 : } 716 54: SET { 717 56: SEQUENCE { 718 58: OBJECT IDENTIFIER stateOrProvinceName(2 5 4 8) 719 63: PrintableString 'California' 720 : } 721 : } 722 75: SET { 723 77: SEQUENCE { 724 79: OBJECT IDENTIFIER localityName (2 5 4 7) 725 84: PrintableString 'San Jose' 726 : } 727 : } 728 94: SET { 729 96: SEQUENCE { 730 98: OBJECT IDENTIFIER organizationName (2 5 4 10) 731 103: PrintableString 'sipit' 732 : } 733 : } 734 110: SET { 735 112: SEQUENCE { 736 114: OBJECT IDENTIFIER 737 : organizationalUnitName (2 5 4 11) 738 119: PrintableString 739 'Sipit Test Certificate Authority' 740 : } 741 : } 742 : } 743 153: INTEGER 01 95 00 71 02 33 00 57 744 : } 745 163: SEQUENCE { 746 165: OBJECT IDENTIFIER rsaEncryption(1 2 840 113549 1 1 1) 747 176: NULL 748 : } 749 178: OCTET STRING 750 : 7C F3 8A 02 E8 44 2C A6 9B 3E 64 46 06 D3 95 2D 751 : DF 19 8F 5D 0C 24 6B F7 93 03 E7 3C 98 F1 57 74 752 : 67 70 0E 40 F8 05 96 34 06 36 97 61 5C 0B 2D 61 753 : AD CB F0 82 56 23 E5 09 C0 C7 BC A5 F4 A3 B7 59 754 : 5D 8B 44 6E 3F 7C DE 50 54 2C 95 73 CC 9A 74 8B 755 : A9 26 68 FD F8 82 01 43 1D 30 3C 0C 40 B2 19 A2 756 : 5A 90 06 0F AC 95 CB DF 21 13 F2 26 C8 10 45 A3 757 : F4 AB 54 74 72 FD 91 6C 73 27 BF 62 47 7B EC 58 758 : } 759 : } 760 309: SEQUENCE { 761 311: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 762 322: SEQUENCE { 763 324: OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2) 764 335: OCTET STRING 765 : 50 9E 44 AA A5 54 C3 5C 0D 9A DF 65 F7 47 36 99 766 : } 767 353: [0] 768 : 55 C5 C7 EA 5D 5A 7C 06 95 3C 24 25 D5 53 08 BB 769 : 04 19 B4 BF 84 15 F5 6C 4C 80 05 14 06 3E F3 D1 770 : B7 04 A1 46 4E E3 1E FF 16 35 79 2A 06 DD A8 83 771 : 61 24 E1 62 B0 DA 03 53 78 F8 B7 CD B2 11 68 57 772 : BE 5F 13 49 B9 5E AB 6F 6E 26 2D 8A A5 9E E5 10 773 : } 774 : } 775 : } 776 : } 778 8.3. MESSAGE Message with Encrypted and Signed Body 780 In the example below, one of the headers is contained in a box and is 781 split across two lines. This was only done to make it fit in the RFC 782 format. This header should not have the box around it and should be 783 on one line with no whitespace between the "mime;" and the "smime- 784 type". Note that Content-Type is split across lines for formatting 785 but is not split in the real message. 787 MESSAGE sip:kumiko@example.net SIP/2.0 788 To: 789 From: ;tag=361300da 790 Via: SIP/2.0/UDP 68.122.119.3:5060; 791 branch=z9hG4bK-d87543-0710dbfb18ebb8e6-1--d87543-;rport 792 Call-ID: 5eda27a67de6283d@Y2ouY2lzY28uc2lwaXQubmV0 793 CSeq: 1 MESSAGE 794 Contact: 795 Max-Forwards: 70 796 Content-Transfer-Encoding: binary 797 Content-Type: multipart/signed;boundary=1af019eb7754ddf7;\ 798 micalg=sha1;protocol="application/pkcs7-signature" 799 Date: Sat, 19 Nov 2005 23:35:40 GMT 800 User-Agent: SIPimp.org/0.2.5 (curses) 801 Content-Length: 1191 803 --1af019eb7754ddf7 804 |--See note about stuff in this box --------------------| 805 |Content-Type: application/pkcs7-mime; | 806 | smime-type=enveloped-data;name=smime.p7m | 807 |-------------------------------------------------------| 808 Content-Disposition: attachment;handling=required;filename=smime.p7 809 Content-Transfer-Encoding: binary 811 ***************** 812 * BINARY BLOB 3 * 813 ***************** 814 --1af019eb7754ddf7 815 Content-Type: application/pkcs7-mime;name=smime.p7s 816 Content-Disposition: attachment;handling=required;filename=smime.p7s 817 Content-Transfer-Encoding: binary 819 ***************** 820 * BINARY BLOB 4 * 821 ***************** 822 --1af019eb7754ddf7-- 824 Binary blob 3 826 0:SEQUENCE { 827 4: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 828 15: [0] { 829 19: SEQUENCE { 830 23: INTEGER 0 831 26: SET { 832 30: SEQUENCE { 833 34: INTEGER 0 834 37: SEQUENCE { 835 39: SEQUENCE { 836 41: SET { 837 43: SEQUENCE { 838 45: OBJECT IDENTIFIER countryName (2 5 4 6) 839 50: PrintableString 'US' 840 : } 841 : } 842 54: SET { 843 56: SEQUENCE { 844 58: OBJECT IDENTIFIER stateOrProvinceName(2 5 4 8) 845 63: PrintableString 'California' 846 : } 847 : } 848 75: SET { 849 77: SEQUENCE { 850 79: OBJECT IDENTIFIER localityName (2 5 4 7) 851 84: PrintableString 'San Jose' 852 : } 853 : } 854 94: SET { 855 96: SEQUENCE { 856 98: OBJECT IDENTIFIER organizationName (2 5 4 10) 857 103: PrintableString 'sipit' 858 : } 859 : } 860 110: SET { 861 112: SEQUENCE { 862 114: OBJECT IDENTIFIER 863 : organizationalUnitName (2 5 4 11) 864 119: PrintableString 865 'Sipit Test Certificate Authority' 866 : } 867 : } 868 : } 869 153: INTEGER 01 95 00 71 02 33 00 57 870 : } 871 163: SEQUENCE { 872 165: OBJECT IDENTIFIER rsaEncryption(1 2 840 113549 1 1 1) 873 176: NULL 874 : } 875 178: OCTET STRING 876 : 69 B3 A3 61 F4 F8 63 4F 46 0A 1A AB 0F 1B 16 09 877 : DB 3A A9 12 3B 23 F0 C9 4E 68 04 15 AB 42 4F 66 878 : FA EF 8D C4 86 88 41 BA 53 A3 88 49 54 E3 0E EB 879 : E3 69 63 5A DF 77 2A 8A 1E 42 7E E4 A7 DB CF 90 880 : 7E 90 47 FD 20 C9 B2 3B 2F A5 42 2A 68 66 9A 25 881 : 53 D8 FC D9 70 9F 02 0F F2 D2 CB F7 15 7F 6F 4F 882 : AB 19 0F 55 51 A2 76 24 DA A3 78 F4 1E 31 AA 6A 883 : DF 7C E2 42 3B C5 33 11 E0 EE EE 2E 02 9D 8C 1A 884 : } 885 : } 886 309: SEQUENCE { 887 311: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 888 322: SEQUENCE { 889 324: OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2) 890 335: OCTET STRING 891 : 72 71 AE FE 55 12 BA 99 92 EA D3 C5 9C B6 60 69 892 : } 893 353: [0] 894 : 9A 9F DD 9E 58 B6 BE 59 BC CA 6C 3E 3E F5 81 A3 895 : 30 A0 38 A3 1C 25 92 E3 AA 07 7A 85 7C 36 F0 12 896 : 9F 80 DF 98 BD 1E 22 EC BF 8B 03 EB 33 AE 81 75 897 : D3 91 0A 82 1E 13 8C 60 F0 2B 55 DD 03 52 84 52 898 : B1 51 5F E2 F0 CE 8A 94 4B F5 46 CE BF 77 80 8F 899 : } 900 : } 901 : } 902 : } 904 Binary Blob 4 906 0:SEQUENCE { 907 4: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 908 15: [0] { 909 19: SEQUENCE { 910 23: INTEGER 1 911 26: SET { 912 28: SEQUENCE { 913 30: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 914 : } 915 : } 916 37: SEQUENCE { 917 39: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 918 : } 919 50: SET { 920 54: SEQUENCE { 921 58: INTEGER 1 922 61: SEQUENCE { 923 63: SEQUENCE { 924 65: SET { 925 67: SEQUENCE { 926 69: OBJECT IDENTIFIER countryName (2 5 4 6) 927 74: PrintableString 'US' 928 : } 929 : } 930 78: SET { 931 80: SEQUENCE { 932 82: OBJECT IDENTIFIER stateOrProvinceName(2 5 4 8) 933 87: PrintableString 'California' 934 : } 935 : } 936 99: SET { 937 101: SEQUENCE { 938 103: OBJECT IDENTIFIER localityName (2 5 4 7) 939 108: PrintableString 'San Jose' 940 : } 941 : } 942 118: SET { 943 120: SEQUENCE { 944 122: OBJECT IDENTIFIER organizationName (2 5 4 10) 945 127: PrintableString 'sipit' 946 : } 947 : } 948 134: SET { 949 136: SEQUENCE { 950 138: OBJECT IDENTIFIER 951 : organizationalUnitName (2 5 4 11) 952 143: PrintableString 953 'Sipit Test Certificate Authority' 954 : } 955 : } 956 : } 957 177: INTEGER 01 95 00 71 02 33 00 58 958 : } 959 187: SEQUENCE { 960 189: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 961 : } 962 196: SEQUENCE { 963 198: OBJECT IDENTIFIER rsaEncryption(1 2 840 113549 1 1 1) 964 209: NULL 965 : } 966 211: OCTET STRING 967 : 16 85 D7 B8 08 C6 32 D5 85 7D 26 0F F8 89 DA D0 968 : B8 FE 96 FB 40 C9 0E 52 C7 FE A5 87 55 F7 1A 86 969 : 29 80 CC B0 75 A3 72 DD 76 80 6B 2C 8B C0 14 EA 970 : 49 FE 18 8F A6 27 BC 5B 60 C1 FE 15 4D 2A 42 DD 971 : 33 F8 0D D0 77 11 73 82 31 4D 31 66 B1 CF 95 F0 972 : 9D EE DF 81 E3 54 DF 8C 7B 63 70 D4 93 B5 AE E0 973 : D4 90 DB BE D8 0B 3B C2 99 6A FE 5A F0 E9 F0 DF 974 : 85 F2 A6 8C 28 33 0D 77 04 59 78 06 E5 0E 48 78 975 : } 976 : } 977 : } 978 : } 979 : } 981 9. Test Consideration 983 This section describes some common interoperability problems. 984 Implementers should verify that their clients do the correct things 985 and perhaps make their clients forgiving in what they receive, or at 986 least have them produce reasonable error messages when interacting 987 with software that has these problems. 989 A common problem is that some SIP clients incorrectly only do SSLv3 990 and do not support TLS. 992 Many SIP clients were found to accept expired certificates with no 993 warning or error. 995 TLS and S/MIME can provide the identity of the peer that a client is 996 communicating with in the Subject Alternative Name in the 997 certificate. The software must check that this name corresponds to 998 the identity the server is trying to contact. If a client is trying 999 to set up a TLS connection to good.example.com and it gets a TLS 1000 connection set up with a server that presents a valid certificate but 1001 with the name evil.example.com, it must generate an error or warning 1002 of some type. Similarly with S/MIME, if a user is trying to 1003 communicate with sip:fluffy@example.com, one of the items in the 1004 Subject Alternate Name set in the certificate must match. 1006 Some implementations used binary MIME encodings while others used 1007 base64. The preferred form is binary. 1009 In several places in this draft, the messages contain the encoding 1010 for the SHA-1 digest algorithm identifier. The preferred form for 1011 encoding as set out in Section 2 of RFC 3370 [10] is the form in 1012 which the optional AlgorithmIdentifier parameter field is omitted. 1013 However, RFC 3370 also says the receives need to be able to receive 1014 the form in which the AlgorithmIdentifier parameter field is present 1015 and set to NULL. Examples of the form using NULL can be found in 1016 Section 4.2 of RFC 4134 [11]. Receivers really do need to be able to 1017 receive the form that includes the NULL because the NULL form, while 1018 not preferred, is what was observed as being generated by most 1019 implementations. Implementers should also note that if the algorithm 1020 is MD5 instead of SHA1, then the form that omits the 1021 AlgorithmIdentifier parameters field is not allowed and the sender 1022 has to use the form where the NULL is included. 1024 The preferred encryption algorithm for S/MIME in SIP is AES as 1025 defined in RFC 3853 [9]. 1027 Interoperability was generally better when UAs did not attach the 1028 senders' certificates. Attaching the certificates significantly 1029 increases the size of the messages, and since it can not be relied 1030 on, it does not turn out to be useful in most situations. 1032 10. IANA Considerations 1034 No IANA actions are required. 1036 11. Acknowledgments 1038 Many thanks to the developers of all the open source software used to 1039 create these call flows. This includes the underling crypto and TLS 1040 software used from openssl.org, the SIP stack from 1041 www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. 1042 The TLS flow dumps were done with SSLDump from 1043 http://www.rtfm.com/ssldump. The book "SSL and TLS" [13] was a huge 1044 help in developing the code for these flows. It's sad there is no 1045 second edition. 1047 Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat 1048 Chan, and Lyndsay Campbell who all helped find and correct mistakes 1049 in this document. 1051 12. References 1053 12.1. Normative References 1055 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1056 Levels", BCP 14, RFC 2119, March 1997. 1058 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1059 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1060 Session Initiation Protocol", RFC 3261, June 2002. 1062 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1063 Public Key Infrastructure Certificate and Certificate 1064 Revocation List (CRL) Profile", RFC 3280, April 2002. 1066 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 1067 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 1068 January 1999. 1070 [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1071 T. Wright, "Transport Layer Security (TLS) Extensions", 1072 RFC 3546, June 2003. 1074 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1075 Transport Layer Security (TLS)", RFC 3268, June 2002. 1077 [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1078 (S/MIME) Version 3.1 Message Specification", RFC 3851, 1079 July 2004. 1081 [8] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 1082 August 2002. 1084 [9] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1085 Requirement for the Session Initiation Protocol (SIP)", 1086 RFC 3853, July 2004. 1088 [10] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 1089 RFC 3370, August 2002. 1091 12.2. Informative References 1093 [11] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1094 July 2005. 1096 [12] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1097 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1098 Instant Messaging", RFC 3428, December 2002. 1100 [13] Rescorla, E., "SSL and TLS - Designing and Building Secure 1101 Systems", 2001. 1103 Appendix A. Making Test Certificates 1105 These scripts allow you to make certificates for test purposes. The 1106 certificates will all share a common CA root so that everyone running 1107 these scripts can have interoperable certificates. WARNING - these 1108 certificates are totally insecure and are for test purposes only. 1109 All the CA created by this script share the same private key to 1110 facilitate interoperability testing, but this totally breaks the 1111 security since the private key of the CA is well known. 1113 The instructions assume a Unix-like environment with openssl 1114 installed, but openssl does work in Windows too. Make sure you have 1115 openssl installed by trying to run "openssl". Run the makeCA script 1116 found in Appendix A.1; this creates a subdirectory called demoCA. If 1117 the makeCA script cannot find where your openssl is installed you 1118 will have to set an environment variable called OPENSSLDIR to 1119 whatever directory contains the file openssl.cnf. You can find this 1120 with a "locate openssl.cnf". You are now ready to make certificates. 1122 To create certs for use with TLS, run the makeCert script found in 1123 Appendix A.2 with the fully qualified domain name of the proxy you 1124 are making the certificate for. For example, "makeCert 1125 host.example.net". This will generate a private key and a 1126 certificate. The private key will be left in a file named 1127 domain_key_example.net.pem in pem format. The certificate will be in 1128 domain_cert_example.net.pem. Some programs expect both the 1129 certificate and private key combined together in a PKCS12 format 1130 file. This is created by the script and left in a file named 1131 example.net.p12. Some programs expect this file to have a .pfx 1132 extension instead of .p12 - just rename the file if needed. A filed 1133 with a certificate signing request, called example.net.csr, is also 1134 created and can be used to get the certificate signed by another CA. 1136 A second argument indicating the number of days for which the 1137 certificate should be valid can be passed to the makeCert script. It 1138 is possible to make an expired certificate using the command 1139 "makeCert host.example.net 0". 1141 Anywhere that a password is used to protect a certificate, the 1142 password is set to the string "password". 1144 The root certificate for the CA is in the file 1145 root_cert_fluffyCA.pem. 1147 For things that need DER format certificates, a certificate can be 1148 converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM 1149 -out cert.der -outform DER". 1151 Some programs expect certificates in PKCS#7 format (with a file 1152 extension of .p7c). You can convert these from PEM format to PKCS#7 1153 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ 1154 cacert.pem -outform DER -out cert.p7c" 1156 IE, Outlook, and Netscape can import and export .p12 files and .p7c 1157 files. You can convert a pkcs7 certificate to PEM format with 1158 "openssl pkcs7 -in cert.p7c -inform DER -outform PEM -out cert.pem". 1160 The private key can be converted to pkcs8 format with "openssl pkcs8 1161 -in a_key.pem -topk8 -outform DER -out a_key.p8c" 1163 In general, a TLS client will just need the root certificate of the 1164 CA. A TLS server will need its private key and its certificate. 1166 These could be in two PEM files or one .p12 file. An S/MIME program 1167 will need its private key and certificate, the root certificate of 1168 the CA, and the certificate for every other user it communicates 1169 with. 1171 A.1. makeCA script 1173 #!/bin/sh 1174 #set -x 1176 rm -rf demoCA 1178 mkdir demoCA 1179 mkdir demoCA/certs 1180 mkdir demoCA/crl 1181 mkdir demoCA/newcerts 1182 mkdir demoCA/private 1183 echo "01" > demoCA/serial 1184 hexdump -n 4 -e '4/1 "%04u"' /dev/random > demoCA/serial 1185 touch demoCA/index.txt 1187 # You may need to modify this for where your default file is 1188 # you can find where yours in by typing "openssl ca" 1189 for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do 1190 CONF=${OPENSSLDIR:=$D}/openssl.cnf 1191 [ -f ${CONF} ] && break 1192 done 1194 if [ ! -f $CONF ]; then 1195 echo "Can not find file $CONF - set your OPENSSLDIR variable" 1196 exit 1197 fi 1198 cp $CONF openssl.cnf 1200 cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem <